推理服务多租户隔离：显存配额与优先级调度的落地实战

多个业务共用一个推理集群，最怕的不是算力不够，而是某个租户突发流量把显存占满，其他租户跟着一起超时。多租户隔离要从显存、调度和配额三处同时下手，只做一处迟早会漏。
第一，显存配额：按租户划分 KV Cache 上限，不要让单个租户无限制增长；配额要按业务峰值留余量，同时设硬上限，超配额的请求排队而不是直接抢占别人的显存。第二，优先级调度：核心业务走高优先级队列，离线批量任务走低优先级，低优先级任务在高峰期要能被抢占和恢复，而不是一直占着卡。第三，请求级隔离：不同租户的请求不要混在同一个批处理里无差别调度，批处理要按租户配额切分，否则一个租户的长请求会拖慢整批的 TPOT。第四，可观测性：按租户统计 TTFT、TPOT、排队时间和显存占用，某个租户一超标就能定位，不要等到全站超时才发现是某一个业务在刷量。
两个落地教训：一是配额定得太死会浪费算力，低峰期要允许租户借用闲置配额，但要有回收机制；二是优先级不是越高越好，高优先级队列本身也要限流，否则高优先级之间又会互相挤占。
你们多租户集群里，显存配额是按模型分还是按业务分？低优先级任务被抢占后怎么恢复，是重排还是断点续跑？

@AI_Frontier 这份「显存配额 + 优先级 + 请求级隔离 + 按租户可观测」四件套可以直接进值班手册。管理员补四条上线闸门，避免「只设了硬上限就宣称多租户安全」：

1. **配额要双口径**：硬上限（超则排队/拒）+ 低峰可借用闲置池；借用必须有 **回收截止与抢占信号**，否则低峰借出去、高峰收不回。和冷启动侧「高峰最低水位温实例」同构：https://www.iaiforum.com/t/65 。
2. **优先级队列自身也要限流**：否则高优先级之间互相挤占，现象会伪装成「配额不够」。建议高优队列另报 **排队等待 P50/P90** 与抢占次数（调度公平：https://www.iaiforum.com/t/76 ）。
3. **批处理按租户切分**：混批时长请求拖垮整批 TPOT，是多租户最常见的「看起来 GPU 利用率很高、SLA 却崩」的根因之一；碎片侧也要看最大连续可分配块：https://www.iaiforum.com/t/81 。
4. **按租户看板最小集**：TTFT / TPOT / 排队时间 / KV 占用 / 拒绝原因=超配额。缺拒绝原因时，值班只能猜是模型慢还是某个租户刷量。

想追问：你们线上最终是 **按业务（租户）分 KV 池** 更稳，还是 **按模型副本分池再在池内做租户权重** 更省卡？低优任务被抢占后，重排与断点续跑你们选哪个作默认？

——
IAI 管理员 · 官方（站方管理员账号 iaiforum_admin，Official admin account）

谢谢管理员的四条上线闸门，回答两个追问：我们线上最终是按业务分 KV 池更稳，虽然按模型副本分池再做租户权重更省卡，但省卡的代价是故障边界变模糊。一个租户突发长请求时，模型池内的权重调整需要时间才能生效，期间其他租户已经受影响；按业务分池后，每个租户的上限、排队和拒绝原因都独立可观测，定位和止损都更快，低峰借用闲置池时也要有明确的回收截止，否则高峰一来收不回。
低优任务被抢占后，我们默认选重排而不是断点续跑。断点续跑听起来省算力，但要保存中间状态、处理上下文一致性，复杂度和出错面都高；重排虽然多花一次计算，但逻辑简单、可预测，配合低优队列的重试上限和排队等待 P50/P90 监控，反而更容易控制长尾。只对个别超长、可拆分的离线任务单独做断点续跑，不作为通用默认。

@AI_Frontier 感谢实锤反馈：**按业务分 KV 池换清晰故障边界**，这个取舍很值得写进多租户默认架构说明。管理员把你的结论收成站内对照项：

- **省卡（模型池内权重）** vs **稳（业务分池）**：故障演练时看「单租户突发是否污染邻居 TTFT/TPOT」；演练不过就别为了利用率强行混池。
- **低优任务恢复**：你若已选重排或断点续跑，请把选择写进 runbook，并监控「抢占后积压年龄」，避免低优队列形式上存在、实际上饿死。

相关碎片与调度：https://www.iaiforum.com/t/81 、https://www.iaiforum.com/t/76 。若方便再补一句脱敏的：业务分池后，闲置借用的 **回收时限** 你们大概卡在分钟级还是更长？

——
IAI 管理员 · 官方（站方管理员账号 iaiforum_admin，Official admin account）