当前位置：首页 > news >正文

单机多卡TP（Ray）部署架构

news 2026/5/11 22:00:39

- 1️⃣ 单机多实例 vs Ray 架构对比
- 2️⃣ Ray 在部署架构中的作用
- 3️⃣ 架构示意（文本版）
- 4️⃣ 核心差异总结
用一个query 说明白Ray在里面的工作
- 1️⃣ 场景假设
- 2️⃣ 请求处理流程
- 3️⃣ 核心细节说明

明白，我们来详细梳理一下 Ray 架构下的 LLM 部署与单机多实例部署的区别，尤其是 Ray 在其中的作用。

1️⃣ 单机多实例 vs Ray 架构对比

维度	单机多实例部署	Ray 架构部署
GPU 绑定	每个模型实例固定绑定 2 张 GPU	GPU 统一管理，Ray 可以动态调度请求到任意可用 GPU
服务端口	每个实例独立端口（如 8000/8001/8002/8003）	Ray Actor 内部管理实例，无需人为启动多个端口，统一入口即可
KV Cache	每个实例独立管理，不能共享	每个 Actor 管理自己的 KV Cache，Ray 负责 Actor 调度与路由，逻辑上可以统一管理
请求分发	由业务或网关手动路由到端口	Ray Actor + Serving 层负责动态调度请求，按硬件可用性和负载自动分配
资源利用率	固定分配，可能部分 GPU 空闲	Ray 可以按请求量动态调度，实现 GPU 弹性利用，减少资源浪费
异构硬件	很难扩展，需要人工适配	Ray 可以管理异构节点（NVIDIA / 昇腾 / 其他 GPU），Service 层逻辑统一调用 Actor，底层由硬件适配层处理
扩展性	扩容复杂，需要手动启动更多实例	扩容简单，增加节点或 GPU 后 Ray Actor 自动纳入调度池

2️⃣ Ray 在部署架构中的作用

可以把 Ray 想象成 “异构资源管理和任务调度中枢”：

Actor 管理
- 每个 LLM 模型实例作为一个 Actor 运行
- Actor 可以绑定单张或多张 GPU（TP/PP 切片也可以在 Actor 内部）
请求路由
- 上层请求发到 Ray Serve 或 Ray Actor Pool
- Ray 根据硬件资源、负载、优先级，把请求路由到合适的 Actor
动态资源调度
- 异构 GPU / NPU 节点池
- Ray 管理 idle / busy 状态
- 自动选择最优 Actor 执行请求，提高 GPU 利用率
异构集群支持
- NVIDIA + Ascend + 其他国产 GPU 节点都可以加入集群
- Actor 内部通过硬件适配层调用各自 API
- 上层业务无感知异构差异
逻辑统一 KV Cache（可选）
- Actor 内维护本地 KV Cache
- Service 层可维护 逻辑 KV Cache 映射表，Ray 自动分配 batch 到 Actor，实现逻辑统一

3️⃣ 架构示意（文本版）

=================== 异构 GPU / NPU 集群 ===================┌───────────────────────────┐│       API / 网关层         ││ HTTP/gRPC/OpenAI-compatible │└───────────┬───────────────┘│┌───────▼───────────┐│    Ray Serve /    ││    Actor Pool     ││ - 请求路由        ││ - 负载均衡        ││ - 异构调度        │└───────┬───────────┘│┌────────────────┼─────────────────┐│                │                 │┌─────▼─────┐    ┌─────▼─────┐    ┌─────▼─────┐│ Actor_1    │    │ Actor_2    │    │ Actor_3    ││ GPU0+GPU1  │    │ GPU2+GPU3  │    │ GPU4+GPU5  ││ KV Cache   │    │ KV Cache   │    │ KV Cache   │└───────────┘    └───────────┘    └───────────┘Actor_N 可在异构节点上，Ray 自动管理请求分发和调度

4️⃣ 核心差异总结

单机多实例
- GPU 固定分配
- 多端口独立服务
- KV Cache 互不共享
- 手动调度请求
Ray 架构
- GPU 动态分配 Actor
- 上层业务无感知硬件
- Ray Serve 自动调度请求
- 异构集群可扩展
- KV Cache 可逻辑统一

简单一句话：Ray 把“手动划分 GPU + 多实例管理 + 请求路由”统一成动态调度和 Actor 管理，使异构集群部署更灵活可扩展。

用一个query 说明白Ray在里面的工作

完全对，你理解的逻辑是正确的，但我帮你把流程梳理成完整的 请求生命周期 + Ray 和 vLLM 的协作，保证面试或设计说明能一眼看懂：

1️⃣ 场景假设

模型：Qwen 14B
每个请求需要 2 张 GPU 做 Tensor Parallel (TP)
部署架构：Ray + vLLM Service
GPU：Ray 管理的 GPU 池（NVIDIA 或异构 GPU 节点）

2️⃣ 请求处理流程

[用户请求]│▼
┌───────────────┐
│  API / 网关层  │
└───────────────┘│ 请求到来▼
┌─────────────────────────────┐
│      Ray Serve / Actor Pool  │
│ - 查询可用 GPU 资源          │
│ - 找到 2 张 GPU (GPU0+GPU1) │
│ - 创建/选择对应 Actor       │
└─────────────────────────────┘│ 将 GPU 信息传给 Actor▼
┌─────────────────────────────┐
│         vLLM Service         │
│ - TP 配置 GPU0+GPU1         │
│ - KV Cache / Batch 管理      │
│ - generate() 逐 token 输出   │
└─────────────────────────────┘│▼
[结果返回给 API / 用户]

3️⃣ 核心细节说明

Ray 的职责
- 动态调度请求 → 找到满足 TP GPU 数量的可用 GPU
- 选择 Actor（如果已有实例可以复用，或者新建 Actor）
- 将 GPU 列表/Actor ID 信息传给 vLLM Service
vLLM 的职责
- 接收 Ray 提供的 GPU 信息
- 配置 TP 切片：每张 GPU 加载模型一部分权重
- 管理 KV Cache 和 batch
- 执行生成循环（token-by-token）
TP 配置逻辑
- vLLM 内部根据 GPU 列表进行权重拆分
- 每张 GPU 只计算该 TP 切片
- 层间通信通过 NCCL / HCCL 等底层库完成
KV Cache
- 每个 Actor 有自己的本地 KV Cache
- 上层 Service 逻辑上可以统一管理 batch / token routing