Roteamento de provedores no OpenRouter: qualidade do modelo, limites de tokens e custos reais

O roteamento de provedores do OpenRouter define qual serviço de inferência responde à sua solicitação. Duas chamadas com o mesmo nome de modelo ainda dependem dos limites do endpoint, dos parâmetros aceitos, do software de serviço e das preferências de roteamento. Quando as respostas ficam mais curtas ou as chamadas de ferramentas falham, verifique essas diferenças antes de culpar a quantização.

Principais pontos #

• Rótulos de precisão descrevem um formato numérico, não uma pontuação de exatidão.
• Limites do endpoint definem o contexto disponível, o tamanho da saída e o suporte a recursos.
• Roteamento explícito precisa de uma política de fallback e de uma preferência de provedor.
• Auto Exacto melhora a seleção de provedores usando sinais de qualidade, com uma rota opt-in para solicitações sem ferramentas.
• Custo efetivo inclui saída, comportamento do cache, novas tentativas e conclusão bem-sucedida da tarefa.

Pré-requisitos: Familiaridade com solicitações JSON e acesso à configuração do OpenRouter da sua aplicação. A inspeção do endpoint usa uma API pública. Enviar solicitações ao modelo exige uma chave de API e gera cobranças. Verifique os metadados do endpoint antes de repetir um exemplo datado.

Tempo e dificuldade: Cerca de 20 minutos para uma revisão inicial da configuração. Nível intermediário. Uma comparação útil entre provedores exige testes adicionais com prompts representativos.

O que o nome do modelo não informa #

Um identificador de modelo seleciona o modelo solicitado. O provedor executa o serviço de inferência, incluindo a implementação do modelo, os limites de tokens e o analisador de chamadas de ferramentas. Um benchmark do modelo não valida todos os serviços que hospedam esses pesos.

O roteamento básico favorece preços menores entre candidatos saudáveis. O OpenRouter documenta uma ponderação pelo inverso do quadrado do preço. No exemplo simplificado, um candidato de US$ 1 recebe nove vezes o peso de seleção de um candidato de US$ 3. Isso descreve pesos relativos, não uma garantia para a próxima solicitação. Ordenação explícita, classificação, cache e roteamento por qualidade também afetam a seleção. Consulte a documentação de roteamento de provedores .

A ponderação de preço não determina a conta mais barata para sua carga. O exemplo documentado não define uma mistura universal de entrada e saída para o escalar de preço. Não infira a probabilidade de seleção de um provedor apenas pelo preço de entrada.

Leia a precisão no contexto #

Quantização armazena valores numéricos em uma representação reduzida. O efeito depende do modelo, do método e da implementação de inferência. Uma precisão menor exige testes, mas o rótulo sozinho não demonstra que um provedor alterou os pesos originais.

GPT-OSS oferece um exemplo concreto. A documentação de lançamento do OpenAI gpt-oss-120b informa que os pesos dos especialistas mixture-of-experts usam MXFP4 e que as avaliações usaram a mesma quantização. Um rótulo de quatro bits para esses pesos é compatível com a versão publicada. Ele não prova uma redução adicional feita pelo provedor.

Upcasting converte valores armazenados para uma representação mais ampla. Converter um checkpoint já quantizado para BF16 não recupera informações descartadas durante a quantização. Por outro lado, converter um checkpoint originalmente de maior precisão para quatro bits introduz uma alteração separada que merece avaliação.

Rótulos iguais também não eliminam diferenças de quantização. Eles omitem detalhes como os tensores quantizados, as escolhas de calibração e os kernels de execução. Teste o endpoint completo em vez de tratar a profundidade de bits como ranking de qualidade.

Verifique o orçamento de tokens #

curl --fail --silent --show-error \
  'https://openrouter.ai/api/v1/models/openai/gpt-oss-120b/endpoints' \
  | jq '.data.endpoints[] | {
      name,
      provider_name,
      context_length,
      max_completion_tokens,
      supported_parameters,
      quantization,
      pricing
    }'

A API de endpoints expõe metadados do provedor para um modelo. Este comando precisa de curl e jq. Inspecione a resposta atual do endpoint gpt-oss-120b antes de selecionar um serviço. Trate campos ausentes ou nulos como desconhecidos, não como ilimitados. Salve um snapshot local datado ao comparar resultados.

Uma verificação em 5 de outubro de 2026 retornou estes limites anunciados para gpt-oss-120b. São valores de metadados, não comprimentos de conclusão medidos. Os provedores mudam esses valores com o tempo.

O tamanho do contexto e o tamanho da saída são limites separados. Um modelo de contexto longo ainda precisa de espaço suficiente para a resposta. O histórico da conversa, as instruções do sistema e as definições de ferramentas consomem espaço junto com o documento do usuário.

Tokens de raciocínio também consomem o orçamento de geração em modelos com raciocínio. Um limite pequeno arrisca raciocínio incompleto, pouca saída visível ou término antes da resposta final. Inspecione o uso e o motivo do término em vez de supor que toda resposta curta reflete pesos mais fracos. O OpenRouter explica esse orçamento na documentação de tokens de raciocínio .

Um max_tokens explícito fornece ao roteador um tamanho de saída solicitado para comparar com o suporte do provedor. Escolha esse valor a partir das necessidades medidas da tarefa e do contexto disponível. Definir um valor excessivo reduz a elegibilidade e não garante uma resposta mais longa ou melhor.

Exija seus parâmetros #

{
  "model": "openai/gpt-oss-120b",
  "messages": [
    {"role": "user", "content": "Explain the failure modes of a retry loop."}
  ],
  "max_tokens": 8192,
  "provider": {
    "require_parameters": true
  }
}

require_parameters tem false como padrão. No roteamento padrão, parâmetros sem suporte não necessariamente excluem um endpoint. O OpenRouter documenta provedores que ignoram parâmetros desconhecidos. Definir este campo como true filtra o roteamento pelo suporte declarado.

Metadados de suporte não são uma garantia comportamental. Um endpoint que anuncia suporte a seed ainda precisa de testes de reprodutibilidade. Um endpoint compatível com ferramentas ainda precisa de validação de esquema e testes no nível da aplicação. O filtro impede que incompatibilidades conhecidas entrem no conjunto de candidatos.

Fixe provedores de forma deliberada #

{
  "model": "openai/gpt-oss-120b",
  "messages": [
    {"role": "user", "content": "Summarize the supplied incident report."}
  ],
  "max_tokens": 8192,
  "provider": {
    "order": ["REPLACE_WITH_VERIFIED_PROVIDER_SLUG"],
    "allow_fallbacks": false,
    "require_parameters": true
  }
}

Substitua o placeholder por um slug de provedor copiado da lista de provedores do modelo. Envie o relatório na sua solicitação real. Este modelo serve para revisar a configuração. Ele não é uma solicitação executável até substituir o placeholder.

order estabelece uma preferência. Sozinho, deixa o fallback para outros provedores habilitado. Com allow_fallbacks: false, restringe o roteamento aos provedores listados. Espere uma solicitação falha quando nenhum atender à solicitação ou permanecer disponível.

Variantes de endpoint precisam de atenção. Um slug de provedor base corresponde a várias variantes segundo as regras documentadas. Use o slug da variante específica ao testar uma configuração de serviço determinada. Verifique novamente o provedor informado em cada resposta.

quantizations é uma lista de formatos nomeados permitidos, não um mínimo numérico. Uma lista contendo "fp8" seleciona endpoints FP8 correspondentes. Ela não inclui BF16 automaticamente nem todos os formatos com mais bits. Compare primeiro o checkpoint original. Depois aplique este filtro apenas quando sua avaliação sustentar a restrição.

Mantenha o roteamento de qualidade ativado #

{
  "model": "openai/gpt-oss-120b:exacto",
  "messages": [
    {"role": "user", "content": "Compare the two supplied incident reports."}
  ],
  "max_tokens": 8192,
  "provider": {
    "require_parameters": true
  }
}

O Auto Exacto usa taxa de transferência, telemetria de chamadas de ferramentas e benchmarks para reduzir a prioridade de provedores com desempenho inferior. O anúncio de março de 2026 do OpenRouter relata queda de 88% nos erros de chamadas de ferramentas do GLM-5, de cerca de 8% para perto de 1%. Ele relata gpt-oss-120b passando de 5,6% para 3,5%.

Esses são resultados informados pelo provedor, não uma promessa para sua aplicação. A validade da chamada mede JSON, nomes e esquemas. Uma chamada sintaticamente válida ainda precisa dos argumentos corretos e da ação correta para a tarefa do usuário.

Solicitações com ferramentas recebem Auto Exacto por padrão quando o modelo possui cobertura suficiente de provedores. Para outras solicitações, :exacto ativa o roteamento de qualidade. A documentação atual, portanto, cobre roteamento de qualidade para resumo e chat, além do uso de ferramentas.

sort: "price", o sufixo :floor e a classificação de preço padrão no nível da conta desativam o Auto Exacto. Verifique juntos os ajustes da aplicação e as preferências da conta. Consulte a documentação do Auto Exacto antes de combinar controles de roteamento.

Calcule o custo da sua carga #

O preço de entrada sozinho é uma comparação incompleta. Considere estas taxas ilustrativas, expressas em dólares por milhão de tokens. Elas demonstram a aritmética e não são cotações atuais.

Workload: 6 million input tokens + 1 million output tokens

A = 6 × $0.03 + 1 × $16.00 = $16.18
B = 6 × $0.42 + 1 × $1.32  =  $3.84

Per million combined input and output tokens:
A = $16.18 / 7 = $2.31
B =  $3.84 / 7 = $0.55

O endpoint A custa cerca de 4,2 vezes mais para essa mistura, apesar do preço menor de entrada. A proporção de 533 para 1 entre saída e entrada em A é uma relação entre duas taxas, não um multiplicador do custo total do usuário. Proporções diferentes de entrada e saída mudam a comparação.

As unidades de preço da API diferem das tabelas de comparação. A API de endpoint expressa preços por token. Multiplique por um milhão antes de comparar com as taxas acima.

O cache de prompt adiciona outra variável. Leituras do cache, gravações do cache e entrada sem cache exigem contabilidade separada segundo as regras de cobrança do provedor. Texto repetido não garante um acerto de cache. Confira as contagens e os custos de tokens em cache na documentação de cache de prompt .

O roteamento afeta a continuidade do cache. O OpenRouter documenta roteamento persistente para cache, enquanto a ordem manual de provedores tem precedência. O Auto Exacto também reordena provedores e, às vezes, interrompe um cache aquecido. Compare a economia observada com cache à qualidade e aos custos de novas tentativas antes de alterar qualquer política.

O custo por resultado aceito é a métrica útil da aplicação. Divida o gasto total, incluindo novas tentativas e falhas, pelos resultados que atendem aos critérios de aceitação. Inclua separadamente as cobranças não relacionadas a tokens. Uma taxa baixa de tokens não compensa tarefas que falham repetidamente.

Diagnostique uma resposta inconsistente #

Preserve o ID de geração retornado com a resposta. A API de metadados de geração do OpenRouter expõe identidade do provedor, uso, custo e informações de término. Um ID de sessão agrupa trabalho relacionado, mas não substitui o ID de geração para consultar uma única solicitação.

Salve a solicitação junto com o ID de geração. Mantenha o modelo, as preferências do provedor, os parâmetros solicitados, o horário e o uso da resposta. Isso torna uma comparação posterior de qualidade ou custo reproduzível quando o roteamento, os preços ou os metadados do endpoint mudarem.

Compare endpoints em condições iguais. Use o mesmo prompt, ferramentas, ajustes de raciocínio e orçamento de tokens. Repita em várias tarefas representativas. Separe respostas incompletas, chamadas de ferramentas inválidas e respostas erradas em vez de combiná-las em uma pontuação de qualidade sem explicação.

A incerteza do benchmark importa. A análise da Epoch AI sobre a dificuldade do benchmarking descreve variações de implementações, amostragem e estruturas de agentes. Uma resposta decepcionante não estabelece um defeito persistente do provedor nem identifica sua causa.

Guia de roteamento de endpoints #

Para assistir: Discussão sobre qualidade e roteamento de endpoints do OpenRouter . Verifique novamente as listas de endpoints antes de aplicar preços, limites ou comparações específicas.

Próximos passos #

1. Inspecione os endpoints de um modelo e registre os limites relevantes para sua carga.
2. Selecione uma política de roteamento com requisitos explícitos de parâmetros e comportamento de fallback.
3. Teste tarefas representativas em endpoints candidatos e no roteamento de qualidade.
4. Registre o custo do resultado aceito junto com latência, uso de cache e categorias de falha.
5. Verifique novamente após mudanças nas versões do modelo, no comportamento do serviço ou nos preços do provedor.

Para fundamentos mais amplos de IA, continue com Conceitos básicos de IA . Para permissões de agentes e controles de validação, leia Protegendo sistemas de IA .