Ask HN: Si ChatGPT puede dar servicio a 700 millones de personas, ¿por qué yo no puedo ni ejecutar un solo GPT-4 en local?

• Sam Altman anunció que ChatGPT atiende a aproximadamente 700 millones de usuarios por semana
• Al ejecutar un modelo de nivel GPT-4 en local, la falta de VRAM y la baja velocidad son graves, y surge la duda de cómo OpenAI maneja un uso a tan gran escala con baja latencia y alto rendimiento
• Quiere entender técnicas que van más allá de un simple clúster de GPU, como optimización de modelos, procesamiento distribuido, hardware dedicado y balanceo de carga

---

Resumen de los comentarios clave

1. Estructura de inferencia distribuida a gran escala

• Model Sharding
  • Los parámetros se almacenan distribuidos entre varias GPU
  • Cuando llega una solicitud, cada GPU realiza cálculos sobre su parte de los parámetros y luego se combinan los resultados
• Tensor Parallelism
  • Varias GPU ejecutan en paralelo los cálculos dentro de una misma capa
• Pipeline Parallelism
  • Las capas se dividen en varias etapas para procesarlas de forma secuencial y simultánea, como en una tubería
• Se usa paralelismo mixto para optimizar la memoria de GPU y la carga de cómputo

2. Optimización de memoria y velocidad

• Quantization: convierte los parámetros a una precisión de menos bits para reducir el uso de VRAM
• Offloading de capas: mueve algunas capas a la memoria de CPU cuando hace falta
• LoRA / Adapter Layers: solo se ajustan finamente tareas específicas (fine-tuning), evitando recargar todo el modelo
• KV Caching: reutiliza el contexto para eliminar cálculos repetidos

3. Hardware dedicado y networking

• Uso masivo de NVIDIA H100, A100 y algunas TPU de última generación
• Transferencia de datos ultrarrápida entre GPU con NVLink y NVSwitch, y entre clústeres con Infiniband
• Construcción de una red troncal global entre centros de datos para minimizar la latencia

4. Distribución geográfica y balanceo de carga

• Despliegue de granjas de GPU en múltiples regiones del mundo
• Con GeoDNS, las solicitudes de los usuarios se conectan a la región más cercana
• Los clústeres de GPU se escalan dinámicamente según los patrones de tráfico
• Si una región concentra demasiada carga, el tráfico global se redistribuye

5. Optimización del procesamiento de solicitudes

• Batch Inference: agrupa solicitudes de varios usuarios para hacer la inferencia de una sola vez
• Preprocesamiento con modelos pequeños: las solicitudes simples se resuelven con modelos pequeños, y solo las complejas llaman a un modelo grande
• Caching de resultados: los resultados de prompts idénticos o solicitudes similares se devuelven de inmediato desde caché
• Prompt engineering evita desperdiciar tokens innecesariamente

6. Optimización operativa y de costos

• Se minimizan los recursos ociosos con monitoreo y scheduling del uso de GPU
• Mejora de la eficiencia energética de los centros de datos e incorporación de refrigeración líquida
• Mejora de la velocidad de inferencia con optimizaciones propias de compilador y runtime
• Operación de pipelines automatizados para actualización y despliegue de modelos

Ejemplo de flujo de arquitectura integral

1. Recepción de la solicitud del usuario → enrutamiento a la región más cercana con GeoDNS
2. Preprocesamiento → las solicitudes simples van a un modelo pequeño; solo las complejas se envían a un modelo grande
3. Procesamiento de inferencia distribuida
   • Se aplica model sharding + tensor parallelism + pipeline parallelism
   • Se intercambian resultados intermedios mediante redes de alta velocidad entre GPU
4. Posprocesamiento y caching de resultados → se guarda caché para solicitudes idénticas o similares
5. Entrega de la respuesta → resultados en 1~2 segundos

[popkins]

En el caso de OpenAI, no solo usan hardware de NVIDIA, también están usando MI300X de AMD para inferencia; para entrenamiento sí es solo NVIDIA.
En inferencia, están obsesionados con asegurar VRAM como sea en relación con el costo de inversión.
En el caso de Microsoft, pasa lo mismo: para inferencia están mezclando NVIDIA y AMD.

[popkins]

Especialmente en las regiones de Azure en Asia, la proporción de AMD que usa OpenAI es más o menos NVIDIA 8 / AMD 2.

[GN⁺]

Opinión de Hacker News

• Trabajo directamente con este tipo de sistemas en Google (opinión personal) y puedo decir con certeza que hay gente muy inteligente pensando seriamente en todos los aspectos del problema. No puedo contar mucho más, pero sí quiero compartir material que escribieron colegas. Hay una excelente explicación de arquitectura de aceleradores y de cómo optimizar para lograr altas velocidades en el scaling book. En particular, si te interesa la parte de inferencia, el capítulo de inferencia ayuda bastante. Además recomiendo las guías de unsloth. Profundizan en distintos modelos para encontrar optimizaciones y las presentan muy bien organizadas. Además de la guía de Gemma 3n, hay varias más

  • Para explicarlo con un poco menos de misterio, la inferencia es (en su mayor parte) una tarea sin estado. Por eso no hace falta preocuparse por consistencia de memoria entre cientos de miles de máquinas ni por fallas entre máquinas, como en el entrenamiento. Solo hay que encargarse de enviar una pequeña cantidad de datos a máquinas muy grandes. Las máquinas de investigación con las que yo trabajaba eran equipos ultrapotentes con 8 GPU, y si el modelo cabía en la VRAM total combinada, prácticamente cualquier tarea se podía ejecutar bien. El ingrediente secreto para escalar a gran escala era una “cantidad absurda de capital”. Incluso una vez NVIDIA nos envió una máquina DGX dorada, pero no era muy densa y era carísima. La mayoría de las grandes empresas ya tienen sistemas estables de RPC y orquestación, así que la parte realmente difícil no es mover mensajes, sino meter el modelo en hardware que lo soporte bien (aunque esa no es mi especialidad)

  • Los racks modernos para inferencia a gran escala, las técnicas conocidas de RDMA y redes de baja latencia, y las fuertes optimizaciones de MLA y caché no necesitan describirse como si fueran tecnología mística. Todo eso ya se entiende bastante bien de forma pública, y de hecho cuando una empresa famosa hace algo demasiado customizado, muchas veces hasta resulta una carga por compatibilidad con lo heredado. Lo que de verdad importa es tener bien armado el sistema y los procesos necesarios para operar sistemas grandes. Eso abarca desde compra de equipos y entrenamiento de SRE hasta RTL para nuevos TPU. Si alguien estuviera 10 veces por delante, se notaría enseguida (persona con 10 años de experiencia en inferencia a gran escala dentro del TOP-5)

  • Sobre la frase “somos gente muy inteligente que piensa muy seriamente en todos los problemas”, en realidad puede verse como que están haciendo sistemas de tiempo compartido al estilo mainframe de los años 70

  • Me pregunto si Google, gracias a los TPU, no tendrá una rentabilidad mucho mayor en la inferencia de sus propios modelos que alquilando tarjetas NVIDIA. Entiendo que OpenAI consigue la mayoría de sus GPU a través de su alianza con Microsoft. Tanto el enlace como el libro estuvieron muy interesantes

  • Me llamó la atención la frase: “incluso los modelos ‘pequeños’ de hoy operan cerca de los límites del hardware”. Suena parecido a aquello de los años 60 y 70 de que “incluso los programas pequeños se ejecutan al límite del hardware”. Aunque la optimización y la eficiencia hayan desaparecido en gran parte de la ingeniería de software, en el desarrollo de LLM siguen muy vivas

• Un H100 cuesta 20 mil dólares y tiene 80GB de VRAM. Puedes imaginar un servidor de rack 2U con 100 mil dólares en tarjetas de ese tipo. Si llenas un rack completo con ese equipo y sumas CPU, RAM y refrigeración, estás hablando de alrededor de un millón de dólares por rack (sin contar costos operativos ni personal de mantenimiento). Incluso el equipo “barato” se maneja en unidades de cómputo gigantescas. Espero que cuando reviente la burbuja de la IA sea realista correr buenos modelos locales. En 10 años, un servidor de 100 mil dólares de estos podría venderse en eBay por 3 mil, y hasta me imagino a electricistas recibiendo pedidos para instalar 240V en cocheras o cuartos improvisados para servidores

  • Ni siquiera hace falta esperar 10 años: ya puedes comprar un DGX-1 en eBay por menos de 10 mil dólares. Tiene 256GB de VRAM (HBM2), NVLink, 512GB de RAM, CPU de 40 núcleos, SSD de 8TB y HBA de 100Gbit. Las versiones que no son de marca NVIDIA se consiguen hasta por 6 mil. Eso sí, es extremadamente pesado, muchísimo más ruidoso de lo que imaginas, y una sola unidad casi consume todo un circuito de 240V 16A. Además genera 13,000 BTU de calor por hora al mismo tiempo

  • Incluso si la burbuja de la IA no explota, es muy probable que esos servidores terminen en eBay en 10 años. Los datacenters van a actualizar hardware y vender el usado a terceros

  • Personalmente sospecho que los modelos abiertos usan mucho menos cómputo del que solemos pensar. En los modelos modernos Mixture of Experts, gracias a la estructura de top-k sampling donde solo se activan algunos expertos (parámetros), incluso un modelo SOTA no necesariamente requiere mucho más cómputo que un modelo non-MoE de 70-80B

  • A nivel empresarial, en serving de IA la verdadera pregunta no es “cómo atender a los usuarios”, sino que los inversionistas esperan ROI en algún momento. La infraestructura que haga falta se puede construir mientras siga entrando inversión. Incluso sin optimización, si hace falta, se pueden levantar más almacenes y racks y dar el servicio así

  • No soy estadounidense, así que me dio risa lo de 240V

• Si tú tienes algunos miles de dólares, ellos tienen decenas de miles de millones. La diferencia de escala es 1,000 vs 10,000,000,000. La eficiencia que tienen también es uno o dos órdenes de magnitud mayor por escala. Además, incluso en una MacBook (24GB de RAM) ya puedes correr modelos locales comparables al rendimiento del GPT-4 de lanzamiento. Enlace de comparación de rendimiento

  • Si distribuyes en el tiempo a 700 millones de usuarios a lo largo de un día o una semana, en realidad podría haber solo unas 10 millones de sesiones activas al mismo tiempo. Un usuario individual no puede acumular una semana de recursos de cómputo y gastarlos todos de golpe, pero un proveedor de servicios sí puede escalar horizontalmente y dimensionarse para el pico. Por eso, con el mismo nivel de rendimiento requerido, un entorno local termina necesitando mucho más hardware

• Incluso un solo nodo con GPU ofrece FLOPs y ancho de banda de memoria muy altos. Cuando procesas pocas solicitudes, muchas veces la GPU pasa más tiempo esperando a hacer streaming de los pesos desde la RAM hacia las unidades de cómputo. Si agrupas solicitudes en batch, puedes leer un bloque de pesos una sola vez y usarlo para procesar muchas solicitudes en paralelo, maximizando la eficiencia. Además, puedes comprimir el modelo a 8 bits o menos para reducir el volumen de datos en streaming, y las GPU modernas soportan operaciones de 8 bits y 4 bits. Los modelos Mixture of Experts usan solo una parte de los parámetros por token, así que hace falta cargar menos pesos. La técnica de speculative decoding usa un modelo pequeño para predecir de antemano varios tokens y luego el modelo principal adopta solo los que coinciden. Todas estas optimizaciones juntas producen una eficiencia excelente (basado en experiencia como director del equipo de inferencia en Databricks)

• Uno de los ingredientes secretos de OpenAI es perder miles de millones de dólares. Perdió 5 mil millones en 2024. Artículo relacionado

  • Ahora con los enfoques agentic la situación cambió bastante. Antes era 1 solicitud por 1 procesamiento; ahora, para una sola tarea, se hacen cientos de procesamientos en paralelo. Gracias a ese paralelismo, OAI/Azure tiene ventaja frente a los modelos locales

  • Si eliminaran I+D y solo dieran servicio con modelos existentes, parece que podrían llegar al punto de equilibrio

  • Dio justo en el punto. Incluso después de que la inversión de hasta 10 mil millones de dólares de Microsoft cubriera preentrenamiento, I+D y costos de inferencia, igual siguieron perdiendo miles de millones. Es la estructura del capitalismo orientado al crecimiento al estilo VC

• En inferencia a gran escala, agrupar solicitudes en batch para procesarlas juntas es muchísimo más eficiente que asignar una GPU por usuario, como en un entorno personal. Si quieres conocer algunos trucos de ingeniería de nivel intermedio, puedes ver un artículo que escribió nuestro equipo en el blog de Fin AI. (Seguramente OpenAI y otros también usan técnicas privadas que no aparecen ahí). Post relacionado

  • Esta es la verdadera respuesta clave. Más que muchas de las otras cosas discutidas arriba, el batching es lo que realmente baja los costos de forma drástica. Por ejemplo, si procesar una solicitud costara 50 mil dólares, gracias al batching podrías procesar 100 solicitudes al mismo tiempo con esos mismos 50 mil, casi sin pérdida. No sé exactamente cuántos usuarios puede atender un mismo hardware en la práctica, pero imagino que del orden de cientos. Eso significa bajar efectivamente el costo de 50 mil a 500 dólares (cuando hay suficientes usuarios). El cuello de botella en el procesamiento de LLM casi siempre es el tiempo de cargar los pesos a la GPU, así que en lugar de procesar cada solicitud por separado, se maximiza la eficiencia procesando juntas las operaciones de varias solicitudes. Por ejemplo, si tres conjuntos de pesos (A, B, C) caben en la caché de la GPU y hay dos solicitudes (1, 2), el enfoque normal sería cargar pesos para cada solicitud por separado; en cambio, con batching cargas los pesos una vez y calculas varias solicitudes. Si comparas el tiempo de carga de pesos con el tiempo de cómputo, la diferencia de velocidad antes y después del batching se vuelve muy marcada. En la realidad, cargar pesos es muchísimo más lento que computar, así que mientras más usuarios haya, mayor es la diferencia. En la práctica también hace falta memoria para el estado de activación a fin de soportar más usuarios, así que hay que equilibrar cuántos meter por clúster de GPU. En resumen, el hardware para serving de LLM es muy caro, pero si ya lo tienes, puedes atender a cientos de usuarios al mismo tiempo casi sin degradación de rendimiento

• Tener 700 millones de usuarios semanales no dice gran cosa sobre la carga real. Incluso si la mayoría de usuarios de ChatGPT lo usara una hora al día todos los días de la semana, seguiría inactivo el 96% del tiempo. Mucha gente además usa solo modelos menos complejos. El hecho de que se hable de “usuarios semanales” sugiere, de hecho, que incluso entre los usuarios activos diarios hay varios que no lo usan ni una vez al día. Los desafíos clave son 1) construir servidores donde el modelo quepa en memoria y procese tokens a suficiente velocidad, 2) tener suficientes servidores para el throughput pico total de tokens, y 3) distribuir eficientemente todas las solicitudes entre los servidores. Hay muchos detalles, pero en realidad la última tarea se parece bastante a operar un buscador. Todo el estado está en el historial del chat, así que no hace falta que el mismo chat sea atendido siempre por el mismo servidor. Cuando aparece el mensaje “Thinking...”, no queda expuesto si el modelo realmente está computando o si simplemente está esperando en cola a que haya un servidor disponible

• Uno de los mayores secretos para que los LLM funcionen bien a escala es el “batch size”. Hoy en día la mayoría de los LLM usan arquitectura “Mixture of Experts”, que activa solo una parte de los parámetros totales en cada instante. Gracias a eso, el procesamiento en batch a gran escala es mucho más eficiente. Si quisieras correr GPT-4 en casa, necesitarías poder meter el modelo completo en VRAM, así que harían falta varias GPU como una H100 (unas 40 mil por tarjeta). Pero con un uso personal no podrías aprovechar de verdad esas tarjetas. Es parecido a preguntar: “¿por qué Apple puede fabricar iPhones para miles de millones de personas y yo no puedo fabricar ni uno en mi cochera?”

  • En resumen, la carga de inferencia se distribuye bien entre muchos usuarios y por eso funciona de forma eficiente

  • Entonces me pregunto si sería posible una estructura donde las partes de uso menos frecuente estén en memoria principal y las partes más usadas en VRAM

  • La analogía es muy acertada

• Un truco que también se puede aplicar en casa y que es importante en el rendimiento de Cerebras es speculative decoding. Este método usa un modelo borrador mucho más pequeño para predecir tokens con muchísimo menos cómputo y memoria, y luego el modelo principal adopta los tokens que él mismo probablemente habría elegido. En una configuración bien afinada, se puede lograr hasta 3x de mejora de velocidad. Además, en structured output se puede aplicar “fast forwarding” para saltarse tokens predecibles, por ejemplo precargando el formato inicial en JSON, y así aumentar la velocidad hasta 3x

  • En LM Studio puedes probar speculative drafting combinando gpt-oss-120b y gpt-oss-20b. Aun así, no sentí que el rendimiento mejorara tanto

• El núcleo de la inferencia de LLM es la multiplicación matriz-vector. Cuando hay que procesar muchas consultas al mismo tiempo, se pueden juntar los vectores de cada consulta en una matriz y calcular todo simultáneamente mediante multiplicación matriz-matriz. Desde el punto de vista del hardware, en lugar de gastar tiempo repitiendo multiplicaciones matriz-vector una y otra vez, una sola multiplicación matriz-matriz es muchísimo más eficiente. Eso es precisamente el procesamiento por lotes. El segundo truco es speculative decoding. La inferencia tiene dos etapas: procesamiento del prompt y generación de tokens, y en realidad ambas comparten la misma estructura de “forward pass”. El procesamiento del prompt se puede paralelizar con multiplicación matriz-matriz, y solo el último resultado se usa para iniciar la generación de tokens. Pero como normalmente no se conocen los tokens futuros, esa parte no suele poder paralelizarse. Por eso se usa un modelo borrador rápido para predecir los próximos N tokens, se agregan al prompt de entrada y luego se ejecuta un forward pass paralelo con el modelo principal. De los N tokens generados, todos los que coincidan hasta el primer token válido pueden aceptarse inmediatamente como salida. En teoría, esto puede dar una mejora de velocidad de inferencia de 2x a 4x. Yo no lo he implementado directamente como trabajo, pero además supongo que también aplican agrupación paralela por longitud de consulta o balanceo de carga en tiempo real (porque no todas las solicitudes tienen necesariamente la misma longitud, y hace falta evitar desequilibrios de recursos)