推理服务为什么一上请求合并就开始上下文污染：从 Request Coalescing 到 State Isolation 的工程实战

一、高并发下的请求合并困局GPU 算力昂贵单请求 batch size 为 1 时资源大量闲置。 Request Coalescing 因此成了行业标配——把多个请求打包统一推理。但线上环境一开启合并用户就开始收到「别人的回答」。两个 prompt 被拼接进同一条输入张量后模型会把相邻 token 当作同一序列延续。⚡️ 轻则输出混杂重则暴露用户上下文。对 toB 场景这是事故。图 1高并发推理集群的请求调度挑战二、问题拆解为什么合并就串扰理解污染根因必须看清 Coalescing 的实现。 主流框架把多个请求文本拼接后送入模型。问题出在「分隔」与「共享」边界。第一个陷阱是 Attention Mask 缺陷。如果 mask 未严格屏蔽跨请求 tokenDecoder 就会跨请求 attend。 在大模型中尤为致命长上下文让 token 间影响大。第二个陷阱是 KV Cache 共享。为节省显存部分实现让同 batch 请求共享前缀 KV Cache。 一旦前缀包含用户特定的 system prompt后续请求就会继承状态并泄露。第三个陷阱是 tokenizer 回切。批量解码后输出 token 需按原始请求长度切分。⚠️ 若某请求提前触发 stop sequence剩余位置可能被下一请求填充导致错位。污染类型触发条件典型表现危害等级Attention 串扰Mask 未隔离跨请求 token输出内容混杂 高KV Cache 继承共享前缀含用户状态隐私泄露风险 高回切错位Stop sequence 提前退出返回内容截断或拼接 中Position ID 重叠未重置位置编码长请求逻辑断裂 中三、实战验证复现与定位我们在 vLLM 的 70B 服务上复现了该问题。环境为 8×A100连续 batching 开启。测试用两组无关 prompt一组查询医疗另一组请求代码。importtorch bad_masktorch.ones(seq_len,seq_len)# 全连通correct_masktorch.block_diag(*[# 对角块隔离torch.ones(l,l)forlinrequest_lengths])当 batch 内同时存在长短差异极大的请求时医疗 prompt 的生成结果中出现了def calculate()片段而代码 prompt 返回里混入了药品名称。 打印中间层 attention score 后确认长请求前 20% token 有 12% 权重流向了相邻请求文本区。问题在 Prefix Caching 模块两请求共享 system prompt 前缀时vLLM 的 block manager 会把物理块标记为 shared。✅ 若一请求在前缀后接入私有信息这些信息会被写入共享块并被其他请求读取。图 2GPU 计算单元中的 Attention 计算路径四、深度思考隔离的本质代价解决污染的核心只有一个字隔。但隔离从来不是免费的。️ 完全独立的 KV Cache 分配意味着显存随 batch size 线性增长而显存恰恰是推理服务的最大瓶颈。在笔者看来工程最优解不是 “全隔离” 也不是 “全共享”而是 “按需隔离”。 通用 system prompt 共享前缀合理一旦进入用户私有上下文就必须切到独占物理块。这需要引擎在 block manager 引入 tainting 机制——写入过用户私有 token 的块都不可再被其他请求引用。另一个易被忽视的是 Position ID 分配。 传统连续位置编码在合并请求时会把第二个请求位置接在第一个后面导致模型误认为两者存在顺序依赖。正确做法是为每个请求独立维护 position ID 偏移。五、趋势预估从隔离到弹性合并未来 3 到 6 个月推理服务的竞争焦点将从 “能不能合并” 转向 “敢不敢合并”。 随着多租户 SaaS 场景爆发请求合并必须在安全隔离前提下进行。笔者认为下一代框架会内置 Secure Batching 层在调度阶段自动识别请求的安全域标签。️ 同域请求可激进合并跨域请求强制隔离。同时NVIDIA 正在推进的 Confidential Computing 特性允许在 GPU 内建立硬件隔离区。 当硬件隔离与软件调度协同推理服务或许能在不牺牲吞吐的前提下消除上下文污染风险。图 3安全隔离与弹性合并的未来架构六、结语请求合并是推理服务降本增效的核心手段但上下文污染让这条优化路径充满陷阱。 你在生产环境中遇到过请求串扰问题吗欢迎在评论区分享实战经验。别忘了点赞收藏后续会持续更新推理优化解析。