题目重点：排队受理不等于生成完成，GPU资源需要按任务内存与拓扑分配。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练是类似视频生成产品的系统设计，不描述任何实际产品内部架构。prompt→异步生成job→视频结果，模型具体结构与GPU数量未披露。
- 定义用户延迟目标、时长/分辨率上限、取消和公平配额；任务可能占单卡或多卡，单GPU/job只是一种合同，不通用于所有模型。
解题路线
- Job(id,user,request_hash,model_revision,parameters,status,attempt,artifact_ref)受理持久化，返回job ID；ready/running/completed/failed/canceled状态明确，retry同用户request key不重复收费或建作业。
- 资源scheduler按显存、GPU型号、卡数和互联要求匹配node inventory；多卡gang scheduling一起获取资源，避免逐卡占用死锁。warm model workers减少加载延迟，模型版本/精度必须与job绑定。
- worker用lease/attempt generation回报，心跳失联标unknown并查真实运行；retry产物按attempt暂存，只有条件提交的winner artifact成为结果，旧worker完成不覆盖新版本。
- 任务长且GPU昂贵，取消需协作检查和资源释放确认。可保存可恢复阶段/checkpoint，但随机seed与模型/调度决定复现条件，不保证任何中间latent在版本变化后可继续。
- 区分排队、模型加载、推理、后处理、上传与播放准备时间。按用户/任务大小公平队列，超大任务不堵全部短任务；结果经对象存储/CDN分发，GPU不直接服务每个下载请求。
手动走一遍
一个任务已写视频但完成消息丢失，重试/恢复查artifact manifest和attempt提交，不重新对用户重复收费。4卡job不能在四台无足够互联的单卡机器上随意拼接，拓扑是资源约束。若每job平均60 GPU-seconds、受理100/s，满载算力至少6000 GPU等效，实际还要考虑批处理、规格及利用率。
规模与取舍
资源需求由GPU-seconds、显存和排队SLO共同决定；元数据写与视频bytes分别预算。多卡placement及不同任务时长使简单FIFO可能严重碎片化，不能只用总GPU数推稳定延迟。
易错点与追问
容易失分的边界
- 完成事件早于artifact持久可读，用户拿到空下载。
- 租约到期就宣称旧GPU进程已停止。
- 用HTTP同步等待长生成并在超时后重建任务。
继续深挖
- 如何在deadline、公平、GPU利用率和长任务饥饿间取舍？
- 生成中间预览会带来哪些存储、审核和状态版本要求？
