一次测速为什么不够：怎样建立中转站行为基线

基线描述的是一组条件

行为基线是一段时间内，在监控配置保持不变时，同一调用路径通常返回什么。这里的「同一」至少包括端点、凭据或分组、协议、模型字符串、prompt 版本、请求参数、发起请求的网络区域。少记一项，后面的差异就可能来自测试本身。

例如，昨天用 temperature: 0，今天改成默认值；昨天请求固定版本，今天换成会移动的模型别名。两批输出即使差得很大，也不能归因到中转站。模型版本这一层的区别见模型名称没变，后端行为为什么会漂移。

基线也不等于平均数。TTFT、总耗时和输出 token 数会形成分布；HTTP 状态、stop_reason、缓存字段则更适合统计出现比例。把它们压成一个「正常分」会丢掉排查所需的信息。

固定一份可重放的监控配置

生产流量会随用户输入、上下文长度和工具结果一起变化，适合观察服务影响，不适合直接建立可比基线。另准备一组固定探针，每次原样发送，并给 prompt 和请求体计算版本标识。密钥不能写进记录。

一组实用的探针可以覆盖四类事实：

• 短文本探针固定输入和较小的输出上限，用来观察 HTTP 状态、TTFT、总耗时、输出长度与终止原因。它成本低，适合较高频率运行。
• 固定长度探针保留已知的输入文本，用来比较输入 token 数。相同 tokenizer 和相同请求内容下，这项应当稳定；变化时先查请求是否被改写，再查模型或计费。
• 缓存探针连续发送相同的长前缀，记录缓存写入与读取字段。Anthropic 的提示缓存文档说明缓存按前缀匹配，而且有模型相关的最小长度；测试文本太短会静默不缓存。
• 协议探针构造预期会触发特定 stop_reason、工具调用或错误类型的请求，用来核对响应结构。字段含义应以 Anthropic Messages API或对应厂商的当前文档为准。

探针不必模拟全部业务。它的任务是提供一把长期不变的尺子。业务回归测试负责回答「任务还能不能完成」，固定探针负责回答「调用路径的行为有没有变化」。

采样频率由发现时限和预算决定

想在多长时间内发现变化，决定最长采样间隔。要求半小时内看到持续故障，间隔就不能长于半小时；只关心每日对账，采样可以更稀。还要覆盖业务会经过的时段：只在凌晨采样，无法描述晚高峰。

间歇性分流更麻烦。假设每次请求独立，异常请求占比为 p，连续采样 n 次至少碰到一次的概率是 1-(1-p)^n。异常比例为 10% 时，一次抽检只有 10% 的命中机会；22 次独立采样约有 90% 的机会至少碰到一次。若路由按时间段成批切换，独立假设不成立，样本还要分散到不同时间窗口。

这段计算只帮助安排采样，不能证明某家中转站存在按比例分流。真实请求是否独立、异常比例是多少，事先通常不知道。

建立基线时保留分布和原始样本

首批样本要覆盖日常运行会遇到的时间与负载范围。基线仍在收集时，不急着给「正常」结论。先检查监控配置是否稳定，再分别保存：

中位数能减少少数极慢请求的影响，分位数能把尾部延迟留下来。两者都不能替代原始样本：排查某次 529 或流中断时，需要具体时间、错误体和请求标识。Anthropic 说明每个响应都有 request-id，SSE 还可能在 HTTP 200 之后返回错误事件；细节见其错误文档。OpenAI 也建议记录 x-request-id，并公开了 openai-processing-ms 等排查响应头，见请求调试文档。

留一条官方直连作为对照

只观察中转站，看到变化时仍难判断变化来自上游还是代理。条件允许时，用同一份探针、同一固定模型和同一协议定期请求官方端点，形成独立对照。官方与中转站同期变化，先查厂商发布、公共服务和探针配置；中转站单独变化，再查它的路由、参数透传与响应重组。

官方对照不必和中转站使用相同频率，但要覆盖变化发生的时间附近。两次调用相隔太久，上游状态已经不同，比较价值会下降。对照记录还要注明区域、接口版本和模型 ID，不能用官方固定版本去对比中转站的移动别名。

无法长期承担官方调用成本时，可以在基线建立、告警复核和计划内迁移时运行对照。缺少官方结果不妨碍记录变化，只会缩小归因范围：此时可以陈述中转站偏离自身历史，不能判断偏离是否也发生在官方侧。

变化条件要在看到异常前写好

每个指标没有通用阈值。TTFT 增加多少算异常，取决于任务时限和历史波动；缓存读取从有到无，可能比延迟增加更能说明请求被改写。阈值应同时写明观察窗口、最少样本、持续时间和恢复条件，避免看到一根尖峰后临时改口径。

判定可以分两层：单个请求越界时标为「待复核」，相邻窗口持续偏离或多个独立信号同时变化时再升级。比如 TTFT 变慢而 Usage、终止原因和输出长度稳定，先查网络与排队；输入 token、缓存命中和响应结构同时改变，才值得检查中转站路由或请求改写。

基线更新也要留版本。模型迁移、prompt 改版或监控区域变更后，旧基线不能直接覆盖；记下切换时间，另起一段基线，才能区分计划内变更与未知变化。

给基线标记「收集中」「可比较」「已过期」也很有用。样本尚未覆盖日常时段时处于收集中；监控配置稳定且覆盖预定时段后才进入可比较；模型、prompt、参数或区域改变后立即过期。状态写清楚，界面上的偏离就不会被误读成同条件下的异常。

基线能回答到哪里

行为基线能回答「同一监控配置的近期表现是否偏离过去」，不能单独回答「后端一定是哪一个模型」或「运营方故意掺假」。模型输出有随机性，官方服务的路由与安全组件也可能调整，中转站还可能重写响应字段。

因此，变化发生后要回到原始请求、响应、Usage、网络时间和请求标识，逐项排除。具体读法见如何读懂一条 LinkyMonitor 变化记录；涉及计费时，再用Token 虚标与倍率对账里的官方直连结果做独立参照。