BrowserAI：把 MLC、Transformers、Flare 與 Demucs 四種引擎收進同一個瀏覽器 SDK
Run local LLMs like llama, deepseek-distill, kokoro and more inside your browser
秒懂
- 它是什麼？
- BrowserAI 是一套 TypeScript SDK，讓你在瀏覽器裡載入並執行 LLM、Whisper、Kokoro TTS 與 Demucs 音源分離，全部走 WebGPU 或 WASM。它的價值在於把多個推論引擎統一成一個 generateText 介面，代價是模型清單與引擎行為綁得很緊。
- 適合誰用？
- BrowserAI 適合已經確定要跑在瀏覽器端、且能接受預先配置模型清單的開發者，例如做隱私敏感應用的前端團隊，或需要離線推論的 no-code 平台。不適合需要任意 GGUF 或自訂權重、需要伺服器端批次推論、或必須支援沒有 WebGPU 的舊裝置的專案。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 57 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是「不想為模型開一台伺服器」這件事
把模型跑在使用者的瀏覽器裡，換來的是三件事：推論資料不離開裝置、沒有伺服器推論成本、初次下載完成後可離線使用。README 把這三點寫成 100% Private、Zero Server Costs 與 Offline Capable，並把目標讀者列為網頁開發者、需要隱私考量的公司、做瀏覽器 AI 實驗的研究者，以及 no-code 平台建構者。
真正決定要不要用的不是這些標語，而是模型清單。BrowserAI 走的是預先配置路線，README 明白寫著「More models will be added soon. Request a model by creating an issue.」。這句話同時是承諾也是邊界：你能跑什麼，取決於上游有沒有替你準備好轉換後的權重與對應的引擎設定。想臨時塞一個社群上的 GGUF 進來，就得自己處理轉換與設定，SDK 不會幫你。
四種引擎共用一個 generateText，代價藏在載入參數裡
BrowserAI 的架構核心是引擎抽象。README 列出 MLC、Transformers、Flare 與 Demucs 四種引擎，並宣稱可以在它們之間切換。切換的實際做法體現在模型名稱上：MLC 家族的模型直接用名稱載入，例如 llama-3.2-1b-instruct 或 gemma-2b-it；Flare 走 GGUF 加 WASM 路徑，名稱帶上後綴，例如 llama-3.2-1b-flare；Demucs 則是獨立匯入路徑 @browserai/browserai/demucs，用 DemucsEngine 類別操作。
也就是說，引擎選擇不是一個顯式的 config 參數，而是由模型識別字推導出來的。這種設計讓最常見的用法很短，但當你想知道某個模型到底跑在哪個 runtime 上時，答案藏在名稱後綴與內部對照表裡，不在呼叫端。MLC 路徑接受 quantization 這類載入選項，README 的範例用 q4f16_1；Flare 路徑則另外提供 loadAdapter 載入 safetensors 格式的 LoRA 適配器。兩條路徑的能力不對等，這點在選模型時就要一併決定。
載入是非同步的，並且可以傳入 onProgress 回呼，README 的範例把 progress.progress 直接接到載入百分比。對於動輒數百 MB 的權重，這個回呼不是裝飾，而是介面設計的必要部分。
從 npm 安裝到第一次推論的實際指令
安裝有兩條等價路徑，README 分別列出 npm install @browserai/browserai 與 yarn add @browserai/browserai。套件名稱帶 scope，匯入時從 @browserai/browserai 取 BrowserAI 類別。
最小可用流程是三個呼叫：建立實例、loadModel、generateText。loadModel 的第一個參數是模型名稱字串，第二個是選項物件，範例中使用 quantization 與 onProgress。generateText 回傳的物件結構沿用 OpenAI 風格，內容在 response.choices[0].message.content，這一點對已經寫過 chat completion 的開發者幾乎不用重新學。
生成參數放在第二個參數物件裡，README 示範了 temperature、max_tokens 與 system_prompt。多輪對話則改成傳入訊息陣列，每則帶 role 與 content，system 角色也在同一個陣列中。結構化輸出用 json_schema 搭配 response_format: { type: "json_object" }，schema 本身是標準 JSON Schema，範例要求模型輸出一個顏色陣列，每項含 name 與 hex。
語音部分走同一套介面。Whisper 模型載入後，用 startRecording 與 stopRecording 取得 audioBlob，再交給 transcribeAudio，選項包含 return_timestamps 與 language。TTS 用 kokoro-tts 模型，呼叫 textToSpeech 時指定 voice（範例是 af_bella）與 speed，回傳值是 audioBuffer，需自行用 Web Audio API 的 decodeAudioData 解碼後播放。SDK 不負責播放。
Demucs 是另一條產品線，不是附帶功能
音源分離在 BrowserAI 裡的地位和其他功能不同。它不從主套件匯出，而是走 @browserai/browserai/demucs 這個子路徑，並使用 DemucsEngine 這個獨立類別。載入方式也不一樣，loadModel 收的是一個 htdemucs 設定物件，README 的範例直接留了註解佔位，沒有給出完整欄位。
separate 方法收 AudioBuffer，選項有 shifts 與 overlap。README 對 shifts 的說明是時間位移增強次數，數值越高品質越好但越慢；overlap 是分段重疊比例。回傳物件的 sources 以字串索引存取，README 列出 drums、bass、other、vocals 四個 stem，每個都是 AudioBuffer。
值得注意的限制是模型清單裡 Demucs 只有 HTDemucs 一個選項，而且是 4-stem 版本。如果你的需求是 6-stem 或特定樂器分離，這條路目前走不通。另外 shifts 與 overlap 這兩個參數直接對應品質與延遲的取捨，在瀏覽器裡跑意味著這個取捨會落在使用者的 CPU 或 GPU 上，而不是你能控制的伺服器規格上。
WebGPU 是預設路徑，不是唯一路徑，但兩條路的模型不重疊
README 把 WebGPU 加速列為主要賣點，並以 Near-native performance 描述。同一份文件裡 Flare 引擎被標為 GGUF Models via WASM，這代表存在一條不依賴 WebGPU 的執行路徑。
問題在於兩條路徑支援的模型是分開列的。MLC 清單裡有 Llama-3.2 的 1B 與 3B、SmolLM2 三個尺寸、Qwen3 從 0.6B 到 8B、DeepSeek-R1 蒸餾版 7B 與 8B，還有四款 Snowflake-Arctic-Embed 嵌入模型。Flare 清單只有四款：SmolLM2-135M、SmolLM2-360M、Qwen2.5-0.5B 與 Llama-3.2-1B，量化格式限於 Q8_0 與 Q4_K_M。
這意味著「不支援 WebGPU 就退回 WASM」不是等價替換，而是換一組小得多的模型。如果你的產品要覆蓋較舊的裝置，實際上等於同時要維護兩套模型選擇邏輯與兩套品質預期。文件沒有說明兩條路徑在相同模型上的輸出是否一致，這一點在正式採用前值得自己驗證。
另一個文件沒有交代的地方是 Web Worker 支援的具體用法。功能清單寫了 Web Worker support for non-blocking UI performance，但 README 的範例全部在主執行緒上建立 BrowserAI 實例，沒有給出 worker 內的初始化範例。
結構化輸出與內建資料庫：兩個容易被忽略的設計選擇
json_schema 搭配 response_format 是這份文件裡少見的、有明確行為描述的進階功能。它讓模型輸出可以直接餵給後續程式邏輯，不需要自己寫解析與重試。要注意的是這依賴模型本身的指令遵循能力，README 的範例用的是通用寫法，沒有標明哪些模型實測有效。1B 等級的模型在複雜 schema 上的表現通常不穩定，這是模型層面的限制，不是 SDK 的問題，但採用時必須納入考量。
Built-in database support for storing conversations and embeddings 出現在功能清單裡，但 README 沒有給出任何 API 名稱、設定鍵或使用範例。嵌入模型清單倒是給了四款 Snowflake-Arctic-Embed，暗示 RAG 是規劃中的方向，roadmap 的 Phase 1 也寫了 Simple RAG implementation，Phase 2 是 Enhanced RAG capabilities。以目前能查到的資料，這個資料庫層還無法評估，不建議把它當成採用理由。
什麼情況下它會是錯的工具
第一種情況是需要任意模型。BrowserAI 的模型清單是封閉的，由專案維護者預先轉換與配置。想跑自己微調的權重、或社群剛發布的模型，你得等上游支援，或自己動手做轉換。這和 llama.cpp 這類工具的路線正好相反：llama.cpp 讓你自己拿 GGUF 檔案、自己決定量化、自己控制 context 長度與 GPU 層數，代價是你得處理建置與平台差異。BrowserAI 把這些決定收走，換來的是幾行程式碼就能跑；如果你需要的正是那些被收走的控制權，它就不適合。
第二種情況是推論量集中在少數幾台機器上。瀏覽器端推論的經濟性是建立在把算力成本轉移到使用者裝置上，這在面向大量終端使用者的應用裡成立，在內部批次處理腳本裡完全不成立。
第三種情況是首次載入體驗不能等。離線能力的前提是下載完成，而模型權重不是小檔案。README 提供 onProgress 正是因為這件事需要被呈現給使用者，但呈現進度條不等於解決等待。
第四種是音訊分離的品質要求。Demucs 只有一個模型、一組參數，且 shifts 拉高會直接拖慢瀏覽器。專業用途的 stem 分離通常不在瀏覽器裡做。
授權、版本節奏與升級成本
專案採 MIT 授權，套件可商用、可修改、可再散布，需保留著作權聲明。這是 SDK 層的授權，不涵蓋模型權重。MLC 清單裡的 Llama、Gemma、Qwen、DeepSeek 各自有不同條款，Gemma 系列尤其有自己的使用限制。把 BrowserAI 包進產品前，要逐一確認你實際載入的那幾個模型授權，這件事 SDK 的 MIT 不會替你處理。
版本節奏可以從發布紀錄看出輪廓：v2.0.2 在 2025 年 4 月，v2.0.4 在同年 5 月，下一個主要版本 v2.2.0 到 2026 年 4 月才出現，中間約 11 個月。這不是高頻發布的專案，代表 API 相對穩定，也代表遇到問題時不能期待隔週就有修補。
升級成本主要落在模型名稱與引擎對照上。由於引擎是由模型識別字推導，任何模型清單的調整都可能改變你原本依賴的路徑。鎖定版本、並在升級時重新確認目標模型仍在清單中且仍由同一個引擎承接，是這個架構下必要的檢查動作。文件沒有提供引擎對照的公開查詢方式，只能靠實際載入驗證。
編輯結論
BrowserAI 適合已經確定要跑在瀏覽器端、且能接受預先配置模型清單的開發者，例如做隱私敏感應用的前端團隊，或需要離線推論的 no-code 平台。不適合需要任意 GGUF 或自訂權重、需要伺服器端批次推論、或必須支援沒有 WebGPU 的舊裝置的專案。導入前先確認三件事：目標模型是否出現在 README 的 MLC、Transformers 或 Flare 清單中；你的目標瀏覽器是否提供 WebGPU，否則會退回 Flare 的 WASM 路徑而換到另一組模型；以及首次載入的下載量是否符合你的使用者體驗預算，因為離線能力是建立在初次下載完成之後。
社群筆記