Más allá de una tarjeta: cómo los modelos gigantes funcionan en cientos de GPU

Los modelos de IA más grandes de hoy superan el billón de parámetros y necesitan cerca de 2 terabytes de memoria solo para guardar sus pesos. Sin embargo, la GPU más grande del mercado ofrece unos 288 GB: ni siquiera la tarjeta más ambiciosa se acerca a estos gigantes. Entonces, ¿cómo atienden sin pausa los chats que usan millones de personas cada día? La respuesta es de una sencillez desarmante: no existe una megacomputadora única que los albergue. Funcionan en un sistema coordinado de decenas, a veces cientos, de GPU. En el canal IBM Technology, Grace Ableidinger desmenuza cómo una carga de inferencia LLM se mantiene viva a esa escala, paso a paso.

Servir un modelo en producción es resolver tres límites a la vez. Primero, la huella de memoria del modelo: cada peso debe residir en memoria antes de empezar. Segundo, la memoria de trabajo llamada caché KV : mientras el modelo redacta su respuesta guarda allí el contexto de la conversación, y esa zona crece con cada token producido. Tercero, el caudal de peticiones: cuando cientos o miles de personas acuden al modelo a la vez, cada solicitud hace cola en la tarjeta y la espera de todos crece. La caché KV es la más traicionera de las tres porque nunca se queda quieta: se hincha mientras continúa la generación. Según el trabajo Dynamo de Nvidia, ese contexto que se hincha puede salir de la memoria GPU hacia niveles más baratos como la memoria CPU y los discos rápidos; validaciones junto a Vast y WEKA midieron 35 GB/s hacia una sola H100 y 270 GB/s entre ocho tarjetas.

Atender el tráfico: paralelismo de datos

Cuando el modelo y su caché caben en una tarjeta pero los usuarios se vuelven inabarcables, la solución más simple es copiar el modelo entero en varias tarjetas. Con el paralelismo de datos , cada tarjeta guarda una réplica idéntica y las peticiones se encaminan según la carga del momento — incluso según qué tarjeta ya tiene el contexto útil en su caché. No hace falta coordinación entre réplicas: basta con hacer entrar cada solicitud por la puerta correcta. Según el texto de inferencia distribuida del equipo de vLLM, del 17 de febrero de 2025, la cuantización de pocos bits ya no basta más allá de cientos de miles de millones de parámetros; por eso el motor ofrece el paralelismo de tensores dentro de la tarjeta y el paralelismo de pipeline entre tarjetas. El tráfico se resuelve con copias, y el encaje con técnicas de partición.

Copiar ya no sirve para los modelos realmente enormes, porque el modelo mismo no cabe en una tarjeta. Un modelo es una secuencia de capas de transformadores que portan el conocimiento, e inferir es hacer pasar la entrada por ellas una tras otra. El paralelismo de pipeline corta el modelo en grupos de capas: las primeras en la primera tarjeta, las siguientes en la segunda. Con una sola solicitud, casi todas las tarjetas esperan su turno de brazos cruzados; las peticiones fluyen en continuo, como en una cadena de montaje, para mantener cada puesto ocupado. Las notas de ingeniería de Baseten cifran mil millones de parámetros en torno a un gigabyte en precisión FP8; DeepSeek-V3.1, con sus 671 mil millones de parámetros, desborda la memoria de una sola B200, e incluso 720 GB en cuatro B200 cubren los pesos sin dejar sitio a la caché KV — que suele quedarse con el 80 % o más del espacio restante tras los pesos. Conclusión: el tráfico real a este tamaño pide un nodo completo de ocho tarjetas.

Dos formas de partir: pipeline y tensores

En vez de cortar el modelo en vertical, se puede cortar en horizontal. El paralelismo de tensores divide la matemática dentro de cada capa en lugar de las capas mismas: cada tarjeta toma una rebanada de la misma capa, calcula su parte, y luego las tarjetas combinan los resultados parciales. Esa combinación es una operación colectiva, una barrera que detiene a las tarjetas en cada capa: deben parlotear sin descanso en mitad del cálculo. Semejante cháchara densa solo avanza con un enlace veloz y de baja latencia dentro del mismo servidor; en una red lenta, la charla se vuelve el cuello de botella en vez de la optimización. La guía de DigitalOcean recuerda que un modelo denso de 70 mil millones de parámetros en BF16 reclama unos 140 GB solo para sus pesos; un modelo cómodo con 4K de contexto puede negarse a caber con 64K o 128K bajo tráfico real de producción. El mensaje es claro: la velocidad del camino entre tarjetas importa tanto como la técnica de corte.

Existe además la familia que trabaja como una comunidad de especialistas: la mezcla de expertos. En vez de activar un solo bloque de pesos con cada entrada, estos modelos albergan pequeñas subredes expertas en distintas facetas de la generación — una inclinada a los ejemplos de código, otra a la puntuación, una tercera a los números. El paralelismo de expertos reparte esos expertos entre tarjetas, de modo que ninguna guarda el modelo entero. En cada capa, un enrutador envía cada token al puñado de expertos elegido; los modelos actuales escogen unos 8 de 256, y las salidas se fusionan después. El cómputo por token cae en picado, pagado con un tráfico intenso de encaminamiento entre tarjetas. Como subraya el manual de Modular, cada réplica de datos puede combinar por dentro tensores o pipeline, y el enrutador traza una frontera de fallo al apartar las réplicas que no superan sus controles de salud.

Un parque por tarea: prellenado y descodificación

Las dos fases de la inferencia LLM castigan el equipo de formas opuestas. En el prellenado , el modelo lee y asimila la entrada, encadena matemática paralela densa sobre pesos fijos a velocidad de cómputo, y de paso construye la caché KV. En la descodificación , la respuesta nace token a token, extrayendo a cada paso toda la caché crecida desde la memoria, a velocidad de ancho de banda. Aparcadas juntas, ambas fases se estorban: el apetito de memoria de la descodificación estrecha el territorio del prellenado. La salida instala cada fase en su propio parque de GPU, afinado para su cuello — siempre que la caché viaje entre parques a la velocidad de la luz. El TCP llano sobre Ethernet estándar no sigue el ritmo; hace falta red dedicada, de baja latencia y compatible con RDMA. El relato de SageMaker HyperPod de Amazon une los parques separados con EFA y RDMA, afina por separado el tiempo al primer token y la latencia entre tokens, e impide que las entradas largas atasquen la generación en curso. La guía de Ray añade que la misma separación escala cada fase en nodos heterogéneos más baratos, con las pasarelas NIXL y LMCache de vLLM para el transporte.

Los despliegues reales apilan estas técnicas: tensores dentro del servidor, pipeline entre servidores, datos entre réplicas, expertos para las mezclas, y parques separados por fase. Ese apilado se llama paralelismo multidimensional. En la cima gobierna una capa de orquestación que dirige cada petición al parque de GPU correcto, equilibra la carga y absorbe las tarjetas averiadas sin perder solicitudes. Como resume la presentadora, la regla es simple: tráfico desbordado, se añaden copias; modelo que no cabe, se parte capa a capa o rebanada a rebanada; memoria que se hincha de dos tareas mezcladas, cada tarea recibe su parque. La inferencia distribuida no es la terquedad de embutir modelos gigantes en una máquina — es la disciplina de cortar el trabajo en piezas justas y correr cada una en el equipo adecuado.