3,080 条银行客服语料，一套测试流程，两个模型。OpenRouter 用 Banking77 做了一轮意图分类对比，Jev 1.13 拿到 81.0%，Claude Opus 5 是 84.4%。差距 3.3 个百分点。可另一组数字是：中位延迟 175 毫秒对 2,266 毫秒，每千次请求 0.11 美元对 2.42 美元。便宜 22 倍、快 13 倍的那一方，只输了 3.3 个点。这道题要是还有标准答案，那才是怪事。
3.3 个点是怎么丢的
这是一道封闭题，不是开放题
Banking77 的形态决定了这场比较的性质。77 个预定义意图，用户抛出一句短问，模型从固定集合里挑一个答案。领域窄，句子短，没有多轮，没有工具调用，也没有模糊到需要世界知识才能拍板的情况。这类任务本来就会把大模型和小模型的差距压缩——意图分类属于确定性强、模式密集的活儿，参数量堆到某个点之后，边际收益衰减得很快。看懂这一点，后面那 3.3 个百分点才不至于显得突兀。3,080 条语料、同一套测试流程，是这组数字唯一可靠的前提。
3.3 个点，是一百多条语料
换个算法。3,080 × 3.3% ≈ 102。一百来条银行客服的问句，Opus 答对了而 Jev 答错了。放在日请求百万级的系统里，这个比例会被放大成三万三千次误判；放在日请求一千的内部工具里，最多是几天碰上一次。同一个百分点，在不同流量下是两种完全不同的东西。脱离业务规模谈准确率差距，等于什么都没谈。
错的到底是哪几类
总分之外还有一层信息：错误在 77 个类目上怎么分布。多出来的那些失误，如果集中在长尾意图上，比如某个冷门的支票业务咨询，业务侧的痛感有限；要是落在挂失、冻结、转账到账时间这种高频且高压的类目上，性质就变了，一次错分可能直接触发投诉。同一张成绩单，两类错误值的钱差得远。选型的人该去问的是这个，而不是盯着 84.4% 这个数字反复看。
175 毫秒和 2,266 毫秒，不是同一类体验
差一个数量级意味着什么
175 毫秒在人类的感知阈值之下。用户按下发送，答案基本跟着出现，中间那段空白不会被注意到。2,266 毫秒是明确的等待——一段能被意识到、能被评价、能让人开始怀疑"是不是没反应"的空白。文本客服里两秒还能忍，语音场景里两秒足够打乱整个对话节奏。轮次一乱，用户开始抢话，系统要么被静音键终结，要么被转人工。中位延迟这个指标还有个残酷之处：它是中位数，意味着有一半的请求比它更慢。
只看中位数会漏掉尾巴
报告给的是中位延迟，这是最宽容的统计口径。真正决定用户会不会骂人的是 p95 和 p99。两个模型如果中位数相差 13 倍，尾部大概率差得更远，只是幅度未知。一个在高峰期把 p99 拉到八秒的分类器，即使中位数再漂亮，也会在每天的流量波峰制造一批投诉工单。上生产之前，把尾延迟单独拉出来看一遍，这个动作比比较平均值有用得多。
22 倍价差，省的是谁的钱
把账单放大到百万次
每千次请求 0.11 美元对 2.42 美元，这个量级放在小规模试跑里看不出差别。放大一百倍：一百万次请求，110 美元对 2,420 美元。再放大到一亿次，1.1 万美元对 24.2 万美元，中间差额二十多万。对一个每天跑几十万次意图识别的团队来说，这不是优化项，这是要不要多招几个人的问题。还得记住这两个价格是在启用提示词缓存的条件下测出来的——缓存命中率一旦掉下去，Opus 那一侧的数字只会往上走。
省下的钱能不能覆盖多出来的错
现在把误判成本塞进同一个算式。一百万次请求，3.3 个百分点的准确率差距换算成三万三千次多余的错分。上一段算出的价差是 2,310 美元。2310 ÷ 33000 ≈ 0.07。只要每次误判的平均处置成本超过七美分——转一次人工、多问一轮、用户点一次"联系客服"，哪个都不止这个数——那 22 倍的便宜就被吃干净了。换句话说，成本优势在多大规模上成立，取决于你的错误有多贵，而不取决于单价有多低。这笔账每个团队都得自己算一遍，别人的结论搬不过来。
级联路由：报告里最该抄走的部分
让便宜的先开口
OpenRouter 演示的基于置信度的级联路由，思路并不复杂：Jev 1.13 先跑，读它的置信度分数。分数高的直接采纳，分数低的那部分请求转给 Opus 重新判断。这样一来，成本曲线和准确率曲线不再是非此即彼的取舍，而是由升级比例这一个旋钮同时控制。假设 Jev 在高置信区间能把准确率稳在九成五以上，绝大多数流量就用 175 毫秒和 0.11 美元的价格处理掉了，剩下的疑难杂症才交给那个 2,266 毫秒、贵 22 倍的模型。
阈值就是你的战略选择
升级阈值往上调，转给 Opus 的比例上升，总成本向 2.42 美元靠拢，准确率也向 84.4% 靠拢；往下调则相反。这里没有放之四海皆准的最优值，只有你这条流量上的最优值。还有一件容易忽略的事：延迟分布会变成双峰。快路径 175 毫秒，慢路径两千毫秒起步。网关的超时预算、前端加载态的呈现方式、语音场景的静音补偿，全都得按慢路径来配，否则级联省下的钱会以另一种形式还回去。
前提是置信度真的可信
这套机制有一个静默失效点。模型报 0.95 的置信度，实际正确率却只有 0.8，那筛出来的"高置信"样本本身就在漏，路由再怎么调也是白搭。上线之前拿一批留出数据画一条可靠性曲线，看分数和实际正确率贴不贴合，这一步没法跳过。校准差的模型不是不能做级联，但你得先知道它偏在哪个方向，再决定阈值往哪边挪。
回到选型本身
什么情况下那 3.3 个点亮红灯
流量大、延迟敏感、单次误判的兜底成本低——搜索框的意图预判、聊天机器人的首轮分诊、语音导航的入口路由，都属于这一类。175 毫秒和 0.11 美元在这里是压倒性的优势，3.3 个百分点的差距用后置规则或者一次人工确认就能补回来。硬上 Opus，多花的钱换不来对等的体验提升。
什么情况下必须认这 3.3 个点
请求量不大，但错一次很贵——面向企业客户的工单自动分派，分错了要跨部门来回扯皮；涉及交易指令、账户状态的判断，错了直接是事故。这种场景里，2,266 毫秒多等一会儿，账单上多几个零，都比不上准确率的价值。低频意味着那 22 倍的价格差在绝对金额上根本不算什么，而一次误判的代价可能顶得上几个月的 API 开销。
