当前位置：首页 > news >正文

推理服务为什么一上批量采样就开始输出不可复现：从 RNG State 到 Per-Request Stream 的工程实战

news 2026/5/25 9:09:08

一、批量采样上线后，回归测试开始大面积失败

在生产环境部署 LLM 推理服务时，批量采样（Batch Sampling）是提升吞吐的核心手段。当多个请求被拼接进同一张量后，一次前向传播即可产出多个结果，GPU 利用率通常能提升 30% 到 50%。然而，不少团队在刚刚开启这一优化后就发现，同一 Prompt 的多次调用返回了不同文本，缓存命中率骤降，连回归测试也变得 flaky。

图1：推理服务的批量采样架构

这种非确定性看似是模型固有的随机性，实则往往源自 RNG State 在请求间的隐性共享。批量采样把独立请求塞进同一批次，而底层 CUDA Kernel 中的随机数生成器如果未做隔离，就会导致 Stream 相互污染。

二、问题拆解：为什么批量采样会泄漏随机状态

2.1 单请求采样与批量采样的 RNG 差异

单请求场景下，每个推理调用拥有独立的 RNG Seed，输出稳定可复现。进入批量采样后，vLLM、TensorRT-LLM 等框架会把多个 Sequence 合并为一个 Batch，调用一次sample()Kernel。此时若框架复用同一条 CUDA RNG Stream，后一个请求会消费前一个请求留下的随机状态，结果自然发生漂移。

⚠️ 关键误区：很多工程师认为设置temperature=0就能消除随机性。实际上，即便 Greedy Decode，部分框架在 Top-K 处理时仍会触及 RNG，只是概率分布被削峰后差异变小。

2.2 状态泄漏的三条路径

泄漏路径	触发条件	影响程度
同 Stream 顺序消费	Batch 内 Sequence 共享 RNG	高
Kernel Launch 异步重叠	不同 Batch 间 Stream 复用	中
Checkpoint 恢复丢 Seed	服务重启后 Seed 未持久化	低

[外链图片转存中…(img-UJuC8hbD-1779668516321)]

图2：RNG Stream 在 Batch 内的共享模型

2.3 缓存失效与测试漂移的连锁反应

输出不可复现直接击穿 Prompt Cache 的命中假设。当两次相同输入得到不同输出时，基于 Hash 的语义缓存会判定为未命中，导致后端重复计算。回归测试更是首当其冲，同一用例在不同运行中可能通过也可能失败，调试成本急剧上升。

三、实战验证：构建可复现的批量采样管线

3.1 实验环境

GPU：NVIDIA A100 80GB
框架：vLLM 0.5.2
模型：Qwen2-7B-Instruct
测试负载：1000 条相同 Prompt，Batch Size 8

3.2 复现状态泄漏

默认配置下运行批量推理，记录每条请求的 output hash：

fromvllmimportLLM,SamplingParams llm=LLM(model="Qwen2-7B-Instruct")sp=SamplingParams(temperature=0.7,top_p=0.9,seed=42)prompts=["解释批量采样中的 RNG 泄漏"]*8outputs=llm.generate(prompts,sp)hashes=[hash(o.outputs[0].text)foroinoutputs]print(f"Hash 去重后数量:{len(set(hashes))}")# 往往 > 1

在默认实现中，即便显式传入了seed=42，Batch 内部仍可能出现多个不同输出，因为 vLLM 的旧版本会把 Seed 应用到 Batch 级别而非 Sequence 级别。

3.3 引入 Per-Request RNG Stream

💡 修复思路是为每个 Sequence 分配独立的 Philox Stream，确保随机状态按请求隔离：

# 伪代码：在 Sampler 中为每个 Sequence 绑定独立 Seeddefsample_with_isolated_rng(logits,seq_seeds):results=[]fori,seedinenumerate(seq_seeds):rng=torch.Generator(device='cuda')rng.manual_seed(seed)probs=softmax(logits[i])token=multinomial(probs,generator=rng)results.append(token)returntorch.stack(results)