SGLang 在發布當天送上 Day-0 支援
開源推論框架 SGLang 在 8 月 10 日宣布，與 Meta 超級智慧實驗室（Meta Superintelligence Labs，MSL）合作，為當天發布的多模態模型 Muse Glimmer 提供 Day-0 支援。SGLang 團隊在官方部落格寫道，他們「與 Meta 超級智慧實驗室合作，為 Muse Glimmer 帶來 Day-0 支援」，並為本地硬體上的代理工作流程做了專屬的最佳化。
「Day-0 支援」在 SGLang 的語境裡，指的是模型發布當天就具備完整、可立即上線的推論服務能力——不是「日後會支援」，而是同步可用。這是 SGLang 既定的節奏：據其 GitHub 儲存庫，框架長期為最新開源模型提供 Day-0 支援，從早期的 DeepSeek V3／R1、OpenAI gpt-oss，到 Kimi K3、Mistral Large 3 都是如此。對一個剛釋出的多模態模型，這意味開發者在權重公開的第一天，就能用 SGLang 把它跑起來、接進代理流程，而不必等待框架跟進。
Muse Glimmer 是什麼：30B 多模態、蒸餾自 Muse Spark
Muse Glimmer 是 Meta 超級智慧實驗室此次的主角。據 SGLang 部落格公布的架構，它由 27.9B 的文字解碼器、約 1.9B 的視覺編碼器與一個 GELU 多模態投影器組成；Hugging Face 的模型卡則把總參數標示為約 29.6B、視覺編碼器為 ViT-G/14，並具備 128k+（131,072+）的上下文視窗。模型卡把它描述為從 Muse Spark 蒸餾而來、專為消費級硬體上的自主代理任務打造。
把 Muse Glimmer 放回 Meta 的模型族譜，定位會更清楚。它脫胎自 Meta 較大型的 Muse Spark——那條也驅動終端編碼代理 Muse Code 的多模態模型線；Muse Glimmer 則把同樣的多模態能力壓縮、蒸餾到能在本機跑的尺寸。Meta 在發布公告裡把它定位為「為常駐本地代理工作流程最佳化」的開放權重模型，全文以 Apache 2.0 釋出，並強調它小到能跑在 Mac 或具備高效 GPU 的 PC 這類消費級硬體上。換句話說，這是一款刻意做小、做給本機的多模態模型——Meta 把「離線也能跑的常駐代理」當成它的設計目標。
把 30B 模型搬上 Mac 與 RTX 5090 的工程
Day-0 支援之所以值得單獨一提，不在於「支援」兩個字，而在於 SGLang 配套搬出的工程。據 SGLang 在該篇部落格公布的細節，針對 Muse Glimmer 的最佳化涵蓋三條主線：DFlash 推測解碼、RadixAttention 前綴快取，以及 breakable CUDA graphs。三者合力要解決的，是代理工作流程裡最耗資源的環節——長脈絡下的重複前綴處理，以及單人互動時的解碼延遲。
數字層面，SGLang 自行測得的結果如下：在 NVIDIA GeForce RTX 5090 上、以 NVFP4 量化搭配 DFlash，繳出每秒 1,452 token 的總吞吐、以及單人每秒 236 token 的解碼速度。DFlash 推測解碼把批次 1（單一使用者）的互動吞吐提升了 1.9 至 4.3 倍，視平台與精度而定。支援的硬體與格式也刻意拉廣：檢查點涵蓋 BF16、NVFP4、GGUF 與 MLX 4-bit，後端跨 SM120 與 MLX，因此從 Apple Silicon（Mac mini、M 系列 MacBook Pro、Apple M5 Pro）、RTX 5090、RTX PRO 6000 到 DGX Spark 都在覆蓋範圍內。SGLang 並指出，他們已把包含前綴快取在內的若干最佳化移植到 MLX 後端，讓 Apple Silicon 在代理工作負載上也能維持競爭力。
本地代理推論的現實：便利與未盡之處
把一個 30B 多模態模型塞進消費級硬體、再靠 Day-0 支援把它當天變可用，是這則消息最直接的價值：開發者不必等雲端、不必等框架更新，就能在本機起一個常駐的多模態代理。對重視隱私、低延遲或離線運作的應用——例如本機編碼、文件問答，或仰賴工具呼叫的代理流程——這是一條比純雲端 API 更自主的路徑。
不過有幾個現實門檻值得看清楚。其一，上述所有吞吐數字皆為 SGLang 自行公布、未經 AIDM 獨立實測；「在代理工作流程上具競爭力」的說法也是 SGLang 的自我評價，而非第三方基準。其二，所謂「消費級硬體」仍偏高階——RTX 5090、Apple M5 Pro、DGX Spark 都不是任意筆電能負擔的規格，128k+ 上下文視窗在滿載下對記憶體的壓力也不容忽視。其三，Muse Glimmer 才剛在 8 月 10 日釋出，它在真實長程代理任務裡的穩定度、工具呼叫的可靠度，都還有待社群與時間驗證。換言之，Day-0 支援解的是「能不能跑」的問題，至於「跑得好不好、值不值得換下既有的雲端方案」，仍是開發者得自己在本機量了才知道的事。
