大模型推理服务部署实战：从vLLM单卡推理到多节点Tensor Parallel完整方案

大模型推理部署面临的核心挑战

大语言模型从训练走向线上推理服务，工程团队要解决的远不止”能跑起来”。延迟指标、吞吐量上限、显存占用峰值、多节点通信开销——每一个参数都可能成为生产环境的瓶颈。当前主流的推理框架中，vLLM凭借PagedAttention和连续批处理机制，在单卡和多卡场景下都有出色表现，是多数团队的首选方案。

这篇文章从实际生产环境出发，拆解vLLM从单卡部署到多节点Tensor Parallel的完整链路，包含配置示例、性能调优参数和常见问题诊断。

单卡推理服务起步：vLLM基础配置

单张A100-80G或H100显卡，对于7B-13B参数量的模型（如Qwen2.5-7B-Instruct）可以直接加载，14B-32B模型需要INT4/GPTQ量化后才能塞进单卡显存。以下是一个典型的单卡vLLM启动命令：

python -m vllm.entrypoints.openai.api_server   --model /data/models/Qwen2.5-7B-Instruct   --served-model-name qwen-7b   --host 0.0.0.0   --port 8000   --gpu-memory-utilization 0.92   --max-model-len 4096   --dtype auto   --trust-remote-code

关键参数说明：

• --gpu-memory-utilization：GPU显存使用上限，生产环境建议0.90-0.95，留出余量避免OOM
• --max-model-len：最大上下文长度，直接影响KV Cache占用，设太大会挤占batch空间
• --dtype：auto自动选择，bf16在A100/H100上精度和速度平衡最优

连续批处理与PagedAttention内存优化

vLLM的核心优势在于PagedAttention——将KV Cache分页管理，按需分配和释放，避免传统方案中预分配固定大小显存导致的浪费。配合continuous batching，新请求可以在已有batch运行时动态插入，不必等待整个batch完成。

在单卡场景下，continuous batching的效果可以通过并发请求压测来验证：

# 使用benchmark脚本压测
python benchmarks/benchmark_serving.py   --model /data/models/Qwen2.5-7B-Instruct   --backend vllm   --dataset-name random   --random-input-len 512   --random-output-len 256   --num-prompts 200   --request-rate 10

观察输出中的TTFT（Time to First Token）和ITL（Inter-Token Latency），正常情况下单卡7B模型TTFT应在200ms以内，ITL在30-50ms区间。如果TTFT飙升到秒级，优先检查--max-model-len是否设置过大导致KV Cache争用。

多卡Tensor Parallel部署方案

当模型参数超过单卡显存容量（例如Qwen2.5-72B需要约144GB显存），Tensor Parallel（TP）是必须的。vLLM通过--tensor-parallel-size参数控制TP并行度：

python -m vllm.entrypoints.openai.api_server   --model /data/models/Qwen2.5-72B-Instruct   --tensor-parallel-size 4   --gpu-memory-utilization 0.90   --max-model-len 8192   --dtype bfloat16   --trust-remote-code

TP=4意味着模型权重均匀切分到4张GPU上，每张卡承担1/4的矩阵运算。同一台机器上4卡通过NVLink互联，通信开销极低。注意几点：

• TP并行度必须能整除模型的注意力头数，Qwen2.5-72B有64个注意力头，TP=4/8均可
• 启动时所有GPU初始化需要同步，冷启动时间会比单卡长2-3倍
• 4卡场景下显存占用约为单卡版本的1/4+通信buffer，不是严格1/4

多节点部署：Ray Cluster + vLLM分布式推理

当8卡单机也无法满足（例如70B模型在长上下文场景下的推理），需要跨节点部署。vLLM依赖Ray进行多节点协调：

# 头节点启动Ray
ray start --head --port=6379

# 工作节点加入集群
ray start --address=HEAD_IP:6379

# 在头节点启动vLLM服务
python -m vllm.entrypoints.openai.api_server   --model /data/models/Qwen2.5-72B-Instruct   --tensor-parallel-size 8   --pipeline-parallel-size 2   --distributed-executor-backend ray   --gpu-memory-utilization 0.88   --max-model-len 16384

Pipeline Parallel（PP）将模型按层切分到不同节点，TP在同一节点内切分。TP=8 + PP=2意味着两个节点各8张卡，模型分成两个Stage。跨节点通信走RDMA网络，延迟是瓶颈——确保节点间至少100Gbps InfiniBand互联，否则ITL会显著退化。

多节点场景的排查要点：

• 用ray status确认所有节点GPU正常注册
• 检查NCCL环境变量：NCCL_SOCKET_IFNAME指定正确的网卡，避免走管理网络
• 如果出现NCCL timeout，调大NCCL_TIMEOUT默认值（单位ms）

生产环境性能调优关键参数

除了模型并行度，以下参数对线上推理服务的QPS和延迟有直接影响：

# 限流和批处理
--max-num-seqs 256         # 单batch最大并发序列数
--max-num-batched-tokens 8192  # 单batch最大token数
--enable-chunked-prefill   # 分块预填充，减少长请求阻塞

# 量化降低显存
--quantization awq         # AWQ 4bit量化
--quantization gptq        # GPTQ量化

# KV Cache优化
--swap-space 4             # CPU swap空间(GB)，超出显存时换出到内存

实际调优经验：对于70B模型，开启chunked prefill后，在混合长短请求场景下TTFT P99可降低40%。代价是调度逻辑变复杂，极端情况可能增加ITL抖动，需结合业务场景取舍。

推理服务监控与故障排查

生产环境必须关注的核心指标：

• 显存利用率：vLLM在/metrics端点暴露Prometheus指标，vllm:num_requests_running和vllm:gpu_cache_usage_perc是核心
• 请求排队：vllm:num_requests_waiting持续大于0说明处理能力不足，需要扩容
• OOM Killer：日志中出现torch.cuda.OutOfMemoryError，调低--gpu-memory-utilization或--max-model-len

一个常见的坑是NCCL通信在容器网络下失败。Docker默认使用bridge网络，多容器间NCCL无法自动发现网卡。解决方案：

# docker-compose中指定host网络
network_mode: host

# 或手动设置NCCL环境
ENV NCCL_SOCKET_IFNAME=eth0
ENV NCCL_IB_DISABLE=1  # 没有IB卡时禁用

从单卡到多节点的部署路径，核心是逐步验证：先确认单卡延迟和吞吐达标，再水平扩展TP并行度，跨节点部署时优先保证网络带宽。vLLM的PagedAttention和continuous batching机制降低了推理服务的工程复杂度，但生产调优仍然需要对GPU显存、NCCL通信和请求调度有清晰的理解。