只报告网络前向耗时，会忽略文档读取、图片解码、后处理和结果保存。用户等待的是整条链路。
本文使用2018 年固定 Darknet 提交、YOLOv3 与独立文档数据划分。继续研究检测模型时，先保证数据定义、预处理和评估口径稳定。文中方法和预期不代表已经获得某个准确率或部署成绩，真实结论必须来自记录完整的实验。
1. 从现象推到机制
阶段计时有助定位成本，但异步设备操作需要正确同步才能测量。模型加载和预热通常与稳定请求不同，应单独记录。端到端延迟还包含排队，不能把各阶段孤立最好值拼成整体结果。
图中的四个节点分别表示请求到达、处理阶段、结果输出、完整报告。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
为每个演示任务记录单调时间，固定图片与输出方式。比较冷启动和预热后请求，保留错误与超时。
1
2
3
4
queue_wait -> decode -> preprocess
model_execution -> postprocess -> save_result
end_to_end = response_completed - request_received
separate cold_start and steady_state samples
每次只改变一组关键因素，保存配置、权重、数据清单与输出。训练、验证和测试职责分离，难例分析保留匿名原始证据，不通过删除失败样本改善表面指标。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 只测模型前向 | 不能代表用户实际等待 |
| 包含首次加载的单次结果 | 需标明冷启动条件 |
| 加速器异步返回 | 需核对同步点再解释耗时 |
对照 1：只测模型前向
不能代表用户实际等待。观察时记录完整请求的端到端时间。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：包含首次加载的单次结果
需标明冷启动条件。观察时记录加载与预热阶段。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：加速器异步返回
需核对同步点再解释耗时。观察时记录实际任务完成而非提交时刻。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
优化优先针对真实主要成本。若排队占大头，继续减少一点预处理时间可能无法明显改善高负载体验。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“加速器异步返回”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
