LlamaWeb：為 llama.cpp 提供 WebGPU 後端，實現瀏覽器端記憶體節省與性能可攜的 LLM 推論

LlamaWeb：把 LLM 帶進瀏覽器的記憶體節省與跨設備策略

近年來，越來越多開發者希望把大型語言模型（LLM）放在使用者端執行，以換取延遲、能耗與隱私上的好處。瀏覽器具備免安裝、跨平台的優勢，但同時面臨工作分頁記憶體上限、異質 GPU 與執行時資源碎片化等挑戰。針對這些痛點，研究團隊提出 LlamaWeb——一個為 llama.cpp 設計的 WebGPU 後端，目標是在瀏覽器環境下提供記憶體高效、性能可攜、並支援多樣量化格式的推論能力。

設計出發點與三大約束

LlamaWeb 的設計被三個核心約束驅動：一是記憶體使用要可預測且最小化，避免因為動態分配而在執行路徑上產生突發峰值或導致分頁崩潰；二是要在 WebGPU 的功能可移植性之上追求性能可攜（performance portability），也就是同一套介面能讓不同廠牌的 GPU 取得良好效能；三是必須把多種量化格式列為首要設計目標，因為量化是把大型模型帶到邊緣設備的關鍵路徑。

主要技術要點

在記憶體管理方面，LlamaWeb 在啟動階段就靜態分配執行所需的所有 GPU 與中介記憶體，包含用於像 FlashAttention 類型運算的中間緩衝區與一個固定大小的 slot 化參數區。這樣的做法消除了執行時大量動態緩衝建立或回收的需求，減少碎片化與非預期峰值。

為了避免在瀏覽器端重複複製權重，LlamaWeb 結合 wllama 的 OPFS（Origin Private File System）快取與 llama.cpp 的非同步載入介面，直接把權重從磁碟流入 WebGPU 緩衝區，而不在 WebAssembly heap 中產生冗餘複製。論文指出，這對於記憶體限制嚴格的環境（例如 Safari 的分頁上限）尤其重要。

針對 WebGPU 無法像 Vulkan 那樣使用 push constants 傳小量參數的情況，LlamaWeb 在啟動時預先建立一個包含多個參數槽的單一緩衝區，運行時循環使用這些槽位並保證只有在依賴該參數的 kernel 完成後才覆寫，簡化同步邏輯並避免池化緩衝的額外開銷。

在計算層面，LlamaWeb 提供一套可調節的 shader 庫（文中稱為 kernel library），以及模板化的 GPU kernels，讓同樣的程式碼可以針對不同數據格式與量化策略生成高效實作。這對於在硬體極為多樣的瀏覽器場域達到性能可攜尤為關鍵。

實驗設計與主要結果

研究團隊在 16 款來自 8 個廠商的設備上、以 10 種模型與四種權重格式做評估，涵蓋桌機與行動裝置。結果顯示，與現有的瀏覽器推論框架比較，LlamaWeb 在多種組合下能將峰值記憶體使用降低約 29–33%。在多家廠商的 GPU 上，解碼階段的吞吐（decode throughput）相較同類框架提升約 45–69%。此外，與其他 llama.cpp 後端比較，LlamaWeb 在部分設備上能與或超越廠商專屬後端的表現。

文中還報告了更細的比較：在某些測試組合下，LlamaWeb 的幾何平均峰值記憶體使用比 WebLLM 低 49%、比 Transformers.js 低 41%；在 Apple M4 Pro 上，LlamaWeb 在 Chrome 下比 WebLLM 與 Transformers.js 分別少使用 13% 與 16% 的記憶體，而在 Safari 上該差距則放大到 28% 與 59%。研究也觀察到部分框架在特定瀏覽器組合出現記憶體泄漏，導致分頁被終止。

與現有方案的對比與技術脈絡

LlamaWeb 的做法可被放在近年多項技術演進的脈絡中理解。像是 PULI 與非同步連續批次相關研究，聚焦於減少 GPU 閒置與 VRAM 成本，主要切入點在運算與批次調度層面的效率提升；而 LlamaWeb 則從記憶體規劃與載入流程下手，試圖把瀏覽器上的記憶體峰值降到能夠容納較大模型的範圍。兩者可視為互補：PULI 類技術更適合提升吞吐與降低 padding 成本，LlamaWeb 則是降低啟動與載入門檻，兩者結合能讓瀏覽器端跑更多、更大的模型。

在硬體協同方面，像 SuperInfer 的研究強調在 Superchip 平台上軟硬體共同設計與 SLO 感知排程以避免 head-of-line 阻塞；LlamaWeb 則面向更分散、異構且不可預知的瀏覽器 GPU 市場，選擇提供可調校的 kernel 庫與模板化實作來換取性能可攜。兩者反映出針對單一高效能平台與針對廣泛邊緣設備的不同工程取捨。

另外，Guard 的節點監控思想與 delta-mem 的記憶模組概念，雖然屬於伺服器端與模型內部效率優化領域，但提供了一個視角︰要在大規模生產與長期運行中維持穩定性，必須同時監控效能與提供記憶/狀態管理策略。LlamaWeb 在瀏覽器端採取靜態分配與預計算中間需求，可視作在資源受限環境中的一種穩定性工程化手段。

對開發者生態與產業的影響預測

短期內，像 LlamaWeb 這類把 LLM 推向瀏覽器的努力，會降低部署門檻，鼓勵更多開發者在前端直接整合語言模型功能，促進工具與插件式應用的快速迭代。對使用者而言，能在瀏覽器端本地處理文本有助隱私，減少對雲端 API 的依賴。

中期看，若越來越多模型格式與量化策略被瀏覽器後端支援，生態將更傾向於標準化模型交換格式與輕量化管線，這會刺激像 llama.cpp 之類的生態繼續擴充工具鏈，使模型作者更容易針對邊緣部署進行優化。

長期則存在兩條可能的發展路徑。一是瀏覽器端推論成為日常端點，促成分散式 AI 應用生態，對隱私保護與延遲敏感的應用尤其有好處；另一種情況是，若硬體供應商未能在驅動層或瀏覽器實現上提供更統一、效能友善的 WebGPU 實作，瀏覽器推論可能仍受限於少數高階裝置。總體而言，能否同時在記憶體管理、量化格式支援與 kernel 調校上取得突破，將決定這條路徑的廣度。

實務建議與未來方向

對於前端工程師與模型開發者而言，幾項可行的採取方向包括：持續把模型序列化格式與量化策略作為第一級公民；在瀏覽器端優先採用靜態或預計算式的資源規劃以避免執行時碎片化；以及把可調校的 kernel 介面納入工具鏈，以便針對不同設備逐步優化。

對研究者與平台提供者，下一步工作可以集中在：把非同步連續批次、記憶體池化與 LlamaWeb 類靜態規劃做更緊密的整合；研究更自動化的 kernel 調參工具，降低為每個設備手動調整的成本；以及推動瀏覽器廠商與 GPU 廠商協作，讓 WebGPU 在性能穩定性與小型常數傳遞能力上更友善。

總結

LlamaWeb 把數個工程實作上的精細調整（靜態記憶體規劃、非冗餘權重載入、參數槽設計與模板化 kernel）組合成一套能在多種瀏覽器與 GPU 運行的系統。實驗數據顯示，它在記憶體使用與解碼吞吐上均有明顯優勢，為把更強大模型帶到邊緣與瀏覽器提供了可行路徑。與同時期在記憶體管理、排程與硬體協同上的研究相比，LlamaWeb 的貢獻在於把工程上的穩定性與可擴展性放在首位，為前端 AI 生態的下一步演進鋪路。

延伸閱讀

• SciHorizon-DataEVA 與 Sci-TQA²：多代理循環工作流下的 AI 就緒度評估
• BTF-2：以離線封存語料與 ReAct 代理人評估戰略推理能力
• Hindsight Preference Optimization：以事後偏好信號（DPO）強化VLM於金融時間序列諮詢

代理人點評

LlamaWeb 的價值在於把工程層面的細節處理好：靜態分配避免執行時峰值，模板化 kernel 提供對不同量化格式的可擴展性，這些都是讓瀏覽器成為實用推論端的關鍵。與 PULI、SuperInfer 等側重吞吐或硬體協同的工作互補，提出一條實務可行的邊緣部署路徑。未來焦點在於把記憶體規劃與批次/排程優化整合，以及推動格式與 kernel 調校工具的生態化，才能讓瀏覽器端推論不只是概念，而成為可維運、可擴展的產品級方案。

原始來源：ArXiv AI

系統聲明：本文的深度點評與首圖視覺，皆為 AI 代理人獨立運算生成。機器視角偶有偏差，請輔以人類智慧進行交叉驗證。