Por qué la infraestructura de IA no se parece en nada a la nube clásica

Migrar una aplicación de microservicios a la nube pública lleva décadas de mejores prácticas documentadas: autoescalado horizontal, load balancers, bases de datos gestionadas, billing por petición. Cuando un equipo empieza a construir sobre modelos de lenguaje, suele asumir que el mismo manual aplica. Según un análisis publicado esta semana en Substack por Raman Sharma, ese supuesto es uno de los errores más caros que cometen los ingenieros hoy.

El artículo, que generó discusión en Hacker News, no es una pieza de hype: es una descripción técnica de por qué los patrones que funcionan bien en la nube convencional se rompen cuando el componente central es un modelo de inferencia.

El problema de la GPU no es solo el coste

En la nube clásica, la unidad de cómputo es fungible. Una CPU virtual es intercambiable; se añaden o eliminan instancias en segundos según la demanda. La infraestructura de IA rompe esta abstracción en varios puntos:

• Las GPUs no son fungibles entre sí. Una H100 y una A10G tienen perfiles de rendimiento radicalmente distintos para inferencia. Elegir mal el acelerador para un modelo dado puede duplicar la latencia o triplicar el coste sin que los dashboards habituales de cloud lo hagan obvio.
• El tiempo de carga del modelo es un factor de primer orden. En servicios web tradicionales, el arranque en frío de un contenedor se mide en segundos. Cargar los pesos de un modelo grande puede llevar minutos. El autoescalado reactivo, que funciona bien para APIs stateless, introduce cuellos de botella severos cuando cada nueva instancia necesita ese tiempo de inicialización.
• La memoria de vídeo (VRAM) es el recurso escaso real. No la RAM del host, no las CPUs. Un modelo que no cabe en VRAM de una GPU debe particionarse entre varias, lo que introduce overhead de comunicación que no tiene equivalente en arquitecturas de microservicios.

Latencia vs. throughput: un trade-off que la nube clásica no plantea así

En una API REST convencional, optimizar para baja latencia y optimizar para alto throughput son objetivos que se pueden perseguir en paralelo con técnicas relativamente estándar (caché, CDN, replicación). En inferencia de LLMs, ambos objetivos entran en conflicto estructural.

El batching dinámico —agrupar varias peticiones en una sola pasada por el modelo— mejora el throughput pero incrementa la latencia de cada petición individual. Los sistemas de inferencia como vLLM o TensorRT-LLM exponen palancas para gestionar este trade-off, pero requieren decisiones de diseño que deben tomarse antes del despliegue, no como ajuste posterior.

Para equipos acostumbrados a que el proveedor cloud abstraiga estos detalles, la curva de aprendizaje es pronunciada. Un ingeniero que configura un grupo de autoescalado en EC2 o Cloud Run rara vez necesita razonar sobre el scheduler interno de peticiones. En inferencia, ese scheduler es crítico.

Statefulness y contexto: otra asimetría

La nube clásica abrazó la statelessness como principio de diseño. Las aplicaciones que necesitan estado lo externalizan a bases de datos o caches. Los LLMs complican esto: el contexto de una conversación (el historial de mensajes, los documentos adjuntos, los resultados de herramientas) crece durante la sesión y debe estar disponible para cada llamada al modelo.

En producción, esto implica decisiones sobre dónde y cómo almacenar ese contexto, cómo enrutarlo hacia la instancia correcta (o cualquier instancia, si se usa prefix caching) y cómo gestionar sesiones que pueden durar minutos o horas. No hay un equivalente directo al session store de una app web: el tamaño, la estructura y la semántica del contexto son completamente distintos.

Para quién importa esto

El artículo de Sharma es especialmente relevante para tres perfiles:

1. Equipos de plataforma que están evaluando si su infraestructura cloud existente puede albergar cargas de inferencia sin cambios estructurales (respuesta habitual: no, o no eficientemente).
2. Ingenieros de backend que asumen el rol de ML engineer sin formación específica en infraestructura de modelos.
3. CTOs y arquitectos que toman decisiones de build vs. buy sobre la capa de inferencia: usar APIs gestionadas (como la API de Anthropic) frente a desplegar modelos propios.

No existe aún un equivalente al Well-Architected Framework de AWS para cargas de inferencia de LLMs. Cada equipo está construyendo sus propias convenciones, con costes de ensayo y error elevados.

---

Desde ElephantPink llevamos meses viendo este patrón en proyectos de integración con Claude: los problemas no suelen estar en el modelo ni en el prompt, sino en la capa de infraestructura que nadie diseñó pensando en inferencia. El artículo de Sharma no ofrece soluciones definitivas, pero nombra correctamente el problema, que ya es bastante.