Capítulo 14 — Benchmarking, Testes e Desempenho

Décima quarta e última postagem do passeio capítulo a capítulo pelo LLM Primer IV: Projetando a Cognição da IA com MCP. Em que a arquitetura finalmente tem que responder à pergunta sem sentimentos — o sistema de fato funciona? — e a resposta chega através de benchmarks reais, dois modos de falha sistêmicos, e um precipício de throughput de dez vezes que a maioria dos times descobre no dia do rollout em produção.

Por que este capítulo existe

Um protocolo cuidadosamente desenhado, endurecido com segurança e limpo dentro de um framework ainda tem que responder à pergunta sem sentimentos: o sistema de fato funciona? O agente resolve as tarefas para as quais foi construído? Ele aguenta quando a carga dobra? Onde estão os precipícios de desempenho que transformam degradação graciosa em queda? Os capítulos anteriores foram sobre acertar a arquitetura; este é sobre medir se a arquitetura, uma vez construída, entrega. Ele percorre o MCP-Universe Benchmark — o primeiro harness público de teste exercitando LLMs reais contra servidores MCP reais — os dois modos de falha sistêmicos que o benchmark descobriu e as mitigações que começaram a funcionar, e o lado de throughput onde o gap entre um pool de sessão bem-engenheirado e o padrão ingênuo por-requisição é uma ordem de grandeza.

14.1 MCP-Universe: medindo agentes em servidores reais

Por boa parte de 2024 e início de 2025, a avaliação pública de agentes vivia num lugar estranho. Benchmarks de uso de tool mediam se modelos emitiam chamadas sintaticamente corretas contra APIs sintéticas. Benchmarks de agente mediam conclusão de tarefa em ambientes sandbox. O que faltava era um benchmark exercitando modelos contra servidores MCP reais com autenticação real, rate limits reais, schemas reais que derivam, tools reais que ocasionalmente retornam resultados vazios. MCP-Universe, lançado pela Salesforce AI Research em 2025, foi a primeira tentativa séria. Seis domínios de avaliação cobrindo onze servidores MCP de produção reais — Google Maps, GitHub, Yahoo Finance, Blender, Playwright, motores de busca reais — e 231 tarefas, cada uma com um avaliador automatizado que checa se o estado final combina com o resultado esperado em vez de checar se o modelo emitiu as chamadas de tool "certas" no caminho.

O resultado de manchete se sustentou através de refreshes de modelo. Claude 3.5 Sonnet, que pontua nos oitentas em benchmarks sintéticos, atingiu só os quarentas baixos-a-médios no MCP-Universe geral. GPT-4o, Gemini 1.5 Pro e as variantes Llama-3 70B agruparam-se em território similar. O gap entre desempenho de uso de tool em curso fechado e desempenho em MCP real foi de aproximadamente quarenta pontos absolutos, e escala sozinha não o fechou. As falhas se agrupam em categorias reconhecíveis: degradação de contexto longo conforme saídas de tool enchem a janela; exploração de tool desconhecida conforme o modelo lê errado schemas não familiares; coordenação entre servidores onde formatos de saída não casam e nenhuma ponte semântica existe; e raciocínio específico de tarefa onde o modelo seleciona a tool certa, a chama certa, recebe a resposta certa, e ainda chega à conclusão final errada porque falhou em integrar a saída de tool no raciocínio mais amplo. As decisões estruturais que tornam o MCP-Universe instrumento sério são avaliação baseada em execução (rodar chamadas contra servidores reais, não comparar contra um trace de referência), dados em tempo real (dados de mercado ao vivo, com o avaliador rastreando qual era a resposta na hora da run), e avaliação multi-turno (avaliar o estado final, não cada passo). Um efeito colateral útil: o benchmark opera como sinal indireto de qualidade no design de servidor, e autores de servidor que se importam com desempenho de agente agora têm um alvo público.

14.2 Os dois desafios sistêmicos e o que funciona

Degradação de contexto longo e exploração de tool desconhecida são os dois modos de falha grandes o suficiente para merecer tratamento cuidadoso, porque as mitigações não são óbvias. Degradação de contexto longo em agentes MCP tem formato específico: o contexto enche com saídas de tool que são todas relevantes em algum sentido — cada uma foi resultado de uma chamada que o modelo escolheu fazer — mas cada uma é volumosa e o fato carregador dentro de cada uma é pequeno. As mitigações operam no nível de apresentação de informação. Sumarização de resultado de tool roda um modelo barato (Haiku, GPT-4o-mini, Gemini Flash) sobre a saída crua de tool antes que o resultado aterrisse no contexto do agente; deployments em produção relatam melhoria de duas a três vezes em taxas de conclusão de contexto longo e o custo por chamada é dominado pelo modelo barato. Saída estruturada de tool com um campo summary ao lado do payload JSON — formalizada na revisão de protocolo de 2025 — faz trabalho similar sem a chamada extra de modelo. Compactação de contexto no loop de agente, emparelhada com um scratchpad gerenciado pelo agente que sobrevive a compactação literalmente, trata o caso em que a própria conversa ficou longa demais; deployments em produção disparam compactação a cada vinte a quarenta passos e preservam aproximadamente um terço do contexto original.

Exploração de tool desconhecida tem formato diferente. Quando um agente se conecta a um servidor com tools nas quais não foi treinado, as primeiras chamadas do modelo frequentemente falham — tipos errados, ordem errada, às vezes tool inteiramente errada. A mitigação é uma fase de exploração antes do loop principal: o framework pede ao modelo para ler a descrição de cada tool, resumir o que ela faz, gerar uma invocação de exemplo, e sinalizar parâmetros sobre os quais está inseguro. A nota resultante é prefixada no contexto do agente. O custo é algumas chamadas baratas no início de sessão; o benefício é vinte a trinta pontos percentuais de melhoria de conclusão em benchmarks como MCP-Universe e um registro auditável do entendimento declarado do agente que ajuda a atribuir falhas posteriores. O padrão se estende a tools mudadas: hasheie a superfície de tool na conexão, rode o aquecimento sempre que o hash mudar, e o modo de falha silencioso de deriva (servidor atualizado, agentes falham por semanas antes que alguém perceba) desaparece. Uma terceira questão relacionada que vale nomear: qualidade de descrição de tool. Muitos servidores embarcaram descrições escritas para desenvolvedores humanos — concisas, cheias de jargão, assumindo contexto. Servidores reescritos como se para um estagiário que nunca viu o sistema mostram melhorias mensuráveis contra os mesmos modelos sem mudança de código de agente. A única janela do modelo para a tool é a descrição, e uma descrição que não se sustenta sozinha produz um modelo que não consegue usar a tool.

14.3 O precipício de throughput do pool de sessão

Correção é metade da história; a realidade de produção é que as escolhas de design que tornam um agente rápido frequentemente têm implicações de correção e vice-versa. O maior problema único de throughput em deployments MCP em 2025–2026 é o gap entre dois jeitos de gerenciar sessões Streamable HTTP, e o gap é por volta de dez para um. Sessão-por-requisição abre uma nova sessão por requisição de agente, roda chamadas de tool dentro dela, fecha na conclusão. Pool-de-sessão-compartilhado mantém um pool de sessões de vida longa e atribui cada requisição a uma do pool. A diferença de throughput num servidor padrão com workload representativo aterrissa consistentemente em torno de dez vezes — grosso modo trinta requisições por segundo para sessão-por-requisição, grosso modo 290 a 300 para o pool, em hardware commodity. Times que ignoram o gap o descobrem do jeito difícil: staging roda bem, rollout em produção bate em parede na taxa de requisição onde o overhead de criação de sessão domina.

O mecanismo é direto. Criação de sessão é cara — alocação de estado, negociação de capacidades, validação de credencial, registro de limpeza, logging estruturado — e o handshake no nível MCP adiciona round-trips de protocolo que o transporte não consegue evitar. Sessão-por-requisição paga esse custo a cada requisição; o pool paga uma vez por sessão e amortiza. Os detalhes de implementação que determinam se o pool de fato funciona na prática: isolamento (estado por-requisição é sub-contexto dentro da sessão, criado e destruído por requisição, enquanto estado por-sessão é compartilhado), dimensionamento de pool (o p95 de contagem concorrente com autoscaling para rajadas), checagem de saúde (checagens em segundo plano em sessões ociosas, checagens rápidas na atribuição), e afinidade de requisição via sticky sessions para tools cujo estado abrange múltiplas chamadas. Empilhado em cima, multiplexação de conexão HTTP/2 ou HTTP/3 — uma conexão subjacente carregando muitos streams concorrentes — produz os números de throughput citados; qualquer camada de pool sozinha produz melhoria muito menor. A dimensão de latência de cauda também importa: o servidor sessão-por-requisição tem caudas longas por momentos azarados durante a criação, o pool tem caudas apertadas porque custo de criação é assíncrono fora do caminho quente da requisição. P99 tipicamente melhora três ou quatro vezes — ganho maior que throughput, e o que de fato molda a experiência do usuário.

14.4 O que a série construiu

Os quatro volumes percorreram um arco deliberado. O Volume I foi sobre o interior do modelo. O Volume II foi sobre prompts e raciocínio. O Volume III foi sobre geração aumentada por recuperação. Este volume foi sobre agentes e ferramentas, organizado em torno do MCP porque o MCP é o substrato técnico que tornou a arquitetura agêntica coerente. Três fios percorreram. O primeiro é a separação de cognição de operações: o modelo é a camada cognitiva, o framework e os servidores MCP são a camada operacional, e a maioria das falhas de produção vem de colapsar os dois juntos. O segundo é o orçamento finito de contexto: contexto é recurso escasso, e as escolhas arquiteturais que produzem agentes confiáveis são as que respeitam essa escassez. O terceiro é o protocolo como fronteira: MCP não é só formato de wire mas fronteira pela qual capacidades fluem, confiança precisa ser negociada, e evolução futura continuará acontecendo. Um protocolo que se sustenta sob pressão de engenharia vira infraestrutura; o MCP parece estar fazendo isso.

O que o Volume IV prepara

Este é o último capítulo do volume, então o que ele prepara não é o próximo capítulo mas o próximo volume. O Volume V — Construindo Aplicações LLM no Mundo Real — toma as fundações lançadas nos Volumes I a IV e as monta em arquétipos específicos de aplicação: assistentes para engenharia de software, agentes para automação de negócio, copilots dentro de aplicações verticais, ferramentas autônomas de pesquisa. O tratamento será menos sobre mecanismos subjacentes (que os volumes anteriores cobriram) e mais sobre as escolhas de engenharia no nível de aplicação — como delimitar uma aplicação LLM para entregar valor confiavelmente, como avaliá-la em produção, como gerenciar o ciclo de vida de prompts, tools e memória conforme a aplicação evolui. O leitor que terminar o Volume V terá percorrido o caminho de uma única attention head a uma aplicação implantada que exercita um agente sobre uma pilha de servidores MCP reais em infraestrutura real, com o julgamento de engenharia para saber por que cada camada foi construída do jeito que foi.

A série continua em LLM Primer V — Construindo Aplicações LLM no Mundo Real.