临时 Key 检测怎么做：一次跑完身份、缓存、并发与降级

你拿到一个临时 Key，想在一小时内判断这条渠道值不值得充钱，于是把能跑的测试全跑了一遍，结果身份对不上、缓存没命中、并发一高就报错，反而更迷茫。问题不在测得少，而在没搞清每个检测项各自能证明什么。这篇把四项检测拆开讲，给出一次跑完的顺序、用临时 Key 的注意事项和结果判读表，并说明为什么任何单次结果都不足以定论。

你拿到一个临时 Key，想在一小时内判断这条渠道值不值得充钱，于是把能跑的测试全跑了一遍：身份对不上、缓存没命中、并发一高就报错，测完反而更迷茫。问题往往不在测得少，而在没搞清每个检测项各自能证明什么——身份、缓存、并发、降级这四项，测的根本不是同一件事。

下面把四项拆开：先讲每项能证明和不能证明什么，再给开测前的准备清单、一轮跑完的操作顺序、结果判读表，最后说明为什么任何单次结果都不足以定论。想先对齐价格与模型口径的，可以到站内的模型资料库核对当时的数字。

先分清四项检测各自能证明什么

这四项的说服力并不一样。身份检测直接回答「返回是不是它声称的那个模型」，结论最硬，但也最容易被伪造或误判，靠一两个特征问题根本撑不住结论。缓存检测回答的是计费口径和路由行为，跟模型真伪没有直接关系，别把它当成掉包证据。

身份检测

证明返回与声称的模型是否一致，证据强但要多次交叉验证

缓存检测

证明相同前缀第二次是否走更便宜的计价，反映计费与路由

并发测试

证明这条渠道在你测过的档位下会不会变脸，测不到的档位它不负责

降级观察

证明压力上来后渠道优先牺牲什么，最依赖持续观察

开测前：临时 Key 怎么要、怎么放、怎么留证

1. 要一个可吊销的 Key单独签发、额度受限、随时能作废，别拿正式 Key 来测。测完直接作废，不要留到下次复用，避免它被别的测试污染。
2. 把日志落盘每次请求记录时间、端点、请求参数摘要、响应头里可观测的字段和返回内容指纹。判读时靠的是日志，不是记忆。
3. 别写进配置文件不要把测试 Key 写进客户端配置或提交进代码仓库。泄露风险的处理原则去看 key-safety 那篇，这里不重复。
4. 保证可追溯证据要能说明「同一个 Key 在同一时间段发了哪些请求」，所以时间戳和请求指纹缺一不可，否则对峙时说不清。

开测前还有一件事：想清楚这次测的是「渠道可用性」还是「模型真伪」，两者的测试重点不同。想同时测，就把日志字段分开记，别混在一份记录里，判读时会互相干扰。

身份检测：怎么问才问得出真话

别用网上流传的固定题库，那套东西渠道早就见过。用你自己设计的一组对照问题，包含只有目标模型该答对的、以及目标模型容易暴露习惯的题目，两类混着问，看整体表现而不是单题表现。

• 同一个问题换几种问法各问一遍，看答案是否自相矛盾；单次不一致可能是采样噪声，多次一致地偏移才值得追
• 和官方渠道同题对比时，温度、系统提示、上下文长度都要对齐，否则你测的是参数差异不是渠道差异
• 把「明显错但很自信」和「明显拒绝回答」分开记，前者更像换模型，后者可能只是策略限制
• 什么情况下不适用：模型本身在灰度更新、或渠道明确说明是多模型路由时，身份检测的结论要打折

身份检测最容易被一个误区带偏：拿一个问题答错就断定掉包。采样本身有随机性，一次答错说明不了什么，一串问题稳定地偏向另一个模型的习惯，才算是可追的线索。

缓存检测：命中不命中分别说明什么

构造一段足够长的固定前缀，原样重复发送，比对两次的用量字段差异，看第二次是否走了更便宜的计价。命中了说明这条计费链路支持前缀缓存，不说明它稳定，也不说明你的正式业务能命中。

没命中别急着下结论：可能是前缀太短、渠道没开、也可能两次请求之间被路由到了不同节点。缓存相关的口径与省钱做法，先去看 prompt-caching-cost-guide，这里只做判定，不重复算账。

并发测试：从小到大往上加，看它在哪一档变脸

从单并发开始，逐级往上加，每一档跑够样本量再升，别一步跳到高并发。你要找的是「它在哪一档开始变脸」，而不是「它崩没崩」，所以分档比总并发数更重要。

• 先量出每一档的延迟基线，没有基线就分不清「变慢」是渠道问题还是你自己的网络问题
• 关注三类现象：报错率上升、返回内容变短或变模板化、延迟突然抬升，这三类对应的降级方式不一样
• 报错要记录错误类型和状态码，限流报错和网关报错指向的问题完全不同
• 什么情况下不适用：你线上真实并发远低于测试档位时，高并发下的降级结论对你没有参考价值

测试时最好固定其他变量：同一个端点、同一段提示词、同一台发起机器。变量一多，你测出来的差异就归因不到并发头上，白跑一轮。

降级观察：压力上来之后它先牺牲什么

常见的降级顺序是：先砍返回长度、再换更小的模型、最后直接返回错误。观察它先动哪一项，比看它崩不崩更有信息量，因为这说明渠道在负载下怎么取舍。

1. 持续压而不是打一枪让测试跑一段时间，短时高峰和持续负载下的降级行为可能完全不同，只测几十秒看不出取舍顺序。
2. 记录牺牲顺序把返回长度变化、模型特征漂移、错误出现这三件事按时间排好，看它先动哪一项。
3. 对照渠道自述把观察到的现象和渠道页面自己写的说明对照，能对上的说明它至少说了一部分实话。
4. 限定结论范围这部分的结论只能描述你观察到的时段，不能推广成「这条渠道一直如此」，换时段要重测。

结果判读表：四种组合分别意味着什么

四项检测跑完，不要只看单项好坏，要看组合。下面这张表给的是判断方向，不是绝对结论，具体阈值还是要结合你到站内数据页面核对当时的口径来定。

四种组合里最容易误判的是第二种：缓存不通被当成掉包。缓存反映的是计费口径，和模型真伪是两条线，别把成本问题当诚信问题，也别把诚信问题当成本问题。

• 身份可疑但其余正常：先怀疑路由或模型替换，证据固定下来再沟通
• 身份正常但缓存不通：先查业务侧前缀是不是每次都变，再怀疑渠道
• 多项轻微异常：先怀疑自己的测试环境，换机器换网络复测一次
• 单项异常但不可复现：记录下来，下次复测时重点盯，别当场下结论

为什么一轮跑完还不能定论

渠道会变：上游、路由、限流策略都可能在你测完之后调整，昨天的结论今天未必成立。样本也会骗人：一次成功可能是运气，一次失败可能是抖动，样本量不够时两种误判都会发生。你的业务负载和测试负载不一样，测试里没暴露的问题不代表正式跑起来不会暴露。

要让结论站得住，得靠多时段、多入口的交叉验证。站内的众测雷达就是干这个的，靠多个人的分散观测拼出更稳的判断；个人用户至少也要隔几天复测一轮，把两次结果放在一起看。

另一个常被忽略的点是：你的测试结论只对「你测的那个 Key 那条链路」有效。同一个渠道不同 Key 可能走不同路由，换 Key 之后要把身份这项至少复测一遍，不能直接沿用上一轮结论。