Avanzado 20 minllama.cpp

DeepSeek V3.2 localmente: MoE 671B accesible a los mortels

Instalar DeepSeek v3.2 en local implica asumir una realidad: 671 mil millones de parámetros totales, 37 mil millones activos por token y un nuevo mecanismo de atención dispersa que cambia las reglas del juego con los contextos largos. Esta guía presenta los requisitos de hardware reales (no los de marketing), explica la cuantización Q2_K_XL de ik_llama, muestra la proeza del offload selectivo mediante --override-tensor y termina con los tokens/segundo medidos en una estación de trabajo doméstica en 2026.

Por Mohamed Meguedmi·Actualización 2026-08-27·Probado en Windows, macOS y Linux

#Por qué instalar DeepSeek V3.2 en local

DeepSeek V3.2 es la actualización intermedia publicada por DeepSeek AI a finales de 2025, bajo licencia MIT, que introduce dos cambios significativos respecto a V3: DeepSeek Sparse Attention (DSA), un mecanismo de atención dispersa que hace que el coste de memoria del contexto largo sea subcuadrático, y un refinamiento del entrenamiento de predicción de múltiples tokens. Sobre el papel, se mantiene la calidad de V3 y se gana en eficiencia con 128k+ tokens.

Instalarlo en local responde a tres necesidades concretas: confidencialidad total (ningún documento se envía a DeepSeek), reproducibilidad (los pesos no desaparecen de un día para otro) y experimentación libre (sin límites de frecuencia de solicitudes ni filtros de moderación impuestos).

i
Seamos honestos sobre el objetivo
Un despliegue local de DeepSeek V3.2 no es un reemplazo en tiempo real de ChatGPT. Se busca más bien un rendimiento útil (5–15 tok/s) en una estación de trabajo doméstica potente, para razonamientos en lote, síntesis de documentos largos o código complejo, donde la calidad es más importante que la latencia.

#MoE 671B / 37B activos + DeepSeek Sparse Attention

El kit de IA Local

Tu ChatGPT privado y gratuito en tu máquina en 1 hora — LM Studio, Ollama, Open WebUI, tus documentos, sin nube.

  • Espacio en línea de por vida
  • PDF + archivos
  • Reembolsado 30 j
El kit de IA Local →o todos los kits de por vida — 49 € →

DeepSeek V3.2 mantiene la arquitectura MoE de V3: un router elige 8 expertos de 256 por capa, lo que hace trabajar solo unos ~37 mil millones de parámetros por cada token generado. Los otros 634 mil millones duermen, pero deben seguir siendo accesibles, de lo contrario el router pierde acceso a los expertos que no ha cargado.

Parámetros totales
≈ 671 mil millones (no importa la tasa de bits, es esta cantidad la que debe alojarse en algún lugar: RAM, VRAM o SSD a través de mmap).
Parámetros activos por token
≈ 37 mil millones. Este número determina la velocidad teórica: un MoE 671B soporta el costo de cómputo de un modelo denso de 37B.
Expertos por capa
256 expertos MoE + 1 experto compartido, enrutamiento top-8. Cuanta más RAM tengas, más capas de expertos permanecen en memoria y más estable es la generación.
Atención
Multi-Head Latent Attention (MLA) heredada de V3, ahora combinada con DeepSeek Sparse Attention (DSA) en contextos > 32k tokens.
Contexto
128k tokens anunciados, utilizables en la práctica gracias a DSA: la caché KV ya no se dispara de forma lineal como en un modelo denso clásico del tipo Qwen 3.5 o Gemma 4.
→
Lo que realmente cambia DSA
DeepSeek Sparse Attention selecciona para cada token un subconjunto de posiciones a esperar, en lugar de barrer todo el contexto. A 128k, divide el consumo de memoria del cache KV por 3 a 5 según el ajuste, y acelera el prefill en la misma proporción. Este es el único argumento técnico que justifica buscar V3.2 en lugar de V3 si quieres aprovechar los contextos largos.

#Requisitos de hardware explicados con honestidad

Ninguna configuración de consumo puede ejecutar DeepSeek V3.2 sin malabarismos. Estos son los tres perfiles realistas en 2026, ordenados según el equilibrio entre velocidad y presupuesto.

Perfil A — DDR5 potente (192–384 GB)
Estación de trabajo con Threadripper 7960X / Xeon W o EPYC 9354P, 256 GB DDR5 ECC (8 canales), sin necesidad de GPU. Q2_K_XL cabe íntegramente en la RAM. Velocidad: 5–9 tok/s usando solo la CPU.
Perfil B — RTX 5090 + 192 GB DDR5 (recomendado)
El punto óptimo de 2026: RTX 5090 (32 GB GDDR7, ancho de banda de 1792 GB/s) + 192 GB DDR5 en una plataforma reciente de consumo. Se mantienen las capas de atención y el experto compartido en la GPU, y el resto en RAM. Velocidad: 10–15 tok/s en generación.
Perfil C — RAM modesta + SSD NVMe Gen 4/5
96–128 GB de DDR5 + SSD NVMe de al menos 7 GB/s, ≥ 1 TB libre. Los expertos se mapean en memoria desde el SSD mediante mmap. Velocidad: 1,5–3 tok/s — utilizable en procesamiento por lotes nocturno, no en modo interactivo.
!
192 GB DDR5, el mínimo vital
Con menos de 192 GB de RAM, la cuantización Q2_K_XL (~220 GB para V3.2) no cabe en la memoria física y el sistema recurre constantemente a la paginación desde el SSD. Incluso con un NVMe Gen 5 rápido, caerás por debajo de 2 tok/s. Si el presupuesto para RAM es limitado, baja a IQ1_S en lugar de saturar el SSD.

#1. Elegir la cuantización para V3.2

El ecosistema GGUF para DeepSeek V3.2 está impulsado por dos actores principales: Unsloth (que publica las variantes UD = «Unsloth Dynamic», entre ellas la famosa Q2_K_XL) y bartowski. Las UD utilizan una matriz de importancia para mantener las capas sensibles (atención, experto compartido) con una precisión mayor que el resto, lo que supone una diferencia real en la práctica para la calidad final.

IQ1_S (~150 GB)
Cuantización dinámica de 1 bit. Cabe en 192 GB de RAM con margen. Calidad degradada, pero utilizable para chat general. Evitarla para tareas de código.
Q2_K_XL (~220 GB)
La referencia ik_llama / Unsloth Dynamic. Conserva las capas críticas en Q4-Q5 y comprime los expertos a Q2. ~95 % de la calidad Q4 en los benchmarks de razonamiento. Cabe en 256 GB de RAM o en 192 GB más un poco de offload en SSD.
Q3_K_S (~290 GB)
Para estaciones de trabajo con 384 GB. Calidad casi Q4 en contextos largos. Se recomienda si planeas usar seriamente los 128k tokens.
Q4_K_M (~400 GB)
A pleno rendimiento. Reservado para servidores EPYC de doble socket con 512 GB o más de memoria DDR5. Más allá, la mejora de calidad se vuelve marginal para un uso local.
→
¿Por qué Q2_K_XL y no Q2_K_S?
En un MoE de 671B, la sensibilidad a la cuantización es muy heterogénea: las capas de atención y los enrutadores toleran mal Q2, mientras que los expertos FFN lo toleran bien. Q2_K_XL respeta esta distribución (precisión mixta), mientras que Q2_K_S aplica la misma cantidad de bits en todas partes. Con aproximadamente un 5 % más de memoria, se gana alrededor de un 10 % de calidad en las tareas de código.

#2. Compilar ik_llama.cpp (el fork que gestiona V3.2)

En el momento de escribir estas líneas, la rama principal de ggerganov/llama.cpp admite DeepSeek V3.2, pero sin optimizaciones específicas para el enrutamiento MoE de DeepSeek. El fork ik_llama.cpp (Iwan Kawrakow) incluye kernels CUDA acelerados para los tensores de los expertos y soporte dinámico de DSA: una mejora del 30 al 50 % en la velocidad de generación de V3.2 según la configuración.

Clonar y compilar ik_llama.cpp (CUDA + Flash Attention)
git clone https://github.com/ikawrakow/ik_llama.cpp
cd ik_llama.cpp
cmake -B build \
  -DGGML_CUDA=ON \
  -DGGML_CUDA_FA_ALL_QUANTS=ON \
  -DGGML_CUDA_F16=ON
cmake --build build --config Release -j $(nproc)

En un Mac con Apple Silicon, reemplazar GGML_CUDA por GGML_METAL. En AMD, usar GGML_HIP con ROCm 6.3+. Calcula entre 10 y 15 minutos de compilación en una máquina reciente: es C++ con generación de código CUDA; no inicies la compilación en un portátil sin conectarlo a la red eléctrica.

i
¿Por qué ik_llama en lugar de un binario precompilado?
Existen versiones de ik_llama.cpp para Linux/Windows, pero los kernels CUDA generados durante la compilación dependen de la capacidad de cómputo de tu GPU (sm_120 para RTX 5090, sm_89 para RTX 4090, etc.). Un binario genérico recurre a una implementación genérica de respaldo y pierde un 20–30 % de tasa de procesamiento. Con este volumen, merece la pena dedicar un cuarto de hora a compilar.

#3. Descargar los GGUF V3.2

Los pesos GGUF de DeepSeek V3.2 están publicados en Hugging Face. Para Q2_K_XL Unsloth (la opción recomendada para la mayoría de las configuraciones), una única descarga de ~220 GB dividida en varios archivos.

Descarga Q2_K_XL desde Hugging Face
pip install -U "huggingface_hub[cli]"
huggingface-cli download \
  unsloth/DeepSeek-V3.2-GGUF \
  --include "*UD-Q2_K_XL*" \
  --local-dir ./models/deepseek-v32-q2kxl

La descarga tarda varias horas con una conexión doméstica: asegúrate de contar con una conexión de fibra óptica estable y un disco de destino con al menos 250 GB libres. Los GGUF de este tamaño se dividen en entre 5 y 7 archivos (split-00001-of-N.gguf), e ik_llama.cpp detecta automáticamente las partes si indicas el primer archivo.

!
Verificar los checksums
Un GGUF al que le falta 1 byte produce respuestas coherentes durante 20 tokens y luego entra en un bucle infinito. Es el error más molesto de diagnosticar. Comprueba siempre los SHA proporcionados en el repositorio de Hugging Face antes de la primera inferencia; se tarda 30 segundos por archivo con sha256sum.

#4. Inicio con --override-tensor (la clave del rendimiento híbrido)

El secreto de una buena instalación local de deepseek v3.2 radica en una opción: --override-tensor (alias -ot). Permite seleccionar mediante expresiones regulares qué capas permanecen en CPU/RAM y cuáles pasan a la GPU. En un MoE, no queremos en absoluto cargarlo todo en la GPU (la VRAM nunca será suficiente), pero sí queremos a toda costa que la atención y las capas compartidas se aceleren.

Lanzamiento RTX 5090 + 192 GB DDR5 (perfil B)
./build/bin/llama-server \
  --model ./models/deepseek-v32-q2kxl/DeepSeek-V3.2-UD-Q2_K_XL-00001-of-00005.gguf \
  --ctx-size 65536 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --n-gpu-layers 999 \
  -ot "\.ffn_(up|down|gate)_exps\.=CPU" \
  --threads 16 \
  --flash-attn \
  --host 0.0.0.0 --port 8080

La expresión regular \.ffn_(up|down|gate)_exps\. selecciona los tres tensores FFN por experto —es decir, la inmensa mayoría de los 671B parámetros— y los obliga a permanecer en la CPU. Lo que pasa a la GPU: atención (MLA), experto compartido, embeddings, head. En una RTX 5090 de 32 GB, se consumen ~22 GB de VRAM; el resto se destina a la caché KV.

Ejecución solo en CPU (perfil A, 256 GB DDR5)
./build/bin/llama-server \
  --model ./models/deepseek-v32-q2kxl/DeepSeek-V3.2-UD-Q2_K_XL-00001-of-00005.gguf \
  --ctx-size 32768 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --threads 32 \
  --flash-attn \
  --host 0.0.0.0 --port 8080
→
Cuantizar la caché KV incluso a 32k
En V3.2, --cache-type-k q8_0 --cache-type-v q8_0 dividen por 2 el consumo de la caché KV con una pérdida de calidad imperceptible. Esto te permite mantener 64k de contexto en una GPU de 32 GB en lugar de fallar con OOM en 24k.

#5. Tokens por segundo medidos en una estación de trabajo doméstica

Valores de referencia medidos con una compilación de ik_llama.cpp de mayo de 2026, Q2_K_XL, contexto de 32k y un prompt mixto de francés y código. Las cifras se mantienen estables dentro de un margen de ±15 % según el prompt y el calentamiento de las páginas de memoria.

RTX 5090 + Ryzen 9 7950X3D + 192 GB DDR5-6000
Prefill ~110 tok/s, generación 12–15 tok/s. La configuración doméstica recomendada en 2026.
RTX 4090 + Threadripper 7960X + 256 GB DDR5 ECC
Prefill ~90 tok/s, generación 9–12 tok/s. La 4090 está a la par con la 5090 en este perfil híbrido porque el cuello de botella está en la RAM, no en la GPU.
EPYC 9354P + 384 GB DDR5 ECC (12 canales), sin GPU
Prefill ~70 tok/s, generación 7–9 tok/s. El ancho de banda total de memoria (~460 GB/s) compensa la ausencia de GPU.
Mac Studio M3 Ultra 192 GB
Prefill ~55 tok/s, generación de 6–8 tok/s en Q2_K_XL. La memoria unificada (~820 GB/s) salva la situación.
Ryzen 9 7950X + 128 GB DDR5 + SSD Samsung 990 Pro
Prefill ~25 tok/s, generación 1,5–2,5 tok/s. Sinceramente, solo resulta utilizable por lotes.
i
¿Por qué el prefill es rápido y la generación lenta?
El prefill procesa el prompt en un lote y aprovecha el paralelismo matricial: ahí es donde destacan el ancho de banda de la memoria y la GPU. La generación produce un token a la vez; para cada token hay que volver a leer los ~37B parámetros seleccionados por el enrutamiento. Esto es inherente al MoE; ningún fork de llama.cpp hará milagros.

#DeepSeek V3.2 vs DeepSeek R1: ¿cuál instalar?

Pregunta frecuente, porque ambos modelos comparten la misma arquitectura MoE de 671B / 37B activos y la misma licencia MIT. La diferencia está en el postentrenamiento, no en el esqueleto.

DeepSeek V3.2
Modelo generalista (chat), respuestas directas. Excelente en francés, muy sólido en código. Añade DSA para el contexto largo. Recomendado como asistente de uso diario y para síntesis y redacción.
DeepSeek R1
Modelo de razonamiento (cadena de pensamiento explícita al estilo de o1). Emite muchos tokens internos (<think>...</think>) antes de la respuesta final. Darle prioridad para matemáticas, lógica y depuración algorítmica compleja.
Costo de inferencia
R1 genera entre 3 y 10 veces más tokens (por el thinking) para producir la misma respuesta final. A igual velocidad de generación, R1 tarda 5 minutos donde V3.2 tarda 30 segundos. Esto es crucial en local, donde cada tok/s cuenta.
Contexto largo
Gracias a DSA, V3.2 admite 128k tokens con un caché KV de tamaño razonable. R1 carece de DSA y su consumo de memoria se dispara por encima de 64k.
VRAM/RAM requerida
Idéntica. Ambos modelos comparten la arquitectura 671B/37B y ocupan unos 220 GB con la misma cuantización Q2_K_XL.
→
Veredicto práctico
Instala V3.2 por defecto y cambia puntualmente a R1 para las tareas que justifiquen una cadena de pensamiento explícita (demostraciones matemáticas, depuración compleja). Muchos usuarios locales guardan los dos GGUF en su NVMe y usan un wrapper de enrutamiento sencillo.

#Solución de problemas

«unknown model architecture: deepseek2»
Tu llama.cpp es demasiado antiguo o está compilado sin soporte para deepseek2. Actualiza ik_llama.cpp (rama main posterior a abril de 2026) y vuelve a compilarlo. El binario precompilado estándar no siempre basta.
OOM de CUDA al cargar
Tu expresión regular -ot no asigna suficientes expertos a la CPU. Comprueba con ik_llama-bench la distribución real de los tensores usando ollama-style. La expresión regular correcta para V3.2 apunta a ffn_(up|down|gate)_exps, no solo a ffn_exps.
Generación a 1 tok/s con 192 GB de RAM
El kernel paginará desde el GGUF mientras no haya cargado todas las páginas de uso frecuente. Un primer prompt de calentamiento de 200 tokens precarga los expertos. Si no, aumenta --threads hasta el número de núcleos físicos (no lógicos).
Respuestas que cambian al chino sin razón
Plantilla de chat incorrecta. Comprueba que --chat-template esté en modo auto y que el GGUF incluya la plantilla Jinja de DeepSeek. De lo contrario, especifica --chat-template deepseek3 explícitamente.
DSA parece inactivo (caché KV lineal)
DSA solo se activa a partir de una longitud de contexto mínima (configurable). Para contextos < 16k, el modelo utiliza la atención densa clásica: es el comportamiento esperado y no cambia en nada la calidad.
Fallo con un prompt largo después del calentamiento
Probablemente has saturado la swap. DeepSeek V3.2 no soporta bien la swap: si la RAM física no es suficiente, desactiva la swap (sudo swapoff -a) y deja que llama.cpp gestione la paginación mediante mmap, es más rápido y más estable.

#Para ir más allá

DeepSeek V3.2 en local es un punto de partida para explorar la categoría de «modelos de frontera que puedes alojar por tu cuenta». Tres vías complementarias:

Optimizar la compilación de llama.cpp
La guía "Compilar llama.cpp con CUDA" detalla los flags avanzados (Flash Attention, MMQ, offload tensors) que realmente afectan el rendimiento en MoE.
Entender las cuantizaciones modernas
La guía "Elegir la cuantización (Q4, Q5, Q8, FP16)" explica por qué Q2_K_XL funciona donde Q2 clásico falla y cuándo subir a Q3/Q4.
Ir un paso más allá en tamaño
La guía "Kimi K2 en local" aplica el mismo método a un MoE de 1T parámetros — útil para anticipar dónde irá el ecosistema en 2026-2027.
¿Esta guía te ha ayudado?

¿Un comentario, un error, una precisión? Avísanos, eso mejora la guía para todos.