大模型推理部署实战vLLM与TensorRT-LLM配置参数深度解析90%的大模型推理性能瓶颈并非来自模型本身而是推理引擎的参数配置不当。vLLM的PagedAttention与TensorRT-LLM的in-flight batching在吞吐和延迟上相差可达数倍但若不了解其核心参数含义极易触发OOM、P99延迟飙升等问题。本文基于vLLM 0.4.2与TensorRT-LLM 0.9.0实测逐一拆解两大引擎的配置项给出可复现的调优方案。1. 背景与痛点为什么推理引擎参数如此重要大语言模型推理面临三大挑战自回归解码的串行性、KV Cache的动态内存占用、以及变长请求的批处理效率。通用框架如PyTorch原生推理常因缺乏连续批处理或内存复用机制导致GPU利用率不足30%。据《MLPerf_Inference_v4_Training_基准测试》显示TensorRT-LLM优化后GPT-J在线推理性能提升约187%99%尾延迟条件而vLLM在同等硬件上通过PagedAttention可将吞吐量提升至HuggingFace TGI的2-3倍。但这些提升高度依赖参数配置不当的max_num_batched_tokens或max_batch_size可能使显存闲置或引发频繁重计算。因此深入理解两大引擎的核心参数成为生产部署的必修课。2. vLLM核心参数与配置实践vLLM通过PagedAttention管理KV Cache将物理显存划分为Block按需分配有效减少碎片。其参数集中在vllm.entrypoints.openai.api_server启动命令和AsyncLLMEngine中。关键参数表参数含义默认值调优建议--gpu-memory-utilization预留给KV Cache的GPU显存比例0.90A100-80G可设为0.95若同时运行其他进程降低至0.85--max-num-seqs最大并发序列数256与max_num_batched_tokens配合高吞吐场景可设256~512--max-num-batched-tokens单次迭代处理的最大Token数取决于模型应max_model_len且不超过max_num_seqs * max_model_len建议4096~8192--max-model-len单个序列的最大长度prompt生成模型上下文长度按需降低可减少显存占用例如从4096减至2048--tensor-parallel-size张量并行度1大模型13B跨多卡时设置需能被注意力头数整除--enable-prefix-caching开启前缀缓存True多轮对话场景建议开启可复用相同系统提示的KV Cache配置示例python-mvllm.entrypoints.openai.api_server\--modelmeta-llama/Llama-2-7b-chat-hf\--gpu-memory-utilization0.95\--max-num-seqs256\--max-num-batched-tokens4096\--max-model-len2048\--tensor-parallel-size1\--enable-prefix-caching\--port8000避坑指南gpu-memory-utilization设置过高可能导致CUDA OOM建议预留5%~10%给PyTorch临时分配。若出现max_num_batched_tokens小于max_model_lenvLLM会报错需确保前者大于等于后者。在ROCm 6上运行vLLM需使用官方wheel且暂不支持FlashAttention 3性能约为CUDA同配置的80%参考《CUDA12_ROCm6_CANN_GPU驱动框架对比》。3. TensorRT-LLM核心参数与配置实践TensorRT-LLM采用in-flight batching连续批处理允许请求在生成过程中动态加入/离开批次极大提升GPU占用率。其配置分为构建阶段trtllm-build和运行阶段mpirun run.py。关键参数表参数阶段含义默认值调优建议--max_batch_size构建最大批处理大小无显存充足时设为64~128需与max_input_len/max_output_len联合计算显存--max_input_len构建最大输入长度2048可根据业务prompt长度调整超过会截断或拒绝--max_output_len构建最大生成长度512长文本生成场景可增至1024但会消耗更多KV Cache--paged_kv_cache构建启用分页KV Cache默认开启建议始终开启等同于vLLM的PagedAttention--remove_input_padding构建去除输入填充建议开启减少无效计算提升吞吐--gemm_plugin构建使用GEMM插件精度float16可设为float16或bfloat16Hopper架构可尝试int8--max_num_tokens运行每批次最大Token数无需≤max_batch_size * (max_input_lenmax_output_len)防止OOM构建与运行示例# 构建引擎python examples/llama/build.py\--model_dirmeta-llama/Llama-2-7b-chat-hf\--output_dir./llama2_engine\--dtypefloat16\--max_batch_size64\--max_input_len2048\--max_output_len512\--paged_kv_cacheon\--remove_input_paddingon\--gemm_pluginfloat16# 运行推理mpirun-n1--allow-run-as-root\python3 run.py\--engine_dir./llama2_engine\--tokenizer_dirmeta-llama/Llama-2-7b-chat-hf\--max_output_len512\--input_textHello, I am a language model,避坑指南构建阶段的max_batch_size、max_input_len、max_output_len三者乘积直接决定KV Cache显存占用一旦设定无法动态调整需留有一定余量。TensorRT-LLM仅支持CUDA据《CUDA12_ROCm6_CANN_GPU驱动框架对比》不计划支持ROCmAMD用户需转向vLLM或ROCm原生方案。在H100上启用--use_fp8可进一步降低显存但需配合fp8量化模型构建时需指定--quant_ckpt_path。4. 横向对比与选型建议特性对比表维度vLLM 0.4.2TensorRT-LLM 0.9.0核心技术PagedAttentionin-flight batching 图优化硬件支持CUDA、ROCm (wheel)仅CUDA模型支持主流HuggingFace模型需转换支持更广的量化格式部署复杂度低pip安装即用中需构建引擎吞吐量7B模型高同等硬件可达TGI 2-3倍更高通过编译优化略胜一筹首Token延迟较低略高引擎加载时间多轮对话缓存原生支持prefix caching需自行管理KV Cache复用量化支持AWQ、GPTQ、SqueezeLLMFP8、INT8、INT4等社区生态活跃更新快NVIDIA官方维护稳定选型与调优建议快速原型验证或需要ROCm环境首选vLLM其命令行参数直观开箱即用。追求极致吞吐且硬件为NVIDIATensorRT-LLM通过编译优化可获得额外10%~20%吞吐提升但需投入构建成本。关键参数调优路径先设定max_batch_size/max_num_seqs再根据显存占用调整gpu_memory_utilizationvLLM或max_batch_size×max_input_lenTensorRT-LLM最后通过max_num_batched_tokens/max_num_tokens控制单次计算量。多轮对话场景vLLM的enable-prefix-caching可显著降低首Token延迟建议开启。需要留意昇腾CANN目前不支持vLLM和TensorRT-LLM来源《CUDA12_ROCm6_CANN_GPU驱动框架对比》国产硬件可考虑MindSpore原生推理或SGLang适配方案。无论是vLLM的PagedAttention还是TensorRT-LLM的in-flight batching参数配置是性能释放的钥匙。本文梳理了20余项核心参数实测配置可直接用于生产环境。数据来源MLPerf Inference v4.0基准测试、《CUDA12_ROCm6_CANN_GPU驱动框架对比》文档。 
长河君 · 2026/8/11 19:53:45 · 阅读 1.2k 大模型推理部署实战：vLLM与TensorRT-LLM配置参数深度解析
大模型推理部署实战vLLM与TensorRT-LLM配置参数深度解析90%的大模型推理性能瓶颈并非来自模型本身而是推理引擎的参数配置不当。vLLM的PagedAttention与TensorRT-LLM的in-flight batching在吞吐和延迟上相差可达数倍但若不了解其核心参数含义极易触发OOM、P99延迟飙升等问题。本文基于vLLM 0.4.2与TensorRT-LLM 0.9.0实测逐一拆解两大引擎的配置项给出可复现的调优方案。1. 背景与痛点为什么推理引擎参数如此重要大语言模型推理面临三大挑战自回归解码的串行性、KV Cache的动态内存占用、以及变长请求的批处理效率。通用框架如PyTorch原生推理常因缺乏连续批处理或内存复用机制导致GPU利用率不足30%。据《MLPerf_Inference_v4_Training_基准测试》显示TensorRT-LLM优化后GPT-J在线推理性能提升约187%99%尾延迟条件而vLLM在同等硬件上通过PagedAttention可将吞吐量提升至HuggingFace TGI的2-3倍。但这些提升高度依赖参数配置不当的max_num_batched_tokens或max_batch_size可能使显存闲置或引发频繁重计算。因此深入理解两大引擎的核心参数成为生产部署的必修课。2. vLLM核心参数与配置实践vLLM通过PagedAttention管理KV Cache将物理显存划分为Block按需分配有效减少碎片。其参数集中在vllm.entrypoints.openai.api_server启动命令和AsyncLLMEngine中。关键参数表参数含义默认值调优建议--gpu-memory-utilization预留给KV Cache的GPU显存比例0.90A100-80G可设为0.95若同时运行其他进程降低至0.85--max-num-seqs最大并发序列数256与max_num_batched_tokens配合高吞吐场景可设256~512--max-num-batched-tokens单次迭代处理的最大Token数取决于模型应max_model_len且不超过max_num_seqs * max_model_len建议4096~8192--max-model-len单个序列的最大长度prompt生成模型上下文长度按需降低可减少显存占用例如从4096减至2048--tensor-parallel-size张量并行度1大模型13B跨多卡时设置需能被注意力头数整除--enable-prefix-caching开启前缀缓存True多轮对话场景建议开启可复用相同系统提示的KV Cache配置示例python-mvllm.entrypoints.openai.api_server\--modelmeta-llama/Llama-2-7b-chat-hf\--gpu-memory-utilization0.95\--max-num-seqs256\--max-num-batched-tokens4096\--max-model-len2048\--tensor-parallel-size1\--enable-prefix-caching\--port8000避坑指南gpu-memory-utilization设置过高可能导致CUDA OOM建议预留5%~10%给PyTorch临时分配。若出现max_num_batched_tokens小于max_model_lenvLLM会报错需确保前者大于等于后者。在ROCm 6上运行vLLM需使用官方wheel且暂不支持FlashAttention 3性能约为CUDA同配置的80%参考《CUDA12_ROCm6_CANN_GPU驱动框架对比》。3. TensorRT-LLM核心参数与配置实践TensorRT-LLM采用in-flight batching连续批处理允许请求在生成过程中动态加入/离开批次极大提升GPU占用率。其配置分为构建阶段trtllm-build和运行阶段mpirun run.py。关键参数表参数阶段含义默认值调优建议--max_batch_size构建最大批处理大小无显存充足时设为64~128需与max_input_len/max_output_len联合计算显存--max_input_len构建最大输入长度2048可根据业务prompt长度调整超过会截断或拒绝--max_output_len构建最大生成长度512长文本生成场景可增至1024但会消耗更多KV Cache--paged_kv_cache构建启用分页KV Cache默认开启建议始终开启等同于vLLM的PagedAttention--remove_input_padding构建去除输入填充建议开启减少无效计算提升吞吐--gemm_plugin构建使用GEMM插件精度float16可设为float16或bfloat16Hopper架构可尝试int8--max_num_tokens运行每批次最大Token数无需≤max_batch_size * (max_input_lenmax_output_len)防止OOM构建与运行示例# 构建引擎python examples/llama/build.py\--model_dirmeta-llama/Llama-2-7b-chat-hf\--output_dir./llama2_engine\--dtypefloat16\--max_batch_size64\--max_input_len2048\--max_output_len512\--paged_kv_cacheon\--remove_input_paddingon\--gemm_pluginfloat16# 运行推理mpirun-n1--allow-run-as-root\python3 run.py\--engine_dir./llama2_engine\--tokenizer_dirmeta-llama/Llama-2-7b-chat-hf\--max_output_len512\--input_textHello, I am a language model,避坑指南构建阶段的max_batch_size、max_input_len、max_output_len三者乘积直接决定KV Cache显存占用一旦设定无法动态调整需留有一定余量。TensorRT-LLM仅支持CUDA据《CUDA12_ROCm6_CANN_GPU驱动框架对比》不计划支持ROCmAMD用户需转向vLLM或ROCm原生方案。在H100上启用--use_fp8可进一步降低显存但需配合fp8量化模型构建时需指定--quant_ckpt_path。4. 横向对比与选型建议特性对比表维度vLLM 0.4.2TensorRT-LLM 0.9.0核心技术PagedAttentionin-flight batching 图优化硬件支持CUDA、ROCm (wheel)仅CUDA模型支持主流HuggingFace模型需转换支持更广的量化格式部署复杂度低pip安装即用中需构建引擎吞吐量7B模型高同等硬件可达TGI 2-3倍更高通过编译优化略胜一筹首Token延迟较低略高引擎加载时间多轮对话缓存原生支持prefix caching需自行管理KV Cache复用量化支持AWQ、GPTQ、SqueezeLLMFP8、INT8、INT4等社区生态活跃更新快NVIDIA官方维护稳定选型与调优建议快速原型验证或需要ROCm环境首选vLLM其命令行参数直观开箱即用。追求极致吞吐且硬件为NVIDIATensorRT-LLM通过编译优化可获得额外10%~20%吞吐提升但需投入构建成本。关键参数调优路径先设定max_batch_size/max_num_seqs再根据显存占用调整gpu_memory_utilizationvLLM或max_batch_size×max_input_lenTensorRT-LLM最后通过max_num_batched_tokens/max_num_tokens控制单次计算量。多轮对话场景vLLM的enable-prefix-caching可显著降低首Token延迟建议开启。需要留意昇腾CANN目前不支持vLLM和TensorRT-LLM来源《CUDA12_ROCm6_CANN_GPU驱动框架对比》国产硬件可考虑MindSpore原生推理或SGLang适配方案。无论是vLLM的PagedAttention还是TensorRT-LLM的in-flight batching参数配置是性能释放的钥匙。本文梳理了20余项核心参数实测配置可直接用于生产环境。数据来源MLPerf Inference v4.0基准测试、《CUDA12_ROCm6_CANN_GPU驱动框架对比》文档。