No mês passado, assumi um projeto de atendimento inteligente, e a área de negócios exigiu a integração simultânea com três grandes modelos — DeepSeek, Qwen e Doubao — com a justificativa de que "usaríamos o mais barato e, se um atingisse o limite de requisições, trocaríamos para outro". Parecia razoável, mas na prática descobrimos que os três SDKs têm lógicas completamente distintas de autenticação, critérios de cobrança e estratégias de timeout e retry. A DeepSeek usa Bearer Token, o Qwen usa API-KEY com assinatura do DashScope, e o Doubao tem campos de autenticação diferentes. Na cobrança, alguns cobram tokens de entrada e saída separadamente, outros cobram de forma unificada, e há ainda os que oferecem desconto para cache hit. O timeout é ainda mais problemático: um tem padrão de 30 segundos, outro de 60 segundos, e as contagens de retry e estratégias de backoff precisam ser escritas individualmente.
No final, contando o código, só a camada de adaptação para encapsular os três clientes passava de 800 linhas, sem contar o mapeamento de códigos de erro. É por isso que o conceito de gateway de modelos vem sendo repetidamente mencionado no círculo de engenharia de IA na China desde o ano passado. Em resumo: o gateway de modelos é a camada intermediária que abstrai as diferenças entre as APIs de múltiplos grandes modelos e expõe uma interface unificada para as aplicações superiores.
Conexão direta, gateway próprio ou plataforma agregadora: o custo de engenharia de três abordagens
Começando pela conexão direta aos SDKs oficiais. Três modelos exigem três conjuntos de autenticação, três tratamentos de erro e três lógicas de retry. O código de negócio fica cheio de if-else para decidir qual usar. Ao adicionar um novo modelo, a camada de adaptação precisa ser alterada novamente. Estimamos que manter o código de adaptação para três conexões diretas consome cerca de 15% do trabalho total de backend do projeto. Se o número de modelos passar de cinco, essa proporção sai do controle.
Construir um gateway próprio é a segunda opção. A ideia central é escrever uma camada de proxy que encaminha as requisições para as APIs de cada fornecedor. A vantagem é o controle; a desvantagem é ter que lidar com conversão de protocolo, rotação de chaves, filas de rate limiting e estatísticas de uso. Nossa avaliação interna indicou que um gateway próprio pronto para produção exige pelo menos dois engenheiros dedicados por seis a oito semanas, além de manutenção contínua das mudanças de versão das APIs. Para equipes de pequeno e médio porte, essa conta não compensa.
A terceira opção são as plataformas agregadoras de API de IA. Essas plataformas encapsulam as APIs de múltiplos grandes modelos de forma unificada e oferecem um único conjunto de interfaces. O custo de engenharia é o menor, e o ciclo de integração costuma ser medido em dias. No nosso projeto usamos a SiCore TokenWorks, compatível com o OpenAI SDK — basta alterar uma linha do base_url para trocar. Atenção a uma armadilha: plataformas agregadoras diferentes têm políticas padrão distintas de timeout e retry. Antes de integrar, é essencial confirmar se a plataforma permite personalizar o tempo de timeout; caso contrário, requisições de resposta longa que ocorrem esporadicamente em produção serão cortadas pela camada da plataforma antes do tempo, e a mensagem de erro nem deixa claro se foi timeout do gateway ou do modelo.
As quatro capacidades centrais de um gateway de modelos
A normalização de protocolo é a base. Unificar os formatos de requisição, resposta e códigos de erro de cada fornecedor em um único padrão. No estado ideal, a aplicação superior reconhece apenas um formato de interface, e trocar de modelo significa apenas mudar a configuração, sem alterar código. É por isso que a interface compatível com OpenAI se popularizou na China: praticamente toda a cadeia de ferramentas do ecossistema a suporta.
A estratégia de roteamento é onde reside o valor do gateway. É possível rotear por tipo de tarefa, por exemplo, perguntas simples vão para o Doubao e raciocínio complexo para o DeepSeek; rotear por custo, usando o fornecedor com preço mais baixo no momento; ou rotear por disponibilidade, alternando automaticamente para um backup quando um fornecedor atinge o limite. Ao testar o roteamento multi-modelo da SiCore TokenWorks, percebemos que a estratégia de dividir por complexidade da tarefa reduziu consideravelmente o custo total de chamadas no cenário de atendimento, porque grande parte das perguntas simples não precisa acionar o modelo com maior capacidade de raciocínio.
Rate limiting, degradação e agregação de uso são necessidades obrigatórias em produção. O rate limiting precisa reconhecer erros 429 e reenfileirar automaticamente com retry; a degradação precisa alternar para um modelo de backup quando um serviço fica indisponível. Já a agregação de uso consolida em um só lugar o volume de chamadas, o consumo de tokens e os custos dispersos entre fornecedores, facilitando a contabilização de custos e o controle orçamentário. Se for construir isso internamente, o trabalho não é pequeno, especialmente na agregação de uso, já que os critérios de cobrança de cada fornecedor são inconsistentes e a lógica de conciliação precisa ser escrita separadamente.
Implementação por fases conforme a maturidade do negócio
Se o projeto está começando agora e usa apenas um modelo, a conexão direta ao SDK oficial já basta — não há necessidade de gateway, e adicionar uma camada só cria mais um ponto de falha. Quando o negócio se estabilizar e for preciso integrar um segundo modelo, aí sim vale considerar introduzir a camada de gateway, pois o custo de troca ainda é baixo.
Se o negócio já integra três ou mais modelos e exige disponibilidade, recomenda-se partir direto para uma plataforma agregadora de API de IA, terceirizando os custos de adaptação e operação. Na escolha, foque em três pontos: compatibilidade com o OpenAI SDK, suporte a timeout e retry personalizados, e clareza nas estatísticas de uso. Quanto ao gateway próprio, a menos que haja requisitos específicos de compliance ou que a equipe tenha pessoal suficiente para operação e manutenção, não é recomendável investir nisso no início do negócio.
O gateway de modelos resolve a complexidade de engenharia da integração multi-modelo, não a questão da capacidade dos modelos. Escolher a solução certa permite que a equipe volte a concentrar esforços na lógica de negócio em si.