DeepSeek-V4-Flash de 284B corre en 64 GB de RAM sin GPU

Llama-modchip: 284B DeepSeek on 64GB RAM, no GPU

El proyecto llama-modchip comprime el modelo DeepSeek-V4-Flash de 284B parámetros para que quepa en 64 GB de RAM, logrando 44 tok/s en prefill y hasta 14.7 tok/s en decodificación solo con CPU. También acelera modelos MoE de 30B a más de 100 tok/s en Threadripper y reduce el tiempo de restauración de Claude Code a 13 ms. Todo con optimizaciones como compresión SwiGLU-H2 y decodificación especulativa con Stockfish-PVS, sin necesidad de GPU.

Ejecuta DeepSeek-V4-Flash de 284B (menos de 59 GiB de RAM, 44.4 tok/s en prefill, 9.1-14.7 tok/s) y MoEs de 30B (25-111 tok/s) en una CPU pura de 64 GB con contexto de 256K (0 GPUs).
  1. kennywinker

    El piso para un sistema de IA local funcional no deja de bajar, a pesar de que los precios de la RAM y las GPU siguen subiendo. Una estación de trabajo E5 con muchos hilos, 300 $ de RAM y al menos 100 $ de GPU te da algo que puede hacer >100 tok/s de procesamiento de prompt y ~20 tok/s de salida con Qwen3.8-flash-next:IQ3_S. Si le metes una GPU de 500 $, pasa de apenas usable a gratamente rendidor. Por menos de 800 $ tienes algo que se mantiene a la altura de donde estaba el SOTA hace menos de un año.

    No veo cómo alguien justifica una suscripción a Claude. ¿Quieres alquilar las herramientas que usas para ganarte la vida a quienes intentan automatizar tu trabajo?

  2. aappleby

    Pregunta tonta, pero ¿este repo generado por IA realmente _hace_ algo?

    Comparándolo en Nemotron, corre casi igual que el viejo llama.cpp en la CPU (excepto que el prefill parece mucho más rápido). No veo una opción para configurar DeepSeek en "modchip setup", así que ese aún no lo he probado.

    Edición: esto es en un Ryzen 7945hx de 16 núcleos Zen 4 + 96 GB DDR5.

  3. armcat

    Algo a tener en cuenta con la cuantización agresiva es que se ha demostrado empíricamente [1] que (1) la cuantización tiene un comportamiento de rendimiento no lineal, y (2) generalmente la mejor relación tamaño-rendimiento se da a 4 bits; por debajo de eso verás una reducción significativa del rendimiento.

    Además, he estado jugando con modelos de voz durante los últimos 2 años, y para mí cualquier cosa por debajo de 8 bits es una caída enorme de calidad; así que la cuantización para LLMs y para otros modelos de modalidad específica no es 1:1.

    [1] "Reliability Scaling Laws for Quantized Large Language Models", TUM, https://arxiv.org/pdf/2607.10855

  4. sparse-Matrix

    Funciona bastante bien en mi Ryzen 7 5700U/64GB DDR4

    12 a 14 TPS constantes.

    No es una maravilla, ni mucho menos, pero lo suficientemente rápido para hacer trabajo personal significativo, con un consumo de 15 W.

  5. antirez

    Para poner esto en perspectiva, considera que con 128 GB de RAM unificada puede correr incluso rápido: https://x.com/antirez/status/2119392658661749175

    O sea, un agente de programación aceptablemente rápido. Mira más adelante en la respuesta el prefill a ~300 t/s, pero puede ir aún más rápido con prefills más grandes.

  6. boredatoms

    La cuantización es probablemente lo más importante que hay que saber y no queda nada claro en esa ensalada densa de palabras.

  7. akie

    ¿En qué cuantización? Es lo único que quiero saber.

    EDITO: creo que es de 2 bits. Si es así, me interesaría ver la calidad de la salida. No muy buena, creo.

  8. SillyUsername

    Interesante. Hay bastantes forks de llama.cpp en los que el streaming de pesos ha funcionado, o cuantizaciones especiales / descompresión antes del procesamiento.

    - Bonsai Qwen 3.8 27B

    - Strata

    - Pulsar

    - Este...

    Ojalá el upstream de Llama.cpp aceptara los PRs más rápido; compilan varias veces al día, pero su backlog de PRs era de 1.7K la última vez que lo comprobé, lo cual es una cifra ridículamente impracticable de revisar con unos pocos voluntarios.

    Vi la feature de Qwen 3.8 Bonsai y tardó más de 3 semanas desde su creación hasta ser revisada, e incluso entonces no incluye los parches de bugs que arreglaron downstream y simplemente se dieron por vencidos al intentar subirlos al upstream porque el proceso era demasiado laborioso.

    Así que acaban con soporte de modelos retrasado o ausente, e implementaciones a medio funcionar como el Hadamard Folding de Bonsai, y los modelos nuevos se pierden este tipo de optimización.

    Supongo que está bien si pretendes que tu proyecto sea el proyecto de referencia para forks y fomentar este tipo de especialización, pero no creo que sea intencional.

    Al menos puedo usar llamaswap para manejar los motores de inferencia y los modelos sobre la marcha, y abstraer el hecho de que necesito instalar 3 o 4 diferentes.

Más de este día

2026-11-08