我希望快机器多做任务，但“机器更快”和“这次交给它更早完成”不是一回事。它可能正在忙，或者还没加载需要的模型。
要解决什么
任务必须交给能运行它、并且还有余量的节点。第一版先减少乱分配，不追求全局最优。
有哪些方案
静态平均分配很简单，但忽略速度差异。消费者优先级可以偏向某些节点，却不会自动预测完成时间。全局调度器可考虑更多条件，也会增加状态同步成本。
我先选能力队列加有限执行槽位。当前消费者的 Qos(1) 已经限制每次一条未确认消息。任务持续积压时，快节点较早释放槽位，通常自然会多做一些。RabbitMQ Prefetch
怎样逐步做
第一步记录节点身份、支持的步骤、模型版本、计算后端、可用槽位、是否暂停接单。身份由服务端认证，不能让一个字符串就代表可信节点。
第二步用独立 Worker 进程验证一个执行槽位。节点明确订阅自己支持的队列，例如某个转写模型的任务。相同模型的 CPU、GPU 实现若都满足契约，可以竞争同一队列；不能处理的任务，不要先收下来再反复退回。
第三步保留每槽位一条未确认消息的做法。增加 prefetch 不会给当前同步 Handle 自动增加并发，只可能提前占住工作。同一 GPU 上的转写和总结也要共享资源预算，不能各自声明两个槽位就当成有四份算力。
第四步做暂停接单与排空：停止获取新工作，完成或按协议交还当前 attempt，再退出。没有可用节点时，页面明确显示等待，不把任务直接判失败。
有了测量记录，再考虑按下面的估算选择节点：
预计完成耗时 = 等待空闲的时间 + 文件传输 + 模型准备 + 推理时间
预测按模型、配置和输入时长分组更新；先用简单均值或滑动平均，并记录预测误差。新节点没有数据时用保守基线。
消费者优先级只适合作为简单偏好：高优先级节点被阻塞时，低优先级节点仍能收到任务。它不是“等待最快机器”的策略。RabbitMQ 消费者优先级
怎么验收
给两个速度不同的节点提交同一组短任务，统计各自完成数、耗时和等待。再让快节点忙于长任务，观察短任务是否仍有机会被空闲节点处理。
先交付这两组原始记录。只改优先级、没测用户完成时间，不算证明调度有效。