一个大客户提交一万条 Agent 任务，怎样不拖垮其他租户？

连续追问与解答

沿着问题的前提和约束继续向下读。先理解参考解答，再尝试收起答案，用自己的话解释因果和取舍。

1. 第 1 层只设置全局 Semaphore 为什么不够？

   从保护总容量深入到租户资源分配。

   参考解答

   它限制总同时运行数，不决定哪个租户拿到名额。FIFO 队列里大租户的一万条仍在小租户前面，长任务还可能持续占满槽位。加入租户公平领取、租户并发和不同资源额度；多进程系统的全局限额也需共享协调，进程内 Semaphore 不是全服务配额。

   沿着这个回答继续深入

   1. 第 2 层加每租户 Semaphore 后，为什么小租户还可能等很久？

      父问增租户限额后，队列领取顺序仍可造成头部阻塞。

      参考解答

      若全局 FIFO 先出大量被租户限额挡住的任务，消费者可能拿着这些任务占槽或反复空转，尚未轮到小租户。先公平选可运行租户，再领取其任务并获取资源；失败领取及时释放。队列调度和执行限额要配合，不能只叠两个锁。

      沿着这个回答继续深入

      1. 第 3 层公平按条数轮询，大租户每条要一小时，小租户只要十秒，还公平吗？

         修复队列头阻塞后，任务成本差异要求重新定义公平单位。

         参考解答

         条数公平不等于资源公平。按估计执行成本或时间片分配，长任务在安全步骤边界让出，并用实际成本修正后续额度。无法安全抢占的长步骤使用独立池或更严格并发；评估小租户等待和资源占比，而不是仅比较完成条数。

2. 第 1 层Token 成本无法提前准确估计怎么办？

   公平请求分配还需考虑未知且不等成本。

   参考解答

   按保守上界或估计成本预留，限制单步最大输出和工具次数，结束按真实用量结算并调整以后估计。超出预留需追加额度或停止，未知用量留待对账；调度可先按估计成本公平领取，实际差额影响后续份额。只按任务数无法约束费用。

3. 第 1 层优先级队列会不会让低优先级饿死？

   优先级设计要处理饥饿与容量不可满足的条件。

   参考解答

   会，持续高优先级流量可能永远抢走所有资源。设置最低份额、等待增权或分池容量，限制高优先级准入，并定义超载时的拒绝策略。不可同时承诺无限高优先级吞吐和所有低优先级等待有界；目标要基于容量和测试。