生成耗时 5-6 分钟但无法定位:全链路没有阶段计时

[johnnyzhang-eng]

现象

测试环境生成一个动作要 5–6 分钟。慢在哪一步，现在答不出来。

为什么答不出来

全链路一处计时都没有。grep -rn 'time.monotonic\|perf_counter\|elapsed' 在 ai_engine 与 orchestrator/executor.py 下零命中。

进度上报的形状是 step(stage, i, total, note)，只有阶段名与序号，没有耗时。所以：

• 用户看到进度条在动，但不知道卡在哪
• 我们看到任务从 pending 到 completed 花了 5 分钟，但不知道这 5 分钟怎么分配的
• 任何优化改完之后，无法证明它真的变快了

候选耗时点（按怀疑程度排，但都没有数）

阶段	在哪	怀疑理由
i2v 视频生成	strategy/concrete.py 的 _video.i2v	外部模型调用，5 秒视频，大概率是大头
视频下载	provider 内部	视频文件不小，跨境链路
抽帧	slicing/extract_all_frames_bytes	解码全部帧再挑，帧数多时可观
抠图	逐帧调 matte provider	逐帧跑 onnx，32 帧就是 32 次
后处理	postprocess 定标、像素化、打包	纯 CV，逐帧
帧上传	executor 收尾	32 张 PNG 逐个上传对象存储

上面这张表是猜测，不是测量结果。这正是本 issue 要解决的问题——先有数，再谈优化。

建议做法

一、先记账，不优化

在 ProgressPort.step 之外加一条阶段耗时的记录，落进任务结果（与成色读数同一个地方，已有 quality / prompt_version 的先例）。

要点：

1. 用单调时钟（time.monotonic），不用墙钟——墙钟会被 NTP 校正污染。
2. 记录阶段的起止，而不是只记总时长。总时长现在就能从任务的 create_at / update_at 算出来，没有新信息。
3. 逐帧操作要记「次数 + 总耗时」，不是只记总耗时。抠图 32 帧花 60 秒，与抠图 1 帧花 60 秒，是两个完全不同的问题。
4. 外部调用与本地计算分开记。前者受网络与上游影响、我们改不动；后者是我们能优化的。把两者混在一个数里，会把「上游慢」误读成「我们的代码慢」。

二、有数之后再定优化方向

拿到分布之后才能判断值不值得优化。可能的结论是「95% 时间在等 i2v，本地代码优化空间为零」——那样的话该做的是并行度或用户预期管理，而不是抠 CV 代码。

在有数之前不要改任何性能相关的代码：没有基线就无法证明改动有效，只能交「感觉快了」。

验收

• 一次动作生成完成后，能从任务结果里读到各阶段耗时。
• 逐帧类操作能读到「帧数 + 总耗时」。
• 拿同一个角色同一个动作跑三次，各阶段耗时的分布能看出哪一段稳定慢、哪一段抖动大。

备注

三渲二那条路线的第三段（本地渲帧）已经有实测数据：8 朝向 × 8 帧共 64 张，23 秒，零 API 调用。i2v 这条路线缺的正是同等粒度的数。