Roteamento de Modelos de Peso Aberto em Escala: GLM-5.1 vs Claude Opus 4.7 no Gateway de IA TrueFoundry

Executamos 20 prompts fixos através do TrueFoundry AI Gateway comparando quatro estratégias: todas as Claude Opus 4.7, todas as Z.AI GLM-5.1, um roteador classificador Haiku (fácil → aberto, difícil → fronteira), e um modelo virtual 80/20. Nesta combinação, o roteamento classificador reduziu o custo combinado ~31% versus apenas Opus ($15,72 vs $22,72 por 1M de tokens) enquanto obteve uma pontuação mais alta no nosso avaliador Sonnet (4.94 vs. 4.85). All-open foi o mais barato ($3.00 / 1M) mas mais lento e com qualidade ligeiramente inferior. A conclusão: você não precisa de uma única string de modelo para cada solicitação — o roteamento de Gateway mais um classificador barato pode preservar a qualidade de ponta em tarefas difíceis sem pagar preços de ponta nas fáceis.

Por que isso importa agora

A onda de pesos abertos não é mais teórica. Modelos como GLM-5.1 vêm com codificação agêntica posicionamento, de 200K tokens contexto, e preços de tabela uma ordem de magnitude abaixo das APIs de ponta, enquanto, Claude Opus 4.7 permanece a referência para raciocínio complexo.

Equipes de plataforma enfrentam um dilema familiar:

• Encaminhar tudo para de ponta → qualidade previsível, economia unitária dolorosa em volume.
• Encaminhe tudo para com pesos abertos → custo atrativo, qualidade inconsistente e latência elevada em prompts difíceis.
• Crie roteadores personalizados → flexível, mas você é responsável pela lógica de classificação, failover, reconciliação de faturamento e semântica de cache entre os provedores.

O TrueFoundry AI Gateway fica no meio: mais de 1000 LLMs através de uma API unificada compatível com OpenAI, modelos virtuais com roteamento baseado em peso, cabeçalhos de cache semântico e métricas de preços transparentes para a verdade do faturamento. Queríamos medir se um classificador simples FÁCIL/DIFÍCIL — uma chamada Haiku por solicitação — poderia superar ambos os extremos em custo e qualidade para uma carga de trabalho realista de 20 prompts.

O que comparamos (visão técnica)

Linha de base de pesos abertos: GLM-5.1

GLM-5.1 é o carro-chefe da Z.AI de abril de 2026, acessado via Gateway da TrueFoundry, destinado a trabalhos agentivos de longo prazo — planejamento, uso de ferramentas e loops de codificação multi-etapas.

Linha de base de ponta: Claude Opus 4.7

Opus 4.7 é o modelo de ponta da Anthropic para raciocínio complexo. Nota: O Opus 4.7 usa um novo tokenizador que pode emitir mais tokens do que os modelos Claude mais antigos para o mesmo texto — as comparações de custo devem usar contagens de tokens medidas, não contagens de caracteres.

Roteador classificador em nível de aplicativo

Nosso roteador classifica cada prompt como FÁCIL ou DIFÍCIL em uma única chamada (~8 tokens de saída). FÁCIL → GLM-5.1; DIFÍCIL → Opus 4.7. A pontuação de qualidade usa Claude Sonnet 4.6 como um juiz LLM (1–5 contra rubricas por prompt).

Modelo virtual do Gateway (80/20)

Também testamos um modelo virtual no Gateway configurado para roteamento baseado em peso (80% aberto / 20% de ponta na UI). Isso mede o balanceamento de carga do lado do provedor sem classificação em nível de aplicativo — um "botão" diferente do roteador Haiku.

Sobre nosso benchmark

Prompts: 20 tarefas — 10 rotuladas como fáceis (resumir, formatar JSON, traduzir) e 10 difíceis (tradeoffs de sistemas distribuídos, revisão de injeção SQL, ambiguidade de contrato, depuração de K8s OOM, etc.).

Métricas por estratégia:

O que não afirmamos: pontuações SWE-bench do fornecedor, padrões de tráfego de produção.
‍

Contexto de preços do fornecedor (Maio de 2026)

O GLM-5.1 é aproximadamente 5 vezes mais barato na entrada e cerca de 8 vezes mais barato na saída do que o Opus 4.7 ao preço de tabela — antes de roteamento, cache ou descontos empresariais. A questão interessante é quanto dessa diferença você mantém depois de enviar prompts difíceis para a fronteira.
‍

Nossa análise (execução de 20 prompts)

Custo por 1M de tokens (combinação de tokens desta execução)

‍

Divisão do roteador (classificador)

O roteador Haiku enviou 10/20 prompts para o GLM-5.1 e 10/20 para o Opus 4.7 — uma divisão 50/50 neste conjunto de prompts (10 fáceis + 10 difíceis por design). O volume de tokens seguiu o mesmo padrão: 7.774 tokens no GLM versus 10.072 no Opus para tráfego de conclusão.

As caudas de latência importam

Apenas com pesos abertos teve a p50 mais lento (20.1s) e um extremo p95 (~115s) — uma longa conclusão de GLM num prompt difícil dominou a cauda. Apenas Opus foi o mais rápido no p50 (9.1s) com um p95 moderado (~21s). O classificador ficou no meio no p50 (14.9s) com p95 ~26s.

Qualidade vs custo: o ponto ideal do classificador

• Roteador vs todo Opus: ~31% inferior custo combinado $/1M ($15.72 vs $22.72) com superior pontuação média do avaliador (4.94 vs 4.85). O custo total em dólares para 20 prompts foi essencialmente o mesmo (~$0.28) porque a sobrecarga do avaliador + roteador compensou as economias do GLM — em maior volume, a diferença por token se agrava.
• Roteador vs todo aberto: ~5,2x mais alto $/1M mas +0,19 pontos de qualidade. O mais barato não é o melhor se os prompts complexos importam.
• Virtual 80/20: $7,19 / 1M com base numa estimativa de preço de tabela combinado, mas a qualidade (4,50) ficou atrás de ambas as referências. O roteamento baseado em peso sem reconhecimento de tarefa não é um substituto para a classificação nesta carga de trabalho — valide a mistura real de backends em Gateway Metrics, não apenas o ID do modelo virtual.

Por que estes resultados importam

1. A classificação é barata em comparação com as conclusões de ponta. Uma chamada Haiku por solicitação é ruído em comparação com uma conclusão Opus de 1.024 tokens em tarefas difíceis. A economia do roteador funciona quando o tráfego fácil representa uma grande parte do volume — e quando os roteamentos incorretos são raros.
2. Preço de tabela ≠ sua fatura. O Gateway pode rotear através de diferentes provedores, aplicar cache ou negociar tarifas. Aplicamos os preços de tabela públicos a tokens medidos da nossa execução; você deve conciliar com Gateway Metrics → Baixar Dados Brutos antes de definir as diretrizes de FinOps.
3. Latência e qualidade estão interligadas. Economizar 31% em tokens não ajuda se a latência p95 violar os SLOs. Nosso baseline de peso aberto mostrou que uma única decisão de roteamento ruim (enviar um prompt difícil apenas para GLM) pode disparar a latência de cauda.
4. Dois padrões de roteamento, duas histórias. Nível de app FÁCIL/DIFÍCIL roteamento otimizado para qualidade-custo neste conjunto. Nível de UI modelos virtuais 80/20 otimizados para simplicidade operacional, mas tiveram desempenho inferior em qualidade aqui — úteis para lançamentos graduais, não um substituto completo para roteamento sensível à tarefa.

Lições práticas para equipes de plataforma

1. Comece com um par de modelos de fronteira + peso aberto conectado através de uma única URL base do Gateway. Troque os modelos alterando a string do modelo — sem bifurcação de SDK por provedor.
2. Adicione um classificador barato (Haiku ou similar) antes de adicionar complexidade aos pesos do modelo virtual. Meça a taxa de roteamento incorreto em um subconjunto de prompts de referência.
3. Publique uma lista de níveis de prompts (fácil / difícil) alinhada com suas rubricas — nosso conjunto de 20 prompts é um modelo, não sua distribuição de produção.
4. Reconcilie os custos nas Métricas do Gateway, não em estimativas de notebook. Exporte o CSV de faturamento bruto e faça a junção com os metadados de rastreamento.
5. Adicione cache semântico depois que o roteamento estabilizar — o cache semântico em prompts fáceis e parafraseados é onde o ROI do cache geralmente aparece (não medido nesta execução de baseline).

Como o TrueFoundry AI Gateway tornou isso possível

• API unificada compatível com OpenAI — um cliente, base_url apontado para o Gateway; o mesmo caminho de código para GLM, Opus, Haiku e Sonnet.
• Modelos virtuais — roteamento 80/20 baseado em peso sem alterações na aplicação (documentação).
• Cache semântico — reutilização de resposta baseada em similaridade (documentação).
• Observabilidade — uso de token, latência e cabeçalhos de custo para reconciliação; ~3–4 ms de latência e mais de 350 RPS em 1 vCPU na camada de gateway para cenários de proxy de alto rendimento.

Conclusão

Modelos de peso aberto como GLM-5.1 têm preços para atrair tráfego fácil. Claude Opus 4.7 ainda se mantém relevante em prompts difíceis. A diferença entre eles é grande o suficiente para que o roteamento importa mais do que o marketing do modelo.

Em nosso teste de 20 prompts através TrueFoundry AI Gateway, um roteador classificador Haiku apresentou o melhor cenário combinado: ~31% menor custo combinado por milhão de tokens do que o Opus puro, com uma maior pontuação média dos avaliadores (4,94 vs 4,85). A abordagem totalmente aberta permaneceu como o piso de custo; o Opus completo, o teto de qualidade e velocidade para a latência p50.

‍