性能优化（1）-请求合并 / 优先级队列-RAY调度器

目录

• 为什么需求请求合并和分优先级
  • 1️⃣ 为什么需要 优先级队列（Priority Queue）
    • 场景示例
  • 2️⃣ 为什么需要 请求合并（Batching / Merging）
    • a. 控制 batch 策略
    • b. 高级调度策略
  • 3️⃣ 总结
• 1️⃣ Ray 能做什么
  • 2️⃣ 工作流程示意
  • 3️⃣ 为什么用 Ray 而不直接依赖 Nginx
  • 4️⃣ 实践建议
• 参考资料

为什么需求请求合并和分优先级

明白，你想彻底搞清楚 为什么 AI 网关 / 调度层需要优先级 + 请求合并，尤其是在 vLLM 已经有 continuous batching 的情况下。我给你分层解释。

---

1️⃣ 为什么需要 优先级队列（Priority Queue）

即便 vLLM 有 continuous batching，仍然有场景需要区分请求重要性。原因：

场景示例

请求	类型	长度	优先级理由
A	聊天消息	50 token	高优先级，用户交互，低延迟要求
B	长文生成	1000 token	低优先级，批量生成，可等待
C	小查询	60 token	高优先级，交互请求

如果没有优先级队列：

• vLLM 收到 A、B、C 直接合并 batch
• 结果：A 和 C 可能被 B 阻塞，延迟突然变高
• 对用户体验不友好（聊天延迟长）

优先级队列作用：

• 把高优先级请求单独处理或提前进入 batch
• 低优先级请求可以等待更多合并，提高吞吐
• 延迟可控，体验可预测

---

2️⃣ 为什么需要 请求合并（Batching / Merging）

即便 vLLM 支持 continuous batching，AI 网关仍然可能做请求合并，原因如下：

a. 控制 batch 策略

vLLM 的 continuous batching 是 GPU 层面的“短时间窗口自动合并”，不可控：

• 无法区分高低优先级
• 窗口非常短（5–20ms）
• batch 大小可能不稳定

AI 网关做请求合并可以：

• 设置最大 batch size，控制显存占用
• 按业务策略决定哪些请求可以合并
• 提前把低优先级请求积累成大 batch，提高 GPU 利用率

b. 高级调度策略

比如：

• 高优先级请求 → 小 batch，保证低延迟
• 低优先级请求 → 大 batch，提高吞吐

vLLM continuous batching 只能保证 GPU 吞吐最大化，但不能保证延迟和业务优先级

---

3️⃣ 总结

层级	功能	目标
AI 网关 / 调度层	优先级 + 请求合并	业务层优化：延迟可控、高优先级优先、batch 可控
vLLM	continuous batching	GPU层优化：吞吐最大化、显存高效利用
结合	网关先做优先级 + 合并 → vLLM 做 continuous batching	端到端最优：高并发下延迟和吞吐平衡

核心思想：

• 网关调度 = 谁先上车 + 一起上车
• vLLM 推理 = 上车后如何排满 GPU 座位

1️⃣ Ray 能做什么

Ray 本身是一个分布式计算框架，可以提供：

1. 任务调度

   • 将请求封装成任务（task 或 actor）
   • 自动调度到空闲 GPU 或 CPU 上

2. 请求合并 / 批处理（Batching）

   • 可以把多个请求在短时间窗口（batch window）内收集起来，合并成一个 batch
   • 类似 vLLM continuous batching，但可以在 vLLM 外部控制
   • 可以按业务优先级分队列

3. 优先级队列 / 延迟策略

   • Ray actor 可以维护不同优先级队列
   • 高优先级请求可以先被调度
   • 低优先级请求可以等待更长时间被 batch 合并

4. 多模型 / 多 GPU 调度

   • 支持把不同模型部署到不同 GPU
   • 支持同一模型多实例，自动负载均衡

---

2️⃣ 工作流程示意

客户端请求
     │
     ▼
  Ray Actor（调度器）
     │  ┌───────────────┐
     │  │ 高优先级队列   │
     │  └───────────────┘
     │  ┌───────────────┐
     │  │ 低优先级队列   │
     ▼
  批合并（batch window）
     │
     ▼
  vLLM 推理（GPU）
     │
     ▼
  返回结果给 Ray Actor
     │
     ▼
客户端响应

---

3️⃣ 为什么用 Ray 而不直接依赖 Nginx

特性	Nginx / Envoy	Ray
批处理 / 合并	❌ 不支持复杂 batch	✅ 完全可控（batch window, max batch size）
优先级队列	✅ 支持简单权重或限制	✅ 支持多级优先级、延迟策略
GPU 调度	❌ 无	✅ 自动调度任务到 GPU actor
多模型 / 弹性	❌ 需手动部署多实例	✅ 内建支持多模型、多实例负载均衡
监控 /指标	✅ 限流 QPS	✅ 完整任务 / GPU utilization 监控

---

4️⃣ 实践建议

1. Ray actor + vLLM

   • 每个 actor 管理一个 vLLM 实例（可以是单卡或 TP）
   • actor 内部保持连续 batch 机制

2. Batch Window 控制

   • 窗口长度可调，通常 5–50ms
   • 窗口内收集多个短请求合并成 batch

3. 优先级策略

   • 高优先级请求 → 优先 batch → 保证低延迟
   • 低优先级请求 → 可以等待更多请求合并 → 节约 GPU

4. 弹性扩缩容

   • 高负载时可以启动更多 actor / GPU
   • Ray 调度器会自动均衡任务到空闲 GPU

---

✅ 总结：

通过 Ray 调度器做请求合并完全可行，而且比 Nginx / Envoy 灵活，可以同时实现：

• 多级优先级队列
• batch 合并控制
• GPU actor 弹性调度
• 多模型负载均衡

参考资料

Ray调度器合并策略
https://www.cnblogs.com/aibi1/p/19492626