WebGPU 特性檢測不足以在手機上執行小型 LLM

作者本想透過 WebGPU 在手機瀏覽器中離線執行小型語言模型，無需伺服器推理。特性檢測很簡單：請求 WebGPU 介面卡，讀取其限制，如果緩衝區大小足夠大，就假定可以執行。所有測試的瀏覽器環境都暴露了 WebGPU，且報告的限制看起來足夠容納模型權重。然而，實際執行結果卻並非如此。

裝置報告的 GPU 能力和推理能否完成是兩回事。以下是作者測量的四種情況。所有資料來自倉庫中的原始測量檔案。使用的模型包括 Llama-3.2-1B-Instruct、Qwen2.5-1.5B-Instruct 和 Qwen2.5-0.5B-Instruct，量化至約 4 位。引擎包括 WebLLM 0.2.84、transformers.js 4.2.0 和 wllama 3.4.1。每次執行均冷啟動，短提示約 50 詞元，長提示約 1200 詞元。

第一種情況：iPhone 上的 Safari 在生成過程中過載頁面。裝置為 iPhone 11 Pro Max，iOS 18.7，Safari 26.5。報告 webgpu: true，Apple 介面卡，支援 f16，maxBufferSize 為 715827880 位元組。作為初步檢查，該大小足以容納模型權重。但所有執行均未完成。Qwen2.5-1.5B 透過 WebLLM 下載了全部 728 MB 後，在初始化時失敗並報錯“TypeError: Load failed”。Llama-3.2-1B 透過 WebLLM 走得更遠，到達了 WebGPU 後端的生成階段，然後頁面在生成過程中過載，沒有 JavaScript 可見的異常或可捕獲的“記憶體不足”錯誤。較小的 Qwen2.5-0.5B 透過 wllama 在初始化時也出現了同樣的問題：標籤頁在準備完畢前過載。該裝置上所有引擎和模型均零執行完成。故障模式是無法處理的錯誤，而是標籤頁在背後重啟。

第二種情況：LINE 的內建瀏覽器暴露了 WebGPU，但執行從未完成。裝置為 Pixel 8a，8 GB 記憶體，在 Android 16 上的 LINE 內建瀏覽器中開啟。報告 webgpu: true，Arm Valhall 介面卡，支援 f16，maxBufferSize 為 4294967292 位元組（4 GB 上限）。介面卡限制與成功完成的 Chrome 執行無明顯區別。Llama-3.2-1B 會話開始後，下載中途停滯，從未達到一次完整執行。該會話的結果檔案執行列表為空。介面卡報告沒有透露內建瀏覽器是否能完成下載和初始化，實際上它不能。

第三種情況：同一硬體和模型，僅因引擎不同吞吐量相差約兩倍。在搭載 AMD RDNA 4 GPU 的 Windows 桌面、Chrome 148 上，作者用短提示在三個引擎上分別執行了相同的 Llama-3.2-1B。WebGPU 均存在且被使用。解位元速率為三次執行的中位數。WebLLM 0.2.84 的解碼速率為 196.17 詞元/秒，transformers.js 4.2.0 為 125.41，wllama 3.4.1 為 97.61。最快引擎的解碼速度是最慢的約兩倍。三者的 WebGPU 支援標誌相同，但測量到的吞吐量不同。

第四種情況：Pixel 8a 能完成執行，但長提示詞的預填充耗時 76 秒。裝置同樣是 Pixel 8a，但這次使用普通 Chrome 149，而非內建瀏覽器。Arm Valhall 介面卡報告同樣的 4 GB 緩衝區上限。此環境下模型載入並執行至完成，因此作者有完整的時間記錄。短提示（52 輸入詞元）時，首次輸出詞元時間約 3.8 秒；長提示（1213 輸入詞元）時，首次輸出詞元時間為 77153、76996 和 76449 毫秒，即 76 到 77 秒。之後解碼速度接近 9 詞元/秒。同一裝置處理單行提示只需幾秒，但讀取一頁上下文卻要超過一分鐘。

在這四個測試環境中，WebGPU 的暴露和較大介面卡限制不足以預測小型 LLM 執行能否完成。特性檢測回答了能否請求 WebGPU，而非推理能否完成。