Cómo se entrenan y sirven GPT, Claude y Gemini: el cuello de botella real es la memoria

Una extensa clase magistral de Reiner Pope, CEO de MatX y exarquitecto de TPU en Google, ofrece una de las explicaciones más completas sobre cómo se entrenan y se sirven modelos como GPT, Claude y Gemini. Su tesis central es simple pero poderosa: la economía real de la IA depende menos del marketing y más de tres variables duras, batch size, ancho de banda de memoria y diseño de red entre racks.
***

• Reiner Pope explicó por qué pagar más puede reducir la latencia de respuesta en modelos frontier, y por qué un “modo lento” apenas abarataría costos.
• El análisis muestra que el cuello de botella dominante en inferencia no siempre es el cómputo, sino la memoria HBM y el acceso al KV cache.
• La charla también conecta el tamaño de racks, la sparsity, el contexto largo y la topología de red con el precio final de las API de IA.

Entender cómo operan por dentro los grandes modelos de lenguaje se ha vuelto clave para interpretar desde sus precios hasta el ritmo de avance de la industria. En una conversación técnica entre Dwarkesh Patel y Reiner Pope, CEO de MatX y antiguo responsable de arquitectura TPU en Google, se ofreció una visión poco habitual sobre la relación entre hardware, arquitectura de modelos y economía de la inteligencia artificial.

La conversación, presentada como una clase de pizarra, giró alrededor de una pregunta concreta: ¿por qué algunos proveedores permiten pagar varias veces más para recibir tokens apenas unas veces más rápido? Pope sostiene que la respuesta principal está en el batch size, es decir, cuántos usuarios o secuencias procesa el sistema de forma simultánea.

La idea central es que la inferencia de un modelo transformer puede aproximarse con dos límites físicos. Uno es el tiempo de cómputo, asociado a multiplicar los parámetros activos del modelo. El otro es el tiempo de memoria, que incluye tanto la lectura de pesos como el acceso al KV cache, que almacena representaciones internas de tokens previos para que la atención autoregresiva no tenga que recomputarlo todo desde cero.

Para contextualizar, durante el proceso de decode el modelo genera un token nuevo y ese token atiende a todos los tokens previos. Esa atención no está dominada por multiplicaciones de matrices, sino por lecturas de memoria. Allí es donde el ancho de banda de HBM y la forma de organizar lotes de solicitudes pasan a ser variables decisivas.

Por qué pagar más puede dar menos latencia, pero no milagros

Pope explicó que el gran efecto económico en inferencia es la amortización de pesos sobre un lote grande de solicitudes. Si se atiende a un solo usuario a la vez, el costo por token puede ser hasta mil veces peor que si se agrupan muchos usuarios en un batch. Eso ocurre porque leer los pesos del modelo desde memoria es costoso, pero ese costo se reparte mejor cuando el mismo forward pass sirve a muchas secuencias al mismo tiempo.

Cuando el batch crece, la latencia total no cae a cero. Existe un límite inferior. El sistema necesita leer todos los parámetros del modelo desde memoria y eso toma un tiempo fijo mínimo. Según Pope, ese piso de latencia surge de la propia física del hardware disponible y no puede eliminarse solo con cobrar más al usuario.

En el extremo contrario, un hipotético “modo lento” apenas mejoraría la economía una vez que el sistema ya está suficientemente amortizado. La razón es que, incluso si se espera más, ni el KV cache ni el cómputo por batch dejan de ser trabajo específico de cada solicitud. Por eso, una vez alcanzado cierto tamaño de lote, el costo ya no baja mucho más.

La analogía que usó para describir la operación del sistema fue la de un tren que sale a intervalos fijos. Si el lote óptimo tarda, por ejemplo, unos 20 milisegundos en ejecutarse, entonces cada 20 milisegundos parte un nuevo “tren”. Los pasajeros listos suben; si el tren está lleno, esperan el siguiente. Si no está lleno, igualmente sale. En ese esquema, la peor latencia de cola sería cercana a 40 milisegundos.

Pope añadió que esos 20 milisegundos no son arbitrarios. Derivan de una regla práctica vinculada a la relación entre capacidad de memoria y ancho de banda en generaciones modernas de HBM. En el caso citado para Rubin, una configuración de unos 288 gigabytes divididos por unos 20 terabytes por segundo da cerca de 15 milisegundos, una cifra del mismo orden.

El batch óptimo, la sparsity y el papel de DeepSeek

Uno de los resultados más llamativos de la charla es que el batch size necesario para equilibrar memoria y cómputo depende poco del tamaño absoluto del modelo y mucho más de la sparsity. Pope presentó una derivación simple: el batch requerido debe ser mayor que aproximadamente 300 multiplicado por la sparsity del modelo.

En el caso de DeepSeek V3, mencionó unos 37.000 millones de parámetros activos y unos 700.000 millones de parámetros totales. También señaló un esquema en el que se activan 32 expertos de 256. Ese nivel de sparsity da un factor cercano a 8. Con ello, el batch de equilibrio ronda 2.000 secuencias o tokens generados en paralelo, aunque en la práctica suele elevarse dos o tres veces para compensar ineficiencias del mundo real.

A primera vista, 2.000 secuencias concurrentes podrían parecer pocas para un proveedor frontier. Sin embargo, al traducir esa cifra a throughput, Pope estima alrededor de 128.000 tokens por segundo por sistema, usando la aproximación de batch multiplicado por unas 64 iteraciones por segundo. Comparó esa escala con anuncios públicos en los que Gemini habría operado el año anterior en el rango de cientos de millones de tokens por segundo a nivel global.

Eso implica que un sistema de ese tipo sería cerca de una milésima de Gemini, todavía una escala considerable. También sugiere que la economía de batching no necesariamente obliga a una centralización extrema, porque conseguir miles de secuencias concurrentes no es imposible para servicios de gran tamaño.

La sparsity, no obstante, abre otra discusión. Pope recordó un trabajo titulado “Unified Scaling Laws for Routed Language Models”, donde se observa que incrementar el número de expertos puede elevar la calidad manteniendo fijo el número de parámetros activos. Aun así, el rendimiento no mejora gratis. En el ejemplo citado, un aumento muy grande del número total de parámetros produce una mejora más modesta en eficiencia, y además consume más capacidad de memoria.

Cómo se distribuye una capa MoE dentro de un rack

Para entender por qué el tamaño del rack importa, Pope describió la estructura típica de una capa mixture of experts o MoE. Un router recibe tokens y decide a cuáles expertos enviarlos. Cada experto es, en esencia, un MLP normal con proyección ascendente, no linealidad y proyección descendente. Luego, las salidas se reúnen y se suman con la conexión residual.

La práctica estándar consiste en usar expert parallelism. En lugar de poner todos los expertos en un solo procesador, se reparten entre GPUs distintas. Pope ilustró el caso de un rack Blackwell con 72 GPUs, simplificando a 64 para que un diseño con 256 expertos pueda distribuirse en 4 expertos por GPU. Ese mapeo permite un tráfico all-to-all dentro del rack.

Ahí entra la topología de interconexión. En la descripción ofrecida, las GPUs de Nvidia se conectan dentro del rack mediante NVLink y NVSwitch, formando una red scale-up en la que cualquier GPU puede hablar con otra en dos saltos. Fuera del rack, la comunicación pasa a una red scale-out, típicamente unas 8 veces más lenta en ancho de banda.

El problema aparece cuando una capa MoE se extiende a más de un rack. En promedio, la mitad de los tokens querrán salir del rack para alcanzar expertos alojados en otro lugar. Esa porción del tráfico queda limitada por la red más lenta. Según Pope, por eso un solo rack tiende a fijar el tamaño máximo práctico de una capa de expertos, y por eso la industria empuja dominios scale-up cada vez más grandes.

Además del ancho de banda, existe una restricción física. El salto desde Hopper a Blackwell se vinculó, en parte, a pasar de bandejas a racks como formato de producto. Y el incremento hacia Rubin exige diseños de rack más complejos. No se trata solo de lógica de red, sino de densidad de cables, radios de curvatura, peso total del rack, potencia eléctrica y refrigeración.

Pipelining, memoria y por qué la inferencia no siempre lo aprovecha

La conversación también revisó pipeline parallelism, una técnica que divide las capas del modelo entre distintos racks o etapas. Conceptualmente, es una forma natural de cortar el modelo por profundidad: un rack procesa ciertas capas y el siguiente continúa con las siguientes. Eso reduce la memoria de pesos necesaria por rack.

En inferencia, sin embargo, la ventaja no es tan amplia como podría parecer. Pope señaló que pipelining casi no mejora la latencia por sí mismo. Solo redistribuye el trabajo entre más racks. Además, cada salto entre racks añade latencia de red, que podría estar en el orden de unos pocos milisegundos por hop, aunque aclaró que ese valor depende mucho del hardware y la implementación.

Más importante aún, el pipelining ayuda a recortar la memoria usada por pesos, pero no resuelve bien el consumo por KV cache. Cuando se introducen micro-batches para mantener ocupadas todas las etapas del pipeline, el ahorro por dividir capas se compensa con el aumento de secuencias simultáneas en vuelo. El resultado es que la huella de KV cache por GPU no cae de forma significativa.

Por eso, para inferencia, Pope indicó que lo que tiene más sentido es maximizar expert parallelism dentro del dominio scale-up y usar muy poco pipelining, quizá ninguno o apenas el necesario para que los pesos no sean un problema. Añadió que tensor parallelism, antes más relevante, pierde atractivo cuando los expertos se vuelven más pequeños.

La conclusión práctica fue directa: muchos modelos frontier durante inferencia operan, esencialmente, dentro de un solo dominio scale-up. Si el modelo es demasiado grande para un rack, entonces sí aparece algo de pipelining, pero como solución puntual y no como estrategia dominante.

El muro de memoria y el estancamiento del contexto largo

Uno de los tramos más relevantes de la charla se refiere al llamado memory wall. Aunque la narrativa pública suele enfocarse en FLOPs y capacidad de cómputo, Pope defendió que el gran límite actual para contexto largo y latencia es el ancho de banda de memoria. En decode, los costos ligados al KV cache crecen con la longitud de contexto.

La discusión ayuda a interpretar por qué varios modelos ampliaron rápidamente sus contextos desde cerca de 8.000 tokens hasta un rango de 100.000 o 200.000, pero luego parecieron estancarse. Pope sugirió que ese rango podría coincidir con una zona de equilibrio razonable entre memoria y cómputo. Ir mucho más allá se vuelve prohibitivamente caro, no tanto por cómputo como por ancho de banda de memoria.

El entrevistado también comentó que sparse attention puede mejorar la situación, ya que ciertas variantes cambian el crecimiento lineal por algo más favorable, incluso con términos de raíz cuadrada en algunos trabajos de DeepSeek. Pero eso no elimina el problema por completo, porque si la atención se vuelve demasiado dispersa, la calidad del modelo puede caer.

Esta lectura se conecta con debates más amplios sobre aprendizaje en contexto. Si se asumiera que una IA verdaderamente general puede operar durante periodos muy largos solo con in-context learning, entonces serían necesarios contextos masivos, quizá del orden de decenas o cientos de millones de tokens. Pope fue escéptico sobre una ruta simple hacia ese objetivo con el hardware actual.

Qué revelan los precios de las API sobre el costo real

La conversación también trató de inferir aspectos internos de los modelos a partir de sus precios públicos. Al discutir diferencias de precio para contextos largos, Pope dibujó una curva de costo frente a longitud de contexto en la que el componente de cómputo permanece casi plano por token, mientras el de memoria crece hasta cruzarlo en un punto de inflexión.

Si un proveedor cobra más allá de cierto umbral, como 200.000 tokens en el ejemplo planteado por el entrevistador, eso sugiere que la estructura de precios está alineada con ese cruce. No implica una coincidencia perfecta, pero sí que el proveedor busca preservar margen cuando la memoria se vuelve dominante.

También abordaron la diferencia entre input y output tokens. Cuando el input pasa por prefill, muchos tokens se procesan en paralelo y el costo por token baja porque la carga fija de memoria se divide entre más trabajo útil. En cambio, el output en decode avanza token por token y queda mucho más expuesto al límite de memoria. De allí que, según la observación citada en la charla, el output pueda costar entre 3 y 5 veces más que el input.

Algo similar ocurre con los cache hits. Si un proveedor mantiene el KV cache en una jerarquía de memoria, puede resultar más barato reutilizarlo que recomputarlo. Pope planteó una jerarquía con HBM, DDR, flash e incluso disco mecánico. A partir de horizontes de retención de 5 minutos y 1 hora mencionados en el intercambio, sugirió que ciertos precios de escritura y reutilización podrían apuntar a tiers como flash o incluso spinning disk, algo llamativo por tratarse de una tecnología antigua pero todavía útil en ciertos casos.

Entrenamiento, RL y una hipótesis sobre sobreentrenamiento

Hacia el final, Pope intentó una aproximación de primer principio para relacionar costo de pretraining, reinforcement learning e inferencia. Partió de la conocida fórmula 6ND para entrenamiento, donde forward más backward equivalen a 6 operaciones por parámetro y dato, y comparó eso con el costo de RL y de inferencia, donde un forward simple se aproxima con factor 2.

Su hipótesis fue que, como regla general, los sistemas tienden a optimizar donde costos comparables se igualan. Bajo varias suposiciones heurísticas sobre ineficiencias en RL y throughput de inferencia, la conclusión tentativa es que los tokens de inferencia, los de pretraining y los de RL podrían terminar siendo del mismo orden de magnitud, con diferencias de factor pero no de varios órdenes.

Al llevar ese marco a una estimación concreta, la conversación ensayó números como unos 50 millones de tokens por segundo por modelo específico y una vida útil de despliegue de unos dos meses, lo que arrojó cerca de 200 billones de tokens de inferencia. Frente a una estimación mencionada de 150 billones de tokens de pretraining y un número Chinchilla de alrededor de 2 billones, Pope y Patel plantearon la posibilidad de que modelos frontier estén sobreentrenados en torno a 100 veces respecto al óptimo clásico de Chinchilla.

Ambos admitieron grandes márgenes de error y corrigieron números sobre la marcha, pero el punto de fondo fue que estos cálculos aproximados permiten intuir por qué la industria podría estar desviándose de antiguas reglas de escalado. Ya no basta con optimizar solo el entrenamiento. También hay que optimizar el costo total de servir el modelo a gran escala.

En conjunto, la clase de How GPT, Claude, and Gemini are actually trained and served – Reiner Pope, presentada por Dwarkesh Patel con Pope como expositor, sugiere que la próxima frontera de la IA no depende solo de modelos más grandes. Depende también de memoria más rápida, interconexiones más amplias y decisiones de arquitectura que minimicen cuellos de botella físicos muy concretos.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín