Agent 运行评估 独立测试站
目标与技术方案 ↗

COMPANY AGENT REVIEW

监管与有效性评估

原脚本提供事实,项目与 case 串起目标、结果、代价和人的评价。

已显示最近快照快照同步 2026/10/18 01:45:12

数据已显示。交互加载期间可直接使用板块链接、分类链接和表格展开;刷新可读取最新快照。

核心 case · C14

8/16卡600与2000局串行耗时验证

8卡独占实测:600局54分33秒,2000局2小时29分。

2026-10-12 04:00 至 2026-10-15 04:00(北京时间);历史核对,执行前查最新状态。

人的最终 Review

待审

尚无明确的最终评审意见。

本 case 的 token 总数

待关联

计入该目标下的相关运行与返工,尚缺关联时不估算分摊。

这次要做到什么

无其他任务干扰地测完整耗时,优先复用已有测量。 复用既有证据,按已批准8卡/16卡顺序独占串行测600/2000,冻结版本与计时边界

实际做到什么

8卡600局54m33、2000局2h29m21,视频审计回执;分别r162/r161,含启动与尾部、不含模型冷启。16卡后排。

使用的 Skill

缺少实际使用及版本证据,待核对原执行。

Agent 初评

理解2/4 / 交付2/4 / 可靠2/4 / 协作2/4

与人的最终 Review 分开。

这个 case 收到的反馈

明确状态追问与实验要求

耗时测试要是真实独占串行,并复用已有证据

并行干扰、版本变动和收尾时间必须交代。质询停在586局属于状态可理解性信号,不直接认定卡死。

处理结果:8卡600/2000已测;版本r162/r161不同,16卡后排。

下一步:暂无

我们分析一下,现在评测这边完成一个600局子集,以及完成2000局的完整任务。各自要有多长时间吧?我理解这个咱们可以端到端的跑两个测试,但是保证它串行,就是说是在没有其他任务的前提下,用最高效率完成一些实质的校验,包括600局任务用八卡最佳配置以及16卡最佳配置完成的耗时,以及说2000局的八卡、16卡最佳耗时。但是确保这四个任务本身各自都是串行的。这次确实有其目的的串行,因为我们就是完成测试。但是具体的 checkpoint 你可以自己选一个。我觉得不做多约束,你先出一版实验测试的方案,我们验证一下。
来源 1 ↗
我们现在有哪个评测是基于这种比较真实的结果测出来的吗?还是说之前的那些测试都或多或少有一些并行,并且真正影响了结果的时间?如果有这种完整的结论,其实就不用我们额外跑了嘛。但是如果没有的话,那我们就还是完整执行一次。
来源 1 ↗
dev04那个一张卡的验证预留,具体指什么?能不能清理掉呢?我觉着可能16卡的先不着急测,至少8卡这边如果是空闲的,我们就可以把任务排上。但是核心是串行任务。
来源 1 ↗
https://robodojo-results.jiujianian-dev-world.win/ui/#platform?run=p5k-dev04--v3-egostandard-12k-warningfix95-s0-20261012 怎么理解这个任务?似乎也在 04 并且也在运行
来源 1 ↗
现在 586 局状态保留很久了,是卡死了还是正常运行呢
来源 1 ↗
现在这是处理啥,600 局不是已经正常运行完成了吗
来源 1 ↗

下一步如何判断和改进

建议供评审,不表示已获准启动新的评测或整改。

建议先核对下面的证据缺口,再补充人的最终 Review;已有结果在原验收范围内判断。

原线程实测回执/审计;GPU小时、完整准备时间未统一,不由墙钟乘峰值卡数假算。

展开过程:运行范围、耗时、资源与返工

运行范围

明确独占串行:8卡600局54m33s,2000局2h29m21s;分别r162/r161。16卡分支未完成,不能补预测值。

关键时间与耗时

含启动和尾部、不含模型冷启;不同release限制横向解释。

资源使用

依人要求独占串行测量,优先复用原证据;此实验例外不能变成普通Run必须串行。

返工与人工介入

人纠正应做真实独占及复用已测结果,不把资源等待混进正常吞吐。

来源 1 ↗