基于Kubernetes的ML推理分布式队列设计问题咨询

核心需求拆解 #

• Worker优先消费本地已加载model_id的请求，规避模型下载、GPU加载的耗时开销
• 所有model_id的请求获得平等处理机会，避免请求量高的模型抢占过多资源

Redis实现方案 #

1. 多队列+全局调度的架构 #

• 为每个model_id创建独立的Redis列表队列，命名格式为queue:model:{model_id}
• 维护一个全局有序集合global:model:pending，存储所有有待处理请求的model_id，用分数字段实现平等调度逻辑

2. Worker消费逻辑 #

1. 优先处理已加载模型的请求：Worker遍历本地已加载的model_id列表，依次执行LPOP queue:model:{loaded_model_id}，若获取到消息则直接处理
2. 无已加载请求时的全局调度：
   • 若本地所有已加载模型的队列都为空，从global:model:pending中按平等规则选取model_id：
     • 轮询模式：将model_id的分数设置为自增序号，每次取分数最小的model_id，处理后更新其分数为当前最大序号+1
     • 随机公平模式：用SRANDMEMBER global:model:pending随机选取，保证每个model_id被选中的概率均等
   • 从选中的model_id对应的队列取消息，处理完成后：
     • 若该队列仍有消息（LLEN queue:model:{model_id} > 0），则保留其在全局集合中
     • 若队列已空，执行ZREM global:model:pending {model_id}将其移除

3. 平等处理的关键细节 #

• 避免请求量高的model_id被频繁选中：每次处理完某个model_id的请求后，延迟一段时间再将其重新加入全局集合，或者调整其在有序集合中的分数权重，平衡不同model_id的调度频率

RabbitMQ实现方案 #

1. 按模型路由的队列架构 #

• 创建主题交换机exchange.model.inference，将请求按路由键model.{model_id}发送到对应队列
• 每个model_id对应独立队列queue.model.{model_id}，可配置持久化保证消息不丢失

2. Worker动态订阅策略 #

1. 固定订阅已加载模型队列：Worker启动后，直接绑定本地已加载model_id对应的队列，优先消费这些队列的消息
2. 空闲时动态调度未加载模型：
   • 当所有已订阅队列都为空时，从全局维护的待处理model_id列表（可存在RabbitMQ的临时队列或外部存储）中按平等规则选取一个model_id
   • 临时绑定该model_id的队列进行消费，处理完该队列的所有消息后，取消绑定，回到已加载模型的队列消费

3. 平等处理的保障 #

• 全局调度列表采用轮询机制，每次分配下一个model_id给空闲Worker，确保每个model_id的请求都能被均匀分配
• 给所有模型队列设置相同的优先级（通过队列参数x-max-priority），避免高请求量模型的队列抢占资源

Kubernetes环境适配建议 #

• 用StatefulSet部署Worker，配合PersistentVolume挂载模型缓存目录，保证模型缓存的持久化和可复用
• 部署Sidecar容器专门负责模型下载、缓存更新，与Worker业务逻辑解耦，提升Worker的稳定性
• 结合Horizontal Pod Autoscaler，根据单个模型队列的长度动态调整对应Worker实例数，但需通过全局调度逻辑限制单模型的资源占用比例

内容的提问来源于stack exchange，提问作者marcOwn