核心 case · C19
异步调度与三权重跨Run补位
三权重跨Run补位实测通过，9次补位延迟0.06—1.82秒。
2026-10-12 04:00 至 2026-10-15 04:00（北京时间）；历史核对，执行前查最新状态。
人的最终 Review
待审尚无明确的最终评审意见。
本 case 的 token 总数
待关联这次要做到什么
减少同步等待，核真实空位补派与重启接续。 用三权重跨Run真实空位补派及重启验证，区分计算释放和产物回传
实际做到什么
r169三权重384局/1152视频，峰12仿真卡48worker，9次补位0.06–1.82秒；重启不重复初始化。
使用的 Skill
缺少实际使用及版本证据，待核对原执行。
Agent 初评
理解3/4 / 交付3/4 / 可靠3/4 / 协作3/4
这个 case 收到的反馈
明确性能问题后有实测；未见终态人评
回传阻塞后续计算不合理
计算结束、产物可读、审计完成是不同里程碑；槽位应按真实计算退出释放。
处理结果：r169三权重实测补位0.06–1.82秒；这是局部证据，不外推所有负载。
下一步：暂无
另外就是感觉现在的架构有问题，评测 worker 完成以后回传的流程竟然会阻塞任务继续进行。这感觉完全不合理啊，很多流程是可以异步去做的。你审计好好思考下来源 1 ↗
我觉着第一个点确实是非常严重，他可能就是应该异步化一些。 然后二的话感觉就是一个实现的问题，就是咱们现在为什么还有这种非常多同步的东西。 就是这些感觉就完全是对功能没影响，代码实现导致性能差异。 要不就直接整体先梳理一下。我们看看都有哪些东西，然后看看它的影响面都大不大。 如果不大的话，感觉就可以一口气先改着。上一版，因为我们现在正好线上没有什么评测服务，赶紧把这种优化做了。去验证，有问题修。来源 1 ↗
拖尾还有未领局时应该填空位
日志显示已有同任务多进程，实际缺口是释放与派发慢；不能重复实现已有规则。
处理结果：异步优化与真实补位已验证；冷启动/媒体回传仍耗时。
下一步：暂无
有一个评测调度机制的设计问题，现在的理念是追求资源利用率。所以在拖尾的几个任务 * 多局时，一般是一任务一进程。如果后续没有排队的情况下是不是应该让空余资源也开始消费呢？这样利用率是不是高一些。也能利用拖尾。你怎么看来源 1 ↗
我觉得 1 是我们要解决的重点，2 其实没啥好手段，而且我觉得也没必要扣这么细。现在的规则能解决 1 吗？我们能不能拿一些日志验证一下现在状态。因为我感觉很多时候似乎没跑满来源 1 ↗
空位补上这里现在的比较明显的问题都有哪些呢？来源 1 ↗
下一步如何判断和改进
建议先核对下面的证据缺口，再补充人的最终 Review；已有结果在原验收范围内判断。
已保存2026-10-14-multi-checkpoint-r169.json；容量实证仅对应这次配方。
展开过程：运行范围、耗时、资源与返工
运行范围
r169，384有效局/1152视频，9次跨Run补位0.06–1.82秒，重启无重复初始化。
关键时间与耗时
只给局部补位延迟；无整次交办统一墙钟，不能当整轮速度。
资源使用
峰12仿真卡48worker，前Run供给不足/释放后其他权重补位；用实际事件核容量。
返工与人工介入
验证重启接续与不重复初始化；实现修正和实际验收要区分。