Capítulo 14 — Benchmarking, testing y rendimiento

Decimocuarta y última entrega del recorrido capítulo por capítulo de LLM Primer IV: Designing AI Cognition with MCP. En el que la arquitectura por fin tiene que contestar a la pregunta poco sentimental — ¿el sistema realmente funciona? — y la respuesta llega a través de benchmarks reales, dos modos sistémicos de fallo y un acantilado de throughput de diez veces que la mayoría de los equipos descubre el día del rollout a producción.

Por qué existe este capítulo

Un protocolo cuidadosamente diseñado, endurecido en seguridad y limpiamente envuelto en un framework todavía tiene que contestar a la pregunta poco sentimental: ¿el sistema realmente funciona? ¿El agente resuelve las tareas para las que se construyó? ¿Aguanta cuando la carga se duplica? ¿Dónde están los acantilados de rendimiento que convierten la degradación elegante en caída? Los capítulos anteriores trataban de poner la arquitectura en orden; éste trata de medir si la arquitectura, una vez construida, entrega. Recorre el MCP-Universe Benchmark — el primer arnés de prueba público que ejercita LLM reales contra servidores MCP reales — los dos modos sistémicos de fallo que el benchmark sacó a la luz y las mitigaciones que han empezado a funcionar, y el lado del throughput donde la brecha entre un pool de sesiones bien ingeniado y el patrón ingenuo por petición es de un orden de magnitud.

14.1 MCP-Universe: medir agentes sobre servidores reales

Durante la mayor parte de 2024 y principios de 2025, la evaluación pública de agentes vivía en un sitio raro. Los benchmarks de uso de herramientas medían si los modelos emitían llamadas sintácticamente correctas contra APIs sintéticas. Los benchmarks de agentes medían finalización de tareas en entornos sandboxed. Lo que faltaba era un benchmark que ejercitara modelos contra servidores MCP reales con autenticación real, rate limits reales, esquemas reales que derivan, herramientas reales que ocasionalmente devuelven resultados vacíos. MCP-Universe, publicado por Salesforce AI Research en 2025, fue el primer intento serio. Seis dominios de evaluación abarcando once servidores MCP de producción real — Google Maps, GitHub, Yahoo Finance, Blender, Playwright, motores de búsqueda reales — y 231 tareas, cada una con un evaluador automatizado que comprueba si el estado final coincide con el resultado esperado en vez de comprobar si el modelo emitió las llamadas a herramientas "correctas" por el camino.

El resultado titular ha aguantado entre refrescos de modelo. Claude 3.5 Sonnet, que puntúa en los ochenta en benchmarks sintéticos, llegó sólo a los cuarenta bajos-medios en MCP-Universe en conjunto. GPT-4o, Gemini 1.5 Pro y las variantes Llama-3 70B se agruparon en territorio similar. La brecha entre rendimiento en uso de herramientas en circuito cerrado y rendimiento sobre MCP real fue de unos cuarenta puntos absolutos, y la escala por sí sola no la cerró. Los fallos se agrupan en categorías reconocibles: degradación por contexto largo a medida que las salidas de herramientas llenan la ventana; exploración de herramienta desconocida cuando el modelo malinterpreta esquemas no familiares; coordinación entre servidores donde los formatos de salida desencajan y no hay puente semántico; y razonamiento específico de tarea donde el modelo selecciona la herramienta correcta, la llama bien, recibe la respuesta correcta y aun así llega a la conclusión final equivocada porque no logra integrar la salida de la herramienta en el razonamiento más amplio. Las decisiones estructurales que hacen de MCP-Universe un instrumento serio son la evaluación basada en ejecución (corriendo llamadas contra servidores reales, no comparando con una traza de referencia), los datos en tiempo real (datos de mercado vivos, con el evaluador siguiendo cuál era la respuesta en el momento del run) y la evaluación multi-turno (calificando el estado final, no cada paso). Un efecto secundario útil: el benchmark opera como señal indirecta de calidad sobre el diseño de servidores, y los autores de servidores que se preocupan por el rendimiento de los agentes tienen ahora un objetivo público.

14.2 Los dos retos sistémicos y lo que funciona

La degradación por contexto largo y la exploración de herramientas desconocidas son los dos modos de fallo lo bastante grandes como para merecer un tratamiento cuidadoso, porque las mitigaciones no son obvias. La degradación por contexto largo en agentes MCP tiene una forma específica: el contexto se llena con salidas de herramientas que todas son relevantes en algún sentido — cada una fue el resultado de una llamada que el modelo eligió hacer — pero cada una es voluminosa y el hecho realmente cargante dentro de cada una es pequeño. Las mitigaciones operan al nivel de presentación de la información. La summarización de resultados de herramienta corre un modelo barato (Haiku, GPT-4o-mini, Gemini Flash) sobre la salida cruda antes de que el resultado aterrice en el contexto del agente; los despliegues de producción reportan mejoras de dos a tres veces en tasas de finalización en contexto largo y el coste por llamada lo domina el modelo barato. La salida de herramienta estructurada con un campo summary junto al payload JSON — formalizada en la revisión del protocolo de 2025 — hace trabajo similar sin la llamada extra de modelo. La compactación de contexto en el bucle del agente, emparejada con un scratchpad gestionado por el agente que sobrevive verbatim a la compactación, maneja el caso en que la conversación misma se ha vuelto demasiado larga; los despliegues de producción disparan compactación cada veinte a cuarenta pasos y preservan aproximadamente un tercio del contexto original.

La exploración de herramientas desconocidas tiene otra forma. Cuando un agente se conecta a un servidor con herramientas en las que no ha sido entrenado, las primeras llamadas del modelo a menudo fallan — tipos equivocados, orden equivocado, a veces herramienta equivocada. La mitigación es una fase de exploración antes del bucle principal: el framework le pide al modelo que lea la descripción de cada herramienta, resuma lo que hace, genere un ejemplo de invocación y marque los parámetros sobre los que no está seguro. La nota resultante se antepone al contexto del agente. El coste es unas pocas llamadas baratas al inicio de la sesión; el beneficio son veinte a treinta puntos porcentuales de mejora de finalización en benchmarks como MCP-Universe, y un registro auditable de la comprensión declarada del agente que ayuda a atribuir fallos posteriores. El patrón se extiende a herramientas cambiadas: hashea la superficie de herramientas al conectar, corre el calentamiento siempre que el hash cambie, y el modo de fallo silencioso por drift (servidor actualizado, agentes fallando durante semanas antes de que nadie lo note) desaparece. Un tercer asunto relacionado que conviene nombrar: la calidad de las descripciones de herramientas. Muchos servidores enviaron descripciones escritas para desarrolladores humanos — escuetas, llenas de jerga, asumiendo contexto. Servidores reescritos como si fueran para un becario que nunca ha visto el sistema muestran mejoras medibles contra los mismos modelos sin cambios en el código del agente. La única ventana del modelo sobre la herramienta es la descripción, y una descripción que no se sostiene sola produce un modelo que no puede usar la herramienta.

14.3 El acantilado de throughput del pool de sesiones

La corrección es la mitad de la historia; la realidad de producción es que las elecciones de diseño que hacen rápido a un agente a menudo tienen implicaciones de corrección y viceversa. El mayor problema de throughput de los despliegues MCP de 2025-2026 es la brecha entre dos formas de gestionar sesiones Streamable HTTP, y la brecha es de unas diez veces. Sesión por petición abre una sesión nueva por cada petición de agente, corre las llamadas a herramientas dentro y la cierra al terminar. El pool compartido de sesiones mantiene un pool de sesiones de larga vida y asigna cada petición a una del pool. La diferencia de throughput en un servidor estándar con una carga de trabajo representativa cae consistentemente en torno a las diez veces — unas treinta peticiones por segundo para sesión por petición, unas 290 a 300 para el pool, en hardware estándar. Los equipos que desconocen la brecha la descubren por la vía dura: staging va bien, el rollout de producción topa con un muro a la tasa de peticiones a la que la sobrecarga de creación de sesiones domina.

El mecanismo es directo. La creación de sesión es cara — asignación de estado, negociación de capacidades, validación de credenciales, registro de cleanup, logging estructurado — y el handshake a nivel MCP añade roundtrips de protocolo que el transporte no puede evitar. Sesión por petición paga este coste en cada petición; el pool lo paga una vez por sesión y lo amortiza. Los detalles de implementación que deciden si el pool funciona en la práctica: aislamiento (el estado por petición es un sub-contexto dentro de la sesión, creado y destruido por petición, mientras que el estado por sesión se comparte), dimensionado del pool (el p95 de concurrencia con autoescalado para picos), health checking (comprobaciones en segundo plano de sesiones inactivas, comprobaciones rápidas en la asignación) y afinidad de petición mediante sticky sessions para herramientas cuyo estado abarca varias llamadas. Por encima, la multiplexación de conexión HTTP/2 o HTTP/3 — una conexión subyacente cargando muchos streams concurrentes — produce los números de throughput citados; cualquiera de las dos capas de pool por sí sola produce una mejora mucho menor. La dimensión de cola de latencia también importa: el servidor de sesión por petición tiene colas largas por momentos infortunados durante la creación, el pool las tiene apretadas porque el coste de creación está asíncrono fuera del camino caliente. El P99 mejora habitualmente tres o cuatro veces — una ganancia mayor que la del throughput, y la que da forma de verdad a la experiencia del usuario.

14.4 Lo que la serie ha construido

Los cuatro volúmenes han recorrido un arco deliberado. El Volumen I trataba del interior del modelo. El Volumen II trataba de prompts y razonamiento. El Volumen III trataba de generación aumentada por recuperación. Este volumen ha tratado de agentes y herramientas, organizado alrededor de MCP porque MCP es el sustrato técnico que volvió coherente la arquitectura de agentes. Tres hilos lo han atravesado. El primero es la separación de cognición y operaciones: el modelo es la capa cognitiva, el framework y los servidores MCP son la capa operativa, y la mayoría de los fallos de producción vienen de colapsar las dos. El segundo es el presupuesto finito de contexto: el contexto es un recurso escaso, y las elecciones arquitectónicas que producen agentes fiables son las que respetan esa escasez. El tercero es protocolo-como-frontera: MCP no es sólo un formato de cable sino una frontera a través de la cual fluyen capacidades, hay que negociar confianza, y la evolución futura va a seguir ocurriendo. Un protocolo que aguanta bajo presión de ingeniería se vuelve infraestructura; MCP parece estar haciéndolo.

Lo que prepara el Volumen IV

Éste es el último capítulo del volumen, así que lo que prepara no es el siguiente capítulo sino el siguiente volumen. El Volumen V — Construyendo aplicaciones LLM del mundo real — toma los cimientos puestos a lo largo de los Volúmenes I a IV y los ensambla en arquetipos de aplicación específicos: asistentes para ingeniería de software, agentes para automatización de negocio, copilots dentro de aplicaciones verticales, herramientas autónomas de investigación. El tratamiento será menos sobre mecanismos subyacentes (que los volúmenes previos cubrieron) y más sobre las elecciones de ingeniería al nivel de aplicación — cómo acotar una aplicación LLM para entregar valor de forma fiable, cómo evaluarla en producción, cómo gestionar el ciclo de vida de prompts, herramientas y memoria a medida que la aplicación evoluciona. El lector que termine el Volumen V habrá recorrido el camino desde una sola cabeza de atención hasta una aplicación desplegada que ejercita un agente sobre una pila real de servidores MCP en infraestructura real, con el juicio de ingeniería para saber por qué cada capa se construyó como se construyó.

La serie continúa en LLM Primer V — Creando aplicaciones LLM del mundo real.