从逐字到逐块：大模型推理正告别串行时代
DiffusionGemma、DFlash/Domino、Stem/CLSA 三条并行加速路径同期交汇，大模型推理从逐 token 串行走向块级并行，工程落地该怎么选？
引言
2026 年 6 月，大模型推理领域出现了罕见的”三线交汇”。
6 月 11 日，Google 发布 DiffusionGemma——26B MoE 文本扩散模型，单次前向传播生成 256 个 token，H100 上实测 1000+ tokens/s；6 月 9 日，小米 MiMo 团队推出 MiMo-V2.5-Pro-UltraSpeed，在万亿参数 MoE 模型上突破 1000 tokens/s，核心是 DFlash 块级推测解码 + FP4 量化；6 月 5 日，腾讯混元开源 Stem 稀疏注意力算法（ICML-26 收录），128K 上下文首字延迟降低 3.6 倍；5 月底，上海交大 Domino 框架在 SGLang 上实现 5.8 倍吞吐加速；6 月初，CLSA 跨层稀疏注意力在 128K 上下文下实现 17.1 倍端到端吞吐提升。
这些工作看似方向各异，实则指向同一个结论：自回归逐 token 串行生成的天花板已经被打破，块级并行推理正在成为新的工程范式。 Google 在 DiffusionGemma 推出当天宣布 vLLM 团队原生支持（vLLM 历史上第一个扩散模型），是这一范式迁移的最直接信号。
本文将梳理三条并行加速路径的技术原理，给出工程落地选型决策树和可操作的部署配置。
一、串行瓶颈：为什么逐 token 生成已经到头
1.1 内存带宽墙
当前主流大模型推理的 decode 阶段是内存带宽受限（memory-bandwidth-bound）的：每次生成 1 个 token，都需要将完整模型权重从显存加载到计算单元，但仅执行一次矩阵乘法。GPU 的 Tensor Core 利用率通常不足 10%。
单次 decode step 的瓶颈：
加载权重（~25GB for 70B FP8）→ 1 次 GEMM → 输出 1 token
计算时间 << 权重加载时间 → GPU 大部分时间在"等"在云端高并发场景，多个请求可以 batch 在一起分摊加载开销；但在本地推理或低并发场景，这种逐 token 的”打字机模式”浪费了绝大多数算力。
1.2 加速天花板
传统推测解码（Speculative Decoding）用小模型猜测 + 大模型验证，但受限于草稿模型的串行自回归生成，加速比通常在 2-3 倍封顶。原因很简单：草稿模型自身也是逐 token 生成的，γ 个 token 需要 γ 次前向传播，草稿延迟随块大小线性增长。
| 方法 | 草稿生成方式 | 理论加速上限 | 实测加速 |
|---|---|---|---|
| 无加速 | 逐 token 自回归 | 1× | 1× |
| EAGLE-3 | 逐 token 自回归草稿 | ~2.5× | ~2× |
| DFlash | 单次前向并行块生成 | ~5× | ~3× |
| Domino | 并行草稿 + 因果修正 | ~6× | ~5.8× |
| DiffusionGemma (本地消费级) | 块扩散去噪 | ~4× | ~4× |
| DiffusionGemma (H100 vLLM FP8) | 块扩散去噪 | ~6× | ~6× (1008 t/s vs ~170 t/s 基线) |
注：DiffusionGemma 加速比有两个口径——Google 官方”4ד针对本地消费级硬件（RTX 5090 700+ t/s 对比 AR 同规模模型约 175 t/s）；vLLM 团队在 H100 + FP8 下实测 1008 t/s，对比同 H100 自回归基线（约 170 t/s）实为 6×，原表统一为 4× 不够精确。
二、三条并行加速路径
路径一：扩散式块生成——DiffusionGemma
核心思路：彻底放弃自回归，用扩散模型的方式一次生成整块文本。
DiffusionGemma 的生成过程不是”从左到右逐字输出”，而是：
- 初始化一个 256 token 的”画布”，填入随机占位 token
- 进行多轮去噪（denoising pass），每轮用双向注意力让所有位置互相参考
- 每轮结束后，对每个位置计算熵（entropy），熵低于阈值 0.005 的位置”锁定”
- 锁定位置退出后续去噪，未锁定位置重新采样
- 全部锁定或达到最大步数（48 步）后，将整块 256 token 提交到 KV Cache
# DiffusionGemma 推荐采样配置
sampling_config = {
"max_denoising_steps": 48,
"temperature_start": 0.8,
"temperature_end": 0.4,
"temperature_schedule": "linear", # 线性退火
"entropy_bound": 0.1, # 熵阈值
"canvas_size": 256, # 每块 256 token
"token_selection": "mutual_information" # 互信息选择
}关键架构参数：
| 参数 | 值 |
|---|---|
| 总参数量 | 25.2B (MoE) |
| 每步激活参数 | 3.8B |
| 专家数/激活数 | 128 / 8 + 1 shared |
| 上下文长度 | 256K |
| H100 生成速度 | 1,008-1,100 t/s (FP8) |
| H200 生成速度 | ~1,288 t/s (FP8) |
| RTX 5090 速度 | 700+ t/s |
| 量化后显存 | 18-24 GB |
| 许可证 | Apache 2.0 |
适用场景：本地/边缘推理、低并发交互式应用、非线性生成任务（代码填充、行内编辑、数学/科学结构化输出）。
局限：
- 整体输出质量低于标准 Gemma 4，Google 明确建议生产级高质量输出仍用 Gemma 4
- 高并发云端场景优势减弱，因为 AR 模型可以通过 batch 饱和算力
- 当前为实验性模型，生态支持有限
路径二：块级推测解码——DFlash + Domino
核心思路：保留自回归目标模型，但让草稿模型从”逐字猜测”升级为”一次猜一整块”。
DFlash：块扩散草稿模型
DFlash 的草稿模型是一个 5 层 Transformer，使用双向注意力在单次前向中并行预测整块 token：
DFlash 推理流程：
┌───────────────────────────────────────────────┐
│ 1. 目标模型提供多层隐藏状态（KV 注入） │
│ 2. 草稿模型接收：[最后一个确认token] + [mask×γ] │
│ 3. 单次前向传播 → 并行预测 γ 个 token │
│ 4. 目标模型验证整块 → 接受/拒绝 │
└───────────────────────────────────────────────┘小米 MiMo 在 DFlash 基础上做了三项关键定制：
- Muon 二阶优化器训练草稿模型，提升小 mask 块的接受率
- 模型自蒸馏，让草稿模型更紧密匹配目标模型分布
- SWA（滑动窗口注意力）：草稿模型全部使用 SWA，不依赖完整前缀，算力从线性变为常数级
实测接受长度（MiMo-V2.5-Pro-UltraSpeed）：
| 场景 | 平均接受长度 | 最长接受长度 |
|---|---|---|
| Coding | 6.30 | 7.14 |
| Math/Reasoning | 5.56 | — |
| Agent | 4.29 | — |
MiMo 同时将 mask 块大小限制为 8，降低验证开销、提高并发水平。
Domino：并行草稿 + 因果修正
DFlash 的短板是块内 token 之间缺乏因果依赖建模，导致接受率在长块时下降。Domino（上海交大 + 华科 + 电子科大 + 复旦 + 华为）给出的解法是解耦因果建模与自回归执行：
Domino 架构：
┌──────────────────────────────────────────────────┐
│ 并行草稿骨干 → 产出基础分布 L_base（全块一次性） │
│ ↓ │
│ Domino Head（轻量级因果修正）： │
│ - 因果编码器（GRU, dim=1024）编码前缀依赖 │
│ - 低秩校正头（rank=256）生成 logit 残差 ΔL │
│ - 最终分布：L = L_base + ΔL │
│ ↓ │
│ 融合 Triton kernel + CUDA Graphs 最小化开销 │
└──────────────────────────────────────────────────┘关键训练策略——基准锚定课程（Base-Anchored Curriculum）：
# Domino 训练损失（伪代码）
# 防止因果修正分支"抢功"导致并行骨干退化
lambda_t = 1.0 # 初始值，线性退火到 0
def domino_loss(L_base, L_corrected, targets, step, total_steps):
# 退火权重：初期强调基础分布，后期侧重校正分布
lambda_t = 1.0 - step / total_steps
# 位置依赖指数衰减：优先前端 token
position_weights = [exp(-k / gamma) for k in range(block_size)]
loss = (1 - lambda_t) * ce_loss(L_base, targets, position_weights) \
+ lambda_t * ce_loss(L_corrected, targets, position_weights)
return loss实测性能（Qwen3 系列）：
| 指标 | Transformers 后端 | SGLang 服务 |
|---|---|---|
| 端到端加速 | 最高 5.49× | 最高 5.8× |
路径三：稀疏注意力加速——Stem + CLSA
核心思路：不改变生成范式，但让注意力计算从 O(n²) 降到 O(n·k)。
Stem：因果信息流驱动的块级稀疏
腾讯混元的 Stem 算法从”因果信息流”角度重新审视块级稀疏，核心洞察是初始 token 是信息流的”树干”——它们通过递归依赖链影响所有后续 token 和网络层，稀疏掉初始 token 会导致误差逐层放大。
两项创新：
- Token 位置衰减（TPD）：线性衰减的预算分配，初始位置分配大预算（保留关键信息），末尾位置小预算（激进剪枝），总计算量不变
- 输出感知度量（OAM）：选择 token 时不仅看注意力分数，还看 Value 向量的幅值
HPC 算子库（github.com/Tencent/hpc-ops）做了两层优化：
- HPC-Stem：利用 OAM 纯加法结构数学简化，计算量降低约 64 倍，消除 16GB 中间张量
- HPC-BSA：针对 Hopper 架构从头设计，数据搬运与计算并行流水线，原生支持 vLLM Paged KV Cache 和 FP8
# Stem 在 vLLM 中的集成配置
# 参考: https://github.com/Tencent/AngelSlim
from vllm import LLM, SamplingParams
# 加载模型时启用 Stem 稀疏注意力
model = LLM(
model="tencent/Hunyuan-3-Preview",
sparse_attention_method="stem",
stem_tpd_decay="linear", # Token 位置衰减策略
stem_oam_beta=0.5, # OAM 中 Value 幅值权重
stem_sparsity=0.75, # 75% 稀疏度 = 25% 算力
quantization="fp8", # 配合 FP8 量化效果更佳
)实测性能（Hy3 Preview, W8A8-FP8）：
| 上下文长度 | 首字延迟加速比 |
|---|---|
| 16K | 1.50× |
| 32K | 1.96× |
| 64K | 2.68× |
| 128K | 3.62× |
CLSA：跨层共享路由索引
CLSA（arXiv:2606.06467）基于 YOCO 的 KV 共享架构，进一步跨层共享路由索引——单个索引器计算一次 top-k 选择后，所有解码器层复用同一索引：
CLSA 架构流程：
┌────────────────────────────────────────────────┐
│ Self-Decoder → 生成共享 KV Cache（只算一次） │
│ ↓ │
│ Query-Aware Indexer → 一次 top-k 路由选择 │
│ ↓ │
│ Cross-Decoder × N 层 → 复用共享 KV + 共享索引 │
│ 每层保留自己的 Query 状态和 FFN │
└────────────────────────────────────────────────┘训练采用多层蒸馏两阶段策略：
- 冻结骨干网络，预热索引器学习”共识显著 token”
- 联合稀疏微调，迫使单一索引器满足所有解码器层需求
128K 上下文下：解码吞吐 7.6×，端到端吞吐 17.1×。
局限：强依赖 YOCO 交叉注意力架构，无法直接替换标准 Transformer（如 LLaMA）。
三、工程选型决策树
面对三条路径，生产环境怎么选？以下是决策框架：
你的推理场景是什么？
│
├─ 本地/边缘推理（单用户、低并发）
│ └─ 选择 DiffusionGemma
│ - 块扩散天然适合低并发（消除内存带宽墙）
│ - 18GB 显存可跑（RTX 5090/4090）
│ - 注意：输出质量略低，需评估是否可接受
│
├─ 云端推理（高并发、多租户）
│ ├─ 短上下文（< 32K）
│ │ └─ 选择 DFlash/Domino 块级推测解码
│ │ - 不改变模型架构，即插即用
│ │ - Domino > DFlash（接受率更高）
│ │ - 已有 vLLM/SGLang 集成
│ │
│ └─ 长上下文（> 64K）
│ └─ 选择 Stem 稀疏注意力
│ - 首 token 延迟是长上下文核心痛点
│ - 算法+算子打包，从理论到实测全栈打通
│ - 已集成 Hy3 推理框架
│
└─ 长上下文 + 可改模型架构
└─ 选择 CLSA
- 吞吐提升最极端（17.1×）
- 但需要 YOCO 架构，迁移成本高
- 适合新模型训练时直接采用组合策略
三条路径并非互斥，可以组合使用：
| 组合 | 效果 | 难度 |
|---|---|---|
| Stem (稀疏) + DFlash (推测解码) | 长上下文 + decode 加速 | 中（需验证兼容性） |
| Stem (稀疏) + Domino (推测解码) | 长上下文 + 更高接受率 | 中-高 |
| FP4 量化 + DFlash | MiMo 验证的成熟组合 | 低（MiMo 已开源） |
| DiffusionGemma + 蒸馏微调 | 特定任务极速推理 | 中（需 Unsloth 等工具） |
四、实战配置：Stem + vLLM 部署长上下文推理
以下是以腾讯混元 Stem 为例的完整生产部署配置：
4.1 环境准备
# 安装 vLLM（>= 0.8.0 支持 Stem 稀疏注意力）
pip install vllm>=0.8.0
# 安装 HPC 算子库
pip install hpc-ops # 或从源码编译
# git clone https://github.com/Tencent/hpc-ops.git
# cd hpc-ops && pip install .4.2 启动推理服务
python -m vllm.entrypoints.openai.api_server \
--model tencent/Hunyuan-3-Preview \
--quantization fp8 \
--sparse-attention-method stem \
--stem-sparsity 0.75 \
--stem-tpd-decay linear \
--stem-oam-beta 0.5 \
--max-model-len 131072 \
--gpu-memory-utilization 0.92 \
--tensor-parallel-size 4 \
--port 80004.3 性能调优参数
# 关键调优参数
STEM_CONFIG = {
# 稀疏度：0.5-0.85，推荐 0.75（25% 算力）
"sparsity": 0.75,
# TPD 衰减策略：linear / exponential
# linear 更稳健，exponential 在超长上下文(>256K)时更激进
"tpd_decay": "linear",
# OAM beta 值：0.3-1.0
# 越大越重视 Value 幅值，越小越接近纯注意力分数
# 推荐起始值 0.5，按任务调整
"oam_beta": 0.5,
# 配合 FP8 量化（计算吞吐翻倍）
"quantization": "fp8",
}4.4 监控指标
# 生产环境必须监控的指标
MONITORING = {
# 首 Token 延迟（TTFT）—— Stem 的核心优化目标
"ttft_p50_ms": "目标: < 2000ms @ 128K",
"ttft_p99_ms": "目标: < 5000ms @ 128K",
# 稀疏度实际值（可能因输入长度波动）
"actual_sparsity": "目标: > 0.70",
# 质量退化指标（对比稠密基线）
"quality_regression": "目标: < 2% 准确率下降",
# GPU 利用率
"gpu_util_percent": "目标: > 85%",
# 显存占用
"vram_usage_gb": "目标: < 90% 总显存",
}五、踩坑记录
| 问题 | 现象 | 解决方案 |
|---|---|---|
| Stem 稀疏度设太高 | 首轮问答质量明显下降 | 从 0.75 起步，每次增加 0.05 观察；>0.85 需严格回归测试 |
| DFlash 块大小贪大 | 接受率断崖式下降 | 块大小 8-16 是甜蜜点；MiMo 实测 8 最优 |
| Domino 训练不收敛 | 并行骨干退化，草稿质量崩塌 | 检查 base-anchored curriculum 的 λ 退火速率；确保初期 λ 足够大 |
| DiffusionGemma 去噪步数太多 | 速度优势消失 | 48 步上限，实际 20-30 步即可锁定 90%+ token |
| CLSA 迁移到 LLaMA | 不兼容，需要 YOCO 架构 | CLSA 目前无法用于标准 Transformer；考虑先用 Stem 替代 |
| FP4 量化后 agent 场景退化 | 工具调用格式错误率上升 | MiMo 方案：仅对 MoE Expert 层 FP4，非 Expert 模块保持 FP8 |
| Stem + FP8 精度叠加 | 长尾任务性能下降 | 分开 A/B 测试：先测 FP8 单独影响，再加 Stem；逐层排查 |
六、性能基准横向对比
| 方案 | 模型 | 加速比 | 精度损失 | 显存需求 | 部署复杂度 | 开源 |
|---|---|---|---|---|---|---|
| DiffusionGemma | 26B MoE (3.8B active) | ~4× (本地) | 中（GPQA↓16pp） | 18-24 GB | 低（HuggingFace 即用） | ✅ Apache 2.0 |
| DFlash | Qwen3-8B | ~3× | 低（<1% 基准） | +草稿模型显存 | 中（需训草稿模型） | ✅ |
| Domino | Qwen3 系列 | ~5.8× | 低（<1% 基准） | +草稿模型显存 | 中-高（课程训练） | ✅ |
| Stem | Hy3 Preview | ~3.6× TTFT@128K | 近无损（25%算力） | 无额外 | 低（算法+算子打包） | ✅ |
| CLSA | YOCO 架构 | ~17.1× e2e@128K | 近无损 | KV Cache 大幅缩减 | 高（需改架构） | ✅ |
| MiMo UltraSpeed | 1T MoE | ~10× 输出速度 | 低（FP4 Expert） | 8×H100 | 中 | 部分 |
结论
2026 年 6 月的大模型推理优化领域，正在经历一次从”逐 token 串行”到”块级并行”的范式迁移。三条路径各有明确边界：
- 改生成范式（DiffusionGemma）：最彻底，但质量有折衷，适合特定场景
- 改草稿方式（DFlash/Domino）：最务实，即插即用，适合现有 AR 模型加速
- 改注意力计算（Stem/CLSA）：最精准，解决长上下文核心痛点，Stem 部署最易
对工程师而言，最现实的路径是：先用 Stem 解决长上下文首字延迟，再用 Domino 提升解码吞吐。两者都在 vLLM 生态中有成熟支持，迁移成本最低。如果你的场景是本地推理且对质量容忍度较高，DiffusionGemma 是值得尝鲜的选择——毕竟 Apache 2.0 开源、18GB 显存可跑，门槛已降至消费级硬件。
串行时代正在结束。块级并行推理不是未来，是现在。