Infraestrutura de Roteamento OrcaRouter: Roteamento Sensível à Sessão e Escalonamento de Fronteira

ORCAROUTER · ARQUITETURA DE ROTEAMENTO

Todo gateway de LLM que armazena prompts em cache deve fixar uma conversa a um único modelo. Todo gateway que fixa uma conversa toma sua decisão de roteamento com base no turno menos informativo dessa conversa. Este é um relatório sobre essa compensação e sobre o mecanismo de aderência em camadas que o OrcaRouter oferece para escapar dela.

Assunto: Gateway LLM OrcaRouter (Go / Gin / Redis) · Componente: afinidade de sessão + mecanismo Frontier Escalation · Método: replay de 400 sessões contra o código de decisão de produção · Data: 14 de agosto de 2026

RESUMO — O roteamento de LLM em nível de solicitação — avaliar cada solicitação de forma independente e encaminhá-la ao modelo adequado mais barato — é o regime que quase todos os trabalhos publicados sobre roteadores abordam. É também o regime errado para o tráfego que agora domina o volume dos gateways: sessões de agente multiturno, em que o prompt é 90 % de contexto herdado e o cache de prompt do provedor paga pela continuidade. Trocar de modelo no meio da conversa elimina um desconto de 10× no prefixo compartilhado, então os gateways fixam as sessões. Mas uma fixação feita no turno 1 é uma fixação feita no turno com menos evidências, e ela persiste por toda a vida da conversa.

100 / 100 — sessões latente-difíceis cuja pontuação no turno 1 é indistinguível de uma trivial

+16% — deriva da pontuação de dificuldade apenas pelo comprimento da transcrição, com dificuldade de tarefa idêntica

45% — do custo de fronteira permanente, para 67% de sua cobertura de curva fechada

0,019 — margem entre o gate lançado e o teto das pontuações realistas

1 Dois regimes de roteamento

Um gateway de LLM que fica à frente de muitos provedores precisa responder a uma pergunta por requisição: qual modelo atende a isso? Há duas maneiras estruturalmente diferentes de responder a isso, e a literatura e a realidade de produção se distanciaram quanto a qual delas importa.

Roteamento em nível de requisição trata cada requisição como independente. Um avaliador estima a dificuldade da consulta ou a qualidade prevista da resposta, e a requisição é encaminhada ao modelo mais barato que se espera conseguir processá-la. Este é o regime de essencialmente todos os trabalhos publicados sobre roteamento: RouteLLM treina roteadores baseados em dados de preferência que atingem 95 % da qualidade do GPT-4 com 14 % de chamadas a modelos fortessup>[1]/sup>; FrugalGPT executa uma cascata do mais barato ao mais caro com uma verificação de aceitação/rejeição e relata uma redução de custo de até 98 %sup>[2]/sup>; RouterArena constrói um benchmark de 8.400 consultas para comparar roteadores exatamente nesse eixosup>[3]/sup>. A unidade de análise é a consulta.

Roteamento ciente de sessão

A razão pela qual o roteamento com reconhecimento de sessão existe não é elegância. É aritmética.

2 A economia do cache que torna a aderência obrigatória

Em uma sessão de agente com múltiplos turnos, o turno n tem o prompt do turno n−1 mais um delta. No turno 10, o prefixo acumulado é a esmagadora maioria dos tokens de entrada. Todos os principais provedores agora precificam esse prefixo de forma diferente dependendo se é um cache hit:

Tabela 1.Semântica de cache de prompt por provedor. O cache é baseado em um prefixo exato e na chave de serviço — uma troca de modelo ou uma rotação de chave é uma leitura fria a preço integral.

O OrcaRouter codifica exatamente esses tempos de vida como TTLs de pin: um mapa por tipo de canal das janelas de cache de provedores — 5 minutos para OpenAI, Anthropic e Gemini, 60 minutos para DeepSeek — com um padrão de 5 minutos para provedor não mapeado. O pin de canal+chave expira com essa janela, porque um índice de chave obsoleto não tem valor de cache e apenas distorce o balanceamento de carga. O pin de modelo, em uma implantação com backend Redis e para um ID de sessão elegível a pin longo, persiste por 30 dias — não por valor de cache, que já se foi, mas pela continuidade do formato de requisição. Uma troca de modelo no meio da conversa força uma conversão de formato de requisição que pode ser incompatível com os dados: blocos de raciocínio e IDs de chamada de ferramenta não necessariamente sobrevivem à tradução entre esquemas de provedor.

O DETALHE POUCO APRECIADO

Os caches de prompt são indexados por chave de API, não por modelo. Um gateway que fixa o modelo, mas distribui a carga entre três chaves no mesmo canal, ainda tem leituras frias em duas de cada três chamadas. É por isso que o pin de canal do OrcaRouter armazena {ChannelID, KeyIndex} em vez de um id de canal, e por isso o pin é descartado quando o índice de chave registrado não resolve mais para uma chave habilitada — uma chave impulsionada, mas rotacionada, tenderia a um cache frio enquanto ignora o balanceamento, que é o pior dos dois mundos.

As fixações são flexíveis em todos os casos: a ausência de um ID de sessão resolvível é um no-op, um canal fixado desabilitado ou não saudável degrada para a seleção balanceada normal, e uma fixação a um canal de peso zero em um pool misto é descartada, de modo que um administrador que esteja drenando um canal não seja impedido pela aderência. Elas nunca fazem uma requisição falhar.

3 A armadilha: stickiness desativa o roteador

Aqui está o modo de falha. No OrcaRouter, no caminho de código de pré-escalada, para um roteador ciente de sessão em qualquer estratégia não-DSL, o pino sessão→modelo retornou

Isso seria tolerável se o turno 1 fosse representativo. Não é sistematicamente o caso, por duas razões que se reforçam mutuamente.

3.1 O Turno 1 é o turno menos informativo.

O escalar de dificuldade (service/model_router_difficulty.go) é uma combinação linear ponderada de seis características lexicais:

LogPromptTokens × 0.20 limitado a log(8001) ≈ 8.99

ReasoningCueCount × 0,15 limite 5

SystemPromptLogLen × 0.10 cap log(2001) ≈ 7.60

Densidade de Palavras-chave no Código × 0,20 com limite máximo de 5,0 (correspondências por 100 caracteres)

HasTools × 0.15 já 0/1

MathMarkerCount × 0,20 limite 5

Uma abertura curta sem histórico pontua baixo quase por construção: o termo de token com peso 0,20 está próximo do seu piso, e os termos de raciocínio/matemática disparam em vocabulário que o usuário ainda não teve motivo para usar. As sessões, portanto, comprometem-se com um modelo de pool fraco no momento de menos informação — e com um pin de modelo de 30 dias apoiado por Redis, esse compromisso é longo.

Figura 1. Dificuldade média do último turno por turno de conversa, ao longo de 100 sessões latentemente difíceis e 200 genuinamente fáceis, avaliadas pelo avaliador de produção. No turno 1 — o turno em que o pino fixador é escrito — as duas populações são indistinguíveis (0.210 vs 0.208). A população difícil cruza o portão no turno 5. Sob uma política baseada apenas no pino, todas as 100 sessões latentemente difíceis são alocadas ao pool barato antes que qualquer uma dessas evidências exista.

3.2 A extensão disfarça-se de dificuldade

O segundo problema é mais sutil e enfraquece a correção óbvia. Se você simplesmente reexecutar o gate de dificuldade a cada turno, você estará reexecutando-o com base em uma pontuação calculada sobre a transcrição completa concatenada. Essa pontuação tem uma deriva ascendente embutida: o termo LogPromptTokens com peso 0.20 aumenta monotonicamente com o comprimento da conversa, e, para qualquer sessão de agente, os termos HasTools com peso 0.15 e SystemPromptLogLen com peso 0.10 são efetivamente pisos constantes. Uma sessão longa e entediante parece progressivamente mais difícil.

Figura 2. O artefato de viés de comprimento, medido em 60 sessões constituídas inteiramente por edições triviais (“renomear esta variável”, “adicionar uma verificação de nil”). A pontuação da transcrição completa deriva +16% ao longo de 25 turnos com dificuldade de tarefa constante; a pontuação do turno mais recente (delta) é estável. Uma reavaliação ingênua da pontuação da transcrição completa a cada turno escalaria as sessões pelo crime de serem longas.

A correção que o OrcaRouter envia é um extrator delta separado (service/model_router_delta.go) que pontua apenas a última rodada — o novo texto do usuário mais quaisquer resultados de ferramentas anexados após a última mensagem do assistente — reutilizando os mesmos pesos e limites, mas zerando deliberadamente o SystemPromptLogLen, que não faz parte do delta. A linha azul plana da Figura 2 é esse extrator.

4 Design: aderência em níveis

A fuga ingênua do aprisionamento no turno 1 é re-rotear cada turno — o que é apenas roteamento em nível de requisição, e abre mão do cache. A correção ingênua na outra direção é tornar o pin a memória de "esta sessão ficou difícil" — o que não consegue expressar desescalada nem pode ser limitado. O design do OrcaRouter rejeita ambas.

A reformulação: uma sessão é fixada a um modelo dentro de um nível, e um pequeno Redis estado do nível é a única memória de escalonamento. A fixação do modelo nunca é a memória.

Pools de camadas. A camada forte é o pool de escalonamento resolvido (escalation_pool, que tem como padrão o strong_pool do roteador). A camada base é AllowedModels \ pool da camada forte; um modelo presente em ambos pertence à camada forte. Dentro da camada base, as faixas de dificuldade fraca/média/forte do gated_adaptive continuam operando exatamente como antes.

Pins com escopo de nível. A chave do pin do modelo do nível forte recebe um sufixo :t:strong; o nível base mantém a chave legada inalterada. A escalada, portanto, preserva o pin base, de modo que uma sessão desescalada — ou uma retomada após o estado do nível expirar — retorna ao modelo exato em que começou, não a uma nova escolha arbitrária. Pins fortes são gravados apenas com o TTL curto da janela do provedor: um pin forte de 30 dias sobreviveria ao estado de nível de 4 horas que o justificou.

O gate é executado primeiro. Em selectByStrategy (service/model_router.go:1374), o nível é resolvido de antemão, o conjunto de candidatos é reduzido ao pool do nível, e somente então é consultado o pino fixo — dentro desse nível. Esta é a correção estrutural para §3: o cálculo de dificuldade e os gatilhos de escalada são executados a cada turno, antes que o pino possa contorná-los.

4.1 Três classes de gatilho, classificadas por confiança

Tabela 2. Gatilhos de escalada. Nenhum sinal difuso se intensifica sozinho; apenas uma solicitação explícita do cliente é assumida em n=1, e mesmo ela obedece aos limites.

Três invariantes de higiene são estruturais. Os strikes são deduplicados por ID de requisição por meio de um ring buffer, de modo que retentativas intercaladas do cliente não podem ser contadas em dobro. Falha de infraestrutura nunca é falha de capacidade — 429s, 5xxs e fallbacks de canal nunca geram strikes; apenas sinais de qualidade pós-sucesso contam. E um “turno” é definido como uma requisição concluída e cobrada com sucesso que passou pela avaliação de strikes; portanto, requisições com falha não fazem avançar nem o decaimento de strikes nem o contador de turnos limpos.

4.2 Resolve é puro; o commit é adiado

A propriedade estrutural de maior consequência do mecanismo é que ResolveEscalation não grava nada. Ele retorna uma decisão e uma lista de pendentes intenções. O distribuidor aplica essas intenções no seu bloco pós-sucesso, sobre uma nova leitura dentro de uma transação WATCH do Redis. Isso é importante porque o resolvedor roda em caminhos que nunca devem alterar estado: resoluções especulativas de cadeia de fallback, os endpoints de diagnóstico somente leitura e requisições que posteriormente retornam 403 ou falham a montante. Reaplicar intenções sobre o estado novo também significa que um escritor concorrente desatualizado não pode sobrescrever uma escalada confirmada, e duas escaladas idênticas em corrida se mesclam de forma idempotente.

4.3 Maiúsculas, e por que elas vinculam tudo

Uma escalada de falso positivo custa (strong − base) preço × tokens restantes de episódio quente, e custa silenciosamente — nada falha. O raio de explosão é limitado por tetos que se aplicam a cadaclasse:

escalation_max_per_session (padrão: 1). A desescalada e as reinicializações do cliente não o devolvem, o que elimina o caminho de exploração do loop de redefinição.

um por roteadorTeto de cota escalada (padrão de 20 %) em uma janela móvel de 24–48 h de buckets diários do Redis, além de um teto entre roteadores em todo o workspace. No teto, todo o roteamento de escalada é suprimido — incluindo pedidos explícitos e boosts únicos.

Desescalada apenas nos limites de cache frio, de modo que um falso positivo é limitado a um episódio quente.

A razão pela qual a Classe A obedece aos limites é uma conclusão de modelo de ameaça, não uma preferência de política: em um gateway de API, quem detém o token do workspace controla os cabeçalhos. Um caminho isento de limite do tipo "o cliente pediu" é um canal de gastos sem medição. §7 mede o que acontece quando todo cliente abusa disso.

4.4 A desescalada é assimétrica por design

Escalar com base em evidências corroboradas; desescalar somente quando for gratuito. Uma sessão forte retorna à base somente quando todas as seguintes: a sessão está com cache frio (ociosa além da janela do provedor registrada no escalonamento), acumulou ≥3 turnos avaliados sem strikes, e a dificuldade delta mais recente está abaixo de T1. Dentro da janela quente, uma troca paga uma releitura fria a preço cheio — flapping é a única maneira garantida de fazer o escalonamento ter custo negativo.

5 Método

Medimos o mecanismo reproduzindo um corpus sintético de sessões por meio do código real de decisão de produção. O harness é um teste Go no pacote de serviço que chama ResolveEscalation e CommitEscalationDecision a cada turno contra um armazenamento de camadas com backend em miniredis, com os pontuadores reais de dificuldade, os produtores reais de strikes do lado da requisição e a maquinaria real de teto de participação. Nada no caminho de decisão é reimplementado ou mockado, exceto o sink de eventos de auditoria.

O QUE É REAL E O QUE NÃO É

Real: cada decisão de roteamento, pontuação de dificuldade, detecção de violações, regra de sequência, avaliação de limite e transição de estado do Redis — essas são as funções implementadas. Sintético: o tráfego. O corpus é gerado, não amostrado dos logs de produção. Sua mistura de arquétipos (50 % difíceis) é uma mistura de estresse escolhida para exercitar o mecanismo, não uma estimativa do tráfego real; §6.4 relata a sensibilidade a essa escolha, e ela é grande. Os números de precisão limpos abaixo refletem um corpus cujas classes são separáveis por construção, e devem ser lidos como “o mecanismo dispara onde foi projetado para isso”, não como uma estimativa de precisão de produção.

5.1 Corpus

400 sessões, 3.968 turnos, com semente e determinísticos. Cada turno é um corpo de requisição completo de chat-completions, carregando o histórico cumulativo, uma matriz de definição de duas ferramentas e um prompt de sistema realista — o formato que um agente de codificação realmente envia. Cinco arquétipos, cada um carregando um rótulo de ground-truth:

Tabela 3. Composição do corpus. “Needs strong” é a verdade fundamental usada para as pontuações de precisão e cobertura.

Turnos difíceis carregam um dump de goroutine colado ou um trecho de código-fonte de 3–8 KB, além do texto, porque é isso que um turno real de depuração difícil contém. Esse detalhe acabou sendo extremamente importante — veja §6.2.

5.2 Modelo de custo

Os custos são calculados a partir dos preços de tabela publicados, com semântica de cache por provedor; o modelo é apresentado integralmente para que possa ser contestado.

Tabela 4. Parâmetros do modelo de custos. Preços em $ por 1M de tokens, conforme lista de agosto de 2026.

Uma rodada quente custa 0.1·p_in·prefix + write·p_in·delta; uma rodada fria custa write·p_in·prompt. A rodada 1 é sempre uma gravação completa de cache. A rodada de mudança de nível sob a política de escalada é explicitamente cobrada como fria, portanto o mecanismo paga pela sua própria invalidação de cache.

A qualidade é reportada como cobertura de curvas difíceis — a fração das curvas difíceis do ground truth efetivamente atendidas pelo modelo forte — em vez de um valor de precisão. Não executamos inferência upstream, por isso recusamo-nos a inventar números de precisão.

6 Resultados

6.1 O mecanismo dispara onde foi projetado para disparar.

Tabela 5. Resultados de escalonamento por arquétipo, modo automático, canário 100 %, T2 = 0.70 (padrão de fábrica).

Zero falsos positivos nas 200 sessões fáceis, incluindo as 60 longas que um avaliador de transcrição completa teria colocado na faixa difícil. As classes de gatilho se especializam de forma limpa e sem sobreposição: a dificuldade captura trabalhos com alta carga de raciocínio, os strikes capturam loops de falha. Observe que a pontuação máxima de dificuldade do failure_loop é 0,262 — o gate de dificuldade nunca vê essas sessões de forma alguma. Um agente preso em um loop de erro de compilação não está produzindo prosa densa em indícios de raciocínio; ele está produzindo o mesmo prompt curto com um stack trace diferente. Sem os strikes da Classe C, cada uma dessas 60 sessões continuaria se arrastando no modelo barato indefinidamente.

Figura 3.Quando as sessões escalam, divididas por gatilho. As escaladas impulsionadas por strikes são fortemente concentradas (turno 4, o primeiro turno em que dois strikes podem ter se acumulado dentro da janela de decaimento); as escaladas impulsionadas pela dificuldade distribuem-se pelos turnos 2–11, seguindo a distribuição de início do corpus. A regra da sequência de dois turnos consecutivos significa que a escalada de dificuldade mais precoce possível é o turno 2.

6.2 Constatação: o portão enviado está à beira de um precipício

Nosso primeiro corpus produziuzeroescalações impulsionadas por dificuldade. Os turnos difíceis — carregados de condições de corrida, invariantes, análise de complexidade e vocabulário de provas — atingiram o pico de 0,658 contra um limiar de 0,70. Adicionar os stack traces colados que os turnos reais de depuração realmente carregam empurrou-os para 0,719. O limiar é superado por uma margem de 0,019.

Figura 4. Para onde o orçamento de dificuldade realmente vai, em média, ao longo de 855 turnos difíceis e 3.113 turnos fáceis. Um turno difícil realista atinge 0,719 de um máximo teórico de delta de 0,90. O termo CodeKeywordDensity contribui com 0,069 do seu orçamento de 0,20 — a densidade medida é de 1,72 correspondências por 100 caracteres, contra um teto de saturação de 5,0 — e o 0,10 de SystemPromptLogLen é estruturalmente zero no extrator de delta. Aproximadamente um terço da faixa nominal da pontuação é inatingível por texto realista.

A varredura de limiar confirma que isso é um precipício, não uma inclinação. Em T2, de 0,35 a 0,65, o resultado é idêntico — 200 de 400 sessões escalam, com zero falhas. No 0,70 lançado, o classificador começa a perder sessões; em 0,75, a escalada baseada na dificuldade despenca de 122 sessões para 23.

Figura 5. Sensibilidade do limiar. Toda a faixa de 0,35–0,65 é comportamentalmente idêntica porque nenhum texto delta realista cai nela — a distribuição de pontuações é bimodal, com turnos fáceis agrupados perto de 0,23 e turnos difíceis perto de 0,72, e nada no meio. O padrão enviado fica na borda superior da moda superior.

IMPLICAÇÃO DE ENGENHARIA

T2 is calibrated for the full-transcript distribution the gated_adaptive bands were tuned on, and it is being reused as the delta extractor's threshold. The design document flags that the delta extractor “needs its own tuning”; this measurement quantifies how much. Either the delta gate needs a lower T2 of its own — anywhere in 0.45–0.60 buys identical behaviour with real margin — or the percentile-based threshold already scheduled for Phase 3 (“top X % of this router's recent traffic”) should land, which makes the escalation rate the operator's knob and sidesteps absolute calibration entirely.

6.3 Custo e cobertura

Figura 6. Cinco políticas nas mesmas 400 sessões. À esquerda: custo por 1.000 sessões (escala logarítmica). À direita: fração de turnos genuinamente difíceis atendidos pelo modelo forte.

Tabela 6. Comparação de políticas. Custo por 1.000 sessões no modelo da Tabela 4.

Vale a pena separar dois resultados. Primeiro, a afinidade de sessão, sozinha, economiza 24 % com a mesma escolha de modelo (16,64 → 12,63) e 35 % no par de fronteira (290,93 → 188,30). Isso é pura economia de cache — mesmos modelos, mesmas configurações, apenas a persistência da chave difere. A economia é maior no par de fronteira porque o prêmio de 1,25× da Anthropic sobre escrita torna as chamadas a frio desproporcionalmente caras.

Em segundo lugar, a escalada chega onde um mecanismo de resgate deveria: 45 % do custo sempre-fronteira por 67 % da sua cobertura de turnos difíceis, servindo o modelo forte em apenas 21.4 % dos turnos.

O terço que falta na cobertura não é um defeito; é o preço da catraca. As regras de corroboração que geram zero falsos positivos também significam que o mecanismo não pode agir no primeiro passo de um problema:

Tabela 7. Latência de escalonamento — turnos difíceis atendidos pelo modelo barato antes que a catraca seja acionada.

Dois turnos é exatamente o que a regra de sequência de dois turnos consecutivos especifica, e um turno é exatamente o que a regra de duas batidas para catraca especifica. A latência é proposital, e é a mesma propriedade que produziu zero falsos positivos. Quem quiser um resgate mais rápido tem o cabeçalho Classe A, que atua em n=1 — é precisamente por isso que a escotilha de escape manual foi lançada primeiro.

6.4 A proporção do título depende inteiramente do seu tráfego

O corpus é 50 % difícil por construção. O tráfego real de roteadores não é, e a comparação de custos é extremamente sensível a isso. Reponderando os custos medidos por arquétipo em uma faixa de prevalências de sessões difíceis:

Figura 7. Custo por 1.000 sessões em função de quanto do seu tráfego realmente precisa do modelo forte. O comportamento dentro da classe é mantido nos valores medidos; apenas a mistura muda.

Tabela 8. Sensibilidade de prevalência, $ por 1.000 sessões.

Na taxa de escalada alvo de ≤5 % das sessões estabelecida no próprio documento de design, a escalada custa 1,6× a conta do pool barato e 12 % da conta da fronteira. Na mistura de estresse de 50 %, custa 6,7× a conta do pool barato. Ambas as afirmações são verdadeiras; elas respondem a perguntas diferentes. A operacionalmente relevante é a primeira, e é por isso que o padrão do teto de participação é 20 %, em vez de “desligado” — o teto, não a precisão do gatilho, é o que realmente limita a conta.

6.5 Os limites resistem ao abuso adversário.

Reexecutamos o corpus com a maquinaria real de share-cap — sem stub, buckets diários reais do Redis — sob o modelo de ameaça do §8: cada cliente envia X-OrcaRouter-Tier: strong em todos os turnos.

Figura 8. Abuso adversarial de cabeçalho contra o teto de 20 % de participação escalada. As primeiras 20 requisições não têm restrições por design — o piso de aquecimento impede que “1 escalada de 2” seja lida como 50 % e bloqueie o recurso em um roteador recém-iniciado — após o que a participação converge e se mantém. Estado final: 296 de 1.439 requisições atendidas como fortes (20,6 %), com 1.143 pedidos explícitos negados e auditados como eventos denied_cap.

O excesso residual de 0,6 % é o comportamento intencional de uma comparação estritamente maior em um contador de rastreamento aproximado, e o teto de 1 por sessão impede que sessões individuais consumam o orçamento. Cada negação é visível para o cliente no cabeçalho de resposta X-Orca-Session-Tier: base; reason=denied:share_cap e para o operador na tabela de auditoria — uma escalada suprimida nunca é silenciosa.

7 O que mudaríamos

Dê ao extrator de delta seu próprio limiar. Reutilizar o T2 da transcrição completa deixa uma margem de 0.019 (§6.2). Um T2 específico para delta em 0.45–0.60 é comportamentalmente idêntico neste corpus, com duas ordens de grandeza mais folga. O trabalho de limiar percentual já agendado engloba isso e é a melhor correção.

Não deixe que o termo densidade de código permaneça apenas decorativo. Ele contribui com 0,069 do seu orçamento de 0,20 no texto realista mais denso que conseguimos construir, porque seu limite de saturação de 5 correspondências por 100 caracteres implica aproximadamente uma palavra-chave de código a cada vinte caracteres. Ou redefina esse limite com base em uma distribuição de produção medida, ou realoque seu peso.

A Classe C é o cavalo de batalha para o tráfego de agentes, e é a menos desenvolvida. A população failure_loop é invisível para o gate de dificuldade (pico 0.262) e é capturada inteiramente por strikes. As sessões de agentes falham por loop, não por se tornarem lexicamente mais difíceis. Os produtores restantes do lado da resposta — e o hook de captura de streaming nativo do Gemini que ainda está faltando — valem mais do que ajustes adicionais de dificuldade.

Publique a latência de escalonamento. Duas rodadas de trabalho árduo servidas no modelo barato é o custo honesto de uma catraca de corroboração, e os operadores devem vê-lo no painel de análises ao lado da precisão, não descobri-lo.

8 Limitações

O corpus é sintético. Foi construído para separar de forma limpa, portanto o resultado de zero falso-positivo caracteriza a especificidade do mecanismo em entrada separável, não a sua precisão no tráfego de produção. O número real de precisão só pode vir do trabalho de rotulagem em modo-sombra que o design especifica — pipeline de gatilho completo em execução, sem rotear nada, decisões rotuladas retroativamente — com um gate de go-live em ≥70 % de precisão rotulada.

O modelo de custo assume 500 tokens de saída fixos por turno, o que suprime um efeito real: os modelos de fronteira emitem mais tokens de raciocínio, portanto o verdadeiro prêmio de fronteira é subestimado. Ele também modela o aquecimento de cache em nível de requisição como um valor uniforme de 1/N sobre os slots de chave; um pool ponderado usaria o índice de Herfindahl Σw², e um canal de chave única não mostraria nenhuma vantagem de cache para afinidade de sessão na camada de canal — embora a fixação na camada de modelo ainda importe para estratégias adaptativas.

Não executamos inferência upstream, portanto nenhuma alegação de precisão ou de sucesso na tarefa é feita. A cobertura de turnos difíceis é um proxy para a qualidade e assume que o modelo forte é de fato melhor nesses turnos — plausível para os arquétipos construídos, não verificado aqui.

Por fim, isto mede a implementação de um gateway. O modo de falha de bloqueio no turno 1 deve generalizar para qualquer roteador ciente de cache que fixe sessões, mas os números específicos são propriedades desses limiares, desses pesos e desses preços.

9 Trabalhos relacionados

O roteamento em nível de requisição é bem coberto. FrugalGPTsup>[2]/sup> introduziu a cascata de LLMs — consultar o modelo barato, pontuar a resposta, escalar em caso de baixa confiança — relatando até 98 % de redução de custo com acurácia equivalente. RouteLLMsup>[1]/sup> treina roteadores em dados de preferência do Chatbot Arena e relata alcançar 95 % da qualidade do GPT-4 com 14 % de chamadas ao modelo forte, com roteadores transferíveis entre pares de modelos sem retreinamento. RouterArenasup>[3]/sup> fornece a base de avaliação que faltava: 8.400 consultas em diferentes domínios e níveis de dificuldade, avaliadas em termos de acurácia, custo, otimalidade do roteamento, robustez e overhead do roteador.

O que nenhum deles aborda é a conversa como unidade de roteamento. Uma cascata escalona uma solicitação e esquece; no próximo turno, o mesmo modelo barato é executado novamente na mesma tarefa agora sabidamente difícil. Um roteador treinado por preferências pontua uma consulta, não uma trajetória. A lacuna que este relatório aborda é o que um roteador deve lembrar entre turnos, por quanto tempo, e o que deve ser permitido fazê-lo mudar de ideia — uma questão que só se torna urgente quando o cache de prompts torna o esquecimento caro.

OrcaRouter inclui um harness RouterArena na própria árvore (eval/) que avalia suas cinco estratégias de nível de solicitação — cheapest, quality, balanced, linucb, gated_adaptive — contra o conjunto de dados aberto sem modificar o repositório upstream. O mecanismo de nível de sessão descrito aqui é ortogonal a todas as cinco e compõe-se com elas.

10 Conclusão

O cache de prompt mudou a economia do roteamento de LLMs de uma forma que a literatura sobre roteamento ainda não acompanhou. Quando a continuidade vale um desconto de 10× na maioria dos seus tokens de entrada, um roteador precisa fixar — e no momento em que fixa, toma sua decisão no turno em que sabe menos, e convive com essa decisão pelo restante da conversa. O roteamento em nível de solicitação não tem esse problema e paga por isso em cache misses; a reavaliação ingênua a cada turno reintroduz os misses e adiciona um artefato de viés de comprimento por cima.

Aderência em camadas resolve isso separando duas coisas que parecem uma: qual modelo atende esta sessão (o pino, estável dentro de uma camada) e a qual camada esta sessão pertence (um pequeno pedaço de estado, limitado, corroborado e que expira). Em nossa reprodução, essa separação recupera 87 % das sessões cuja dificuldade é indetectável no turno 1, com zero falsos positivos em 200 sessões fáceis, a 45 % do custo de always-frontier — e mantém um limite de gastos de 20 % contra clientes que tentam ativamente burlá-lo.

As fraquezas honestas do mecanismo são de calibração, não de arquitetura: um limite de dificuldade reutilizado de uma distribuição para a qual não foi ajustado, um termo de característica que não consegue atingir seu orçamento e duas rodadas de latência inevitável de resgate. Essas são tratáveis. A afirmação arquitetural — de que a memória de escalada deve ser separada do pino, de que nenhum sinal difuso pode avançar sozinho e de que os limites devem vincular a solicitação explícita do próprio cliente porque o cliente detém o token — é a parte que manteríamos.

11 Fontes

1. LMSYS Org. RouteLLM: Um Framework de Código Aberto para Roteamento de LLM Custo-Efetivo. a href="https://www.lmsys.org/blog/2024-07-01-routellm/">u>lmsys.org/blog/2024-07-01-routellm//u>/a> · código: a href="https://github.com/lm-sys/RouteLLM">u>github.com/lm-sys/RouteLLM/u>/a>

2. Chen, Zaharia e Zou. FrugalGPT: Como Usar Grandes Modelos de Linguagem Reduzindo Custos e Melhorando o Desempenho. 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: Uma Plataforma Aberta para Comparação Abrangente de Roteadores de LLM. arXiv:2510.00202. a href="https://arxiv.org/abs/2510.00202">u>arxiv.org/abs/2510.00202/u>/a>

4. OpenAI. Cache de prompts na API. a href="https://openai.com/index/api-prompt-caching/">u>openai.com/index/api-prompt-caching//u>/a> — cache automático, prefixo de ≥1,024 tokens em incrementos de 128 tokens, remoção por inatividade de 5 a 10 minutos, ≤1 hora; desconto de entrada em cache por nível de modelo. Preços: a href="https://openai.com/api/pricing/">u>openai.com/api/pricing//u>/a>

5. Anthropic. Cache de prompt. 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> — leitura de cache a 0,1× da entrada base; gravação a 1,25× (TTL de 5 minutos) ou 2× (TTL de 1 hora), renovado a cada uso. Preços: a href="https://www.anthropic.com/pricing">u>anthropic.com/pricing/u>/a>

6. DeepSeek. A API DeepSeek apresenta Cache de Contexto em Disco. a href="https://api-docs.deepseek.com/news/news0802/">u>api-docs.deepseek.com/news/news0802//u>/a> — automático, cobrado por hits reais de cache, redução de ordem de grandeza nos hits.

7. Google. Cache de contexto da API Gemini. a href="https://ai.google.dev/gemini-api/docs/caching">u>ai.google.dev/gemini-api/docs/caching/u>/a> — cache implícito e explícito com TTL precificado por armazenamento.

8. Código-fonte do OrcaRouter, este repositório: service/session_affinity.go (pins, TTLs, chaves com escopo por nível) · service/session_escalation.go (o mecanismo) · service/model_router.go:1374 (selectByStrategy: redução de nível antes da leitura do pin) · service/model_router_difficulty.go (pesos e limites) · service/model_router_delta.go (extrator de delta) · service/escalation_strikes.go (produtores do lado da requisição) · service/escalation_caps.go (limites de participação) · docs/features/frontier-escalation.md (design, rodadas de revisão 1–4).

Reprodutibilidade. O harness de medição é um teste Go no pacote de serviço que aciona ResolveEscalation / CommitEscalationDecision contra o miniredis, além de um pipeline de análise e figuras em Python. A geração do corpus é semeada (rand.NewSource(20260814)) e a execução completa é determinística: 400 sessões, 3.968 turnos, três experimentos (replay principal, execução de teto adversarial, varredura de limiar de 9 pontos). As figuras usam uma paleta categórica validada para CVD; cada figura é acompanhada de sua tabela subjacente. Nenhum dado de produção foi acessado, e nenhuma parte desta análise foi submetida ao repositório.