把 LLM 跑在瀏覽器裡：WebGPU + WebLLM 實戰筆記
AI 出現後，網站設計師最大的利多是什麼？不是自動生成 UI，而是能夠打造從前根本不可能存在的體驗。但要做到這件事，現有的 AI 開發方式有幾道牆要先拆。
AI 出現之後，網站設計師最大的利多是什麼？
我認為不是 Copilot 幫你寫程式，也不是 AI 生成 UI 稿。而是一件更根本的事：你現在有機會打造從前根本不可能存在的體驗。
手機 app 爆發 vs. AI 的變化
先退一步看一個大格局。
手機 app 出現的時候，真正被顛覆的不是「app 的形式」，而是內容的分佈方式。過去媒體消費是主流驅動的——你看的是 Netflix 上架的片、聽的是唱片公司推的歌。手機把門檻砍到幾乎是零，YouTube、TikTok、Suno、Sora 讓任何人都能做內容，長尾需求第一次有機會被滿足。
AI 現在正在對生產力工具做同樣的事：
左上角是舊世界的主流：Microsoft Office、Jira，這些工具用「一個產品服務所有人」的邏輯設計，結果是每個人都在用一個對自己來說只有 30% 合適的工具。AI 讓右下角開始爆發——Cursor、Custom GPTs、Notion AI，每個工具都可以針對特定的使用情境深度優化。
這個象限的移動，就是設計師的機會所在。
How might we build UI/UX that was impossible before?
那些之前不可能存在的體驗
具體來說，什麼樣的體驗是「之前不可能存在」的？
幾個方向：
- 流程中的即時推理：不是一個問答框，而是在用戶填表、操作流程的當下，根據他的行為即時給出有意義的回應。
- 超個人化的介面邏輯：同一個功能，對不同使用者顯示不同的引導路徑，由模型判斷而非規則判斷。
- 離線可用的 AI 輔助：網路不穩的環境裡，AI 功能不應該是第一個消失的東西。
這些場景有一個共同的前提：模型需要非常靠近使用者，延遲要低、成本要可控、可用性要高。
但這裡有一個現實的問題：現有的 AI 開發方式，很難做到這些。
用外部 API 的五道牆
大多數 AI 功能的開發方式是打第三方 API。這個路徑快，但當你認真要做上面那些體驗時，你會撞到五道牆：
- 費用誰出：token 費用算在你的成本裡，還是讓用戶付？沒有清晰答案，而且難以控制。
- 延遲太高：每次互動都要一個完整的 round-trip。想做真正即時的體驗，這個延遲是障礙。
- 網路依賴：沒網路就沒 AI。在很多真實場景，這不是邊緣案例。
- 流量限制：用戶多起來就開始收到 429。你對這件事幾乎沒有控制權。
- 開發體驗：要怎麼 mock 一個 streaming AI 回應？每次開發都要真的打 API，慢又貴。
這五個問題的共同根源：模型不在你這裡。
WebLLM：讓模型住在瀏覽器
WebLLM 是 MLC AI 開發的開源套件，讓你在瀏覽器裡直接執行語言模型，不需要後端。底層結合兩個技術：
- WebGPU：瀏覽器對 GPU 的直接存取層，讓矩陣運算跑在用戶的顯示卡上。
- WebAssembly：處理 CPU 端的序列邏輯，補齊 GPU 不擅長的部分。
模型第一次載入時下載到 Cache Storage，之後再開頁面直接從本地讀。效能上比 native 執行約慢 20%，對互動場景來說可以接受。記憶體通常在 1GB 以下。
API 設計對齊 OpenAI，包括 streaming、structured JSON output、tool calling 都支援——原本呼叫 ChatGPT 的程式碼遷移成本很低。
從微調到瀏覽器：三個步驟
如果需要針對特定任務客製化模型：
1. 微調
用 Unsloth 搭配 LoRA 做微調。LoRA 不改動模型全部參數，只在特定層加低秩適配器，訓練量大幅降低。
2. 量化
用 MLC-LLM 把模型從 float32 壓到 float16 或 int8，縮到 1GB 左右，效能損失有限。
3. 部署設定
在 WebLLM 指定模型位置、model ID 和 architecture config 即可載入。
兩個落地案例
MBTI 問卷即時輔助
問卷題目措辭模糊，用戶填到一半不確定意思。把小模型跑在頁面裡，讓用戶直接問「這題是什麼意思」——不用離開頁面、不打外部 API、不用擔心費用。
AI Town 多 Agent 模擬
多個 agent 持續互動的模擬場景。如果每一步都打外部 API，費用和延遲都撐不住。模型搬到瀏覽器，模擬可以長時間跑，成本幾乎是零。
小模型正在變強
這個方向成立有個大前提：小模型的能力邊界正在快速擴大。
1B 到 3B 的模型，在特定任務上的表現已經可以和幾年前的大模型相比。加上微調讓你能針對特定情境優化，「小但夠用」這個組合越來越可行。
Web 端 AI 不是要取代雲端推論，而是讓「哪些任務真的需要打遠端 API」這個問題，變得值得認真想一想。那些真正靠近使用者、需要即時回應的體驗，或許本來就不應該繞一圈去雲端。