现象：首字延迟（TTFT）超预期

某金融客户在 DeepSeek-V4 企业知识库问答系统上线后，监控显示 P99 首字延迟（Time To First Token）频繁突破 1.2 秒，显著高于测试环境基准值（平均 600ms）。问题集中出现在工作日晚高峰时段。

排查链路与关键日志

1. 负载层面：
2. 监控显示 GPU 利用率峰值仅 65%，排除算力瓶颈
3. vLLM 日志中发现 SCHEDULING_DELAY 告警，单请求排队时间达 400ms
4. 节点级监控发现 CPU 上下文切换频率异常（>15k次/秒），暗示调度竞争
5. RAG 管线：
6. 向量检索阶段平均耗时 120ms（Milvus 2.3 集群），但 P99 达 480ms
7. 重排阶段 cross-encoder 模型占用 210ms（未启用量化）
8. 日志显示 12% 请求触发了 fallback 到 brute-force 相似度计算
9. 请求特征：
10. 20% 请求携带超过 5 个附件（PDF/PPT），触发长上下文处理
11. 日志中出现 INPUT_TRUNCATED 警告，实际处理 token 数达 28k
12. 用户会话分析显示 35% 的连续追问涉及跨文档关联

根因分析

1. 批处理调度缺陷：
2. 默认的 vLLM Continuous Batching 策略对混合长度请求适应性差
3. 长文本请求阻塞整个批次调度（见日志 batch_size=8, max_seq_len=32000）
4. 未针对 RAG 场景配置差异化的调度优先级队列
5. 检索-生成耦合：
6. 同步调用检索管线导致 LLM 推理必须等待全部 RAG 结果就绪
7. 未实现 streaming retrieval 与 speculative decoding 的协同
8. 向量检索结果缓存未考虑文档更新频率（部分缓存命中率仅 40%）
9. 冷启动惩罚：
10. 未预热 cross-encoder 模型，首请求加载耗时额外增加 300ms
11. GPU 显存碎片化导致长上下文请求需要多次内存重整
12. 隐藏成本：
13. 动态文档加载时未预计算 embedding，实时编码占 TTFT 的 18%
14. 未启用 FlashAttention-2，导致长序列处理效率低下

优化方案与验证

关键改动（含实测收益）

最终效果：生产环境 P99 TTFT 稳定在 680ms 以内，吞吐量提升 2.4 倍，且： - 长文档请求放弃率从 15% 降至 3% - 每日 GPU 费用节省 $230（按 AWS p4d 实例计费）

预防体系

1. 容量规划检查项：
2. 按业务文档平均长度计算 vLLM 内存占用（公式：max_seq_len × batch_size × 2.5MB）
3. 压力测试需覆盖 "5 附件 + 高峰 QPS" 组合场景
4. 预留 20% 显存余量应对突发长上下文请求
5. 监控看板必选指标：
6. rag_retrieval_latency（按文档类型分桶）
7. vllm_scheduler_delay（区分长短上下文队列）
8. first_token_latency（按用户角色打标）
9. speculative_decoding_hit_rate（流式场景）
10. 上线前验证清单：
11. [ ] 量化模型 golden set 测试通过率 ≥98%
12. [ ] 混合长度请求的调度延迟差异 <20%
13. [ ] 流式传输模式下结果一致性验证
14. [ ] 冷启动预热脚本覆盖所有路由组合

延伸讨论

何时不建议继续优化 RAG 延迟？

当出现以下情况时，应考虑业务逻辑调整而非技术优化： 1. 用户真实满意度与 TTFT 指标脱钩（如延迟从 1.2s→0.8s 但 NPS 无变化） 2. 超过 50% 的延迟来自非技术因素（如人工审核流程强制等待） 3. 进一步优化需牺牲 >5% 回答质量

DeepSeek-V4 特定注意事项

• 128k 上下文场景需特别验证分段处理的语义连贯性
• 企业知识库建议开启 enable_document_boundary_detection 参数
• 对财务/合规相关查询，禁用流式传输以确保结果完整性

注：本案例优化方法适用于 DeepSeek-V4 的 128k 上下文窗口场景，若使用更小窗口模型需调整分段策略阈值。优化前后的完整日志样本和配置对比已开源在 GitHub 仓库 deepseek-rag-optimization-demo。