题目重点：当 GPU 容量突然减半，结合服务能力、排队时延、429、付费层级和模型版本更新设计闭环控制。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 以每秒可处理 token 而非请求数作为主要容量单位；服务速率 μ 随模型、输入/输出长度、批量形状变化，不把 GPU 数量直接等同处理能力。
- 训练版付费和免费各有逻辑队列、最小保留容量与可借用空闲份额；具体合同/SLA/429 策略题目未明确，需要产品约束。
- 请求 deadline、已接入排队上限和重试提示头都是设计参数；用户优先级决定服务分配但不改变安全/权限校验。
解题路线
- 首先把健康 GPU 从调度池摘除并阻止继续派单；在入口估算每个请求的 token 负载，结合当前可用 GPU 的实测吞吐得出 μ。容量减半时，若到达负载 λ 仍大于 μ，队列长度按 `dQ/dt≈λ−μ` 增长，必须尽快减少新接入负载。
- 将队列监控从仅看条数升级为排队 token 工作量与等待时间，按模型/层级分别统计 p50/p99、超时率、完成率、batch fill 与拒绝率。控制器可用 EWMA 平滑容量和队列延迟，以水位区间逐步调紧各 tier 的 token bucket / concurrency permit；紧急水位立即返回 429 或 503 并给有界重试建议，不能只让所有人经历无限长排队。
- 付费/免费分别排队，按保留份额加可借用配额调度；免费的等待可降级或拒绝，付费仍需有上限。长期高优先级占满时对低优先级设置最小服务或明确的拒绝承诺，避免无期限饥饿。
- 恢复阶段逐步加回健康 GPU、预热模型并验证错误率/延迟，再缓慢放宽准入，防止重试风暴。模型更新属 control plane：新旧版本流量分流、容量预算、回滚和缓存键必须含模型版本；prompt cache 可减重复计算，但不能把语义近似命中当作精确相同输入。
手动走一遍
训练例健康状态服务能力 100k token/s，常态到达 70k。半数 GPU 故障后实测只剩 48k token/s，若仍接 70k，未处理工作每秒增加约 22k token。即使聚合层降低消费速率，也只是把等待前移；入口必须把新接入压到不超过 48k 且留恢复余量。若付费保证 30k、免费保留 5k，剩余容量可暂借；这些数值是示例而非题目 SLA。
规模与取舍
入口判断和 token bucket 更新期望 O(1)；有序/按 deadline 调度可用 O(log Q) 入出队，Q 是排队请求数。控制器采样 O(队列/模型/层级数量)，不是算法复杂度的主风险；主风险在估载误差、控制滞后和重试放大。
易错点与追问
容易失分的边界
- 半数 GPU down 仍只调低 worker poller，却不限制入口，等待和内存继续增长。
- 只看请求 QPS，不看 prompt/输出 token 差异。
- 把付费和免费混一队列，却事后声称能稳定保证付费尾延迟。
- 容量一恢复就解除全部限制，导致缓存冷启动和用户重试同时冲击。
- 把候选人的队列/缓存实现细节当成原题给定组件。
继续深挖
- 如何在无法准确预测输出 token 数时设置准入预算与事后扣账？
- 请求正在执行时 GPU 故障，是否重试、何处记录幂等性、如何避免重复计费？
- 模型滚动更新和集群故障叠加时，怎样预留安全余量？
