Un estudio de IDC encargado por Lenovo encuestó a casi 3.000 responsables de TI empresarial y concluyó que el 88% de las pruebas de concepto de IA nunca llegan a un despliegue generalizado. Por cada 33 PoCs lanzados, solo cuatro avanzan. El propio análisis del estudio es directo: la brecha refleja un “bajo nivel de preparación organizativa en materia de datos, procesos e infraestructura de TI”. S&P Global sitúa la tasa de abandono en el 42% de las empresas que descartaron la mayoría de sus iniciativas de IA en 2025, frente al 17% del año anterior. La analista de Gartner Anushree Verma pronosticó en junio de 2025 que más del 40% de los proyectos de IA agéntica serán cancelados antes de finales de 2027, citando costes crecientes y controles de riesgo insuficientes.
Los modelos no son el problema. Los modelos que impulsan la mayoría de los PoCs empresariales son genuinamente capaces. Lo que falla es la suposición de infraestructura que hay debajo: que un sistema que funciona de forma impecable para un agente, una sesión y un turno seguirá funcionando cuando se le aplica carga concurrente real.
No lo hará. Y el modo de fallo es lo suficientemente específico como para que puedas probarlo antes de comprometerte con la capacidad de producción.
La ruptura arquitectónica que nadie prueba en un PoC
El servicio de LLMs logra eficiencia económica mediante infraestructura compartida sin estado. Se agrupan las solicitudes, se comparte el tiempo de GPU entre sesiones y se escala horizontalmente sin importar qué instancia atiende a qué usuario. Las cargas de trabajo agénticas rompen este modelo por completo. Un agente requiere estado por sesión a lo largo de múltiples llamadas de inferencia y ejecuciones de herramientas. Cada turno de una conversación se añade a un contexto creciente que debe estar disponible, intacto, para el siguiente turno.
Considera la aritmética. Una ventana de contexto de 256.000 tokens requiere aproximadamente 22 GB de caché KV para una sola sesión. Con 64 usuarios concurrentes, eso se convierte en aproximadamente 1,4 TB. Con 1.000 usuarios concurrentes, alrededor de 22 TB. Un modelo de 70B cuantizado a FP8 cabe en una sola GPU de 96 GB con margen de sobra, para cero sesiones de agente concurrentes a 128K de contexto. La demo funciona. El modelo carga limpiamente. Luego apuntas tres agentes en producción y el framework de servicio comienza a desalojar contexto a mitad de tarea, porque no hay otro lugar donde almacenarlo. El agente no falla; simplemente pierde el hilo de forma silenciosa.
El agente que falla en producción no falla porque el modelo sea incorrecto. Falla porque la infraestructura fue dimensionada para una demo, no para una conversación que crece con cada turno.
Las conversaciones de múltiples turnos agravan esto. En un flujo de trabajo de agente de cinco turnos con un system prompt de 200 tokens y 150 tokens por turno, el prompt del último turno contiene aproximadamente 950 tokens, de los cuales solo unos 150 son nuevos. Los frameworks de inferencia existentes gestionan esto de forma deficiente: recomputan el prefijo completo en lugar de extender una representación en caché. Los benchmarks de investigación contra vLLM y SGLang en cargas de trabajo de llamadas a herramientas multiagente muestran que una implementación de referencia con estado es 2,1 veces más rápida por turno en un flujo de trabajo agéntico de seis turnos, con la ventaja ampliándose a medida que aumenta la profundidad de la conversación.
La latencia de las llamadas a herramientas se acumula más rápido de lo que los equipos esperan
La mayor parte del tiempo total de pared de una solicitud de agente se pasa esperando: esperando la inferencia del modelo, la recuperación de datos, las invocaciones de herramientas y las consultas de memoria. El AWS Well-Architected Agentic AI Lens lo explicita: ejecutar operaciones independientes de forma concurrente, reutilizar conexiones activas y deduplicar consultas repetidas reduce la latencia total sin cambiar modelos ni prompts. Sin embargo, los equipos que introducen paralelismo sin respetar los límites de tasa de los sistemas downstream ni la capacidad del pool de conexiones descubren que las llamadas concurrentes se limitan o se encolan, convirtiendo la ganancia de latencia prevista en latencia adicional más fallos en cascada.
Los bucles de reintento basados en fallos empeoran esto. Cuando falla una llamada a una herramienta, el agente añade la observación del error y lo intenta de nuevo. Cada reintento hace crecer el contexto. Un fallo de cola larga que sería invisible en una demo de sesión única se convierte en un patrón de crecimiento de contexto desbocado bajo carga concurrente, saturando simultáneamente tanto la memoria de la GPU como las colas de llamadas a herramientas.
La afinidad de sesión es el elemento que la mayoría de los equipos descubre solo después de haber desplegado. Sin hashing consistente por sesión o ID de usuario en la capa del balanceador de carga, una solicitud de seguimiento en una conversación de múltiples turnos puede llegar a una instancia de vLLM que no tiene la caché KV de esa sesión. El framework de servicio realiza entonces un re-prefill completo de todo el historial de conversación. Esto es tanto un problema de corrección como de latencia: el contexto aparente del agente es correcto, pero la penalización de latencia se acumula en cada turno después del primero, y la caché KV que construiste se reconstruye desde cero en cada salto.
La capa de almacenamiento que tu PoC probablemente no construyó
La infraestructura agéntica de producción requiere dos niveles de almacenamiento distintos que casi ningún PoC aprovisiona correctamente. El almacenamiento temporal guarda el historial de conversación durante las sesiones activas; Redis es la opción estándar porque es rápido y admite expiración automática. El almacenamiento persistente mantiene la memoria a largo plazo, el historial de llamadas a herramientas y los datos de evaluación entre sesiones y reinicios. Son sistemas diferentes con requisitos distintos de consistencia y durabilidad, y confundirlos, u omitir el almacenamiento persistente por completo, es la segunda causa más común por la que un PoC colapsa en producción, después del desalojo de la caché KV.
El servicio agéntico eficiente requiere gestionar conjuntamente la ejecución del modelo, la caché de contexto persistente, la interacción con herramientas y la recuperación ante fallos. Optimizar cualquier componente de forma aislada, que es lo que casi siempre hace un PoC, produce un sistema que parece listo para producción hasta que el segundo componente falla bajo carga.
El checklist que cierra la brecha
Antes de aprobar la capacidad de producción para una carga de trabajo agéntica, ejecuta estas pruebas contra tu entorno de PoC real:
- Prueba de presión de caché KV. Simula tus sesiones concurrentes máximas esperadas con tu longitud de contexto objetivo. Calcula el requisito de caché KV (aproximadamente 22 GB por sesión de 256K tokens para un modelo grande). Confirma que tu flota de GPUs puede mantener esa caché sin desalojo. Si no puede, necesitas más memoria de GPU, una estrategia de descarga de KV o una ventana de contexto efectiva más corta.
- Verificación de afinidad de sesión. Envía una conversación de diez turnos a través de tu balanceador de carga con al menos tres instancias de backend. Confirma que cada turno llega a la misma instancia, o que tu capa de compartición de caché hace que la distinción sea transparente. Mide el TTFT en los turnos del dos al diez.
- Saturación concurrente de llamadas a herramientas. Ejecuta tu flujo de trabajo de agente a 50, 100 y 200 sesiones concurrentes simultáneamente. Observa la saturación de colas en tu capa de inferencia y el throttling en tus backends de herramientas. Mide el TTFT en P99, no el TTFT medio: la latencia media oculta el comportamiento de cola que hace que los agentes parezcan bloqueados.
- Contención de bucles de reintento. Inyecta deliberadamente fallos en llamadas a herramientas al 10% y al 25%. Confirma que tu framework de agente limita la profundidad de reintento y el crecimiento del contexto. Un agente que reintenta indefinidamente agotará tanto la caché KV como la cuota de llamadas a herramientas bajo condiciones de fallo.
- Separación de niveles de almacenamiento. Confirma que el historial de conversación vive en un almacén efímero rápido con TTL, y que el historial de llamadas a herramientas y la memoria a largo plazo persisten tras un reinicio completo de la infraestructura. Ejecuta el reinicio. Verifica que el agente se reanuda correctamente.
Ejecutamos cargas de trabajo de inferencia en GPU desde MUC1, nuestra instalación en Múnich, que da servicio a los clusters de finanzas y automatización industrial donde los despliegues de IA agéntica avanzan más rápido. Los equipos con los que trabajamos en el aprovisionamiento de GPU bare-metal allí ven repetidamente el mismo patrón de colapso: un PoC que funcionó limpiamente con un número de sesiones de un solo dígito sufre fallos de desalojo de KV y de afinidad de sesión la primera vez que se incorpora un grupo de usuarios real. El checklist anterior es lo que repasamos con los clientes antes de que dimensionen la capacidad de producción, porque adaptar la memoria de GPU y una capa de sesión Redis después de salir a producción cuesta significativamente más que probarlo durante la fase de PoC.
Lo que realmente significa estar listo para producción en IA agéntica
La investigación de Capgemini de 2025 encontró que solo el 2% de las organizaciones han desplegado IA agéntica a plena escala. La brecha entre ese número y el volumen de PoCs en marcha no es un problema de calidad del modelo. El patrón de fallo central, tal como lo describen consistentemente las investigaciones, es una brecha de verificación entre capacidad y despliegue: los pilotos tienen éxito en condiciones controladas y luego flaquean en producción porque la integración, el acceso a los datos y la capa de infraestructura nunca se sometieron a pruebas de estrés conjuntamente.
El PoC que supera las cinco pruebas anteriores no tiene garantizado el éxito en producción. Pero el PoC que las omite casi con certeza fallará, exactamente en el momento en que más importa.
