OrcaRouter 路由基础设施：会话感知路由与前沿升级

ORCAROUTER · 路由架构

每个缓存提示词的 LLM 网关都必须将对话固定到单一模型。而每个固定对话的网关都会基于该对话中信息量最低的那一轮做出路由决策。本文报告了这一权衡，以及 OrcaRouter 为摆脱它而推出的分层粘性机制。

主题： OrcaRouter LLM 网关 (Go / Gin / Redis) · 组件： 会话亲和性 + Frontier 升级引擎 · 方法： 对生产决策代码进行 400 次会话重放 · 日期： 2026年8月14日

摘要——请求级LLM路由——即对每个请求独立评分并分派给成本最低的合适模型——是几乎所有已发表的路由研究工作所针对的模式。但对于如今占网关流量主导地位的流量，它同样是错误的模式：多轮智能体会话中，提示词90%是沿用下来的上下文，而服务商的提示词缓存正是为这种连续性提供回报。在对话中途切换模型，会丧失共享前缀上10倍的折扣，因此网关会将会话固定住。然而，第1轮所做的固定，恰恰是在证据最少的一轮做出的，并将持续整个对话周期。

100 / 100 — 潜在困难会话，其第1轮得分与普通会话无法区分

+16%——在相同任务难度下，仅由转录长度导致的难度评分漂移

45% — 始终前沿成本的占比，覆盖其 67% 的急转弯范围

0.019 — 发布门槛与实际得分上限之间的差距

1 两种路由机制

一个位于众多提供商之前的 LLM 网关，每个请求都必须回答一个问题：该由哪个模型来服务？回答这个问题有两种结构上不同的方式，而文献研究与生产现实在哪种方式才是关键这一点上已经渐行渐远。

请求级路由将每个请求视为独立。评分器估计查询难度或预测响应质量，然后将请求分派到预期能处理它的最便宜模型。这基本上是所有已发表路由工作的范式：RouteLLM 训练基于偏好数据的路由器，以 14% 的强模型调用达到 GPT-4 质量的 95%sup>[1]/sup>；FrugalGPT 通过接受/拒绝检查从廉价模型级联到昂贵模型，并报告最高可降低 98% 的成本sup>[2]/sup>；RouterArena 构建了一个包含 8,400 个查询的基准测试，专门在这一维度上比较路由器sup>[3]/sup>。分析的基本单元是查询。

会话感知路由

会话感知路由存在的原因并非优雅，而是算术。

2 使粘性成为必然的缓存经济学

在多轮代理会话中，第 n轮的提示词是第 n−1轮的提示词加上一个增量。到第10轮时，累积的前缀占输入标记的绝大多数。现在，每个主要提供商都根据该前缀是否为缓存命中来对其区别定价：

表1。各提供商的提示缓存语义。缓存以精确前缀和服务键为键——切换模型或轮换密钥即属于全价冷读。

OrcaRouter 将这些生命周期精确编码为固定条目的 TTL：一个按通道类型划分的提供商缓存窗口映射——OpenAI、Anthropic 和 Gemini 为 5 分钟，DeepSeek 为 60 分钟——未映射提供商的默认值为 5 分钟。通道+密钥固定条目随该窗口过期，因为过时的密钥索引没有缓存价值，只会扭曲负载均衡。模型固定条目在基于 Redis 的部署中，且会话 ID 符合长期固定资格时，持续 30 天——并非为了早已消失的缓存价值，而是为了请求格式的连续性。对话中途切换模型会强制进行可能不兼容数据的请求格式转换：思考块和工具调用 ID 在提供商的 schema 之间转换时未必能保留。

被低估的细节

提示缓存的键控按 API 密钥进行，而不是按模型。固定模型但在同一通道上对三个密钥进行负载均衡的网关仍然每三次中有两次发生冷读取。这就是为什么 OrcaRouter 的通道固定存储的是 {ChannelID, KeyIndex} 而不是通道 ID，也是为什么当记录的密钥索引不再解析到已启用的密钥时，该固定会被丢弃——一个被提升但已轮换的密钥会偏向冷缓存，同时绕过负载均衡，这等于同时承受了两种方案的最坏情况。

这些钉选全程都是软性的：无法解析的会话 ID 不会产生任何操作，被钉选的通道若已禁用或不健康，则会降级为普通的均衡选择；在混合池中，钉选到权重为零的通道会被丢弃，因此管理员排空通道时不会被粘性所阻挠。它们永远不会让请求失败。

3 陷阱：粘性会禁用路由器

以下是故障模式。在OrcaRouter的 预升级代码路径中，对于任何非DSL策略上的会话感知路由器，会话→模型引脚返回了

如果第1轮具有代表性，那或许还可以忍受。但事实系统性地并非如此，原因有二，且相互叠加。

3.1 第1轮是信息量最少的一轮

难度标量（service/model_router_difficulty.go）是六个词汇特征的加权线性组合：

LogPromptTokens × 0.20 上限为 log(8001) ≈ 8.99

ReasoningCueCount × 0.15，上限 5

SystemPromptLogLen × 0.10 上限 log(2001) ≈ 7.60

CodeKeywordDensity × 0.20 上限 5.0（每 100 个字符的匹配数）

HasTools × 0.15 已经 0/1

MathMarkerCount × 0.20，上限 5

一个简短且没有历史记录的开场白几乎必然得分较低：权重为0.20的token项已接近其下限，而推理/数学项则会在用户尚无理由使用的词汇上触发。因此，会话在信息最少的时刻就确定了弱池模型——并且由于基于Redis的30天模型固定，这一确定会长期持续。

图 1.按对话轮次计算的最新轮次难度的平均值，基于 100 个潜在困难会话和 200 个真正容易的会话，由生产评分器进行评分。在第 1 轮——即写入 sticky pin 的那一轮——两个群体无法区分（0.210 对比 0.208）。困难群体在第 5 轮越过门槛。在仅使用 pin 的策略下，所有 100 个潜在困难会话都会在出现任何此类证据之前被归入廉价池。

3.2 长度伪装成难度

第二个问题更微妙，它削弱了那个显而易见的修复方案。如果你只是每轮重新运行难度门槛，那你就是在对根据整个拼接的对话记录计算出的分数重新运行它。这个分数存在内在的向上漂移：权重为0.20的LogPromptTokens项随对话长度单调上升，而对于任何智能体会话，权重为0.15的HasTools项和权重为0.10的SystemPromptLogLen项实际上都是恒定下限。一个冗长乏味的会话会显得越来越难。

图2. 长度偏差伪影，基于60个完全由琐碎编辑（“重命名此变量”、“添加nil检查”）组成的会话进行测量。在任务难度恒定的情况下，全文转录分数在25轮中漂移了+16 %；最新一轮（增量）分数持平。如果每轮都天真地重新评估全文转录分数，就会因为会话过长而升级会话。

OrcaRouter 附带的修复是一个单独的增量提取器（service/model_router_delta.go），它仅对最新一轮对话进行评分——即新用户文本加上在最后一条助手消息之后附加的任何工具结果——复用相同的权重和上限，但有意将 SystemPromptLogLen 归零，因为它不属于增量部分。图 2 中平坦的蓝色线条就是该提取器。

4 设计：分层粘性

从第1轮锁定中脱身的天真做法是重新路由每一轮——但这只是请求级路由，并且放弃了缓存。另一个方向的天真修法是让固定标记成为“这个会话变难了”的记忆——这既无法表达降级，也无法加以设限。OrcaRouter的设计拒绝了这两种方案。

重新定义：会话被固定到层级内的一个模型，并且一个小的 Redis 层级状态 是唯一的升级记忆。模型固定永远不是记忆。

层级池。强层级是解析后的升级池（escalation_pool，默认使用路由器的 strong_pool）。基础层级是 AllowedModels \ 强层级池；同时属于两者的模型归入强层级。在基础层级内部，gated_adaptive 的弱/中/强难度分带保持与此前完全相同的运作方式。

按层级限定的固定项。强层级的模型固定键带有 :t:strong 后缀；基础层级保留原有的键不变。因此，升级操作会保留基础固定项，从而使降级后的会话——或在层级状态过期后恢复的会话——回到其最初使用的确切模型，而不是任意重新选择。强固定项仅以较短的 provider-window TTL 写入：30 天的强固定项会比证明其合理性的 4 小时层级状态存活更久。

门控先运行。在 selectByStrategy（service/model_router.go:1374）中，层级会预先解析，候选集被缩小到该层级的资源池，并且仅在这时才会在该层级内查询粘性固定。这是针对§3的结构性修复：难度计算和升级触发条件每轮都会运行，然后粘性固定才能将它们短路。

4.1 三类触发器，按可信度排序

表2。升级触发条件。任何模糊信号都不会单独触发升级；只有客户明确要求时，才会在n=1时提交，即便如此也必须遵守上限。

三个卫生不变量起着支撑作用。违规记录通过环形缓冲区按请求 ID 去重，因此交错的客户端重试不会重复计数。基础设施故障绝不是能力故障 — 429、5xx 和通道回退永远不会被计为违规；只有成功后的质量信号才算数。而且，“回合”（turn）被定义为一次已完成、计费成功的请求，并且该请求执行了违规评估，因此失败的请求既不会推进违规衰减，也不会推进干净回合计数器。

4.2 解析是纯粹的；提交是延迟的

该引擎最关键的结构特性在于，ResolveEscalation 不会写入任何数据。它只返回一个决策以及一系列待处理的意图。分配器在其成功后的处理块中将这些意图应用到一个Redis WATCH 事务内的全新读取之上。这一点至关重要，因为解析器运行在绝不允许变更状态的路径上：推测性回退链解析、只读诊断端点，以及之后会返回 403 或在上游失败的请求。将意图重新应用到全新状态上还意味着，过期的并发写入者无法覆盖已提交的升级，两个竞争的相同升级也会以幂等方式合并。

4.3 大写字母，以及它们为何绑定一切

一次误报升级的代价是 (strong − base) 价格 × 剩余热事件令牌数，而且这种代价是无声无息产生的——不会引发任何失败。爆炸半径受适用于每个类别的上限约束：

escalation_max_per_session（默认值为 1）。降级和客户端重置不会返还该次数，从而封堵了利用重置循环刷次数的路径。

每个路由器的升级份额上限（默认 20%），基于 Redis 日桶的最近 24–48 小时窗口，外加工作区级跨路由器上限。达到上限时，所有升级路由都会被抑制——包括显式请求和一次性提升。

仅在缓存冷边界处进行降级，因此误报被限制在一次热周期内。

A 类遵守上限的原因是威胁模型的结论，而非策略偏好：在 API 网关上，持有工作区令牌的人控制请求头。一条免上限的“客户端要求如此”路径，就是未计量的消费通道。§7 度量的是，当每个客户端都滥用它时会发生什么。

4.4 降级刻意设计为不对称的

基于经证实的证据升级；仅在无代价时降级。一个强会话仅在全部满足以下条件时才返回基线：会话处于缓存冷状态（空闲时间超过升级时记录的提供者窗口），已累积 ≥3 次无违规的评估轮次，且最新的难度增量低于 T1。在暖窗口内，一次切换要付出全价冷重读的代价——反复切换是唯一能保证让升级成本变为负值的方式。

5 方法

我们通过将合成会话语料库经由实际生产决策代码重放来测量该机制。该测试装置是 service 包中的一个 Go 测试，它逐轮针对以 miniredis 为后端的层级存储调用 ResolveEscalation 和 CommitEscalationDecision，并使用了真实的难度评分器、真实的请求侧 strike 生成器和真实的份额上限机制。除了审计事件接收器以外，决策路径上没有其他任何部分被重新实现或模拟。

什么是真实的，什么不是

真实：每一次路由决策、难度评分、打击检测、连续规则、上限评估和 Redis 状态转换——这些就是已上线的功能。合成：流量。语料库是生成的，而非从生产日志中采样。其原型混合（50% 为困难样本）是一种压力混合，用以驱动机制运转，而非对真实流量的估计；§6.4 报告了对这一选择的敏感性，且影响很大。以下干净的精度数字反映的是类别在构造上即可分离的语料库，应将其解读为“机制在预设位置触发”，而非生产精度估计。

5.1 语料库

400 个会话，3,968 轮对话，已设置种子且结果确定。每一轮都是一个完整的 chat-completions 请求体，携带累积的历史记录、一个双工具定义数组，以及一个逼真的系统提示——这正是编码代理实际发送的形式。五种原型，每种都带有真实标签：

表 3.语料库构成。“Needs strong”是用于精确率和覆盖率评分的真值。

困难的回合除了叙述文字之外，还包含粘贴的 goroutine 转储或 3–8 KB 的源代码摘录，因为真正的困难调试回合正是如此。这一细节结果被证明极为重要——参见 §6.2。

5.2 成本模型

成本根据公布的标价计算，并采用按提供商的缓存语义；模型被完整陈述，从而可以对其提出异议。

表4.成本模型参数。价格为每100万token的美元金额，2026年8月价目表。

{{1}}热轮次的成本为 0.1·p_in·prefix + write·p_in·delta；冷轮次的成本为 write·p_in·prompt。{{/1}}{{2}}第 1 轮次始终是一次完整的缓存写入。{{/2}}{{3}}升级策略下的层级切换轮次明确按冷轮次计费，因此该机制为其自身的缓存失效买单。{{/3}}

质量以高难对话覆盖率的形式报告——即强模型实际服务的、真实标签为高难的对话轮次所占比例——而非以准确率数字来衡量。我们没有运行上游推理，因此拒绝编造准确率数字。

6个结果

6.1 机构按设计在预定位置触发

表 5. 按原型划分的升级结果：自动模式、金丝雀 100%、T2 = 0.70（发布默认值）。

在 200 个简单会话上零误报，包括完整转录评分器本会漂移到困难区间的 60 个长会话。触发类特化干净且互不重叠：difficulty 捕获推理密集型工作，strikes 捕获失败循环。注意，failure_loop 的峰值难度分数为 0.262 —— 难度门限根本不会看到这些会话。陷入编译错误循环的代理不会产生推理线索密集的文本；它产生的是同一个短提示，只是堆栈跟踪不同。没有 C 类 strikes，这 60 个会话中的每一个都会在廉价模型上无限期地磨下去。

图3.当会话升级时，按触发因素拆分。由strike驱动的升级高度集中（第4轮，即衰减窗口内可累积两次strike的首个轮次）；由难度驱动的升级则遵循语料库的起始分布，散布在第2至第11轮。连续两轮的规则意味着难度升级最早只能出现在第2轮。

6.2 发现：已交付的门位于悬崖边缘

我们的第一个语料库产生了零次难度驱动的升级。那些高难度回合——充斥着竞态条件、不变量、复杂度分析和证明词汇——峰值达到 0.658，而门槛为 0.70。加入真实调试回合实际携带的粘贴堆栈跟踪后，峰值被推升至 0.719。最终以 0.019 的优势通过了门槛。

图4.难度预算实际用在哪里，基于855个困难轮次和3,113个简单轮次的平均。一个现实的困难轮次达到理论0.90 delta最大值的0.719。CodeKeywordDensity项贡献了其0.20预算中的0.069——实测密度为每100个字符1.72个匹配，而饱和上限为5.0——SystemPromptLogLen的0.10在delta提取器中结构性为零。现实文本无法达到约三分之一的评分名义范围。

阈值扫描证实这是一处悬崖，而非斜坡。在 T2 从 0.35 到 0.65 的整个区间内，结果完全一致——400 个会话中有 200 个升级，零漏报。在已发布的 0.70 阈值下，分类器开始漏掉会话；到 0.75 时，难度驱动的升级从 122 个会话骤降至 23 个。

图 5。阈值敏感性。整个0.35–0.65区间在行为上完全相同，因为没有任何真实的delta文本落入其中——得分分布呈双峰形态，简单轮次聚集在0.23附近，困难轮次聚集在0.72附近，中间没有其他值。出厂默认值位于上峰的顶部边缘。

工程含义

T2 是为full-transcript分布进行校准的，而 gated_adaptive 频带正是基于该分布调优的。它现被重复用作 delta 提取器的阈值。设计文档指出 delta 提取器“需要自己的调优”；此度量量化了差距。要么 delta 门控自身需要一个更低的 T2——0.45–0.60 范围内的任何值都能以真实余量获得相同行为——要么应落地 Phase 3 已规划的基于百分位的阈值（“该路由近期流量的前 X %”），这将使升级速率成为操作员的旋钮，并完全绕开绝对校准。

6.3 成本与覆盖范围

图 6. 同一组 400 个会话上的五种策略。左图：每 1,000 次会话的成本（对数刻度）。右图：由强模型处理的真正困难回合的比例。

表6.策略比较。在表4模型下每1,000次会话的成本。

有两项结果值得区分。首先，在相同模型选择下，仅会话亲和性就能节省 24 %（16.64 → 12.63），在前沿模型对上为 35 %（290.93 → 188.30）。这纯粹是缓存经济学——相同的模型、其他一切相同，只是键的粘性不同。在前沿模型对上节省更大，因为 Anthropic 的 1.25× 写入溢价使得冷轮次格外昂贵。

其次，升级机制落在了救援机制应有的位置：仅需始终使用前沿模型成本的 45%，即可覆盖 67% 的困难轮次，仅在 21.4% 的轮次中调用强模型。

缺失的三分之一覆盖率并非缺陷；这是棘轮的代价。带来零误报的佐证规则，也意味着该机制无法在问题初现时就采取行动：

表 7.升级延迟——棘轮触发前由廉价模型处理的困难请求。

两轮正是连续两轮连胜规则所规定的，而一轮正是两次犯规即升档规则所规定的。这种延迟是设计使然，也正是产生零误报的同一特性。任何想要更快救援的人都可以使用 Class A header，它在 n=1 时生效——这正是手动逃生舱率先发布的原因。

6.4 标题比率完全取决于你的流量

该语料库经构造有 50% 为困难样本。真实的路由器流量并非如此，而成本比较对此极为敏感。在不同的困难会话发生率范围内，对测得的各原型成本进行重新加权：

图 7.每 1,000 次会话的成本是流量中真正需要强模型的比例的函数。类内行为保持为测量值；只有混合比例发生变化。

表8.患病率敏感性，美元/1,000次会话。

按照设计文档自身的升级目标比率（≤5% 的会话），升级成本是廉价池账单的1.6倍，以及前沿账单的12%。在压力混合50%的情况下，其成本是廉价池账单的6.7倍。两者都属实；它们回答的是不同的问题。与运营相关的是前者，这就是为什么份额上限默认为20%而不是“关闭”——实际上限制账单的是上限，而不是触发的精确度。

6.5 这些盖子能承受对抗性滥用

我们使用真实的共享上限机制重新运行了语料库——没有存根，而是使用真实的Redis日桶——在§8威胁模型下：每个客户端在每一轮都发送X-OrcaRouter-Tier: strong。

图 8. 针对 20% 升级份额上限的对抗性标头滥用。前 20 个请求在设计上不受约束——预热下限可防止“2 次升级中的 1 次”被解读为 50% 并在新路由器上锁定该功能——此后份额收敛并保持。最终状态：1,439 个请求中有 296 个获得强升级服务（20.6%），1,143 个明确请求被拒绝并审计为 denied_cap 事件。

剩余的 0.6% 过冲是对近似尾部计数器做严格大于比较时的预期行为，而每会话上限 1 可防止单个会话消耗预算。每次拒绝都会通过 X-Orca-Session-Tier: base; reason=denied:share_cap 响应头对客户端可见，并在审计表中对操作员可见——被抑制的升级永远不会悄无声息。

7 我们会改变什么

赋予 delta 提取器自己的阈值。复用完整转录本的 T2 会留下 0.019 的余量（§6.2）。将 delta 专用的 T2 设为 0.45–0.60，在此语料库上行为完全相同，且余量高出两个数量级。已排期的分位数阈值工作已涵盖此方案，是更好的修复方式。

不要让代码密度这一项仅仅停留在装饰性层面。在我们能构建的最密集的现实文本中，它贡献了其0.20预算中的0.069，因为其每100字符匹配5次的饱和度上限意味着大约每二十个字符就出现一个代码关键字。要么根据实测的生产分布重新设定上限，要么重新分配其权重。

Class C 是智能体流量的主力，但同时也是发展最不完善的。failure_loop 群体对难度门控不可见（峰值 0.262），完全由 strikes 捕获。智能体会话失败是因为陷入循环，而不是因为词汇难度增加。其余的响应侧生产者——以及仍然缺失的原生 Gemini 流式捕获钩子——比进一步调整难度更有价值。

发布升级延迟。在廉价模型上多付出的两轮苦功，是获得佐证棘轮的实打实代价；操作员应在分析面板中紧挨着精确度看到它，而不是自己去发现。

8 限制

该语料库是人工合成的，其构造旨在实现清晰分离，因此零假阳性结果表征的是该机制在可分离输入上的特异性，而非其在生产流量上的精确率。真实的精确率数字只能来自设计所规定的影子模式标注任务——完整触发管线照常运行、不路由任何内容、决策被追溯标注——并以标注精确率≥70%作为上线门槛。

成本模型假设每轮固定输出500个token，这掩盖了一个真实效应：前沿模型会输出更多推理token，因此真正的前沿溢价被低估了。该模型还将请求级缓存热度建模为在键槽位上均匀分布的1/N；加权池则会使用赫芬达尔指数Σw²，而单键通道在通道层完全不会体现会话亲和性的缓存优势——尽管模型层的固定(pin)对自适应策略仍然重要。

我们没有运行上游推理，因此不作出任何准确性或任务成功率的声明。困难回合覆盖率是质量的代理指标，其假设是强模型在这些回合上确实更优——对于所构建的原型而言这看似合理，但在此处未经验证。

最后，这衡量的是单个网关的实现。首轮锁定（turn-1 lock-in）失效模式应当能推广到任何固定会话的缓存感知路由器，但具体数值取决于这些阈值、这些权重和这些价格。

9 相关工作

请求级路由已有充分讨论。FrugalGPTsup>[2]/sup> 引入了LLM级联——先查询廉价模型，对答案进行评分，在置信度低时升级——报告在同等准确率下成本降低高达98%。RouteLLMsup>[1]/sup> 在Chatbot Arena偏好数据上训练路由器，报告以14%的强模型调用达到GPT-4质量的95%，且路由器无需重新训练即可跨模型对迁移。RouterArenasup>[3]/sup> 提供了缺失的评估基础：覆盖各领域和难度级别的8,400个查询，从准确率、成本、路由最优性、鲁棒性和路由器开销等方面进行评分。

这些方法都没有将对话本身视为路由单元。级联策略会升级一个请求，然后将其遗忘；下一轮会在同一个已知困难的任务上重新运行同一个廉价模型。经过偏好训练的路由器评估的是查询，而非轨迹。本报告要解决的关键问题是：路由器应在轮次之间记住什么、记住多久，以及什么情况下应允许其改变决策——这个问题只有在提示缓存使得遗忘代价高昂时才变得紧迫。

OrcaRouter 在其源码树中附带了一个 RouterArena 测试框架（eval/），它针对开放数据集对其五种请求级策略——cheapest、quality、balanced、linucb、gated_adaptive——进行基准测试，而无需修改上游仓库。这里描述的会话级机制与这五种策略正交，并能与它们组合使用。

10 结论

提示缓存改变了 LLM 路由的经济性，而路由相关文献尚未跟上这一变化。一旦连续性意味着你大部分输入 token 都能享受 10 倍折扣，路由器就必须固定（pin）——而它一旦固定，就会在掌握信息最少的那一轮做出决定，并在整个对话期间一直承受这个决定。请求级路由没有这个问题，但代价是缓存未命中；朴素的逐轮重新评估则会在重新引入未命中的同时，额外叠加一个长度偏差伪影。

分层粘性通过将两个看似一体的事物分开来解决它：哪个模型服务本次会话（即固定点，在层内保持稳定）以及本次会话属于哪一层（一个小的、有上限的、经证实的、会过期的状态片段）。在我们的回放中，这种分离恢复了87%的难度在第一轮时无法检测的会话，在200个简单会话上零误报，成本仅为始终使用前沿模型成本的45%——并且对积极试图击败它的客户端保持20%的支出上限。

该机制真正的弱点是校准问题，而非架构问题：一个从未经调优的分布中复用的难度门控，一个无法达到其预算的特征项，以及两轮不可避免的救援延迟。这些都是可以解决的。架构上的主张——升级记忆必须与PIN码分离，任何模糊信号都不得单独触发棘轮，且由于客户端持有令牌，上限必须约束客户端自身的明确请求——才是我们会保留的部分。

11个来源

1. LMSYS Org. RouteLLM：一个用于经济高效LLM路由的开源框架。 a href="https://www.lmsys.org/blog/2024-07-01-routellm/">u>lmsys.org/blog/2024-07-01-routellm//u>/a> · 代码： a href="https://github.com/lm-sys/RouteLLM">u>github.com/lm-sys/RouteLLM/u>/a>

2. Chen, Zaharia & Zou. FrugalGPT：如何在降低成本和提高性能的同时使用大型语言模型。 arXiv:2305.05176. a href="https://arxiv.org/abs/2305.05176">u>arxiv.org/abs/2305.05176/u>/a>

3. Lu, Liu, Yuan, Cui, Zhang, Liu & Xing. RouterArena：一个用于全面比较LLM路由器的开放平台。 arXiv:2510.00202. a href="https://arxiv.org/abs/2510.00202">u>arxiv.org/abs/2510.00202/u>/a>

4. OpenAI。 API 中的提示缓存。 a href="https://openai.com/index/api-prompt-caching/">u>openai.com/index/api-prompt-caching//u>/a> — 自动缓存，≥1,024 个 token 的前缀按 128 个 token 递增，空闲 5–10 分钟逐出，≤1 小时；按模型层级提供缓存输入折扣。定价： a href="https://openai.com/api/pricing/">u>openai.com/api/pricing//u>/a>

5. Anthropic. 提示缓存。 a href="https://platform.claude.com/docs/en/build-with-claude/prompt-caching">u>platform.claude.com/docs/en/build-with-claude/prompt-caching/u>/a> — 缓存读取按基准输入价格的 0.1 倍计费，写入按 1.25 倍（5 分钟 TTL）或 2 倍（1 小时 TTL）计费，使用时刷新。定价：a href="https://www.anthropic.com/pricing">u>anthropic.com/pricing/u>/a>

6. DeepSeek。 DeepSeek API 推出了磁盘上下文缓存。 a href="https://api-docs.deepseek.com/news/news0802/">u>api-docs.deepseek.com/news/news0802//u>/a> — 自动，按实际缓存命中计费，命中时成本降低一个数量级。

7. Google。 Gemini API 上下文缓存。 a href="https://ai.google.dev/gemini-api/docs/caching">u>ai.google.dev/gemini-api/docs/caching/u>/a> — 隐式和显式缓存，TTL 按存储计费。

8. OrcaRouter 源代码，此仓库：service/session_affinity.go（固定项、TTL、层级作用域键）· service/session_escalation.go（引擎）· service/model_router.go:1374（selectByStrategy：在读取固定项之前先进行层级收窄）· service/model_router_difficulty.go（权重与上限）· service/model_router_delta.go（增量提取器）· service/escalation_strikes.go（请求侧生产者）· service/escalation_caps.go（份额上限）· docs/features/frontier-escalation.md（设计，评审轮次 1–4）。

可重现性。测量工具是 service 包中的一个 Go 测试，通过 miniredis 驱动 ResolveEscalation / CommitEscalationDecision，外加一个 Python 分析和图表生成流水线。语料库生成采用种子（rand.NewSource(20260814)），完整运行是确定性的：400 个会话、3,968 轮对话、三个实验（主回放、对抗性上限运行、9 点阈值扫描）。图表使用经 CVD 验证的分类调色板；每个图表都配有其对应的底层数据表。未访问任何生产数据，且本分析的任何部分均未提交到仓库。