La pregunta que nadie te responde bien
Vale, usas ChatGPT o Claude todos los días. Le preguntas cosas, te responde en segundos, y mientras tanto hay otros tres millones de personas haciendo lo mismo. ¿Cómo es posible?
La respuesta corta es: una barbaridad de hardware, una red que parece ciencia ficción, y un software de serving que es donde está la magia de verdad.
La respuesta larga es este artículo. Agárrate. Que va a flipar.
¿Dónde te cuento más?
Estoy 100% seguro de que este artículo te va a encantar. Te quedarás con ganas de más. Antes de que se olvide, suscríbete a la newsletter para que no se pase una:
1. El hardware: no es “tener muchas GPUs”, es tener las GPUs correctas
GPUs de datacenter: otra liga
Cuando hablamos de inferencia a escala industrial, no estamos hablando de tu RTX 4090 para jugar al Cyberpunk. Estamos hablando de GPUs NVIDIA de datacenter: las H100, H200, y la nueva generación Blackwell (GB200/GB300).
¿Por qué estas y no otras? Por dos cosas:
- Potencia bruta de cómputo para operaciones de Transformers
- HBM (High Bandwidth Memory): memoria con un ancho de banda descomunal
HBM en una frase: Es memoria que está físicamente apilada encima del chip de la GPU, conectada con miles de cables microscópicos. Resultado: puedes mover datos entre la memoria y el procesador muchísimo más rápido que con memoria normal.
Y aquí viene el plot twist:
En inferencia de LLMs grandes, lo que te limita no es el cómputo, es la memoria. Tienes que estar moviendo constantemente los pesos del modelo y el KV cache (luego te cuento qué es esto). Si tu memoria es lenta, da igual que tu GPU sea un cohete.
El truco: “una GPU gigante” en vez de muchas sueltas
Para modelos muy grandes, el problema no es solo tener GPUs potentes. Es cómo las conectas entre sí.
Imagina que tienes un modelo de 400 mil millones de parámetros. No cabe en una GPU. Tienes que repartirlo entre varias. Y cada vez que generas un token, esas GPUs tienen que hablar entre ellas. Si la comunicación es lenta, todo se va al carajo.
Solución: sistemas como el GB200 NVL72, que conectan 72 GPUs en un único dominio NVLink para que se comporten como una sola GPU monstruosa.
NVLink en una frase: Es un bus de comunicación propietario de NVIDIA que conecta GPUs entre sí con un ancho de banda brutal (hasta 900 GB/s por enlace), saltándose el cuello de botella de tener que pasar por la CPU o por PCIe.
Esto permite repartir el modelo y el KV cache entre muchas GPUs sin que la latencia se dispare.
2. La red: dos mundos completamente distintos
Cuando hablamos de red en estos clusters, hay que distinguir dos niveles que no tienen nada que ver entre sí:
Dentro del rack: NVLink y NVSwitch
Aquí hablamos de comunicación entre GPUs que están en el mismo servidor o rack. Esto va por NVLink (el cable gordo entre GPUs) y NVSwitch (un switch que permite que todas las GPUs hablen con todas).
Las características: latencia de microsegundos, anchos de banda de cientos de GB/s. Básicamente, las GPUs se ven como si fueran una sola máquina.
Entre racks: InfiniBand o Ethernet
Aquí la cosa cambia. Cuando tienes que comunicar GPUs que están en racks distintos (o en edificios distintos), usas:
- InfiniBand: El estándar de facto para HPC y AI. Latencias muy bajas, anchos de banda enormes.
- Ethernet de alta velocidad: Algunos despliegues usan Ethernet muy tuneada (100/400 Gbps con RDMA).
InfiniBand en una frase: Es una tecnología de red diseñada para que los datos vayan directamente de la memoria de una máquina a la memoria de otra, sin pasar por el sistema operativo. Latencias de microsegundos en vez de milisegundos.
El objetivo de toda la ingeniería de red es simple: que generar un token no dependa de esperar a que lleguen datos de otro rack. Porque si dependes de eso, la latencia se multiplica y el usuario ve el cursor parpadeando como un imbécil.
3. Memoria: no es solo “el modelo”
Aquí viene un concepto que mucha gente no tiene claro. Cuando cargas un LLM en memoria, no solo ocupas espacio con los pesos del modelo. Hay tres inquilinos:
Los pesos del modelo
Los parámetros del modelo, que pueden estar en varios formatos:
- FP16 (16 bits por parámetro)
- FP8 (8 bits, más comprimido)
- INT4/FP4 (4 bits, cuantización agresiva)
Cuantización en una frase: Es reducir la precisión de los números que representan los pesos del modelo. En vez de usar 16 bits por número, usas 8 o 4. Pierdes algo de calidad, pero el modelo ocupa menos y va más rápido.
El KV cache
Este es el grande. El KV cache almacena información de los tokens anteriores para no tener que recalcularla en cada paso.
KV cache en una frase: Cuando el modelo procesa un token, guarda unos vectores (keys y values) que necesitará para procesar los siguientes tokens. Sin esta caché, cada token nuevo requeriría reprocesar toda la conversación desde cero.
El problema: el KV cache crece con la longitud del contexto y con el número de usuarios concurrentes. Si tienes un contexto de 100K tokens y 1000 usuarios simultáneos, estás hablando de terabytes de memoria solo para cachés.
Buffers y estado del runtime
Espacio temporal para operaciones intermedias, estado del scheduler, colas de peticiones, etc. No es lo más grande, pero suma.
4. Electricidad y refrigeración: el límite físico de verdad
Aquí es donde la cosa se pone seria. Puedes comprar todas las GPUs que quieras, pero:
Potencia eléctrica
Un rack con GPUs de última generación puede consumir 40-100 kW. Un datacenter grande para AI puede necesitar cientos de megavatios. Para que te hagas una idea, eso es el consumo de una ciudad pequeña.
Las empresas de AI están firmando contratos directamente con proveedores de energía y hasta construyendo sus propias plantas.
Refrigeración
Aquí está el muro físico. Con 40-100 kW por rack:
- Refrigeración por aire: Olvídate. El aire no puede llevarse tanto calor.
- Refrigeración líquida: Es el estándar para despliegues densos. Tubos con agua (o líquido refrigerante) que pasan directamente por las GPUs.
Refrigeración líquida directa en una frase: En vez de soplar aire frío sobre los chips, pasas un líquido refrigerante por conductos que tocan directamente los componentes calientes. Mucho más eficiente para disipar calor concentrado.
Los sistemas tipo NVL72 ya vienen diseñados para refrigeración líquida porque, a esa densidad, no hay otra opción.
5. El software de serving: donde está la magia de verdad
Aquí es donde la gente no se entera y donde está la diferencia entre un servicio que funciona y uno que se muere.
Un servicio como Claude o ChatGPT no hace “una inferencia por usuario” de forma aislada. Hace algo muchísimo más sofisticado.
Batching inteligente
El concepto es simple: en vez de procesar una petición, procesamos muchas a la vez.
Batching en una frase: Agrupar múltiples peticiones para procesarlas juntas en un solo pase por la GPU. Las GPUs son muy buenas procesando muchas cosas en paralelo, así que un batch de 32 peticiones puede tardar casi lo mismo que una sola.
El truco está en hacer batching sin destrozar la latencia. No puedes esperar 10 segundos a juntar peticiones. Hay algoritmos que van formando batches dinámicamente, añadiendo peticiones sobre la marcha.
Separar prefill y decode
Esto es clave y poca gente lo entiende. La inferencia de un LLM tiene dos fases completamente distintas:
Prefill: Procesar el prompt inicial. Mucho cómputo de golpe, pero una sola vez.
Decode: Generar tokens uno a uno. Poco cómputo por paso, pero muchos pasos, y la latencia es crítica porque el usuario está esperando.
Prefill vs Decode en una frase: Prefill es leer todo tu mensaje de golpe (intensivo en cómputo). Decode es ir escribiendo la respuesta palabra a palabra (intensivo en ancho de banda de memoria y sensible a latencia).
Los sistemas modernos optimizan estas dos fases por separado y las escalan de forma distinta. Puedes tener pools de GPUs especializadas en prefill y otras en decode.
Disaggregated serving: desacoplar todo
La arquitectura más avanzada descompone el sistema en componentes independientes:
- Nodos de prefill: Procesan prompts
- Nodos de decode: Generan tokens
- Servidores de KV cache: Almacenan y sirven cachés
- Routers: Reparten peticiones según carga
Disaggregated serving en una frase: En vez de que cada servidor haga todo, especializas servidores en tareas concretas y los conectas. Como una cadena de montaje en vez de un artesano que hace todo él solo.
Esto es especialmente importante para modelos MoE (Mixture of Experts).
MoE en una frase: Un modelo que tiene múltiples “submodelos” expertos y un router que decide cuál usar para cada token. Solo activas una parte del modelo en cada paso, así que un modelo de 1 trillón de parámetros puede tener el coste computacional de uno de 100 mil millones.
Trucos para bajar latencia
Además de todo lo anterior, hay técnicas específicas para que la respuesta llegue más rápido:
Speculative decoding: Usas un modelo pequeño y rápido para proponer varios tokens de golpe. El modelo grande los valida en paralelo. Si acierta, te has ahorrado varios pasos.
Speculative decoding en una frase: Un modelo pequeño propone “apuestas” de lo que va a decir el modelo grande. El grande valida las apuestas en un solo pase. Si aciertas 4 tokens de 5, te has ahorrado 4 pasos de decode.
Caché de prompts frecuentes: Si mucha gente hace la misma pregunta, puedes cachear parte del procesamiento.
Reutilización de KV cache: Si una conversación continúa, no recalculas el KV cache de los mensajes anteriores.
6. Los números: ¿cuánto hardware es “esto”?
No hay un número fijo porque depende de:
- Tamaño del modelo
- Si es denso o MoE (y cuántos parámetros activos por token)
- Longitud media de las conversaciones
- Tokens por segundo objetivo
- Usuarios simultáneos
Lo que sí sabemos:
- El gasto en inferencia es gigantesco. Estamos hablando de miles de millones de dólares al año en compute.
- Gran parte se alquila a clouds (Azure, AWS, Google Cloud, Oracle).
- Los despliegues típicos para workloads de OpenAI/Anthropic se asocian a clusters de miles de GPUs en configuraciones NVL72.
Para que te hagas una idea: análisis independientes estiman que OpenAI gasta en compute una cifra de 10 dígitos anuales, y una parte muy relevante es solo para servir inferencia.
7. Cómo se aprovisionan OpenAI y Anthropic
El patrón típico es:
- Usar nubes públicas (Microsoft para OpenAI, AWS y Google para Anthropic) para tener capacidad elástica
- Reservar bloques enormes de GPUs a largo plazo con contratos millonarios
- Montar su propia capa de serving encima de la infraestructura cloud
Las noticias recientes hablan de:
- Acuerdos masivos de capacidad (OpenAI diversificando proveedores)
- Inversiones de infraestructura específicas para Anthropic
- Construcción de datacenters dedicados
Básicamente, estas empresas son de los mayores clientes de infraestructura cloud del mundo.
El resumen
Para servir un LLM a millones de usuarios “en tiempo real” necesitas:
- GPUs de datacenter con HBM (H100/H200/Blackwell) porque lo que te limita es el ancho de banda de memoria
- Interconexión NVLink dentro del rack para que las GPUs se comporten como una sola
- Red rápida entre racks (InfiniBand) para coordinar sin añadir latencia
- Energía y refrigeración a escala porque estamos hablando de megavatios y refrigeración líquida
- Un sistema de serving que haga magia: batching inteligente, separación prefill/decode, disaggregated serving, speculative decoding, cachés…
El hardware es impresionante, pero la diferencia la hace el software. Puedes tener todas las GPUs del mundo; si tu sistema de serving es mediocre, vas a servir a una fracción de los usuarios que podrías.
Y eso, amigos, es cómo funciona la fábrica que hace que puedas preguntarle tonterías a un LLM a las 3 de la mañana y que te responda en dos segundos.