站点突然变慢或「降智」时，先做这 4 组对照测试

同一句提示词，昨天答得利索，今天又慢又敷衍，很多人的第一反应是「这家站不行了」。但慢和变笨可能是四件事：你到站点的链路、站点到上游的链路、上游当时的状态、以及你自己开了缓存或换了客户端。这篇给一套照着做的对照顺序，每步都告诉你排除了什么、什么情况下不适用，最后给一张记录表，方便你拿着数据去问客服或决定换不换。

同一句提示词，昨天答得利索，今天又慢又敷衍，很多人的第一反应是「这家站不行了」。但慢和变笨可能是四件事：你到站点的链路、站点到上游的链路、上游当时的状态、以及你自己开了缓存或换了客户端。别急着骂客服，也别急着换站，先按顺序做四组对照，每一步都能排除掉一个嫌疑对象。

下面这套顺序不复杂，但有个前提：你得有参照物。从来没在正常状态下留过记录的人，先补一次基线再谈「变慢」。四组测试做完，你手上就有一张能拿去问客服、也能拿去决定要不要换站的记录表。

动手之前：先固定住变量

• 固定输入：把一两条真实任务的原提示词存成文件，别每次现敲，否则对比的不是站点而是你的措辞
• 固定参数：温度、最大输出、是否流式、是否带系统提示都写进记录，任何一项变了结果就不可比
• 先量基线：第一次怀疑变慢时就去 /tools/speed-test 测一轮首字延迟和总时长，之后所有对比都拿它当参照
• 不适用的情况：如果你连一次正常状态下的基线都没留过，先别下「变慢」的结论，你缺的是参照物不是证据

第一组：同题换站，分清是这条链路还是这个模型

1. 准备两份入口当前在用的站点保留，另找一家同级别站点或官方直连作为对照，两边都别改参数
2. 交替跑两轮先A后B再B再A，避免「先跑的那次正好赶上抖动」这种先入为主
3. 记录四件事首字延迟、总时长、是否过中断、回答结构是否完整，四项都写，不要只写快慢

能排除什么：两边都慢，多半怪你自己的网络或客户端；只有一家慢，问题基本落在这家站点的链路或排队上。这里要顺带核对两处：到 /sites 看该站近期有没有公告或状态说明，到 /ai-status 看上游是否整体异常。上游抖动是全网性的，别把它的账记到单家站点头上。

第二组：同站换模型，分清是「降智」还是模型本身

做法很简单：同一个问题，在同一站点里换成另一个明显不同的模型各跑一次，参数保持不变。换模型后恢复正常，说明是某个模型被降级或路由到了别的版本；换了模型还是一样差，才可能是站点整体在限流、压缩上下文或者干脆在偷偷动手脚。

比较的时候看什么要拎清：不同模型的输出长度和风格本来就不同，别比谁写得长，要比「事实是否正确、指令是否遵守」。这一点容易被带偏，很多人以为回答变短就是降智，其实可能只是你换了个本来就话少的模型。

第三组：同站换时段，分清是拥堵还是真变差

这组要排除的是概率事件。低谷正常、高峰明显变差，说明是并发排队，属于容量问题而不是质量下降；全天都差才是真退步。记录时只写「晚上更卡」没用，要写清几点到几点、跑了几次、几次超时几次正常，这样才能和客服对齐口径。

另外别忘了自身因素：公司网络、代理、家宽晚高峰都会一起变。所以第三组必须和第一组交叉印证，单看时段容易把自家网络的问题算到站点头上。

第四组：缓存开关与上下文长度，排掉最容易误判的一项

• 同一提示词分别用全新会话和延续旧会话各跑一次
• 再对比开与不开提示缓存两轮
• 新会话正常、旧会话变慢，通常是上下文太长导致处理时间上升，不是站点变笨
• 顺手查账单口径：缓存计费与你想的不一样时，表现会像「同样的话这次更贵」，去 /tools/token-price-calculator 与站内计费说明核对
• 不适用的情况：有些站点默认强制缓存或强制不开，你控制不了，这时只能把会话长度固定住再比

这一组最容易被忽略，因为很多人默认「我什么都没改」。但延续旧会话本身就是变量，上下文越长，首字延迟越容易上升。先把会话长度固定住，你后面几组的数据才有可比性。

记录模板与下一步动作

判断顺序固定下来：先看换站结果定责任方，再看换模型定是不是被降级，再看时段定是不是拥堵，最后看缓存与会话定是不是自己造成的。这套顺序能避免你在一堆变量里瞎猜。

留证方向：把异常那几次的原始请求与回复导出留存，截图带时间，方便后续申诉；哪些信息能发、哪些不能发，参照站内 key-safety 那篇的原则。什么时候该走：同一时段、同题换站仍然明显异常，且多次复现，就别继续充值试探，直接按止损流程处理。

别拿一次卡顿的体验去换站，先拿四组对照的数据去问客服。