固定 seed 跑六后端：一把 key 上到底有多少输出是可复现的

为什么 seed 可复现性值得关注

在多模型应用里，我们常需要「同一输入、同一参数得到相同输出」，用来做回归测试、效果对比、A/B 实验或调试。很多 API 提供 seed 参数，承诺在给定 seed 下输出尽量确定。但当你通过聚合站一把 key 调用多个后端时，seed 是否被尊重、可复现程度如何，会因后端而异。

本文讨论三件事：

• 不同后端对 seed 语义的处理差异；
• 通过聚合站转发时，哪些环节可能影响可复现性；
• 当只有部分后端可复现时，如何设计可重放的流水线。

各后端对 seed 的处理并不一致

需要先明确一个事实：seed 并不是所有模型都原生支持的参数，即便支持，语义也多是「尽力而为」而非严格保证。常见差异包括：

• 是否接受该参数：有的后端接受并尝试使用；有的直接忽略；有的在未知参数时报错。
• 确定性范围：即使固定 seed，温度、采样策略、batching、硬件差异、模型版本更新都可能让输出漂移。
• 版本绑定：同一模型名在不同时间可能指向不同快照，seed 相同也不保证跨版本一致。

因此，判断「某个后端是否尊重 seed」不能只看文档，需要以实际请求为准。

通过聚合站转发时的额外变量

聚合站把统一格式的请求翻译到各后端，这一层可能引入额外变量：

• 参数映射：seed 可能被透传、被丢弃或被改名，取决于后端适配。
• 默认值注入：聚合站或后端可能补全 temperature、top_p 等参数，影响采样。
• 路由与重试：若同一模型有多个上游，请求可能落到不同实例，输出随之变化。
• 流式与非流式：两种模式在分块与拼接上不同，可能影响你观察到的文本。

所以「可复现」要在你实际使用的调用路径上测，而不是假设官方行为等同转发后行为。

实测思路：用最小实验定位可复现性

不依赖具体数字，可以按以下步骤做一次结构化探测：

1. 固定请求：同一 prompt、同一参数（temperature 固定、max_tokens 固定），显式传入 seed。
2. 重复调用：对同一后端连续请求多次，比较输出是否完全一致。
3. 跨后端对比：对每个后端重复上述步骤，记录「完全一致 / 部分一致 / 不一致」。
4. 变更单变量：分别改变 seed、temperature、是否流式，观察输出变化，判断哪个变量真正起作用。
5. 记录元数据：保存返回中的模型标识、版本信息（若有）、请求时间，便于后续归因。

结论通常不是「支持/不支持」的二元判断，而是每个后端在不同条件下的可复现等级。

当只有部分后端可复现时：可重放流水线设计

现实是多后端混合，可复现性参差不齐。与其追求全局严格复现，不如设计「可重放」的流水线：

1. 记录请求指纹

为每次调用生成指纹，包含：后端/模型标识、完整请求参数、seed、prompt 哈希、聚合站返回的模型元数据。指纹是后续回放与比对的锚点。

2. 分层断言，而非全文相等

对可复现后端，可做严格文本比对；对弱可复现后端，改用结构化断言：

• JSON 输出校验 schema 与关键字段；
• 关键实体/关键词是否出现；
• 分类标签是否落在预期集合；
• 长度、格式等稳定性指标。

这样即使文本有细微差异，流水线仍能判定「行为一致」。

3. 缓存与回放

把首次成功调用（请求+响应）落盘为 fixture。回归时优先回放 fixture，只有 fixture 缺失或显式要求实时调用时才打后端。回放不依赖后端是否可复现，适合稳定测试。

4. 分后端策略

• 可复现后端：固定 seed 做精确回归；
• 弱可复现后端：固定 seed + 多次采样，用统计指标（一致率、字段命中率）判断；
• 不可复现后端：只做契约测试（响应结构、错误码、延迟区间），不做内容比对。

5. 版本与路由锁定

在请求中尽量固定模型标识与版本；若聚合站支持指定上游或路由策略，记录并固定，减少实例漂移。模型升级时，主动更新 fixture 与断言基线。

6. 把可复现性当作监控项

定期对每个后端跑 seed 探测，把「一致率变化」作为告警信号。后端行为或转发层变更时能尽早发现。

小结

固定 seed 在多后端环境下不是「开关」，而是分后端、分条件的可复现等级。通过实测定位每个后端的行为，再用请求指纹、分层断言、fixture 回放和分后端策略搭建流水线，可以在只有部分可复现的情况下，仍然得到稳定、可重放的工程流程。