小米把 1T 模型推到 1000 tokens/s，靠的不是专用硬件
MiMo-V2.5-Pro-UltraSpeed 在一台 8 卡商用 GPU 上让万亿参数模型解码破 1000 tps。真正的信号是 model-system codesign 打破了「极致速度=专用硬件」的等式，而不是那套手术室生死营销。
概述
小米这次值得记住的，不是「1000 tokens/s」这个数字本身，而是它是在一台 8 卡商用 GPU 节点上、用一个万亿参数 MoE 模型跑出来的。过去想把推理速度推到这个量级，业内的默认答案是换硬件——Cerebras 的晶圆级集成、Groq 把权重全塞进片上 SRAM 的专用架构。MiMo-V2.5-Pro-UltraSpeed 走的是另一条路：不碰专用芯片，只靠 model-system codesign（模型与系统协同设计）把同样的速度榨出来。
这件事打破的，是「极致推理速度=专用硬件」这条被反复默认的等式。如果一个 1T 模型能在你买得到的 GPU 上解码破千 tps，那么决定速度上限的就不再只是你有没有钱买 Groq、排不排得上 Cerebras，而是你的量化方案、投机解码算法、kernel 调度有没有做到位。对自建推理栈、做 coding agent 和实时 agent 的团队，这是个真信号：FP4-only-experts 和 DFlash 是可以直接借鉴的范式。
但官方那套叙事要拆开看。博客把「速度即智能」、手术室里「与死神赛跑」、限时申请制包装成普惠，这些是营销，不是信号。真正的判断在于：哪些工程是可复现、可迁移的，哪些是 demo 级别的资源调度和情绪话术。下面会把这两层逐一分开来看。
发生了什么
6 月 8 日，小米 MiMo 模型团队联合 TileRT 系统团队发布 MiMo-V2.5-Pro-UltraSpeed，宣称在 1T 参数模型上首次把 decode 速度推过 1000 tokens/s，演示视频里峰值约 1200 tps，硬件是一台标准的 8 卡商用 GPU 节点。官方明确把自己和 Cerebras、Groq 这类专用硬件路线对立起来，强调「只在商用 GPU 上、纯靠 model-system codesign」拿到这个速度。
实现拆成三件工程，缺一不可。第一是 FP4（MXFP4）量化，但只量化 MoE Experts：MiMo-V2.5-Pro 是 MoE 架构，Experts 占了绝大多数参数，也是对量化最宽容的部分，其余模块全部保留原精度；再配合 FP4 QAT（量化感知训练），官方称整体能力基本持平 FP8。第二是 DFlash——一种块级掩码并行投机解码：传统投机解码靠一个小 draft 模型逐 token 猜测，DFlash 让 draft 一次前向就填满整块掩码位置，绕开了「自回归式起草」的串行约束；块大小限定为 8，配合滑动窗口注意力（SWA）、Muon 二阶优化器和自蒸馏来训练，官方给出的平均接受长度是 Coding 6.30、Math/推理 5.56、Agent 4.29（Coding 最高可达 7.14，即每轮 8 个 draft token 接受 6–7 个）。第三是 TileRT 推理系统：在千 tps 频率下，每个算子的生命周期被压到微秒级，传统系统的「算子边界」——每次 kernel 启动、硬件同步、全局显存往返——都会在微秒尺度撕裂执行流，留下肉眼可见的 Execution Gap；TileRT 用持久化引擎 kernel（整条流水线常驻 GPU 内连续预取）加 Warp Specialization（把通信、搬运、张量计算在 Tile 级别拆开、异构协同）把这些缝隙抹平。
配套的还有商业和开源动作。API 走限时申请制，仅 6 月 9 日到 6 月 23 日开放，定价是 MiMo-V2.5-Pro 的 3 倍、换约 10 倍速度，且不纳入 Token Plan；免费 Chat 同样限两周，每账号每天最多排队 10 次、单会话上限 30 分钟、空闲 5 分钟自动释放。同时小米在 HuggingFace 开源了 MiMo-V2.5-Pro-FP4-DFlash checkpoint，含 FP4 量化权重和 DFlash 参数。DFlash 本身则来自一篇研究社区论文（arXiv 2602.06036），用轻量块扩散模型做并行起草，论文宣称在多个模型和任务上拿到超过 6 倍的无损加速，比 SOTA 的 EAGLE-3 再快 2.5 倍。
为何重要
值得改变判断的，是「极致速度只能靠专用硬件」这个前提被推翻了。Cerebras 和 Groq 的故事一直建立在一个隐含假设上：通用 GPU 的内存带宽和算子调度天花板就在那儿，要突破只能换一套物理形态。MiMo 这次证明了天花板还有相当大的余量没被榨干——靠的是把模型设计和系统设计绑在一起做。FP4 从 QAT 阶段就让模型适应低精度；DFlash 的 draft 模型刻意只用 SWA，和 MiMo-V2 系列对齐，把 draft 的每步注意力开销从随上下文线性增长压成常数窗口；TileRT 的 kernel 又是专门为这套量化和投机解码管线定制的。三层不是各自优化后拼起来，而是彼此为对方让步、共同演化的结果。这正是它对 builder 最有价值的地方：它演示的是一种方法论，而你买不到一台对应的机器。
第二个该被记住的点，是这套范式有一部分是可直接复用的。FP4 只量化 MoE Experts、DFlash 块级并行起草——这两件的原理留到「技术要点」展开，这里只给一句指针：做 MoE 推理的团队现在就该评估「只把 Experts 降到 FP4」，做结构化生成的团队该认真看已开源的 DFlash checkpoint。这两条都不是只能看不能碰的黑箱，落地门槛比想象中低。
第三，要给热度泼盆冷水：这套速度目前是 demo 级资源，不是可依赖的生产 SLA（为什么这么判，见末节「该忽略什么」对限时申请制的拆解）。在它给出稳定供给和透明定价之前，把它当能力展示看，别当可押注上线的服务。
技术要点
三件工程里，最值得 builder 抄作业的是前两件，因为它们和你跑什么硬件、用什么框架的耦合度最低。
FP4-only-experts 的关键不在 FP4 本身（MXFP4 是 OCP 标准化格式，Blackwell 这代卡有原生支持，HN 上也有人据此推测它跑的就是 Blackwell），而在「按模块挑量化精度」这个分层思路。它把一个看似全局的决策（模型量化几 bit）拆成了按参数敏感度分配预算的问题。这对任何 MoE 部署都成立，且不需要小米的 kernel 也能落地——主流推理框架对混合精度的支持已经够用。要注意的前提是它依赖 QAT，不是免费的训练后量化；你得有重训或微调的预算才能拿到「基本持平 FP8」这个结果。
DFlash 更有意思，因为它把投机解码和扩散模型这两条线接上了。传统投机解码（含 EAGLE 系）的 draft 仍是自回归的，串行链条没断。DFlash 用块扩散（block diffusion）做 draft：一次前向填满一整块掩码位，天然并行。小米在这之上叠了三个适配——draft 只用 SWA 摆脱对完整前缀的依赖、把 draft 的每步注意力开销从随上下文线性增长压成常数窗口（KV 仍随生成增长）；训练时把掩码信号采样下沉到 GPU 本地分片，一条序列一步就能产出上万个独立训练信号、避开跨设备通信；用 Muon 二阶优化器加自蒸馏保证小掩码块仍有高接受率。结果是 Coding/Math 这类结构性强、可预测性高的场景接受长度漂亮（6.30/5.56），Agent 场景中等（4.29）。
但接受长度这张表恰恰暴露了边界。小米自己承认：在语义发散、不确定性高的通用对话里，当前接受率还不高。这与「速度即智能」的宣传是矛盾的——投机解码的加速本质上吃的是「可预测性红利」，越是程式化、越是有标准答案的任务（写代码、算数学）越快，越是开放、创造性的对话越慢。换句话说，这套速度在可验证、强结构的任务上极快，在自由对话里会明显回落。它最适合 coding agent，正是因为这个形状。
对建设者的影响
如果你在自建推理栈，这次发布该改变你对「速度上限取决于什么」的认知。结论是：在投入买专用硬件之前，先把 model-system codesign 的空间吃干净。具体三步——其一，如果你跑 MoE，立刻评估「只量化 Experts 到 FP4」的方案，这是投入产出比最高的一刀，但要预留 QAT 的训练预算，别指望训练后量化能白嫖同样的精度。其二，如果你的负载是 coding agent 或结构化生成，认真看 DFlash：checkpoint 和论文都公开了，块级并行起草在这类高可预测性任务上的接受长度（6+）足以带来真实的端到端收益，远好于自回归 draft。其三，TileRT 那层（持久化 kernel、Warp Specialization、消除算子边界 gap）收益最大但最难自造，它要的是底层 kernel 工程能力；多数团队的现实选择是盯着 TileRT（开源在 tile-ai/TileRT）这类项目能不能用，而不是从零写。
但有一条纪律要守住：别为了追这个速度去重构你不需要的东西。绝大多数产品的瓶颈不是 decode 速度不够快，而是首 token 延迟、并发吞吐、成本、可靠性。1000 tps 解决的是「生成一长段输出要等多久」，它对 best-of-N 并行采样、长代码生成、实时交互这类场景是真价值；但如果你的用户一次只要几十个 token，或者你的瓶颈在检索和工具调用上，这个速度对你近乎无关。投入之前，先确认自己确实落在前一类场景里。
商业上的指针只有一句：别把这个限时 API 当生产依赖，要集成就拿开源 checkpoint 自己跑，把它当「一套可复现的方法」而非「一个可调用的服务」。也别只盯官方数字——HN 上有人对演示里的 1200 tps 峰值是否代表持续吞吐、还是择优截取的瞬时值存疑，真正能信的口径是平均 decode 速度与不同任务下的接受长度，这些你自己跑 checkpoint 就能复测。
该忽略什么
第一个要扔掉的是「速度即智能」。博客把它写成核心论点——速度快到一定程度，模型就从工具变成思维的延伸。但前文「技术要点」已经说清了它为什么站不住：投机解码吃的是可预测性红利，把速度转化为质量靠的是在同样墙钟时间里跑 best-of-N、并行探索多条路径再择优，而这条路有个硬前提——你得有办法验证哪条路径对。代码能跑测试、数学能验算，速度才换得来质量；开放任务里跑十条路径只是十个没法判优的答案。快是放大器，可验证性才是决定放大方向的开关。
第二个是手术室那段生死叙事。把 1T 模型的提速包装成「在手术台上与死神赛跑、为外科医生多争取一分自由度」，是纯粹的情绪营销，和这次发布的工程内容没有任何技术关联。医疗影像分析的瓶颈从来不是 LLM 解码速度，而是准确率、可解释性、监管审批和责任归属。把通用文本生成的 tps 数字嫁接到生死场景，是在借不相干的崇高感给一个推理速度 demo 镀金，读者应当直接略过。
第三个是把限时申请制读成普惠。「3 倍价格换 10 倍速度」「免费 Chat 限时开放」听上去是让利，但每天排队 10 次、单会话 30 分钟、申请不保证通过、仅开放两周——这些恰恰是稀缺资源在做配给。它告诉你的真相是：高速推理目前供给极其有限，这是一次受控的能力展示，不是一个可规模化、可依赖的产品。HN 上的怀疑很到位——这家公司不是靠融资烧钱的，这个定价和这套限制迟早要在账本上对齐。在它变成有稳定 SLA 的正式服务之前，把它当 demo 看，别当生产基础设施押注。