审核

审核检查的是竞技场能否使用你上传的模型和清单。它在提交创建了 testing 版本且两个文件都已进入存储桶后开始。它不评判你的策略是否强到足以获胜。

检查什么

平台按顺序执行以下阶段：

1. 确认两个对象都已按你的版本的键存入存储桶。如果缺少一个，审核会一直等到上传窗口关闭，也就是你 POST 之后三十分钟；之后版本会得到 ARTIFACT_MISSING 或 MANIFEST_MISSING，这表示上传步骤没有完成。
2. 重新计算清单的哈希并与 manifest_hash 比对。清单的长度是你的大小指标的两项之一。
3. 根据你的清单和模型文件的引用，在节点上注册模型。
4. 通过该引用获取模型文件并重新计算哈希、与你声明的摘要比对，从 protobuf 中读取计算图（参数、节点、算子、IR 版本、opset），构建执行计划，并以你的 probe_dims 在全零输入上运行五次推理。它们的中位数必须在游戏的回合时限之内，Ants 为 1,000 ms。
5. 按你所在赛季的表，根据 artifact_bytes + len(manifest) 划定重量级，并应用该重量级的 opset、算子和参数策略。
6. 在算子预算内，用你的清单处理游戏的参考观测，并检查策略头每次都能解码出有效动作。
7. 记录为 verified 或 rejected。

没有任何阶段会因为计算图开销大而拒绝它。开销的问题由对局中的回合时限来处理：错过时限的席位会被判罚。

每个适配器都必须生成清单所声明的数据类型和形状的张量，而且计算图必须接受它。请保留你自己的动作检查：平台只确认你的策略头能解码，并不评判它解码出的是不是好的走法。

查看进度

GET /v1/me/versions/{id} 返回 phase，在审核期间还返回 admit_attempt。queued 表示审核尚未开始；verifying 表示审核时钟已经接手，或某个运行器已经认领了它，或它的报告正在等待判定。公开的 GET /v1/versions/{id} 在版本登上天梯之前都回答 404。审核时钟每 20 秒运行一次，每次处理有限的一批。获取对象、构建计算图、排队和重试都会增加耗时，没有什么能保证一次提交在一个时钟周期内完成。

版本也可能因为它所在赛季根本没有审核运行器在线而停留在 queued。这不消耗它的尝试次数，所以不会算在模型头上——但它也不能无限期等下去。/status 会说明有多少台机器可以处理这个队列，赛季自己的页面则会针对该赛季说明。

运行器的审核认领持续 600 秒，一个版本最多有三次尝试。这两个都是部署值，与对局的回合时限无关。每次参考推理允许 5,000 ms；Ants 的一个回合给每个席位 1,000 ms。

已通过审核

verified 表示检查已通过，版本正在等待试赛。它还不参加常规的计分对局。平台安排好试赛后，版本响应中会带有最新的 trial：它的对局 ID、状态、地图、入队时间，以及在它待处理期间已等待的秒数。

等待试赛太久的版本不会被任何计时器作废。如果它一直停在 verified，请查看它的试赛状态：审核已经结束了。

已拒绝

提交中的问题（哈希不匹配、不支持的算子、计算图不接受的形状、适配器超出预算、缺少上传）会产生一个拒绝原因。修正文件，在你自己的机器上检查，然后作为下一个版本提交。拒绝原因列出了所有原因。

被拒绝不会影响该模型之前的参赛中版本，你的其他模型也不受影响。在你修正候选版本期间，继续用那个版本的对局来评估你的下一次改动。

平台无法完成检查时

临时的存储或容量故障会把版本送回队列，它仍保持 testing。在等待运行器期间发生的故障不消耗任何次数；在已认领它的运行器上发生的故障（无法获取模型文件、无法连接它的节点或未能及时报告）会消耗三次尝试中的一次。这类故障与你的模型无关。如果审核一直无法完成，版本最终会变为 TIMED_OUT。要请运营方调查，请报告版本 ID 以及你看到的阶段和原因；不要为了绕过暂时不可用的服务而改动本来正常的权重。

探测过慢会重试，而每次尝试都过慢就是你的问题了。测量探测的运行器可能正忙，所以中位数超过回合时限时，版本会被送回重试，并消耗一次尝试。如果三次尝试探测都超过回合时限，版本会被以 PROBE_TOO_SLOW 拒绝，其 infer_us 保存最后一次的中位数。tinybrains check 运行的是同一个探测。

ARTIFACT_MISSING 不属于这一类。存储桶为空是你的提交的问题，重试再多次也不会凭空出现字节，所以平台会拒绝这个版本。请再次提交以获得新版本和新的 URL，然后 PUT 两个文件。