本地推理编排启动三个 vLLM 实例，共享一张 RTX 4070 的 8GB 显存；Qwen3-1.7B 模型经 FP8 量化后仍约占 ~4.5GB。高并发下 GPU 显存占用持续打满，P95 延迟尖刺明显，首 token 延迟抖动超过 2 秒。加卡预算充足，但本地开发环境不允许——优化必须在不改动代码、不增加硬件的前提下完成。
核心论点
vLLM 的优化不是"换更好的 GPU"，而是在现有硬件上通过配置级别的调整榨干每一分显存和 CPU 周期。实测发现，max_num_batched_tokens=4096是唯一显著有效的参数（medium/long prompt 首 token 延迟降低 43-72%），而 KV Cache Offloading、Stream Interval、-O2 等预期收益在当前 8GB 单卡 + 小模型场景下并未显现。配置调优的 ROI 取决于硬件、模型大小和业务负载的三重匹配，不是所有参数都普适。
一、背景：三实例共享单卡的显存战争
| 服务 | 模型 | 显存预算 | 状态 |
|---|---|---|---|
| vllm-bge-reranker | BAAI/bge-reranker-base | ~1.0 GB | 稳定 |
| vllm-bge-m3 | BAAI/bge-m3 | ~1.5 GB | 稳定 |
| vllm-qwen3 | Qwen3-1.7B-unified (FP8) | ~4.5 GB | 满负荷 |
约束：RTX 4070 8GB，三实例通过--gpu-memory-utilization严格预算显存。CUDA context、模型权重、KV Cache、激活值全部挤在一块，没有余量。
FP8 量化后为什么依然紧张：KV Cache 的大小与序列长度成正比。电商客服场景平均上下文 512-2048 tokens，KV Cache 动态增长时，即使权重已量化，缓存层仍会逐渐打满显存。一旦超出预算，vLLM 驱逐最老的请求，重算 KV Cache 产生延迟尖刺。
从"能跑"到"跑好"的差距：当前--enforce-eager模式牺牲了 CUDA Graph 和 kernel fusion，启动快但 decode 吞吐低。KV Cache 没有 offloading 机制，溢出驱逐。流式响应每 token 都触发一次 HTTP 序列化，host overhead 在高并发下成为瓶颈。长 prompt 的 prefill 阶段会独占调度步，阻塞其他请求的 decode。
决策：不改硬件、不改代码，优先通过 vLLM 内置的配置开关优化。配置层面的 ROI 最高，因为零部署风险、零回归面，但必须通过实测验证预期。
二、立即可试（改配置 + 跑压测）
2.1 KV Cache Offloading —— 用 CPU 内存换 GPU 吞吐
机制：KV Cache 超出显存预算时，自动通过 DMA 异步卸载到 CPU DRAM；需要时再异步加载回 GPU。卸载与模型计算并行，不阻塞 GPU 执行。
# docker-compose.vllm.yml 中 vllm-qwen3 服务environment:-VLLM_CPU_OFFLOAD_GB=4效果验证：
| 指标 | 博客预期 | 实际（4 并发） | 实际（16 并发） |
|---|---|---|---|
| P95 延迟 | 下降 15-30% | Short -31%，Medium +18%，Long +27% | 与本节 4 并发结果几乎相同 |
| 吞吐量 (req/s) | 提升 20-50% | 略降 1-4% | 受 max-num-seqs=8 限制 |
| GPU Memory-Usage | 峰值不再打满 | 平稳，但无显著吞吐提升 | 瓶颈转移为队列排队 |
| 成功率 | - | 92% → 100%（稳定性提升） | 100% |
决策：offloading 4GB 的代价是带宽而非容量。实测显示，低并发下 CPU-GPU 传输开销超过收益，但稳定性有明显改善（Short 场景成功率 92% → 100%，消除偶发超时）。建议仅在显存不足频繁触发 OOM 或对稳定性要求高于延迟时启用。
2.2 Stream Interval —— 降低 Host 开销
机制：流式响应采用 SSE（Server-Sent Events，服务端单向推送事件）协议，默认每生成一个 token 就发送一次 HTTP 分块。--stream-interval 10缓冲 10 个 token 后批量发送，减少网络序列化和 CPU 调度开销。首 token 仍立即发送，首 token 延迟不受影响。
command:>--stream-interval 10效果验证：
| 指标 | 预期变化 | 测量方式 | 实际（4 并发） |
|---|---|---|---|
| P95 延迟（100+ 并发） | 改善 10-20% | k6 报告 | 收益被 max_num_batched_tokens=4096 覆盖 |
| TTFT | 无变化（首 token 立即发送） | k6 自定义指标 | 无变化 |
决策：纯配置调整，零风险。但在当前负载下，max_num_batched_tokens=4096（见 3.2 节）已覆盖其主要收益。Stream Interval 更适合 CPU 成为瓶颈的高并发场景，当前 GPU 利用率不高时收益有限。
2.3 优化级别：从 --enforce-eager 升级到 -O2
机制：--enforce-eager禁用 CUDA Graph 以节省显存，但每次 kernel 都要重新 launch。-O2启用 CUDA Graph 捕获和torch.compile融合，将整个模型执行图录制为 DAG，后续直接 replay，减少 kernel launch 开销。
# 当前command:>---enforce-eager# 改为command:>--O2--cuda-graph-capture-size 512效果验证：
| 指标 | 预期变化 | 实际（RTX 4070 + 1.7B） |
|---|---|---|
| 冷启动时间 | 增加 5-15s | 增加约 10s |
| 稳态 P95 延迟 | 下降 10-30% | 无明显改善 |
| 显存占用 | 增加 ~500MB-1GB | 增加 ~200MB |
决策：在当前硬件和模型规模下，CUDA Graph 无明显改善。-O2更适合大模型（7B+）或高 batch size 场景。建议保持--enforce-eager或仅使用-O1（更轻量）。
三、需要验证的进阶配置
注：本节列出的是"预期收益高、但需实测确认"的配置。其中
max_num_batched_tokens调优在实测后被证实为唯一 P0，其余两项（Prefix Caching、Chunked Prefill 机制本身）因当前负载特征未达预期，列为待验证或进阶。
3.1 Prefix Caching —— 拦截重复前缀
机制：共享前缀（如 system prompt、RAG 检索到的文档片段、多轮对话历史）的 KV Cache 持久化在 GPU 显存中。新请求到达时，直接复用已有 KV Cache，仅计算新增后缀。通过写时复制（Copy-on-Write）保证多请求共享时的安全修改。
command:>--enable-prefix-caching --prefix-caching-memory-percentage 0.1效果验证：
- 构造共享前缀场景（多个请求携带相同的 system prompt + 前 100 tokens）
- 对比开启前后的首token延迟
- 实测结果：固定前缀场景 Short 首token延迟 p95 降低 54%（136ms → 61ms），但Agent 实际场景下 system prompt 高度动态（本地 Agent 的提示词由规则片段、技能描述与实时意图上下文拼接而成），导致 cache 命中率极低，Long 场景 首token延迟 p95 反升 32%。
适用场景：多轮对话、RAG 检索、固定 system prompt 的客服场景。不适用于当前 Agent 架构（动态拼接 prompt）。
决策：vLLM 0.21.0 已支持自动前缀缓存，但命中率取决于业务前缀的重复度。当前项目的 system prompt 包含订单号、用户意图、情绪 tone 等动态内容， Prefix Cache 几乎失效。在 system prompt 完全固定的子场景，或者调整提示词顺序将不变量放在前面后启用。
3.2 Chunked Prefill + max_num_batched_tokens 调优
机制：长 prompt 的 prefill 阶段（计算密集型）会独占一个调度步，阻塞其他 decode 请求（内存带宽密集型）。Chunked Prefill 将长 prompt 拆分为小块（默认 chunk size 由--max-num-batched-tokens控制），与 decode 请求交错执行。
command:>--max-num-batched-tokens 4096调优方向：
| 参数值 | 首token延迟均值 | TTFT p95 | ITL 均值（Inter-Token Latency，token 间延迟） | Tok/s | 适用场景 | 实测结论 |
|---|---|---|---|---|---|---|
| 2048 | 52.0ms | 66.3ms✅ | 11.0ms | 90.9 | 短 prompt 为主 | Short 最优；Long p95 97.8ms，不如 4096 |
| 4096 | 52.1ms | 65.0ms | 10.8ms | 92.6 | 混合负载 | Medium/Long 最优（-43%/-72%）；Short p95 136.1ms |
| 8192 | 79.5ms | 111.2ms | 11.0ms | 90.8 | 长 prompt 为主 | 最差，Medium/Long 均不如 2048/4096 |
效果验证：
- 4 并发，每场景 12 次请求，输出 256 tokens
- 对比 2048 / 4096 / 8192 三个值
- 实测关键发现：
- 4096 是 Medium/Long 场景的最优解：Long TTFT p95 从 97.8ms（2048）降至 69.4ms（-29%），从 215.9ms（8192）降至 69.4ms（-68%）
- 2048 是 Short 场景的最优解：TTFT p95 66.3ms，且 100% 成功率；4096 的 Short p95 136.1ms 且有 1/12 超时
- 8192 全面劣化：Medium p95 111.2ms（比 4096 的 65.0ms 差 71%），Long p95 215.9ms（比 4096 差 212%）
- 规律：
max_num_batched_tokens增大 → prefill 块变大 → decode 被阻塞更久 → Long prompt 尾延迟恶化
决策：电商 Agent 混合负载推荐4096（Medium/Long 收益巨大，Short 尾延迟可接受）。如果业务以极短 prompt 为主且对稳定性要求极高，可选 2048。8192 不推荐。
四、为什么不做的：单卡硬件限制
| 优化 | 不能做的原因 | 硬性门槛 |
|---|---|---|
| Speculative Decoding | 8GB 显存已满，加载 draft model 极易 OOM；Qwen3-1.7B 本身小，2-3x 加速后绝对延迟仍 <100ms，边际收益低 | ≥2× 模型显存余量 |
| Disaggregated Serving | 需 ≥2 张 GPU 分离 prefill（计算密集）和 decode（内存带宽密集）池 | 2+ GPU |
| TP（张量并行） / PP（流水线并行） / EP（专家并行） | 单 GPU 无法做 tensor / pipeline / expert parallelism | 2+ GPU |
| AWQ / GPTQ 4-bit | FP8 已占 ~4.5GB，再量化收益空间小且需重新校准；bge 模型已很小，量化收益有限 | 需重新校准 + 验证精度 |
| FlashAttention 3 | 需 H100（Hopper）架构的 TMA 单元 | H100+ |
决策逻辑：这些优化的收益曲线在低并发、小模型场景下是凹的——硬件投入线性增长，但延迟改善呈边际递减。当前项目的最佳 ROI 在配置调优层，不在架构升级层。
五、多卡展望：什么时候该上什么（当前不可达）
5.1 并行策略选型指南
| GPU 数量 | 推荐策略 | 适用场景 | 通信要求 |
|---|---|---|---|
| 1 | 单进程 + KV Offloading | 当前项目 | 无 |
| 2-4 | TP=2/4 | 单模型大 batch，低延迟 | NVLink 优先 |
| 4-8 | TP + PP | 超大模型（70B+） | NVLink / InfiniBand |
| 8+ | TP + EP（MoE） | MoE 模型，专家并行 | InfiniBand（专家负载不均） |
决策：张量并行的通信开销在 NVLink 下可忽略（1.4TB/s），但在 PCIe 下会成为瓶颈。单卡升级到双卡时，优先张量并行而非 流水线并行，因为 attention 层通信密集、流水线并行的 bubble 效应在小 batch 下更明显。
5.2 Disaggregated Serving 的 ROI 拐点
Prefill 阶段计算密集（大规模矩阵乘法），Decode 阶段内存带宽密集（反复读取 KV Cache + 权重）。分离后：
- Prefill workers 用计算优化型 GPU（如 L40S）
- Decode workers 用内存带宽优化型 GPU（如 H100）
- KV Cache 通过专用服务在两者间传输
拐点条件：
- 并发 >100 且 首token延迟与 TPOT（每输出一个 token 的平均时间）的冲突
- 长 prompt 占比高（prefill 时间 > decode 时间）
- 当前项目：单卡 + 低并发，不满足
决策：Disaggregated Serving 是"用硬件换延迟确定性"，不是"用软件换吞吐"。当调度器无法同时满足 TTFT 和 ITL 时，分离才有意义。
5.3 Speculative Decoding 的适用条件
- Draft model 显存 = target model 的 10-20%
- 生成密集型负载（长文本生成 >200 tokens）
- 当前 Qwen3-1.7B 本身小，2-3x 加速后绝对延迟仍 <100ms，对用户体验改善有限
适用场景：7B+ 模型 + 生成密集型 workload + 有多卡余量承载 draft model。
六、决策矩阵：优化优先级（基于实测修正）
| 优化 | 改动量 | 实际收益 | 风险 | 优先级 | 备注 |
|---|---|---|---|---|---|
max_num_batched_tokens=4096 | 1 行参数 | Medium/Long TTFT -43~72% | 低 | P0 | 唯一显著有效的参数 |
| KV Cache Offloading | 1 行环境变量 | 稳定性提升（成功率 92%→100%），延迟略增 | 低 | 当前不启用 | 低并发下 overhead > 收益；OOM 时考虑 |
| -O2 优化级别 | 改 command | 无明显改善 | 低 | 不启用 | RTX 4070 + 1.7B 小模型无收益 |
| Stream Interval | 1 行参数 | 收益被 max_num_batched_tokens=4096 覆盖 | 无 | 不启用 | 高 CPU 瓶颈场景可能有用 |
| Prefix Caching | 2 行参数 | 固定前缀有效，当前场景无效 | 中 | 不启用 | 动态 system prompt 命中率低 |
决策逻辑：P0 是"今天下班前就能上线"的改动。实测发现，配置优化的收益高度依赖硬件和负载的匹配——文档中的"预期收益"往往基于大模型或高并发场景，不能直接套用到小模型单卡环境。必须建立 baseline、单变量调优、压测验证，才能找到真正有效的参数。
核心要点
- Baseline 先行：每次调优前必须建立 baseline，用数据而非感觉决策
- 单变量测试：每次只改一个参数，避免混淆因果
- 分层验证：L1（vLLM 专项）→ L2（业务流程）→ L3（功能回归），逐层确认
- 硬件-模型-负载三重匹配：没有普适的"最优参数"，只有适合当前场景的配置
)