在《英雄无敌：上古纪元》的战场上，部队会移动、转身，也会被邻近单位和法术特效挡住。策略程序要理解当前局面，首先得知道哪些位置还有活着的部队。一个把尸体、石头或顶部头像也框出来的检测器，会把后面的状态判断带偏。
我们用401张逐图审核的原图训练公开COCO模型，让它们完成同一项任务：输入完整截图，输出每支可见存活部队的位置框和分数。比较对象是FCOS、YOLO26s和RT-DETRv2；YOLO另加一组梯度累积对照，实际是三个模型家族、四套训练配方。
在75张来源隔离的测试图上，FCOS的AP50:95为70.67，验证集选出的YOLO26s配方为70.21。AP50:95综合不同框重叠要求下的检测表现，这里按满分100显示，后文解释具体计分。两者分数接近，但后者在选定阈值下漏检更少；已驻留单图检测中位数分别为37.83ms和11.85ms。本轮保留FCOS作为按验证AP选出的定位精度候选，把YOLO26s作为快速、高召回的候选框方案。 输入大小、训练配方和参考框来源都影响比较，冷启动也出现了一次需要单独解释的异常。
B12介绍了怎样收集战场框、补充生物身份，并保留此前的小规模检测与分类实验。本篇使用扩大的审核数据，单独回答“哪种检测方案能把部队框得准、跑得快”。读者不需要先读 B12。
flowchart LR
A[Full screenshot] --> B[Model-specific resize]
B --> C[Trained detector]
C --> D[Native-coordinate boxes]
D --> E[Compare and measure]
F[Reviewed reference boxes] --> E图 1：每个模型都从完整截图开始，参考框只进入训练和离线评估。实际识别时没有人工框、单位名字或相邻帧提示。
1. 一个框代表一支存活部队
这个游戏里，画面上的一个生物模型通常代表一整支部队。模型脚下的数量可能是 1，也可能是 200；本次都只画一个框。我们框住可见的身体、坐骑和装备，尽量排除数量徽标、光圈和影子。只露出一部分身体，但仍能确认是活着的部队时，也保留一个参考框，并注明部分遮挡。
下面这张原图同时包含场内生物、场边英雄、行动顺序头像和地面物体。检测器收到的是这张完整原图的像素，而不是事先裁好的生物图片。
审核后，这张画面保留了六个活体参考框。图中名称帮助读者理解对象，但训练检测器时会把这些不同身份统一为一个类别：living_creature_stack，即存活生物部队。
整个流程可以这样理解：先确认当前是战场，把截图按某个模型的要求缩放，模型找出候选框，再把坐标还原到原图。离线评估时才把预测与图 3 这样的参考框比较。后续身份分类器可以分别读取这些框内的裁图，但名字认对与框画对是两个问题，本篇只测后者。
场景分类已经在前级完成；本次不评价把菜单误送进检测器的情况。尸体、地形、场边英雄和 UI 头像都属于非目标。它们仍完整地出现在模型输入中，没有先按固定区域抹掉。
2. 722 张审核原图里，哪些能训练检测器？
两批数据共有 722 张原图、7,651 个已知身份框。这并不表示全部图片都适合训练检测器：有些画面正在过渡，有些只能确认几个局部目标，尚不足以确定图中所有活体。只标出一半目标的图片，会让训练器把另一半真实部队学成背景。
本次因此使用完成全画面检查的 619 张原图、7,289 个框。其余 103 张不进入本轮完整检测比较；其中可用的单个裁图仍可用于身份分类研究。训练时只读取活体框，所有身份合并为一个检测类别；结果不输出种类或名字。
先按录屏分组，再训练
同一场战斗连续截出的图片非常相似。如果随机分图片，模型可能在训练时已看过测试画面里的同一军队、站位和背景。这里把整段来源视频放在同一个分组，保留旧实验曾使用过的保护来源，另取新录屏作为验证和测试。
| 数据组 | 原图 | 活体框 | 来源视频 | 用来做什么 |
|---|---|---|---|---|
| 训练 | 401 | 4,588 | 28 | 更新模型权重 |
| 验证 | 54 | 715 | 2 | 选训练轮次、分数阈值与候选方案 |
| 测试 | 75 | 969 | 2 | 选择固定后，做最终比较 |
| 旧保护来源 | 89 | 1,017 | 5 | 保留历史对照，不用于本次训练或选模型 |
| 合计 | 619 | 7,289 | 37 | 四组各有独立用途 |
去掉89张旧保护来源，本次实际参与训练、验证和测试的是 530张、6,272个框。619张的原图分辨率分别为：491张2560×1440、20张1920×1080、108张1920×1078。没有先把这些原图统一压成小缩略图再作为训练来源。
验证来源是 9 月 5 日 03:51 和 9 月 6 日 03:13 的两段录屏；测试来源是 9 月 5 日 06:05 和 9 月 6 日 22:46 的两段录屏。75 张测试图覆盖洞穴、草地、熔岩、红珊瑚、岩地和雪地六种地图外观，数量分别是 11、6、11、20、14 和 13 张。验证图覆盖其中四种；训练组也包含六种地图，因此这是换来源视频的测试，不是完全没见过地图的测试。
旧数据里有些地图类别尚未记录，仍可凭完整活体框训练；我们不会给它们猜一个地图名后再计算分地图成绩。
尸体负样本有什么作用？
另有 36 个已明确指出的非活体裁图：21 个尸体、13 个地形、1 个场边英雄和1个头像。它们让我们能具体检查“模型会不会把这个东西误当活体”，也可用于后续裁图有效性分类器。
这些困难例中，31个属于训练来源，5个属于测试来源；测试里的5个全部是尸体，而且只来自2张原图。这只能支持局部的尸体误报检查，远不足以证明模型在所有战斗里都会排除尸体。
它们是有目的收集的困难例，不能表示每张原图里的所有尸体都已经标完。因此本轮不直接训练“活体、尸体、地形”多类检测器。完整活体标注图中的其他区域正常作为背景；这36个额外裁图不单独复制进检测训练集，且始终跟随原视频的分组。
标签由助手查看原图、放大区域和必要的相邻帧后确认，用户接受它们用于训练。具体来说，冻结的B12 FCOS先提出候选框，助手再逐帧审核、补漏和修正；许多被接受的框仍沿用了候选框的位置与边界。因此，参考标注可能偏向FCOS习惯的框形状，尤其会影响要求边界更精确的AP指标。
按来源隔离，不等于独立盲标。 这次可以检验模型在新录屏上的表现，但不能仅凭几个AP点的差异宣称某种架构普遍更好。六种地图共享同一游戏的美术与界面，两个测试来源也不足以代表所有版本和录制条件。
3. 为什么比较 FCOS、YOLO26s 和 RT-DETRv2？
公开检测模型通常先在自然照片上训练，学过人、车、动物等对象。这里利用这些基础视觉能力，再用战场框微调。三个模型都重新从公开 COCO 权重开始，没有用先前的战场微调权重继续训练。
FCOS：保留熟悉的特征，重新学习战场目标
FCOS从图像中提取多个尺度的特征，在特征图的每个位置判断是否靠近目标，并预测框的边界。多尺度特征金字塔 FPN 让同一模型同时处理较大和较小的单位。它不需要先放置一组固定形状的候选框，通常称为 anchor-free 检测器。
本次使用 ResNet50-FPN 版本，保留并冻结已经学好的特征骨干，只训练负责分类和修框的检测头。这样能直接复用已有工程经验，并以较少需要更新的参数适应战场。代价是骨干没有进一步适应游戏纹理，最后是否足够，要看验证结果。FCOS论文与torchvision模型说明提供结构和公开权重依据。
YOLO26s：把部署速度作为一个明确候选方向
YOLO26s是一种轻量实时检测器。它也从多个尺度预测目标，但网络更小，设计中同时考虑了推理开销。我们选择 small 规模，而非最小的 nano，希望在小生物和速度之间保留一些余地；这只是选择待测候选的理由，不代表它一定更适合本游戏。
传统检测器经常为同一对象给出多个重叠框，再用非极大值抑制（NMS）留下较高分的框。这能去重，但两个真实单位挤在一起时也可能互相影响。本次选择YOLO26的端到端分支，让模型直接学习输出较少重复框，推理不再另做NMS。运行时显式设置 nms=False，不混用另一个默认分支的结果。YOLO26官方说明
RT-DETRv2：让一组检测查询共同寻找目标
RT-DETRv2用卷积骨干提取图像特征，先从这些特征中选择候选，再让一组检测查询通过注意力读取周围信息，逐步修正框。查询是一种携带候选信息、继续向图像特征取信息的向量，它不需要我们预先指出生物在哪。训练会把预测与参考目标进行一对一匹配；推理同样不依赖额外NMS。
本次使用较小的 ResNet18 版本，对应 PekingU/rtdetr_v2_r18vd 公开权重。它提供与前两种不同的检测方案，同时保持较小模型规模。没有NMS不意味着一定不会漏掉重叠单位；它仍需要从有限像素里判断有几个不同目标。RT-DETRv2论文与作者模型卡
公开指标帮助选候选，不能代替本地测试
截至2026年9月8日，一手来源提供了下面这些参考值。AP50:95衡量检测框在一组不同重叠要求下的整体表现，后文会解释怎样计分。
| 公开模型 | COCO AP50:95 | 原作者速度条件 |
|---|---|---|
| FCOS ResNet50-FPN | 39.2 | 官方模型页未列毫秒延迟 |
| YOLO26s端到端分支 | 47.8 | 640输入，T4 / TensorRT10，2.5ms |
| RT-DETRv2-S / R18 | 48.1 | 640输入，T4 / TensorRT FP16，217FPS |
来源：FCOS、YOLO26、RT-DETR。YOLO26s另一个默认分支的公开AP是48.6，但上面的速度测的是端到端分支，不能把48.6和2.5ms组合为同一路径成绩。RT-DETR的217FPS按倒数约为4.61ms，这只是单位换算。我们不会由这些不同公开条件推算RTX5080上的战场速度。
调研也包含两阶段的 Faster R-CNN、基于DINOv2视觉特征的 RF-DETR Small，以及训练时借助视觉基础模型蒸馏的 RT-DETRv4。RF-DETR Small的公开结果很有吸引力：512输入、COCO 53.0 AP，T4 TensorRT FP16单图3.5ms；其官方测量在forward之间留有缓冲，不等同持续视频吞吐。这些模型本轮只做选型参考，没有战场实测行，不会与三种实际训练结果混在一起。Faster R-CNN官方权重、RF-DETR基准方法、RT-DETRv4官方实现
生产选型还包括软件许可。torchvision采用BSD-3-Clause，RT-DETR采用Apache-2.0；Ultralytics为其代码与模型提供AGPL-3.0或Enterprise路径。因此YOLO即使本地结果更好，也需要结合计划中的发布方式选择许可。这里记录维护方条款，不把模型的开放下载等同于所有使用方式没有限制。torchvision许可、RT-DETR模型许可、Ultralytics许可说明
4. 三个模型到底看见多大的图？
三个模型读取同一批完整原图，没有人工裁图、棋盘区域裁切或图片切片。它们内部需要的张量形状不同，所以“用了同一张截图”并不等于“处理了同样多的像素”。
以图2的2560×1440原图为例：
| 模型 | 输入如何变化 | 实际影响 |
|---|---|---|
| FCOS | 保持比例，短边目标800、长边上限1333，再补齐计算网格 | 实际图像1333×749，张量补齐至1344×768 |
| YOLO26s | 保持比例缩到960宽，补边成为960×960 | 图像内容约960×540，其余为补边 |
| RT-DETRv2 R18 | 整张图直接缩放成640×640 | 横纵缩放比例不同，原有宽高比例被改变 |
因此一个原图宽100像素的单位，进入YOLO时大约只有37.5像素宽；进入RT-DETR时宽度大约25像素。模型仍然能利用周围信息，但小目标的细节已经减少。FCOS保留更多空间采样，计算量也随之增加。这一轮比较的是可运行的整套配方，不能把成绩差异完全归因于架构。
训练范围也不同
全部训练使用同一随机种子，预算上限为30轮。FCOS与YOLO允许在验证指标连续10轮不提升时提前停止；RT-DETRv2使用固定学习率，完整运行30轮，再选择其中验证AP最高的权重。数据增强仅作用于训练图片，用于模拟位置和亮度变化。
| 模型 | 哪些参数更新 | 训练设置 |
|---|---|---|
| FCOS | 冻结骨干与FPN，更新检测头 | AdamW，学习率0.001，batch4，FP32；翻转、轻微亮度与对比度 |
| YOLO26s | 完整模型微调 | AdamW，初始学习率0.001，batch8，混合精度；轻微几何变化和部分mosaic |
| RT-DETRv2 R18 | 完整模型微调，保留预训练批归一化统计 | AdamW，骨干学习率0.00001、其余0.0001，batch4，FP32 |
这里的batch表示一次前向计算同时送入多少张图片，未必等于一次权重更新看到的总量。FP32是32位浮点计算；YOLO训练使用混合精度以降低显存和计算开销。最终共同评估与测速都使用FP32张量。mosaic把多张训练图组合到一个画面里，改变单位周围的上下文；它只是一种训练增强，测试仍使用完整真实截图。
YOLO增加一组对照：相同30轮，不一定更新相同次数
检查训练配置时，我们发现Ultralytics默认的名义batch为 nbs=64。实际batch是8时，预热结束后会先累积8次前向与反向计算的梯度，再更新一次权重；大多数更新因此汇集约64张图的信息。梯度累积可以在显存有限时模拟较大的batch，但也意味着同样跑完30轮，模型更新次数可能远少于按每个batch更新的配方。
因此在运行最终测试之前，新增一组 nbs=8 的YOLO对照，其余设置不变。它每个实际batch更新一次，用来检查更新频率对这批小数据的影响。两个YOLO都从同一个公开COCO权重重新训练，不从另一配方的战场权重接着跑。
| YOLO配方 | 实际batch | 名义batch | 预热后怎样更新 |
|---|---|---|---|
| 原配方 | 8 | 64 | 累积8个batch，再更新权重 |
| 额外对照 | 8 | 8 | 每个batch更新权重 |
原配方的“219次”只是按框架源代码回放得到的更新调度机会，未直接记录优化器成功执行的次数，因此不能把219称为实测成功更新数。新增对照在优化器成功执行时直接计数：1,530次尝试中成功更新1,524次，混合精度跳过6次。相同轮数不等于相同更新预算；未实测的原配方成功步数仍记为未知。
这是一项训练配方对照，没有新增第四种检测架构。共同接口的验证AP50:95为：原配方68.80，额外对照69.19，因此在测试前选定nbs8作为YOLO家族的代表。最终测试仍保留两个YOLO配方，没有看过测试后倒过来更换代表。这个单种子的小幅差异只支持本轮配方选择，尚不足以证明nbs8总会更好。
checkpoint选择保留各框架的训练方式
checkpoint是某一轮保存下来的模型权重。FCOS和RT-DETR直接用共同的COCO评估程序计算验证AP并选择权重；YOLO先用自身框架的验证指标选择权重，再进入共同评估。
YOLO这里还有一个容易忽略的差别：Ultralytics 8.4.144训练中的验证器会组织保持比例的矩形batch；即使训练设置了 rect=False，也不能据此称每次内部验证都使用960×960张量。我们后续的共同验证、测试和测速明确用960×960的方形补边输入。YOLO权重按它的原生验证配方选择，最终成绩按本文统一接口计算。 这个差别随结果一同保留。
实际记录能说明这两个阶段的区别：原YOLO配方由原生验证选中第23轮，AP为69.37；同一权重经过共同的960方形输入评估，验证AP变为68.80。nbs8选中第21轮。FCOS与RT-DETR分别选中第9轮和第3轮，最终使用的不是最后一轮权重。
训练成本与模型规模
| 配方 | 完成 / 选中轮次 | 观测训练耗时 | 成功权重更新 | 参数量 / 可训练参数量 |
|---|---|---|---|---|
| FCOS | 19 / 9 | 768.82秒 | 1,919 | 32.12M / 4.74M |
| YOLO nbs64 | 30 / 23 | 1,024.12秒 | 未记录 | 9.95M / 全部微调 |
| YOLO nbs8 | 30 / 21 | 1,257.36秒 | 1,524 | 9.95M / 全部微调 |
| RT-DETRv2 | 30 / 3 | 1,241.38秒 | 3,030 | 20.07M / 20.07M |
参数量来自本地单类模型，YOLO统计在推理融合之前，所以不直接等于公开COCO表的参数量。FCOS和RT-DETR耗时包括训练循环、逐轮验证和输出；YOLO记录整个框架训练调用，还包括框架准备和最终最佳权重验证，计时边界并不完全相同。
表中成功更新数属于完成的整段训练，不等于选中权重已经经历的更新数。例如nbs8的第21轮权重对应1,071次更新尝试、1,065次成功更新；1,524次是完整30轮的总数。
固定训练、验证来源避免了把测试图拿去调参；输入和训练差异则说明，这不是只替换网络结构的等算力消融。额外YOLO对照与RT-DETR的后期训练部分重叠，使用同一块GPU，因此上述耗时仅记录本次开发成本，不能公平比较训练速度。推理测速在训练全部结束后独占GPU，依次运行。
5. 框画出来了，怎样判断对错？
首先比较预测框和参考框的重叠。IoU是两框交集面积除以并集面积：完全重合时为1，完全错开时为0。工作点统计要求IoU至少0.5，且一个参考目标只能匹配一个预测框。同一个部队被框两次，多出的那个框算误报。
- 精确率：模型画出的框，有多少匹配了真实活体。把尸体或石头框出来会降低它。
- 召回率：参考中的活体有多少被找到。漏掉被翅膀挡住的单位会降低它。
- F1：综合精确率和召回率，避免只靠少画框或大量画框获得单项高分。
每个模型在验证集上，从0.05到0.95、每隔0.05选择分数阈值，以F1最高为准；相同时先选择精确率更高的，再选择更高阈值。阈值在打开最终测试结果前保存。模型分数用于排序与筛选，未经校准不解释为“这个框正确的概率”。
同时保留一个优先减少误报的工作点：在相同验证阈值里，先要求精确率至少98%，再选择召回率最高的；相同则优先更高精确率、再选更高阈值。如果没有阈值达到要求，会明确报告未达标，退而选择精确率最高的点。这个工作点也在测试前固定。98%是验证集上的选择目标，不是对新视频或生产运行的准确率承诺。
单个阈值仍不能展示完整表现，因此还计算标准COCO AP：遍历不同分数阈值，汇总精确率与召回率。AP50要求IoU至少0.5；AP50:95进一步把0.50、0.55直到0.95的要求一起平均。一个只把单位大概框住的模型，可能AP50不错，但更严格的AP50:95较低。
共同评估使用官方 pycocotools，每张图保留分数至少0.001、最多100个预测，不额外过滤固定位置的UI区域。这个较低的保存下限是为了让AP能观察分数排序，而非提前用工作阈值删掉大量候选。COCO的小、中、大目标组按原图框面积划分；小于32×32面积才算small，不能把“缩小后看起来很小”直接归进这一组。
除总分外，我们还统计每张图的误报数、不同地图的结果，以及清晰目标和部分遮挡目标的召回。尸体等困难例提供具体反例检查；它们不是穷尽标注，不能据此计算所有尸体的检测召回率。
6. 同一批测试原图上的结果
先用54张验证图固定权重、两个阈值和家族代表，再对75张测试图运行检测。下面AP统一乘以100显示，越高越好；它不是“多少张截图完全正确”的比例。
| 配方 | 验证AP50:95 | 测试AP50:95 | 测试AP50 | 测试AP75 |
|---|---|---|---|---|
| FCOS | 74.66 | 70.67 | 96.53 | 79.81 |
| YOLO nbs64 | 68.80 | 69.32 | 98.47 | 82.71 |
| YOLO nbs8 · 验证选出的YOLO代表 | 69.19 | 70.21 | 98.69 | 85.17 |
| RT-DETRv2 | 52.93 | 52.81 | 82.98 | 57.93 |
FCOS是按验证AP事先选定的整体候选，测试仍保留这一选择。它的测试AP50:95比YOLO nbs8高0.46点，但在AP50和AP75上后者更高；不同重叠要求的结果不会自动给出同一个排序。参考框也可能偏向FCOS的边界习惯，不能把0.46点解释成已证明的架构优势。
按实际使用阈值看漏检和误报
这张表使用各自在验证集上选出的最大F1阈值。TP为匹配成功，FP为没有匹配参考目标的预测，FN为漏掉的参考目标。每行的TP加FN都等于测试集的969个活体框。
| 配方 | 阈值 | TP / FP / FN | 精确率 / 召回率 | F1 | 每图FP |
|---|---|---|---|---|---|
| FCOS | 0.55 | 910 / 44 / 59 | 95.39% / 93.91% | 94.64% | 0.59 |
| YOLO nbs64 | 0.35 | 936 / 49 / 33 | 95.03% / 96.59% | 95.80% | 0.65 |
| YOLO nbs8 | 0.40 | 938 / 33 / 31 | 96.60% / 96.80% | 96.70% | 0.44 |
| RT-DETRv2 | 0.10 | 606 / 109 / 363 | 84.76% / 62.54% | 71.97% | 1.45 |
如果用途是先尽量找出部队，再交给身份或有效性分类器，YOLO nbs8在这批测试中很有价值：找到938个目标，同时保留33个未匹配框。这个工作点仍有误报，不适合把所有输出无条件写入游戏状态。
优先减少误报，要付出多少召回？
下面改用预先固定的“验证精确率至少98%”工作点；没有利用测试结果重新挑阈值。
| 配方 | 阈值 | 验证精确率 / 是否达标 | 测试TP / FP / FN | 测试精确率 / 召回率 |
|---|---|---|---|---|
| FCOS | 0.70 | 98.84% / 是 | 762 / 8 / 207 | 98.96% / 78.64% |
| YOLO nbs64 | 0.45 | 98.54% / 是 | 927 / 30 / 42 | 96.87% / 95.67% |
| YOLO nbs8 | 0.50 | 98.25% / 是 | 928 / 19 / 41 | 97.99% / 95.77% |
| RT-DETRv2 | 0.15 | 85.71% / 未达标 | 13 / 0 / 956 | 100.00% / 1.34% |
RT-DETR这一行不可用作“高精度成功方案”。 它在验证集就没有达到98%目标，阈值升到0.15后几乎不再输出目标。测试精确率100%只来自13个检出，漏掉956个，不是把战场识别完整了。较高AP与某个固定阈值下的低召回也不矛盾：AP查看较完整的分数排序，而此工作点会直接删掉较低分预测。
FCOS把误报从44个降到8个，同时漏检从59个增加到207个。YOLO nbs8保留较高召回，但测试精确率97.99%仍略低于98%。这说明验证目标不能当成新视频的质量保证，也说明“暂时不输出”与“输出一个错对象”的代价需要分别讨论。
遮挡和地图上的差异
测试集包含736个清晰目标和233个部分遮挡目标。下表仍使用各自最大F1阈值，展示匹配数量和召回率。
| 配方 | 清晰目标 | 部分遮挡目标 |
|---|---|---|
| FCOS | 710 / 736 · 96.47% | 200 / 233 · 85.84% |
| YOLO nbs64 | 731 / 736 · 99.32% | 205 / 233 · 87.98% |
| YOLO nbs8 | 725 / 736 · 98.51% | 213 / 233 · 91.42% |
| RT-DETRv2 | 453 / 736 · 61.55% | 153 / 233 · 65.67% |
RT-DETR在这两个子集的顺序反过来，不表示遮挡帮助检测：它们不是同一批目标的有遮挡、无遮挡配对实验，单位种类、地图和站位也不同。
展开六种地图的召回率
| 地图 | 原图 / 活体框 | FCOS | YOLO nbs64 | YOLO nbs8 | RT-DETRv2 |
|---|---|---|---|---|---|
| 洞穴 | 11 / 145 | 97.24% | 98.62% | 99.31% | 67.59% |
| 草地 | 6 / 72 | 94.44% | 94.44% | 94.44% | 72.22% |
| 熔岩 | 11 / 151 | 99.34% | 98.68% | 98.01% | 49.01% |
| 红珊瑚 | 20 / 265 | 92.08% | 98.49% | 97.36% | 55.47% |
| 岩地 | 14 / 155 | 96.77% | 99.35% | 98.71% | 61.94% |
| 雪地 | 13 / 181 | 86.74% | 88.95% | 92.27% | 76.80% |
每组只有6至20张图，且共享两个录屏来源，不能把地图间差异单独归因于地形纹理。COCO small在本测试中没有适用参考框，因此small AP记为不适用，而不是零分；模型缩放后仍可能把这些原生大框压得很小。
原图与四宫格：既看常见画面，也看失败
六个地图例子按固定规则选择：先按来源、再按时间，取该地图第一张测试图；另加三个家族代表预测合计FP+FN最多的一张。下面四宫格的顺序固定为：左上审核参考，右上FCOS，左下YOLO nbs8，右下RT-DETRv2。绿色是匹配框，红色是未匹配预测，黄色是漏掉的参考框。红框可能是边界不够贴合或重复检测，不能直接等同于尸体或背景误报。所有叠加文字使用英文；原始游戏像素保持原样。
红珊瑚：同样是红框，错误原因不同
FCOS找到13个匹配目标，产生2个FP和1个FN：右上目标的预测框与参考边界不够吻合，低于IoU0.5，被同时记作一个未匹配预测和一个漏检；中部还有同一生物的重复框。YOLO漏掉右侧狭小、暗色的生物，其余13个匹配，没有FP。RT-DETR只匹配3个，漏掉11个，另外把两处地形石块框成活体。这些是不同的失败机制，处理方式也不应一概叫“排除尸体”。
雪地：汇总较弱的模型，也有局部更好的帧
这一帧右上有7支部队密集重叠。FCOS与YOLO各为12TP、2FP、2FN；RT-DETR为13TP、2FP、1FN，反而少漏一个。它在全测试集较弱，不意味着每张图都差；选择图片时也必须保留这样的例子。
洞穴：不同单位与背景同时进入检测器
展开草地、熔岩、红珊瑚与岩地的代表帧
另外，对测试来源里单独记录的5个尸体区域，四套配方在各自F1阈值下都没有FP与其达到IoU0.5。但这些区域只来自同一录屏的2张图，还可能重复显示同一尸体。这只是5个已知区域的局部检查，不能写成“没有尸体误检”或“尸体负样本测试通过率100%”。
7. 冷启动和持续运行速度分开测
处理一段视频时，模型通常先加载一次，然后持续处理截图。把每次新进程启动都计入单帧速度会夸大日常开销；只计GPU算子、完全不管缩放和结果还原，又会低估实际等待时间。
本次在同一台Windows机器的RTX5080上，使用PyTorch 2.13.0+cu130、eager、FP32张量、batch1顺序测试各配方，期间GPU没有其他训练任务，PyTorch的CPU线程数固定为4。eager表示直接执行模型，没有先编译为TensorRT引擎。YOLO使用Ultralytics 8.4.144，RT-DETR使用Transformers 5.16.1。训练时用混合精度的YOLO，在这一步也切回FP32。所有配方使用同一后端配置：矩阵乘法关闭TF32，cuDNN卷积允许TF32，因此这里不是承诺所有底层运算都采用严格的FP32精度。公开T4/TensorRT表格不参与本机速度排名。
测速拆成三个问题：
| 读者关心的问题 | 测量包含什么 |
|---|---|
| 启动程序后多久能得到第一个结果？ | 从父进程启动新的Python进程，到收到第一张图结果已生成的通知；含解释器启动、导入、首图解码、加载权重和首次推理 |
| 启动时主要等在哪里？ | 另记模块导入、模型加载及首次推理；不同框架把准备工作放在不同阶段，因此不能单看加载一列判快慢 |
| 模型已驻留后，每张图多快？ | 预热后重复推理，记录中位数和P95；含预处理、数据传输、模型、后处理和CPU结果 |
每套配方启动3个独立的Python进程，权重使用已经下载好的本地文件。这是进程冷启动，不是重启电脑后清空文件缓存的存储冷启动。YOLO会把部分GPU后端准备、模型融合和内部预热推迟到第一次预测；FCOS与RT-DETR在加载阶段已把模型移到GPU。因此，启动至首个结果的总时间比拆开的“模型加载时间”更适合横向比较。
驻留测速使用同一组30张2560×1440的验证原图，按录屏和地图交替选取；每个进程先预热3张，再将30张图重复3遍，得到90次单图延迟。每套配方的3个进程合计270次，把原始耗时合并后计算中位数和P95，而不是平均三个中位数。最终测试图不参与测速采样。这里测的是逐张处理的延迟，不是加大batch后的最高吞吐。
P95表示95%的测量不超过这个延迟，比单个最快值更接近日常偶发变慢的体验。GPU操作常异步执行，因此计时前后都等待GPU完成，不能把“提交了一次计算”当成“结果已经算完”。
上述驻留推理从已经解码的RGB图片开始。原生截图解码另行测量，同时直接计时一轮“从缓存读取并解码截图，再检测”的完整操作；不能简单把两个中位数相加当成这个结果。视频解码、前级场景分类、后级生物身份分类、绘框和网页通信均不包含在内。这意味着本篇报告的是战场检测模块的耗时，完整视频管线还需要加上其他步骤。
模型驻留后：图片解码已经是显著成本
| 配方 | 已解码图片检测，中位数 / P95 | 只解码缓存原图，中位数 / P95 | 解码＋检测，中位数 / P95 |
|---|---|---|---|
| FCOS | 37.83 / 44.70ms | 32.89 / 35.16ms | 72.67 / 79.88ms |
| YOLO nbs64 | 13.37 / 18.85ms | 34.69 / 44.83ms | 51.00 / 68.05ms |
| YOLO nbs8 | 11.85 / 15.29ms | 33.12 / 37.37ms | 46.34 / 56.45ms |
| RT-DETRv2 | 18.08 / 30.50ms | 33.04 / 36.25ms | 52.87 / 64.06ms |
检测列合计270次实测，解码和“解码＋检测”各90次。P95取合并排序后零基索引 floor(0.95×n) 的样本，四套配方使用同一规则。YOLO nbs8检测本身约11.85ms，读取2560×1440 PNG并解码却约33ms；换一个更快网络，不会自动消除图片读取的成本。若后续视频管线能直接复用已解码帧，才更接近第一列的范围。
两个YOLO的结构和推理输入相同，nbs只改变训练方式。这次11.85ms与13.37ms的差别不能归因于“nbs8让网络运算更快”；运行顺序、缓存和系统波动没有被独立控制。它们共同显示的是YOLO配方在本机的较低驻留延迟。
新进程启动：保留一次明显异常
下面完整列出每次进程启动至第一张图返回的时间，以及该次调用中首次预测本身的时间，单位均为秒。
| 配方 | 三次进程启动至首结果 | 对应三次首次预测 |
|---|---|---|
| FCOS | 84.875 / 3.462 / 2.954 | 5.276 / 0.290 / 0.298 |
| YOLO nbs64 | 9.572 / 2.150 / 2.031 | 1.796 / 0.457 / 0.420 |
| YOLO nbs8 | 2.396 / 2.021 / 1.977 | 0.423 / 0.441 / 0.429 |
| RT-DETRv2 | 23.153 / 4.766 / 4.566 | 0.401 / 0.426 / 0.372 |
FCOS首轮84.875秒明显高于随后两次。原始记录中，模块导入占30.918秒，适配器导入与模型加载占48.551秒，首次预测占5.276秒，另有少量解释器、首图解码和通信开销。异常原因尚未隔离，因此保留原数，但不能把84秒当成FCOS日常启动耗时，更不能归因于它的检测架构。 报一个中位数也不能代替对这次异常的说明。
RT-DETR首轮与后两轮同样差异较大。两个YOLO先后运行，共享已有的本地权重和系统文件缓存；nbs8启动更短不能证明训练时改一个nbs参数就能降低加载成本。这里的三次记录描述本次运行环境，尚不能估计长期启动延迟分布。生产部署需要另外复现并定位首次导入与加载的长尾。
8. 依据什么选择下一步模型？
这次比较先固定了一件事：检测器必须只靠完整截图找到场内存活部队，不能依赖事先给好的生物框或名字。619张完整标注画面提供训练与评估基础，其中测试部分来自两段新录屏；36个非活体困难例补充对误报的检查。
本轮在测试前按验证AP50:95固定了FCOS作为整体候选，YOLO nbs8作为YOLO家族代表。测试没有改变这项选择，但补充了用途上的取舍：
- 定位精度与较少误报的候选：FCOS。 测试AP50:95为70.67；在预先选定的较严格工作点，8个FP对应207个FN。适合继续验证“宁可暂时不报，也少报错对象”的路径，但暂时漏掉的目标能否由后续帧恢复，还没有在本文测量。
- 快速、高召回的候选框生成：YOLO26s nbs8。 在F1工作点检出938／969个活体，驻留延迟中位数11.85ms。可继续连接裁图有效性与身份识别，但33个FP说明不能把所有框直接当成可信状态。
- 保留失败配方：RT-DETRv2 R18。 这套640输入、固定学习率的配方召回不足，严格阈值还导致几乎不输出目标。它不适合本轮直接采用；这不等于Transformer检测器在游戏上普遍无效。
把无效区域当成活体，可能污染后续身份和状态；一帧中暂时漏掉模糊目标，则可能等待下一帧恢复。这两种错误代价不同，不能只靠一个F1决定生产策略。需要把检测、裁图有效性、身份和时序放在一起测，同时保留各阶段错误，避免后级“看起来合理”掩盖前级漏检。
下一轮优先补充由独立方式重画的边界参考、密集遮挡和小暗色单位、以及更完整的尸体与地形困难例；再测试分辨率或切片带来的收益。因为已经查看过这75张测试图，针对这些错误做出的新修改必须用新的最终测试来源验证。本轮只用一个随机种子、两个测试录屏，启动长尾也尚未解释，实验模型没有自动替换生产版本。
Comments