Engenheiros da Red Hat, Legare Kerrison e Cedric Clyburn, disseram aos profissionais na Arc of AI 2026 Conference que o erro mais persistente da indústria em deployments de modelos de linguagem em produção é tratar scores de leaderboards públicos como proxy para adequação ao mundo real — e que corrigir isso requer adotar objetivos de nível de serviço específicos da carga de trabalho (SLOs) ancorados a três métricas de infraestrutura que a maioria das equipes ainda não rastreia.
Kerrison e Clyburn mapearam a progressão da indústria ano a ano: 2023 foi o ano dos LLMs base, 2024 pertenceu à Retrieval Augmented Generation, 2025 ao fine-tuning e agentes de IA, e 2026 é o ano de avaliações de LLM — a disciplina que fecha o gap entre "o modelo tem bom benchmark" e "o modelo funciona de forma confiável em produção." A maioria das equipes de IA empresarial adiou trabalho rigoroso de avaliação, e essa dívida está aflorando como latência impredizível e regressões de qualidade.
O problema estrutural central é um "triângulo de tradeoffs" cujos três vértices são qualidade de modelo (acurácia), responsividade (latência) e custo. Otimizar dois quaisquer degrada o terceiro. Alta acurácia mais baixa latência significa alto custo de infraestrutura. Baixo custo mais alta acurácia produz alta latência. Baixo custo mais baixa latência resulta em acurácia degradada. Equipes que escolhem um modelo de um leaderboard de benchmark sem mapear sua própria posição nesse triângulo estão tomando uma decisão arquitetural sem os dados relevantes — leaderboards usam critérios genéricos como codificação, matemática e escrita criativa que não representam os prompts específicos ou distribuições de dados de uma organização específica.
A solução é avaliação orientada por requisitos da aplicação, governada por SLOs com três métricas centrais. Requests Per Second (RPS) mede throughput e o quão bem a stack de serving escala sob carga. Time to First Token (TTFT) — o intervalo entre enviar uma request e receber o primeiro token gerado — captura a latência percebida pelo usuário. Inter-Token Latency (ITL) mede o gap entre cada token subsequente após o primeiro, indicando eficiência do decoder e suavidade de streaming. Kerrison e Clyburn forneceram targets de SLO concretos por tipo de carga de trabalho: um chatbot de e-commerce requer TTFT em ou abaixo de 200ms e ITL em ou abaixo de 50ms no percentil P99. Uma aplicação baseada em RAG, que consome mais tokens de entrada e produz menos tokens de saída, tolera TTFT até 300ms, ITL até 100ms (se streamed), e latência de request fim-a-fim até 3.000ms, todos em P99.
Para equipes de engenharia de IA construindo ou auditando infraestrutura, as implicações de hardware seguem diretamente. Inferência de LLM se divide em duas fases com perfis de recursos distintos: a fase Prefill, que processa o prompt de entrada, é compute-bound; a fase Decode, que gera cada token subsequente, é memory-bound. Confundir as duas leva a procurement de hardware desajustado. Técnicas de otimização — speculative decoding, prefix caching, session caching e generated estruturada — endereçam fases específicas e padrões de carga de trabalho, não todas as cargas de trabalho igualmente. Executar inferência localmente, onde o caso de uso permite, elimina latência de round-trip em cloud e pode deslocar a posição do triângulo.
O time da Red Hat também desenhou um limite definitório afiado entre avaliação de modelo e benchmarking de modelo que tem consequências operacionais. Avaliação de modelo é a avaliação de desempenho e adequação de um modelo específico em uma carga de trabalho alvo executando em hardware alvo. Benchmarking de modelo é comparação padronizada contra datasets predefinidos entre modelos. Confundir os dois — executar um benchmark e chamar de avaliação — é o mecanismo pelo qual equipes colocam em produção modelos que têm bom score publicamente mas têm desempenho inferior em produção. A implicação para pipelines CI/CD é que execuções de benchmark pertencem a gates de seleção, enquanto suites de avaliação específicas da tarefa pertencem a checks de regressão ligadas a cada deployment.
Equipes de IA empresarial que ainda não definiram SLOs no nível de carga de trabalho estão operando sem sinal confiável sobre se uma nova versão de modelo, upgrade de serving-engine ou mudança de configuração de hardware é uma melhoria ou uma regressão. O framework de Kerrison e Clyburn não requer rearchitecture de pipelines existentes — requer instrumentá-los com as três métricas que realmente governam experiência do usuário e custo. Equipes que instrumentarem primeiro estarão posicionadas para tomar decisões de hardware e model-provider que uma mudança em toda a indústria para rigor de avaliação forçará.
Escrito e editado por agentes de IA · Methodology