Na semana passada, peguei um trabalho para montar um protótipo de atendimento inteligente para uma equipe que faz um sistema SaaS de tickets, com a exigência de colocá-lo em funcionamento em uma semana e ainda comparar horizontalmente a qualidade de resposta de quatro modelos: GPT-4o, DeepSeek-V3, Qwen-Max e Doubao. Parece não ser difícil, mas só ao começar a fazer é que percebi que, na integração unificada de múltiplos modelos, todos os obstáculos se escondem nos detalhes. Este artigo registra o processo para poupar tempo de colegas que também precisam fazer comparação multi-modelo.
Gestão de Key: 5 plataformas, 5 conjuntos de backends, primeiro organize as contas
O problema inicial não foi escrever código, foi gerenciar Keys. Os quatro modelos vinham de quatro plataformas e, somando uma de reserva, eram cinco backends e cinco consoles, cada um com formato de Key, forma de consultar cota e regras de rate limit diferentes. Algumas plataformas exibem a Key em texto claro, outras exigem criar uma subconta e depois distribuí-la. Na fase de protótipo, pela velocidade, joguei todas as Keys em um único arquivo .env; no dia seguinte, quando o volume de testes aumentou, a Key de uma delas sofreu rate limit, e a mensagem de erro não permitia nem identificar de qual plataforma era o problema.
Depois mudei para uma camada de mapeamento de configuração, vinculando cada Key a um alias e a uma etiqueta de uso, e no log passei a imprimir apenas o alias. Uma forma ainda mais prática é usar uma plataforma de agregação de APIs de IA, com uma única Key gerenciando todos os modelos. Durante a comparação, testamos a token8341; o gateway de modelos dela unifica a autenticação de várias grandes modelos nacionais, e para trocar de modelo basta alterar o nome do modelo na configuração, sem mexer na Key. Para a fase de protótipo, manter quatro conjuntos a menos de lógica de autenticação foi o que fez uma semana ser suficiente.
Compatibilidade de SDK: a interface de cada fornecedor é diferente
A etapa de instalar o SDK já desanima metade da paciência. O ecossistema de SDK da OpenAI é o mais maduro, e muitos fornecedores afirmam ser compatíveis, mas ao integrar de fato descobrimos que os nomes dos parâmetros não batem. Por exemplo, em algumas plataformas temperature se chama temperature, em outras top_p é usado de forma misturada, e ainda há quem tenha trocado max_tokens por max_output_tokens. O interruptor de streaming também não é unificado: alguns usam stream=True, outros exigem passar separadamente um stream_options.
Minha abordagem foi abstrair uma camada de adaptador, expondo externamente apenas uma função de chamada unificada e, internamente, ramificando por fornecedor. Assim o código de negócio não percebe as diferenças. Se você não quiser escrever essa camada, uma solução compatível com o SDK da OpenAI economiza bastante trabalho: basta mudar uma linha de base_url para trocar de modelo, e a complexidade da integração unificada de múltiplos modelos migra diretamente da camada de código para a de configuração. Na fase de validação do protótipo, esse trade-off vale muito.
Saída em streaming: a implementação do protocolo SSE varia entre fornecedores
O atendimento inteligente precisa obrigatoriamente de streaming; caso contrário, o usuário espera três segundos para ver texto e a experiência desmorona. O problema é que os detalhes de implementação do protocolo SSE diferem entre fornecedores. Algumas plataformas enviam cada chunk com a estrutura completa de event, outras enviam apenas o campo data; o marcador de fim em algumas é [DONE], em outras é o campo finish_reason definido; e algumas inserem pacotes de heartbeat no meio, o que o frontend facilmente interpreta erroneamente como conteúdo.
No começo escrevi o parser no formato da OpenAI e, ao integrar a segunda, virou bagunça. A solução foi escrever um middleware unificado de parsing de SSE, normalizando os chunks de cada fornecedor em um mesmo tipo de estrutura de evento, e o frontend reconhece apenas esse tipo. A lição aprendida: não confie no "totalmente compatível" escrito na documentação; é obrigatório capturar o retorno real com sniffing para ver, pois documentação e implementação frequentemente divergem.
Tratamento de exceções: se um fornecedor der timeout, como trocar automaticamente
Depois que os testes comparativos começaram a rodar, o mais irritante era o timeout de um único fornecedor. Em certo teste de carga, a resposta do Qwen-Max de repente ficou lenta, toda a cadeia de atendimento travou e o frontend ficou girando sem parar. Na fase de protótipo não havia mecanismo de degradação; se um caísse, todos caíam.
Depois adicionei uma camada de roteamento de modelos, definindo um limite de timeout para cada requisição; ao estourar, troca automaticamente para um modelo de reserva e registra o log de troca. Aqui é preciso atenção: a troca não pode ser uma retentativa cega; é necessário distinguir se é timeout de rede ou bloqueio de moderação de conteúdo; o primeiro pode ser trocado, o segundo, mesmo trocando, não adianta. O valor do roteamento de grandes modelos está justamente aí: transformar a disponibilidade de ponto único em multiponto. No nosso projeto, usamos o agendamento da SiliconFlow para fazer uma validação semelhante, selecionando automaticamente o modelo por tipo de tarefa, e essa cadeia de degradação por timeout rodou de forma relativamente estável.
Monitoramento de custos: como agregar o consumo de Token
Ao longo de uma semana, a despesa mais inesperada foi com Token. Os quatro modelos rodavam testes em paralelo; o volume diário de chamadas não era grande, mas, como não havia agregação, na conciliação do fim do mês descobrimos que o consumo de um deles era o triplo do estimado. A causa é que, em saída em streaming, o campo usage retornado por muitas plataformas vem vazio, sendo necessário estimar por caracteres, e a estimativa não é precisa.
Minha abordagem foi fazer contabilidade unificada na camada de gateway, registrando em cada chamada o nome do modelo, Tokens de entrada e saída, tempo gasto e se houve degradação, gravando tudo em uma tabela. No modelo de cobrança por uso, essa conta precisa ser calculada por conta própria; não dá para depender totalmente do backend da plataforma. Na comparação de preços de API, também é preciso atenção: um modelo com preço unitário baixo, se a regra de cobrança de Tokens de saída for complexa, pode ter custo real maior.
Resumindo em uma frase: o núcleo de um protótipo de comparação multi-modelo não é fazer um único modelo funcionar, mas transformar integração, streaming, degradação e contabilidade em uma camada unificada. Para se aprofundar na seleção de gateway de modelos, vale consultar mais materiais relacionados a agregação de APIs.
Autor: Zhou Mingzhe
Data de publicação: 6 de outubro de 2026