DeepSeek V4 Flash TP2 并发 Prefill 调优实战
内容提要
分享 DeepSeek V4 Flash TP2 模型的并发调优经验：多并发时第二个 Prefill 等待过久，原因是 vLLM 的 --long-prefill-token-threshold 参数默认值 2048 过大，导致首个 Prefill 独占调度。调小该值可增加多 Prefill 调度机会。实测 1024 最佳，8 并发下后续 Prefill 等待从 90 秒降至约 7 秒，总吞吐仅降 2.5%；降至 512 则吞吐损失超 15%。
延伸解读
参数作用与默认值陷阱
文章指出，--long-prefill-token-threshold 控制单个 Prefill 请求在一次调度迭代中最多处理的 Token 数，默认 2048，最大 4096。作者最初认为 2048 足够，但实际发现该值过大时，vLLM 会让第一个 Prefill 充分执行，导致后续 Prefill 排队等待。这提醒我们，默认值未必适合所有场景，需根据并发情况调整。
调优收益与代价的权衡
作者测试发现，将该参数设为 1024 时，8 并发下后续 Prefill 等待时间从 90 秒降至约 7 秒，总吞吐仅下降 2.5%。若进一步降至 512，等待时间继续减少，但吞吐损失超过 15%。这说明调优需在延迟和吞吐之间找到平衡点，1024 在该场景下是较优选择。
适用场景与局限性
该经验基于 DeepSeek V4 Flash TP2 模型和特定硬件配置（两台算力舱，总显存超 256GB，支持 1MB 上下文）。不同模型、硬件或并发模式下，最佳阈值可能不同。读者在参考时，应结合自身环境进行测试，不宜直接套用 1024 这个值。
Q&A
DeepSeek V4 Flash TP2 模型多并发时第二个 Prefill 等待过久的原因是什么？
原因是 vLLM 的 --long-prefill-token-threshold 参数默认值 2048 过大，导致首个 Prefill 独占调度，后续 Prefill 被排队。
--long-prefill-token-threshold 参数的作用是什么？
该参数限制单个 Prefill 请求一次调度迭代中最多处理的 Tokens 数量，默认 2048，最大可设 4096。
如何调整 --long-prefill-token-threshold 来优化多并发 Prefill 等待？
需要调小该值，以增加 vLLM 调度多个 Prefill 的机会。实测设置为 1024 效果最佳。
将 --long-prefill-token-threshold 设置为 1024 后，性能提升如何？
8 并发同时请求时，后续 Prefill 等待时间从最大 90 秒降至约 7 秒，总吞吐仅下降 2.5%。
如果继续将 --long-prefill-token-threshold 降至 512，会有什么影响？
虽然后续请求的 TTFT 还会继续下降，但总吞吐量会下降超过 15%。
DeepSeek V4 Flash TP2 模型支持多大的上下文？
由于两台机器显存总共超过 256 GB，即使是非常大的 DeepSeek 也可以提供 1MB 的超大上下文。
