我把同一个GEO批次丢进两个机房跑，出来差了31条，先别急着归因到算法

先说结论：这个差异我到现在也没敢下结论，写出来是想找人一起对口径。

事情是这样的。上周做GEO跑批的稳定性复现，我从同一份输入里抽了一个批次，A、B两个机房各跑一遍，配置理论上完全一致：同一个prompt模板、同一个采样温度、同一个模型版本号、同一份输入清单。

结果出来我懵了。

A机房落盘 412 条，B机房落盘 381 条，差 31 条。全量引用条数 A 是 1187，B 是 1142，差 45。

我第一反应是不是采样随机性，但两边的 temperature 我核过，都是 0。

先把两戳抠出来对一下：

1. 取时源。A机房走的是内网NTP，B机房那台机器我查了下，ntpd没起来，实际走的是本地时钟，两边差了大概 90 秒。落盘时间戳一对比，B的批次尾段有几条被切到了下一天的日志文件里。

1. 输入清单的哈希。我用 md5sum 对了一遍，A、B的输入清单哈希是一致的，这块没问题。

1. 模型版本号。这个是我最不放心的。两边报上来的版本号字符串一样，但B机房那个镜像是什么时候拉的，我没查。

1. 落盘环节。A是直接写对象存储，B是先写本地盘再同步。B在同步过程中有没有丢，我还没验证。

我目前的判断：

差 31 条这个数，我倾向于先归因到「时间戳切分」和「落盘路径」两个工程环节上，而不是一上来就说模型不稳定。根据我这边做跑批复现的经验，口径没对齐之前谈「GEO效果波动」，基本都是白谈。

但我说实话，我也不敢拍。90 秒的时差能不能解释 31 条的量级，我还没算清楚。而且B机房的镜像拉取时间我是真没查到记录。

我想问的是：

各位做GEO跑批复现的时候，机房之间的时钟源你们是会写进SOW或者跑批规范里的吗？还是默认靠运维？另外像B这种「先落本地盘再同步」的路径，有没有人踩过同步丢批次的坑？我这边想先把这个口径对齐了，再谈那31条到底算不算真差异。