题目重点：消息突增会影响排队、模型容量和客户端状态，不只是HTTP吞吐。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练有会话、生成请求、流事件和外部工具动作；实际bot实现未给，先定义要恢复哪些state。
- 恢复不保证把任意模型中间计算从断点继续；若模型不支持checkpoint，需将请求标interrupted并定义重试。
解题路线
- 列负载链：入口validation/rate limit、持久queue、model worker、stream gateway、storage。队列上限/过期和tenant budget先定，输入无限增加不是仅靠autoscale即可解决。
- Conversation/Message/GenerationRequest分别持久，request ID防用户重发创建两个回复；stream带seq及done，客户端断线可补流。模型算力满时明确accepted/queued，而不是长连接等待后全部timeout重试。
- 工具动作使用action ID、持久结果与权限检查；恢复重放只重建状态，不无条件再次发邮件/执行付款。外部动作成功但本地未知需查幂等结果，不能凭当前聊天记录猜。
- 崩溃恢复从snapshot+event log还原已确认消息和request状态；running失联标unknown/interrupted，确认worker lease再决定retry，attempt fence阻止旧生成继续覆盖结果。
- 观测queue age、in-flight tokens、time-to-first-token、生成完成率、断流/重试倍率和成本。给用户可取消/状态查询，削峰时优先缩scope/容量明确拒绝而非让无限积压拖垮恢复。
手动走一遍
用户等30秒无首token后点三次提交，幂等ID应返回同queued request，而不是形成四个模型job。bot重启后工具动作已完成，事件结果可重建答案，不再发同一外部操作。
规模与取舍
模型资源按输入/输出tokens及服务时长，连接数、存储写与工具调用单计。备份RPO/RTO须明确哪些已ACK数据可丢、多久恢复；内存snapshot不满足进程重启持久恢复。
易错点与追问
容易失分的边界
- 只扩API实例而GPU/模型quota才是瓶颈。
- 恢复state后自动重执行所有历史动作。
继续深挖
- 有限模型容量下不同租户长短请求如何公平排队？
- stream无resume能力时，用户重试体验如何说明？
