vllm微调最佳实践

目录

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

1️⃣ 参数含义

max_num_batched_tokens

max_num_batched_tokens 指的是 在decode阶段单次批处理（batch）中允许的最大总 token 数。

  • 公式理解：

  • 当 vLLM 聚合多个请求做 batch 处理时，它会不断累加各个请求的 token 数，直到达到 max_num_batched_tokens，然后就会触发一次 forward 计算。

  • 换句话说，它限制了 一次 batch 推理的最大 token 数量，而不是 batch 的请求数量。

--max-num-seqs

--max-num-seqs 指的是 一次 batch 中允许同时处理的最大序列（requests）数量。

  • 换句话说，它控制 batch 内请求的数量上限，而不是 batch 内 token 的总量。
  • 每个序列就是一个完整的生成任务，例如一次 API 请求或一次 prompt 的生成。

公式理解：

image

  • vLLM 会把不同的请求拼到一个 batch 里
  • 当请求数量达到 max_num_seqs，batch 就会触发 forward

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 哪一步真正拉开差距

--enable-chunked-prefill 用法

你想了解的--enable-chunked-prefill是vLLM中针对长上下文推理优化的核心参数，我会先明确它的启用场景，再分析对吞吐量的影响（结论先给：多数场景下不下降，长上下文/高并发下反而提升；仅短上下文低并发时略有损耗），最后给出清晰的启用判断标准。

一、先搞懂：--enable-chunked-prefill 到底是什么？

在LLM推理的prefill阶段（处理用户prompt、生成KV缓存的阶段），默认情况下vLLM会一次性把整个prompt的所有token全部处理完；而启用--enable-chunked-prefill后，会把长prompt拆成多个chunk（小块）分批处理，核心解决：

  1. 长上下文下单次prefill占用显存过高、触发OOM（内存溢出）的问题；
  2. 长prompt独占GPU计算资源，导致其他请求排队等待、整体并发效率低的问题。

二、什么时候启用（核心场景）

启用这个参数的核心判断标准是：你的推理场景中存在「长上下文prompt」或「高并发+中等长度prompt」，具体分4类典型场景：

启用场景 具体特征 举例
1. 长上下文推理（最核心场景） prompt长度 ≥ 2048 tokens（如4K/8K/16K上下文）；
单卡显存紧张（如A10G 24G跑7B模型处理8K prompt）		 处理法律文档、长文本总结、代码库解析等长prompt请求
2. 高并发推理（多请求叠加） max_num_seqs ≥ 32（高并发），且单请求prompt长度 ≥ 512 tokens；
观察到prefill阶段GPU利用率波动大、请求排队严重		 云服务API场景，每秒30+请求，单请求prompt平均1024 tokens
3. 显存受限场景 模型+KV缓存占用显存接近90%，频繁触发OOM或显存碎片；
使用较小显存显卡（如A10 24G、T4 16G）跑大模型		 A10 24G跑13B模型，处理4K上下文请求时OOM
4. 混合长度请求场景 同时有短prompt（<512）和长prompt（>2048）请求，长请求导致短请求延迟飙升 聊天机器人场景，既有单轮短问答，又有长文本分析请求

三、什么时候不启用（禁用场景）

仅在「短上下文+低并发」场景下建议禁用，避免微小的调度损耗：

  1. 所有请求的prompt长度 ≤ 512 tokens（如普通聊天机器人，单轮prompt平均200 tokens）；
  2. 并发数极低（max_num_seqs ≤ 8），GPU资源充足，无排队等待；
  3. 对prefill阶段的延迟极致敏感（如要求首次token响应时间TTFT < 100ms），且能接受显存占用高的问题。

四、对吞吐量的影响：多数场景提升，仅极端短上下文略降

吞吐量（Throughput）的核心是「单位时间内处理的总token数」，这个参数对吞吐量的影响分场景：

场景 吞吐量变化 原因
长上下文（≥2048 tokens） ↑ 提升10%~50% 1. 避免OOM导致请求失败，提升有效处理量；
2. 分批prefill让GPU计算资源不被长请求独占，能并行处理更多请求；
3. 显存碎片减少，KV缓存利用率提升
高并发+中等上下文（512~2048） ↑ 提升5%~20% 减少长请求的排队阻塞，整体请求处理效率更高
短上下文+低并发（<512 tokens，max_num_seqs ≤8） ↓ 下降≤5% 分批调度带来微小的CPU/GPU通信开销，且无并发排队问题可优化，纯增加少量损耗

五、实操建议（如何验证是否该启用）

  1. 先测基准：禁用该参数，跑典型请求场景，记录：
    • 吞吐量（tokens/sec）、P99 TTFT、显存峰值、OOM次数；
  2. 启用后对比：开启--enable-chunked-prefill（可搭配--chunked-prefill-size指定chunk大小，默认1024），重复测试；
  3. 判断标准：
    • 若吞吐量提升/显存下降/TTFT改善 → 保留启用；
    • 若吞吐量下降>5%且无显存问题 → 禁用。

总结

  1. 核心启用条件：长上下文（≥2048 tokens）、高并发、显存受限，这三类场景必开；
  2. 吞吐量影响：长上下文/高并发下提升，仅短上下文低并发时略有损耗（≤5%）；
  3. 关键逻辑：该参数的核心是「用微小的调度损耗，换显存利用率和并发效率的提升」，是长上下文推理的刚需优化。

如果需要，我可以给你一份完整的压测命令示例（包含该参数的调优），以及chunk size（--chunked-prefill-size）的最佳取值建议。

posted @ 2026-01-20 15:47  向着朝阳  阅读(270)  评论(0)    收藏  举报