Como rotear requisições para LLM ao modelo adequado para cada tarefa

Resposta curta: roteie as solicitações no seu aplicativo e use uma única chave CometAPI e a base URL compatível com OpenAI https://api.cometapi.com/v1 para chamar o modelo selecionado. Envie trabalho repetitivo e fácil de verificar para uma camada de baixo custo; interações com clientes sensíveis à latência para uma camada rápida; e trabalho ambíguo ou de alto impacto para uma camada de alta precisão. Mantenha esses rótulos como sua própria política — não como um ranking universal de modelos — e meça todas as camadas no mesmo conjunto de teste.

Este guia constrói esse roteador de três camadas com um exemplo compacto em Python, fallback limitado e um modelo de custo que contabiliza novas tentativas e saídas rejeitadas. O exemplo usa IDs de modelos atuais do catálogo da CometAPI, mas a lógica de roteamento fica separada para que os modelos possam ser substituídos sem reescrever o aplicativo.

O que é roteamento de LLM?

Roteamento de LLM é o processo de enviar cada solicitação para o modelo ou a camada de serviço que melhor se ajusta à sua tarefa, meta de latência, requisito de qualidade e orçamento.

Como você deve rotear solicitações de LLM por tarefa?

Em 20 de agosto de 2026, os seguintes IDs de modelos e campos de preços do catálogo estavam disponíveis por meio da CometAPI Models API pública. As tarifas estimadas para consumidores abaixo aplicam o valor atual de ratio do catálogo aos preços de base de entrada e saída, conforme o CometAPI pricing guide. Confirme a tarifa final exibida para sua conta antes do uso em produção.

“Rápida” significa que a rota tem um objetivo de latência; “alta precisão” significa que possui um objetivo de qualidade mais rígido. Nenhum desses rótulos prova que um modelo é sempre o mais rápido ou o mais preciso. Avalie latência p50 e p95, taxa de aprovação por tarefa e custo por saída aceita no seu próprio tráfego antes de tornar o mapeamento permanente.

Como configurar a CometAPI para um roteador de LLM?

Você precisa de uma chave da CometAPI, Python 3.10 ou posterior e do pacote OpenAI para Python. Armazene a chave no servidor em vez de no código-fonte.

pip install openaiexport COMETAPI_KEY="your-key-here"

O exemplo usa POST /v1/chat/completions. A CometAPI documenta isso como uma interface compartilhada para vários provedores, mas o comportamento dos parâmetros ainda pode variar por modelo. Verifique a entrada atual do modelo e a referência de Chat Completions antes de adicionar campos específicos do provedor.

O que você precisa para construir um roteador de LLM?

• Mapeie tarefas estáveis para camadas de serviço. Não peça para outro LLM classificar toda solicitação a menos que sinais simples do aplicativo sejam insuficientes. Uma tag de suporte é previsivelmente trabalho de camada barata; uma resposta ao vivo é sensível à latência; uma revisão de política merece o gate de qualidade mais rígido.
• Valide a saída. Sucesso no status HTTP não significa que o resultado é utilizável. Passe um validador específico da tarefa para o roteador. Um validador de classificação pode verificar um rótulo permitido; um validador de resposta ao cliente pode impor comprimento e proibições; um fluxo estruturado pode validar um schema JSON.
• Faça fallback de forma restrita. Tente a próxima rota aprovada após timeout, 408, 429, 5xx temporário ou uma falha limitada no gate de qualidade. Não use outro modelo para encobrir entrada malformada, chave inválida ou parâmetros não suportados.

Como construir um roteador de LLM em Python?

import osimport time​from openai import APIError, OpenAI​client = OpenAI(    api_key=os.environ["COMETAPI_KEY"],    base_url="https://api.cometapi.com/v1",    max_retries=0,    timeout=20,)​MODELS = {    "cheap": "deepseek-v4-flash",    "fast": "gemini-3.7-flash",    "accurate": "claude-opus-5",}​# Put the preferred tier first; later tiers are fallbacks.ROUTES = {    "tag": ["cheap", "fast", "accurate"],    "reply": ["fast", "cheap", "accurate"],    "policy_review": ["accurate", "fast", "cheap"],}​​def retryable(error):    status = getattr(error, "status_code", None)    return status is None or status in {408, 429} or (status and status >= 500)​​def route(task, prompt, validate=lambda text: True):    attempts = []    for tier in ROUTES.get(task, ROUTES["reply"]):        model = MODELS[tier]        started = time.perf_counter()        try:            response = client.chat.completions.create(                model=model,                messages=[{"role": "user", "content": prompt}],                max_tokens=400,            )            text = response.choices[0].message.content or ""            attempts.append({                "tier": tier,                "model": model,                "latency_ms": round((time.perf_counter() - started) * 1000),                "accepted": validate(text),            })            if attempts[-1]["accepted"]:                return {                    "text": text,                    "route": tier,                    "model": model,                    "usage": response.usage.model_dump() if response.usage else None,                    "attempts": attempts,                }        except APIError as error:            attempts.append({"tier": tier, "model": model, "status": error.status_code})            if not retryable(error):                raise​    raise RuntimeError(f"No route passed: {attempts}")​​if __name__ == "__main__":    result = route(        "reply",        "Reply to a customer asking when their refund will arrive. Do not promise a date.",        validate=lambda text: 30 <= len(text) <= 600 and "guarantee" not in text.lower(),    )    print(result)

Como limitar as novas tentativas antes do fallback?

Mantenha as novas tentativas do SDK em zero e envolva cada chamada de modelo com um limite explícito. O helper abaixo só repete falhas de API reintentáveis uma vez e, em seguida, lança a exceção para que a rota externa avance para a próxima camada aprovada.

MAX_ATTEMPTS_PER_MODEL = 2​def call_model(model, prompt):    for attempt in range(1, MAX_ATTEMPTS_PER_MODEL + 1):        try:            return client.chat.completions.create(                model=model,                messages=[{"role": "user", "content": prompt}],                max_tokens=400,            )        except APIError as error:            if not retryable(error) or attempt == MAX_ATTEMPTS_PER_MODEL:                raise            time.sleep(min(0.5 * (2 ** (attempt - 1)), 2.0))

Em route(), substitua a chamada direta a client.chat.completions.create(...) por call_model(model, prompt). Com três camadas, uma solicitação para após no máximo seis chamadas de provedores; falhas de validação ainda escalam uma vez por camada, em vez de repetir a mesma saída.

Execute com python3 llm_task_router.py. Para mudar de provedores ou gerações de modelos depois, atualize MODELS; a política da tarefa e o contrato de resposta permanecem em um só lugar.

O exemplo usa apenas parâmetros compartilhados pelos modelos selecionados. Adicione controles de tokens específicos do modelo por meio de uma camada adaptadora após verificar a compatibilidade do modelo.

Como testar uma política de roteamento de LLM?

Primeiro verifique se a política determinística seleciona a camada primária pretendida. Estas são expectativas de roteamento, não resultados de desempenho do provedor:

Um teste de fumaça bem-sucedido retorna a resposta mais a camada selecionada, o ID do modelo, o uso de tokens e todas as tentativas. Os valores reais de tokens e latência variarão:

{  "text": "...",  "route": "fast",  "model": "gemini-3.7-flash",  "usage": {    "prompt_tokens": "measured value",    "completion_tokens": "measured value"  },  "attempts": [    {      "tier": "fast",      "model": "gemini-3.7-flash",      "latency_ms": "measured value",      "accepted": true    }  ]}

Para uma comparação real, execute as mesmas solicitações rotuladas em todos os três modelos. Registre taxa de aprovação por tarefa, latência p50 e p95, taxa de erro, tokens de entrada e saída, taxa de fallback e taxa de revisão humana. A métrica que normalmente importa é o custo por saída aceita, não o custo por chamada de API.

Quanto custa o roteamento com múltiplos modelos?

Use um formato de carga de trabalho único para comparação justa. Assuma 1 milhão de tokens no total: 800.000 tokens de entrada e 200.000 tokens de saída. Usando as tarifas derivadas do catálogo verificadas em 20 de agosto de 2026:

Se o tráfego for 60% barata, 30% rápida e 10% alta precisão, o custo de tokens combinado projetado é de cerca de $1.19 por 1 milhão de tokens totais. Enviar a mesma mistura inteiramente para a rota de alta precisão seria cerca de $7.20 sob essas premissas. Este é um cálculo de preço, não prova de que a política mista atenderá à sua meta de qualidade.

Novas tentativas e rejeições mudam o resultado. Uma taxa de nova tentativa única de 5% eleva a projeção de $1.19 para aproximadamente $1.25. Se uma saída de baixo custo falhar na validação e a solicitação inteira for repetida na camada de alta precisão, contabilize ambas as chamadas. Acompanhe as saídas aceitas para que um modelo aparentemente barato não oculte custos de revisão ou regeneração.

Quais são as falhas de roteamento de LLM mais comuns?

O guia de erros e novas tentativas recomenda repetir limites de taxa e falhas temporárias da plataforma com backoff, enquanto solicitações malformadas e falhas de autenticação devem ser corrigidas. O guia de fallback também mantém o fallback de modelos ordenado e explícito.

Roteamento na aplicação vs. CometAPI Auto: qual usar?

Use roteamento na aplicação quando controle e reprodutibilidade importarem. Mantenha a decisão no seu código quando as tarefas forem estáveis e você precisar de identidades de modelo fixas, orçamentos por camada, validadores personalizados e uma ordem de fallback auditável. Essa abordagem também facilita comparar o mesmo mapa de modelos entre versões.

Use o CometAPI Auto quando reduzir a manutenção do roteamento for mais importante. Defina model=auto para um padrão equilibrado ou model=auto-high quando a qualidade tiver prioridade maior. A CometAPI seleciona dinamicamente um modelo elegível com base nas características da solicitação e no pool de roteamento atual, de modo que o modelo subjacente pode variar; isso torna o Auto menos adequado quando cada execução deve usar o mesmo modelo ou parâmetros específicos do modelo.

Como executar roteamento de LLM em produção?

• Atualize o registro de modelos. Chame GET https://api.cometapi.com/api/models durante a implantação ou inicialização e falhe o release se um ID configurado ou endpoint necessário estiver ausente. IDs de modelo, preços e capacidades podem mudar.
• Mantenha opções específicas do provedor fora do roteador. Uma superfície comum de Chat Completions não torna todos os parâmetros idênticos. Por exemplo, suporte a logprobs, controles de raciocínio ou múltiplos candidatos podem diferir. Coloque essas diferenças em adaptadores testados.
• Limite tráfego e saída. Limite a concorrência antes que as solicitações saiam do aplicativo, use backoff exponencial com jitter para 429 e defina um teto de tokens de saída. O guia de limites de taxa da CometAPI recomenda os mesmos controles no lado da aplicação.
• Registre a decisão. Grave tipo de tarefa, versão da política, camada escolhida, ID do modelo, latência, uso de tokens, resultado da validação, contagem de novas tentativas, motivo do fallback e estimativa de custo. Evite registrar segredos ou conteúdo do cliente desnecessário.
• Promova rotas com evidências. Mantenha um conjunto de avaliação rotulado para cada tarefa. Faça rollout gradual das mudanças no mapeamento, compare-as com a política anterior e preserve um caminho rápido de rollback.

Perguntas frequentes

A CometAPI decide automaticamente qual modelo é barato, rápido ou preciso?

Este tutorial mantém essa política no código da aplicação. A CometAPI fornece a chave compartilhada, a base URL, o catálogo de modelos, a interface de Chat Completions e blocos de construção de fallback documentados. Sua equipe define o que cada camada significa e qual modelo passou nos testes.

Uma única chave CometAPI pode chamar modelos de diferentes provedores?

Sim. Para rotas de texto compatíveis com OpenAI, use https://api.cometapi.com/v1 e altere o valor de model. O catálogo atual deve ser verificado antes da implantação.

Por que não enviar toda solicitação para o modelo mais barato?

A menor tarifa por token pode se tornar cara se as saídas falharem na validação, exigirem novas tentativas ou gerarem trabalho de revisão humana. Compare o custo por resultado aceito e mantenha tarefas de alto impacto atrás de gates de qualidade mais rígidos.

Falha de qualidade deve acionar fallback?

Apenas quando a falha for detectável por máquina e a escalada for limitada. Um erro de schema, campo obrigatório ausente ou promessa proibida pode justificar uma escalada. Insatisfação vaga deve virar dados de avaliação, não um loop ilimitado de novas tentativas.

Com que frequência o mapa de modelos deve mudar?

Mude quando dados atuais do catálogo e uma avaliação repetível mostrarem uma melhor troca. Não rotacione modelos apenas porque um novo nome apareceu no catálogo.

Posso adicionar um modelo OpenAI depois?

Sim. Adicione um ID de modelo compatível com OpenAI atual a MODELS, teste o mesmo contrato de solicitação e resposta e coloque-o na ordem da rota. O cliente, a chave e a base URL permanecem inalterados.

Como manter uma política de roteamento de LLM sustentável?

O roteador multi-provedor mais simples não é uma caixa-preta autônoma. É uma política de tarefas curta e versionada, apoiada por acesso de API compartilhado, metadados atuais de modelos, um validador de qualidade e uma cadeia de fallback estreita. A CometAPI reduz o trabalho de conexão a uma chave e uma base URL compatível com OpenAI; sua aplicação mantém o controle das decisões de custo, latência e qualidade.