这类问题我又碰上了一次。服务跑在容器里，trace 上 LLM 调用那条 span 的耗时是 0ms，用户端看到的却是 9 秒，把前后 span 相加也远不到总时长，跨机调用尤其明显。
第一反应是「用 time.time 记录跨机器时间点，机器间偏差直接进入时长」，验证下来不成立。
这类报错背后常见的原因有几处，逐个排除就行。span 的开始与结束取自不同时钟源，相减得到负数被截成 0；容器与宿主机时间不同步，NTP 漂移到了秒级；流式调用只在首包记了一次结束时间。
第一件事是看两台机器的时间偏差
python -c "import time;print(time.time())"再往下改用单调时钟统计时长
python -c "import time;print(time.monotonic())"校时并确认容器时间来源
chronyc tracking等前面都确认过，再用一次真实请求对照总耗时
curl -s -o /dev/null -w "%{time_total}\n" http://127.0.0.1:8000/v1/models恢复的判定其实很直接。trace 上总时长与 curl 的 time_total 相差小于 5%，各机器时间偏差小于 50ms，span 时长不再出现 0。
这里还有个坑。跨机 span 的时长依赖各机时钟，容器里漂移更常见，记录 duration 用单调时钟比记绝对时间可靠。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。