题目重点：并发生成前预留预算，结束后结算，不能只数请求。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练合同有tenant预算与短期限速两层；输入token可估算，输出长度上界需配置。
- 采用硬预算不允许透支；并发/重试/流式中断的计费真值需以模型服务账单口径确认。
解题路线
- 请求携带idempotencyKey，预算账本按租户原子reserve预计最大成本，成功才发生成；不足拒绝或降低输出上限。token bucket只控制速率，不自动守住日/月总预算。
- 生成结束commit(actual)，释放多余预留；失败/中断按实际已用token结算。请求ID与reservation状态机让重试不会重复预留/重复退款。
- 长任务预留过多损害利用率，可分段追加额度，但每追加前必须原子扣减，且不能承诺已生成后再检查硬预算。超时租约回收须确认任务真正终止或以fencing拒绝旧任务继续消费。
手动走一遍
余额1000，两请求各预留600；原子处理让首个通过、第二个拒绝，不出现两次读余额均足够的超支。首个实际400，释放200，余额600。生成网络断开但后端仍运行，客户端不能立刻release全部600，否则后台消费与新请求一起突破预算。
规模与取舍
每请求若干原子账本操作，热点tenant会受单key串行吞吐限制；可授权分片额度但严格总预算需要额度守恒与回收。监控预留悬挂、账单差与拒绝率。
易错点与追问
容易失分的边界
- 估计平均输出并事后补扣不能保证硬额度。
- 退款幂等和扣费幂等同样必要，否则重试可凭空增加余额。
继续深挖
- 模型最终usage迟到，如何让账目可恢复并保持保守上界？
- 多区域服务如何分配子预算，区域断网时是否仍允许消费？
