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，而非推理能否完成。