OrcaRouter 라우팅 인프라: 세션 인지 라우팅 및 프론티어 에스컬레이션

ORCAROUTER · 라우팅 아키텍처

프롬프트를 캐시하는 모든 LLM 게이트웨이는 대화를 하나의 모델에 고정해야 한다. 대화를 고정하는 모든 게이트웨이는 해당 대화에서 정보량이 가장 적은 턴을 기준으로 라우팅 결정을 내린다. 이 글은 그러한 트레이드오프와, OrcaRouter가 이를 벗어나기 위해 탑재한 계층적 고정(tiered-stickiness) 메커니즘에 대한 보고서다.

제목: OrcaRouter LLM 게이트웨이 (Go / Gin / Redis) · 구성 요소: 세션 어피니티 + Frontier 에스컬레이션 엔진 · 방법: 프로덕션 결정 코드에 대한 400세션 리플레이 · 날짜: 2026년 8월 14일

초록 — 요청 수준 LLM 라우팅, 즉 각 요청을 독립적으로 평가하고 가장 저렴하면서도 적합한 모델에 배정하는 방식은, 지금까지 발표된 라우터 연구의 거의 전부가 다루는 방식입니다. 그러나 이는 현재 게이트웨이 트래픽을 지배하는 흐름에는 맞지 않는 방식이기도 합니다. 바로 다중 턴 에이전트 세션인데, 이때 프롬프트의 90%는 이월된 컨텍스트이고, 제공자의 프롬프트 캐시가 연속성을 담당합니다. 대화 중간에 모델을 바꾸면 공유된 접두사에 대한 10배 할인을 잃게 되므로, 게이트웨이는 세션을 고정합니다. 하지만 1턴에서 내린 고정 결정은 가장 증거가 부족한 시점의 결정이며, 그 결정은 대화가 끝날 때까지 유지됩니다.

100 / 100 — 턴-1 점수가 사소한 점수와 구별할 수 없는 잠재-하드 세션

+16% — 동일한 작업 난이도에서 전사 길이만으로 인한 난이도 점수 변동

45% — always-frontier 비용의 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는 공급자 스키마 간 변환 시 반드시 유지된다는 보장이 없습니다.

과소평가된 디테일

프롬프트 캐시는 키가 지정되며API 키별로, 모델별이 아닙니다. 모델을 고정하지만 동일한 채널에서 세 개의 키에 걸쳐 부하를 분산하는 게이트웨이는 여전히 세 번 중 두 번은 콜드 리드를 수행합니다. 이것이 OrcaRouter의 채널 핀이 채널 ID 대신 {ChannelID, KeyIndex}를 저장하는 이유이며, 기록된 키 인덱스가 더 이상 활성화된 키와 대응되지 않을 때 핀이 삭제되는 이유이기도 합니다. 부스트되었지만 순환된 키는 부하 분산을 우회하는 동시에 콜드 캐시를 사용하도록 편향되어 최악의 조합이 됩니다.

핀은 유연합니다. 즉, 세션 ID를 확인할 수 없는 경우는 no-op이며, 비활성화되거나 비정상인 핀된 채널은 일반적인 균형 선택으로 폴백되고, 혼합 풀에서 가중치가 0인 채널에 대한 핀은 무시되므로 채널을 드레이닝하는 관리자가 고정(stickiness) 때문에 방해받지 않습니다. 이 핀들은 결코 요청을 실패시키지 않습니다.

3 함정: stickiness가 라우터를 비활성화한다.

실패 모드는 다음과 같습니다. OrcaRouter의 에스컬레이션 전 코드 경로, 비-DSL 전략을 사용하는 세션 인식 라우터의 경우, 세션→모델 핀이 반환한 값은

1턴이 대표적이라면 그것은 견딜 만할 것이다. 그러나 그것은 체계적으로 그렇지 않으며, 그 이유는 두 가지가 복합적으로 작용하기 때문이다.

3.1 턴 1은 가장 정보가 적은 턴입니다.

난이도 스칼라(service/model_router_difficulty.go)는 6가지 어휘 특징에 대한 가중 선형 결합입니다:

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 가중치가 적용된 토큰 항목은 최저치에 가깝고, 추론/수학 용어는 사용자가 아직 사용할 이유가 없었던 어휘에서 발동하기 때문입니다. 따라서 세션은 정보가 가장 부족한 시점에 약한 풀 모델을 고정하게 되며, Redis 기반 30일 모델 핀으로 인해 그 고정은 오래 지속됩니다.

그림 1. 프로덕션 스코어러가 채점한 100개의 잠재적으로 어려운 세션과 200개의 진짜 쉬운 세션에서의 대화 턴별 최신 턴 난이도 평균. 턴 1 — 스티키 핀이 기록되는 턴 — 에서 두 집단은 구별할 수 없다 (0.210 대 0.208). 어려운 집단은 턴 5에서 게이트를 통과한다. 핀 전용 정책에서는 그러한 증거가 존재하기 전에 100개의 잠재적으로 어려운 세션 모두가 저비용 풀에 배정된다.

3.2 길이는 어려움으로 위장한다

두 번째 문제는 더 미묘하며 명백한 해결책을 훼손합니다. 매 턴마다 난이도 게이트를 다시 실행하기만 하면, 당신은 전체 연결 대화록에 대해 계산된 점수로 그 게이트를 다시 실행하는 셈입니다. 그 점수에는 상승 편향이 내장되어 있습니다. 가중치 0.20의 LogPromptTokens 항목은 대화 길이에 따라 단조롭게 증가하며, 모든 에이전트 세션에서 가중치 0.15의 HasTools 항목과 가중치 0.10의 SystemPromptLogLen 항목은 사실상 일정한 하한선입니다. 길고 지루한 세션은 점점 더 어려워 보입니다.

그림 2. 길이 편향 인공물은 사소한 편집(“이 변수 이름 바꾸기”, “nil 검사 추가”)만으로 구성된 60개 세션에서 측정되었습니다. 전체 대화록 점수는 일정한 작업 난이도에서 25턴에 걸쳐 +16%만큼 점진적으로 벗어나는 반면, 최신 턴(델타) 점수는 일정합니다. 매 턴마다 전체 대화록 점수를 단순히 재평가하면 세션이 길다는 이유만으로 에스컬레이션될 것입니다.

OrcaRouter가 제공하는 수정 사항은 별도의 델타 추출기(service/model_router_delta.go)입니다. 이 추출기는 새 사용자 텍스트와 마지막 어시스턴트 메시지 이후에 첨부된 도구 결과를 포함한 최신 턴만 점수화합니다. 동일한 가중치와 상한을 재사용하지만, 델타의 일부가 아닌 SystemPromptLogLen은 의도적으로 0으로 설정합니다. 그림 2의 평평한 파란색 선이 바로 이 추출기입니다.

4 디자인: 계층적 고착성

1턴 고착에서 벗어나는 순진한 탈출구는 모든 턴을 다시 라우팅하는 것인데, 이는 그저 요청 수준 라우팅일 뿐이며 캐시를 포기하게 된다. 반대 방향의 순진한 해결책은 핀을 '이 세션이 어려워졌다'는 기억으로 만드는 것인데, 이는 완화(de-escalation)를 표현할 수 없고 상한을 둘 수도 없다. OrcaRouter의 설계는 둘 다를 거부한다.

재구성: 세션은 티어 내의 모델에 고정되며, 작은 Redis 티어 상태가 유일한 에스컬레이션 메모리입니다. 모델 고정은 결코 메모리가 아닙니다.

티어 풀. 강한 티어는 결정된 에스컬레이션 풀(escalation_pool, 기본값은 라우터의 strong_pool)입니다. 기본 티어는 AllowedModels에서 강한 티어 풀을 뺀 집합이며, 두 곳에 모두 속하는 모델은 강한 티어에 속합니다. 기본 티어 내부에서 gated_adaptive의 약함/중간/강함 난이도 밴딩은 이전과 동일하게 계속 작동합니다.

Tier-scoped pins. The strong tier's model-pin key gets a :t:strong suffix; the base tier keeps the legacy key unchanged. Escalation therefore preserves the base pin, so a de-escalated session — or one resumed after the tier state expires — lands back on the exact model it started on, not an arbitrary re-pick. Strong pins are written with the short provider-window TTL only: a 30-day strong pin would outlive the 4-hour tier state that justified it.

게이트가 먼저 실행됩니다. selectByStrategy(service/model_router.go:1374)에서는 티어가 먼저 결정되고, 후보 집합은 해당 티어의 풀로 좁혀지며, 그리고 오직 그런 다음에 스티키 핀이 참조됩니다 — 해당 티어 내에서. 이것이 §3에 대한 구조적 수정입니다: 난이도 계산과 에스컬레이션 트리거는 핀이 이를 단락시키기 전에 매 턴 실행됩니다.

4.1 신뢰도에 따라 정렬된 세 가지 트리거 클래스

표 2. 에스컬레이션 트리거. 어떤 모호한 신호도 결코 혼자서 상향되지 않습니다; 오직 명시적인 클라이언트 요청만이 n=1에서 커밋되며, 그것조차도 상한선을 따릅니다.

세 가지 위생 불변식이 핵심 기반이다. 스트라이크는 링 버퍼를 통해 요청 ID로 중복 제거되므로, 클라이언트 재시도가 겹쳐도 이중으로 집계되지 않는다.인프라 장애는 결코 역량 장애가 아니다. — 429 응답, 5xx 응답, 채널 폴백은 절대 스트라이크를 발생시키지 않으며, 오직 성공 이후의 품질 신호만 집계된다. 또한 '턴'은 스트라이크 평가를 거쳐 완료되고 과금에 성공한 요청으로 정의되므로, 실패한 요청은 스트라이크 감소도 클린 턴 카운터도 진행시키지 않는다.

4.2 리졸브는 순수하며, 커밋은 지연됩니다.

엔진의 가장 중요한 구조적 속성은 ResolveEscalation이 아무것도 쓰지 않는다는 것입니다. 이는 결정과 보류 중인 인텐트 목록을 반환합니다. 디스트리뷰터는 성공 후 블록에서 그 인텐트를 Redis WATCH 트랜잭션 내부의 새로운 읽기에 적용합니다. 이것이 중요한 이유는 리졸버가 상태를 절대 변경해서는 안 되는 경로, 즉 추측적 폴백 체인 해석, 읽기 전용 진단 엔드포인트, 그리고 이후 403을 반환하거나 업스트림에서 실패하는 요청에서 실행되기 때문입니다. 인텐트를 새로운 상태에 다시 적용한다는 것은 상태가 오래된 동시성 작성자가 커밋된 에스컬레이션을 덮어쓸 수 없고, 경쟁하는 두 개의 동일한 에스컬레이션이 멱등적으로 병합된다는 의미이기도 합니다.

4.3 캡과 모든 것을 바인딩하는 이유

A false-positive escalation costs (strong − base) price × remaining warm-episode tokens, and it costs it silently — nothing fails. The blast radius is bounded by caps that apply to every class:

escalation_max_per_session(기본값 1). De-escalation 및 클라이언트 리셋은 이를 환불하지 않으므로, 리셋 루프를 악용하는 경로가 차단됩니다.

라우터별 에스컬레이션 비율 상한 (기본 20%)은 Redis 일별 버킷의 최근 24–48시간 창을 기준으로 하며, 작업공간 전체의 라우터 간 상한도 포함합니다. 상한에 도달하면 모든 에스컬레이션 라우팅이 억제됩니다 — 명시적 요청과 일회성 부스트를 포함합니다.

캐시-콜드 경계에서만 디에스컬레이션이 이루어지므로, 오탐(false positive)은 하나의 웜 에피소드로 제한됩니다.

Class A가 상한을 준수하는 이유는 정책 선호가 아니라 위협 모델 결론입니다. API 게이트웨이에서는 워크스페이스 토큰을 보유한 사람이 헤더를 제어합니다. 상한이 면제된 "클라이언트가 요청했다"는 경로는 측정되지 않은 지출 채널이 됩니다. §7은 모든 클라이언트가 이를 남용할 때 어떤 일이 발생하는지 측정합니다.

4.4 비난 완화는 설계상 비대칭적이다

확증된 증거가 있으면 에스컬레이션하고, 무료일 때만 디에스컬레이션한다. 강력한 세션은 오직 다음 조건이 모두 충족될 때만 기본 상태로 복귀한다: 세션이 캐시-콜드이고(에스컬레이션 시 기록된 공급자 윈도우를 초과한 유휴 상태), 스트라이크 없는 평가된 턴이 3회 이상 누적되었으며, 최신 델타 난이도가 T1 미만이다. 웜 윈도우 내에서 전환하면 정가의 콜드 재읽기를 지불하게 된다 — 플래핑은 에스컬레이션 비용을 음수로 만드는 유일하게 보장된 방법이다.

5 방법

우리는 합성 세션 코퍼스를 재생함으로써 실제 프로덕션 의사결정 코드를 통해 메커니즘을 측정했습니다. 하네스는 서비스 패키지의 Go 테스트로, miniredis 기반 티어 저장소를 대상으로 턴마다 ResolveEscalation과 CommitEscalationDecision을 호출하며, 실제 난이도 스코어러, 실제 요청 측 스트라이크 생성기, 실제 공유 상한 메커니즘을 함께 사용합니다. 의사결정 경로에 대해서는 감사 이벤트 싱크 외에는 재구현되거나 목킹된 것이 없습니다.

무엇이 진짜이고 무엇이 아닌가

실제: 모든 라우팅 결정, 난이도 점수, 스트라이크 탐지, 연속 기록 규칙, 상한 평가, Redis 상태 전환 — 이것들이 배포된 함수들입니다.합성: 트래픽입니다. 말뭉치는 생성된 것이지 프로덕션 로그에서 샘플링된 것이 아닙니다. 그 아키타입 구성(50%는 어려운 유형)은 메커니즘을 시험하기 위해 선택된 스트레스 테스트용 구성이지 실제 트래픽의 추정치가 아닙니다. §6.4는 그 선택에 대한 민감도를 보고하며, 그 민감도는 큽니다. 아래의 깔끔한 정밀도 수치는 구성상 분리 가능한 클래스를 가진 말뭉치를 반영하며, "메커니즘이 설계된 곳에서 발동한다"는 의미로 읽어야 하지, 프로덕션 정밀도 추정치로 읽어서는 안 됩니다.

5.1 말뭉치

400개 세션, 3,968턴, 시드 고정 및 결정론적 방식. 각 턴은 누적 대화 기록, 2개 도구 정의 배열, 현실적인 시스템 프롬프트를 담은 전체 채팅 완료 요청 본문입니다 — 코딩 에이전트가 실제로 전송하는 형태입니다. 각각 ground-truth 레이블을 가진 5가지 아키타입:

표 3. 말뭉치 구성. "Needs strong"은 정밀도와 커버리지 점수에 사용된 실측값(ground truth)입니다.

어려운 디버깅 전환에는 산문 외에도 3–8KB 분량의 고루틴 덤프나 소스 코드 발췌문이 포함되는데, 이는 실제로 어려운 디버깅 전환에 그러한 내용이 포함되기 때문입니다. 이 세부 사항은 매우 중요하게 작용하는 것으로 드러났습니다 — §6.2를 참조하세요.

5.2 비용 모델

비용은 게시된 정가와 공급자별 캐시 의미론을 기반으로 계산되며, 모델은 전체가 명시되어 있어 이의를 제기할 수 있습니다.

표 4. 비용 모델 파라미터. 가격은 1M 토큰당 $, 2026년 8월 목록 기준.

웜 턴 비용은 0.1·p_in·prefix + write·p_in·delta이고, 콜드 턴 비용은 write·p_in·prompt입니다. 1번 턴은 항상 전체 캐시 쓰기입니다. 에스컬레이션 정책에서 계층 전환 턴은 명시적으로 콜드로 청구되므로, 해당 메커니즘은 자체 캐시 무효화 비용을 스스로 부담합니다.

품질은 하드턴 커버리지 — 강한 모델이 실제로 서비스한 ground-truth 하드 턴의 비율 — 로 보고되며, 정확도 수치로 보고되지는 않습니다. 우리는 업스트림 추론을 실행하지 않았으므로, 정확도 수치를 지어내지 않겠습니다.

결과 6개

6.1 메커니즘은 설계된 곳에서 작동한다.

표 5.아키타입별 에스컬레이션 결과, 자동 모드, 카나리 100%, T2 = 0.70(출시 기본값).

200개의 쉬운 세션에서 오탐이 전혀 없었습니다. 여기에는 전체 대본 스코어러로 평가했다면 하드 밴드로 빠졌을 60개의 긴 세션도 포함됩니다. 트리거 클래스는 겹침 없이 깔끔하게 특화됩니다: difficulty는 추론 중심 작업을 잡아내고, strikes는 실패 루프를 잡아냅니다. 참고로 failure_loop의 최고 난이도 점수는 0.262입니다 — difficulty 게이트는 그런 세션을 전혀 보지 못합니다. 컴파일 오류 루프에 갇힌 에이전트는 추론 신호가 밀집된 산문을 생성하는 것이 아니라, 다른 스택 트레이스가 포함된 동일한 짧은 프롬프트를 생성합니다. Class C 스트라이크가 없다면, 그 60개 세션 각각은 저비용 모델에서 무한정 갈려나갔을 것입니다.

그림 3. 세션이 확대될 때, 트리거별로 구분하십시오. 스트라이크로 인한 확대는 뚜렷하게 집중되어 있습니다(턴 4, 즉 감쇠 창 내에서 스트라이크가 두 번 누적될 수 있는 첫 번째 턴). 난이도로 인한 확대는 말뭉치의 시작 분포에 따라 턴 2~11에 걸쳐 분포합니다. 연속 두 턴 규칙에 따르면 난이도 확대가 가능한 가장 이른 시점은 턴 2입니다.

6.2 발견: 출하된 게이트가 절벽 가장자리에 자리하고 있다

우리의 첫 번째 코퍼스가 생성한 것은 제로 건의 난이도 기반 에스컬레이션이었다. 하드 턴 — 레이스 컨디션, 불변식, 복잡성 분석, 증명 어휘로 가득 찬 — 은 0.70 게이트를 기준으로 0.658에서 정점을 찍었다. 실제 디버깅 턴이 수반하는 붙여 넣은 스택 트레이스를 추가하자 0.719로 상승했다. 게이트는 0.019의 차이로 통과했다.

그림 4. 어려움 예산이 실제로 어디에 사용되는지, 855개의 어려운 턴과 3,113개의 쉬운 턴을 평균한 결과입니다. 현실적인 어려운 턴은 이론상 최대 델타 0.90의 0.719에 도달합니다. CodeKeywordDensity 항목은 0.20 예산 중 0.069를 기여하는데, 측정된 밀도는 포화 상한 5.0 대비 문자 100개당 1.72개이며, SystemPromptLogLen의 0.10은 델타 추출기에서 구조적으로 0입니다. 점수의 명목 범위 중 약 1/3은 현실적인 텍스트로는 도달할 수 없습니다.

임계값 스윕은 이것이 경사가 아니라 절벽임을 확인시켜 줍니다. T2가 0.35에서 0.65 사이일 때 결과는 동일합니다 — 400개 세션 중 200개가 에스컬레이션되며, 누락은 전혀 없습니다. 출시된 0.70에서는 분류기가 세션을 놓치기 시작하고, 0.75에서는 난이도 기반 에스컬레이션이 122개 세션에서 23개로 급감합니다.

그림 5. 임계값 민감도. 0.35–0.65 범위 전체는 행동적으로 동일합니다. 그 범위에는 현실적인 델타 텍스트가 존재하지 않기 때문입니다. 점수 분포는 이중 모드(bimodal)이며, 쉬운 턴은 0.23 부근에, 어려운 턴은 0.72 부근에 모여 있고, 그 사이에는 아무것도 없습니다. 출시 기본값은 상위 모드의 상단 가장자리에 위치합니다.

공학적 함의

T2는 전체 트랜스크립트 분포(gated_adaptive 밴드가 튜닝된 분포)에 대해 보정되었으며, 델타 추출기의 임계값으로 재사용되고 있습니다. 설계 문서는 델타 추출기가 "자체 튜닝이 필요하다"고 지적하며, 이 측정은 그 필요성을 정량화합니다. 델타 게이트에 자체적으로 더 낮은 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 %의 턴에서만 서빙합니다.

커버리지에서 누락된 3분의 1은 결함이 아니라 래칫의 대가입니다. 거짓 양성이 전혀 없도록 하는 확증 규칙은 또한 메커니즘이 문제의 첫 단계에서 작동할 수 없음을 의미합니다:

표 7. 에스컬레이션 지연 시간 — 래칫이 발동하기 전에 저비용 모델에서 처리되는 급격한 방향 전환.

두 턴(turn)은 정확히 2연속 턴 규칙(two-consecutive-turn streak rule)이 명시하는 내용이고, 한 턴은 정확히 2스트라이크-래칫(two-strikes-to-ratchet)이 명시하는 내용입니다. 지연(latency)은 의도된 설계이며, 오탐(false positive)이 전혀 발생하지 않게 한 것과 동일한 속성입니다. 더 빠른 구조를 원한다면 n=1에서 작동하는 Class A 헤더가 있습니다. 이것이 바로 수동 탈출 해치(manual escape hatch)가 먼저 출시된 이유입니다.

6.4 헤드라인 비율은 전적으로 트래픽에 따라 달라집니다.

코퍼스는 구성상 50%가 하드입니다. 실제 라우터 트래픽은 그렇지 않으며, 비용 비교는 이에 매우 민감합니다. 하드 세션 비율의 범위에 걸쳐 측정된 아키타입별 비용을 재가중하면:

그림 7. 강력한 모델이 실제로 필요한 트래픽 비율에 따른 1,000개 세션당 비용. 클래스 내 동작은 측정된 값으로 유지되며, 혼합 비율만 변경됩니다.

표 8. 유병률 민감도, 세션 1,000회당 $.

설계 문서 자체의 목표 에스컬레이션 비율(세션의 ≤5%)에서, 에스컬레이션 비용은 저비용 풀 청구액의 1.6배, 프런티어 청구액의 12%이다. 스트레스 혼합 50%에서는 저비용 풀 청구액의 6.7배가 된다. 두 수치 모두 사실이며, 서로 다른 질문에 답한다. 운영상 관련 있는 것은 전자이며, 이것이 공유 상한이 기본적으로 '꺼짐'이 아닌 20%로 설정되는 이유다. 실제로 비용을 제한하는 것은 상한이지 트리거 정밀도가 아니다.

6.5 캡은 적대적 남용 상황에서도 견딥니다.

우리는 실제 share-cap 메커니즘으로 코퍼스를 재실행했습니다 — 스텁 없이, 실제 Redis day-bucket을 사용 — §8 위협 모델 하에서: 모든 클라이언트가 매 턴마다 X-OrcaRouter-Tier: strong을 전송합니다.

그림 8.20% 상향 비율 상한에 대한 적대적 헤더 남용. 처음 20개 요청은 설계상 제약이 없습니다. 워밍업 최소 기준은 "2건 중 1건 상향"이 50%로 해석되어 새 라우터에서 기능이 잠기는 것을 방지하며, 이후에는 비율이 수렴하여 유지됩니다. 최종 상태: 1,439개 요청 중 296개가 강력(strong) 처리되어 20.6%를 기록했으며, 명시적 요청 1,143개는 거부되어 denied_cap 이벤트로 감사되었습니다.

잔여 0.6% 오버슈트는 근사 후행 카운터에 대한 초과 비교의 의도된 동작이며, 세션당 상한 1은 개별 세션이 예산을 소진하지 못하게 합니다. 모든 거부는 X-Orca-Session-Tier: base; reason=denied:share_cap 응답 헤더를 통해 클라이언트에게, 그리고 감사 테이블을 통해 운영자에게 표시됩니다 — 억제된 에스컬레이션은 결코 조용히 지나가지 않습니다.

7 우리가 바꿀 점

델타 추출기에 자체 임계값을 부여하십시오. 전체 트랜스크립트 T2를 재사용하면 0.019의 여유가 남습니다(§6.2). 0.45–0.60 범위의 델타 전용 T2는 이 코퍼스에서 동작상 동일하며, 두 자릿수 더 큰 여유를 가집니다. 이미 예정된 백분위수 임계값 작업이 이를 포괄하며 더 나은 해결책입니다.

코드 밀도 항목이 장식으로만 남지 않게 하십시오. 이 항목은 우리가 구성할 수 있는 가장 밀도 높은 현실적인 텍스트에서 0.20 예산 중 0.069를 기여하는데, 100자당 5회 일치라는 포화 상한이 대략 20자마다 하나의 코드 키워드가 있음을 의미하기 때문입니다. 측정된 프로덕션 분포를 기준으로 상한을 다시 설정하거나 가중치를 재배분하십시오.

Class C는 에이전트 트래픽의 주력이며, 가장 덜 개발되어 있습니다. failure_loop 집단은 difficulty gate (peak 0.262)에 감지되지 않으며, 전적으로 strikes에 의해 포착됩니다. 에이전트 세션은 루프를 돌며 실패할 뿐, 어휘적 난이도가 높아져서 실패하는 것은 아닙니다. 나머지 응답 측 생성기들 — 그리고 아직 없는 네이티브 Gemini 스트리밍 캡처 훅 — 은 추가적인 난이도 튜닝보다 더 가치가 있습니다.

에스컬레이션 지연 시간을 공개하세요. 저렴한 모델에서 수행되는 두 차례의 힘든 작업은 확증 래칫의 정직한 비용이며, 운영자는 이를 정밀도 옆의 분석 패널에서 볼 수 있어야지, 직접 발견해서는 안 됩니다.

8 제한사항

코퍼스는 합성 데이터입니다. 깔끔하게 분리되도록 구성되었으므로, 제로 오탐(false positive) 결과는 분리 가능한 입력에 대한 메커니즘의 특이성을 나타낼 뿐, 운영 트래픽에 대한 정밀도를 나타내지 않습니다. 실제 정밀도 수치는 설계가 명시하는 섀도우 모드 라벨링 작업에서만 얻을 수 있습니다. 전체 트리거 파이프라인을 가동하되 아무것도 라우팅하지 않고, 결정 사항을 사후적으로 라벨링하는 방식이며, 라벨링 정밀도 ≥70%에서 라이브 전환 게이트를 통과합니다.

비용 모델은 턴당 고정 500개의 출력 토큰을 가정하는데, 이는 실제 효과를 가린다. 프론티어 모델은 더 많은 추론 토큰을 생성하므로 실제 프론티어 프리미엄은 과소평가된다. 또한 요청 수준 캐시 워밍을 키 슬롯 전반에 걸쳐 균일한 1/N로 모델링한다. 가중 풀은 허핀달 지수 Σw²를 사용할 것이며, 단일 키 채널은 채널 계층에서 세션 선호도에 따른 캐시 이점을 전혀 나타내지 않을 것이다. 다만 모델 계층 고정은 적응형 전략에 여전히 중요하다.

우리는 업스트림 추론을 실행하지 않았으므로 정확성이나 작업 성공에 대한 주장은 하지 않습니다. 하드 턴 커버리지는 품질의 대리 지표이며, 강한 모델이 그러한 턴에서 실제로 더 낫다고 가정합니다. 이는 구축된 원형 유형에 대해서는 그럴듯하지만 여기서는 검증되지 않았습니다.

마지막으로, 이는 하나의 게이트웨이 구현을 측정한 것입니다. 턴-1 고착 실패 모드는 세션을 고정하는 캐시 인지 라우터라면 일반화되어야 하지만, 구체적인 수치는 이러한 임계값, 가중치, 가격의 속성입니다.

9 관련 연구

요청 수준 라우팅은 잘 다루어져 왔다. FrugalGPTsup>[2]/sup>는 LLM 캐스케이드를 도입했다 — 저비용 모델에 질의하고, 답변에 점수를 매기며, 신뢰도가 낮으면 상위 모델로 이관하는 방식 — 동일한 정확도에서 최대 98%의 비용 절감을 보고했다. RouteLLMsup>[1]/sup>은 Chatbot Arena 선호도 데이터로 라우터를 훈련시키며, 강력한 모델 호출 14%만으로 GPT-4 품질의 95%를 달성한다고 보고한다. 이 라우터는 재훈련 없이 모델 쌍 간에 전이된다. RouterArenasup>[3]/sup>는 부재했던 평가 기반을 제공한다: 도메인과 난이도에 걸친 8,400개의 쿼리로, 정확도, 비용, 라우팅 최적성, 견고성 및 라우터 오버헤드 기준으로 평가된다.

이들 중 어느 것도 라우팅 단위로서의 대화를 다루지 않습니다. 캐스케이드는 요청을 에스컬레이션하고 잊어버립니다. 다음 턴에서는 이제 어려운 것으로 드러난 동일한 작업에 동일한 저비용 모델을 다시 실행합니다. 선호도 기반 훈련 라우터는 쿼리에 점수를 매기지 궤적에는 점수를 매기지 않습니다. 이 보고서가 다루는 격차는 라우터가 턴 사이에 무엇을 기억해야 하는지, 얼마나 오래 기억해야 하는지, 그리고 무엇이 그 마음을 바꾸도록 허용되어야 하는지입니다 — 프롬프트 캐싱이 잊어버리는 데 드는 비용을 높인 이후에야 시급해지는 질문입니다.

OrcaRouter는 업스트림 저장소를 수정하지 않고 공개 데이터셋에 대해 다섯 가지 요청 수준 전략(cheapest, quality, balanced, linucb, gated_adaptive)을 벤치마킹하는 저장소 내(in-tree) RouterArena 하네스(eval/)를 제공합니다. 여기서 설명하는 세션 수준 메커니즘은 다섯 가지 전략 모두와 직교하며, 모두와 결합(compose)할 수 있습니다.

10 결론

프롬프트 캐싱은 LLM 라우팅의 경제 구조를 바꾸어 놓았지만, 라우팅 문헌은 아직 이를 따라잡지 못하고 있다. 연속성이 대부분의 입력 토큰에 대해 10배 할인을 의미하게 되면, 라우터는 고정(pin)해야 한다. 그리고 고정하는 순간, 라우터는 가장 정보가 부족한 턴에서 결정을 내리고, 그 결정을 대화가 끝날 때까지 유지하게 된다. 요청 수준 라우팅에는 이 문제가 없지만, 캐시 미스라는 대가를 치른다. 순진한 턴별 재평가는 캐시 미스를 다시 도입할 뿐만 아니라 그 위에 길이 편향 아티팩트까지 얹는다.

계층적 고착성은 하나처럼 보이는 두 가지를 분리하여 이를 해결합니다: 이 세션을 서비스하는 모델 (티어 내에서 안정적인 핀) 그리고 이 세션이 속한 티어 (작고, 상한이 있으며, 검증되고, 만료되는 상태 조각). 우리의 재현에서 이러한 분리는 1턴에서 난이도가 감지되지 않는 세션의 87%를 복구하며, 200개의 쉬운 세션에서 오탐이 0건이고, 항상 프론티어 비용의 45% 수준입니다. 또한 이를 적극적으로 무력화하려는 클라이언트를 상대로 20% 지출 상한을 유지합니다.

이 메커니즘의 솔직한 약점은 아키텍처가 아니라 보정(calibration)에 있다: 튜닝되지 않은 분포에서 재사용된 난이도 게이트, 예산에 도달할 수 없는 피처 항목, 그리고 불가피한 복구 지연 두 턴. 그것들은 해결 가능하다. 아키텍처적 주장 — 에스컬레이션 메모리가 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> — 자동 캐싱, 128토큰 단위의 ≥1,024토큰 프리픽스, 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가 디스크 기반 컨텍스트 캐싱(Context Caching on Disk)을 도입했습니다. a href="https://api-docs.deepseek.com/news/news0802/">u>api-docs.deepseek.com/news/news0802//u>/a> — 자동으로 동작하며, 실제 캐시 적중 시에만 비용이 청구되고, 적중 시 비용이 약 10분의 1 수준으로 절감됩니다.

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 분석 및 figure 파이프라인을 포함합니다. 코퍼스 생성은 시드가 지정되어 있으며(rand.NewSource(20260814)), 전체 실행은 결정적입니다: 세션 400개, 턴 3,968개, 세 가지 실험(메인 리플레이, 적대적 상한 실행, 9-포인트 임계값 스윕). 그림은 CVD 검증을 거친 범주형 팔레트를 사용하며, 모든 그림은 그 기반 테이블과 함께 제공됩니다. 프로덕션 데이터에는 접근하지 않았으며, 이 분석의 어떤 부분도 저장소에 커밋되지 않았습니다.