作為一種無孔不入的力量，一項(xiàng)技術(shù)的演變往往是一個(gè)耗時(shí)的過程。但邊緣計(jì)算不同——它的影響半徑正以指數(shù)級(jí)的速度增長(zhǎng)。AI是邊緣發(fā)揮關(guān)鍵作用的領(lǐng)域，從 Kneron、IBM、Synaptic、Run:ai 等公司如何投資該技術(shù)就可以看出這一點(diǎn)。

在太空技術(shù)或醫(yī)療保健等其他行業(yè)，包括Fortifyedge和Sidus Space在內(nèi)的公司都在為邊緣計(jì)算做大規(guī)劃。

有關(guān)應(yīng)用程序性能和安全性的技術(shù)進(jìn)步和問題

然而，這種近乎無處不在的存在勢(shì)必會(huì)引發(fā)有關(guān)應(yīng)用程序性能和安全性的問題。邊緣計(jì)算也不例外，近年來，它在容納新工具方面變得更加包容。

根據(jù)我作為初創(chuàng)公司新興技術(shù)負(fù)責(zé)人的經(jīng)驗(yàn)，我發(fā)現(xiàn)在采用邊緣計(jì)算之前了解邊緣計(jì)算的發(fā)展方向是勢(shì)在必行的。在我之前為 ReadWrtie 撰寫的文章中，我討論了邊緣計(jì)算的主要推動(dòng)因素。在本文中，我的重點(diǎn)是最近的技術(shù)發(fā)展，這些發(fā)展試圖解決緊迫的工業(yè)問題并塑造未來。

WebAssembly將成為JavaScript庫的更好替代品

基于 JavaScript 的 AI/ML 庫在基于 Web 的應(yīng)用程序中很流行且成熟。驅(qū)動(dòng)力是通過運(yùn)行邊緣分析來提高交付個(gè)性化內(nèi)容的效率。但它有限制，并且不像沙箱那樣提供安全性。VM 模塊不保證安全的沙盒執(zhí)行。此外，對(duì)于基于容器的應(yīng)用程序，啟動(dòng)延遲是主要限制因素。

WebAssembly 作為邊緣應(yīng)用程序開發(fā)的替代方案正在迅速崛起。它是可移植的，并通過沙箱運(yùn)行時(shí)環(huán)境提供安全性。作為一個(gè)加號(hào)，它允許容器比冷(慢)啟動(dòng)容器更快地啟動(dòng)。

企業(yè)可以利用基于 WebAssembly 的代碼在瀏覽器中運(yùn)行 AI/ML 推理以及通過 CDN PoP 運(yùn)行程序邏輯。它在各個(gè)行業(yè)的滲透率顯著增長(zhǎng)，研究通過分析來自源代碼存儲(chǔ)庫、包管理器和實(shí)時(shí)網(wǎng)站等多個(gè)來源的二進(jìn)制文件來支持它。識(shí)別面部表情和處理圖像或視頻以提高操作效率的用例將從 WebAssembly 中獲益更多。

TinyML確保更好地優(yōu)化邊緣AI

邊緣 AI 是指在邊緣部署 AI/ML 應(yīng)用程序。然而，大多數(shù)邊緣設(shè)備在計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)帶寬方面不如云或服務(wù)器機(jī)器資源豐富。

TinyML 是在資源受限設(shè)備上使用 AI/ML。它驅(qū)動(dòng)設(shè)備邊緣的邊緣 AI 實(shí)現(xiàn)。在 TinyML 下，可能的優(yōu)化途徑是優(yōu)化 AI/ML 模型和優(yōu)化 AI/ML 框架，而為此，ARM 架構(gòu)是一個(gè)完美的選擇。

它是一種廣泛接受的邊緣設(shè)備架構(gòu)。研究表明，對(duì)于 AI/ML 推理等工作負(fù)載，與 x86 相比，ARM 架構(gòu)的性能性價(jià)比更高。

對(duì)于模型優(yōu)化，開發(fā)人員使用模型修剪、模型收縮或參數(shù)量化。

但 TinyML 在模型部署、維護(hù)不同模型版本、應(yīng)用程序可觀察性、監(jiān)控等方面存在一些界限。這些操作挑戰(zhàn)統(tǒng)稱為 TinyMLOP。隨著 TinyML 的日益普及，產(chǎn)品工程師將更傾向于 TinyMLOP 解決方案提供平臺(tái)。

為多個(gè)CSP取消架構(gòu)塊的編排

云服務(wù)提供商(CSP)現(xiàn)在提供更靠近網(wǎng)絡(luò)邊緣的資源，提供不同的好處。這給喜歡與多個(gè) CSP 合作的企業(yè)帶來了一些架構(gòu)挑戰(zhàn)。完美的解決方案需要根據(jù)實(shí)時(shí)網(wǎng)絡(luò)流量、延遲需求和其他參數(shù)優(yōu)化放置邊緣工作負(fù)載。

對(duì)以最佳方式管理分布式邊緣工作負(fù)載的編排和執(zhí)行的服務(wù)的需求量很大。但他們必須確保最佳的資源管理和服務(wù)水平協(xié)議 (SLA)。

Kubernetes、 Docker Swarm 等編排工具現(xiàn)在對(duì)管理基于容器的工作負(fù)載或服務(wù)有很高的需求。當(dāng)應(yīng)用程序在網(wǎng)絡(luò)規(guī)模上運(yùn)行時(shí)，這些工具可以很好地工作。但在邊緣計(jì)算的情況下，我們有資源限制，這些編排工具的控制平面完全不合適，因?yàn)樗鼈兿拇罅抠Y源。

K3S和KubeEdge等項(xiàng)目致力于改進(jìn)和調(diào)整 Kubernetes 以實(shí)現(xiàn)特定于邊緣的實(shí)現(xiàn)。根據(jù)這份測(cè)試報(bào)告，KubeEdge 聲稱可以擴(kuò)展到 10 萬個(gè)并發(fā)邊緣節(jié)點(diǎn)。這些工具將進(jìn)行進(jìn)一步的改進(jìn)和優(yōu)化，以滿足邊緣計(jì)算的要求。

聯(lián)邦學(xué)習(xí)激活節(jié)點(diǎn)學(xué)習(xí)并減少數(shù)據(jù)泄露

聯(lián)邦學(xué)習(xí)是一種分布式機(jī)器學(xué)習(xí) (ML) 方法，其中模型是在終端設(shè)備、組織或個(gè)人等數(shù)據(jù)源上單獨(dú)構(gòu)建的。

在邊緣計(jì)算方面，聯(lián)邦機(jī)器學(xué)習(xí)技術(shù)很有可能會(huì)流行起來，因?yàn)樗梢杂行У亟鉀Q與分布式數(shù)據(jù)源、高數(shù)據(jù)量和數(shù)據(jù)隱私約束相關(guān)的問題。

使用這種方法，開發(fā)人員不必將學(xué)習(xí)數(shù)據(jù)傳輸?shù)街醒敕?wù)器。相反，多個(gè)分布式邊緣節(jié)點(diǎn)可以一起學(xué)習(xí)共享機(jī)器學(xué)習(xí)模型。

與使用差異隱私技術(shù)以及聯(lián)邦學(xué)習(xí)相關(guān)的研究提案也得到了很大的支持。他們承諾在未來加強(qiáng)數(shù)據(jù)隱私。

零信任架構(gòu)擁有更好的安全承諾

傳統(tǒng)的基于邊界的安全方法不適用于邊緣計(jì)算。由于邊緣計(jì)算的分布式特性，沒有明顯的邊界。

但是，零信任架構(gòu)是一種網(wǎng)絡(luò)安全策略，它在訪問資源時(shí)不假定信任。零信任的原則是“從不信任，始終驗(yàn)證”。每個(gè)請(qǐng)求都應(yīng)該經(jīng)過身份驗(yàn)證、授權(quán)和持續(xù)驗(yàn)證。

如果我們考慮邊緣計(jì)算的分布式特性，它很可能有更廣泛的攻擊面。零信任安全模型可能是保護(hù)邊緣資源、工作負(fù)載以及與邊緣交互的集中式云的最佳選擇。

綜上所述

IoT、Metaverse和區(qū)塊鏈應(yīng)用程序不斷變化的需求將觸發(fā)邊緣計(jì)算的高度采用，因?yàn)樵摷夹g(shù)可以保證這些領(lǐng)域更好的性能、合規(guī)性和增強(qiáng)的用戶體驗(yàn)。了解圍繞邊緣計(jì)算的這些關(guān)鍵技術(shù)進(jìn)步可以幫助您做出決策并提高實(shí)施的成功率。