摘要
战斗画面的英雄 HUD 区域有英雄头像。项目已有一个图标分类器能认头像，本实验想在一组独立准备的 16 张头像裁图（简称 HUD16）上，用事先固定的策略跑一次“影子运行”：私下计算结果、不接入任何产品，只看分类器在这组裁图上会怎么判。
为了不影响同时在跑的其他任务，这次运行被限制在一个很紧的资源窗口里，而且只允许运行一次。结果：唯一的一次运行在模型初始化阶段超过了 20 秒的期限，被强制终止，没有产生任何可评分结果。按规则，失败原样保留，不重试。
要回答的问题
在固定策略、严格资源限制下，现有头像分类器对 HUD16 这 16 个裁图会给出什么排名和接受决定？
数据与来源
- HUD16：16 张从原生截图裁出的英雄 HUD 头像（194×226 像素，RGB），来自两个来源组，经过数据方和质检方联合冻结。准入时：9 个可读身份、6 个任务控制样本（2 个场景角色、4 个纯 UI）、1 个待定。
- 更早的一组 HUD10 输入不重新运行；留出的来源不包括在内。
- 参考答案不作为输入；运行只读取中性的清单和文件时间戳。
- 分类器：已有的图标分类器检查点。
方法
预检（--preflight-only）只读清单和准入元数据，确认 16 行、两个来源组、裁图尺寸以及原图/裁图时间戳都没变，不建目录、不起进程、不解码图像。预检通过。
实际运行还需要明确的资源释放授权，然后只创建一次 run-001，已存在就不覆盖、不自动重试。资源限制：
| 限制 | 值 |
|---|---|
| 进程 | 一个挂起启动的工作进程，放入专属的 Windows Job，关闭即杀 |
| 内存 | 提交内存上限 2 GiB，峰值常驻内存守卫 2 GiB |
| 时间 | 初始化 20 秒、批处理 5 秒、共享工作期限 25 秒、含清理总共 30 秒 |
| 计算 | 最多 16 次裁图解码和 16 次全库 NCC 排名，一次模型加载，一批 CPU float32 推理；各数学库线程数 2 |
| 禁止 | 额外预热、拟合、改裁图、OCR、GPU、训练、下载、视频解码、网络连接 |
输出原计划保存完整的 77 类原始排名、旧运行时的决定，以及单独的“仅有效性门槛”决定（门槛 .494140625）。
设置
运行前做过一次仪器软件验证：3 个人造分组，0 错误、0 失败，没有调用模型、OCR、子进程或读取图像——这只证明调用框架本身的逻辑，不是识别结果。
结果
| 项目 | 实际 |
|---|---|
| 状态 | INITIALIZATION_DEADLINE（初始化超时） |
| 耗时 | 20.031 秒 |
| 工作进程退出码 | 124 |
| 峰值常驻内存 | 441,368,576 字节（约 0.41 GiB，未超 2 GiB） |
| 记录到的阶段 | 只有 worker_started（0.078 秒） |
| 模型是否就绪 | 否 |
| 工作进程日志 | 空 |
| Job 中进程总数 / 结束时仍活动 | 2 / 0 |
没有任何可评分的排名或决定。
失败与负结果
整个实验以失败结束：工作进程启动后 20 秒内没有完成模型初始化，被期限终止。内存不是原因（峰值约 0.41 GiB）；日志为空，所以从这次运行本身看不出卡在哪一步（导入、加载检查点还是别的启动步骤）。
按事先约定：失败保留、不重试；不把它算作头像准确率、3 秒目标或 p95 的任何证据；资源窗口立即归还；之后只允许只读地排查启动过程和进程成员，并做可逆的软件修复，不能直接开第二次模型窗口。
局限
- 没有产生任何识别数据，不能对分类器在 HUD16 上的表现下任何结论。
- 预检和仪器软件验证通过，只说明输入冻结和调用框架正确，不是识别准确率、校准或速度。
结论与下一步
在这么紧的初始化期限下，冷启动的模型加载没能完成。若要重新尝试，需要先只读地定位启动慢在哪里（例如进程启动、依赖导入或检查点加载），做可逆修复，再申请新的、单独批准的窗口。
Comments