更关键的是，实现这个速度的路径不是"把量化做狠一点"或"投机解码多猜几个 token"这么简单。它触及了一个更根本的问题：当推理系统逼近硬件物理极限时，模型架构和推理引擎必须从设计阶段就开始同步进化，而不是各自优化完再拼到一起。

这篇拆解 MiMo × TileRT 做了什么，以及"Speed Scaling"作为新范式到底意味着什么。

万亿参数推理为什么特别难

先说背景。MoE（Mixture of Experts）架构让万亿参数模型在训练端变得可行——每次前向传播只激活一小部分参数，推理时的计算量远低于密集模型。但推理端有一个不太一样的瓶颈：显存带宽。

一个 1T 参数的 MoE 模型，即使只激活几百亿参数，完整的权重还是得住在 GPU 显存里。用 FP16 加载需要 2TB 显存，8 张 80GB H100 只有 640GB，根本装不下。即使用 FP8（1TB），仍然超出单节点容量。

这意味着推理速度的瓶颈不在计算，而在数据搬运——每生成一个 token，GPU 都要从显存读取相关权重，读取速度直接决定生成速度。业界称之为"Memory-Bound"场景，token/s 的上限 = 显存带宽 / 每 token 需要读取的字节数。

所以，要让 1T 模型跑快，核心就两件事：减少每次搬运的数据量，和减少搬运次数。

第一层：FP4 选择性量化——不是所有参数都值得用低精度

减少数据量最直接的方法是量化。MiMo-V2.5-Pro 采用的是 OCP Microscaling (MXFP4) 格式——一种 Microsoft 主导的 FP4 标准，在极低比特下保持数值稳定性。

但关键不是"全模型 FP4"。如果暴力把所有层都压到 4 bit，模型在复杂推理、代码生成等任务上会出现明显退化。MiMo 的做法是选择性量化：

• MoE Expert 层：占总参数量的绝大部分，且对量化容忍度最高 → 用 FP4
• Router 和 Attention 层：参数量小但对精度敏感 → 保持 FP8

用人话说就是：大部分"搬运工"（Expert）换成了轻装，但"调度员"（Router）和"注意力核心"保留重装。这不是一个拍脑袋的决定，而是 MiMo 团队和 TileRT 在 profiling 阶段反复测量每层的精度敏感度后得出的工程策略。

这种做法和我们之前拆解过的 KVarN 用 KV Cache 量化减少推理显存 有异曲同工之处——都是瞄准推理 pipeline 中的带宽瓶颈做定点优化。区别在于，KVarN 压缩的是 KV Cache 的存储，MiMo 压缩的是模型权重本身的搬运。

第二层：DFlash——不只是"猜得快"，而是"猜的形态"变了

量化解决的是"每次搬运多少"的问题，投机解码解决的是"搬运几次"的问题。

传统投机解码（Speculative Decoding）的思路很直觉：用一个小模型快速"猜"若干后续 token，然后大模型一次性验证。如果猜对了，就省了好几轮自回归生成。问题在于，草稿本身仍然是自回归的——小模型每猜一个 token 也要一轮前向传播，瓶颈依然存在。

DFlash（来自 z-lab 的 DFlash 项目，GitHub 近 5000 星）的做法完全不同：它用块级掩码并行预测取代了自回归草稿。具体来说：

1. 选取一个 token 块（比如 8 个位置），把其中一部分位置 mask 掉
2. 草稿模型一次性预测所有被 mask 的位置，不需要逐个生成
3. 大模型验证整个块的正确性

这种"块扩散"方式从根本上绕过了草稿阶段的串行约束。我们在 之前拆解 DFlash + DDTree 的文章 中详细介绍过这个机制——当时是在消费级 RTX 3090 上跑 Qwen3.5-27B，做到了 207 tok/s。

MiMo × TileRT 把同一个思路搬到了万亿参数场景，并做了针对 MoE 架构的定制优化：

• 使用 Muon 二阶优化器和模型自蒸馏来训练草稿头，确保在 FP4 权重下仍有高接受率
• 块大小限制在 8 个 token，控制单次验证的计算开销
• 在代码生成场景实测平均接受长度 6.30，最高 7.14——意味着每轮验证大概能"一口气"确认 6-7 个 token

这个数字很重要。接受率太低（比如只有 3-4），投机解码的收益就被验证开销吃掉了。6+ 的接受长度意味着大模型每做一次前向传播，实际产出 6-7 个有效 token，等效地把推理速度翻了 5-6 倍。

第三层：TileRT 的 Tile-Based 持久执行引擎

如果说量化和投机解码是"减少工作量"，TileRT 做的是"减少工作的间隙"。

传统的推理框架（vLLM、TensorRT-LLM 等）把模型拆成大量独立算子，每个算子有独立的 kernel launch。在常规速度下（几十 tok/s），每次 launch 的开销（host 端调度、硬件同步、全局内存往返）可以被密集计算掩盖。但在 1000 tok/s 的频率下，每个算子的生命周期被压缩到微秒级，这些开销突然变成了主要瓶颈。

TileRT 的解决方案是一个全新执行模型——Persistent Engine：

• 不再逐算子 launch，而是把整个计算管线打包成一个持续运行在 GPU 上的持久化引擎
• 当一个 Tile（数据块）在 Compute Core 上处理时，下一个 Tile 的数据已经通过多级内存层次（Global → Shared → Register）开始预取
• 引入 Warp Specialization：不同的 Warp 组被分配到不同角色（计算、数据搬运、通信），打破传统"所有 Warp 做同一件事"的刚性执行模式
• Heterogeneous Workers 将这种专业化策略扩展到多个 SM，实现跨 GPU 执行域的协调

用人话翻译：传统推理引擎像一个流水线上每个工位都独立接单、独立交付的工厂；TileRT 把它变成了一个连续流动的传送带，每个环节的衔接间隙被压到了接近零。

这解释了为什么 TileRT 能从"几百 tok/s"跨越到"1000+ tok/s"——后者不是前者的线性延伸，而是需要一个质变的执行范式。

TileRT 本身是开源项目（1277 星），已经在 GLM-5.1-highspeed 等生产环境中上线，不是纸上谈兵。

三层叠加的工程细节

单独看每一层，都不算革命性创新——量化、投机解码、执行优化，业界都在做。MiMo × TileRT 的真正价值在于三层之间的协同设计：

这种"模型-系统联合设计"（Model-System Codesign）是文章中最值得记住的概念。传统流程是：模型团队训好模型 → 系统团队想办法部署 → 各自优化 → 拼到一起。MiMo × TileRT 的做法是：在模型设计阶段就引入推理系统团队的约束，让模型架构天然适合超低延迟执行。

1000 tok/s 到底能做什么

速度数字本身不是目的。MiMo 的博客列了三个场景，我认为其中两个真正有工程价值：

1. Best-of-N / Tree Search 推理

在相同的时间预算内，1000 tok/s 让模型可以并行跑几十条推理路径，自动选出最优解。这比"等一个答案，祈祷它正确"要可靠得多。对于代码生成、数学证明等需要探索的任务，这意味着质量的实质性提升，而不只是更快的打字机。

2. Coding Agent 的实时交互

开发者用 AI 写代码时，最大的体验杀手是"等"。1000 tok/s 意味着大段代码生成可以在几秒内完成，Agent 可以在同一个交互回合中完成"写代码 → 测试 → 修复"的完整循环，而不是让开发者盯着 loading 动画发呆。

第三个场景是"毫秒级实时决策"（量化交易、反欺诈），坦白说我持保留态度——这些场景对模型输出质量的要求和对延迟的要求往往互相矛盾，1000 tok/s 解决了延迟但没解决可靠性问题。

对工程选型的实际意义

如果你在做 AI 基础设施选型，这个发布有几个值得注意的点：

TileRT 是一个实际可用的开源推理引擎，不是实验室 demo。它已经部署在 GLM-5.1 的生产环境中。如果你的场景对延迟极度敏感（实时 Agent、交互式编码），值得评估。相比 本地推理引擎 Ollama/llama.cpp 的定位是消费级硬件上的便捷部署，TileRT 的定位是数据中心级的极致延迟。

DFlash 的块级预测方式正在成为推理加速的主流路径。4999 星不是没有原因的——它比传统投机解码更适合大模型、长序列场景。如果你用 vLLM 或 TensorRT-LLM，关注这两个框架对 DFlash 的集成进度。

FP4 量化正在从"勉强可用"变成"生产级"。MXFP4 标准（Microsoft 主导的 Microscaling 格式）在极低比特下的数值稳定性已经被多个团队验证。但注意，MiMo 的成功依赖于 MoE 架构的特殊性——Expert 层天然对量化友好。如果你的模型是密集架构，全模型 FP4 的效果可能不如预期。

一句话总结

1000 tok/s 不是一个"量化做得更狠"的结果，而是模型架构和推理系统从设计阶段就深度耦合的产物。当推理速度开始像训练算力一样成为决定模型能力边界的变量时，“Speed Scaling"这个概念值得每个做 AI 基础设施的人认真对待。

信源：

• MiMo × TileRT 官方博客
• TileRT 技术博客：Breaking 1000 TPS
• TileRT GitHub（1277 星）
• DFlash GitHub（4999 星）
• MiMo-V2.5-Pro-UltraSpeed 模型文档
• MXFP4 Microscaling Formats 规格