Infraestructura AWS para modelos base

Por qué la escala dejó de ser una sola curva

Durante años, “escalar” modelos base se entendió principalmente como dedicar más potencia de cómputo al pre-entrenamiento para mejorar capacidades. Investigaciones como Kaplan et al. (2020) respaldaron esa idea mostrando tendencias predecibles al aumentar parámetros, datos y cómputo. Sin embargo, el panorama evolucionó: el rendimiento ya no crece solo con un eje de escala.

Hoy conviene pensar en tres regímenes de escala que influyen en todo el ciclo de vida del modelo: pre-entrenamiento, post-entrenamiento (por ejemplo, fine-tuning supervisado y técnicas basadas en RL) y computo en tiempo de inferencia (estrategias de muestreo múltiples, verificación y procesos de “pensar más”). Juntos, estos regímenes exigen una infraestructura convergente: cómputo acelerado estrechamente acoplado, red de baja latencia y alto ancho de banda, y almacenamiento distribuido para datos y checkpoints. Además aumentan la necesidad de orquestación y observabilidad para mantener la salud y el rendimiento del clúster.

La pila de software open source que impulsa el ciclo de vida

Gran parte del ecosistema para modelos base es open source. En el nivel de orquestación y recursos se usan sistemas como Slurm y Kubernetes. Los frameworks de desarrollo y entrenamiento distribuido más comunes son PyTorch y JAX. Para la capa de observabilidad, Prometheus suele recolectar métricas y Grafana se utiliza para visualización y alertas. Esta combinación forma una arquitectura en capas donde la infraestructura soporta la orquestación, que a su vez habilita los marcos ML, con observabilidad transversal a todas las capas.

Para equipos en América Latina que planifican proyectos con modelos base, esa arquitectura OSS permite flexibilidad y evita el vendor lock-in, pero también requiere capacidades operativas para integrar y mantener los componentes a escala.

Los bloques de construcción de AWS: cómputo, red y almacenamiento

En AWS, las tres piezas fundamentales son aceleradores con gran memoria en dispositivo, interconexión de alto ancho de banda para comunicación colectiva y almacenamiento distribuido escalable para datos y checkpoints. Estos elementos son críticos tanto para pre-entrenamiento como para inferencia a gran escala.

Amazon EC2 ofrece varias generaciones de GPUs NVIDIA en familias de instancias P. Entre las opciones mencionadas están:

P5: incluye variantes como p5.48xlarge con ocho GPUs NVIDIA H100, p5.4xlarge con una H100, y variantes p5e.48xlarge/p5en.48xlarge con GPUs H200.
P6: introduce la arquitectura Blackwell con instancias p6-b200.48xlarge (B200) y p6-b300.48xlarge (B300).

A nivel técnico, las dimensiones que más importan al comparar aceleradores son el throughput de Tensor Cores, la capacidad y ancho de banda de HBM, y el ancho de banda de interconexión dentro y entre nodos. A modo de referencia, la siguiente tabla resume el rendimiento por GPU (especificaciones SXM/HGX alineadas con NVSwitch/NVLink para nodos multi-GPU), reportando rendimiento denso en operaciones Tensor:

GPU (variante)	BF16/FP16 Tensor pico (denso)	FP8 Tensor pico (denso)	FP4 Tensor pico (denso)	HBM capacidad	HBM ancho de banda
H100 (SXM)	0.9895 PFLOPS	1.979 PFLOPS	—	80 GB HBM3	3.35 TB/s
H200 (SXM)	0.9895 PFLOPS	1.979 PFLOPS	—	141 GB HBM3e	4.8 TB/s
B200 (HGX, por GPU)	2.25 PFLOPS	4.5 PFLOPS	9 PFLOPS	180 GB HBM3e	8 TB/s
B300 (HGX, por GPU)	2.25 PFLOPS	4.5 PFLOPS	13.5 PFLOPS	288 GB HBM3e	8 TB/s

Nota: los valores muestran rendimiento denso; cuando NVIDIA reporta números “con sparsity” se toma la aproximación de densidad indicada por sus guías. Las cifras de B200 se presentan por GPU dividiendo los totales de sistema por ocho, acorde a especificaciones HGX.

Por qué la red y el movimiento de memoria importan tanto

A medida que los modelos y los batch sizes crecen, el tiempo por paso de entrenamiento deja de estar dominado por la aritmética de los tensores y pasa a estar dictado por la comunicación colectiva y el movimiento de memoria. Eso hace que el diseño del interconectado (NVLink, NVSwitch, redes de alta velocidad entre nodos) y la arquitectura de almacenamiento sean tan importantes como las FLOPS brutas.

Para cargas multi-nodo, garantizar baja latencia y alto ancho de banda entre GPUs es clave para mantener la eficiencia. De forma complementaria, el almacenamiento distribuido debe servir datos con suficiente rendimiento y soportar checkpoints grandes sin convertirse en cuello de botella.

Orquestación y observabilidad: mantener el cluster sano y eficiente

Con requisitos tan acoplados, la orquestación de recursos y la visibilidad operativa son indispensables. Kubernetes y Slurm son opciones probadas para gestionar recursos en distintos entornos; la elección depende del modelo operativo del equipo y del grado de personalización requerido. Por su parte, Prometheus y Grafana ofrecen una base sólida para monitorear métricas de hardware, utilización de GPU, latencias de red y métricas de entrenamiento.

En AWS, los servicios administrados y las integraciones con la capa de observabilidad pueden reducir la carga operativa, una consideración relevante para equipos en Latinoamérica que buscan desplegar capacidades de IA sin montar toda la infraestructura desde cero.

Implicaciones para equipos y tomadores de decisión en América Latina

Estrategia híbrida: muchas organizaciones en la región combinan workloads locales con nubes públicas. Comprender las dependencias de red y almacenamiento ayuda a decidir qué mover a la nube y qué dejar on-prem.
Capacidad operativa: aprovechar OSS da flexibilidad, pero exige habilidades en orquestación y observabilidad. Los servicios administrados de AWS pueden acelerar despliegues y reducir riesgo operativo.
Elección de instancias: el trade-off entre memoria por GPU, throughput de Tensor y ancho de banda de interconexión es central para optimizar costo/tiempo en entrenamientos grandes. Evaluar el perfil de la carga (pre-entrenamiento vs fine-tuning vs inferencia) guía la selección.

Conclusión

El entrenamiento e inferencia de modelos base se sostienen sobre tres ejes combinados: cómputo acelerado con memoria amplia, red de alta velocidad y almacenamiento distribuido. En la práctica, esas necesidades se traducen en elecciones técnicas (familias de instancias, topologías de red) y operativas (orquestación, observabilidad) que determinan la eficiencia y el escalamiento.

Para equipos en América Latina, la recomendación es adoptar una visión holística: no basta con escoger GPUs potentes; hay que integrar red, almacenamiento y software OSS con una estrategia de operación que equilibre control y gestión administrada. Con esa base, es posible desplegar pipelines de entrenamiento e inferencia que escalen con los demands actuales de los modelos base, sin perder de vista costos operativos y riesgos técnicos.