Quando vale trocar de provedor de LLM (e quando não)
Premissa
Este post não se apoia em benchmark específico de provedor, número de custo publicado ou caso real documentado — não havia fonte verificável disponível para esta pauta. O que segue é uma análise de critérios de engenharia, do tipo que você aplicaria para qualquer decisão de troca de fornecedor crítico (banco de dados, fila, cloud). Se você está decidindo uma migração real, rode seus próprios testes de carga, custo e qualidade com os provedores candidatos antes de aplicar qualquer conclusão daqui.
Tese
Trocar de provedor de LLM vale a pena quando o motivo é estrutural — custo por token em escala, limite de contexto, SLA de disponibilidade, requisito de residência de dados ou uma lacuna de capacidade que afeta o produto. Não vale a pena quando o motivo é tático — um benchmark isolado, uma promessa de marketing, ou a sensação de que "o modelo novo é mais esperto" sem medição no seu próprio caso de uso.
A diferença entre as duas situações é simples de enunciar e difícil de aplicar sob pressão: motivo estrutural tem métrica associada e comparação reprodutível; motivo tático é anedota.
Razões para trocar
Custo em escala muda o P&L, não só a fatura. Se o seu volume de chamadas já é alto o suficiente para que o custo por token vire linha relevante de orçamento, uma diferença de preço entre provedores comparáveis compensa o esforço de migração. Abaixo de um certo volume, o tempo de engenharia gasto na troca custa mais do que a economia gerada — então a pergunta certa não é "qual é mais barato", é "em que volume a diferença de preço supera o custo de migrar e manter dois integrações durante a transição".
Limite de contexto e capacidades específicas bloqueiam features. Se o seu produto depende de processar documentos longos, multimodalidade, function calling com schema mais rico ou latência abaixo de um teto específico, e o provedor atual não atende isso de forma alguma, não existe otimização que resolva — é troca ou é renunciar à feature.
Disponibilidade e SLA são requisito de produto, não preferência. Se o seu caso de uso tem SLA contratual com seus próprios clientes e o provedor atual tem histórico de instabilidade incompatível com esse SLA, a decisão de trocar é sobre risco operacional, não sobre preço ou qualidade de resposta. O conceito de orçamento de erro associado a um SLO, descrito no SRE Book do Google, é uma referência útil para formalizar esse limite antes de decidir.
Residência de dados e compliance são restrições, não trade-offs. Se regulação ou contrato exige que dados não saiam de uma região ou não passem por determinado processamento, e o provedor atual não oferece essa garantia, não há meio-termo possível.
Lock-in por dependência de feature proprietária cresce com o tempo. Quanto mais sua aplicação depende de recursos específicos de um provedor (fine-tuning proprietário, formato de prompt particular, embeddings amarrados ao mesmo fornecedor), maior o custo de sair depois. Se você já percebe essa dependência crescendo e ainda está em fase de decidir arquitetura, trocar agora é mais barato do que trocar daqui a um ano.
Contraponto: quando não vale
Resultado de benchmark público não é o seu caso de uso. Rankings genéricos de qualidade de modelo medem tarefas padronizadas, não o seu prompt, seu domínio, nem o seu formato de saída esperado. Um modelo que pontua melhor em benchmark pode performar pior no seu pipeline específico, e isso só aparece com comparação direta no seu próprio tráfego — rodando os modelos candidatos em paralelo sobre a mesma amostra de prompts reais e medindo taxa de erro e retrabalho, não em um teste de conversão genérico.
Migração técnica tem custo real que raramente aparece no plano inicial. Trocar de provedor de LLM normalmente significa: reescrever ou ajustar prompts (modelos diferentes respondem de forma diferente ao mesmo prompt), revalidar comportamento em casos de borda, ajustar parsing de saída se o formato de resposta mudar, e rodar um período de operação paralela para comparar qualidade e custo antes de desligar o antigo. Subestimar esse esforço é o erro mais comum nesse tipo de decisão — o padrão de migração incremental descrito por Martin Fowler como Strangler Fig Application é um bom modelo mental para essa operação paralela.
Dependência de uma API compatível não elimina o trabalho de validação. Mesmo quando a interface de chamada é parecida entre provedores, o comportamento do modelo por trás não é. Trocar o endpoint sem revalidar qualidade de resposta é trocar um problema conhecido por um desconhecido.
Decisão unilateral de quem não opera o sistema no dia a dia é bandeira vermelha. Se a motivação para trocar vem de pressão externa (uma manchete, um anúncio de lançamento) e não de quem lida com os logs de erro, latência e custo do sistema em produção, vale desacelerar e pedir os números antes de aprovar a migração.
Condições que mudam a posição
Essa análise muda se o seu sistema ainda está em protótipo ou validação de produto. Nessa fase, o custo de trocar é baixo (pouco código, pouco tráfego em produção, nenhum SLA em jogo), então testar múltiplos provedores em paralelo é barato e recomendável — é exatamente o momento de não se comprometer cedo demais com um único fornecedor.
Também muda se você já projetou a arquitetura com uma camada de abstração entre aplicação e provedor (um gateway de LLM, uma interface própria que normaliza chamadas e parsing de saída). Nesse caso, o custo de troca cai significativamente, e vale reavaliar provedores com mais frequência, porque o risco de lock-in já foi mitigado por design — com a ressalva de que essa abstração tem seu próprio custo de manutenção e pode esconder diferenças reais de comportamento entre modelos atrás de uma interface uniforme demais, adiando um problema de qualidade em vez de eliminá-lo.
Decisão prática
Antes de abrir uma migração, escreva três números: custo mensal atual por volume de uso, latência média e p95 medidos no seu tráfego real, e taxa de erro ou retrabalho de qualidade de resposta no seu caso de uso específico. Rode o provedor candidato em paralelo, com os mesmos prompts e o mesmo volume de amostra, e compare os mesmos três números antes de decidir. Se a diferença não for clara nessas três métricas, a troca provavelmente não vale o esforço — e se for clara, você já tem os dados para justificar a decisão para quem aprova o orçamento.