Por Que a Consistência da Inferência Serverless Varia Tanto no Mesmo Modelo

Imagine o seguinte cenário: você seleciona um LLM para sua aplicação, testa em um sandbox de inferência serverless, tudo funciona perfeitamente. Então migra para produção em outro provedor — e a acurácia, o tempo até o primeiro token (TTFT) e o throughput despencam. Era o mesmo modelo. O que aconteceu?

A resposta está nas decisões de infraestrutura que os provedores tomam nos bastidores — e que raramente documentam. Este artigo explica o que realmente está sob o capô e como medir a consistência antes de comprometer um modelo em produção.

As decisões invisíveis dos provedores

Provedores de inferência serverless fazem escolhas cruciais por modelo: quantas réplicas manter aquecidas, qual precisão numérica usar (BF16, FP8, INT4), em qual tier de GPU rodar (H100, A100, MI300X) e qual runtime de serving empregar (vLLM, TensorRT-LLM, SGLang). Cada decisão afeta diretamente a latência e a consistência que você experimenta.

O fator determinante por trás dessas escolhas é a popularidade percebida do modelo. Modelos com tráfego alto e consistente justificam múltiplas réplicas aquecidas. Modelos de nicho podem ter zero réplicas fora de picos, forçando cold starts de 10 a 90 segundos quando uma requisição chega.

O impacto real dos cold starts

Cold starts são o principal motor da variância de latência. Um modelo pode ter TTFT mediano de 0,4 segundos — porque a maioria das requisições atinge uma réplica quente — mas um percentil 95 (p95) que excede 6 segundos, já que uma em cada vinte requisições dispara um cold start. Medir apenas a mediana mascara completamente esse comportamento.

Os testes internos citados no artigo revelaram diferenças alarmantes. O DeepSeek V4 Pro apresentou coeficiente de variação (CV) de 21% em uma plataforma e 710% em outra — uma diferença de 34 vezes na consistência. O mesmo modelo, o mesmo nome, mundos diferentes.

Quantização, GPUs e runtimes

A quantização é uma faca de dois gumes. BF16 preserva os pesos originais, mas consome mais memória. FP8 e INT8 reduzem o consumo pela metade com degradação mínima. INT4 corta ainda mais, mas pode afetar a qualidade em benchmarks de raciocínio. Provedores raramente publicam qual precisão usam para cada modelo.

O hardware também importa. Um modelo servido em H100 NVL pode ter TTFT 2–3 vezes menor que em A100 80GB. E o runtime de serving — vLLM, TensorRT-LLM ou kernels customizados — produz perfis de throughput e latência significativamente diferentes para os mesmos pesos.

Batching e tráfego

Sob carga, provedores agrupam múltiplas requisições em batches para melhorar a utilização de GPU. Modelos populares com tráfego previsível fazem batch eficientemente. Modelos de nicho com tráfego esparso e irregular formam batches ruins, e uma requisição pode ficar na fila atrás de batches de modelos populares — adicionando latência indistinguível de ruído de cold start.

Como medir antes de comprometer

A lição principal é: não existe um único “melhor” provedor para todos os modelos. A qualidade do serving varia por plataforma e por modelo dentro da mesma plataforma. Um catálogo com 400 modelos não significa que todos recebem o mesmo investimento em infraestrutura.

Para medir com confiança, execute benchmarks com prompts fixos e temperatura zero, medindo não apenas a mediana mas também p95 e p99 de TTFT e throughput. Execute os testes em horários diferentes para capturar variações de carga. Compare o mesmo modelo em múltiplos provedores antes de decidir. A documentação do provedor raramente conta a história completa — seus próprios números sim.