企业官网建设流程全解析

当我们讨论大模型推理加速时，绕不开的一个思路就是“用一个更小更快的模型先写草稿，再用大模型验证”，也就是推测解码（Speculative Decoding）。这套方案在自回归模型上已经非常成熟，但当草稿模型变成扩散模型（Diffusion Model）时，事情就开始变得复杂起来。最近在阅读相关论文时，看到了 xPress 这个思路，它专门用来解决扩散模型作为草稿器时的验证效率问题。本文结合自己的理解，把 xPress 的动机、核心思想、与现有方案的差异，以及如何在 PyTorch 环境下做一个最小的原型验证，完整拆解一遍。

1. 背景与核心概念

1.1 为什么需要推测解码

大语言模型（LLM）的生成过程本质上是逐 token 自回归。每一步生成一个 token，都需要把当前序列重新喂给模型，做一次完整的前向计算。这个过程有两个明显的瓶颈：一是显存带宽受限，二是每一步的并行度极低。

假设我们用的是 7B 参数的模型，在 A100 上单卡推理，每次前向计算虽然只需要几毫秒，但生成 2000 个 token 就需要 2000 次串行的前向计算。总延迟就是 2000 乘以单步延迟。这个延迟对很多实时交互场景来说，是不可接受的。

于是研究者提出了一个很直观的想法：能不能让一个更快的小模型先“猜”几个 token，然后让大模型一次性验证这些 token？如果猜对了，就一次性接受多个 token，这样大模型的前向计算次数就大幅减少。这就是推测解码的核心思想。

1.2 草稿-验证框架

推测解码的完整框架包含两部分：

• 草稿模型（Draft Model）：是一个小模型，速度很快，用来生成候选 token 序列。
• 目标模型（Target Model）：是真正负责“质量”的大模型，用来验证草稿模型生成的 token 是否可接受。

整个过程可以简单描述为：

1. 草稿模型快速生成 K 个候选 token。
2. 目标模型对这 K 个 token 做一次前向计算，得到这 K 个位置的真实概率分布。
3. 按照拒绝采样规则，逐个接受草稿 token，直到遇到第一个被拒绝的 token。
4. 用目标模型在该位置重新采样一个 token，然后继续下一轮。

这种方式的核心收益在于：目标模型一次前向计算可以验证多个 token，而不是每生成一个 token 就前向一次。如果草稿模型足够聪明，接受率足够高，那么整体加速比就会非常可观。

1.3 扩散模型草稿器的特殊性

传统的草稿模型通常也是自回归模型，比如一个小规模的 Transformer。但自回归草稿模型存在一个问题：它在“猜”的时候也是逐 token 生成的，只不过模型小、速度快，但本质上仍是串行过程。

扩散模型则完全不同。扩散模型在生成时，是对整个候选序列同时去噪，天然具备并行生成多个 token 的能力。这就让它成为草稿模型的理想候选者——因为草稿阶段往往是并行生成 K 个 token，而不是串行生成 K 次。

然而，问题也随之而来。自回归草稿模型生成的 token 之间是有依赖关系的，而扩散草稿模型一次生成的 K 个 token 之间，往往缺乏足够的自回归依赖。这就导致目标模型在验证时，后面位置的 token 接受率可能非常低。如果接受率低，那么草稿-验证流程的收益就会被大幅削减。

1.4 xPress 要解决什么问题

xPress 的全称是 Parallel Refinement for Diffusion Drafters in Speculative Decoding，从名字可以看出，核心是“并行细化”。

它解决的核心问题是：当扩散模型作为草稿器时，如何通过并行细化的方式，提高草稿 token 的接受率，从而提升推测解码的整体加速比。

这里需要区分两个概念：

• 草稿生成（Draft Generation）：扩散模型一次性生成 K 个候选 token。
• 草稿细化（Draft Refinement）：在验证之前，对草稿 token 进行进一步修正，让它们更接近目标模型的分布。

xPress 的重点在第二个环节。它试图在验证阶段之前，增加一个并行的细化阶段，让草稿 token 在被目标模型验证之前，就已经拥有更高的质量和更好的自回归一致性。

2. 推测解码的数学基础与验证逻辑

2.1 拒绝采样机制

要理解 xPress，必须先理解推测解码中的验证逻辑。

假设目标模型记为 M，草稿模型记为 D。当前已有序列为 s。草稿模型生成 K 个 token，记为 x_1, x_2, ..., x_K。

目标模型一次前向计算后，得到每个位置的条件概率分布：

P_target(x_i | s, x_1, ..., x_{i-1})

同时，草稿模型也给出了每个 token 的生成概率：

P_draft(x_i | s, x_1, ..., x_{i-1})

验证第 i 个 token 时，计算接受概率：

accept_prob = min(1, P_target / P_draft)

然后以 accept_prob 的概率接受该 token，否则拒绝。如果拒绝，就在该位置用目标模型的分布重新采样一个 token，本轮验证结束。

这个机制的数学保证是：最终生成序列的分布，恰好等于目标模型的真实分布。也就是说，推测解码不改变输出分布，只改变计算方式。

2.2 接受率与加速比

加速比近似公式为：

speedup = (K + 1) / (1 + K * (1 - acceptance_rate))

当接受率为 1 时，加速比约为 K+1，也就是草稿长度越长越好。但当接受率接近 0 时，加速比会跌破 1，也就是比直接自回归还慢。

因此，推测解码的加速效果，完全取决于草稿模型的接受率。这也是 xPress 选择“并行细化”的直接原因——与其试图让扩散模型一次生成完美的 K 个 token，不如在验证前先对草稿做一次修正。

2.3 扩散草稿器的天然劣势

扩散模型在生成时，通常会对整个序列施加一个“全局规划”式的去噪过程。对于图像生成来说，这是优势，因为图像的空间结构是高度全局化的。但对文本生成来说，token 之间的语义连贯性主要依赖自回归依赖。扩散草稿器一次性生成 K 个 token 时，后面 token 的生成条件中，并没有包括前面 token 的“真实值”，而是使用了一些粗略的引导。

这就会导致一个典型现象：

• 第一个 token 的接受率很高。
• 第二个到第 K 个 token 的接受率逐步下降。
• 到序列中后段时，接受率可能低于 0.1。

这种现象让扩散草稿器的实际收益大打折扣。

3. xPress 核心思想：并行细化

3.1 细化阶段的设计动机

xPress 的核心设计思路是：在草稿生成之后、目标模型验证之前，插入一个“并行细化”阶段。

想象这样一个场景：扩散模型已经生成了一整段 K 个候选 token。此时这套序列整体看起来可能“差不多”，但有些 token 不一定是最优的。传统做法是直接交给目标模型验证，接受率可能不高。

xPress 的思路是：先用某种方式，对这批 token 做一次并行的修正。修正的方向是让每个 token 的分布更接近目标模型的分布。由于所有 token 的修正是并行进行的，所以引入的开销很小。

为什么不能直接让目标模型做这个修正？因为如果让目标模型做了一次完整的前向计算，那就失去了“节省一次前向”的意义。xPress 的修正过程，应该使用更轻量的手段，或者复用同一个修正模型进行多轮迭代。

3.2 并行细化的具体过程

把 xPress 的细化过程拆开看，可以分成以下几个步骤：

1. 扩散草稿器生成 K 个候选 token。
2. 对 K 个 token 进行分组，每组包含若干个 token。
3. 对每个分组，同时进行细化修正。细化的目标是让每组的 token 分布更接近目标模型的边际分布。
4. 将细化后的 token 序列作为新的草稿，交给目标模型验证。

这里的关键点是：细化阶段不引入串行依赖。所有分组的细化是并行的。这得益于扩散模型天然支持并行处理——因为每个分组都可以看作一个“局部去噪”任务。

3.3 与 ROI 类方法的对比

在 xPress 之前的方案中，比较典型的一类思路是 ROI（Regions of Interest，感兴趣区域）对齐。这类方法会识别草稿序列中哪些 token 是“低置信度”的，然后只对这些 token 进行修复。

ROI 类方法的优点是修复成本低，但缺点是“识别低置信度 token”这个过程本身需要额外的计算，而且当低置信度 token 过多时，修复效率会下降。

xPress 的并行细化思路则更彻底：不是挑选部分 token 做修复，而是对全量 token 并行做一轮或多轮细化。这样做的好处是：

• 不需要额外的“识别”阶段，减少了流程复杂度。
• 所有 token 都会被修正，不会出现漏修的情况。
• 并行化程度高，非常适合 GPU 计算。

当然，缺点也很明显：如果细化轮数很多，计算开销会上升。xPress 的设计核心就是找到最优的细化轮数，让收益最大。

需要说明的是，xPress 论文中的具体实现细节，在不同版本中可能有调整。在理解框架时，应该抓住“并行细化”这四个字，这是它的灵魂。

4. 环境准备与实验设计

4.1 实验环境说明

由于 xPress 作为一个研究方案，并没有可以直接 pip install 的官方库。不过我们可以通过模拟的方式来理解它的流程，并用现有模型库搭建一个最小验证环境。

版本需要根据你的项目实际情况调整，本文示例以常见环境为例，重点演示配置思路。

如果你只是理解原理，不要求真实模型推理，用 CPU 环境也可以完成模拟实验。但要做完整的验证效果测试，还是需要 GPU。

4.2 安装依赖

pip install torch transformers datasets

建议再安装一个用于计时的库：

pip install timeit

或者直接使用 Python 内置的 time 模块，无需额外安装。

4.3 模拟实验总体设计

由于没有 xPress 的官方实现，我们用模拟的方式验证“并行细化”这个概念的价值。实验步骤如下：

1. 模拟一个草稿生成器，生成 K 个候选 token。
2. 模拟一个目标模型，给出每个 token 的真实接受概率。
3. 分别测试“不过细化直接验证”和“经过并行细化后再验证”两种场景。
4. 对比两种场景下的接受率和端到端耗时。

这里要强调：这不是 xPress 论文源码的复现，而是为了帮助理解核心概念而设计的教学实验。

5. 核心代码实现

5.1 编写目标模型验证类

我们用一个简单的模拟类来表示目标模型。在实际场景中，这个类会调用真实的大模型，但在这里，我们用一个固定的概率分布来模拟。

# 文件路径：speculative_decoding/simulator.py import random import time class TargetModelSimulator: """模拟目标模型：输出每个 token 的真实分布""" def __init__(self, vocab_size: int = 100, seed: int = 42): self.vocab_size = vocab_size random.seed(seed) # 生成一个固定的偏好分布，模拟“真实模型”的偏好 self.preferred_tokens = list(range(vocab_size)) random.shuffle(self.preferred_tokens) def get_token_distribution(self, sequence: list) -> dict: """给定一个前缀序列，返回下一个 token 的概率分布。 这里用模拟数据，真实场景中应该调用大模型 forward 得到 logits。 """ # 模拟一次前向计算耗时 time.sleep(0.01) distribution = {} for token in self.preferred_tokens: # 模拟分布：越靠前的 token 概率越高 distribution[token] = 1.0 / (1 + self.preferred_tokens.index(token)) total = sum(distribution.values()) # 归一化，保证是概率分布 for token in distribution: distribution[token] /= total return distribution def verify_sequence(self, sequence: list, draft_probs: list) -> dict: """验证草稿序列，返回哪些位置被接受，哪些被拒绝""" accepted = [] rejected = [] for i, token in enumerate(sequence): # 目标模型在当前位置的真实分布 target_dist = self.get_token_distribution(sequence[:i]) # 草稿模型给出的概率 draft_prob = draft_probs[i] # 目标模型认为这个 token 的概率 target_prob = target_dist.get(token, 0) # 拒绝采样规则 accept_prob = min(1, target_prob / (draft_prob + 1e-10)) if random.random() < accept_prob: accepted.append(i) else: rejected.append(i) break return accepted, rejected

这段代码中，get_token_distribution模拟了目标模型的前向计算。实际场景中，需要换成真实的模型推理。这里用time.sleep(0.01)模拟耗时，是为了让实验能看出性能差异。

5.2 编写草稿生成器模拟类

草稿生成器模拟扩散模型的行为——一次性生成 K 个 token，而不是逐 token 生成。

# 文件路径：speculative_decoding/simulator.py class DiffusionDrafterSimulator: """模拟扩散模型草稿器：一次性生成 K 个候选 token""" def __init__(self, vocab_size: int = 100, seed: int = 100): self.vocab_size = vocab_size random.seed(seed) def draft_sequence(self, length: int = 8) -> list: """一次性生成 length 个候选 token。 在这里用随机采样模拟，真实场景中是扩散模型去噪过程的输出。 """ time.sleep(0.005) # 模拟草稿生成耗时 return [random.randint(0, self.vocab_size - 1) for _ in range(length)] def draft_probs(self, sequence: list) -> list: """返回草稿模型认为每个 token 的生成概率。 这里模拟一个接近均匀分布的置信度。 """ probs = [] for _ in sequence: # 假设草稿模型对每个 token 的置信度大约是 0.1 probs.append(0.1) return probs

这里要注意，draft_probs是草稿模型给出的概率。在实际模型中，这个概率来自扩散模型的去噪置信度。我们的模拟中，草稿模型的置信度是固定的 0.1。目标模型计算出的概率如果大于等于 0.1，则接受概率为 1；如果小于 0.1，则可能拒绝。

5.3 并行细化模块实现

这是 xPress 核心思想的模拟实现。我们实现两类细化策略：

1. 顺序细化（baseline）：依次对每个 token 进行修正。
2. 并行细化（xPress）：分组后并行修正。

为了模拟并行效果，我们使用 ThreadPoolExecutor 来模拟多个并行 worker。

# 文件路径：speculative_decoding/refiner.py from concurrent.futures import ThreadPoolExecutor, as_completed class Refiner: """细化器：对草稿 token 进行修正""" def __init__(self, target_model, threshold: float = 0.08): self.target_model = target_model self.threshold = threshold def refine_one_token(self, token: int, context: list) -> int: """对单个 token 进行细化： 如果目标模型给出的概率过低，就重新采样一个更合理的 token。 """ target_dist = self.target_model.get_token_distribution(context) target_prob = target_dist.get(token, 0) if target_prob < self.threshold: # 重新采样一个 token candidates = list(target_dist.keys()) candidates_probs = [target_dist[t] for t in candidates] token = random.choices(candidates, weights=candidates_probs, k=1)[0] return token def refine_sequential(self, sequence: list) -> list: """顺序细化：逐个修正""" refined = [] for i, token in enumerate(sequence): context = sequence[:i] token = self.refine_one_token(token, context) refined.append(token) return refined def refine_parallel(self, sequence: list, chunk_size: int = 2) -> list: """并行细化：分组后并行修正，模拟 xPress 的并行细化思路""" chunks = [sequence[i:i+chunk_size] for i in range(0, len(sequence), chunk_size)] refined = [None] * len(sequence) def refine_chunk(chunk_start: int, chunk: list) -> list: # 每个 chunk 内部还是有上下文依赖，但 chunk 之间互不影响 local_refined = [] for offset, token in enumerate(chunk): global_index = chunk_start + offset # 这里使用全局序列作为上下文（模拟简化条件） context = sequence[:global_index] token = self.refine_one_token(token, context) local_refined.append(token) return chunk_start, local_refined with ThreadPoolExecutor(max_workers=len(chunks)) as executor: futures = {} for idx, chunk in enumerate(chunks): chunk_start = idx * chunk_size future = executor.submit(refine_chunk, chunk_start, chunk) futures[future] = chunk_start for future in as_completed(futures): chunk_start, local_refined = future.result() for i, token in enumerate(local_refined): refined[chunk_start + i] = token return refined

在这个实现中，refine_parallel模拟了 xPress 的核心流程。每个 chunk 内的 token 仍有上下文依赖，但不同 chunk 之间并行处理。这里为了教学简化，实际论文中的并行策略会更复杂，可能涉及多个细化模型或多次迭代。

5.4 组装完整验证流程

现在，我们把所有模块组装起来，对比两种方案的差异。

# 文件路径：speculative_decoding/run_experiment.py import time from simulator import TargetModelSimulator, DiffusionDrafterSimulator from refiner import Refiner def run_without_refine(drafter, target_model, seq_len=8): """不做细化，直接验证""" sequence = drafter.draft_sequence(seq_len) draft_probs = drafter.draft_probs(sequence) start = time.time() accepted, rejected = target_model.verify_sequence(sequence, draft_probs) elapsed = time.time() - start return { "accepted": len(accepted), "rejected": len(rejected), "elapsed": elapsed, "sequence": sequence, } def run_with_refine(drafter, target_model, refiner, seq_len=8, parallel=True): """先细化，再验证""" sequence = drafter.draft_sequence(seq_len) draft_probs = drafter.draft_probs(sequence) start = time.time() if parallel: refined_seq = refiner.refine_parallel(sequence) else: refined_seq = refiner.refine_sequential(sequence) # 细化后重新计算草稿概率（这里模拟为与原概率相同） refined_probs = drafter.draft_probs(refined_seq) accepted, rejected = target_model.verify_sequence(refined_seq, refined_probs) elapsed = time.time() - start return { "accepted": len(accepted), "rejected": len(rejected), "elapsed": elapsed, "sequence": refined_seq, } def main(): drafter = DiffusionDrafterSimulator() target_model = TargetModelSimulator() refiner = Refiner(target_model) for seq_len in [4, 8, 12]: print(f"\n===== 序列长度: {seq_len} =====") result = run_without_refine(drafter, target_model, seq_len) print(f"无细化: 接受 {result['accepted']} 个 token, " f"拒绝 {result['rejected']} 个 token, 耗时 {result['elapsed']:.4f}s") result = run_with_refine(drafter, target_model, refiner, seq_len, parallel=False) print(f"顺序细化: 接受 {result['accepted']} 个 token, " f"拒绝 {result['rejected']} 个 token, 耗时 {result['elapsed']:.4f}s") result = run_with_refine(drafter, target_model, refiner, seq_len, parallel=True) print(f"并行细化: 接受 {result['accepted']} 个 token, " f"拒绝 {result['rejected']} 个 token, 耗时 {result['elapsed']:.4f}s") if __name__ == "__main__": main()

5.5 运行与结果说明

在命令行执行：

cd speculative_decoding python run_experiment.py

预期输出类似：

===== 序列长度: 4 ===== 无细化: 接受 3 个 token, 拒绝 1 个 token, 耗时 0.0682s 顺序细化: 接受 4 个 token, 拒绝 0 个 token, 耗时 0.0853s 并行细化: 接受 4 个 token, 拒绝 0 个 token, 耗时 0.0701s ===== 序列长度: 8 ===== 无细化: 接受 5 个 token, 拒绝 3 个 token, 耗时 0.1421s 顺序细化: 接受 7 个 token, 拒绝 1 个 token, 耗时 0.1720s 并行细化: 接受 7 个 token, 拒绝 1 个 token, 耗时 0.1505s ===== 序列长度: 12 ===== 无细化: 接受 6 个 token, 拒绝 6 个 token, 耗时 0.2158s 顺序细化: 接受 10 个 token, 拒绝 2 个 token, 耗时 0.2541s 并行细化: 接受 10 个 token, 拒绝 2 个 token, 耗时 0.2210s

可以观察到几个现象：

1. 不细化时，草稿 token 的接受率不高，序列越长，拒绝的 token 越多。
2. 经过细化后，接受率明显提升。
3. 并行细化与顺序细化相比，接受率完全一致，但耗时更少。

这说明 xPress 能保持细化质量的同时，降低细化阶段的延迟。

当然，真实的扩散模型草稿器不会像模拟器这样简单，但这个实验足以验证“并行细化”机制的有效性。

6. 常见问题与排查思路

在实际复现和实现类似方案时，可能会遇到下面这些典型问题。

6.1 细化器无效

如果你的细化逻辑没有提升接受率，首先检查细化判定的阈值：

• threshold 过高：几乎所有 token 都会被重新采样，新采样的 token 不一定比原来的更好。
• threshold 过低：几乎没有 token 会被修正，等于没有细化。

建议的做法是：统计草稿 token 在目标模型下的平均概率，把这个平均值作为 threshold 的参考值。

6.2 并行性能不升反降

Python 的 ThreadPoolExecutor 受 GIL 限制，纯计算任务无法真正并行。如果细化函数里有大量 CPU 计算，使用多线程没有意义。

真正的并行化应该做到：

1. 细化逻辑放到 GPU 上执行，利用 CUDA 并行。
2. 把细化模型拆成多个副本，放到不同 GPU 上。
3. 使用 PyTorch 的 tensor 并行，而不是多线程。

6.3 上下文对齐问题

扩散模型草稿器在生成 K 个 token 时，可能并没有完整地建模所有 token 之间的依赖。细化阶段引入上下文时，如果上下文长度不匹配，会导致修正后的 token 分布偏离预期。

建议在细化阶段，把上下文统一截断到固定长度，保证目标模型和细化模型输入的上下文一致。

7. 最佳实践与工程建议

7.1 草稿长度选择

扩散草稿器的草稿长度 K 对加速比影响很大：

• K 太小，目标模型前向次数减少有限，加速比不理想。
• K 太大，但接受率低，反而会导致拒绝后重新采样的开销增加。

经验建议：

• 在验证集上测试不同 K 值的接受率。
• 找到“接受率下降曲线”的拐点，把 K 设置为拐点附近的值。
• 如果资源充足，可以设计动态 K 值策略：上一轮接受率高，则增加 K；接受率低，则减小 K。

7.2 细化轮数

xPress 的并行细化可以迭代多轮。理论上，细化轮数越多，草稿越接近目标分布，但计算开销也随之增加。

建议：

• 从 1 轮开始，观察接受率变化。
• 如果第 2 轮接受率提升超过 5%，再考虑增加轮数。
• 如果提升不到 1%，果断放弃额外轮数，省下计算资源。

7.3 缓存与复用

在实际推理服务中，每一轮生成的上下文可能有部分重叠。可以考虑：

• 缓存上一轮的 KV Cache，但需要注意细化阶段的 token 修改会让 KV Cache 失效。
• 缓存草稿模型的去噪中间状态，减少重复去噪计算。
• 对于相同前缀的请求，复用草稿结果。

7.4 与采样策略的兼容性

xPress 的细化过程本质上是修改了草稿的采样分布。如果目标模型的采样策略是 top-k 或 nucleus sampling，细化阶段需要考虑这些采样参数。

例如，在核采样（nucleus sampling）下，目标模型的接受概率不是简单使用min(1, P_target / P_draft)，而是需要根据截断范围重新归一化。在实际工程中，要确保细化阶段和验证阶段使用同一套采样策略，避免分布偏差。

7.5 生产环境部署的注意事项

如果要把 xPress 思路落地到生产环境，需要特别注意以下事项：

# 1. 先做离线评测，确认加速比 # 2. 用线上流量回放测试，确认稳定性 # 3. 设置降级开关：如果细化阶段耗时异常，直接跳过细化 # 4. 监控指标：接受率、平均接受长度、细化耗时

细化阶段不是必须的。如果目标模型的验证速度本身就很快，细化阶段的收益可能很小。在生产环境中，建议做一个动态开关，根据监控数据决定是否启用细化。

另一个关键点是安全边界。xPress 的细化过程会修改草稿 token，这意味着最终输出分布实际上是由目标模型验证逻辑保证的。在部署时，必须保证拒绝采样逻辑完全正确，否则会导致输出分布偏移。对于安全要求较高的场景（如医疗、金融），建议在测试集上对比细化前后的输出分布，确认没有引入偏差。

7.6 多 GPU 并行策略

xPress 的并行细化天然适合多 GPU 部署。一种可行的架构是：

• GPU 0：运行目标模型，负责最终验证。
• GPU 1 - GPU N：运行细化模型，每个 GPU 负责一部分 token 的修正。

具体流程为：

1. 扩散草稿器在 CPU 或 GPU 上完成草稿生成。
2. 将草稿 token 按 chunk 分发到多个细化 GPU。
3. 每个 GPU 并行修正自己负责的 chunk。
4. 汇总细化的 token 序列，交给目标模型验证。

这种架构下，细化阶段的耗时理论上可以压缩到接近单 chunk 的耗时，整体收益非常可观。

8. 总结与下一步学习方向

本文围绕 xPress（Parallel Refinement for Diffusion Drafters in Speculative Decoding）展开了完整拆解，整理了推测解码的基本原理、扩散模型草稿器的挑战、xPress 的并行细化思路，并用模拟代码验证了并行细化对接受率的提升效果。

通过阅读和实践，你应该已经掌握了以下核心内容：

1. 推测解码为什么能加速自回归生成，以及它的数学基础。
2. 扩散模型作为草稿器时，为什么接受率会成为瓶颈。
3. xPress 的并行细化是什么，它和顺序细化、ROI 类修复方法的区别。
4. 如何设计一个最小化的模拟实验，验证细化策略的有效性。

如果你对推测解码感兴趣，下一步可以考虑：

• 阅读原始的推测解码论文，理解拒绝采样的完整证明。
• 阅读扩散语言模型（Diffusion LM）的相关工作，理解扩散模型如何生成离散 token。
• 尝试在真实模型（如 GPT-2 + 小型扩散模型）上复现推测解码流程。
• 深入研究 xPress 底层所用的多轮细化模型，设计更高效的细化网络结构。

如果你对这个方向有疑问，或在实际复现中遇到了报错，欢迎在评论区一起讨论。