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

目录

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

在微服务架构里，Ray 相当于 “请求路由组件 + 注册中心 + 负载均衡器”，而每个 Actor 就像独立微服务实例，接收请求、处理逻辑、维护状态。这样整个异构 LLM 集群就像一个微服务生态，动态调度和弹性扩展天然支持异构硬件。

---

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 想象成 “异构资源管理和任务调度中枢”：

1. Actor 管理

   • 每个 LLM 模型实例作为一个 Actor 运行
   • Actor 可以绑定单张或多张 GPU（TP/PP 切片也可以在 Actor 内部）

2. 请求路由

   • 上层请求发到 Ray Serve 或 Ray Actor Pool
   • Ray 根据硬件资源、负载、优先级，把请求路由到合适的 Actor

3. 动态资源调度

   • 异构 GPU / NPU 节点池
   • Ray 管理 idle / busy 状态
   • 自动选择最优 Actor 执行请求，提高 GPU 利用率

4. 异构集群支持

   • NVIDIA + Ascend + 其他国产 GPU 节点都可以加入集群
   • Actor 内部通过硬件适配层调用各自 API
   • 上层业务无感知异构差异

5. 逻辑统一 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️⃣ 核心差异总结

1. 单机多实例

   • GPU 固定分配
   • 多端口独立服务
   • KV Cache 互不共享
   • 手动调度请求

2. 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️⃣ 核心细节说明

1. Ray 的职责

   • 动态调度请求 → 找到满足 TP GPU 数量的可用 GPU
   • 选择 Actor（如果已有实例可以复用，或者新建 Actor）
   • 将 GPU 列表/Actor ID 信息传给 vLLM Service

2. vLLM 的职责

   • 接收 Ray 提供的 GPU 信息
   • 配置 TP 切片：每张 GPU 加载模型一部分权重
   • 管理 KV Cache 和 batch
   • 执行生成循环（token-by-token）

3. TP 配置逻辑

   • vLLM 内部根据 GPU 列表进行权重拆分
   • 每张 GPU 只计算该 TP 切片
   • 层间通信通过 NCCL / HCCL 等底层库完成

4. KV Cache

   • 每个 Actor 有自己的本地 KV Cache
   • 上层 Service 逻辑上可以统一管理 batch / token routing