Primeiro a configuração, porque foi aí que isto descarrilou. Peguei no prompt exato por trás da nossa demo de voz de marca na landing page, aquela que lê alguns dos seus posts e escreve um novo na sua voz, e corri-o em três modelos: o Sonnet 4.6 da Claude (o que usamos em produção), o DeepSeek e o GLM. Seis amostras de voz diferentes, cada uma duas vezes, cada resultado anonimizado avaliado por um juiz cego. A pergunta tinha dinheiro a sério por trás: será que um modelo mais barato conseguiria fazer este trabalho tão bem como o Sonnet, ou melhor?
Corri isto de três formas, e as três execuções discordaram de forma tão completa que "qual modelo" acabou por ser a pergunta errada. Ronda a ronda.
Ronda 1: trocar a string do modelo
Este é o teste que a maioria das pessoas realmente faz. As mesmas definições da produção, apenas um nome de modelo diferente.
| Modelo | JSON válido | Latência | Custo/geração |
|---|---|---|---|
| Sonnet 4.6 | 12/12 | 7.9s | $0.0079 |
| DeepSeek | 4/12 | 22.7s | $0.0013 |
| GLM | 0/12 | 26.7s | $0.0041 |
O GLM produziu zero resultados utilizáveis. O DeepSeek produziu quatro. Não porque sejam modelos maus, mas porque ambos são "reasoning-first": dentro do orçamento de tokens de produção, pensam em voz alta ("1. Let me analyze the posts...") e ficam sem espaço antes de emitirem o JSON de que a página precisa. A troca ingénua não entrega uma demo pior. Entrega uma demo avariada. Se eu tivesse decidido por uma verificação pontual de dois resultados, teria aprendido isso através dos utilizadores.
Ronda 2: dar-lhes espaço
Os mesmos modelos, mas com o modo JSON ativado e um orçamento de tokens maior, para que os modelos de raciocínio possam terminar o seu pensamento.
| Modelo | JSON válido | Latência | Pontuação do juiz |
|---|---|---|---|
| Sonnet 4.6 | 12/12 | 7.7s | 3.37 |
| DeepSeek | 11/12 | 43s | 4.33 |
| GLM | 12/12 | 44s | 4.73 |
O quadro inverte-se. Com espaço para terminar, os dois concorrentes emitem JSON válido, e o juiz avalia a correspondência de voz deles ao nível do Sonnet ou acima. Portanto, os modelos em si nunca foram o problema; o problema foi o primeiro teste. Mas repare na latência. Mais de 40 segundos. Ninguém espera 44 segundos por uma demo de landing page. Ótimo resultado, funcionalidade inutilizável.
Ronda 3: a versão que realmente colocaria em produção
Modo JSON ativado, raciocínio desligado, DeepSeek no seu endpoint rápido.
| Modelo | JSON válido | Latência | Custo/geração | Pontuação do juiz |
|---|---|---|---|---|
| Sonnet 4.6 | 12/12 | 8.7s | $0.0079 | 3.17 |
| DeepSeek (rápido) | 12/12 | 2.8s | $0.00019 | 4.10 |
| GLM (sem raciocínio) | 12/12 | 9.0s | $0.0017 | 4.77 |
Com a engenharia certa, ambos se tornam genuinamente viáveis. O endpoint rápido do DeepSeek respondeu em 2,8 segundos, mais rápido que o Sonnet, a cerca de um quinquagésimo do custo, com JSON válido em todas as vezes. O GLM igualou a velocidade do Sonnet a um quinto do custo e obteve a pontuação mais alta do juiz. As amostras confirmaram os números. O GLM acertou em cheio numa despedida de um criador de conteúdo ("currently romanticizing my overpriced matcha, and I will not be taking questions"), e as amostras bilingues voltaram corretamente em italiano nos três modelos.
O que eu realmente aprendi
O modelo foi a variável menos interessante. Os mesmos três modelos passaram de avariados a melhores-que-o-modelo-atual sem mudar o modelo em nada, apenas a engenharia à sua volta. O orçamento de tokens, o modo JSON e se o raciocínio estava ligado ou desligado importaram mais do que qual laboratório treinou a coisa. Todo o exercício foi um lembrete de que "basta trocar para o modelo mais barato" é uma frase que esconde toda a engenharia real.
Uma ressalva, porque o juiz também não era perfeito. Detetou corretamente que o Sonnet envolve o seu JSON em blocos markdown, o que é real e é a razão pela qual a produção tem um removedor desses blocos. Mas também alucinou violações de travessão em resultados que não continham nenhum travessão. Por isso, confio mais nas amostras que analisei a olho do que nas pontuações decimais exatas. A direção é sólida; a terceira casa decimal não é.
A decisão prática? Para esta demo em particular, a despesa é insignificante, por isso o Sonnet mantém-se como opção segura por defeito, e o endpoint rápido do DeepSeek é o upgrade a que recorreria primeiro. As verdadeiras poupanças não estão aqui, de qualquer forma. Estão nas funcionalidades de alto volume que correm milhares de vezes por dia, onde ser 50 vezes mais barato deixa de ser um erro de arredondamento. Esse é o teste que vale a pena correr a seguir.
Se levar uma coisa disto: antes de trocar um modelo para poupar dinheiro, corra-o através da engenharia exata onde ele vai viver. O modelo que pensa estar a testar não é o que os seus utilizadores recebem.