前篇報導請見:Wasm是雲原生技術的下一步發展,更是GAI實現快速推論關鍵助力
2023年是WebAssembly快速起飛的一年,CNCF和Wasm社群聯手,開始大力推廣這項技術,為了方便各界進行導入評估,他們盤點了相關專案和工具鏈,在第一屆WasmCon大會上正式發表了Wasm生態地圖(Wasm Landscape)第一版,後來也整合到原本的雲原生生態地圖中,成為其中一項子類別。
CNCF在生態地圖中強調,WebAssembly的特性是一個安全的沙盒,可以提供一個輕量、快速、安全、跨語言、跨平臺的應用程式執行環境。這項技術快速成了雲原生技術的其中一項關鍵技術。
Wasm的跨硬體環境、跨平臺和高效能計算能力,在這兩年爆紅的生成式AI浪潮中,也找到了新的應用場景,開始受到生成式AI開發社群和企業的重視。
專門提供Wasm平臺服務的新創Fermyon技術長Radu Matie指出,許多AI開發者愛用容器技術來部署各式各樣的AI推論,就是希望能用更快的方式來回應模型推論的結果。但是,「容器化AI冷啟動最大的挑戰是,數GB的容器映像檔和LLM模型資料。」他強調。
想要用GPU硬體來執行一隻AI推論程式,除了開發者自己的程式碼之外,還需要Nvidia的CUDA runtime,以及AI技術框架像是PyTorch、TensorFlow等函式庫,這樣的容器映像檔至少要4.8GB大小,再加上所用的LLM模型檔案大小可能高達10~50GB,想要建立一個容器化的AI推論應用,至少要15GB,也拖慢冷啟動的速度,往往需要30秒,甚至好幾分鐘,開發者多半得先啟動一隻AI推論服務來待命,這也限制了AI推論可部署和執行的模式。
Radu Matie指出,若改用Wasm來封裝AI推論應用程式碼,只需要數MB檔案大小,而不需要數GB的容器映像檔,冷啟動速度可以大幅縮短到幾毫秒,也就千分之幾秒,可以切割出短暫的GPU算力,來提供「剛好即時(Just in time)」的AI推論回應。「不需要將GPU綁定到特定容器來待命,可以簡化和更善用GPU基礎架構的算力。」這正是吸引GAI開發者和相關技術專案開始嘗試Wasm的關鍵。
甚至今年也出現了專門用Wasm打包的AI推論框架LlamaEdge,包括了一套10億參數量的Llama 2模型,檔案大小只有30MB,可以提供GPU原生應用執行速度,也能快速部署到Docker和K8s叢集中。
CNCF舉行首次Wasm大調查
CNCF在2023年底舉辦第一次的Wasm大調查,來了解開發者怎麼運用這項技術,調查了255位有Wasm實戰經驗的開發者。調查發現,Wasm應用範圍早已擴散到各類型的應用需求,不侷限於Web應用。6成開發用來打造Web應用,35%用於資料視覺化處理,也有3成2用於IoT環境,結合Wasm和AI應用的開發者也高達3成,這是最常見的四大類應用場景,也可以反映出Wasm技術目前最適合的四類場景。其他應用需求,像是遊戲、邊緣運算、加密、伺服器端服務也都有1~2成的採用比例。
目前約有4成開發者高度願意繼續用於瀏覽器環境,而有2成6則願意用於非瀏覽器環境,不過,也有2成開發者擔心這項技術還在發展中,保持觀望態度,還沒決定未來是否要跟進採用。甚至有5~7%開發者更為謹慎,決定還沒有到可以採用的程度。
CNCF在2023年底公布首次Wasm大調查,顯示Wasm應用範圍已擴散到各類型的應用需求,6成開發者用來打造Web應用,35%用於資料視覺化處理,也有3成2用於IoT環境,結合Wasm和AI應用的開發者也高達3成。圖片來源/CNCF
Wasm技術最吸引開發者的特色,包括了超快啟動速度,可以用於探索新應用,以及可跨專案共享程式碼、可提高JavaScript效能、滿足高運算任務的需求、可到處執行的二進位檔等等。這些都是吸引開發者,讓他們願意,甚至很想用的原因。
開發者打造Wasm應用所用的開發語言排名,JavaScript理所當然是第一名,高達45%,幾乎有一半的Wasm應用採用了JavaScript,其次則是C#(31%)、C++(30%)、Python(29%)和Java(29%)。特別的是,用COBOL這個老牌語言來打造Wasm的開發者竟然也高達15%。超過34%的開發者在開發專案中開始採用WASI,另有34%開發者預計未來一年會採用。
對於可以提供元件模式的WASI專案,多數Wasm開發者都知道這項專案,目前有34%的開發者正在用,也有3成預計未來一年會開始採用。吸引開發者採用WASI的主要原因,高達四成看上了WASI能讓Wasm程式碼具有可移動性(Portability),也能大幅簡化Wasm的部署。另外減少複雜度、提高WebAssembly原生能力和Runtime獨立性,都是WASI受到青睞的原因。目前WASI專案也計畫比照Wasm,申請成為W3C標準,正在提案討論過程中。Wasm開發者最期待WASI未來可以增加HTTP、IO/streams、SQL這三項能力。
根據CNCF在2023年底公布的Wasm大調查,開發者頭號痛點是除錯困難,像是現有除錯工具的支援還不夠,第二項困難是不同Runtime的效能差異很大,導致開發者得自行挑選適合自己應用場景的runtime,增加開發專案管理的複雜度。圖片來源/CNCF
不過,從這次調查中,也可以看到目前Wasm開發的挑戰和相關工具還不夠成熟,有待發展之初。Wasm開發者最頭痛的三大困難,高達2成開發者認為除錯非常困難,像是現有除錯工具的支援還不夠或是得自己尋找除錯作法,第二項困難是不同Runtime的效能差異很大,這就導致開發者得自行挑選適合自己應用場景的runtime,或是針對不同場景採用不同的runtime,這也增加了開發專案管理的複雜度。第三個挑戰也是runtime的問題,高達15%的Wasm開發者認為現有Wasm runtime的開發者體驗落差太多,彼此的操作習慣,命令語法差異很大,得學習不同套的作法,提高了不少學習門檻和開發複雜度。其他開發挑戰還有像是,缺乏了更完整的工具、學習資源不足、特定瀏覽器有相容問題、需要不少程式碼客制等挑戰。
這些困難都是Wasm目前技術發展的挑戰,也是相關Wasm工具鏈未來的機會。
WASI小組加速發展元件模式,要讓不同語言的Wasm元件直接互動
Cosmonic技術長Bailey Hayes也是WASI小組共同主席。這位將Wasm推廣到瀏覽器以外世界的關鍵推手,在今年初KubeCon歐洲大會的演講中,她介紹了WASI最新的元件模式,目前是預覽第二版,也就是0.2版,吸引了雲原生社群的高度關注。這個WASI元件模式,可以讓不同開發語言所編譯的Wasm程式,有一套標準的輸入輸出方式,互相溝通,甚至放到同一個更大的Wasm元件中互動。舉例來說,用Go語言寫的Wasm元件,和用Rust語言寫的Wasm元件,有共同的標準輸入輸出方式,就像用同一種語言開發的元件一樣,甚至可以把這兩個元件,放入一個更大的Wasm元件中混用。這個元件模型,讓Wasm具備了跨各種語言的能力。
Bailey Hayes指出,元件模式將會限制不同元件只能用標準輸入、輸出管道來確保安全性,但也可以在元件內部建立全域式變數和記憶體,用同一個runtime的跨元件間呼叫速度,甚至可以短到奈秒等級的超高速回應。她預告,新版WASI 0.2版草案標準即將完成,就會納入這個全新的元件模式。
不只如此,WASI在0.2版中,也將開始支援網路能力,換句話說,Wasm元件不只是可以在單一應用環境中彼此溝通,未來也看好能與外部環境,甚至網際網路上的第三方應用元件相互溝通,有了網路溝通能力,也可以讓Wasm元件更適合用來打造一支支微服務程式碼,甚至建立一個全用Wasm元件組成的微服務架構。
下一步,Bailey Hayes預告,WASI預覽第三版的0.3版,要進一步開始讓WASI支援原生的非同步能力,讓瀏覽器外的wasm元件,可以用非同步的方式,來彼此呼叫和協作,這是2025年接下來的發展重點。
熱門新聞
2024-11-29
2024-12-02
2024-11-30
2024-11-29
2024-11-29
2024-11-29
2024-11-29