从单机到多节点分布式推理部署，架构上最大的变化是从"单机多卡"的内部通信变成了"跨节点"的网络通信。核心在于如何配置分布式节点和并行策略。
核心架构变化：从TP到PP+TP
在单机多卡部署时，我们主要使用 张量并行（Tensor Parallelism，TP），它在单节点内通过高速总线（如NVLink）拆分模型权重，通信开销极低。
但在多节点场景下，跨节点的网络带宽远低于节点内总线，如果继续单独使用TP，大量的数据传输会成为性能瓶颈。因此，多节点部署的核心策略是 流水线并行（Pipeline Parallelism，PP）+ 张量并行（Tensor Parallelism，TP） 的组合。
PP (Pipeline Parallelism, 流水线并行)：将模型的不同层切分到不同节点上。数据像一个流水线一样，在节点间依次处理。这能有效减少跨节点的数据传输量。
TP (Tensor Parallelism, 张量并行)：在每个节点内部，继续将切分到的层（Layer）拆分到多张GPU上，充分利用节点内的高速互联。
简单来说，策略就是：节点之间用PP，节点内部用TP。一个部署任务的总GPU数 = PP大小 × TP大小。
分布式推理：vLLM 集成 Ray
使用vllm做分布式推理，目前主流方案是与 Ray 分布式计算框架集成，将 Ray 作为分布式执行的后端调度器。在多节点场景下，Ray 负责管理集群资源、在节点间协调任务，而 vLLM 则作为推理引擎运行在 Ray 的 Worker 上，利用 Ray 分配好的 GPU 资源进行模型推理 。这两者形成了一种“资源调度（Ray）+ 计算引擎（vLLM）”的经典协作模式。
以下是它们集成的分层架构示意图：
下面从具体的配置步骤展开，涵盖从 Ray 集群搭建到 vLLM 集成以及生产环境调优的完整流程。
在启动 vLLM 服务之前，需要在所有节点上安装并启动一个 Ray 集群。这是多节点部署的前提条件 。
1. 安装 Ray：在所有节点上执行以下命令安装 Ray。
pip install "ray[default]"
2. 启动 Head 节点：在选为主节点（管理节点）的机器上执行。
ray start --head --port=6379
也可以指定其他端口，6379 是 Ray 的默认端口。执行成功后，终端会显示 Ray 集群的地址，类似 192.168.1.10:6379 。
3. 连接 Worker 节点：在其余所有的 Worker 节点上，执行以下命令连接到 Head 节点。将 <HEAD_NODE_IP> 替换为 Head 节点的实际 IP 地址。
ray start --address=<HEAD_NODE_IP>:6379
执行完这些步骤后，一个多节点的 Ray 集群就运行起来了，此时 vLLM 就可以接入并使用集群内的所有 GPU 资源。
Ray 集群就绪后，只需在 Head 节点上正常启动 vLLM 服务，并通过关键参数指定使用 Ray 作为分布式执行后端。
以 Qwen3 模型部署为例，使用2个节点，每个节点配有4张GPU，部署Qwen3-32B模型。以下是一个生产环境级别的vLLM启动命令示例：
vllm serve /path/to/Qwen3-32B \ --tensor-parallel-size 4 \ # 每个节点内使用4卡进行TP --pipeline-parallel-size 2 \ # 共有2个节点进行PP --distributed-executor-backend ray \ # 多节点必须使用Ray作为后端 --max-model-len 8192 \ # 根据实际场景设置，过长会消耗大量显存 --gpu-memory-utilization 0.90 \ # 保留部分显存余量 --max-num-seqs 256 \ # 控制并发量，避免OOM --trust-remote-code \ # Qwen3需要此参数 --enforce-eager \ # 多节点复杂图下可能更稳定（可选） --swap-space 16 \ # 设置CPU交换空间（单位：GiB） --api-key $YOUR_API_KEY # 设置访问认证token --enable-auto-tool-choice \ --tool-call-parser hermes \ --reasoning-parser qwen3 \ --disable-custom-all-reduce ......
vLLM 在启动时会自动连接已经运行的 Ray 集群，无需额外指定 Ray 地址 。
在多节点、高性能生产环境中，网络通信往往是性能瓶颈。需要通过环境变量来精细控制底层通信库（如 NCCL）的行为，以确保数据能在节点间高速传输 。
建议在启动 vLLM 服务的 Head 节点上，预先设置以下环境变量：
环境变量可以在启动 vLLM 的终端中直接 export，或者将它们写入启动脚本的开头。例如：
# 设置 NCCL 超时时间，防止通信卡死 export NCCL_TIMEOUT=1800 # 设置共享内存大小，vLLM 会用到 /dev/shm 进行数据交换 export VLLM_SHM_SIZE=16GB export NCCL_SOCKET_IFNAME=ib0 export NCCL_IB_DISABLE=0 export NCCL_DEBUG=INFO vllm serve /path/to/Qwen3-32B \ --tensor-parallel-size 4 \ --pipeline-parallel-size 2 \ --distributed-executor-backend ray \ --trust-remote-code
量化技术的应用：对于Qwen3-32B这样的模型，在生产环境中强烈建议使用量化版本（如FP8、AWQ、GPTQ）。例如，Qwen/Qwen3-32B-FP8 可以显著降低模型显存占用和跨节点通信的数据量，从而允许更大的并发度或更低的延迟。启动时需配合 --kv-cache-dtype fp8 和 --quantization fp8 等参数。
性能调优测试：生产环境没有“一键最优解”。需要根据实际的请求流量、输入输出长度、SLA要求，对 TP 和 PP 的组合进行基准测试。例如，在8卡H100的节点上，对于Qwen3-32B，是选择 TP=8, PP=1（单节点）还是 TP=4, PP=2（双节点），需要通过压力测试来决定。
除了上述配置，在生产环境中还需要留意以下几点：
共享内存：确保所有 vLLM 容器或进程挂载了 /dev/shm（共享内存），并且大小足够（例如 16GB）。vLLM 在数据处理和进程通信中会大量使用共享内存 。在 Docker 或 Kubernetes 中，这通常需要显式配置。
环境一致性：确保所有节点上的 Python 环境、vLLM 版本、Ray 版本以及模型路径完全一致 。任何不一致都可能导致无法预料的错误。
权限设置：在 Kubernetes 等容器化环境中，可能需要为容器添加 IPC_LOCK 权限，以允许 Ray 和 vLLM 锁定内存中的页面，这对性能至关重要 。
监控与健康检查：利用 Ray 的仪表盘（默认在 Head 节点的 8265 端口）监控集群状态。同时，为 vLLM 服务配置健康检查端点（如 /health），以便于服务发现和自动恢复 。
在开始之前，有几个关键点需要先明确：
硬件假设：本次配置以 2 个节点、每个节点 4 张 Hopper 系列 GPU（如 H100）为例。这是 DeepSeek-V3.2 的常见部署场景。
核心优化原则：对于 DeepSeek-V3.2，官方强烈推荐采用“数据并行 + 专家并行”（DP+EP）模式，而不是单纯的张量并行（TP）。因为其核心算子主要针对 TP=1 进行了优化，DP+EP 模式能避免因注意力头填充导致的性能开销，提供更优的吞吐量 。
基础环境：请确保 Ray 集群已在所有节点上正确启动和配置，vLLM 将通过 --distributed-executor-backend ray 参数连接并使用该集群 。
以下命令需在 Ray Head 节点上执行。它将启动一个使用 2 个节点（共 8 张 GPU）、并启用工具调用和生产级性能优化的 DeepSeek-V3.2 服务。
# 设置访问 API 密钥 (推荐从环境变量读取) export VLLM_API_KEY="sk-your-secret-production-token" vllm serve deepseek-ai/DeepSeek-V3.2 \ # 模型加载相关 --model deepseek-ai/DeepSeek-V3.2 \ --tokenizer-mode deepseek_v32 \ --trust-remote-code \ --dtype auto \ --kv-cache-dtype fp8 \ \ # 并行策略相关 (核心: Ray + DP + EP) --distributed-executor-backend ray \ --data-parallel-size 8 \ --enable-expert-parallel \ --tensor-parallel-size 1 \ \ # 工具调用相关 --enable-auto-tool-choice \ --tool-call-parser deepseek_v32 \ --reasoning-parser deepseek_v3 \ --chat-template /path/to/xxx_deepseek.jinja \ # 可选 \ # 性能与内存调优 --max-model-len 8192 \ --gpu-memory-utilization 0.90 \ --max-num-seqs 256 \ --enable-chunked-prefill \ --enable-prefix-caching \ \ # 服务器及API配置 --host 0.0.0.0 \ --port 8000 \ --served-model-name deepseek-v3-2 \ --api-key $VLLM_API_KEY \ --disable-log-requests
这类参数确保 vLLM 能正确识别和加载 DeepSeek-V3.2 的特殊架构。
这是与单机部署最大的区别所在。采用 DP + EP + TP=1 的黄金组合。
为什么是 DP=8, EP=8, TP=1？
这相当于在 8 张 GPU 上创建了 8 个模型副本（DP），同时每个副本的 MoE 专家层也被分布到所有 8 张 GPU 上（EP），而每个 GPU 上的模型其他部分则独立运行（TP=1）。这种模式完美匹配了 DeepSeek-V3.2 的 MoE 架构，是官方推荐的服务模式 。
Each GPU holds a complete copy of the model but processes a different batch of data. This is the simplest and most common strategy.
Models with a Mixture-of-Experts (MoE) architecture contain many "expert" sub-models. Only a subset of these experts is activated to process each request. Therefore, these expert sub-models can be stored on different GPUs. When an inference workload requires a specific expert, the data is routed to the relevant GPU.
让模型具备使用外部工具的能力。
生产环境稳定性和效率的保障。
对外提供服务的关键设置。
客户端调用示例：当设置了 --api-key 后，客户端代码（如 Python）需要这样配置请求头：
import os from openai import OpenAI client = OpenAI( api_key=os.environ.get("VLLM_API_KEY"), # 使用与服务端相同的 key base_url="http://<你的模型服务IP>:8000/v1" )
在需要启用“思考模式”时，需通过 extra_body 传递参数，这与 DeepSeek 官方 API 略有不同 ：
response = client.chat.completions.create(
model="deepseek-v3-2",
messages=[{"role": "user", "content": "..."}],
tools=[...], # 调用工具定义
extra_body={"chat_template_kwargs": {"thinking": True}} # 关键点
)
# 获取思考内容：response.choices[0].message.reasoning关于 DeepGEMM：DeepSeek 模型依赖 DeepGEMM 库进行高效的 MoE 和 MQA 计算。默认安装即可。如果在 H20 等特定 GPU 上遇到性能问题或过长的预热时间，可以尝试通过设置环境变量 VLLM_USE_DEEP_GEMM=0 来禁用它 。
监控与告警：结合 Prometheus 和 Grafana 监控体系，关注 vLLM 暴露的指标，特别是抢占次数（preemption count）。如果抢占频繁，说明显存不足，需调整 max_num_seqs 或 gpu_memory_utilization 。
参考：
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。