Escalar aprendizaje automático: cuatro cuellos de botella distintos

A 30 de julio de 2026, «escalar un modelo» puede significar ingerir más datos, terminar antes un entrenamiento, atender más peticiones o ejecutar en menos memoria. Son problemas distintos. Añadir máquinas a ciegas puede desplazar el atasco a la red, empeorar el coste o duplicar errores de datos. La capacidad duradera es trazar una curva recurso→resultado y localizar cuál de cuatro sistemas —datos, entrenamiento, servicio o modelo— deja de cumplir su objetivo.

Escala empieza con una unidad y un presupuesto

Define primero qué crece: filas por día, terabytes, parámetros, aceleradores, peticiones por segundo, usuarios simultáneos o versiones. Después fija el objetivo: calidad, tiempo de entrenamiento, latencia percentil 95, disponibilidad, coste por predicción o energía. «Funciona con millones» no informa si no nombra unidad, periodo y nivel de servicio.

Una prueba de escala repite la carga y multiplica una variable mientras registra rendimiento y coste. La curva muestra el punto de saturación. Si duplicar trabajadores reduce el tiempo solo un 10%, comunicación, almacenamiento o una fase serial dominan. Si el modelo mejora poco al duplicar datos, quizá el límite sea calidad, arquitectura o evaluación.

Cuello 1: mover y validar datos

El primer límite suele aparecer antes de la GPU. Los datos llegan con esquemas, formatos, tasas y niveles de calidad diferentes. Hay que poder versionar el conjunto, detectar duplicados, validar rangos y reconstruir qué filas produjeron un modelo. El trabajo de Data Validation for Machine Learning describe comprobaciones de esquema, anomalías y sesgo entre entrenamiento y servicio dentro de pipelines productivos.

Un sistema distribuido divide almacenamiento y cómputo. El guía de arquitectura de HDFS explica bloques grandes, replicación y un espacio de nombres coordinado para almacenar ficheros en muchas máquinas. MapReduce formalizó una interfaz para repartir transformaciones y recuperarse de fallos de trabajadores. Estas decisiones sirven a cargas por lotes; no convierten automáticamente un pipeline en tiempo real.

Apache Spark añadió conjuntos distribuidos resistentes y reutilizables en memoria para cargas iterativas e interactivas, descritos en el paper de RDD. Mantener datos en memoria puede acelerar iteraciones, pero exige observar particiones, shuffle, derrames a disco y sesgo de claves. Un nombre de framework no sustituye un perfil de la etapa lenta.

Más datos también multiplican defectos

Escalar volumen sin procedencia puede aumentar fugas entre entrenamiento y prueba, etiquetas contradictorias y datos personales innecesarios. Cada transformación necesita entrada, versión de código, salida y validación. Si se corrige una fuente, el linaje indica qué modelos deben rehacerse.

Los datos sintéticos no sustituyen «almacenar originales indefinidamente». Pueden cubrir casos raros o permitir experimentos, pero heredan el simulador, el generador y su sesgo. Hay que conservar especificación, semillas, parámetros y muestras reales de validación. La política de retención se decide por necesidad, derechos y riesgo, no por una promesa generativa.

Cuello 2: repartir entrenamiento

En paralelismo de datos, cada trabajador procesa un lote y los gradientes se combinan. Aumentar el lote cambia la optimización; no basta sumar GPUs. El estudio Accurate, Large Minibatch SGD documentó ajustes de tasa de aprendizaje y calentamiento para entrenar ImageNet en una hora con un lote grande. El resultado fue una receta medida, no una ley de escalado lineal.

En paralelismo de modelo, capas, tensores o estados se reparten porque no caben en un dispositivo. ZeRO propuso particionar estados del optimizador, gradientes y parámetros para reducir redundancia de memoria. A cambio aparecen comunicación y complejidad. Hay que medir utilización de aceleradores, ancho de banda, tiempo de sincronización, memoria pico y rendimiento por euro.

La tolerancia a fallos también tiene precio. Los checkpoints permiten reanudar, pero escribirlos demasiado a menudo detiene el cálculo; demasiado poco obliga a repetir horas. Se decide su frecuencia con tasa de fallo, coste de guardado y tiempo perdido esperado. La recuperación debe ensayarse: un archivo que nunca se restauró no es todavía una estrategia.

El tamaño óptimo depende de datos y cómputo

El número de parámetros no es una medida autosuficiente. Training Compute-Optimal Large Language Models entrenó cientos de configuraciones y mostró que, bajo un presupuesto fijo, repartir recursos entre tamaño y tokens podía superar modelos mayores pero subentrenados. La pregunta útil es cuánto rendimiento marginal compra la siguiente unidad de cómputo.

Por eso el informe debe incluir curva de aprendizaje frente a datos, parámetros y operaciones, no un único punto. Cuando el rendimiento se aplana, añadir infraestructura puede ser peor que mejorar etiquetas, objetivo o arquitectura. «Rendimientos decrecientes» no son una fatalidad abstracta: se miden para el escenario concreto.

Cuello 3: servir predicciones

El entrenamiento ocurre ocasionalmente; la inferencia puede ocurrir millones de veces. Un servicio debe cargar versiones, agrupar peticiones, limitar colas, aislar fallos y registrar resultados. TensorFlow-Serving describió un sistema para administrar modelos y ofrecer inferencia de alto rendimiento con versionado y batching.

Throughput y latencia se intercambian. Esperar para formar un lote usa mejor el acelerador, pero retrasa la primera petición. La media oculta colas: se reportan percentiles 50, 95 y 99 bajo concurrencia creciente. También importan arranque en frío, tamaño de payload, caché, timeouts y tasa de error.

El autoscaling reacciona a una señal. La documentación del Horizontal Pod Autoscaler de Kubernetes explica cómo ajustar réplicas según métricas. Si la señal es CPU pero el límite real es memoria de GPU o longitud de cola, escalar tarde o en exceso. Hay que considerar tiempo de arranque y evitar oscilaciones.

Cuello 4: el modelo no cabe en el presupuesto

Un sistema puede manejar datos y tráfico y aun así ser demasiado lento o caro. La compresión actúa aquí. En distillation, un estudiante aprende de la distribución de salidas de un profesor además de las etiquetas. La comparación debe mantener tarea y medir pérdida de calidad por clase, latencia, memoria y coste.

Cuantización reduce precisión numérica; poda elimina pesos o estructuras; caché reutiliza resultados; un modelo en cascada reserva el grande para casos difíciles. Ninguna técnica es gratis. La cuantización puede afectar clases raras, la poda puede no acelerar hardware real y la caché necesita reglas de caducidad. Se mide en el dispositivo de destino.

Las redes siamesas, en cambio, son arquitecturas para comparar pares o aprender similitud. Pueden ser útiles en búsqueda o verificación, pero no son por definición una técnica de escalabilidad. Incluirlas bajo «eficiencia» confunde tarea con recurso.

Aprendizaje online no elimina el pipeline

Actualizar con flujos evita reentrenar desde cero en algunos algoritmos, pero añade orden temporal, deriva, etiquetas tardías y posibilidad de corrupción. Se necesitan ventanas, versión de características, evaluación previa a promoción y rollback. Una actualización continua sin control puede escalar el error tan rápido como el dato.

Separa ingestión continua de actualización continua. Un sistema puede recibir eventos en tiempo real, agregarlos y reentrenar por lotes bajo revisión. La frecuencia correcta depende de cuánto cambia la relación que se predice, no de la velocidad de llegada.

La hoja de diagnóstico

Para cada etapa registra: volumen de entrada; tasa de procesamiento; recurso limitante; latencia; memoria; tasa de fallo; calidad de salida; coste; y mecanismo de recuperación. Haz una prueba al doble, cinco veces y diez veces la carga. Cambia una variable por experimento y observa dónde deja de crecer el rendimiento.

Después elige la intervención que corresponde: particionar o validar para datos; paralelizar y checkpoint para entrenamiento; batching y réplicas para servicio; comprimir o enrutar para inferencia. Escalar no es poseer más máquinas, sino mantener una propiedad definida mientras crece una carga definida, con una curva que demuestra dónde se paga cada mejora.