大模型部署参数调优清单

面向生产推理服务的参数设置依据与实施方法

适用框架 vLLM TensorRT LLM TGI SGLang llama.cpp

版本 1.0

日期 2026年10月30日

文档说明

本清单用于大模型推理服务的容量规划、参数配置、性能压测和生产验收。核心方法是先明确服务级目标，再确定模型与显存边界，随后调节批处理和调度参数，最后完成高级优化、稳定性压测和上线验收。

核心结论：不存在脱离模型、硬件和请求分布的通用最优参数。最终配置应在满足延迟和稳定性目标的前提下，使单位GPU吞吐或单位token成本达到最优。

推荐使用方式

  • 用真实请求构建固定压测集，至少覆盖输入长度、输出长度、并发和长短混合分布。

  • 每轮只改变一组相关参数，并记录配置、框架版本、硬件、性能和质量结果。

  • 同时观察P50、P95和P99，不以平均延迟代替长尾指标。

  • 先完成单实例调优，再进行多副本负载均衡和自动扩缩容。

目录

一 调优目标与指标体系

业务场景与目标优先级

业务类型 第一目标 第二目标 典型特点
在线聊天 首token延迟 TTFT P99延迟与TPOT 输入中等，持续流式输出
Agent与代码生成 每token延迟 TPOT 长上下文稳定性 输出长，工具调用多
RAG问答 TTFT与前缀缓存命中率 吞吐 系统提示和检索模板重复
离线批处理 总吞吐 tokens/s 单位token成本 可充分合批，单请求延迟不敏感
文档摘要 长输入Prefill吞吐 显存容量 输入长，Prefill占比高
多租户API P99与租户隔离 GPU利用率 请求长度差异大

必须监控的性能指标

  • TTFT：收到请求到生成第一个token的时间。

  • TPOT或ITL：生成阶段相邻token的平均间隔。

  • 端到端延迟：请求从进入系统到完整完成的时间。

  • 输出吞吐：每秒生成的token数；总吞吐还包括输入token。

  • 请求吞吐：每秒完成请求数。

  • 排队时间：用于区分模型执行慢与请求等待。

  • GPU指标：计算利用率、显存使用、内存带宽、功耗、温度、NVLink或PCIe流量及硬件错误。

服务级目标示例

P95 TTFT小于800毫秒

P99 TTFT小于2秒

P95 TPOT小于40毫秒每token

单实例输出吞吐达到业务基准

GPU显存峰值低于95%

OOM率为0，5xx错误率低于0.1%

二 模型精度与量化

dtype计算精度

硬件或场景 建议起点 设置依据
A100 H100 H200 B100 B200 BF16 动态范围较FP16宽，训练与推理通常更稳定
V100 T4及部分消费卡 FP16 硬件支持通常更成熟
H100及更新GPU BF16与FP8对比 测试FP8的吞吐和显存收益，并回归质量
CPU部署 INT8 INT4或GGUF 通常受内存容量和带宽限制
显存不足 AWQ GPTQ Marlin INT4 优先降低权重显存，为KV Cache腾出空间

设置依据

  • 模型以BF16训练时优先BF16；FP16出现溢出、NaN或分布异常时切换BF16。

  • 量化后必须验证指令遵循、长文本、数学、代码、JSON输出、工具调用和多轮一致性。

  • 量化减少权重显存，但吞吐收益取决于量化内核、解包开销和实际瓶颈。

  • 建议按BF16基准、FP16、FP8、INT8、INT4的顺序逐级验证。

quantization量化方式

选项 适用场景 注意事项
AWQ或GPTQ Marlin NVIDIA GPU在线服务 需要匹配专用高性能内核
FP8 H100及更新GPU 需验证模型质量和KV精度
GGUF Q4 K M或Q5 K M CPU和边缘设备 平衡内存、速度和质量
INT4 极端显存约束 质量下降风险最高
BF16或FP16 质量优先 占用较大但基线可靠

验收建议：质量下降不超过业务阈值，吞吐或可承载并发提升至少15%至20%，单位token成本下降，且P99延迟和错误率没有明显恶化。

三 上下文与输出长度

参数 建议与典型范围 设置依据及风险
max_model_len或max_seq_len 普通池8K或16K；长上下文池32K或64K；超长池128K以上 按真实请求P99设置。过大会增加KV Cache、Prefill计算、驻留时间和长尾风险
max_input_tokens 输入长度P99加安全余量 RAG同时控制召回数量、分段长度和拼接总量
max_new_tokens 分类32至256；问答512至2048；代码2048至8192；推理模型按预算限制 过大的声明值会降低调度器可接纳并发并增加成本
max_total_tokens max_input_tokens加max_new_tokens 是单请求内存预算的重要上限，不应无条件等于模型最大上下文

服务分层建议

/chat       max_new_tokens <= 2048

/extract    max_new_tokens <= 512

/code       max_new_tokens <= 8192

/reasoning  max_new_tokens <= 16384

四 KV Cache与显存

参数 推荐起点 设置依据
gpu_memory_utilization 独占GPU 0.90至0.95；容器化0.85至0.92；共享GPU 0.70至0.85 过低限制并发，过高会挤压CUDA图、临时张量和通信缓冲区
kv_cache_free_gpu_mem_fraction 独占GPU可测试至0.95但不可设为1 仍需为输入输出和运行时缓冲保留空间
kv_cache_dtype BF16或FP16为质量基线；FP8用于高并发或长上下文 KV量化可提高可服务token数，但需验证长上下文回忆与结构化输出
block_size 短请求8或16；通用16或32；长上下文32或64 小块减少尾部浪费，大块降低元数据与调度开销
swap_space或KV Offload 只作为保护机制 常态换入换出会造成PCIe传输和P99抖动

KV Cache容量估算

单token KV字节数 ≈ 2 × 层数 × KV头数 × head_dim × dtype字节数

总KV显存 ≈ 并发序列数 × 平均驻留token数 × 单token KV字节数

GQA和MQA模型的KV头数量较少，KV占用通常明显低于标准MHA模型。容量规划必须同时考虑模型权重和KV Cache；权重能装入GPU不代表目标并发能够实现。

Prefix Cache前缀缓存

  • 适用于固定系统提示、共享RAG模板、多轮会话、Few shot示例和重复工具说明。

  • 稳定内容放在Prompt前部，用户变量放在后部；移除时间戳、请求ID和随机字段。

  • 统一JSON字段与工具描述顺序，避免语义相同但token序列不同。

  • 监控命中率、节省的Prefill token和缓存内存；命中率低时不应盲目扩大缓存。

五 批处理与调度

参数 推荐扫描范围 调优依据
max_num_seqs或max_batch_size 1 2 4 8 16 32 64 128 256 太小GPU吃不满；太大会增加KV竞争、调度开销并恶化P99
max_num_batched_tokens 1024 2048 4096 8192 16384 32768 较小通常有利TPOT；较大通常有利TTFT和Prefill吞吐
max_batch_prefill_tokens 根据输入分布扫描 过小长Prompt拆分过细；过大会阻塞正在decode的请求
max_batch_total_tokens 从保守值每次增加10%至25% 直到吞吐不再提升、P99恶化、显存余量过小或发生OOM
prefill_chunk_size 512 1024 2048 4096 8192 小块使decode平滑，大块提高Prefill效率
max_waiting_tokens 结合queue_wait与TPOT调节 过小会频繁插入Prefill，过大会增加新请求等待

场景化起点

场景 max_num_batched_tokens max_num_seqs 关注指标
在线聊天 2048至8192 16至64 P95与P99 TTFT TPOT
RAG问答 4096至16384 16至64 TTFT与前缀命中率
长文档摘要 8192至32768 4至32 Prefill吞吐和短请求干扰
离线批处理 16384至65536以上 128至1024 tokens每秒和单位成本

调度策略

  • 普通API以FCFS作为基线。

  • 多租户使用优先级和每租户并发及token限额。

  • 在线与离线业务应分队列或分实例，不依赖单一优先级解决隔离。

  • 长短请求混合时按预计token成本分类，必要时采用前缀感知或截止时间调度。

六 并行策略

并行方式 适用条件 主要代价与决策依据
Tensor Parallel TP 单卡放不下权重或KV，或需要降低单请求延迟 每层跨GPU通信；选择能够放下模型的最小TP，再测试更大TP是否改善SLO
Pipeline Parallel PP 模型跨节点或无法用合理TP部署 存在流水线气泡和阶段不均衡；单节点内通常优先TP
Data Parallel DP 单副本可放入GPU，需要水平扩展吞吐 多个完整模型副本；负载均衡应依据活跃token而非仅请求数
Expert Parallel EP MoE模型 关注专家路由倾斜、All to All时间和跨节点拓扑

负载均衡权重

request_cost = α × input_tokens + β × requested_output_tokens + γ × active_decode_time

仅按请求数轮询会导致接收长请求的副本过载。推荐同时使用当前活跃token、KV Cache占用和预计完成时间作为路由依据。

七 CUDA与内核优化

优化项 建议 验证重点
Flash Attention 默认优先开启 长上下文正确性、特殊mask、多模态和版本兼容
CUDA Graph 为高频batch size捕获，如1 2 4 8 16 32 额外显存、预热时间和动态shape回退
enforce_eager 性能基线设为false；排障时临时设为true 不应把强制Eager作为永久稳定性修复
融合算子与自定义Kernel 逐项开启并做A B测试 硬件适配、输出一致性、升级后的重新验证
Speculative Decoding 输出长且草稿模型命中率高时测试 接受率、额外显存、端到端收益

八 CPU NUMA与卸载

参数或配置 设置建议 依据
CPU线程数 按物理核心和GPU数量设置；限制Tokenizer与HTTP线程池 CPU饱和会使GPU空闲并推高TTFT
NUMA绑定 服务进程、Pinned Memory和GPU绑定到相近NUMA节点 减少跨NUMA访问和PCIe路径开销
cpu_offload_gb 仅在显存略不足且可容忍高延迟时使用 以主存和PCIe传输换显存，不适合高吞吐在线服务
KV Offload 仅用于抢占和峰值保护 高频换入换出说明容量配置不合理

CPU瓶颈症状

  • GPU利用率低但CPU个别核心达到100%。

  • 并发增加后TTFT突然上升，而GPU显存仍有余量。

  • 从单GPU扩展到多GPU后吞吐没有按预期增长。

  • JSON序列化、Tokenization或流式网络输出占用大量CPU时间。

九 采样与生成参数

参数 常见设置 设置依据
temperature 抽取0至0.2；RAG 0至0.4；聊天0.6至0.9；创意0.8至1.2 影响随机性、输出长度、结构化成功率和重试成本
top_p 通常0.8至1.0 不要与temperature和top_k同时激进调整
top_k 0或20至100 结构化输出应优先使用Schema或Grammar约束
repetition_penalty 通常1.0至1.1 过高会破坏代码、表格、引用和正常中文重复
n或best_of 在线服务默认限制为1 计算和KV占用接近倍数增加
logprobs 默认关闭并限制top_logprobs 增加GPU计算、CPU处理和响应体大小

十 并发 队列 限流与超时

最大并发与队列

最大可接受排队请求数 ≈ 目标到达率 × 最大容忍排队时间

队列过大不会提高容量，只会把拒绝转化为长时间等待。客户端超时后若服务端仍继续生成，还会造成GPU浪费。

建议拆分的超时

  • queue_timeout：排队超时后快速返回429或503。

  • ttft_timeout：首token未在目标时间内产生时取消。

  • idle_stream_timeout：流式输出长时间无token时取消。

  • request_total_timeout：限制端到端总时长。

  • 客户端断连必须向推理引擎传播取消并释放KV Cache。

限流维度

  • 每秒请求数和并发请求数。

  • 每分钟输入token与输出token。

  • 单请求最大输入、输出和总token。

  • 每租户活跃KV token及长上下文请求占比。

  • n、best_of和logprobs上限。

十一 多实例与自动扩缩容

主题 建议 依据
多个小实例 延迟优先、流量波动大、需要隔离和滚动升级 排队更短，故障域更小，但动态批处理池较小
单个大实例 吞吐优先、流量稳定 KV池更大，批处理效率更高，但故障影响更大
MIG 小模型、多租户硬隔离 资源无法互借，大模型和峰值流量适应性较弱
扩容指标 queue_wait pending_requests active_tokens KV利用率 TTFT 不要仅以GPU计算利用率作为扩容依据
预热 模型加载、JIT、CUDA Graph、NCCL和典型请求完成后再接流量 端口可用不等于实例已达到稳定性能

扩缩容规则示例

扩容：P95 queue_wait > 300 ms 持续2分钟

或 pending_requests > 每实例目标队列 × 副本数

或 KV cache utilization > 85%

缩容：低负载持续10至20分钟后再执行

十二 场景化推荐起点

场景 推荐起始配置
在线聊天 延迟优先 BF16；最小可容纳模型的TP；上下文8K至16K；显存利用率0.88至0.92；max_num_seqs 16至64；batched tokens 2048至8192；开启chunked prefill prefix cache CUDA Graph
RAG服务 上下文16K至32K；按拼接后P99限制输入；输出512至2048；开启前缀缓存与分块Prefill；batched tokens 4096至16384
离线批量生成 max_num_seqs 128至1024；batched tokens 16384至65536以上；显存利用率0.92至0.97；目标为最大化tokens每秒
长上下文服务 上下文32K至模型验证上限；max_num_seqs 4至32；batched tokens 4096至32768；开启分块Prefill和前缀缓存；测试FP8 KV
CPU或边缘设备 GGUF Q4 K M或Q5 K M；线程接近物理核心数；严格限制上下文；batch从128 256 512扫描

十三 常见问题与处理顺序

GPU利用率低

  • 确认请求量是否足够。

  • 增加max_num_seqs或max_num_batched_tokens。

  • 检查CPU、Tokenizer、同步点和网络流式输出。

  • 检查TP是否过大以及优化Attention和Kernel是否启用。

显存很多但吞吐低

  • 批次限制过小或流量不足。

  • CPU调度、Tokenization或序列化成为瓶颈。

  • 跨GPU通信过高或TP规模过大。

  • CUDA Graph没有覆盖高频batch。

  • 量化内核或模型结构没有使用优化实现。

OOM处理顺序

  • 降低gpu_memory_utilization或KV Cache比例。

  • 降低max_num_batched_tokens。

  • 降低max_num_seqs。

  • 降低max_model_len、max_input_tokens和max_new_tokens。

  • 使用权重量化或FP8 KV Cache。

  • 检查CUDA Graph和临时缓冲区。

  • 增加TP或GPU数量，并排查重复进程占用。

TTFT高但TPOT正常

优先减少排队、增加Prefill预算、开启Flash Attention和Prefix Cache、减少输入长度或增加副本。

TTFT正常但TPOT高

优先减少活跃decode batch、降低batched tokens、减小Prefill块、减少Prefill插入频率、检查内存带宽和TP通信。

平均延迟正常但P99很差

重点检查长短请求混跑、输出上限、KV Cache接近满载、抢占与swap、多租户隔离、CPU或网络抖动、GPU降频以及断连请求未取消。

十四 标准调优流程

阶段一 建立基线：固定模型、权重、Tokenizer、硬件、驱动、CUDA、框架、Prompt模板、压测集和采样参数。

阶段二 确定容量边界：依次确定dtype与量化、TP、上下文长度、输入输出上限、显存比例和KV精度。

阶段三 调批处理：对max_num_seqs、max_num_batched_tokens和显存比例进行二维或三维网格搜索。

阶段四 平衡Prefill与Decode：测试chunked prefill、prefill chunk、waiting tokens等参数，在TTFT与TPOT之间取舍。

阶段五 开启高级优化：逐项启用Flash Attention、CUDA Graph、Prefix Cache、FP8 KV和投机解码。

阶段六 稳定性压测：完成稳态、峰值、突发、长短混合、极长输出、断连、故障和滚动升级测试。

推荐网格搜索

max_num_seqs: 8, 16, 32, 64, 128

max_num_batched_tokens: 2048, 4096, 8192, 16384

gpu_memory_utilization: 0.85, 0.90, 0.93

每个组合至少运行足够长时间，覆盖预热后的稳态区间，并保存P50、P95、P99、吞吐、显存峰值、错误率和质量回归结果。

十五 上线验收清单

  • 模型版本、权重哈希和Tokenizer版本固定。

  • 驱动、CUDA、NCCL和推理引擎版本固定。

  • BF16、FP16或量化模型通过业务质量回归。

  • max_input_tokens按真实分布设置。

  • max_new_tokens由服务端限制。

  • 长短上下文请求已决定是否分池。

  • 显存利用率保留峰值安全余量。

  • KV Cache容量覆盖目标并发。

  • max_num_seqs经过真实压测。

  • max_num_batched_tokens经过TTFT和TPOT权衡。

  • Chunked Prefill经过真实长Prompt测试。

  • Prefix Cache命中率有监控。

  • CUDA Graph只覆盖高频shape。

  • 客户端取消能释放生成任务。

  • 请求队列有硬上限。

  • 按用户限制RPS、并发和token。

  • 监控TTFT、TPOT、排队时间和P99。

  • 监控显存、利用率、温度、功耗和硬件错误。

  • 自动扩容不只依赖GPU利用率。

  • 新实例完成预热后再接流量。

  • 通过峰值、突发、长短混合和断连压测。

  • 上线配置比OOM边界至少回退一个安全档位。

  • 配置变更支持灰度、回滚并关联性能数据。

十六 参数实验记录模板

字段 记录内容
实验编号 日期与唯一编号
模型与精度 模型版本 dtype 量化方式
硬件 GPU型号 数量 拓扑 CPU与内存
软件栈 驱动 CUDA NCCL 推理引擎版本
请求分布 输入与输出长度P50 P95 P99 并发 到达率
核心参数 TP PP DP 上下文 KV 批处理 调度
性能结果 TTFT TPOT E2E 吞吐 显存 GPU利用率
质量结果 任务准确率 结构化成功率 长上下文回忆
稳定性 OOM 5xx 取消成功率 P99抖动
结论 保留 淘汰或进入下一轮测试

结语

大模型部署调优的本质，是在模型质量、延迟、吞吐、显存、稳定性和成本之间进行约束优化。建议以真实流量分布和明确SLO为基础，对并行方式、精度与量化、KV Cache、批处理、上下文长度和Prefill策略进行联合搜索，最终选择满足延迟目标、P99稳定、无OOM且单位GPU产出最高的配置。