大模型推理优化深度拆解：vLLM与TensorRT-LLM配置参数详解及选型实践

大语言模型落地过程中，推理吞吐与首Token延迟始终是核心瓶颈。传统HuggingFace Transformers单请求处理模式在并发场景下GPU利用率常不足30%，KV缓存内存碎片化严重。vLLM凭借PagedAttention以不到50行CUDA扩展将吞吐提升数十倍，而TensorRT-LLM借助图编译与插件生态，在MLPerf Inference v4.0中使GPT-J性能较v3.1提升达187%。本文从参数级别拆解两大框架的优化机理、关键配置项与硬件适配差异，为实际部署提供可复现的决策参考。## 一、推理优化的核心痛点与技术路线分化

一、推理优化的核心痛点与技术路线分化大模型自回归解码的本质决定了每个Token生成都需完整前向计算，KV缓存在长序列下呈平方增长。以HuggingFace默认的静态批处理为例，一个请求未结束前，整批GPU算力被迫等待，形成“木桶效应”。同时，非连续内存管理导致碎片严重，显存利用率常低于40%（据公开NVIDIA技术博客）。为破局，业界分化出两条主线：以vLLM为代表的动态批处理+PagedAttention路线，聚焦内存管理与并发调度；以NVIDIA TensorRT-LLM为代表的深度图编译路线，通过算子融合、量化与层间优化极致压榨硬件。两者均将GPT-J类模型推理吞吐提升至原生的3倍以上，但优化重点和参数体系截然不同。理解这些差异需要先把握推理引擎的三大杠杆指标：吞吐（Token/s）、延迟（TTFT/TPOT）和有效批大小上限。vLLM通过虚拟内存式KV管理提升有效批大小，TensorRT-LLM通过编译期优化降低每Token延迟。下文以vLLM v0.4.2和TensorRT-LLM v0.9.0为例，逐项解析关键配置参数及其作用域。## 二、vLLM：PagedAttention与调度参数的实战解析

二、vLLM：PagedAttention与调度参数的实战解析

vLLM的核心创新是将操作系统的分页思想引入KV缓存管理。其PagedAttention将每请求的KV缓存划分为固定大小的Block（默认block_size=16），物理上非连续存储，通过页表实现逻辑连续。这从根本上消灭了因序列长度差异导致的内存外部碎片，显存利用率可达96%以上。关键参数：- max_num_batched_tokens（默认2048）：一次迭代中最多处理的Token总数，直接决定计算强度。设置为GPU显存带宽的1/3-1/2可平衡延迟与吞吐，例如A100-80G可调至4096–8192。- max_num_seqs（默认256）：同一批次中最大并发序列数。资源受限于GPU显存，当请求长度差异大时，过高值可能触发预取失败，需配合gpu_memory_utilization（默认0.9）调优。- block_size：影响页表开销和计算效率。16适用于多数场景，短序列可考虑8以减少内部浪费，长序列64则减少页表尺寸。- swap_space：CPU内存用于KV缓存交换的空间（默认4GB）。高性能SSD下可提高，作为显存溢出的缓冲。调度策略参数：vLLM的Continuous Batching允许在同一迭代中解耦请求的到达与完成。max_paddings（已废弃，由max_num_batched_tokens替代）曾控制填充上限。当前版本通过preemption_mode处理抢占（swap或recompute），当显存不足时，可启用swap预留更多批次。实践中，部署LLaMA-2-70B在4×A100-80G上，推荐配置：tensor-parallel-size=4, max_num_batched_tokens=8192, max_num_seqs=128, gpu_memory_utilization=0.92。通过调整max_num_batched_tokens从2048升至8192，在ShareGPT数据集上实测吞吐可从2300 Token/s提升至5100 Token/s，但TTFT会从120ms升至210ms，需按SLO取舍。

三、TensorRT-LLM：图编译优化与Inflight Batching参数体系

TensorRT-LLM走编译优化路线，通过将模型转换为TensorRT Engine，在构建期执行算子融合（如LayerNorm+MLP融合）、张量内存布局优化、多流并发和FP8/INT4量化校准。其In-Flight Batching与vLLM的Continuous Batching理念相似，但实现上依赖运行时调度器和专门的请求队列。核心参数分为构建期与运行期。构建期（trtllm-build）关键选项：- --max_batch_size（默认256）：Engine可处理最大批次大小，影响内存预分配。设置过大会浪费显存，过小则限制并发。- --max_input_len与--max_output_len：必须覆盖业务最大输入输出长度。两者乘积决定KV缓存最大占用，77B模型512输入+256输出，单请求需约64GB KV缓存（FP16）。- --paged_kv_cache：启用PagedKV，与vLLM理念一致，但TensorRT-LLM的block大小可配置（默认128），大block利于吞吐，小block减少内部浪费。- --use_fp8/--int8_kv_cache：需提前用calibration数据集生成量化表。据MLPerf Inference v4.0提交结果，FP8量化使GPT-J性能较FP16提升约187%，延迟降低60%以上。

• --plugins：加载自定义算子如gemm_plugin、rmsnorm_plugin，可进一步提高特定GPU（如H100）效率。运行期参数（GptManager）：- max_tokens_in_paged_kv_cache：限制页表池大小，结合kv_cache_free_gpu_mem_fraction（默认0.9）控制显存占用，避免OOM。- scheduler_policy：MAX_UTILIZATION优先填满批次以最大化吞吐，GUARANTEED_NO_EVICT则满足延迟SLA。- enable_trt_overlap：启用计算与通信重叠，尤其在TP>1时有效，可降低10-15%延迟。以GPT-J 6B部署为例，TensorRT-LLM v0.9.0配置：max_batch_size=64, max_input_len=1024, max_output_len=256, paged_kv_cache, use_fp8, scheduler_policy=MAX_UTILIZATION，在A10 GPU上可实现吞吐420 Token/s，是vLLM同配置的1.4倍，但首次构建Engine耗时约15分钟。## 四、对比分析、硬件适配与选型实践建议

两大框架的性能天花板与灵活性互有取舍。从吞吐极致性看，TensorRT-LLM因编译优化优势明显，尤其适配NVIDIA新硬件特性（如Hopper架构FP8 Transformer Engine）。MLPerf Inference v4.0数据显示其GPT-J 99% Tail Latency较v3.1提升187%，DLRM v2提升67%，这与TensorRT-LLM的深层融合与量化直接相关。vLLM在通用性和快速原型上更优，无需模型转换，支持更多第三方模型且开发成本低。
硬件适配差异显著：基于CUDA 12生态，TensorRT-LLM为NVIDIA原生，vLLM同样原生支持NVIDIA GPU并通过ROCm 6提供AMD官方wheel。但在国产算力方面，现有资料显示CANN栈（昇腾NPU）对vLLM的支持仍处于适配阶段，TensorRT-LLM暂未支持非NVIDIA硬件。因此若业务存在多架构部署需求，vLLM具有更高的跨平台可移植性；若锁定NVIDIA H100/L40S等新硬件且对延迟极度敏感，TensorRT-LLM+FP8组合往往是首选。选型决策矩阵：- 场景1：内部对话机器人，2-3秒可接受延迟 → vLLM，利用其易部署和丰富参数快速调优。- 场景2：在线客服，<500ms TTFT硬约束 → TensorRT-LLM，开启Inflight Batching+FP8+GUARANTEED_NO_EVICT策略。- 场景3：模型评估/批量离线推理 → vLLM，配合preemption_mode=swap最大化吞吐。- 场景4：代码生成（长输出） → TensorRT-LLM的激进KV Cache优化更优，配合paged_kv_cache和紧凑block_size。关键参数速记：vLLM主调max_num_batched_tokens、max_num_seqs和gpu_memory_utilization；TensorRT-LLM关注构建期max_batch_size、量化开关以及运行时调度策略。建议以实际业务数据构建轻量基准测试，对比P99延迟与显存占用，避免仅凭峰值吞吐做决策。

vLLM与TensorRT-LLM分别代表了动态批处理与编译优化的最高水平，背后是对内存、计算和并发调度的不同理解。配置参数的细节差异直接影响生产环境的ROI。建议团队结合硬件路线与业务SLO，将参数调优作为持续性工程的一部分。在CUDA 12与Hopper架构加持下，推理优化仍有显著红利可挖，而随着vLLM对PagedAttention V2和TensorRT-LLM对FP8的持续深化，这一领域的迭代速度正不断加快。