vLLM、SGLang、vMLX：本地 LLM 新選擇
本地 LLM 工具鏈開始分流。vLLM、SGLang、vMLX、MLC-LLM 與 ExLlamaV3，正把重點從「能跑」推向「怎麼跑得更快、更穩、更貼近硬體」。
vLLM、SGLang、vMLX、MLC-LLM 和 ExLlamaV3，正在把本地 LLM 工作流從單機聊天，推向可部署、可批次處理的服務形態。
多數人接觸本地模型，第一站仍是 Ollama 或 llama.cpp。這兩個工具依然好用，但一旦模型要接 API、跑多個客戶端、或支援 agent，runtime 就不再只是背景角色。
這篇整理的重點很直接：本地 AI 工具鏈已經分工。不同 runtime 各自對準伺服、結構化輸出、Apple Silicon、瀏覽器端、手機端，或消費級 GPU，沒有單一解法能吃下所有場景。
| 項目 | 數值 |
|---|---|
| 主要 runtime | 5 個 |
| Apple Silicon 路線 | MLX、MLX-LM、vMLX |
| 瀏覽器／行動裝置路線 | MLC-LLM、WebLLM |
| 消費級 GPU 路線 | ExLlamaV3 |
| 伺服取向路線 | vLLM、SGLang |
發生了什麼
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
文章把本地 LLM 生態切成幾條明確路線。vLLM 主打高吞吐伺服、OpenAI 相容 API、continuous batching 和 PagedAttention，適合多個應用同時打同一個端點。
SGLang 則更偏向結構化生成。它把 RadixAttention、prefill-decode disaggregation、speculative decoding、tensor 與 expert parallelism、multi-LoRA batching 放在一起，目標是重複提示詞、schema 驅動輸出與工具調用。
如果工作負載更靠近 Apple 生態，MLX、MLX-LM 和 vMLX 會更合適。它們的重點不是把模型塞進通用伺服器，而是貼著 Apple Silicon 的記憶體與算力特性來跑。
另一端是跨裝置部署。MLC-LLM 與 WebLLM 面向瀏覽器、手機、平板與嵌入式設備；ExLlamaV3 則鎖定消費級 GPU，並可搭配 TabbyAPI 做成 OpenAI 風格服務。
- vLLM：伺服與批次吞吐優先。
- SGLang：結構化輸出與重複工作流優先。
- MLX／vMLX：Apple Silicon 原生路線。
- MLC-LLM／WebLLM／ExLlamaV3：端側與消費級硬體優先。
這代表選型邏輯已經變了。以前問的是「哪個模型能跑」，現在更常問「哪個 runtime 能把這個模型穩定地接到產品裡」。
為什麼重要
對開發者來說，runtime 會直接影響延遲、VRAM 佔用、吞吐量與輸出穩定性。當本地模型只是聊天玩具時，Ollama 或 llama.cpp 很夠用；但一旦要服務多個用戶、處理 RAG、或回傳可驗證的 JSON，runtime 的差異就會被放大。
這也解釋了為何本地 AI 正在分裂成多條硬體路線。Nvidia 用戶可以追求高吞吐伺服，Mac 用戶有原生路徑，AMD 與消費級 GPU 則需要更貼近記憶體限制的工具；同一個模型，在不同 runtime 上，體驗可能差很多。
對產業來說，這不是單純的工具更新，而是部署思維的變化。模型本身越來越像可替換零件，真正拉開差距的，反而是 batching、cache、parallelism，以及 runtime 對硬體的理解。
結論很硬：本地 LLM 已經不是「裝哪個模型」的問題，而是「你要把它放在哪種 runtime 上」的問題。