2026 年 6 月 8 日，小米 MiMo 与 TileRT 团队公布，MiMo-V2.5-Pro-UltraSpeed 在单个标准 8 GPU 节点上，达到每秒生成超过 1000 个 Token 的解码速度，演示峰值约 1200。它基于万亿参数规模的 MiMo-V2.5-Pro，结合量化、推测解码和推理系统优化。两篇技术博客尚未给出足以复现全部速度结果的硬件与负载配置。
这一结果为高性能 GPU 推理提供了一个新案例。Cerebras 在 5 月公布，Artificial Analysis 测得其 Kimi K2.6 服务输出速度为每秒 981 个 Token，是当时下一家最快 GPU 服务的 6.7 倍。不过，MiMo 与 Kimi 的模型、精度和测试条件不同，不能仅凭两个数字判断 GPU 已经追平或超越专用芯片。
官方称生成速度约为标准版的 10 倍，试用 API 价格为 3 倍
UltraSpeed 是基于 MiMo-V2.5-Pro 的高速推理版本，采用经过量化感知训练的权重，并加入草稿模型与专用运行时。官方公布的主要信息如下：
- 模型规模：约万亿参数，采用混合专家（MoE）架构
- 生成速度：解码超过 1000 Token/秒，演示峰值约 1200；官方称约为标准版的 10 倍
- 硬件：单个标准 8 GPU 节点，博客未列出完整配置
- 定价：试用 API 价格为标准版的 3 倍，不支持 Token Plan
- 开放方式：6 月 9 日至 23 日申请制试用；FP4-DFlash 权重已公开至 Hugging Face，TileRT 部分模块在 GitHub 开源
两项已公开的速度数据来自不同测试，只能分别解读：
| 模型 / 推理服务 | 输出速度（Token/秒） | 数据来源与条件 |
|---|---|---|
| MiMo-V2.5-Pro-UltraSpeed | 超过 1000，演示峰值约 1200 | 小米自测；单个 8 GPU 节点，使用量化和推测解码 |
| Cerebras 的 Kimi K2.6 服务 | 981 | Cerebras 引用 Artificial Analysis 5 月 6 日对私有端点的测量 |
这里关注解码阶段的输出速度，不包含所有请求的排队、首个 Token 等待和工具调用时间。模型、上下文、批大小与并发数均会影响结果；它也不同于整台服务器承接多路请求的总吞吐量。
量化、推测解码和 GPU 调度共同减少等待
小米与 TileRT 把优化分为三部分：用更低精度减少权重访存，用草稿模型提高每轮可确认的 Token 数，再减少 GPU 执行过程中反复调度的开销。各部分需要配合，才能把算法上的提速转成实际生成速度。
将专家权重量化为 FP4，减少存储和访存开销
在万亿参数规模下，读取权重会占用大量内存带宽。小米采用 MXFP4 格式，仅将 MoE 专家模块量化为 FP4，其余模块保持 FP8 精度，以减少模型存储和访存开销。
专家模块占据了模型的大部分参数。小米称，只量化这部分并配合量化感知训练（QAT），在其展示的基准上能保持与 FP8 版本接近的表现。保留其他模块的精度，则是为了减轻全模型低比特量化对复杂推理和代码任务的影响。
草稿模型一次预测多个 Token，再交给主模型验证
推测解码先由较小的草稿模型预测后续 Token，再由主模型验证。正确实现的验证与采样过程，可以保持目标模型的输出分布；目标模型自身经过量化后是否保持能力，则是另一项需要评估的问题。草稿模型越大或生成越慢，额外开销也越高。
DFlash 让草稿模型在一次前向计算中填充一整块掩码位置，并行预测多个 Token。小米用 Muon 优化器和模型自蒸馏训练草稿模型，并采用固定滑动窗口注意力（SWA），使草稿阶段不必每次读取完整前缀。块大小设为 8，以平衡接受长度与验证开销。主模型的长上下文处理仍有相应成本。
效果数据：
| 场景 | 平均接受长度（/8） |
|---|---|
| 编程 | 6.30 |
| 数学 / 推理 | 5.56 |
| Agent 任务 | 4.29 |
小米报告，在编程场景中，每轮验证平均接受 6.30 个 Token，个别样本达到 7.14。开放域对话的不确定性更高，草稿被接受的比例相对较低，团队表示还在继续改进。
让计算持续运行，减少算子之间的调度开销
当生成速度提高后，算子启动、同步和访存之间的短暂等待会更明显。TileRT 团队认为，这些原本容易被大块计算掩盖的开销，是其低延迟推理优化的重点。
TileRT 主要采用两种执行安排：
- 持久化执行内核（Persistent Engine Kernel）：让计算流程持续驻留在 GPU 上，减少逐个算子启动的需要，并提前搬运后续数据，使计算和数据传输重叠。
- 线程组分工（Warp Specialization）：把数据搬运、张量计算和通信交给不同线程组，再协调它们的执行，减少相互等待。
TileRT 特别提到 RMSNorm、RoPE 和 KV Cache 写入等辅助操作。它们的计算量不一定大，但若反复打断执行，也会累积延迟。优化因此需要检查整条执行流程。
软件优化能提高 GPU 利用率，硬件比较仍需统一条件
MiMo UltraSpeed 展示了模型和推理系统协同优化的收益：量化、草稿预测与 GPU 调度共同影响最终速度。它并不意味着推理已经不再受硬件约束。
Cerebras 采用晶圆级芯片，Groq 采用专用推理芯片，小米与 TileRT 则在 GPU 节点上调整模型和运行方式。不同路线都在减少计算、通信和内存访问中的等待，不能把它们概括为硬件与软件的单一竞争。
对采用 GPU 的部署团队，这个案例的参考价值在于：除了升级设备，还可以结合模型特点检查量化、推测解码和执行调度。但某一配置的高速演示能否用于自己的业务，要看延迟、并发、质量和成本能否同时满足要求。
TileRT 将其观点概括为“Speed is the New Scaling Law”。这是团队对速度重要性的判断。对于 Agent、多次采样和实时交互，更快生成可以在相同时间内支持更多尝试；任务质量是否因此提高，还取决于验证方法、工具调用和整体时间预算。
量化权重与草稿模型已公开，完整测速还需要运行环境
截至发布时，MiMo 的速度声明来自小米自测，本文所引资料尚无独立复现结果。小米已公开量化权重与 DFlash 草稿模型（Hugging Face：XiaomiMiMo/MiMo-V2.5-Pro-FP4-DFlash），TileRT 也在 GitHub（tile-ai/TileRT）开放了部分模块。
这些资料可以帮助社区检查量化和草稿模型，并开展自己的部署测试。不过，公开权重和部分组件并不等于已公开完整的高速服务栈。复现每秒超过 1000 个 Token，还需要匹配硬件、运行时、采样设置和测试负载。
还需验证复现结果、持续供给和输出质量
第一，独立复现。后续测试需要报告硬件型号、输入输出长度、并发量和运行配置，才能判断速度在不同条件下如何变化。
第二，持续供给。此次试用窗口截至 6 月 23 日。后续是否长期开放、如何收费和分配容量，会影响开发者能否将 UltraSpeed 接入稳定业务。
第三，输出质量。小米的自测显示量化后能力接近原版，代码正确率、复杂推理和长上下文表现仍值得在真实任务中比较。速度提高是否值得更高的 API 价格，也要结合每项任务的总成本判断。
小米与 TileRT 给出了一个明确的工程结果和部分公开材料。接下来更有用的信息，是同样的优化能在多少种负载下保持收益，以及完整部署需要哪些条件。
