Nenhuma decisão no stack de inferência move um eixo só. Subir para o modelo maior melhora a qualidade, dobra a fatura e puxa a latência junto. Descer para o menor corta custo, piora as respostas e devolve a economia em retrabalho.
São quatro eixos acoplados: latência, qualidade, custo e confiabilidade. Cada knob do stack de inferência paga em um eixo para comprar outro.
Este artigo é o mapa: define os quatro eixos e o vocabulário que o resto da série reutiliza sem redefinir.
Eixo 1: latência
A latência de um LLM se mede em pelo menos três números, cada um com causa própria. As definições abaixo seguem a documentação de benchmarking da Anyscale.
TTFT (time to first token) é o tempo até o primeiro token chegar. Três fatores dominam: o tamanho do prompt, a fila no servidor e a fase de prefill. No prefill, o modelo processa o prompt inteiro e monta o KV cache, a memória de curto prazo da sessão.
TPOT (time per output token) e ITL (inter-token latency) medem o ritmo dos tokens depois que a geração começa. Valores baixos e constantes dão fluidez ao streaming. Valores altos ou instáveis fazem o texto chegar em rajadas.
Latência E2E (end-to-end) é a soma: prefill mais um passo de decode por token de saída.
E2E = TTFT + decode phase
TPOT = (E2E latency - TTFT) / (output tokens - 1)
A média esconde os casos ruins. Por isso a medição usa percentis: p50 é a experiência típica, p95 é o usuário azarado, p99 é o quase pior caso. SLA de produção se define em p95 ou p99, não em média.
Prefill e decode têm perfis de hardware opostos, e essa diferença explica boa parte do stack de inferência. O próximo artigo da série abre essa caixa.
Eixo 2: qualidade
Qualidade é o eixo sem unidade universal. A medida real é um eval: um conjunto de tarefas com critério de acerto, rodado contra o seu caso de uso.
Na falta do seu eval, a indústria usa índices públicos como proxy. O exemplo mais citado é o Intelligence Index da Artificial Analysis. A versão atual combina nove avaliações em quatro grupos: agentes (GDPval-AA v2, Tau3-Banking), código (Terminal-Bench v2.1, SciCode), geral (AA-LCR, AA-Omniscience) e raciocínio científico (HLE, GPQA Diamond, CritPt).
O AA-Omniscience pesa 12% do índice, dividido em duas partes: 8% para acurácia e 4% para taxa de não alucinação. Responder errado perde ponto. Abster-se, não. Qualidade em 2026 inclui saber quando não responder.
Índice público mede o modelo em tarefas genéricas. O seu produto depende do modelo na sua tarefa. A distância entre os dois só aparece com eval próprio, assunto de um artigo futuro da série.
Eixo 3: custo
Custo de API se mede em dólares por milhão de tokens (MTok), com preços separados para entrada e saída. Tabela da Anthropic, em julho de 2026:
| Modelo | Input / MTok | Output / MTok |
|---|---|---|
| Claude Haiku 4.5 | $1 | $5 |
| Claude Sonnet 5 (até 31 ago 2026) | $2 | $10 |
| Claude Sonnet 5 (a partir de 1 set 2026) | $3 | $15 |
| Claude Opus 5 | $5 | $25 |
| Claude Fable 5 | $10 | $50 |
O catálogo da OpenAI tem a mesma estrutura. No tier standard, faixa de contexto curto: gpt-5.4-nano a $0,20/$1,25, gpt-5.4-mini a $0,75/$4,50, gpt-5.6-luna a $1/$6, gpt-5.6-terra a $2,50/$15, gpt-5.6-sol a $5/$30.
Duas leituras nossas dessas tabelas. Primeira: a saída custa 5x a entrada na Anthropic e 6x na OpenAI. Segunda: a régua entre o menor e o maior modelo passa de uma ordem de grandeza: 10x na Anthropic, 25x na OpenAI.
A assimetria entrada/saída define estratégia. Aplicações de contexto longo e resposta curta gastam quase tudo em entrada. É onde os descontos moram:
- Prompt caching: leitura de cache a 0,1x o preço de entrada, nos dois provedores. A escrita custa 1,25x (cache de 5 minutos) ou 2x (cache de 1 hora) na Anthropic. Na faixa de contexto curto dos gpt-5.6, a OpenAI lista escrita a 1,25x.
- Batch API: 50% de desconto em entrada e saída na Anthropic, para processamento assíncrono.
Eixo 4: confiabilidade
Confiabilidade é o eixo que só aparece em produção. A documentação de erros da Anthropic lista os modos de falha que o seu código precisa tratar:
429 rate_limit_error -> your account hit a rate limit
500 api_error -> retry with exponential backoff
504 timeout_error -> consider streaming for long requests
529 overloaded_error -> API temporarily overloaded
O 529 é o mais instrutivo. A Anthropic nota que ele pode ocorrer quando a API recebe tráfego alto de todos os usuários. Ou seja, uma falha que não depende do seu código. Sua arquitetura precisa de um plano para o dia em que o provedor degrada.
Há também limites de aceleração: em casos raros, um crescimento brusco de uso pode gerar 429. A recomendação da Anthropic é subir o volume gradualmente.
Confiabilidade também tem preço de tabela. O Priority Tier da Anthropic vende prioridade de processamento com meta de 99,5% de uptime, mediante compromisso de capacidade por contrato. Novos compromissos não estão mais à venda, mas o desenho mostra o ponto: uptime acima do best-effort é produto, não default.
Todo knob move mais de um eixo
Cada mecanismo do stack de inferência é uma troca entre eixos, com taxas de câmbio publicadas em tabela de preço.
| Mecanismo | Você paga com | Você compra |
|---|---|---|
| Modelo menor | qualidade | custo por token até 25x menor |
| Fast mode | custo (2x) | velocidade de saída (até 2,5x) |
| Batch API | latência (até 24h) | custo (50% de desconto) |
| Prompt caching | escrita a 1,25x, prefixo estável | custo (0,1x), TTFT menor, alívio de rate limit |
| Retry com backoff | latência | confiabilidade |
| Fallback de modelo | qualidade, às vezes | confiabilidade |
Três linhas merecem zoom.
Fast mode é a troca mais pura. O fast mode da Anthropic (research preview) entrega até 2,5x mais tokens de saída por segundo no Claude Opus 5 e no Opus 4.8. Mesmo modelo, mesma qualidade. O preço: $10/$50 por MTok, o dobro da tarifa padrão do Opus 5. É latência comprada com dinheiro, sem tocar nos outros eixos.
Batch é a troca inversa. Você abre mão de resposta imediata: a maioria dos lotes termina em até 1 hora. O resultado sai quando tudo completa, ou em 24 horas, o que vier primeiro. Em troca, metade do preço. A Anthropic descreve o batch como capacidade fora da sua cota normal, o que também alivia o eixo de confiabilidade do tráfego interativo.
Prompt caching é o raro ganho triplo. Leitura a 0,1x corta custo. O reuso do prefill melhora o TTFT em documentos longos. E, na Anthropic, cache hit não desconta do rate limit, o que estica sua capacidade. O pagamento é disciplina de engenharia: o cache cobre o prefixo exato do prompt (tools, system e messages, nessa ordem). Qualquer mudança nesse prefixo derruba o reuso. Os artigos sobre KV cache e caching da série destrincham isso.
Modelos de raciocínio adicionam um knob transversal: mais tokens de pensamento antes da resposta final. Esses tokens custam dinheiro e tempo, comprando qualidade em tarefas difíceis. É a mesma troca dos outros knobs, dentro de uma única chamada.
O stack inteiro, camada por camada
Os knobs acima são a camada visível. As trocas existem em todas as camadas do stack de inferência:
Application -> routing, fallback, retries, evals
Provider API -> caching, batch, fast mode, service tiers
Serving -> continuous batching, paged attention, speculative decoding
Model -> size, quantization, distillation, reasoning effort
Hardware -> GPUs, memory, interconnect
A física é a mesma em todas. Modelos maiores têm forward pass mais longo e geram menos tokens por segundo. Servidores sob carga enfileiram requests e inflam o TTFT. Quantização economiza memória e pode custar qualidade. A série vai descer o stack camada por camada, com esses quatro eixos como régua.
O provedor também vive esse conflito, e contra você. A taxa de transferência do sistema (system TPS) sobe com mais requests simultâneos no mesmo hardware. A sua velocidade individual (user TPS) tipicamente cai pelo mesmo motivo.
Como medir: SLO e goodput
O erro clássico no stack de inferência é otimizar um eixo sem medir os outros. A ferramenta contra isso é o goodput: a porcentagem de requests que cumprem todos os seus SLOs ao mesmo tempo.
Goodput = requests meeting all SLOs / total requests * 100%
Example SLOs: TTFT < 500ms, TPOT < 15ms, E2E < 2s
Um sistema pode exibir throughput alto com goodput caindo: sob carga crescente, a latência degrada antes de a vazão parar de subir. Throughput mede o quanto o sistema trabalha. Goodput mede o quanto desse trabalho presta.
Defina SLO por caso de uso, não por sistema. Chat interativo exige TTFT baixo. Pipeline noturno tolera horas, e por isso o batch existe. O mesmo produto pode ter os dois perfis em endpoints diferentes.
O vocabulário desta série
Estes termos voltam nos próximos artigos, sem redefinição:
| Termo | Definição curta |
|---|---|
| TTFT | tempo até o primeiro token da resposta |
| TPOT / ITL | intervalo entre tokens depois que a geração começa |
| Prefill | fase que processa o prompt inteiro e monta o KV cache |
| Decode | fase que gera a saída, um token por passo |
| KV cache | estado de atenção reutilizado entre passos e requests |
| MTok | milhão de tokens, unidade de preço das APIs |
| p50 / p95 / p99 | percentis de latência: típico, azarado, quase pior caso |
| Goodput | fração de requests que cumprem todos os SLOs |
| Rate limit | teto de tokens ou requests por janela de tempo |
| Fallback | rota alternativa de modelo ou provedor em falha |
O ponto central
Latência, qualidade, custo e confiabilidade formam um sistema acoplado no stack de inferência. Os provedores publicam as taxas de câmbio: 2x o preço por 2,5x a velocidade. 50% de desconto por até 24 horas de espera. Leitura a 0,1x em troca de disciplina de prefixo.
Escolher modelo é só a primeira dessas trocas. Engenharia de inferência é decidir, com números, qual eixo paga a conta de qual. O resto da série mostra onde cada troca acontece no stack de inferência, começando pela mais fundamental: prefill contra decode.
Fontes:





Deixe um comentário