大模型推理优化实战：vLLM与TensorRT-LLM部署性能对比

大模型推理优化是AI模型部署环节的核心瓶颈。当模型参数达到70B甚至更大规模时，推理延迟、吞吐量和显存利用率直接影响线上服务质量。当前主流推理框架中，vLLM凭借PagedAttention机制占据开源生态主导地位，TensorRT-LLM则在NVIDIA硬件上展现出极致性能。本文通过实际部署测试，对比两种框架在Llama-3-70B模型上的推理性能表现，给出生产环境选型建议。

vLLM推理框架部署与PagedAttention机制配置

vLLM的核心创新在于PagedAttention，将KV Cache按固定大小的block管理，类似操作系统的虚拟内存分页机制。这种方式将显存碎片率从传统方案的60%以上降低到4%以内，显著提升并发处理能力。

安装vLLM并启动推理服务：

# 安装vLLM（需CUDA 12.1+）
pip install vllm

# 启动OpenAI兼容API服务
python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Meta-Llama-3-70B-Instruct \
    --tensor-parallel-size 4 \
    --gpu-memory-utilization 0.90 \
    --max-model-len 8192 \
    --enable-prefix-caching \
    --swap-space 16 \
    --port 8000

关键参数说明：

• --tensor-parallel-size 4：4卡张量并行，70B模型需要至少4张A100-80G
• --gpu-memory-utilization 0.90：显存利用率上限，预留10%给系统进程
• --enable-prefix-caching：启用前缀缓存，对重复system prompt场景提升30%+吞吐
• --swap-space 16：CPU侧swap空间(GB)，KV Cache溢出时暂存

使用Python SDK发起推理请求并测量延迟：

from vllm import LLM, SamplingParams
import time

llm = LLM(
    model="meta-llama/Meta-Llama-3-70B-Instruct",
    tensor_parallel_size=4,
    gpu_memory_utilization=0.90,
    enable_prefix_caching=True
)

prompts = ["请解释分布式锁的实现原理"] * 100
sampling_params = SamplingParams(
    temperature=0.7,
    top_p=0.9,
    max_tokens=512
)

start = time.time()
outputs = llm.generate(prompts, sampling_params)
elapsed = time.time() - start

total_tokens = sum(len(o.outputs[0].token_ids) for o in outputs)
print(f"吞吐量: {total_tokens / elapsed:.1f} tokens/s")
print(f"平均延迟: {elapsed:.2f}s")

TensorRT-LLM引擎构建与INT8量化优化

TensorRT-LLM的部署流程分为两步：先将模型编译为TensorRT引擎，再通过Triton Inference Server提供服务。引擎构建阶段执行层融合、kernel自动调优和精度校准。

# 获取TensorRT-LLM源码
git clone https://github.com/NVIDIA/TensorRT-LLM.git
cd TensorRT-LLM/examples/llama

# 转换HuggingFace权重为TensorRT格式
python3 convert_checkpoint.py \
    --model_dir meta-llama/Meta-Llama-3-70B-Instruct \
    --output_dir ./llama_70b_checkpoint \
    --dtype float16

# 构建INT8量化引擎
python3 ../build.py \
    --checkpoint_dir ./llama_70b_checkpoint \
    --output_dir ./llama_70b_engine \
    --gemm_plugin float16 \
    --use_int8 \
    --max_batch_size 32 \
    --max_input_len 2048 \
    --max_output_len 512 \
    --world_size 4 \
    --tp_size 4

INT8量化通过SmoothQuant算法实现，校准过程需要500-1000条代表性输入数据。量化后模型体积减少50%，推理吞吐提升约2.3倍，精度损失控制在1%以内。

通过Triton部署服务：

# model.pbtxt 配置
name: "llama_70b"
backend: "tensorrtllm"
max_batch_size: 32

input [
  { name: "input_ids", data_type: TYPE_INT32, dims: [ -1 ] },
  { name: "input_lengths", data_type: TYPE_INT32, dims: [ 1 ] }
]
output [
  { name: "output_ids", data_type: TYPE_INT32, dims: [ -1, -1 ] }
]

dynamic_batching {
  preferred_batch_size: [ 4, 8, 16, 32 ]
  max_queue_delay_microseconds: 100000
}

vLLM与TensorRT-LLM推理性能基准对比

测试环境：4×A100-80G，CUDA 12.4，输入长度512 tokens，输出512 tokens，batch size从1到32递增。

数据分析：TensorRT-LLM在纯吞吐量上领先约35%-50%，主要得益于kernel fusion和INT8量化。但vLLM在动态批处理和prefix caching上有优势，面对变长输入场景时延迟波动更小。

生产环境推理服务部署要点

显存管理是首要问题。70B模型FP16权重约140GB，4卡A100-80G总计320GB，剩余180GB用于KV Cache。按每token占用0.5MB KV Cache计算，单请求8K上下文需要4GB，理论最大并发约45路。实际部署中预留20%显存余量，建议并发数设为35-38。

连续批处理（Continuous Batching）是提升吞吐的关键。传统静态批处理要求同一批次所有请求完成后才能处理下一批，长尾请求会拖慢整体吞吐。连续批处理在每次iteration级别动态加入新请求、移除已完成请求，GPU利用率从40%提升到85%以上。

监控指标部署：

# Prometheus指标采集
from prometheus_client import Counter, Histogram, start_http_server

request_count = Counter('llm_requests_total', 'Total inference requests')
request_latency = Histogram('llm_request_latency_seconds', 'Request latency')

@app.post("/v1/completions")
async def completions(request: Request):
    request_count.inc()
    with request_latency.time():
        result = await llm_engine.generate(request.prompt)
    return result

start_http_server(9090)

核心监控指标包括：tokens/s吞吐量、TTFT（Time To First Token）、E2E延迟P99、GPU显存使用率、KV Cache命中率。建议设置告警阈值：TTFT超过2秒、P99延迟超过5秒、显存使用率超过95%时触发告警。

选型建议：追求极致吞吐且有NVIDIA硬件的团队优先TensorRT-LLM；需要灵活部署、多硬件兼容、快速迭代的团队选择vLLM。两者并非互斥，可通过统一推理网关按场景路由到不同后端。