Una investigación de IDC realizada con Lenovo encontró que, de cada 33 proof of concepts de IA que lanza una empresa, solo cuatro alcanzan un despliegue a gran escala. La encuesta de S&P Global Market Intelligence de 2025, con más de 1.000 empresas, reveló que la organización promedio descarta el 46% de sus PoC de IA antes de llegar a producción. Esos números no son principalmente un problema de ciencia de datos. Son un problema de infraestructura disfrazado de uno.

El patrón es consistente: un equipo valida un modelo en instancias cloud compartidas, capacidad de GPU prestada o una única estación de trabajo potente. El modelo funciona. El caso de negocio parece sólido. Luego alguien intenta promoverlo a producción y todo se desmorona en menos de 30 días. El throughput de red es una fracción de lo que tenía el clúster de entrenamiento. La latencia de almacenamiento triplica lo que necesita el servicio de inferencia. Aparece un requisito de soberanía que el entorno original nunca tuvo que satisfacer. El PoC nunca estuvo mal; simplemente nunca se probó bajo condiciones de producción.

Este artículo es un pre-mortem. Ejecuta estos puntos de control antes de comprometerte con una arquitectura, no después del primer incidente en producción.

El giro del almacenamiento que sorprende a casi todos

El entrenamiento y la inferencia no solo difieren en su perfil de cómputo; sus requisitos de almacenamiento son, en aspectos importantes, opuestos. El entrenamiento está dominado por el throughput de escritura secuencial. Un modelo de lenguaje grande moderno genera escrituras de checkpoint de alrededor de 350 GB cada pocas horas para preservar el estado del entrenamiento. Si el sistema de almacenamiento no puede absorber ese pico, los recursos de GPU quedan inactivos a un coste real mientras se vacía la cola de escritura.

La inferencia invierte el problema por completo. Un clúster de inferencia en producción que gestiona 100 solicitudes concurrentes necesita más de 100.000 IOPS con latencia de submilisegundo, porque el modelo debe cargar los pesos y los datos de contexto antes de generar cualquier respuesta. El almacenamiento en bloque respaldado por NVMe con latencia de submilisegundo reduce el tiempo hasta el primer token entre un 60% y un 80% en comparación con el almacenamiento conectado en red, según benchmarks de infraestructura de equipos que ejecutan inferencia en producción a escala. Duplica las solicitudes concurrentes y duplicas el requisito de IOPS, de forma lineal.

El PoC se ejecutó en el mismo nivel de almacenamiento que el trabajo de entrenamiento. La inferencia en producción tiene una física completamente diferente. Esa discrepancia no es un problema de ajuste; es un problema de arquitectura.

Un modelo de 70.000 millones de parámetros en media precisión ocupa aproximadamente 140 GB. Si sirves más de un modelo simultáneamente en servidores de inferencia, esa huella de almacenamiento se multiplica rápidamente. Algunas arquitecturas de almacenamiento distribuido consumen silenciosamente 5 GB de DRAM y 4 núcleos de CPU por nodo GPU en overhead; a cualquier tamaño de clúster significativo, eso representa una fracción considerable de tu presupuesto de cómputo antes de que llegue una sola solicitud de inferencia.

El punto de control: somete tu nivel de almacenamiento de inferencia a una simulación realista de solicitudes concurrentes antes de fijar la arquitectura. La velocidad de lectura secuencial no es la métrica relevante aquí.

Selección de GPU: el valor predeterminado casi nunca es el correcto

Las GPU de clase entrenamiento, las H100 y sus sucesoras, están diseñadas para maximizar el throughput en una carga de trabajo sostenida. Eso es exactamente lo que necesitas durante el entrenamiento. Con frecuencia no es lo que necesitas durante la inferencia, donde el cuello de botella es la latencia por solicitud y no el throughput agregado.

Las configuraciones optimizadas para inferencia, con menos VRAM, menor consumo energético y soporte de precisión FP8 o INT8, suelen ofrecer un mejor coste por solicitud aunque sus FLOPS máximos sean menores. La respuesta correcta depende del tamaño del modelo, el objetivo de latencia y el perfil de concurrencia. La respuesta incorrecta es asumir por defecto “usamos la misma GPU con la que entrenamos” sin revisar los números.

Una encuesta de 2024 sobre el estado de la infraestructura de IA encontró que solo el 15% de las organizaciones logra una utilización de GPU superior al 85% durante los períodos pico, y el 74% está insatisfecho con las herramientas actuales de planificación de GPU. La infrautilización a esa escala no es un problema de configuración de planificación; generalmente es señal de que el tipo de GPU se eligió por la comodidad del PoC y no por la forma de la carga de trabajo en producción.

Interconexión de red: la brecha entre una demo y un clúster

Dentro de un nodo multi-GPU, NVLink proporciona alrededor de 900 GB/s de ancho de banda entre GPUs. Entre nodos, las redes InfiniBand o RoCE suelen entregar entre 400 y 800 Gb/s por nodo. Esos números importan porque el entrenamiento distribuido mueve gradientes continuamente a través de ese fabric; cualquier congestión o pico de latencia detiene simultáneamente todas las GPU del trabajo.

Un PoC que se ejecuta en un único nodo, o en instancias cloud compartidas donde la interconexión es opaca, nunca ha tocado esta restricción. El equipo observa buen throughput en la ejecución de entrenamiento, asume que la arquitectura escala y luego descubre, en la primera promoción a múltiples nodos, que su nivel de red no puede sostener la sincronización de gradientes a la tasa requerida. La solución suele requerir un cambio de hardware, no un parche de software.

La red de inferencia es un problema diferente: se trata del camino desde el balanceador de carga hasta el servidor de inferencia, y desde el servidor de inferencia hasta el nivel de almacenamiento. La latencia aquí impacta directamente en el tiempo hasta el primer token y en la latencia de cola en el percentil 99. Ambas métricas importan en cualquier aplicación orientada al usuario.

Restricciones de soberanía que solo aparecen a escala de producción

Un PoC que se ejecuta con capacidad prestada en una región de un hyperscaler puede nunca plantear una pregunta sobre residencia de datos, porque el volumen de datos es pequeño y el equipo controla el acceso de forma informal. La producción cambia ambos hechos. Los volúmenes de datos crecen, los controles de acceso necesitan ser auditables y el equipo legal empieza a preguntar dónde residen realmente los pesos del modelo y los datos de entrenamiento.

Para organizaciones en finanzas, sanidad o defensa, la respuesta a esa pregunta tiene peso contractual y regulatorio. Los pesos de un modelo entrenado con datos propietarios o sensibles son en sí mismos activos sensibles; su ubicación de almacenamiento y el registro de acceso están sujetos al mismo escrutinio que los datos subyacentes. Una arquitectura que no puede responder “dónde residen estos datos, bajo qué jurisdicción legal y quién puede acceder a ellos” no está lista para producción independientemente de su rendimiento técnico.

Ejecutamos cargas de trabajo de inferencia y entrenamiento en GPU para clientes de estos sectores en nuestra infraestructura Bare Metal, donde el aislamiento físico, la jurisdicción legal y la cadena de control de acceso son explícitos desde el primer día, en lugar de incorporarse a posteriori cuando una revisión de cumplimiento descubre la brecha.

La lista de verificación de preparación arquitectónica

Antes de promover cualquier PoC de IA, trabaja explícitamente estos puntos de control:

  • Perfil de almacenamiento: ¿Has realizado benchmarks de IOPS aleatorios a tu concurrencia objetivo, no solo del throughput secuencial? ¿Tu nivel de almacenamiento escala IOPS de forma lineal con las solicitudes concurrentes?
  • Selección de GPU: ¿El tipo de GPU se eligió para el objetivo de latencia de inferencia en producción o para el trabajo de entrenamiento que lo precedió? ¿Has modelado el coste por solicitud en al menos dos configuraciones de GPU?
  • Interconexión de red: ¿Has probado la sincronización de gradientes multinodo con volúmenes de datos realistas? ¿Conoces el perfil de latencia entre tus servidores de inferencia y tu nivel de almacenamiento?
  • Línea base de utilización: ¿Cuál es tu utilización de GPU esperada en el pico? Si la respuesta está por debajo del 70%, la arquitectura de planificación o batching necesita revisión antes de escalar el hardware.
  • Residencia de datos: ¿Puedes responder, con documentación, dónde reside cada activo de datos, bajo qué jurisdicción y quién tiene las claves de cifrado? ¿Esa respuesta se mantiene estable a medida que escala la carga de trabajo?
  • Modos de fallo: ¿Qué ocurre con las solicitudes de inferencia en curso cuando falla un nodo? ¿La recuperación de checkpoints está probada con volúmenes de datos de producción o solo a escala de PoC?

El purgatorio piloto es tanto un problema de infraestructura como organizacional

El término de la industria “pilot purgatory” describe proyectos que demuestran validez técnica pero nunca llegan al despliegue en producción. La mayoría de los análisis lo atribuyen a la preparación organizacional, el patrocinio ejecutivo o la alineación con el negocio. Esos factores son reales. Pero el propio enfoque de IDC es directo: la baja tasa de conversión de PoC a producción indica una baja preparación organizacional “en términos de datos, procesos e infraestructura de TI”. La infraestructura se menciona explícitamente.

La curva de esfuerzo exponencial entre el prototipo y la producción no se debe solo a la calidad del código o a la precisión del modelo. Se trata de la capa física: los IOPS de almacenamiento, el fabric de red, la configuración de GPU, el modelo de control de acceso. Un PoC que nunca se probó contra esas restricciones no ha validado la arquitectura; ha validado el modelo en una arquitectura que todavía no existe.

Ejecuta el punto de control de infraestructura antes de que el caso de negocio quede cerrado. El coste de descubrir una brecha de almacenamiento o red durante una revisión de cumplimiento o un incidente en producción es un orden de magnitud mayor que descubrirla durante la planificación de la arquitectura.