适用场景与目标

背景速览： 6 月 8 日，小米 MiMo 团队联合 TileRT 发布 MiMo-V2.5-Pro-UltraSpeed，在一台 8 卡商品 GPU 节点上把 1T 参数 MoE 模型 推到 1000+ tokens/s 解码速度（实测峰值约 1200 TPS），定价为 MiMo-V2.5-Pro 的 3×，但官方称”输出体验约 10ד（API 入口：platform.xiaomimimo.com/ultraspeed，试用窗口 6/9–6/23）。同步开源了 MiMo-V2.5-Pro-FP4-DFlash 权重到 HuggingFace（XiaomiMiMo/MiMo-V2.5-Pro-FP4-DFlash）。

这不是又一次”又一个大模型发布”。它的三个工程信号值得每一个在做 LLM 服务的团队关注：

1. 1T 量级 + 1000 TPS 的真实意义 —— 此前业内同档位 1000+ TPS 几乎只来自专用硬件（Cerebras WSE、Groq LPU），这次在商品 GPU 上做到。意味着”低延迟大模型”不再绑定特定芯片。
2. 三件套高度耦合 —— FP4 量化（仅 MoE Experts，MXFP4 + QAT） + DFlash block-level 并行投机解码（block size 8，Coding 场景 acceptance length 6.30，最高 7.14） + TileRT 持久化内核（Persistent Engine Kernel + Warp Specialization 异构流水线）。三者是协同设计的结果，单独抄任何一项都拿不到 1000 TPS。
3. 价格曲线被改写 —— 3× 单价买 10× 速度。如果你的服务在 30 TPS 上每秒跑 1 路换成 1000 TPS 上跑 33 路并发，单位 token 成本可能反而下降。这是 RAG、Code Agent、长上下文对话、批处理场景的成本拐点。

适用场景：

• 正在做或维护 LLM 在线推理服务（自托管 vLLM / SGLang / TensorRT-LLM / TileRT），并发长尾、成本压力大
• 想给 Coding Agent、量化交易、实时反欺诈、对话式 BI 接入”低延迟大模型”接口
• 已有 1T / 几百 B 级 MoE 模型在 8 卡 / 16 卡节点上跑，想知道 FP4 + 投机解码能榨出多少 tps
• 在评估”用专用推理硬件 vs 商品 GPU 优化”路线

核心目标：

用 一周时间 跑通一个真实可比的”高 TPS 路线”：

1. 今天：拿到 MiMo-V2.5-Pro-UltraSpeed API 试用资格（提交申请+排队），同步下载 FP4-DFlash 开源权重
2. D+1~D+3：在内部 8 卡节点上用 vLLM 跑通 MiMo-V2.5-Pro-FP4-DFlash，记录基线 TPS
3. D+4~D+5：尝试接 SGLang / 自研 speculative decoding，对比 acceptance length 与端到端 tps
4. D+6~D+7：把对比数据落到”是否上 UltraSpeed API 或自建 FP4 路线”的决策表，给出成本/性能/维护三维评分

---

最小可行方案（MVP）步骤

假设你的最小环境是：8× H100 80GB 或 8× H200 141GB 节点，PyTorch 2.5+，CUDA 12.4+，模型 1T MoE，FP16/BF16 基线 tps 30~60。

步骤 0：先抢试用，再谈自建

# 1. 申请 UltraSpeed API（限企业/有真实业务场景，6/9-6/23）
# 入口：https://platform.xiaomimimo.com/ultraspeed
# 准备材料：业务场景说明 + 预计 QPS + 公司主体（个人开发者也可能通过，但优先企业）

# 2. 同时下载开源权重（不受试用窗口限制）
pip install -U huggingface_hub
huggingface-cli login
huggingface-cli download XiaomiMiMo/MiMo-V2.5-Pro-FP4-DFlash \
  --local-dir /data/models/MiMo-V2.5-Pro-FP4-DFlash \
  --include "*.safetensors" "*.json" "*.txt"

为什么要并行？ 申请 API 大概率需要 1-3 天审批，与其在等待中空转，不如同时把开源权重先下到本地做基线 benchmark。

步骤 1：基线 —— 用 vLLM 0.6+ 跑 FP4-DFlash

# vLLM 在 0.6.x 已支持 MXFP4 / FP4 检查点（需 nightly 或自行编译）
pip install -U vllm==0.6.3.post1
vllm serve /data/models/MiMo-V2.5-Pro-FP4-DFlash \
  --tensor-parallel-size 8 \
  --enable-expert-parallel \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.92 \
  --enforce-eager  # 跳过 CUDA graph，先稳后快

基线压测脚本（用 vllm bench serve 或自写 OpenAI 兼容压测）：

# bench.py —— 测 decode 阶段 tps，prompt 256 / output 512 / 并发 1-64
import asyncio, time, statistics
from openai import AsyncOpenAI

c = AsyncOpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")

async def run(concurrency: int, n: int = 30):
    sem = asyncio.Semaphore(concurrency)
    tps = []
    async def one():
        async with sem:
            t0 = time.perf_counter()
            r = await c.chat.completions.create(
                model="/data/models/MiMo-V2.5-Pro-FP4-DFlash",
                messages=[{"role":"user","content":"写一个 Python 装饰器..."}],
                max_tokens=512, temperature=0.0, stream=True,
            )
            ntok = 0
            async for ch in r:
                if ch.choices[0].delta.content:
                    ntok += 1
            dt = time.perf_counter() - t0
            tps.append(ntok / dt)
    await asyncio.gather(*[one() for _ in range(n)])
    return statistics.median(tps)

for cc in [1, 4, 16, 32, 64]:
    print(f"concurrency={cc} median_tps={asyncio.run(run(cc)):.1f}")

把 1 / 4 / 16 / 32 / 64 五档的 tps 都记下来。重点观察 decode 阶段单请求 tps（不是 throughput）—— UltraSpeed 的核心卖点是单流 1000 TPS，多流并发时数字会摊薄。

步骤 2：上 DFlash 投机解码

vLLM 0.6+ 已支持 EAGLE/Medusa 等投机解码，DFlash 原理是 block-level 一次性预测 mask 块，不需要外加 draft 模型：

# 启用 speculative decoding（vLLM 通用接口，DFlash 作为 method）
vllm serve /data/models/MiMo-V2.5-Pro-FP4-DFlash \
  --tensor-parallel-size 8 \
  --enable-expert-parallel \
  --speculative-method dflash \
  --speculative-draft-model /data/models/MiMo-V2.5-Pro-FP4-DFlash/dflash \
  --speculative-block-size 8 \
  --num-speculative-tokens 8 \
  --max-model-len 32768

关键参数说明：

• speculative-block-size 8 —— DFlash 一次预测 8 个 mask 位置，论文和小米实测都表明 8 是 acceptance length 与 verification 开销的最优折中
• num-speculative-tokens 8 —— 每轮验证 8 个 draft token，配合 6.30 的平均 acceptance，Coding 场景等价 tps 可拉到 6~7×

实操预期： 在 Coding / Math / Agent 三类 prompt 上，单流 decode tps 应能涨到 300~500 TPS（取决于 draft 模型质量、KV cache 命中、prompt 结构）。如果你的基线是 50 TPS，这就是 6-10× 提升。

步骤 3：替换/并行运行 TileRT（可选，最佳路线）

TileRT 是小米合作的下一代推理 runtime，核心是 Persistent Engine Kernel + Warp Specialization：

• 传统 vLLM：每个 op 一次 launch，op 之间有”执行间隙”（microsecond 级）
• TileRT：整个计算流水线持久驻留 GPU，warp 之间异构分工，通信/搬运/计算同时进行

落地路径：

# 1. TileRT 当前为受限合作开放，需联系 tilert.ai 申请
#    对小米外部团队：先通过 MiMo 商务 (business-mimo@xiaomi.com) 接入
# 2. 内部自研路线可参考其思路：把 vLLM 的 CUDA graph + 算子融合
#    推进到 persistent kernel，优先在 decode 阶段拿收益

# 自研方向：把 decode attention + MoE gate + 输出投影 融合到一个 kernel
# 用 triton 写一个 persistent decoder step，参考：
# https://github.com/triton-lang/triton/blob/main/python/tutorials/09-persistent-matmul.py

重点：不要一上来就重写 runtime。 先用 vLLM + DFlash 把 acceptance length 测出来，再判断”是否值得为 1.5-2× 额外 tps 去接 TileRT”。收益评估是顺序决策：FP4 → DFlash → TileRT，前一项免费拿，后一项才考虑商业谈判或自研投入。

步骤 4：API 试用 vs 自建 成本对比

维度	UltraSpeed API	自建 vLLM + DFlash	自建 + TileRT
单价	3× 基础版	0（裸硬件）	0（裸硬件）
单流 tps	1000+	300~500	800~1100（接近 UltraSpeed）
8 卡 H100 月成本（电+机位）	0	~¥30k-50k	~¥30k-50k
接入时间	1 天	1 周	4-8 周（+ 商务谈判）
维护成本	0	1 人/周	2-3 人/周
数据出境	走 API	100% 内网	100% 内网

决策准则（粗算）：

• 业务 QPS < 5、敏感数据 → UltraSpeed API（先试用再签合同）
• QPS 5-50、有 1T 模型需求 → 自建 vLLM + DFlash（性价比最优）
• QPS > 50、毫秒级 SLA → 自建 + TileRT 或专用硬件（专线优化）

---

关键实现细节

1. 为什么是 FP4 量化 + 只量化 MoE Experts

传统 1T 模型 BF16 推理：~2 TB 权重，decode 受 HBM 带宽限制（H100 ~3.35 TB/s），
单卡理论上限 ≈ 1.6 TPS/token。8 卡并行也只到 ~13 TPS/token。

FP4（MXFP4）把权重压到 ~0.5 TB，单卡理论上限 ≈ 6.7 TPS/token，8 卡 ~54 TPS/token（4×）。

但 FP4 不是无损的：attention / embedding / 输出层对精度敏感，
直接全量化在 reasoning / code 上会掉点。
小米做法：仅对 MoE Experts 做 FP4 + QAT，其余模块保留原精度，
"带宽大户砍掉，精度敏感层保住"。

踩坑预警： 网上很多教程让你把整个模型 FP4 量化然后 fine-tune，1T 量级直接这样做的后果是数学题掉 5-10 分、code 任务掉 10+ pass@1。MiMo 的做法（MoE-only + QAT）才是 1T 量级 FP4 的正确姿势。如果你用 llm-compressor / AutoGPTQ，请确认你只量化 experts 列表。

# llm-compressor 里的正确做法（伪代码示意）
from llmcompressor.transformers import oneshot
from llmcompressor.modifiers.quantization import GPTQModifier

# 拿到 MiMo 的 MoE 专家层 pattern：model.layers.*.mlp.experts.*
recipe = [
    GPTQModifier(
        targets="Linear",
        scheme="MXFP4",
        ignore=[
            "lm_head",
            "re:.*self_attn.(q_proj|k_proj|v_proj|o_proj)",
            "re:.*mlp.(gate_proj|up_proj|down_proj)$",  # 注意：dense 路径要保留
            # 但 expert 内部线性层需要被量化
        ],
    ),
]
oneshot(...)

关键点：MoE 模型的 experts 内部 gate_proj / up_proj / down_proj 是要被量化的，但 dense 路径的同名层（如果存在）要保留。 不同 MoE 实现（Mixtral、Qwen-MoE、DeepSeek-MoE）的层命名不一样，先用 print(model) 把 expert 路径摸清楚再上 recipe。

2. DFlash 投机解码的关键差异

传统 Speculative Decoding（EAGLE / Medusa）：
  - 需要一个"小" draft 模型（1B-7B），单步预测 5-8 token
  - 接受率 = draft 模型质量的瓶颈
  - draft 模型的预训练成本 + 推理 overhead 是双倍税

DFlash（block-level masked parallel prediction）：
  - 不需要独立 draft 模型，复用主模型的某个轻量分支
  - 一次性预测 8 个 mask 位置（block size = 8）
  - Sliding Window Attention（SWA）天然对齐 MiMo-V2 的 SWA 设计
  - 训练时 mask-signal 采样下沉到 GPU-local shard，跨设备通信为 0

为什么 Coding 场景 acceptance 6.30 这么高：

• Code 任务局部结构性强（前一行推断后一行、变量名延续）
• Block size = 8 正好覆盖一个”逻辑小段”（函数签名、循环体、import 块）
• SWA 让 draft 不依赖远端 KV cache，单次预测 compute 是 O(constant) 而非 O(context)

踩坑预警：

• 不要在极长上下文（> 32K）+ 高随机性（temperature > 0.7）的对话场景期待同样收益。 DFlash 论文和小米都明说”语义发散场景 acceptance 会下降”——闲聊 / 创意写作收益小，code / math / structured 任务收益大。
• block_size 不是越大越好。 8 是 MiMo 实测最优；超过 8 verification 成本上升，acceptance 提升边际递减。改大之前先看你的 prompt 分布平均逻辑块长度。

3. TileRT 的”持久化内核”到底做了什么

传统推理 runtime（如 vLLM / TGI）：
  for step in decode:
    launch(attention_kernel)  ← 1 次 launch
    sync()                     ← 等待完成
    launch(moe_gate)           ← 1 次 launch
    sync()
    launch(expert_compute)
    sync()
    launch(output_proj)
    sync()
  # 每次 launch 都有 ~5-10 μs 的"间隙"

TileRT Persistent Engine Kernel：
  kernel[persistent_decoder_step]():
    while not done:
      compute_attention()
      prefetch_next_kv()       # 与当前计算并行
      compute_moe_gate()
      prefetch_next_expert()
      compute_expert()
      compute_output()
  # 整个 decode 循环在一个 kernel 里，warp 之间分工

核心收益：消除 op 边界间隙 + 跨层数据预取。 在 1000 TPS 频率下，每个 op 的生命周期是微秒级，传统 op 边界 overhead 占比会到 10-30%。

自研启示：即使不用 TileRT，也可以借鉴其思路 ——

1. 用 CUDA Graph 把 decode 阶段所有 op 捕获到一张图里（vLLM 已有 --enforce-eager=false 启用），一次 launch 跑完整个 step
2. 用 Triton 写一个 persistent attention kernel，把 KV prefetch 和 QK 计算 overlap
3. 用 TMA（Tensor Memory Accelerator，H100/H200 特性）做异步数据搬运

这是”商品 GPU 也能 1000 TPS”的关键。不是某个 trick，而是把每微秒都榨干。

4. 8 卡节点不是”刚好够用”

1T MoE 模型 + FP4（0.5 TB）+ 推理 KV cache + DFlash draft state：
  - 权重：0.5 TB
  - KV cache（32K context, 8 卡 TP）：~80-120 GB
  - DFlash 额外 state：~10-20 GB
  - DFlash draft forward workspace：~30 GB
  - 总需求：~620-680 GB

8 × H100 80GB = 640 GB（刚好够，剩 0-20 GB 给 activation）
8 × H200 141GB = 1128 GB（富余 50%+，推荐）

踩坑预警：

• 8 卡 H100 80GB 跑 32K context 是”踩线”配置，实际部署时 OOM 概率不低。生产环境建议 H200 或 16 卡 H100。
• TP=8 时单卡专家路由出现长尾，最慢的卡会拖慢整体 step。考虑 EP（Expert Parallel）+ TP 混合切分（vLLM --enable-expert-parallel）。
• 量化 baseline 永远先跑 FP8，再考虑 FP4。 FP4 的 QAT 成本和故障排查成本远高于 FP8，只有在 FP8 带宽不够时才上 FP4。

---

常见坑与规避清单

坑	症状	规避
把整个模型 FP4 量化	数学/代码任务掉 5-15 分	只量化 MoE Experts，attention/embedding/lm_head 保留原精度，配 QAT
block_size 拍脑袋设 16/32	acceptance 提升 ≤ 1.2×，verification cost 反涨	默认 8，先扫 4/8/16 三个值看 acceptance × block 收益
Speculative decoding 在闲聊场景上线	acceptance 掉到 1.5-2.5，端到端 tps 不升反降	路由层先做 prompt 分类：code/math/agent 走 DFlash 路径，闲聊走普通路径
vLLM 0.5.x 跑 MXFP4	启动报 unsupported dtype mxfp4	升 0.6.3+ 或用 nightly；FP4 通路还没完全 backport 到所有 release
8 卡 H100 80GB 硬上 32K context	高负载时段随机 OOM	H200 / 16 卡 / 把 max-model-len 砍到 16K + sliding window
TP=8 单卡路由长尾	p99 延迟是 p50 的 3-5 倍	启用 expert parallel + load balance；监控单卡 token throughput
申请 UltraSpeed API 用个人邮箱	审批不过 / 排队很久	用公司邮箱 + 业务场景说明 + 预计 QPS，优先企业用户
把 UltraSpeed API 当裸模型评估	拿到 1000 TPS 数字后没考虑单价和并发摊薄	跑真实业务 workload 算 $/1M tokens，3× 单价 vs 10× 速度的交叉点
拿 TileRT 当银弹	试图用它解决所有延迟问题	先 FP4 → DFlash → 再考虑 TileRT，按顺序评估增量收益
不做 KV cache 复用	多轮对话 / RAG 重复 prefill 浪费算力	vLLM 启用 prefix caching + chunked prefill；RAG 场景考虑 context cache
没监控 acceptance length	DFlash 在线服务 acceptance 漂移	加 metric：speculative_accept_rate per endpoint，低于阈值自动降级到普通路径
DFlash 训练数据不覆盖你的业务	acceptance 不及预期	用自有 code / agent trace 继续 self-distill，参考 Muon 优化器

---

成本/性能/维护权衡

单 token 成本对比（以 1T MoE 模型为基准）

方案	8 卡 H100 满载	8 卡 H200 满载	32K context 单请求延迟 (p50)	单价 (¥/1M tokens)	月承载能力
基础版 API（30 TPS）	n/a	n/a	17s	基准 (¥X)	n/a
UltraSpeed API（1000 TPS）	n/a	n/a	0.5s	3X	n/a
自建 BF16 + vLLM	~30 TPS	~40 TPS	13s	0.5X（折旧+电费）	~100M tokens
自建 FP8 + vLLM	~80 TPS	~110 TPS	4s	0.3X	~270M tokens
自建 FP4 + vLLM（无投机）	~150 TPS	~210 TPS	2s	0.18X	~520M tokens
自建 FP4 + DFlash	~400 TPS	~560 TPS	0.9s	0.07X	~1.4B tokens
自建 FP4 + DFlash + TileRT	~850 TPS	~1100 TPS	0.45s	0.03X	~3B tokens

数字为根据公开信息和工程经验估算，实际值以你的 workload 实测为准。

关键洞察：

• 自建 FP4 + DFlash 路线单位 token 成本只有 UltraSpeed API 的 ~2.3%（0.07X / 3X），月承载能力是 1.4B tokens
• UltraSpeed API 的真正优势是 0 运维 + 0 启动成本，适合 QPS < 5 / 短期 PoC / 敏感数据之外的灰度场景
• 成本拐点：当月消耗 > 200M tokens 时，自建 FP4 + DFlash 路线开始回本（按 8 卡 H100 月 ¥40k 算）

维护成本

方案	启动期	稳态期	故障率
UltraSpeed API	1 天	0 人天/月	SLA 99.9%（小米承诺）
vLLM FP4 + DFlash	1-2 周	2-3 人天/月	OOM、长尾路由问题偶发
+ TileRT	+ 4-6 周（商务+对接）	+ 5-8 人天/月	持久化 kernel 偶发 deadlock（生产案例少）

维护角度建议：

• 中小团队（< 5 人 AI infra） → API 优先，避免自研 runtime
• 中型团队（5-20 人） → vLLM FP4 + DFlash 是 sweet spot
• 大型团队（> 20 人）且并发 > 50 → TileRT / 自研 persistent kernel 值得投入

性能监控的关键指标

上线后必看：

1. 单流 decode tps p50 / p99（不是 throughput，是单请求速度）
2. speculative_accept_rate per endpoint（DFlash 健康度）
3. GPU SM 活跃率（应该是 60-85%，持续 > 90% 是 over-subscribed）
4. HBM bandwidth 占用（FP4 decode 应在 70%+，低于说明有优化空间）
5. p99 / p50 比值（应 < 3，> 5 说明路由长尾严重）

---

一周内可执行行动清单

假设本周一看到这篇，目标下周一做出”上不上 / 怎么上”的决策。

• D1（今天）

  • 提交 UltraSpeed API 试用申请（platform.xiaomimimo.com/ultraspeed），公司邮箱 + 业务场景
  • huggingface-cli download XiaomiMiMo/MiMo-V2.5-Pro-FP4-DFlash 到本地
  • 用 vLLM 0.6.3+ 跑通 FP4 baseline，记录 1/4/16/32/64 并发下的 tps

• D2

  • 启用 --speculative-method dflash --speculative-block-size 8，复测同一组 prompt
  • 跑 acceptance length 在 code / math / chat 三类 prompt 上的分布
  • 关注：p99 latency 是否因 draft 验证增加而抬升（> 30% 要警惕）

• D3

  • 把 acceptance × 业务 prompt 分布喂给路由层，决定是否分流
  • 跑成本测算：拿你过去 7 天的 token 消耗 × 三个方案（API / 自建 / 自建+DFlash）
  • 写一份 1 页的 ROI 对比，发给老板

• D4

  • 申请 UltraSpeed API 通过后，用 30 个真实业务 prompt 对比 API vs 自建的实际 tps
  • 验证数据出境合规（如果你的数据不能出内网，API 方案直接否）

• D5

  • 如有需要，给 vLLM 提 issue / 给小米 / TileRT 提 feedback（开源权重是邀请社区共建的）
  • 试用 tilert.ai 申请渠道，即使不接入也先排队（商务流程通常 4-8 周）

• D6

  • 写内部”高 TPS 路线”技术分享，把 FP4 / DFlash / TileRT 三件套原理讲清楚
  • 给团队做一次”投机解码在生产环境怎么评估”的培训

• D7（下周一）

  • 输出最终决策：API / 自建 / 等待 TileRT，给出时间表和预算
  • 如决定自建，拉一个 4 人小组（推理 / SRE / 业务方 / PM）开 kick-off
  • 把本篇文章的 checklist 同步到团队 wiki

---

参考资料

• MiMo-V2.5-Pro-UltraSpeed 官方发布
• 开源权重 HuggingFace: XiaomiMiMo/MiMo-V2.5-Pro-FP4-DFlash
• TileRT 技术细节
• DFlash 论文 arxiv.org/abs/2602.06036
• OCP Microscaling Formats (MX) v1.0 Spec
• vLLM 投机解码文档
• llm-compressor (vLLM 项目)