一名开发者在Linux.do论坛发帖求助，称其在8张NVIDIA H200 GPU（2TB内存、模型存放于本地NVMe）上通过vLLM nightly版本部署DeepSeek-V4.1-Flash时遭遇严重性能问题。启动配置包括8路张量并行、1048576最大上下文长度、64并发上限、前缀缓存与推测解码等参数，并挂载了CPU卸载连接器。实际运行中，仅8个并发请求就导致服务近乎瘫痪：客户端等待2至15分钟仍收不到首个token，最终超时断开，completion_tokens为0。vLLM日志显示8个请求处于运行状态，但生成吞吐量为0.0 toks/s，KV缓存占用仅约1%；nvidia-smi显示GPU SM利用率达100%，显存占用6%至28%，PCIe接收速率2.5至7 GB/s，温度功耗正常，ECC无报错。该用户的请求prompt普遍长达数万至数十万token，推理强度多为high或max。其怀疑超长上下文的prefill阶段堵塞队列，导致decode任务无法被调度；也可能是CPU卸载导致PCIe数据搬运过慢。尝试关闭KV卸载无效，CUDA Graph捕获时出现空图警告但最终显示完成，Rust前端也提示部分参数未生效。发帖人询问是否需下调max-model-len、换回Python前端，或相关特性本身尚不成熟。
事件分析
该案例暴露出超长上下文推理服务的典型瓶颈：当单请求prompt达数十万token时，prefill计算量远超decode，在缺乏有效调度隔离的情况下会长时间霸占GPU，形成SM利用率满载而生成吞吐归零的假象。推测解码、CPU卸载、Rust前端等多个前沿特性叠加启用，也显著放大了问题排查难度。随着各家模型将上下文窗口推向百万级token，推理框架的prefill/decode调度策略、KV缓存管理与显存分层方案正成为新的工程焦点，开源推理栈在生产环境中的稳定性仍有待打磨。后续值得关注的方向包括：分块prefill的优先级调度改进、超长上下文场景的官方性能基准数据，以及DeepSeek-V4.1-Flash与vLLM版本兼容性的修复进展。
核心观点：GPU满载却零输出，暴露的正是超长上下文时代的调度瓶颈——算力不再是短板，推理架构设计才是。
原文链接：Linux.do
