WebLLM：把 LLM 推論搬進瀏覽器，靠 WebGPU 與 OpenAI 相容介面
High-performance In-browser LLM Inference Engine
秒懂
- 它是什麼？
- WebLLM 是 MLC LLM 的姊妹專案，用 TypeScript 包裝 WebGPU 推論，讓模型在瀏覽器內執行、不經伺服器。它的價值在於相容 OpenAI API 與預建模型清單，代價是使用者必須先下載數 GB 權重，且瀏覽器支援面窄。
- 適合誰用？
- WebLLM 適合已經鎖定 Chromium 系瀏覽器、能接受首次載入數 GB 模型權重、且需要資料留在使用者裝置上的前端團隊，例如離線筆記工具、瀏覽器擴充功能或內部演示。不適合需要穩定首字延遲、必須支援 Safari 與 Firefox、或模型權重不能公開下載的產品。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 2 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
為什麼要在瀏覽器裡跑模型
把推論放在瀏覽器解決的是一個很具體的問題：使用者資料不必離開裝置。README 的說法是「enable privacy while enjoying GPU acceleration」，而整個引擎「runs inside the browser with no server support」。對於處理草稿、日誌、內部文件的工具，這個差別不是行銷語言，而是架構上的分水嶺：沒有伺服器就沒有推論成本曲線，也沒有伺服器端的資料留存問題。
目標讀者因此相當明確。前端工程師想把聊天或摘要功能加進既有網頁應用，卻不想維運 GPU 後端；做 Chrome Extension 的人，README 有專門的範例；還有需要在示範環境展示模型能力、不想先開雲端執行個體的團隊。反過來說，如果你的產品要對外提供服務、要計費、要控制輸出品質，把模型交給使用者裝置執行，等於把延遲與可用性一併交出去。
WebGPU 是唯一入口，也是唯一的門檻
WebLLM 的加速完全建立在 WebGPU 上，README 的敘述是「accelerated with WebGPU」。這代表兩件事。第一，沒有 WebGPU 就沒有退路，專案沒有描述 WebGL 或 WASM 後備路徑。第二，支援範圍由瀏覽器決定，而不是由 WebLLM 決定。
專案本身是 MLC LLM 的伴隨專案，模型以 MLC 格式提供，推論核心來自 TVM 生態。README 提到結構化 JSON 生成「implemented in the WebAssembly portion of the model library」，說明實際的計算與取樣邏輯有一部分落在 WASM，TypeScript 層負責的是引擎介面、模型下載與快取。這個分層對使用者的意義是：你拿到的是 npm 套件，但真正的推論能力取決於編譯好的模型產物，不是純 JavaScript。
因此評估 WebLLM 的第一步不是讀 API，而是確認你的使用者用什麼瀏覽器。這一點在 README 裡沒有被特別強調，但它是整個採用決策的前提。
CreateMLCEngine：對齊 OpenAI 的介面設計
安裝走標準套件管理器，README 給了三種寫法：npm install @mlc-ai/web-llm、yarn add @mlc-ai/web-llm、pnpm install @mlc-ai/web-llm。也可以完全不裝，透過 CDN 直接匯入：
import * as webllm from "https://esm.run/@mlc-ai/web-llm";
或動態匯入：const webllm = await import("https://esm.run/@mlc-ai/web-llm");
主要操作都經過 MLCEngine 這個介面。README 的說明是建立實例並載入模型後，就能取得聊天補全。專案宣稱與 OpenAI API 完全相容，涵蓋 streaming、JSON-mode、logit-level 控制、seeding，function-calling 標註為 WIP。這個相容性決定了遷移成本：如果你的程式碼本來就打 chat completions 的形狀，改動集中在建立引擎與換掉請求端點，而不是重寫提示詞管理與串流解析。
要注意的是「相容」的邊界。README 明列 function-calling 仍在開發中，如果你的產品依賴工具呼叫，這條路目前走不通。JSON-mode 則被描述為在 WASM 層實作，屬於專案較有信心的一塊。
預建模型清單與自帶模型的取捨
WebLLM 不是任意模型都能跑。README 明確指出支援的是 MLC Models 的子集，清單定義在 prebuiltAppConfig.model_list。目前列出的家族包括 Llama 3 與 Llama 2、Hermes-2-Pro-Llama-3、Phi 3／Phi 2／Phi 1.5、Gemma-2B、Mistral-7B-v0.3 與幾個 Mistral 微調版本，以及 Qwen2 的 0.5B、1.5B、7B。
這份清單透露了專案的定位：以中小型開源模型為主，參數量從 0.5B 到 7B 級別。這不是限制的抱怨，而是事實描述。想在瀏覽器裡跑更大的模型，會直接撞上使用者裝置的記憶體與下載時間。
若清單裡沒有你要的模型，README 給的兩條路是開 issue 請求新增，或自行以 MLC 格式編譯並透過自訂模型機制接入。第二條路意味著你要進入 MLC LLM 的編譯流程，這已經超出前端工程的範圍，需要有人能處理模型轉換與量化。把這一點算進採用成本，比事後才發現沒人會編譯模型要誠實得多。
Worker、Service Worker 與擴充功能：整合面的實際形狀
WebLLM 提供 Web Worker 與 Service Worker 支援，README 的目的是「Optimize UI performance and manage the lifecycle of models efficiently」。這不是可有可無的加分項。推論是長時間佔用 GPU 的工作，放在主執行緒會直接凍結介面。專案把這條路徑寫進主要特色，等於承認單執行緒用法只適合最簡單的示範。
Chrome Extension 支援同樣有專門範例，README 提到基本與進階兩種擴充功能範例。這是專案最自然的落地場景之一：擴充功能本來就活在瀏覽器裡，沒有伺服器，使用者對資料外傳也較敏感。
範例資源方面，README 指向 examples 目錄、JSFiddle 與 CodePen 上的聊天機器人示範，以及 WebLLM Chat 這個較完整的專案，其中 app/client/webllm.ts 被點名為進階整合的參考。對評估者來說，這份範例密度比文件本身更能說明 API 的實際用法。
下載、快取與首次體驗的真實成本
WebLLM 沒有伺服器，代價轉移到使用者身上：模型權重必須下載到本機。README 沒有給出各模型的檔案大小，但從模型清單的參數量級可以推斷，這是數百 MB 到數 GB 的下載。首次開啟的等待時間因此不是毫秒級的問題，而是分鐘級的問題。
這個特性會改變產品設計。你需要進度回報、需要快取策略、需要處理使用者在載入途中關閉分頁的情況。README 提到模型生命週期管理是 Worker 支援的目的之一，但沒有描述快取失效或版本升級時的行為。這一塊在採用前應該自己驗證，而不是假設它會自動處理好。
另一個未在材料中說明的是多分頁情境：兩個分頁同時載入同一模型會發生什麼，README 沒有交代。這類問題通常要到實際部署才會浮現。
什麼時候不該選 WebLLM
最明顯的替代路線是伺服器端推論，例如透過 Ollama 或 vLLM 這類自架服務，再用相容 OpenAI 的 HTTP 端點接前端。兩者的差異不在模型能力，而在成本落在誰身上。伺服器端推論讓你把延遲、模型選擇與版本升級握在自己手裡，代價是 GPU 成本與資料經過你的機器。WebLLM 把這三件事交給使用者裝置，換來零邊際推論成本與資料不出裝置。
如果你的產品必須支援 Safari 或 Firefox 的廣泛版本，WebLLM 會直接變成不可行選項，因為它沒有非 WebGPU 的退路，而這類瀏覽器的 WebGPU 可用性由瀏覽器廠商決定，不是你能控制的。
如果你的模型是內部微調、權重不能公開下載，瀏覽器端推論的前提就不成立，因為權重必須送到使用者機器上。這不是 WebLLM 的缺陷，而是架構的必然。
還有一種情況是輸出品質必須嚴格可控。使用者裝置五花八門，量化版本與硬體差異可能導致行為不一致，而 README 沒有提供這方面的相容性保證。
維護節奏、授權與採用前的檢查清單
專案採用 Apache-2.0，對於商業整合是相對寬鬆的選擇。但要留意的是授權只涵蓋 WebLLM 本身的程式碼，不涵蓋你下載的模型權重。README 列出的是模型名稱與來源，每個模型家族有自己的授權條款，例如 Llama 系列與 Qwen 系列並不相同。把模型散布給使用者下載之前，這一層要自己確認，這裡不構成法律意見。
維護面可以觀察到的訊號是發布節奏：v0.2.82、v0.2.83、v0.2.85，版本號停在 0.2.x，語意化版本意義上仍屬未定版階段，API 有變動的可能。從 v0.2.83 到 v0.2.85 之間約四個半月，屬於持續但不算密集的更新。
採用前的檢查清單可以很短：確認目標瀏覽器的 WebGPU 狀態、確認 prebuiltAppConfig.model_list 是否涵蓋所需模型、確認該模型的授權允許你的散布方式、確認首次載入的檔案大小在使用者可接受範圍內。四項都通過，再開始寫 CreateMLCEngine 的整合程式碼。
編輯結論
WebLLM 適合已經鎖定 Chromium 系瀏覽器、能接受首次載入數 GB 模型權重、且需要資料留在使用者裝置上的前端團隊，例如離線筆記工具、瀏覽器擴充功能或內部演示。不適合需要穩定首字延遲、必須支援 Safari 與 Firefox、或模型權重不能公開下載的產品。採用前先確認三件事：目標瀏覽器是否真的具備 WebGPU、prebuiltAppConfig.model_list 裡是否有你需要的模型家族、以及模型檔案的授權條款是否允許你的散布方式。這三項都能在寫第一行程式前查完。
社群筆記