Ray调度-请求合并策略

目录

• 1️⃣ Ray 的基本能力
• 2️⃣ 合并策略设计
  • a. Batch Window（时间窗口）
  • b. Max Batch Size（最大 batch 大小）
  • c. 优先级队列
  • d. Batch 拆分 / 显存估算
• 3️⃣ Ray + vLLM 合并示意
• 4️⃣ 核心特点

好，我来详细拆解 Ray 在 AI 推理场景下的请求合并策略，特别是和 vLLM 配合时的做法。Ray 本身只是一个调度框架，所以合并策略需要我们自己设计，Ray 提供机制来实现它。

---

1️⃣ Ray 的基本能力

在 Ray 中，你可以：

1. Actor 管理模型实例

   • 每个 GPU 上部署一个 vLLM actor
   • Actor 内部可以管理自己的 batch / KV Cache

2. Task 调度

   • 将每个请求封装成 task
   • 调度器负责把 task 分配给 actor

3. Batch 合并

   • 通过 Ray 的 Actor 或 Queue，可以在“短时间窗口”内把多个 task 合并
   • 形成一个 batch 一次送 vLLM 推理

---

2️⃣ 合并策略设计

a. Batch Window（时间窗口）

• 将收到的请求在短时间内收集（例如 5–50ms）
• 超过窗口就立即送 vLLM
• 这样即使请求量低，也不会无限等待

示意：

t=0ms: 收到请求 A
t=3ms: 收到请求 B
t=5ms: 达到 batch window → A+B 一起送 GPU

b. Max Batch Size（最大 batch 大小）

• 避免一次合并太多请求，显存占用过高
• 超过 max batch size → 立即送 vLLM，剩余请求等待下一轮
• 对 24GB 显卡非常重要，尤其 14B / 32B 模型

示意：

Batch window=10ms, max_batch=4
收到请求: A,B,C,D,E
合并前: [A,B,C,D] → GPU
剩余: [E] → 下一轮

c. 优先级队列

• 高优先级请求放入高优先级队列
• 低优先级请求放入低优先级队列
• 合并时，先合并高优先级请求
• 避免小请求被大请求阻塞

示意：

高优先级队列: A,C
低优先级队列: B,D
合并策略:
- 高优先级：优先合并 batch → 送 GPU
- 低优先级：等 batch window 或 max batch 再送

d. Batch 拆分 / 显存估算

• 对每个请求预估 GPU 显存消耗（token 长度 × hidden size）
• 在合并时保证 batch 总显存不超过 Actor 限制
• Ray Actor 内可实现动态 batch 拆分

---

3️⃣ Ray + vLLM 合并示意

客户端请求
     │
     ▼
Ray Scheduler Actor
  ┌───────────────┐
  │ 高优先级队列   │
  └───────────────┘
  ┌───────────────┐
  │ 低优先级队列   │
  └───────────────┘
     │
     ▼
Batch 合并策略：
  - Batch window
  - Max batch size
  - 显存估算
     │
     ▼
vLLM Actor（GPU） → 推理
     │
     ▼
Ray Scheduler → 拆分结果 → 返回客户端

---

4️⃣ 核心特点

1. 控制延迟：高优先级小请求不会被大请求阻塞
2. 控制显存：batch 大小根据 GPU 显存动态控制
3. 提高吞吐：低优先级请求可合并成大 batch，充分利用 GPU
4. 弹性扩展：可动态增加 vLLM Actor，Ray 自动调度

---

✅ 总结一句话：

Ray 的合并策略本质是：在调度层对请求按优先级和显存约束做批处理，再送 vLLM，保证高优先级低延迟，低优先级高吞吐，同时利用 GPU 最大化。

---

如果你愿意，我可以帮你画一张Ray + vLLM 的完整优先级 + 合并 batch 流程图，把高低优先级队列、batch window、max batch size、GPU Actor 的关系都标出来。

你希望我画吗？