今年以来,“如何 Tokenmaxxing” 成为了大洋两岸都在讨论的问题。 然而,在真实企业场景中,大家都在用的主流开源大模型推理框架 vLLM 一直隐藏着一个“吞 Token 大坑”: 系统看起来正常运行,请求也正常返回,但模型的回答质量却在高并发、多卡并行等复杂环境下悄悄下降。 近日,范式 $06682(06682)$ 工程师向开源大模型推理框架 vLLM 提交的一项关键 Bugfix 已被官方社区合并。该修复解决了 vLLM 在 Pipeline Parallelism(流水线并行)模式下,高并发请求可能导致 prompt token 丢失,并进一步引发模型推理准确率下降的问题。 01 多卡流水线并行,会“吞掉”用户的 Token 可以把大模型想象成一条很长的生产线。模型太大,一张 GPU 放不下或算不过来,就把它按层拆成几段:前面几层放在 GPU 1,中间几层放在 GPU 2,后面几层放在 GPU 3。请求进来后,数据会像产品上流水线一样,依次经过每一段 GPU,最后产出结果。在有多个请求或 micro-batch 时,不同 GPU 可以同时处理不同阶段,从而提高整体吞吐。 图片 它的好处是:让多张 GPU 一起干活,跑更大的模型、扛更多请求。 但难点也在这里:请求多了以后,每一站都要记清楚“这个请求处理到哪了、上下文有哪些”。一旦记录错了,模型就可能漏看一部分题目背景,答案自然会变差。所以,流水线并行看起来是“多卡分工”,本质上考验的是:多张 GPU 能不能配合得又快又准。 但当系统同时处理大量请求时,问题就出现了。vLLM 在流水线并行模式下,需要一边拆分任务、一边分批处理输入内容,还要不断调整请求顺序。原有逻辑在少数复杂场景下,可能把某个请求的上下文记录错