Muse Glimmer在单块RTX 5090上达到230 Tokens/s：SGLang的Day-0支持才是真正的发布故事

每秒230个token，对任何模型来说都是一个很快的数字。对于Muse Glimmer——Meta Superintelligence Labs发布的Meta 30B密集开放权重模型，于2026年8月10日以Apache 2.0许可推出——这个数字正是区分"能在我的GPU上运行"的模型与"能服务真实智能体"的模型的分水岭。SGLang在权重上线的当天就宣布了对Muse Glimmer的day-0支持，其公布的单块GeForce RTX 5090测试结果为：在NVFP4量化和Meta的DFlash投机解码草稿模型均开启的情况下，batch 1下每用户每秒可处理236.4个token。

那个数字已经说明了这次发布的大部分内容，但剩下的部分仍然值得细细品味，因为有趣的并不是头条速度。真正有趣的是，这个模型还能在 RTX PRO 6000、NVIDIA DGX Spark 上开箱即用，并通过 MLX 支持 Apple silicon——而且 SGLang 将这项工作称为与 Meta Superintelligence Labs 的合作，而非社区的事后补充。这是很长时间以来，Meta 推出的第一个接近前沿水平、却围绕服务栈而非仅围绕权重设计的模型。

这里的“day-0支持”实际上意味着什么？

SGLang v0.5.17 中的 Day-0 支持意味着该模型并非事后才仓促加入：运行时的工作与权重在同一发布窗口内完成，并为 Meta 实际目标硬件构建了专门的路径。SGLang 的 SM120 后端覆盖了 Blackwell 台式机和工作站产品线——RTX 5090、RTX PRO 6000 和 DGX Spark 均运行同一条优化路径——而 Apple 芯片则获得原生 MLX 后端，而非缓慢的移植版本。

SGLang和Meta调优所针对的堆栈是特定的。该模型作为一个18GB的NVFP4检查点运行，配有一个5GB的BF16 DFlash草稿模型，这是Meta为Muse Glimmer训练的投机解码配套模型。这一组合可以装入32GB显卡且仍有富余空间，整个NVFP4加MXFP8混合量化路径的驻留内存大约为19.5GB。在SGLang方面，发布说明将三项可靠性机制列为同一方案的一部分：DFlash投机解码、用于前缀缓存的RadixAttention，以及可中断的CUDA图。

数字，以及它是什么与不是什么

SGLang 公布的 RTX 5090 数据，全部采用 NVFP4 和 SM120 路径，具体如下：

• 单用户解码（批次1）——标准模式63.9 tokens/s，DFlash投机解码下236.4 tokens/s。这3.7倍的提升正是交互性指标，它决定了本地代理给人的感觉是像一场对话，还是像在排队。

• 聚合输出（批次 8）——标准为 501 tokens/s，使用 DFlash 后为 1,452 tokens/s。这是本地服务器同时服务多个请求时的吞吐量数值。

• 作为对比，在同一块 GPU 上，GGUF q4_k_m — 大多数人在使用 llama.cpp 风格运行时采用的路径 — 标准速度达到 72.6 tokens/s，使用 DFlash 时为 140.7 tokens/s。NVFP4 路径明显领先。

这些是SGLang和Meta在发布当天公布的数据，并非独立的复现结果——更诚实的说法是“供应商与框架方报告”，社区验证将在未来几周内陆续展开。但公布数据的两套技术栈呈现出的规律是一致的。在llama.cpp中，Meta报告在RTX 5090上借助DFlash实现每秒74.9至233.4个token，提升3.1倍；M5 Max从26.6升至50.2；M4 Max从23.7升至37.8。两种不同的运行时、两种不同的测量方式，结果处于同一量级：一个30B模型在单张消费级GPU上以每秒200多个token的速度解码，而且在每一个已公布数据的Nvidia平台上，DFlash都将吞吐量大约提升至三倍。

为什么"serves"比"runs"更重要

Meta的硬件博客提出了比桌面端数字更大胆的说法。在NVIDIA Blackwell Ultra——数据中心代际，而非桌面显卡——上，博客引用了每GPU每秒超过20,000个token的数据，精度为BF16/NVF4，SGLang和vLLM均被列为支持的开源技术栈。这是另一个量级，也揭示了Meta真正在构建的东西：相同的权重旨在从笔记本电脑到GPU服务器机架的任何地方运行，而服务框架从第一天起就被视为一等公民，而非事后才编写的移植。

可靠性的这一半与速度同等重要。一个因为服务层卡顿而在任务中途崩溃的本地代理，并不比一个被限流的云端代理好到哪儿去。day-0 技术栈中的这些机制——可中断的投机解码、让长智能体上下文的重新进入成本保持低廉的前缀缓存、以及针对基础模型调优的草稿模型——恰恰是让常驻本地代理得以存续的关键。这正是这次发布一直指向的“速度与可靠性”，它是一个真正的工程主张，而不是一句营销话术。

你实际上可以用它做什么

Muse Glimmer 是一个 30B 参数的密集多模态模型——通过冻结的感知编码器接受文本和图像输入，输出文本——在 100 多种语言上训练，拥有 131,072 个 token 的上下文窗口，知识截止日期为 2026 年 1 月 4 日。它的职责是那些不起眼的智能体工作：函数调用、工具使用、日程与文件管理、LLM 作为评委的评估，以及带故障恢复的多步任务——当工具调用失败时，模型被训练为诊断并重试，而不是停止。它公开了推理努力级别（从 low 到 xhigh），你可以在系统提示中设置，这就是如何在相同权重下用延迟换取深度的方式。

每秒230个token的速度才是让这一切能在单台机器上顺畅运行的关键。低于大约50 token/s时，交互式智能体用起来就像一场远程调试会话；达到200以上时，它则像本地工具一样自如。这个模型的全部说服力，就凝聚在这一数字之中，也正是这份硬件清单——RTX 5090、RTX PRO 6000、DGX Spark、MLX Macs——读起来更像本地智能体时代的购物指南，而非兼容性脚注的原因所在。

费用是多少

Muse Glimmer 本身是免费的——Apache 2.0 权重托管在 Hugging Face 的 meta-models/Muse-Glimmer-30B 上，GGUF 量化版本也已发布，适用于 llama.cpp 风格的运行时，且没有公开的 Meta API。真正的成本在于其底层的硬件：18GB 的 NVFP4 检查点加上 5GB 的草稿模型，意味着你需要一块 24GB 或 32GB 的显卡，或者一台高端的 M 系列 Mac。如果你已经拥有这些硬件，那么始终在线的本地代理的边际成本只是电费。如果没有，那么 GPU 就是预算中的主要开支——这才是将“免费模型”与托管 API 进行比较时最诚实的角度。

当你真的做这种比较时，要把两边的价格都直接算清楚。在 OrcaRouter，你所看到的 200 多个托管模型中任何一个的价格，都是提供商列出的价格以 0% 加价直接传递的，因此供应商降价当天就会在这里生效——这让本地与托管的成本核算保持透明。Muse Glimmer 本身今天不在 OrcaRouter 上，因为还没有推理提供商在提供它；它以下载形式交付。一旦有提供商开始提供它，用于访问目录其余部分的同一个密钥也将用于访问它，而自动故障转移正是这样一种机制：在全新、由供应商报告的模型还没有独立业绩记录之前，将生产流量指向它是安全的。

速度背后更大的故事

把发布首日的 SGLang 支持当作一个信号来看，这次发布就不再只是单款模型。Muse Glimmer 是 Meta 旗舰闭源模型 Muse Spark 1.2 的蒸馏版本，Meta 表示教师模型的权重“将在未来几周内”公开。一个搭载调优推理服务栈的 30B 本地智能体、一个即将开源的教师模型，外加同期宣布的 10 亿美元社区基金——这绝非一次小版本更新。这是面向本地智能体市场的开放权重产品线的冰山一角，而首日即落地的框架支持恰恰表明：Meta 意在让人们真正运行它，而不只是下载它。

摆在桌面上的告诫是：目前围绕这次发布的所有速度和基准数据，均为供应商或框架方报告的结果。吞吐量数字在两个独立技术栈上表现一致，这令人安心，但独立基准测试、Artificial Analysis 的测评条目，以及真实世界的复现，才能真正证实每秒 230 个token 的说法——而这类验证通常在发布后的几周内就会落地。

按大致的时间顺序，值得关注的是：Muse Spark 1.2 开放权重版本发布（{{1}}关于“Meta 回来了”的战略解读取决于此{{/1}}）；在非英伟达硬件上的首次独立吞吐量复现，其中 MLX 路径值得关注；以及首家提供 Glimmer 端点的推理服务商——{{2}}届时，“免费本地模型”与“托管 API”之争将不再是理论假设，而是你一键即可做出的选择{{/2}}。