Serving Masked Diffusion LLMs：基于真实硬件的性能刻画与服务设计原则

摘要：掩码扩散语言模型（dLLMs）理论上可通过并行去噪多 Token 实现比自回归（AR）模型更快的文本生成。然而，当前所有 dLLM 服务系统均未在真实并发负载下实测其行为特征——这导致 AR 模型沿用的服务假设（如请求延迟连续性、GPU 计算主导瓶颈、batch size 与质量负相关等）被不加验证地迁移至 dLLMs，存在严重设计偏差。本文以 LLaDA-8B-Instruct + D2F LoRA 在单张 NVIDIA H200 GPU 上为基准，结合 GSM8K 和 HumanEval 实测，揭示三大关键事实：（1）请求难度呈离散阶梯状分布（共 11 个固定去噪步数等级），且无法在生成前预测；（2）短预算（<320 tokens）基准严重低估服务延迟方差；（3）单请求端到端耗时中仅 24% 为 GPU 计算，76% 为 CPU 侧调度开销；批处理的核心收益并非计算复用，而是摊销该开销——batch size=16 时吞吐提升达 16.0×。我们进一步论证：在合理假设下，dLLM 的输出质量不随 batch size 增大而下降（实测 GSM8K 准确率稳定在 74–76%）；并推导出 Poisson 到达场景下固定填充同步批处理（fixed-fill synchronized batching）的 batch timeout 最优规则。结论直指本质：dLLM 服务必须将并行粒度下沉至「每一步去噪」，其 admission control 与 request eviction 的交互逻辑，与 AR 模型根本不同。

背景动机：为什么不能把 vLLM 直接套在 dLLM 上？

当前生产环境中的 LLM 推理服务栈（如 vLLM、TGI、SGLang）几乎全部围绕自回归范式构建：token-by-token 解码、KV Cache 动态增长、prefill/decode 阶段分离、PagedAttention 内存管理、以及基于 token 吞吐（tok/s）和首 token 延迟（TTFT）的 SLA 设计。当社区开始尝试部署新型掩码扩散语言模型（masked diffusion LLMs, dLLMs）时，一个危险但普遍的倾向是——直接复用现有 AR serving infra，并仅替换模型权重与 tokenizer。

这种“模型即插件”思路在 dLLM 场景下是技术债务的温床。原因在于：dLLM 的执行语义与 AR 模型存在范式级差异：

AR 模型是 sequential state machine：每个 token 依赖前序所有 token，forward pass 严格串行；
dLLM 是 parallel iterative solver：一次 forward pass 对整段 masked sequence 执行全量去噪（例如：输入 [MASK, MASK, ..., MASK] → 输出 ["The", "quick", "brown", ...]），迭代步数（denoising steps）决定收敛精度与延迟，但各步之间无 token 级依赖。

这意味着：vLLM 的 PagedAttention 缓存机制对 dLLM 几乎无意义（无 KV 增长）；TGI 的 continuous batching 在 step-level 并行下可能引入非必要同步开销；而基于“平均 TTFT”设计的 autoscaler，在面对离散步数跳跃时会持续误判容量水位。

本文工作正是对这一盲区的首次硬核填补：拒绝假设，拥抱测量。作者没有停留在理论加速比或单请求 benchmark，而是将 LLaDA-8B-Instruct（带 D2F LoRA adapter）真机部署于 H200 GPU，模拟真实 API 流量（Poisson 到达 + 并发请求），系统性拆解 wall-clock time 构成、量化步数分布、检验 batch size 对 accuracy 的影响——所有结论均锚定在可观测、可复现的硬件行为上。

核心技术：dLLM Serving 的三支柱发现与实现启示

1. 请求难度离散化：告别“平均步数”，拥抱“步数桶”

dLLM 的去噪步数（如 16/32/64）常被当作超参配置，但本文首次证实：同一模型+同一 prompt 下，不同请求的实际收敛步数并非连续变量，而是落入 11 个固定离散等级（178 + 29k 组合）。更关键的是——没有任何前置特征（prompt length、token entropy、logit variance 等）能在生成前可靠预测其所属等级（R² ≤ 0.150）。

这对运维意味着什么？
→ 传统基于“平均步数”的 capacity planning 失效。若按均值 32 步规划，实际 64 步请求将导致 GPU 队列堆积、P99 延迟飙升。
→ 必须采用 step-aware admission control：在请求入队时，根据其预估最大步数（而非均值）分配 slot，并预留 buffer。

yaml

# 示例：K8s Deployment 中为 dLLM 服务注入 step-aware 资源约束
apiVersion: apps/v1
kind: Deployment
metadata:
  name: dllm-server-h200
spec:
  template:
    spec:
      containers:
      - name: inference
        image: ai-ear/dllm-serving:v0.3.1
        resources:
          limits:
            nvidia.com/gpu: 1
            # 关键：显式声明最大步数预算（对应 worst-case latency）
            memory: 80Gi  # H200 显存 + CPU 内存协同需求
        env:
        - name: MAX_DENOISE_STEPS
          value: "64"  # 不是 32！必须按 P99 步数桶上限设
        - name: STEP_BUCKETING_ENABLED
          value: "true"

2. GPU 计算非瓶颈：CPU Dispatch 开销主导延迟

测量显示：单请求端到端耗时中，GPU kernel execution 仅占 24%，其余 76% 为 CPU 侧开销——包括 TensorRT-LLM 的 step scheduler dispatch、LoRA adapter 加载/卸载、masked sequence padding/reordering、以及 Python-to-C++ bridge 延迟。

这颠覆了 AR serving 的直觉（AR 中 GPU 占比常 >60%）。对 dLLM 而言，批处理的核心价值不是“计算并行”，而是“dispatch 摊销”：一次 dispatch 触发 N 个请求的同一 denoising step forward pass，使 CPU 开销分摊至每个请求。

实测数据极具冲击力：

batch size=1（per-request dispatch）：吞吐 = X req/s
batch size=16：吞吐 = 16.0×X req/s

注意：这不是线性 scaling，而是因 dispatch 开销被极致摊销所致。这也解释了为何 dLLM 的 batch size 效益曲线比 AR 更陡峭。

3. 质量稳定性：batch size ≠ quality decay

AR 模型中，增大 batch size 常伴随 attention mask 稀疏化、KV cache 截断等副作用，导致质量轻微下降。但本文从结构上论证：dLLM 的每步去噪是独立的、全序列级别的 transformation，只要满足三个假设——
① LoRA adapter 参数在 batch 内共享（无 per-request 微调）；
② masked token positions 保持 batch 内一致（需 padding 对齐）；
③ step scheduler 保证所有请求同步进入/退出同一 denoising step；
→ 则 batch size 扩展不引入任何近似误差。

实测 GSM8K 准确率验证了该结论：

batch size=1：74.2%
batch size=16：75.8%
batch size=32：76.1%

波动 <0.5%，属统计噪声范围。这意味着：dLLM 的 SLO 可以安全地以 throughput 为首要优化目标，无需在 latency/quality 间做权衡。

运维建议：面向 dLLM 的 K8s/SRE 实践清单

拒绝“通用推理 Pod”模板
不要复用 vLLM/TGI 的 Helm chart。dLLM Pod 必须显式声明 MAX_DENOISE_STEPS、STEP_BUCKET_COUNT、DISPATCH_OVERHEAD_ESTIMATE_MS 等环境变量，并通过 initContainer 预热 LoRA adapter。
重构 HorizontalPodAutoscaler（HPA）指标
放弃 cpuUtilization 或 avg_latency。应采集自定义指标：
- dllm_step_queue_length（等待进入下一步的请求数）
- dllm_step_completion_rate_per_second（每秒完成的 step 数）
- dllm_dispatch_overhead_ms_p95
  HPA 触发阈值应基于 step_completion_rate 与 max_steps 的乘积（即潜在最坏延迟）。

设计 step-level timeout 与 eviction 策略

python

# 伪代码：dLLM admission controller 的核心逻辑
def admit_request(request):
    # Step 1: 根据 prompt 特征粗分类（非预测！仅为桶索引）
    bucket = coarse_step_bucketing(request.prompt)
    # Step 2: 查询当前 GPU 的剩余 step-capacity（考虑 worst-case bucket）
    remaining_steps = gpu_capacity - sum(max_steps_in_queue)
    if remaining_steps < BUCKET_MAX_STEPS[bucket]:
        return REJECT_WITH_RETRY_AFTER(500ms)  # 短暂退避，非长重试
    # Step 3: 分配 slot，并记录其 step bucket
    queue.append((request, bucket))

监控告警必须覆盖“step 级别”
Prometheus exporter 需暴露：
- dllm_step_latency_seconds{step="16",bucket="high"}
- dllm_dispatch_overhead_seconds_count
- dllm_gpu_compute_ratio（用于识别是否进入新硬件瓶颈区）
  告警规则示例：dllm_dispatch_overhead_seconds_count > 10000 → 检查 Python GIL 或 LoRA 加载路径。

延伸阅读：超越论文的技术纵深

硬件适配层：H200 的 141GB/s HBM3 带宽对 dLLM 至关重要——因其每步需加载全量 embedding + LoRA delta（远大于 AR 的单 token logits）。若迁移到 A100，需重新校准 MAX_DENOISE_STEPS，因 memory bandwidth 成为新瓶颈。
与 Scheduling 的耦合：Kubernetes 默认的 BestEffort QoS 对 dLLM 危险。必须使用 Guaranteed + memory.limit 严格隔离，否则 dispatch jitter 将放大为 step-level timeout cascade。
未来演进方向：本文聚焦 single-GPU。多卡 dLLM serving 的挑战在于 step synchronization —— NCCL AllReduce 在每步结束时的阻塞成本可能吞噬并行收益。值得关注的研究方向：异步 step pipeline（类似 DeepSpeed Ulysses）、step-aware tensor parallelism。

结语：LLM serving 正从“AR 一统天下”迈入“多范式共存”时代。dLLM 不是 AR 的变体，而是一种需要全新基础设施原语的新物种。它的价值不在“取代 AR”，而在“补全 AR 的短板”——对低延迟、高吞吐、确定性质量的苛刻场景（如实时游戏 NPC、金融高频决策摘要），dLLM 提供了不可替代的工程选项。作为 SRE，我们的责任不是争论范式优劣，而是构建能诚实承载每一种范式的、可测量、可推理、可演进的生产系统。本文，正是那块不可或缺的基石。

Serving Masked Diffusion LLMs：基于真实硬件的性能刻画与服务设计原则 ​

背景动机：为什么不能把 vLLM 直接套在 dLLM 上？ ​

核心技术：dLLM Serving 的三支柱发现与实现启示 ​

1. 请求难度离散化：告别“平均步数”，拥抱“步数桶” ​

2. GPU 计算非瓶颈：CPU Dispatch 开销主导延迟 ​

3. 质量稳定性：batch size ≠ quality decay ​

运维建议：面向 dLLM 的 K8s/SRE 实践清单 ​

延伸阅读：超越论文的技术纵深 ​