长文问答首字变慢怎么办：四张L40S的预填充与解码分离验证方案

数据性质与适用范围

本篇为S1工程模拟方案，按公开技术资料与明确的业务假设编制。容量计算使用文中假设；验收数值是待验证目标，没有本站实机测试日志。实际交付应保存硬件、版本、请求集和原始结果，再确定服务能力。

问题出在负载混合

模拟一个企业内部API，150名员工使用32B问答模型。请求中80%为2K输入、512输出的普通问答，20%为16K输入、1024输出的长文解释。用户反映正在生成的答案会突然停顿，而服务器平均GPU利用率并不低。待验证假设是长请求预填充与短请求解码竞争资源；真实原因也可能是网关缓冲、客户端网络或检索慢，必须先分段计时。

现有设备为一台4×L40S 48GB服务器，512GB ECC内存、双25GbE和NVMe模型盘。32B BF16权重约64GB十进制量级，计划每两张卡承载一份模型，缓存与运行时另计。四张L40S并不构成NVLink平台，GPU通信与缓存传输需要检查PCIe拓扑和实际路径。

对照组必须公平

方案A是两个独立的双卡统一实例，由网关均匀分流。方案B仍用同样实例，但网关按输入长度把长短请求分队列并限制长任务活跃数。方案C使用两卡预填充组和两卡解码组，通过当前锁定版本支持的KV连接器传输缓存。所有方案使用相同模型、精度、总GPU数、输入集、输出上限和到达率，避免把更多硬件带来的改善算成架构效果。

vLLM相关功能在所引用版本中标注为实验性。连接器、张量并行和部署方式有版本限制，正式上线前须按该版本示例完成最小验证；不能只把两个实例命名成prefill、decode就认为已经分离。

请求与缓存的实际流转

客户端首先拿到请求ID，网关完成鉴权和token预算。预填充组计算输入并建立KV Cache，传输层把相应缓存送给解码组，解码组生成后续token并流式返回。任一环节取消都应传播到另一侧。日志需要关联两个实例ID，才能知道时延究竟花在排队、预填充、缓存传输还是解码。

预填充分离不能自动减少总计算量，而且可能增加复制和网络开销。相同机器中的PCIe路径也要测量，不假设“同机就没有通信成本”。先用一个短请求核对分离结果，再让两个请求同时进入，观察是否发生缓存错配、重复释放或孤立任务。

负载怎么压，指标怎么看

每组运行三种到达率：0.2、0.5、1.0请求/秒，各持续20分钟，并随机打散长短请求顺序。高档负载按加权输出计算，平均每请求614.4 tokens，对应614.4输出tokens/秒的需求；这是业务需求推算，不表示四卡能够达到。若未完成请求越来越多，应报告排队增长，不能只统计已经完成的快速请求。

• 首字延迟：从网关接收至第一个有效文本，分别统计短请求与长请求P50、P95。
• token间隔：统计流式生成过程的P95间隔和超过1秒的停顿次数。
• 传输成本：记录KV字节数、耗时、失败和重试；与输入长度一起保存。
• 成功率：分客户端取消、限流拒绝、内部错误和正常完成，避免把主动拒绝当作隐形成功。

方案C的验收目标为短请求P95 token间隔较A下降至少20%，同时普通问答首字不超过3秒、总完成量不下降超过10%。这些是项目设定的通过条件。若B已满足目标而C复杂度更高，就保留B。

上线与回滚

先让5%流量进入方案C，观察一整天，再到20%。必须保留统一实例入口，网关配置可以直接切回。预填充进程退出时，不应无限等待；在约定超时后返回可重试错误，只有请求未产生输出且具有幂等标识时才自动重试。已流式输出的请求不要悄悄拼接第二个模型的答案。

交付中保存连接器版本、缓存传输拓扑、三组相同请求的原始结果和故障取消记录。适用条件是长短请求混合造成明确的阶段竞争；纯短请求、低并发和传输路径较慢的环境，分离方案可能没有收益。

技术依据与复现资料

• vLLM预填充分离官方文档：https://docs.vllm.ai/en/v0.18.0/features/disagg_prefill/