1. 技术背景与核心概念

• 在大规模语言模型（LLM）的工程实践中，单 GPU 的算力与显存容量已成为制约模型部署的显著瓶颈。当前主流的分布式推理策略主要依托两个核心技术栈：Ray（分布式计算基础设施）与 vLLM/Transformers（模型推理引擎）。理解二者的协作关系，需要首先厘清数据并行（Data Parallelism, DP）与张量并行（Tensor Parallelism, TP）在推理场景下的本质差异。

官方资源导航：

• Ray Serve: 官方文档 | 生产部署指南
• vLLM 分布式推理: 分布式服务文档 | GitHub 仓库
• Ray Data LLM: Ray Data 处理大模型指南

2. Ray + vLLM：张量并行驱动的超大规模模型推理

2.1 架构定位与核心机制

• Ray 与 vLLM 的结合代表了模型并行（Model Parallelism）在推理阶段的工程实践。在该架构中，Ray 充当分布式计算的基础设施编排层，而 vLLM 则专注于单请求的多 GPU 协同计算。

---

启动阶段的资源编排： 当执行 vllm serve 命令并指定 --distributed-executor-backend ray 时，系统触发以下初始化流程。

1. 集群发现：vLLM 主进程通过 Ray 的 GCS（Global Control Store）获取集群拓扑，识别可用的 GPU 资源池
2. 进程编排：Ray 根据 tensor_parallel_size 参数，在选定的 GPU 上启动 vLLM Worker 进程，每个 Worker 负责模型特定层的计算
3. 通信拓扑建立：Ray 协调建立基于 NCCL 的高带宽 GPU 间通信通道，为张量切分传输做准备
4. 权重加载与分布：主进程将模型权重按张量维度（如注意力头的分割）分布到各 Worker，确保单张 GPU 仅驻留部分参数

• Ray + vLLM 启动阶段资源编排 的时序图如下。

• 图示说明

阶段	关键操作	技术细节
1. 集群发现	GCS 心跳检测	Ray Global Control Store 返回可用 GPU 资源拓扑，包含设备 ID、显存容量、节点位置
2. 进程编排	Placement Group 调度	Ray 根据 tensor_parallel_size 创建Placement Group，确保 Worker 进程在物理上靠近，减少跨节点通信延迟
3. 通信拓扑	NCCL Group 初始化	建立 Ring 或 Tree 结构的 AllReduce/AllGather 通信环，为张量并行中的激活值和 KV Cache 传输做准备
4. 权重分布	张量维度切分	按注意力头(Attention Heads)和MLP层切分权重，确保单张 GPU 仅驻留 1/N 参数，通过 NCCL 实现推理时的张量聚合

流程图视角

• 关注步骤依赖关系的流程图。

---

运行时的协同计算：在推理阶段，架构呈现出高度的计算-通信耦合特征。

• 请求分片：单个请求的前向传播（Forward Pass）被切分为跨 GPU 的子计算图。例如，对于 70B 参数模型采用 8 路张量并行时，每个 GPU 处理约 8.75B 参数的计算子图
• 激活值传输：在 Transformer 层的计算过程中，层间激活值（Activations）通过 Ray 管理的 NCCL 通信原语进行 All-Reduce/All-Gather 操作，确保语义的连贯性
• 连续批处理（Continuous Batching）：vLLM 通过 PagedAttention 机制动态管理 KV Cache，Ray 则负责跨 GPU 的内存页调度，实现请求粒度的动态插入与流式输出

2.2 内存管理与计算密度优化

vLLM 引入的 PagedAttention 技术，本质上是将操作系统虚拟内存管理思想应用于注意力机制。在与 Ray 结合时，这一优势被放大至多节点环境：

• 内存碎片化消除：通过将 KV Cache 分块（默认块大小 16 tokens）并动态分配，避免了传统静态分配导致的内存浪费
• 零复制跨节点传输：Ray 的 Plasma 对象存储与 vLLM 的内存池结合，实现了跨节点 KV Cache 的零序列化传输
• 高吞吐量批处理：在 Ray 管理的集群中，vLLM 可维持高达 80-90% 的 GPU 计算利用率（FLOPs 利用率），远高于数据并行模式的 30-50%

2.3 适用边界与局限性

该模式的核心局限在于并发度与单请求处理延迟的权衡：

• 并发天花板：由于所有 GPU 必须协同处理单个请求，系统的最大并发数受限于 pipeline 阶段的处理能力，而非GPU数量
• 通信开销：在多节点场景下，跨机网络带宽（通常 25-100 Gbps）成为瓶颈，All-Reduce 操作可能占据 20-40% 的端到端延迟
• 故障恢复复杂度：单点 GPU 故障会导致整个推理流水线失效，Ray 虽然我提供故障检测与 Actor 重启，但上下文状态的恢复仍会导致毫秒级甚至秒级的中断

---

3. Ray + Transformers：数据并行驱动的独立推理服务

3.1 架构本质：无状态服务的水平扩展

• 与 vLLM 的紧密耦合不同，Ray 与 HuggingFace Transformers 的结合体现了无状态微服务（Stateless Microservices）设计理念。在此模式下，Ray Serve 作为服务网格（Service Mesh），将每个模型实例封装为独立的推理节点。

部署架构的解耦特性：

@serve.deployment(num_replicas=6, ray_actor_options={"num_gpus": 1})
class TransformerDeployment:
    def __init__(self):
        # 每个 Actor 独立加载完整模型副本
        self.model = AutoModelForSequenceClassification.from_pretrained("bert-base-uncased")

代码揭示了两个关键设计决策：

1. 模型副本独立性：每个 Ray Actor 在独立的 GPU 上加载完整的模型权重，Actor 间无共享状态，形成典型的数据并行格局
2. 请求级负载均衡：Ray Serve 的代理层（Proxy）通过轮询或最少连接算法将请求路由至空闲 Actor，实现了请求级别的并行处理

3.2 计算特征与性能模型

• 低延迟与高并发： 由于单个请求的处理被限制在单个 GPU 内，避免了跨设备通信开销，单请求延迟（Latency）显著低于张量并行模式。对于 BERT-base（110M 参数）这类模型，单 GPU 可支持 100-500 QPS（Queries Per Second），通过 Ray 的水平扩展可线性提升总吞吐量。

• 内存冗余与资源利用率： 数据并行的代价是内存效率的牺牲。N个GPU上部署N个副本意味着模型权重被重复存储N次。对于 7B 参数（FP16约14GB）的模型，8张GPU需占用总计 112GB 显存存储相同参数，而张量并行仅需约14GB（加上激活值缓冲）。

• 批处理策略： Transformers 的默认实现采用静态批处理（Static Batching），即请求在客户端或服务端累积至预设批次大小后统一推理。这与 vLLM 的连续批处理形成对比，导致在请求到达率不稳定时产生"队头阻塞"（Head-of-Line Blocking）现象。

3.3 流式处理与交互模式差异

• 在生成式任务中，Ray + Transformers 的流式实现需依赖显式的HTTP流式传输机制（如 SSE 或 Chunked Transfer Encoding），由 Ray Serve 的FastAPI集成提供支持。然而，由于缺乏vLLM的Token级调度能力，其首字延迟（Time to First Token, TTFT）通常较高，且难以在生成过程中动态插入新请求。

4. 系统性对比：架构、性能与运维维度

4.1 并行哲学与资源抽象

维度	Ray + vLLM (张量并行)	Ray + Transformers (数据并行)
并行粒度	单请求内的操作级并行（Intra-request Parallelism）	请求间的任务级并行（Inter-request Parallelism）
资源抽象	多 GPU 虚拟化为单一逻辑推理引擎	每个 GPU 作为独立推理节点
状态管理	分布式状态（Distributed KV Cache）	无状态（Stateless），请求上下文仅存于单节点
扩展向量	纵向扩展（Scale-up）为主，横向扩展用于 Pipeline Parallelism	横向扩展（Scale-out）优先，复制成本线性增长
通信模式	密集集体通信（Collective Communication）	仅控制平面通信（Health Check, Metrics）

4.2 性能特征的空间与时间维度

吞吐量（Throughput）与延迟（Latency）的取舍：

• vLLM 模式在大批次、长序列场景下占优。当批量大小（Batch Size）> 16 且序列长度 > 1024 时，其高 GPU 利用率（FLOPs Utilization）可有效摊销通信开销。实测数据显示，在 Llama2-70B 模型上，vLLM 的吞吐量可达 Transformers 数据并行的 3-5 倍（当总 GPU 数相同时）。

• Transformers 数据并行在低延迟敏感型任务中表现更优。对于平均序列长度 < 256 的分类或短文本生成任务，其 P99 延迟通常低于 vLLM 的 30-50%，因为避免了跨 GPU 同步等待。

---

扩展效率（Scaling Efficiency）：

• 强扩展（Strong Scaling）：固定总 workload，增加 GPU 数量。vLLM 在单节点内可实现 85-95% 的强扩展效率，但跨节点时因网络延迟骤降至 60-70%。Transformers 数据并行在理想负载均衡下可保持接近线性的强扩展。
• 弱扩展（Weak Scaling）：固定单 GPU workload，增加 GPU 与数据量。vLLM 受限于单请求处理，弱扩展能力有限；Transformers 模式则能通过增加副本数近乎无限地扩展吞吐量。

4.3 可靠性（Reliability）与故障域

故障隔离粒度是两种架构的关键差异：

• 数据并行模式具备进程级故障隔离。单个 Ray Actor 的崩溃仅影响其承载的请求，其余 5 个副本可立即接管流量，符合微服务的"故障封闭"（Fault Isolation）原则。
• 张量并行模式存在级联故障风险。由于单请求处理依赖所有 GPU 的协同，任一 GPU 故障或网络抖动将导致整个推理集群的拒绝服务（DoS），直至 Ray 完成 Actor 重建与状态恢复。

恢复时间目标（RTO）：

• Transformers 数据并行：秒级（仅需重启单个 Actor）
• vLLM 张量并行：分钟级（需重新加载模型权重并重建通信拓扑）

5. 决策矩阵：如何选择适宜的分布式策略

5.1 技术性决策因素矩阵

决策因素	权重	Ray + vLLM (TP) 评分	Ray + Transformers (DP) 评分	决策逻辑
模型规模	极高	>13B 必须	≤7B 可用	当模型参数量超过单 GPU 显存（通常 80GB A100）时，张量并行成为必要选项
序列长度	高	>2K tokens 优势	<512 tokens 优势	长序列导致 KV Cache 膨胀，vLLM 的 PagedAttention 内存优势显著
并发请求量	高	低-中并发（<50 QPS）	极高并发（>1000 QPS）	vLLM 的并发受限于 pipeline 深度；数据并行可通过副本线性扩展并发
延迟敏感度	中	TTFT 较高（100-500ms）	TTFT 较低（10-100ms）	对于实时对话系统，首字延迟是关键 UX 指标
任务类型	中	生成式任务（文本/代码）	判别式任务（分类/评分/Embedding）	生成任务受益于 vLLM 的投机解码与流式优化；判别任务数据并行更直接
基础设施	中	需要高速互连（NVLink/InfiniBand）	通用以太网即可	多机张量并行对网络拓扑极其敏感，需在节点内完成 TP，节点间采用 PP
运维复杂度	低	高（需监控 NCCL 通信、内存碎片）	低（仅需监控单节点指标）	数据并行模式与现代可观测性栈（Prometheus/Grafana）集成更成熟

• 评分说明：评分基于相对优势，非绝对性能指标。

5.2 场景化使用建议矩阵

应用场景	推荐架构	配置建议	关键考量
ultra-large 模型服务 (70B+/MoE 架构)	Ray + vLLM	TP=8（单节点）+ PP=2-4（跨节点） --distributed-executor-backend ray	必须确保节点间 InfiniBand 连接；启用 CUDA Graph 优化减少 CPU 开销；监控 GPU 间通信带宽利用率
中高并发对话 API (Chatbot as a Service)	混合架构 Ray Serve + vLLM (TP)	多实例 vLLM 部署（每个实例 TP=4/8） Ray Serve 作为网关负载均衡	在 vLLM 实例间实现数据并行，实例内使用张量并行；利用 Ray 的 fractional GPU 支持超分 GPU
实时内容审核 (Content Moderation)	Ray + Transformers	num_replicas=N_GPUs batch_size=32-64	使用 pipeline() API 实现 CPU 预处理后 GPU 推理；启用 Ray Serve 的自动扩缩容应对流量峰值
Embedding 服务 (RAG 检索)	Ray + Transformers	动态批处理 + ONNX Runtime/TensorRT 加速 多副本部署	Embedding 模型通常 <3B，单 GPU 可处理高并发；使用 Ray Data 进行离线批量推理更高效
批量离线推理 (Batch Inference)	Ray Data + vLLM	vLLMEngineProcessorConfig 利用 Ray Data 的流式处理	使用 Ray Data 的流式执行引擎，将数据加载、预处理、推理、后处理流水线化，最大化 GPU 利用率
多模态大模型 (VLM like GPT-4V)	Ray + vLLM	视觉编码器与语言模型分离部署 Ray Serve 多模型组合	利用 Ray Serve 的模型组合能力，将图像编码器（可能仅需 CPU 或单 GPU）与 vLLM 推理引擎解耦部署

5.3 架构演进与混合策略

对于生产环境中复杂的负载模式，建议采用分层并行（Hierarchical Parallelism） 策略：

1. 第一层（节点间）：使用 Ray Serve 将请求路由至不同的 vLLM 实例，实现数据并行。
2. 第二层（节点内）：每个 vLLM 实例内部使用 张量并行（TP）处理超大模型。
3. 第三层（批处理）：在 vLLM 内部利用 连续批处理 提升单 GPU 利用率。

• 这种"Ray 管人、vLLM 管计算"的分层架构，既保留了数据并行的弹性与容错性，又获得了张量并行对大模型的支持能力。在 Kubernetes 环境中，可通过 KubeRay Operator 与 vLLM 的 Docker 镜像实现该架构的原生支持。

6. 总结

• Ray 与 vLLM/Transformers 的集成展现了大模型分布式系统的两种设计哲学：基础设施抽象与计算密集优化。

• vLLM 模式通过 Ray 的分布式能力突破了单设备显存墙，适用于超大规模模型的低吞吐高算力场景；而 Transformers 数据并行模式则利用 Ray Serve 的服务编排能力，为高并发、低延迟的业务需求提供了简单可靠的解决方案。

• 对于学习者而言，深入理解这两种模式的架构差异，不仅有助于在具体工程中选择合适的技术栈，更能从分布式系统设计的宏观视角，把握并行计算中通信-计算权衡（Communication-Computation Trade-off）、强一致性 vs 可用性（Consistency vs Availability）等核心计算机科学原理在大模型时代的演绎与变迁。