OrcaRouter 路由基礎設施：會話感知路由與前沿升級

ORCAROUTER · 路由架構

每個會快取提示詞的 LLM 閘道，都必須將對話綁定到單一模型；而每個綁定對話的閘道，其路由決策都是基於該對話中資訊量最少的回合。這份報告探討這項取捨，以及 OrcaRouter 為擺脫這項取捨而內建的分層黏著機制。

主旨： OrcaRouter LLM 閘道 (Go / Gin / Redis) · 元件： 工作階段親和性 + Frontier Escalation 引擎 · 方法： 針對生產決策程式碼執行 400 次工作階段重播 · 日期： 2026年8月14日

摘要——請求級 LLM 路由——即獨立評估每個請求，並將其分派給成本最低且足夠的模型——是幾乎所有已發表的路由器研究都在探討的範式。但對於如今主導閘道流量的流量類型，它卻是錯誤的範式：多輪代理會話中，提示詞有 90% 是延續下來的上下文，而提供者的提示詞快取會獎勵這種連續性。在對話中途切換模型，會喪失共享前綴的 10× 折扣，因此閘道會固定會話。然而，在第 1 回合所做的固定，是在證據最少的回合所做的固定，而且會持續到對話結束。

100 / 100 — 潛在困難的會話，其第一回合的分數與簡單會話難以區分

+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>。分析單位是查詢。

Session-aware routing → 會話感知路由

工作階段感知路由存在的理由不是優雅。而是算術。

2 使黏性成為必然的快取經濟學

在一個多輪代理會話中，第 n 輪的提示是第 n−1 輪的提示加上一個增量。到第10輪時，累積下來的前綴佔據了輸入 token 的絕大多數。現在，每個主要提供者都根據是否命中快取來對該前綴收取不同的費用。

表1.各提供者的提示快取語意。快取是以精確的前綴和服務金鑰作為鍵值——切換模型或輪換金鑰都會造成全價冷讀取。

OrcaRouter 將這些生命週期精確編碼為 pin 的 TTL：一個依通道類型區分的提供者快取時間窗對應表——OpenAI、Anthropic 和 Gemini 為 5 分鐘，DeepSeek 為 60 分鐘——未對應提供者的預設值為 5 分鐘。channel+key 的 pin 會隨該時間窗到期，因為過期的金鑰索引沒有快取價值，只會扭曲負載平衡。該模型 pin，在 Redis 後端的部署中，若 session id 具備長期 pin 資格，則持續 30 天——並非為了早已消失的快取價值，而是為了請求格式的連續性。對話中途切換模型會強制進行請求格式轉換，而這種轉換可能造成資料不相容：思考區塊與工具呼叫 ID 不一定能在提供者 schema 之間的轉換中完好保留。

被低估的細節

提示詞快取是以API 金鑰作為鍵值，而非以模型作為鍵值。一個固定模型、但在同一通道上於三把金鑰之間進行負載平衡的閘道，每三個回合仍會有兩個回合是冷讀取。這就是為什麼 OrcaRouter 的通道釘選儲存的是 {ChannelID, KeyIndex} 而非通道 ID，也是為什麼當記錄的金鑰索引不再對應到任何已啟用的金鑰時，釘選會被丟棄——一把被提升但已遭輪替的金鑰會使流量偏向冷快取，同時又繞過了負載平衡，可謂兩全其弊。

釘選是軟性的，全程皆然：無法解析的工作階段 ID 為無操作；停用或不健康的釘選頻道會降級為正常的平衡選擇；在混合池中，對權重為零頻道的釘選會被丟棄，使正在排空頻道的管理員不會被黏著性所阻礙。它們絕不會讓請求失敗。

3 陷阱：黏性使路由器失效

以下是失敗模式。在 OrcaRouter 的升級前程式碼路徑中，對於任何非 DSL 策略上的工作階段感知路由器，session→model 綁定回傳了

倘若第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 輪（寫入固定釘子的那一輪），兩個群體無法區分（0.210 對 0.208）。困難群體在第 5 輪跨越門檻。在僅使用釘子的策略下，所有 100 個潛在困難會話都會在該證據出現之前被提交至廉價池。

3.2 長度偽裝成難度

第二個問題更加微妙，而且它會削弱這個顯而易見的修正方式。如果你只是每一輪都重新執行難度門檻，你等於是在對一個基於完整串接的對話紀錄所計算出的分數重新執行該門檻。該分數具有內建的向上漂移傾向：權重0.20的LogPromptTokens項會隨對話長度單調遞增，而對任何代理工作階段而言，權重0.15的HasTools與權重0.10的SystemPromptLogLen項實際上都是恆定下限。一個又長又無聊的工作階段看起來會越來越困難。

圖 2。長度偏誤（length-bias）假象，測量自 60 個完全由瑣碎編輯（「重新命名此變數」、「新增 nil 檢查」）組成的會話。在任務難度恆定的情況下，完整逐字稿分數在 25 個回合中漂移了 +16%；最新回合（delta）分數則持平。若每回合都天真地重新評估完整逐字稿分數，就會因為「對話太長」這個罪名而升級會話。

OrcaRouter 提供的修正是一個獨立的 delta萃取器（service/model_router_delta.go），它只對最新的對話回合進行評分——即新的使用者文字加上最後一條助理訊息之後附加的任何工具結果——重複使用相同的權重和上限，但刻意將 SystemPromptLogLen 歸零，因為它不屬於 delta 的一部分。圖 2 的平坦藍色線條就是該萃取器。

4 設計：分層黏著度

從第一輪鎖定的困境中脫逃的簡單做法，是每一輪都重新路由——這只是請求級路由，卻喪失了快取。另一個方向的簡單修法，是讓 pin 記住「這個 session 變難了」——這無法表達降級，也無法設定上限。OrcaRouter 的設計拒絕這兩者。

重新架構：工作階段被釘選在某一層級內的模型上，而一個小巧的 Redis 層級狀態是唯一的升級記憶。模型釘選本身永遠不是記憶。

分層池。 強層級為已解析的升級池（escalation_pool，預設為路由器的 strong_pool）。基礎層級為 AllowedModels \ 強層級池；同時屬於兩者的模型歸入強層級。在基礎層級內部，gated_adaptive 的 weak/mid/strong 難度分級機制仍與先前完全相同地運作。

層級範圍的釘選。強層級的模型釘選鍵會加上 :t:strong 後綴；基礎層級則保持舊版鍵不變。因此，升級會保留基礎釘選，所以已降級的工作階段——或在層級狀態過期後恢復的工作階段——會回到它最初開始的確切模型，而非任意的重新挑選。強釘選僅以短暫的提供者視窗 TTL 寫入：一個 30 天的強釘選會比使其合理的 4 小時層級狀態更長壽。

閘門首先執行。在 selectByStrategy（service/model_router.go:1374）中，層級會預先解析，候選集合會縮小到該層級的池，而且只有在那時才會查詢黏性 pin——在該層級內。這就是 §3 的結構性修復：難度計算與升級觸發每回合都會執行，在 pin 可以使其短路之前。

4.1 三種觸發類別，按可信度排序

表2。 升級觸發條件。模糊訊號絕不會獨自升級；只有明確的客戶請求才會在 n=1 時觸發，而且即使如此也須遵守上限。

三項衛生不變量承載著系統的關鍵運作。Strike 透過環形緩衝區按 request id 去重，因此交錯的客戶端重試不會重複計數。基礎設施故障永遠不是能力故障 — 429、5xx 與通道回退永遠不會觸發 strike；只有成功後的品質訊號才算數。而「turn」被定義為一個已完成、計費成功且執行過 strike 評估的請求，因此失敗的請求既不會推進 strike 衰減，也不會推進 clean-turn 計數器。

4.2 解析是純粹的；提交是延遲的

此引擎最具深遠影響的結構特性在於 ResolveEscalation 不會寫入任何資料。它會回傳一個決策，以及一組待處理的意圖。分發器會在成功後的區塊中，將那些意圖套用至Redis WATCH 交易內的全新讀取。這之所以重要，是因為解析器運行在絕不容許變更狀態的路徑上：推測性的備援鏈解析、唯讀的診斷端點，以及後來可能回傳 403 或在上游失敗的要求。將意圖重新套用至全新狀態，也意味著過時的並行寫入者無法覆寫已提交的升級，而兩個互相競爭的相同升級會以冪等方式合併。

4.3 大寫字母，以及為何它們綁定一切

一次誤報升級的成本是 (strong − base) 價格 × 剩餘的 warm-episode 代幣，而且這種成本是無聲的——不會有任何失敗。爆炸半徑受到上限所約束，該上限適用於 所有類別：

escalation_max_per_session（預設為 1）。降級（de-escalation）與用戶端重設皆不會退還此額度，因此封閉了利用重設迴圈鑽漏洞的途徑。

一個每路由器的升級份額上限（預設 20 %）在 Redis 日桶的過去 24–48 小時時間窗內，再加上一個工作區範圍的跨路由器上限。達到上限時，所有升級路由都會被抑制——包括明確要求與一次性提升。

僅在快取冷邊界進行降級，因此誤報被限制在單一熱事件內。

「Class A 之所以遵守上限，是威脅模型得出的結論，而非政策偏好：在 API 閘道上，持有工作區 Token 的人即掌控了標頭。一條豁免上限、以「客戶要求」為由的路徑，就是未計量的支出管道。§7 量化了當每個客戶都濫用它時會發生什麼。」

4.4 降級刻意設計為不對稱的

根據確鑿證據升級；只有在免費時才降級。一個強勢的 session 返回基線，僅當全部以下條件成立時：session 為 cache-cold（閒置時間超過升級時記錄的 provider window）、已累積 ≥3 個無 strike 的已評估回合，且最新 delta 難度低於 T1。在 warm window 內，切換需要付出全價的 cold 重新讀取——flapping 是唯一保證讓升級變成負成本的方式。

5 方法

我們透過重放合成會話語料庫來測量該機制，將之送入實際生產決策程式碼。測試平台是服務套件中的一個 Go 測試，它針對以 miniredis 為後端的等級儲存，在每一輪中呼叫 ResolveEscalation 和 CommitEscalationDecision，並使用真實的難度評分器、真實的請求端 strike 產生器，以及真實的 share-cap 機制。除了稽核事件接收器之外，決策路徑中沒有任何部分被重新實作或模擬。

什麼是真實的，什麼不是

真實：每個路由決策、難度分數、打擊偵測、連勝規則、上限評估與 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月牌價。

一個熱回合的成本為 0.1·p_in·prefix + write·p_in·delta；一個冷回合的成本為 write·p_in·prompt。第 1 回合永遠是完整的快取寫入。在升級策略下，層級切換的回合被明確地以冷回合計費，因此該機制會自行支付其快取失效的成本。

品質的報告方式為困難轉彎覆蓋率——即強模型實際處理的 ground truth 困難轉彎所佔比例——而非以準確度數字呈現。我們並未執行上游推論，因此不會編造準確度數字。

6 個結果

6.1 機制在其設計之處觸發

表 5. 依原型分類的升級結果，自動模式，canary 100%，T2 = 0.70（出廠預設）。

200個簡單會話零誤報，其中包括完整轉錄本評分器原本會漂移到困難區間的那60個長會話。觸發類別分工明確且互不重疊：difficulty捕捉推理密集型任務，strikes捕捉失敗循環。請注意，failure_loop的峰值難度評分為0.262 — difficulty門檻根本不會看到這些會話。陷入編譯錯誤循環的代理並不會產生富含推理線索的文字；它產生的是帶有不同堆疊追蹤的相同短提示。如果沒有Class C strikes，這60個會話中的每一個都會在廉價模型上無限期地耗下去。

圖3。當會話升級時，依觸發因素拆分。由攻擊驅動的升級急劇集中（第4回合，這是衰減窗口內可能累積兩次攻擊的第一個回合）；由難度驅動的升級則依循語料庫的起始分佈，分散於第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範圍在行為上完全相同，因為沒有實際的差異文本落在其中——分數分佈是雙峰的，容易的輪次集中於0.23附近，困難的輪次集中於0.72附近，中間沒有其他值。出廠預設值位於上峰的上邊緣。

工程含義

T2 是針對 完整轉錄分佈（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× 寫入溢價使得冷回合（cold turns）不成比例地昂貴。

第二，升級落在救援機制應在之處：以始終前沿成本的45%覆蓋其67%的困難回合，僅在21.4%的回合中服務於強模型。

缺失的第三部分覆蓋並非缺陷；那是棘輪的代價。那些產生零誤報的佐證規則，也意味著機制無法在問題的第一回合就採取行動：

表7. 升級延遲—棘輪觸發前由廉價模型處理的困難請求。

「兩回合正是『連續兩回合連勝規則』所規定的，而一回合正是『兩次違規即觸發棘輪』所規定的。延遲本身就是設計，而正是這個屬性造就了零誤報。任何想要更快救援的人都有 Class A 標頭，它在 n=1 時觸發——這正是手動逃生艙率先出貨的原因。」

6.4 標題比例完全取決於你的流量

該語料庫因建構方式而有 50% 屬於困難案例。實際路由器流量並非如此，而成本比較對此極為敏感。在一系列困難工作階段盛行率下，重新加權衡量各原型類別的成本：

圖 7。每 1,000 次工作階段的成本，隨真正需要強大模型的流量比例而變化。類別內的行為保持在測量值；只有混合比例改變。

表8. 盛行率敏感度，每1,000次工作階段之美元。

在設計文件自身設定的目標升級率（≤5% 的工作階段）下，升級成本為廉價池帳單的 1.6 倍，以及邊疆帳單的 12%。在壓力混合 50% 的情況下，成本為廉價池帳單的 6.7 倍。兩種說法都正確；它們回答的是不同問題。與營運相關的是前者，而這正是為什麼份額上限預設為 20% 而非「關閉」——真正限制帳單的是上限，而非觸發精確度。

6.5 蓋體在惡意濫用下仍能保持完好

我們在 §8 威脅模型下重新執行了語料庫，使用真實的共享上限機制——沒有 stub、真實的 Redis 按日分桶——每個客戶端在每一輪都會發送 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 次匹配，意味著大約每二十個字元就會出現一個程式碼關鍵字。要麼根據量測到的生產環境分佈重新設定其上限，要麼重新分配其權重。

C 類是代理程式流量的主力，也是開發最少的一類。 failure_loop 族群對難度門檻而言是不可見的（峰值 0.262），完全由 strikes 捕捉。代理程式工作階段因迴圈而失敗，而非因詞彙難度提高而失敗。其餘的回應端產生器——以及仍然缺失的原生 Gemini 串流捕獲鉤子——比進一步調整難度更有價值。

發布升級延遲。在廉價模型上跑兩輪苦工，是這道相互印證棘輪機制的誠實代價；操作人員應該在分析面板中、緊鄰精確度的地方看到它，而不是自己去挖掘。

8 限制

該語料庫是人工合成的。其構建旨在清晰分離，因此零誤報結果體現的是該機制在可分離輸入上的特異性，而非在生產流量上的精確度。真正的精確度數據只能來自設計所指定的影子模式標註任務——完整運行觸發管道、不路由任何內容、對決策進行回溯性標註——並以標註精確度≥70%作為上線門檻。

成本模型假設{{1}}每次回合固定輸出 500 個 token{{/1}}，這掩蓋了一個真實效應：{{2}}前沿模型會產生更多推理 token，因此真正的前沿模型溢價被低估了{{/2}}。它還將{{3}}請求層級的快取熱度建模為均勻分佈於 key 槽位上的 1/N{{/3}}；{{4}}加權池則會使用赫芬達爾指數 Σw²，而在通道層面上，單一 key 通道根本不會為工作階段親和性展現任何快取優勢——儘管模型層的固定對自適應策略仍然重要{{/4}}。

我們沒有執行上游推論，因此不對準確性或任務成功率作出任何宣稱。困難回合覆蓋率是品質的代理指標，它假設較強的模型在那些回合中確實表現較佳——對於所構建的原型而言這是合理的，但在此未經驗證。

最後，這衡量的是單一閘道的實作方式。turn-1 鎖定失敗模式應該可以推廣到任何具有快取感知且固定工作階段的路由器，但具體數值則取決於這些閾值、這些權重和這些價格。

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× 折扣，路由器就必須釘住——而在釘住的那一刻，它是在自己資訊最少的回合做出決定，並在整段對話的剩餘時間裡與這個決定共存。請求層級路由沒有這個問題，卻要付出快取未命中的代價；樸素的逐輪重新評估則會重新引入未命中，並額外疊加一個長度偏差偽影。

分層黏著性透過將兩個看似同一件事的事物分開來解決這個問題：此工作階段由哪個模型提供服務（釘選，在層級內穩定）以及此工作階段屬於哪個層級（一個小型、有上限、經彼此驗證、會過期的狀態片段）。在我們的重播中，這種分離收復了 87% 在回合 1 無法察覺其困難度的工作階段，在 200 個簡單工作階段上零誤判，成本僅為 always-frontier 的 45%——而且仍能對主動試圖攻破它的客戶端維持 20% 的花費上限。

「該機制的真實弱點在於校準，而非架構：一個難度門檻重用了並非為其調校的分佈，一個特徵項無法達到其預算，以及兩輪不可避免的救援延遲。這些都是可處理的。而架構上的主張——升級記憶必須與PIN碼分離，任何模糊訊號不得單獨遞增，且上限必須約束客戶端自身的明確請求，因為客戶端持有權杖——才是我們會保留的部分。」

11 個來源

1. LMSYS 組織 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> 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 進行隱含與明確快取。

{{1}}8. OrcaRouter 原始碼，此儲存庫：{{/1}} {{2}}service/session_affinity.go（釘選、TTL、分層範圍的鍵）{{/2}} · {{3}}service/session_escalation.go（引擎）{{/3}} · {{4}}service/model_router.go:1374（selectByStrategy：在釘選讀取之前先進行分層縮減）{{/4}} · {{5}}service/model_router_difficulty.go（權重與上限）{{/5}} · {{6}}service/model_router_delta.go（delta 萃取器）{{/6}} · {{7}}service/escalation_strikes.go（請求端生產者）{{/7}} · {{8}}service/escalation_caps.go（份額上限）{{/8}} · {{9}}docs/features/frontier-escalation.md（設計、審查輪次 1–4）。{{/9}}

可重現性。量測框架是 service 套件中的一個 Go 測試，以 miniredis 驅動 ResolveEscalation / CommitEscalationDecision，外加一個 Python 分析與圖表管線。語料庫產生已設定種子（rand.NewSource(20260814)），完整執行具有確定性：400 個會話、3,968 輪、三個實驗（主要重播、對抗性上限執行、9 點閾值掃描）。圖表使用經 CVD 驗證的類別色盤；每張圖表都與其底層資料表配對。未存取任何生產資料，且此分析的任何部分均未提交至儲存庫。