1T 模型跑出 1000 tok/s:MiMo × TileRT 的模型-系统联合设计到底做了什么

一个万亿参数的模型,在 8 张消费级 GPU 上每秒吐出 1000 个 token——这件事本身并不新鲜,因为类似数字过去只在论文 demo 或特制硬件上见过。但小米 MiMo 团队和 TileRT 推出的 MiMo-V2.5-Pro-UltraSpeed,用的是商品化 GPU、开源推理框架、没有定制芯片。这就有意思了。 更关键的是,实现这个速度的路径不是"把量化做狠一点"或"投机解码多猜几个 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 的做法是选择性量化: ...

June 10, 2026 · 2 min · Hypho

Gemma 4 的多 token 预测:LLM 推理加速不该只盯着量化

如果你最近还在把“LLM 推理优化”等同于量化,我建议停一下。 量化当然重要,尤其是本地部署和消费级 GPU 场景。但 Google 刚发的 Gemma 4 多 token 预测(Multi-Token Prediction, MTP)让我更确信一件事:下一轮推理加速的主战场,不只是在“把模型压小”,而是在减少大模型被调用的次数。 Google 在官方博客里说,Gemma 4 通过 MTP drafters 在推理阶段最高可以做到 up to 3x faster。这个数字本身很抓眼球,但我更关心它背后的工程含义:如果草稿器能一次猜中多个后续 token,大模型就不必老老实实一个 token 一个 token 地跑完整前向传播。 说白了就是:以前是大模型每吐一个字都要“亲自审批”;现在是小模型先写一小段,大模型批量盖章。 为什么“一个 token 一次前向”这么浪费 自回归 LLM 的默认解码方式很朴素:给定上下文,预测下一个 token;把这个 token 拼回上下文,再预测下一个。这个循环看起来合理,但对硬件很不友好。 每生成一个 token,模型都要访问大量权重。对于 27B、70B 这种规模,瓶颈往往不是矩阵乘法算不动,而是显存带宽和调度开销被小步循环吃掉。你可以把它理解成:GPU 明明适合一次搬一大车货,结果我们让它每次只送一个快递。 这也是为什么我之前写 DFlash + DDTree 投机解码 时,最看重的不是某个 benchmark 数字,而是“平均接受长度”。只要一次验证能接受更多 token,大模型前向次数就会下降,吞吐自然上来。 Gemma 4 的 MTP 走的是同一条大方向,但实现路径更靠近模型训练本身。 传统 speculative decoding 通常需要一个独立的小 draft model。经典论文 Speculative Sampling 的思路就是:小模型先生成候选,大模型并行验证,最后用修正过的采样过程保证输出分布不变。这套方法很漂亮,但工程上有两个麻烦:你要维护两个模型,还要处理 tokenizer、KV cache、调度和显存布局。 MTP 的反直觉之处在于,它不一定非要靠“另一个完整小模型”来猜。Meta 的论文 Better & Faster Large Language Models via Multi-token Prediction 提出,在训练时让模型不只预测下一个 token,而是同时预测未来多个 token。技术上可以看成在共享 trunk 上接多个输出 head,训练目标从“只看一步”扩展到“顺手看几步”。 ...

May 6, 2026 · 2 min · Hypho

单卡 207 tok/s:DFlash + DDTree 让 Qwen3.5-27B 在 RTX 3090 上跑出推理新纪录

一个 27B 参数的大模型,在一张 2021 年买的游戏显卡上能跑多快? Lucebox 团队给出了一个让很多人没想到的数字:207.6 token/s。用的还是 Qwen3.5-27B 官方模型,不是蒸馏,不是 INT8 量化残血版——就是 Q4_K_M 量化版本,目标加草稿模型全部加载在一张 24 GB VRAM 的 RTX 3090 上。 这个成绩靠的不是等英伟达下一代消费级显卡,而是对解码算法本身动刀子。 为什么自回归解码是瓶颈 大多数人聊 LLM 推理优化,会先想到量化、KV cache 压缩、batch 并行。但对单卡消费级 GPU 来说,这些都已经做到头了——Q4_K_M 量化能压缩到约 16 GB,再压下去效果肉眼可见地降。 问题出在自回归解码本身。每生成一个 token,GPU 要完整跑一遍 27B 参数的前向传播。27B 参数在 Q4_K_M 下大约 16 GB,VRAM 带宽是 936 GB/s——每次解码都要把这 16 GB 从显存读一遍,理论带宽利用率撑死不到 20%。这是机械式的物理限制,不是软件优化能绕过去的。 speculative decoding(投机解码)解决的就是这个问题:用一个小草稿模型一次生成多个候选 token,再用大模型一次验证整串。如果草稿猜得准,大模型只跑一次就能吐出五六个 token,GPU 计算资源用得更充分。 DFlash:块扩散草稿,比 Chain EAGLE 更容易命中 主流投机解码方案是 EAGLE(及其 chain 版),草稿模型做自回归预测,每步大约能接受 3 个 token。DFlash(2026) 换了个思路:用块扩散(block diffusion) 做草稿——一个 5 层非因果的去噪网络,同时预测多个位置,而不是逐个生成。 ...

April 21, 2026 · 2 min · Hypho