Modelo MoE de 284B corre en CPU sin GPU: así funciona

⏱️ Lectura: 16 min

Un modelo MoE en CPU de 284.330 millones de parámetros corriendo sin una sola GPU, en una computadora de 64 GB de RAM, suena a error de imprenta. El proyecto llama-modchip lo logra con DeepSeek-V4-Flash a 44,36 tokens por segundo en la etapa de prefill y entre 9,1 y 14,7 tokens por segundo generando texto. No hay truco de marketing detrás: son tres técnicas de ingeniería (cuantización agresiva, offloading selectivo de expertos y cacheo de contexto) que explican por completo el resultado.

📑 En este artículo

1. TL;DR
2. ¿Qué es un modelo MoE en CPU?
3. Por qué importa correr mezcla de expertos sin GPU
4. Cómo funciona la inferencia en RAM pura
   1. Cuantización agresiva: de 82 GB a 56 GB
   2. Offloading selectivo de expertos: qué se queda caliente y qué se transmite
   3. Cacheo de contexto: 256K tokens sin recalcular nada
5. Ejemplos prácticos: qué rendimiento esperar por tipo de máquina
   1. Cómo probarlo
6. Casos de uso reales para inferencia en RAM pura
7. Errores comunes y buenas prácticas
8. Comparativa con alternativas de cuantización
9. Profundizando: el detalle detrás del tiling y el rollback especulativo
10. Preguntas frecuentes
    1. ¿Qué es un modelo MoE en CPU y en qué se diferencia de uno denso?
    2. ¿Cuánta RAM necesito para correr DeepSeek-V4-Flash con llama-modchip?
    3. ¿El offloading selectivo de expertos reduce la calidad de las respuestas?
    4. ¿llama-modchip también puede usar una GPU si la tengo disponible?
    5. ¿Qué tan rápido se restaura el contexto de un agente con inferencia en RAM pura?
11. Referencias
    1. 📚 Artículos relacionados

TL;DR

• DeepSeek-V4-Flash (284,33B parámetros totales, 13,17B activos) corre completo en 56,56 GiB gracias a una cuantización de 1,71 bits por peso.
• El enrutamiento top-6 sobre 256 expertos por capa activa apenas el 2,3% de los expertos disponibles en cada paso.
• El offloading selectivo mantiene calientes solo los expertos frecuentes y transmite los fríos sin desalojar la caché L3 del procesador.
• Un drafter especulativo de 1,64 MB acelera la generación sin necesitar una segunda GPU.
• Restaurar un contexto de 256K tokens desde /dev/shm toma entre 13,1 y 32,6 milisegundos, no minutos.

¿Qué es un modelo MoE en CPU?

Un modelo MoE en CPU es un sistema de mezcla de expertos (Mixture-of-Experts) que ejecuta inferencia completa en memoria RAM del procesador, sin GPU, activando por token solo una fracción de sus parámetros totales mediante enrutamiento dinámico, cuantización agresiva del checkpoint y técnicas de caché que evitan intercambiar datos con el disco.

El caso que mejor ilustra la técnica es llama-modchip, un conjunto de parches sobre los kernels de ggml y llama.cpp. No es un modelo nuevo: es una capa de transcodificación de cuantización y herramientas de runtime que toma checkpoints MoE existentes, como DeepSeek-V4-Flash o Nemotron-3.5-30B-A3B, y los adapta para correr en procesadores x86_64 con AVX-512 o AVX2, y en ARM64 con NEON, SVE o Metal.

DeepSeek-V4-Flash organiza sus 284,33B parámetros en 43 capas de atención latente multi-cabeza (MLA) y 256 expertos enrutados por capa. Esa arquitectura explica por qué la cuantización y el offloading funcionan capa por capa: cada una de las 43 capas MLA decide de forma independiente a cuáles de sus 256 expertos consultar en cada token.

Lo primero que hay que entender es el problema de tamaño. Una build estándar UD-IQ1_S de DeepSeek-V4-Flash ocupa 76,87 GiB (82,5 GB), mientras que un sistema Linux de 64 GB físicos solo expone unos 62,5 GiB utilizables. La diferencia, casi 14,4 GiB, es la que provoca thrashing de la caché de páginas o un OOM kill antes de que el modelo termine de cargar.

Por qué importa correr mezcla de expertos sin GPU

Que un modelo de mezcla de expertos de esta escala corra sin GPU importa porque invierte la relación habitual entre tamaño y costo de hardware. De los 284,33B parámetros totales de DeepSeek-V4-Flash, solo 13,17B están activos en cualquier paso de inferencia: apenas el 4,6% del total. Esa dispersión es la que vuelve viable ejecutar un modelo de esta escala en una máquina de escritorio en vez de un clúster de GPUs.

💭 Clave: si solo el 4,6% de los parámetros participa en cada token, mover el 95,4% restante entre RAM y caché sin penalizar el rendimiento es el verdadero problema de ingeniería, no entrenar un modelo más chico.

El mismo enfoque escala hacia arriba y hacia abajo. En una laptop de 16 a 32 GB basta un modelo más chico, como Nemotron-3.5-30B-A3B cuantizado a 3,75 bpw en 14,35 GiB, para alcanzar entre 25,0 y 60,4 tokens por segundo. En el otro extremo, una workstation Threadripper de 8 canales con AVX-512BW satura el ancho de banda de DDR5 y empuja ese mismo tipo de modelo de 30B hasta 111,62 tokens por segundo, también sin GPU.

Nemotron-3.5-30B-A3B toma un camino distinto: en vez de capas de atención tradicionales, usa 46 capas de Mamba-2, un modelo de espacio de estados (SSM) que no necesita un KV cache tradicional. Eso le permite sostener un contexto de 256K tokens con solo 432 MB de KV cache, mucho menos de lo que necesitaría una arquitectura de atención pura del mismo tamaño.

Cómo funciona la inferencia en RAM pura

La inferencia en RAM pura descansa en tres decisiones de diseño que actúan en capas distintas: cuánto espacio ocupa el checkpoint en disco, qué pesos viajan a través de la jerarquía de caché del procesador en cada token, y qué parte del cómputo ya hecho se puede reutilizar entre turnos de conversación.

flowchart TD
A["64 GB RAM física"] --> B["62.5 GiB utilizables en Linux"]
B --> C["56.56 GiB pesos del modelo cuantizado"]
B --> D["KV cache a 256K de contexto"]
B --> E["Margen para el sistema operativo"]
subgraph Presupuesto
C
D
E
end

Cuantización agresiva: de 82 GB a 56 GB

La cuantización reduce la precisión numérica de cada peso para que ocupe menos espacio en RAM. Un modelo en BF16 usa 16 bits por peso; llama-modchip empuja esa cifra hasta 1,71 bits por peso de media (bpw) para DeepSeek-V4-Flash, lo que explica por qué el checkpoint pasa de 76,87 GiB a 56,56 GiB en disco.

No toda la red se cuantiza igual. Las normas y el estado de las capas recurrentes se mantienen en F32 para no perder estabilidad numérica, mientras que los expertos fríos (los que rara vez se activan) reciben los esquemas más agresivos, como el formato Fractal-64 de Nemotron, que agrupa 64 pesos por bloque con un escalar en BF16 y llega a 3,75 bpw sin perder puntaje en los benchmarks internos de calidad del proyecto (100/100 en benchmarks/eval_quality).

Offloading selectivo de expertos: qué se queda caliente y qué se transmite

Una idea común, y equivocada, es pensar que llama-modchip descarta expertos para ahorrar cómputo. Por defecto evalúa los seis expertos enrutados de cada capa (Top-6 sobre 256 expertos totales) sin ningún pruning adicional: la dispersión ya viene del enrutador del propio modelo, no de un recorte posterior.

Lo que sí optimiza es cómo llegan esos pesos a la CPU. Los parches de kernel reemplazan el streaming de expertos fríos con instrucciones _MM_HINT_NTA (acceso no temporal), que cargan los pesos sin marcarlos como datos reutilizables en caché. Así evitan que un experto que se usa una sola vez por token desaloje las líneas de caché L3 que sostienen la atención y el KV cache, esos sí reutilizados en cada paso.

sequenceDiagram
participant R as Router
participant H as Experto caliente
participant F as Experto frío
participant L as Caché L3
R->>H: activa experto frecuente
H-->>L: reutiliza línea de caché
R->>F: activa experto raro
F-->>L: stream con hint no temporal
Note over F,L: el experto frío no desaloja la caché caliente

El mismo parche introduce un esquema de tiling multi-columna en cuatro niveles: registro ZMM de AVX-512BW, L1D de 32 KB, L2 de 1 MB y L3 de 64 MB, con bloques de {8,4,3,2} columnas para el producto matriz-vector cuantizado del prefill. En un procesador Zen 5 de 16 núcleos, ese cambio llevó el rendimiento de prefill de 25,0 a 44,36 tokens por segundo (+77%), y una FlashAttention MQA8 register-stationary sumó otro 53% al decode.

Cacheo de contexto: 256K tokens sin recalcular nada

El tercer pilar es no recalcular lo que ya se procesó. Con contexto de 256K tokens, el KV cache de DeepSeek-V4-Flash ocupa buena parte del presupuesto de RAM: el VmRSS pico del proceso llega a 57,61 u 58,9 GiB, de los cuales una porción considerable es caché de atención y no pesos del modelo.

Para sesiones de agentes que abren y cierran contexto todo el tiempo, por ejemplo un flujo de 40 herramientas en Claude Code, llama-modchip guarda snapshots del estado de KV en /dev/shm, memoria compartida respaldada por RAM. Restaurar uno de esos snapshots toma entre 13,1 y 32,6 milisegundos, frente a los segundos que costaría reprocesar el prompt completo desde cero.

Para acelerar la generación token a token, el proyecto combina esa caché con decodificación autoespeculativa: un drafter liviano de 1,64 MB basado en n-gramas de Zobrist (adaptado de un algoritmo de ajedrez, Stockfish-PVS v2) propone varios tokens candidatos que el modelo grande verifica en paralelo en vez de generarlos uno por uno. Un fix de rollback especulativo en tiempo $O(1)$ evita que los estados recurrentes y MLA de arquitecturas tipo deepseek4 queden corruptos cuando el drafter se equivoca y hay que descartar un token.

flowchart LR
A["Drafter Stockfish-PVS 1.64 MB"] --> B["Propone tokens candidatos"]
B --> C["Modelo grande verifica en paralelo"]
C -->|"tokens aceptados"| D["Se agregan a la salida"]
C -->|"token rechazado"| E["Rollback O(1) de estados MLA"]
E --> A

Ejemplos prácticos: qué rendimiento esperar por tipo de máquina

El rendimiento de un MoE sin GPU depende mucho más de la clase de hardware que del tamaño nominal del modelo. Esta tabla resume las cuatro configuraciones que documenta el propio proyecto:

Cómo probarlo

El repositorio incluye un script install.sh en la raíz y guías específicas para Apple Silicon, Fedora y Windows en sus carpetas apple-silicon/, fedora/ y windows/. Como las dependencias exactas (versión del compilador, flags de AVX-512, submódulos de llama.cpp) cambian según la distribución y la CPU, lo más seguro es seguir el quickstart del README oficial en vez de copiar un comando genérico: un flag de compilación equivocado para tu procesador puede impedir que el binario arranque.

Casos de uso reales para inferencia en RAM pura

El caso más concreto que documenta el proyecto es el de agentes de código que abren sesiones largas. Un flujo típico de Claude Code con 40 herramientas activas se beneficia directamente de restaurar contexto desde /dev/shm en milisegundos en vez de volver a procesar el prompt completo en cada reinicio de sesión.

Otro caso de uso es el de desarrolladores que quieren evaluar llms en CPU con arquitecturas MoE completas, con sus 256 expertos y su enrutador real, sin pagar por GPUs en la nube. Y en el extremo de hardware híbrido, una GPU de 16 GB alcanza para mantener caliente el tronco de atención mientras los expertos fríos quedan en RAM del sistema, una combinación que en el benchmark del proyecto llega a 80,80 tokens por segundo con Nemotron-30B o Qwen3-30B.

Errores comunes y buenas prácticas

El error más frecuente es asumir que cualquier build pública de un modelo MoE cabe en 64 GB. Una build estándar UD-IQ1_S de DeepSeek-V4-Flash pesa 76,87 GiB: hace falta específicamente el formato de llama-modchip, de 56,56 GiB, para que entre en el presupuesto real.

⚠️ Ojo: calculá siempre contra los 62,5 GiB utilizables de un sistema Linux de 64 GB, no contra los 64 GB nominales: el sistema operativo y los buffers se quedan con el resto.

Otro error es confundir offloading selectivo con pruning de expertos: como ya se explicó, el proyecto evalúa los seis expertos de cada capa sin recortar ninguno. Optimiza el movimiento de datos, no la cantidad de cómputo.

La tercera trampa es ignorar el swap. El diseño completo apunta a cero intercambio con NVMe: si el sistema empieza a paginar a disco, la latencia se dispara aunque el proceso técnicamente siga corriendo. Para confirmar qué formato de cuantización quedó cargado, el log de arranque del binario imprime el bpw efectivo de cada tensor; si ese detalle no aparece en tu build, es señal de que estás corriendo el checkpoint estándar y no el de llama-modchip. Y como el rendimiento depende del set de instrucciones SIMD disponible, conviene medir con tu propia CPU antes de asumir que los 44,36 tok/s del Zen 5 de 16 núcleos se repiten en un procesador con solo AVX2.

Comparativa con alternativas de cuantización

No todos los formatos de cuantización hacen el mismo compromiso entre tamaño y calidad. La siguiente tabla compara las tres variantes que llama-modchip ofrece para Nemotron-3.5-30B-A3B:

La alternativa de usar GPU completa sigue siendo más rápida en términos absolutos, pero exige memoria de video que un modelo de 284B simplemente no consigue en una tarjeta de consumo. La inferencia en RAM pura no compite en velocidad pico: compite en que corre, punto, sin inversión adicional en hardware.

Profundizando: el detalle detrás del tiling y el rollback especulativo

El esquema de tiling de cuatro niveles no es solo una optimización de caché: es un cambio en el orden en que se recorren las columnas de la matriz de pesos. Procesar varias columnas a la vez por bloque de registro reduce la cantidad de veces que el mismo bloque de L2 o L3 se vuelve a traer desde RAM, que es la operación más cara en un procesador moderno.

El bloque de tiling no es un número fijo: el runtime evalúa las combinaciones {8,4,3,2} columnas por nivel de caché y elige la que más rendimiento da para el tamaño de matriz de cada capa, porque una capa con más expertos activos por token no se beneficia igual de un bloque de 8 columnas que una capa con pocos.

El rollback especulativo en tiempo $O(1)$ resuelve un problema específico de las arquitecturas con estados recurrentes tipo Mamba-2 o MLA: a diferencia de un transformer puro, donde descartar un token especulativo rechazado es trivial, estos modelos acumulan un estado comprimido que cambia con cada token procesado. Sin un mecanismo de rollback eficiente, deshacer un token mal especulado obligaría a recalcular el estado completo desde el último checkpoint válido, lo que anularía la ganancia de la decodificación especulativa.

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: cloná el repositorio de llama-modchip y corré primero el modelo Nemotron-3.5-30B-A3B en formato Q4_0 para medir cuántos tokens por segundo te da tu propia CPU, antes de intentar cargar el checkpoint completo de 284B.

Preguntas frecuentes

¿Qué es un modelo MoE en CPU y en qué se diferencia de uno denso?

Un modelo MoE en CPU activa solo una fracción de sus parámetros por token mediante un enrutador, mientras que un modelo denso usa el 100% de sus pesos en cada paso. Esa dispersión es la que permite que un modelo de 284B parámetros totales solo necesite mover 13,17B parámetros activos por token.

¿Cuánta RAM necesito para correr DeepSeek-V4-Flash con llama-modchip?

El proyecto reporta un pico de 57,61 a 58,9 GiB de VmRSS con contexto de 256K tokens, dentro de los 62,5 GiB utilizables de un sistema Linux con 64 GB físicos de RAM. Con menos de eso, el sistema recurre a swap o directamente falla por OOM.

¿El offloading selectivo de expertos reduce la calidad de las respuestas?

No. Por defecto se evalúan los seis expertos enrutados de cada capa (Top-6 sobre 256), igual que en una build sin optimizar. Lo que cambia es cómo esos pesos viajan por la jerarquía de caché, no cuántos expertos participan en el cálculo.

¿llama-modchip también puede usar una GPU si la tengo disponible?

Sí, en modo híbrido: mantiene el tronco de atención y las capas SSM en la GPU con -ngl 99 mientras deja los expertos MoE fríos en RAM del sistema. En esa configuración, con una GPU de 16 GB, el proyecto reporta 80,80 tokens por segundo con Nemotron-30B o Qwen3-30B.

¿Qué tan rápido se restaura el contexto de un agente con inferencia en RAM pura?

Entre 13,1 y 32,6 milisegundos para un snapshot de KV cache guardado en /dev/shm, según el tamaño del prompt. El caso documentado es un flujo de 40 herramientas de Claude Code, muy por debajo de los segundos que tomaría reprocesar el prompt desde cero.

Referencias

• GitHub: synchopate/llama-modchip: repositorio oficial con el README, los benchmarks y la documentación de arquitectura del proyecto.
• GitHub: ggml-org/llama.cpp: el runtime de inferencia sobre el que llama-modchip aplica sus parches de kernel.
• Wikipedia: Mixture of experts: explicación general de la arquitectura de enrutamiento condicional que usan estos modelos.
• GitHub: DeepSeek AI: organización oficial que publica los checkpoints base de la familia DeepSeek-V4.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Imagen destacada: Foto de Brian Kostiuk en Unsplash