vllm微调最佳实践

目录

• • vLLM 调参总览（生产 vs 实验）
    • 一、生产环境 必调参数（强相关稳定性 & 性能）
    • 二、生产环境强烈建议（在线服务关键优化）
    • 三、“看场景用”的参数（半生产 / 半实验）
    • 四、实验 / Benchmark / 学习用途（生产不建议）
  • 五、参数与阶段的“心智模型映射”（非常重要）
  • 六、生产级“最小推荐配置模板”
  • 七、一句话工程总结（你可以直接对团队说）
• 针对LS400,A100 80G,H100 的参数变化
• 一、结论先行（一句话版）
• 二、三种卡的“推理能力画像”（先理解差异）
• 三、哪些 vLLM 参数“会随着卡而变化”
  • 1️⃣ --max-model-len（KV Cache 上限，显存决定）
  • 2️⃣ --gpu-memory-utilization（安全上限不同）
  • 3️⃣ --max-num-seqs（并发序列数）
  • 4️⃣ --max-num-batched-tokens（吞吐核心参数）
  • 5️⃣ 执行模式相关参数（是否“敢开”）
    • --enforce-eager（禁用 CUDA Graph）
    • Attention 后端（无需显式参数）
• 四、哪些参数不随卡变化（逻辑不变）
• 五、三种卡的“推荐起始配置模板”
  • • ▶ L40S 48GB（稳定在线服务）
    • ▶ A100 80GB（高并发生产）
    • ▶ H100 80GB（极限吞吐 / 低延迟）
• 六、工程级一句话总结

vLLM 调参不是“参数越多越好”，而是围绕 Prefill、Decode、KV Cache 三件事做约束与平衡。
下面是基于我们整个对话脉络（vLLM 0.13.x + 4090 + Qwen14B + 在线 API 服务）整理出的 一份“工程级可落地”的 vLLM 调参总表。
我按 是否必调 / 是否适合生产 / 是否偏实验 做了明确区分，避免你在生产环境“参数越加越多，反而失控”。

---

vLLM 调参总览（生产 vs 实验）

阅读方式建议

• 先看「生产环境必调」
• 再看「按业务形态选择」
• 最后看「实验 / Benchmark 专用」

---

一、生产环境 必调参数（强相关稳定性 & 性能）

参数	作用	影响阶段	调参目标	是否生产必需	备注
--model	模型权重路径	全流程	正确加载模型	✅	与 tokenizer 强绑定
--quantization	量化方式（awq / gptq 等）	全流程	降显存、提升吞吐	✅	4090 + 14B 基本必量化
--max-model-len	单请求最大 token 数	Prefill / KV	控制 KV Cache 上限	✅	过大 = 吃显存
--gpu-memory-utilization	GPU 显存可用比例	KV / batching	防 OOM + 吞吐平衡	✅	0.85–0.92 常用
--max-num-seqs	同时活跃序列数	Decode	控制并发	✅	防止 step 过慢
--max-num-batched-tokens	单 step 总 token 上限	Decode	提升 tokens/s	✅	比 max-num-seqs 更重要
--scheduling-policy	请求调度策略	Decode	稳定尾延迟	✅	fcfs 最稳
--port	服务端口	运维	避免冲突	✅	基础项

---

二、生产环境强烈建议（在线服务关键优化）

参数	作用	解决的问题	是否推荐生产	适用场景	备注
--enable-prefix-caching	复用 prompt 前缀 KV Cache	降低 TTFT	✅	多轮对话 / RAG	token_id 级别
--enable-chunked-prefill	拆分长 prompt prefill	降低 P95/P99	✅（有条件）	长 prompt 混合请求	稳定性参数
--enforce-eager	禁用 CUDA Graph	提升兼容性	✅	消费级显卡	稳定优先
--disable-cpu-offload	禁用 CPU KV	防性能倒退	✅	GPU 显存够	CPU 常拖慢
--log-level INFO	日志级别	可观测性	✅	生产调优	看 backend / cache

---

三、“看场景用”的参数（半生产 / 半实验）

参数	作用	影响	是否默认开启	使用建议
--dtype auto	自动选择精度	显存 / 性能	⚠️ 可选	量化模型意义不大
--tensor-parallel-size	Tensor 并行	多卡扩展	⚠️	单卡 4090 不用
--pipeline-parallel-size	Pipeline 并行	多卡扩展	⚠️	延迟增加
--swap-space	CPU swap	防 OOM	⚠️	线上慎用
--enable-logprobs	输出概率	推理成本	❌	会明显降吞吐

---

四、实验 / Benchmark / 学习用途（生产不建议）

参数	目的	为什么不建议生产
--enable-flash-attn	强制 FA	0.13 已自动选择 backend
--attention-backend	指定 attention 实现	易失效 / 版本敏感
--disable-kv-cache	（不存在）	vLLM 核心机制
超大 max-model-len	压模型极限	KV Cache 爆炸
超大 max-num-seqs	测极限并发	P99 会崩

---

五、参数与阶段的“心智模型映射”（非常重要）

阶段	主要相关参数
Tokenizer	tokenizer 固定（不可调）
Prefill	max-model-len / prefix-caching / chunked-prefill
Decode	max-num-seqs / max-num-batched-tokens / scheduling
KV Cache	gpu-memory-utilization / max-model-len
TTFT	prefix-caching / chunked-prefill
tokens/s	max-num-batched-tokens

---

六、生产级“最小推荐配置模板”

你现在这套环境，我给你一个“稳态生产起点”：

python -m vllm.entrypoints.openai.api_server \
  --model /data/models/Qwen1.5-14B-Chat-AWQ \
  --quantization awq \
  --max-model-len 2048 \
  --gpu-memory-utilization 0.9 \
  --max-num-seqs 32 \
  --max-num-batched-tokens 8192 \
  --enable-prefix-caching \
  --enable-chunked-prefill \
  --scheduling-policy fcfs \
  --enforce-eager \
  --disable-cpu-offload \
  --log-level INFO

然后再围绕 2 个参数做系统性调优：

• max-num-batched-tokens
• max-num-seqs

---

七、一句话工程总结（你可以直接对团队说）

vLLM 调参不是“参数越多越好”，而是围绕 Prefill、Decode、KV Cache 三件事做约束与平衡。
生产环境优先稳态与尾延迟，实验参数不要带进线上。

---

如果你愿意，下一步我可以直接帮你做：

• 一张“调参顺序流程图（Step1 → Step5）”
• 4090 + Qwen14B 的参数上限估算公式
• 一套自动化 grid search + 压测脚本思路

你选一个，我继续。

针对LS400,A100 80G,H100 的参数变化

下面给你一份工程级、可直接用于决策的总结。
结论先行，然后给对照表 + 调参建议，明确 哪些参数会变、哪些不需要动。

---

一、结论先行（一句话版）

从 L40S → A100 80G → H100，vLLM 的“参数体系不变”，
但以下三类参数的“可用上限、最优区间、默认建议值”会显著变化：

1. KV Cache 相关（显存决定）
2. Decode 并发相关（算力 + 显存带宽决定）
3. 执行后端相关（是否可放心用 CUDA Graph / 高级 attention）

---

二、三种卡的“推理能力画像”（先理解差异）

项目	L40S 48GB	A100 80GB	H100 80GB
定位	数据中心推理卡	训练 / 推理通用	新一代推理王者
显存	48GB	80GB	80GB
显存带宽	高	很高	极高
FP16 / BF16	强	强	极强
FlashAttention	稳	稳	最优
CUDA Graph 稳定性	高	很高	非常高
KV Cache 空间	大	非常大	非常大
适合形态	在线推理	高并发服务	极限吞吐 / 低延迟

---

三、哪些 vLLM 参数“会随着卡而变化”

下面是只列“真的会变”的参数，不浪费你时间。

---

1️⃣ --max-model-len（KV Cache 上限，显存决定）

卡型	生产常用范围（Qwen 14B AWQ）	说明
L40S 48GB	4096 / 8192	已非常充裕
A100 80GB	8192 / 16384	RAG / 长上下文友好
H100 80GB	8192 / 16384（更稳）	Prefill 更快

显存越大 → 单请求上下文可以拉得越长

---

2️⃣ --gpu-memory-utilization（安全上限不同）

卡型	建议值	原因
L40S	0.88–0.92	稳定优先
A100	0.90–0.94	ECC + 驱动成熟
H100	0.92–0.96	专为高压运行设计

---

3️⃣ --max-num-seqs（并发序列数）

卡型	建议起点	调参方向
L40S	32–64	受算力限制
A100	64–128	Decode 并发拉高
H100	128–256	高并发 decode

H100 的优势：单 step decode 能“顶住”更多序列

---

4️⃣ --max-num-batched-tokens（吞吐核心参数）

卡型	建议范围	说明
L40S	8192–16384	显存允许
A100	16384–32768	吞吐明显上升
H100	32768–65536	tokens/s 爆发

这是 H100 拉开代差的关键参数

---

5️⃣ 执行模式相关参数（是否“敢开”）

--enforce-eager（禁用 CUDA Graph）

卡型	建议
L40S	建议开启（禁用 graph）
A100	可关闭（用默认 graph）
H100	不建议开启（充分利用 CUDA Graph）

---

Attention 后端（无需显式参数）

卡型	实际行为
L40S	FlashAttention
A100	FlashAttention / FlashInfer
H100	FlashAttention-2（最优）

H100 上 不要手动指定 backend，自动选择最好。

---

四、哪些参数不随卡变化（逻辑不变）

这些你不用重新理解：

参数	原因
--enable-prefix-caching	业务形态决定
--enable-chunked-prefill	是否有长 prompt
--scheduling-policy	调度逻辑一致
--quantization awq	模型 & 显存策略
--port / log-level	运维参数

---

五、三种卡的“推荐起始配置模板”

▶ L40S 48GB（稳定在线服务）

--max-model-len 4096
--gpu-memory-utilization 0.9
--max-num-seqs 64
--max-num-batched-tokens 16384
--enable-prefix-caching
--enable-chunked-prefill
--enforce-eager

---

▶ A100 80GB（高并发生产）

--max-model-len 8192
--gpu-memory-utilization 0.93
--max-num-seqs 128
--max-num-batched-tokens 32768
--enable-prefix-caching
--enable-chunked-prefill

---

▶ H100 80GB（极限吞吐 / 低延迟）

--max-model-len 8192
--gpu-memory-utilization 0.95
--max-num-seqs 256
--max-num-batched-tokens 65536
--enable-prefix-caching
--enable-chunked-prefill
# 不要 --enforce-eager

---

六、工程级一句话总结

卡升级，不是“多加几个参数”，
而是把 KV Cache、Decode 并发、batch token 上限一起“整体抬高”。
H100 的优势，90% 体现在 max-num-batched-tokens 能拉得多高。

---

如果你愿意，下一步我可以直接帮你做三件事之一：

1. 给你一个“跨卡通用的调参顺序流程（不返工）”
2. 算一笔账：Qwen14B 在 H100 上理论 tokens/s 上限
3. 讲清楚 A100 vs H100 在 Prefill / Decode 哪一步真正拉开差距