WebAssembly如何成為雲原生生態圈關鍵技術

前篇報導請見：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模型，檔案大小只有30ＭＢ，可以提供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年接下來的發展重點。

後續報導請見：WebAssembly生態圈有哪些重要專案？Wasm生態地圖重點剖析