Por qué DeepSeek es barato a gran escala, pero caro en local

• Algunos modelos de IA como DeepSeek-V3 son baratos y rápidos cuando se ofrecen a gran escala, pero al ejecutarse en local son lentos y costosos
• La razón está en un trade-off fundamental entre throughput (rendimiento) y latency (latencia) relacionado con la eficiencia de uso de la GPU
• Si se aumenta el tamaño del batch, la GPU trabaja con mayor eficiencia, pero el usuario debe esperar a que se acumulen los tokens, lo que provoca mayor latencia
• Los modelos con arquitectura Mixture-of-Experts y pipelines profundos requieren batches grandes y más latencia
• En un entorno local de un solo usuario, es difícil formar un batch lo suficientemente grande, lo que provoca menor rendimiento y mayores costos
• OpenAI, Anthropic y otros logran respuestas rápidas mediante una arquitectura más eficiente, estrategias avanzadas de batching o incluso usando una cantidad excesiva de GPU

---

Inferencia por lotes y eficiencia de la GPU

• La GPU es hardware optimizado para multiplicación de matrices a gran escala (GEMM)
• Si los tokens de varios usuarios se agrupan y se ejecutan como una matriz grande en batch, el throughput mejora drásticamente gracias a la baja sobrecarga de ida y vuelta y la eficiencia de memoria
• El servidor de inferencia acumula en cola los tokens de varias solicitudes, selecciona un batch de tamaño adecuado y ejecuta operaciones GEMM a gran escala
• En este proceso, el servidor debe elegir entre el trade-off de tamaño del batch (más throughput) y tiempo de espera (más latencia)

Por qué algunos modelos están optimizados para batches grandes

Mixture of Experts (MoE) y batching

• La arquitectura MoE (DeepSeek-V3, estimado GPT-4) es una causa principal de baja eficiencia de GPU
• Como cientos de bloques “expertos” requieren multiplicaciones de matrices separadas, en batches pequeños cada experto tiene poco trabajo y la eficiencia cae
• Solo con muchas solicitudes simultáneas se pueden aprovechar suficientemente todos los expertos, así que a nivel de servicio los batches grandes son esenciales
• Con una espera corta (ventana de 5 ms), los expertos quedan inactivos con frecuencia; con una espera larga (ventana de 200 ms), se puede maximizar la eficiencia

Problemas de batching en modelos con pipelines profundos

• Los transformers grandes con cientos de capas se ejecutan dividiendo las capas entre varias GPU (pipelining)
• Si la cantidad de tokens dentro de un batch es menor que los pasos del pipeline, aparece el fenómeno de pipeline bubble, lo que reduce el throughput
• Para evitarlo, es indispensable usar batches grandes (y por tanto más espera), lo que alarga el tiempo de respuesta del modelo

Por qué no siempre se puede mantener la cola llena

• En teoría, si hubiera suficiente tráfico concurrente como para llenar siempre la cola, parecería posible evitar las burbujas
• Pero en la práctica, en la etapa de Attention del transformer solo se puede hacer batching si todas las matrices tienen la misma longitud, por lo que es difícil que una sola cola funcione de manera perfecta
• Además, si se separan las etapas de FFN y attention, aumentan fuertemente la sobrecarga de memoria y los problemas de ineficiencia por movimiento de datos

Resumen y conclusión

• El procesamiento con batches grandes es esencial para reducir el costo de GPU y mejorar el throughput, pero aumenta el tiempo de espera del usuario
• Los modelos con Mixture-of-Experts y arquitecturas de pipeline grande están optimizados de forma inherente para entornos de batching de alta eficiencia basados en espera
• En entornos con poco tráfico, como el uso local, no es posible construir batches grandes optimizados, por lo que la eficiencia de GPU cae bruscamente y el costo de ejecución sube
• OpenAI, Anthropic y otros muestran alta rapidez de respuesta, y esto podría deberse a que
  • (1) usan una arquitectura más eficiente que MoE
  • (2) aplican optimizaciones avanzadas de batching/pipeline y trucos sofisticados de inferencia
  • (3) podrían estar usando muchas más GPU de las necesarias para “comprar” velocidad

Extra: diferencia entre el batch de prefill y el batch del cuerpo principal

• En los transformers, también es posible ejecutar en batch el prefill (entrada larga) del prompt de un usuario para acelerar la inferencia inicial
• Sin embargo, el batching discutido en el texto se refiere al trade-off entre throughput y latencia durante la etapa real de generación de tokens de múltiples solicitudes de usuarios
• El batch de prefill no está directamente relacionado con el batching concurrente de gran tamaño mencionado en el texto

Notas adicionales

• Los sistemas de inferencia reales también suelen usar continuous batching, ejecutando de inmediato cuando el batch se llena
• Pero la estructura fundamental del trade-off entre throughput y latencia sigue siendo la misma

[GN⁺]

Opiniones en Hacker News

• Estoy ejecutando DeepSeek V3 directamente en casa, y me parece que el costo es manejable y que la velocidad y el rendimiento son satisfactorios. Mucha gente piensa que no se pueden correr modelos grandes sin GPU, pero por mi experiencia, un servidor con CPU puede ser incluso más práctico y consumir menos energía. Mi servidor casero usa una placa Supermicro con un EPYC serie 9004 de gama media y 384 GB de RAM; el costo total fue de unos 4000 dólares. Sin GPU, usando solo mucha RAM, a veces el consumo eléctrico es incluso menor que el de una desktop gamer. Uso modelos Unsloth Dynamic GGUF con unos 270 GB de RAM, y en la práctica soportan varias tareas con una calidad casi igual a la original. Normalmente lo corro con contexto de 16k y, si hace falta, lo extiendo hasta 24k. La velocidad de generación es de 9 a 10 tokens por segundo, y con contextos grandes baja a 7. También hay casos de entornos con 2 CPU que ejecutan el modelo completo a una velocidad de tokens aún mayor
  • Me da curiosidad qué tan cerca está realmente el rendimiento de Unsloth Dynamic GGUF respecto al original. En mi experiencia, en tareas simples la diferencia no es grande, pero en tareas complejas o con contexto largo sí se nota claramente. Es cierto que Unsloth está haciendo un gran trabajo, pero es una lástima que falten evaluaciones comparativas directas contra el modelo original sin cuantizar. También es una limitación realista que muchas personas y empresas no tienen forma de correr el modelo original por sí mismas
  • Me pregunto si es posible correr DeepSeek para generación de código con una herramienta como Ollama en una CPU de 40 núcleos y 256 GB de RAM. Estoy pensando en asignarle unos 200 GB de memoria al modelo
  • Mención de que el sitio personal no está accesible. Me presento como Jeff Carr, cofundador de DigitalOcean, con la esperanza de poder establecer contacto
  • Pensaba que una GPU con memoria de alta velocidad era indispensable, pero pregunto si de verdad es posible hacer inferencia sin GPU usando solo gran cantidad de memoria. Me intriga cómo puede funcionar esto solo con memoria no unificada
  • Coincido en que DeepSeek V3 es realmente muy práctico entre los modelos open-weight. Muchas tareas no requieren tantos reasoning tokens como uno pensaría, y la ventaja es que no hay que esperar. También resulta atractivo poder elegir una opción de reasoning más alta cuando se necesite. Si no lo ejecutas tú mismo, también hay algunos proveedores que ofrecen el contexto completo (16k), 80 tps y prometen no usar los datos. Buen ejemplo de uso de un home server 9004, se ve como una gran configuración
• Me parece que este post del blog es impresionante. Estoy de acuerdo con la conclusión (“se necesita batching”), pero creo que la discusión sobre inferencia en modelos MoE debería ser más matizada. La razón por la que un batch grande es importante es que el cuello de botella en la inferencia de LLM no es la falta de cómputo, sino cargar todos los weights desde la VRAM. Si comparas los TFLOPS y el ancho de banda de memoria de un H100, sale que en realidad hay margen para procesar unas 300 FLOP por byte. Mientras más grande sea el batch, más cómputo puedes hacer por cada parámetro cargado, así que hay que maximizar el tamaño del batch. Por eso se usa el término “roofline model”. A medida que el modelo crece, ya no cabe completo en la VRAM, así que hay que distribuirlo entre varias GPU o nodos. Incluso con NVLink o Infiniband, eso sigue siendo más lento que cargar directamente desde VRAM, así que aparece otro cuello de botella. La fortaleza de MoE es el expert parallelism: poner distintos experts en memoria en nodos distintos y minimizar la comunicación entre nodos. Pero eso solo es posible cuando hay suficientes nodos para que todos los experts quepan en VRAM junto con sobrecargas como la caché KV. Al final, el batch size termina creciendo de forma natural, y hay que hacerlo así para que cada GPU trabaje eficientemente
  • Propongo asignar distintos "experts" a un nodo en round-robin y agrupar oportunistamente en batch solo cuando varias solicitudes usen el mismo expert. Sería como tener una cola en lugar de batching puro, así que la latencia sube, pero en entornos como flujos de trabajo de investigación profunda puede ser perfectamente tolerable
  • Cuando el modelo no cabe en una sola GPU, existe un caso real donde la inferencia se hace dividiéndolo por capas y enviando pequeños vectores a la GPU responsable de la siguiente capa para continuar el cómputo. Cerebras hace esto y en Llama 4 Maverick logra 2500 billones de tokens por segundo. Mover vectores sobre el fabric es tan rápido que casi no hay idle time
  • Imagino la posibilidad de que todo fuera mucho más rápido si todos los nodos y weights estuvieran colocados en circuitos analógicos
  • Una de las lógicas para invertir en AMD es que el modelo completo puede caber en un solo chasis, con ventajas tipo map/reduce y menos costo en equipos de red. Si alguien opina lo contrario, me interesaría conocer ese insight
• Resumen en una línea para quien quiera ahorrar tiempo: la respuesta es inferencia por lotes. Consiste en meter simultáneamente los prompts de varias personas en una instancia del modelo, y en la práctica es mucho más eficiente que solo hacer multiplexación temporal muy apretada. Por eso, incluso si fijas la temperatura y el seed, las respuestas del servicio pueden variar cada vez, porque no puedes controlar con qué otros prompts se batchéa el tuyo. Incluso imagino que este fenómeno podría convertirse en un vector de ataque para exfiltración de datos
  • Una de las ventajas del batching es que, cuando quieres evaluar repetidamente el mismo contenido y comprobar si realmente hay "hallucination", puedes lanzar de golpe tantas pruebas como el batch-size. En realidad, el concepto de batch siempre estuvo en los LLM, pero uno suele apreciar su verdadero valor con el tiempo
  • Yo asumía de forma simple que los proveedores siempre hacían batching en todos los modelos, pero me da curiosidad si esto aplica solo a ciertas familias de modelos
  • Me pregunto por qué el hecho de ser batchéado junto con otros prompts hace que la respuesta del modelo varíe
  • Si tu prompt puede quedar agrupado con el de otra persona, eso suena como un vector de ataque muy efectivo
• Dicho de forma concisa:<br>- Los modelos con alta sparsity necesitan batches grandes (muchas solicitudes simultáneas) para que una sola operación de multiplicación de matrices sea lo suficientemente intensiva en cómputo<br>- Para manejar batches de ese tamaño, hacen falta unas 8 a 16 GPU para que los weights del modelo y la caché MLA/KV quepan en HBM. Pero con solo 8 a 16 GPU, el throughput total es bajo, así que la velocidad de respuesta para cada usuario se vuelve realmente lenta. Para que la experiencia sea fluida, probablemente hacen falta unas 256 GPU
  • Yo estoy dando servicio de DeepSeek en un entorno con 16 H100 (2 nodos). Veo entre 50 y 80 tokens/segundo por solicitud, con throughput estable de hasta varios miles de tokens en total. El tiempo hasta el primer token también es estable, y la experiencia es más rápida que cualquier servicio en la nube al que tengamos acceso
  • Se dice que alta sparsity = necesidad de batch grande, pero no termino de entender esa conexión. Casi lo digo en tono burlón, pensando que sparse matmul es básicamente una matmul con muchos ceros
• Me parece una excelente explicación desde la perspectiva de los LLM. Imagino que las empresas hyperscale de LLM analizan con mucho detalle los traces reales de cómputo para encontrar cuellos de botella, y que se toman muy en serio la optimización de cargas mediante load balancers, arquitecturas de pipeline, schedulers, etc. El “prerrequisito de batching” para ganar eficiencia puede jugar en contra en aplicaciones muy sensibles en seguridad, porque aislar las consultas se vuelve extremadamente caro. La virtualización vGPU de NVIDIA divide la memoria de GPU por time-slicing, pero sospecho que en cada context switch hace falta descargar y volver a cargar, sin deduplicación. MIG también divide la memoria de forma fija por usuario, pero para reajustarlo hay que reiniciar la GPU; entiendo perfectamente la frustración de no querer partir una GPU de 96 GB en 4x24 GB. También imagino si agregar memoria secundaria (DRAM) a la tarjeta GPU permitiría subir distintos datos de matrices más rápido que por PCIe, usando HBM como caché.<br>También se elogia la franqueza del libro Software Engineering Survival Guidebook
• Hay margen para muchas más optimizaciones de software para DeepSeek. En la práctica, solo se han optimizado por accesibilidad dos tipos de sistemas: GPU pequeñas con mucha RAM (ktransformers), o sistemas con cantidades enormes de VRAM. Una arquitectura con 192 GB de VRAM + el resto en memoria normal (DGX Station, 2xRTX Pro 6000, etc.) podría correr DeepSeek 4bit bastante rápido gracias al poder de MoE. Si el prompt de DeepSeek no está en chino, la mayoría de los experts ni siquiera se activan. Eso también facilita más el pruning. Todo indica que los sistemas enthusiast van en una dirección que encaja con este tipo de optimización por software. En Reddit también hay ejemplos de un sistema 16x3090 (Pcie 3.0 x4) logrando unos 7 tokens por segundo en llama.cpp, y como una sola 3090 puede escanear toda su VRAM 39 veces por segundo, parece que debe haber otros cuellos de botella de rendimiento
  • El consumo eléctrico de un sistema 16x3090 es nada menos que 5 KW. A ese nivel, si piensas en la factura de luz, usar la API sale más barato. Además, si no usas prompts en chino en DeepSeek, muchos experts no se activan, lo que hace imaginar formas de aligerar el modelo y enrutar los tokens hacia experts más cercanos
  • Una MI300x puede ofrecer 192 GB de VRAM
• No soy investigador de ML ni ingeniero, así que tómenlo con esa salvedad. DeepSeek V3/R1 es tan grande comparado con los modelos locales anteriores que, en efecto, ejecutarlo localmente sale caro. Los parámetros activos son menos que el tamaño total, pero eso solo reduce los requisitos de cómputo; los de memoria siguen siendo los mismos, así que para la mayoría es prácticamente imposible usarlo de verdad sin una GPU enorme. Tampoco se puede comparar directamente con los principales modelos frontier propietarios, porque no se publica información como su tamaño. Y tampoco hay base para esperar que esos modelos corran más barato en local. De hecho, MoE ofrece un mejor tradeoff para entornos locales o de usuario único, porque la ineficiencia del batching no pesa tanto ahí. Si aumentas el batch, la latencia de espera por token puede subir hasta 200 ms, pero a cambio la operación feed-forward (GEMM) se vuelve más grande y por eso el cómputo se hace de manera más eficiente. Me pregunto si al crecer el batch realmente crece la matriz en sí. En mi modelo mental, el objetivo del batch no es “aumentar el tamaño de la matriz de entrada”, sino “mover la limitación desde el ancho de banda de memoria hacia un cuello de botella de cómputo”. Los weights ya se trocean por capas y se cargan de HBM a SRAM, se multiplican por bloques y al final se suman los resultados. Con batching, la ventaja es procesar muchas operaciones a la vez con los mismos weights y así maximizar eficientemente los FLOPS. También dudo de qué tan cierto es que modelos gigantes como los de OpenAI o Anthropic respondan tan rápido como se dice, porque el post no da cifras de time to first token y por eso me parece débil en evidencia
  • Soy el autor del post original. No soy investigador de ML, sino un ingeniero con mucho interés en el tema. En el escenario local de usuario único con MoE, la idea es que, como no existe la ventaja del batching multiusuario, el throughput por GPU cae de forma dramática. Eso pasa a menos que estés lanzando una cantidad enorme de solicitudes de inferencia en paralelo. Al aumentar el tamaño de la matriz de entrada mediante batching, con batch 1 la operación es una matriz de 1xdim; cuando sube el batch, pasa a ser de batch-size x dim, así que la utilización de la GPU aumenta muchísimo y se logra pasar a un cuello de botella de cómputo. Y sí, si usas bastante DeepSeek, se nota que realmente es más lento que otros modelos
• Los mixture of experts necesitan batches grandes, pero con Apple Silicon vale la pena incluso con batch size 1. Gracias a la unified memory, es posible ejecutar localmente modelos grandes, aunque con menor ancho de banda y menos FLOPS, por lo que funcionan relativamente más lento. La característica de MoE es que en cada paso hay que procesar menos parámetros, así que la carga de cómputo es menor. Hay bastantes experiencias de gente que ha corrido DeepSeek en Mac con inferencia de batch único a velocidades razonables. Claro, sigue siendo caro comprar suficiente memoria instalada. Si en el futuro aparecen más máquinas tipo Mac o con una estructura parecida, se dice que serían una combinación ideal con modelos MoE. En comparación, correr modelos dense en una Mac con mucha RAM ampliada es bastante más doloroso
• Hablando con un colega, llegué a la conclusión de que, cuando usamos LLM para apoyo en programación, los modelos están evolucionando en una dirección que se aleja de la optimización esencial. Por políticas internas comparo casi todo con modelos locales de 4 a 30B y varias series de GPT; en particular, GPT-4o da resultados sobresalientes en promedio, pero también tiene tendencia a “inventarse partes de la respuesta”, así que hay que invertir bastante tiempo en verificar e iterar. Al final, me queda la impresión de que “la diferencia frente a modelos locales de pocos parámetros no es tan grande como parece en relación con el esfuerzo”. El problema es que ambos son realmente lentos, así que no permiten iteración rápida. Yo preferiría mucho más un modelo de gran contexto que responda al instante, aunque la calidad sea menor. Más que la mejora en métricas de calidad, deseo que importe más la “velocidad de iteración percibida” en la experiencia real
• No estoy de acuerdo con la afirmación de que “es lento y caro”. Hay casos de workstations viejas basadas en memoria DDR4 que, usando llama.cpp, pueden sacar 3 tokens por segundo con sistemas de alrededor de 1000 dólares
  • Puede que estés confundiendo el modelo real de DeepSeek con una versión distilled. Sin al menos 192 GB de RAM, no se puede correr el modelo verdadero