扩散语言模型详解：并行解码、文本编辑与 Agent 边界

**扩散语言模型（Diffusion Language Model，DLM）**把更广义的扩散模型思想用于语言，通过迭代去噪生成文本，而不是严格从左到右逐个确定输出 Token。这种差异可以暴露更多并行计算，支持填空和反复修订，也会改变延迟结构；但它本身并不保证回答更快、推理更强或 Agent 工具调用更可靠。

真正值得回答的工程问题不是“扩散会不会取代自回归”，而是：某个 DLM、解码器、运行时和硬件组合，能否在明确工作负载上，以更低成本交付与基线同等可靠的结果。

核心结论

• 文本扩散可以发生在连续嵌入、离散 Token 状态，或自回归 Block 与块内扩散的混合结构中。
• 掩码式 DLM 通常并行预测多个位置，提交一部分结果，再把不确定位置重新掩码并继续修订。
• Token 并行更新不等于端到端更快；去噪轮数、每轮有效提交量和 Kernel 效率同样重要。
• 长度预测、Token 编辑、精确格式和缓存复用都是一等运行时契约。
• Agent 场景必须单独测试规划、工具选择、精确参数、失败恢复和多轮交互。
• 应在质量对齐后比较单次合格结果成本，不能搬运不同条件下的 Tokens/s。

扩散语言模型如何生成文本

文本 DLM 先定义一个损坏过程，再学习如何逆转它。以常见的离散掩码方案为例，训练时按随机噪声级别把部分 Token 替换成 Mask，模型根据未损坏上下文恢复原 Token；生成时则从一组 Mask 位置开始，多轮预测并提交结果。

不同系统的“扩散”不能混为同一种 API：

• 连续扩散语言模型在连续表示空间执行去噪，再映射回 Token。
• 离散扩散语言模型直接在 Token 状态上定义损坏与恢复。
• 掩码扩散语言模型使用吸收式 Mask 状态，并决定每轮揭示哪些位置。
• 块扩散模型按顺序生成 Block，但在 Block 内并行更新多个位置。
• 混合系统会组合自回归边界与块内扩散，或把扩散模型用作 Speculative Decoding 的 Drafter。

这些术语描述的是模型家族，不是可互换实现。针对一种噪声过程训练的 Checkpoint，不能默认兼容另一个模型的 Scheduler 或 Remasking 规则。

DLM、掩码语言模型与自回归模型的区别

三种范式最核心的差异是训练目标和产生完整输出的方式。

DLM 仍然可以使用 Transformer 作为 Backbone。“扩散”描述的是生成目标和解码过程，不代表网络结构一定不是 Transformer。

并行解码何时真正有收益

只有每次前向计算能最终确定足够多的正确位置，Parallel Decoding 才能抵消反复修订的成本。真正应该统计的不是“预测了多少 Token”，而是单位时间与算力交付了多少合格输出。

对同一负载至少记录：

• 去噪或编辑轮数；
• 每轮提议、提交、重新掩码、插入和删除的位置数；
• 模型前向次数和累计处理 Token；
• 首个有效局部结果时间与完整完成时间；
• Batch Size、序列长度、硬件、精度和 Runtime Revision；
• 结构化输出、代码与 Tool Call 的验收率；
• 显存、可测量能耗与单次合格结果成本。

近期研究探索了激进并行解码、Token-to-Token 编辑、多 Block 生成、按置信度提交，以及把扩散模型作为 Speculative Decoding Drafter。论文结果只适用于所用 Checkpoint、硬件、Batch、指标和验收标准，它们证明存在有价值的工作点，不证明存在可跨系统复制的固定加速倍数。这些额外推理属于一种专用测试时计算，应按合格输出核算，而不是只数推理或去噪步数。

与因果解码不同，掩码序列每轮之后未必形成稳定前缀。流式产品必须明确：展示可能变化的临时文本、只展示已提交 Block，还是等全部结束再输出。应度量修订频率和用户可见抖动，不能把 GPU 开始计算的时间当作首个有效输出时间。

长度、重掩码、编辑与缓存

自由文本没有预先给定的输出长度。DLM 必须通过固定 Canvas、长度预测器、EOS 策略、插入/删除操作或自回归 Block 边界解决长度问题。长度策略失败会造成截断、Padding 伪影或无效计算。

Remasking 也是一项策略：

1. 为未完成或允许修订的位置估计置信度；
2. 决定本轮提交哪些预测；
3. 可选地重新掩码低置信度位置；
4. 在有界条件下停止；
5. 对最终制品执行独立校验。

置信度并不天然校准为正确概率。Token 可能“自信地错”，局部置信度也可能忽略后续结构依赖。因此应按任务切片评测 Scheduler，并加入对抗格式。

缓存也比因果解码复杂，因为轮次之间可能同时改变多个位置。Block 模型可以恢复稳定前缀复用，其他架构则缓存部分计算或采用专用 Serving 策略。论文报告“支持缓存”不等于部署引擎已经实现，必须固定 Model-Runtime 组合核验。

结构化输出与 Agent 工作流

DLM 在快速草稿、检索辅助、编辑和非因果任务上具有潜力；Agent 控制循环还要求一般文本基准没有覆盖的能力：

• 精确的工具名与参数名；
• 合法的 Schema 与转义；
• 每次 Observation 后的因果状态更新；
• 有界重试与替代计划；
• 跨轮稳定标识；
• 正确终止与取消；
• 不产生未授权副作用。

一项 2026 年研究在选定 DLM 上观察到具身任务中的重复动作，以及 Tool Calling Benchmark 上的精确格式失败。这个结论受模型、Prompt、运行时和基准限制，但它给出了有价值的发布测试。另一些新工作则通过编辑和训练方案报告更强 Agent 结果。因此更合理的结论是：该方向仍未收敛，应实测确切候选。

约束解码可以改善语法，但合法 JSON 不等于正确或已授权的 Tool Call。Agent Harness 评测指南进一步说明了为什么执行策略与结果校验仍必须在模型之外。

建立等价评测

只有先固定应用契约，自回归与扩散候选才可公平比较。

evaluation:
  task_set_revision: "sha256:..."
  model_artifacts:
    autoregressive: "model@immutable-revision"
    diffusion: "model@immutable-revision"
  runtime_revisions:
    autoregressive: "runtime@commit"
    diffusion: "runtime@commit"
  workload:
    prompt_tokens: "记录分布"
    output_tokens: "记录分布"
    batch_sizes: [1, 8]
    concurrency: [1, 16]
  acceptance:
    answer_oracle: "任务专属"
    schema_validation: true
    tool_argument_validation: true
    side_effects: "benchmark 中禁用"

应统一 Prompt、Tokenizer 兼容输入、输出预算、硬件等级、预热规则和任务验收标准。如果两个制品的参数量、训练数据或指令微调差异很大，应明确这是产品比较，而不是纯解码范式比较。

下面的 Go 程序汇总标准化 Trial。它会拒绝非法样本，并报告验收率、P95 延迟和合格 Token 吞吐；这些指标仍不能单独代表质量。

package main

import (
	"errors"
	"fmt"
	"sort"
)

type Trial struct {
	Accepted  bool
	LatencyMS int
	Tokens    int
}

func summarize(trials []Trial) (float64, int, float64, error) {
	if len(trials) == 0 {
		return 0, 0, 0, errors.New("no trials")
	}
	latencies := make([]int, 0, len(trials))
	accepted := 0
	acceptedTokens := 0
	totalSeconds := 0.0
	for _, trial := range trials {
		if trial.LatencyMS <= 0 || trial.Tokens < 0 {
			return 0, 0, 0, errors.New("invalid trial")
		}
		latencies = append(latencies, trial.LatencyMS)
		totalSeconds += float64(trial.LatencyMS) / 1000
		if trial.Accepted {
			accepted++
			acceptedTokens += trial.Tokens
		}
	}
	sort.Ints(latencies)
	index := (95*len(latencies) + 99) / 100
	p95 := latencies[index-1]
	return float64(accepted) / float64(len(trials)),
		p95,
		float64(acceptedTokens) / totalSeconds,
		nil
}

func main() {
	trials := []Trial{
		{Accepted: true, LatencyMS: 420, Tokens: 96},
		{Accepted: false, LatencyMS: 310, Tokens: 80},
		{Accepted: true, LatencyMS: 510, Tokens: 112},
	}
	rate, p95, throughput, err := summarize(trials)
	if err != nil {
		panic(err)
	}
	fmt.Printf("acceptance=%.2f p95_ms=%d accepted_tokens_per_s=%.1f\n",
		rate, p95, throughput)
}

预期输出：

acceptance=0.67 p95_ms=510 accepted_tokens_per_s=167.7

还要按长输出、代码、多语言、精确字符串、Tool Call 与多轮恢复拆分失败，避免平均值掩盖结构性弱点。

生产选型清单

只有满足以下条件，才应让 DLM 承担某类生产负载：

1. 任务级验收率不低于约定基线；
2. 在真实 Batch 与并发分布下改善延迟或成本；
3. 长度、停止、流式输出和取消语义明确；
4. 结构化输出与 Tool Call 通过确定性校验；
5. Runtime 支持观测、过载处理和回滚；
6. 模型许可证与服务依赖符合部署要求；
7. 不支持的场景有因果模型或确定性流程回退。

混合工作负载下，路由可能比整体替换更合理。例如 DLM 负责编辑或候选选择，自回归模型负责精确工具参数。路由器本身也要评测，因为分类错误和回退成本可能吃掉全部收益。

常见失败模式

常见问题

扩散语言模型和图像扩散模型相同吗？

不相同。二者共享“逆转损坏过程”的思想，但语言具有离散符号、精确顺序、可变长度和语法敏感输出，需要专门的损坏、分词、长度与解码设计。

双向上下文会让 DLM 推理更好吗？

不一定。双向去噪有利于修订和填空，但推理质量仍由训练、解码、数据与评测决定。当前研究同时报告了收益和明显失败，尤其是在长程规划与精确 Tool 格式上。

DLM 可以流式输出吗？

可以输出已提交 Block 或临时文本，但中间结果可能继续变化。产品必须明确展示临时 Token、稳定片段还是最终制品，并把用户可见抖动纳入验收。

扩散语言模型支持 KV Cache 吗？

部分 Block 或优化型 DLM 已报告缓存复用，但因果模型的 KV Cache 不能原样迁移到所有扩散解码器。应核验具体 Model-Runtime 组合。

Agent 应该直接用 DLM 作为主策略模型吗？

只有轨迹级评测通过后才可以。需要测试计划切换、重复失败、工具选择、参数精度、终止与恢复。Memory 压缩或候选选择等混合角色，可能比完整控制循环更早具备上线条件。

参考资料

• 扩散语言模型综述
• 扩散语言模型在 Agent 工作流中的系统评测
• DMax 并行解码研究
• LLaDA2.1 Token Editing
• 扩散模型：前向加噪、采样与评测边界
• 大模型推理工程指南