Kimi K2 local: 1 trillón de parámetros MoE en soi

#¿Por qué optar por Kimi K2 en local?

Kimi K2 es el modelo principal de Moonshot AI, publicado con pesos abiertos (Modificado MIT) y con una arquitectura MoE (Mixture of Experts) de 1 trillón de parámetros totales y aproximadamente 32B activos por token. En los benchmarks de razonamiento y código, se sitúa entre los modelos de frontera cerrados, y su contexto largo (anunciado de 128k tokens) lo convierte en un candidato serio para análisis documental masivo.

Ejecutar un modelo de este tamaño en local era, hace 18 meses, una fantasía. Tres avances cambiaron la situación: la generalización de la memoria DDR5 de gran capacidad (192-384 GB por unos pocos cientos de euros), los SSD NVMe Gen 4 capaces de alcanzar 7 GB/s en lectura secuencial y el trabajo del equipo de llama.cpp en cuantizaciones muy agresivas como Q2_K_S e IQ1_M.

#Entender el MoE 1T / 32B activos

La arquitectura MoE reemplaza los bloques FFN densos por una capa de expertos (frecuentemente 256+) entre los cuales un router selecciona 8 a 12 por token. En cuanto al cálculo, se procesan solo los parámetros de los expertos elegidos — por eso los ~32B « activos ». En cuanto a la memoria, todos los expertos deben ser accesibles, de lo contrario el router pierde el acceso al 95 % del modelo.

Parámetros totales

≈ 1 billón (1T). Es lo que permanece almacenado en la RAM o en el disco.

Parámetros activos por token

≈ 32 mil millones. Es lo que determina el cálculo y la velocidad.

Expertos por capa

Varios cientos, de los cuales se enruta un número fijo por token (enrutamiento top-k).

Capas compartidas (atención)

Siempre activas. Dominan el consumo de memoria cuando el contexto es pequeño.

Caché KV

Crece linealmente con el contexto. Con 128k, la caché KV puede superar los 30 GB incluso cuantizada.

#Presupuesto de memoria a considerar

El cálculo de memoria para un MoE 1T se descompone en tres componentes distintos. Comprender esta descomposición es crucial antes de invertir en RAM o SSD.

Pesos del modelo (cuantizados)

Q2_K_S ≈ 245 GB, Q3_K_S ≈ 320 GB, Q4_K_M ≈ 480 GB, Q8_0 ≈ 1 TB. Es la partida que más ocupa y la que más se puede comprimir.

Caché KV (contexto)

Prever ~0,25 MB por token en FP16, ~0,12 MB en Q8. Es decir, 32 GB para 128k tokens en Q8. Configurable mediante --cache-type-k/-v.

Buffers de activación

Algunos GB por GPU para cálculos intermedios. Marginal, pero no debe olvidarse en GPUs de 24 GB.

#Requisitos de hardware

Tres perfiles de máquinas permiten ejecutar Kimi K2 localmente, con concesiones muy distintas en cuanto a velocidad.

Perfil A — DDR5 potente (192-384 GB RAM)

Estación de trabajo Threadripper/Xeon W o plataforma EPYC. 256 GB de DDR5 ECC, sin necesidad de GPU. El modelo cabe completamente en RAM en Q2_K_S. Velocidad esperada: 4-8 tok/s solo con CPU.

Perfil B — DDR5 + 1 GPU de 24 GB

96-128 GB de RAM + RTX 4090/3090. Las capas compartidas se trasladan a la GPU; los expertos permanecen en la RAM. Velocidad esperada: 6-12 tok/s, según el número de expertos que quepan en la VRAM.

Perfil C — RAM modesta + SSD NVMe

64-96 GB de RAM + NVMe Gen 4 (7 GB/s de lectura, ≥ 1 TB libre). Los pesos se mapean en memoria desde el SSD mediante mmap. Velocidad esperada: 1-3 tok/s, muy dependiente de la velocidad real de lectura del SSD.

#1. Compilar llama.cpp con el backend adecuado

Kimi K2 requiere una versión reciente de llama.cpp (una compilación reciente posterior a diciembre de 2025) compatible con su arquitectura MoE y las cuantizaciones IQ. Se compila desde el repositorio oficial.

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON -DGGML_CUDA_FA_ALL_QUANTS=ON
cmake --build build --config Release -j

En Mac con Apple Silicon, reemplazar GGML_CUDA por GGML_METAL. En AMD con ROCm, usar GGML_HIP. La opción GGML_CUDA_FA_ALL_QUANTS activa Flash Attention para todas las cuantizaciones: es indispensable para admitir 128k de contexto sin superar la capacidad de la VRAM.

#2. Elegir la cuantización GGUF

Para un modelo de este tamaño, olvídate de Q4_K_M y superiores a menos que tengas 512 GB de RAM. La cuantización extrema — Q2_K_S, IQ2_XXS, incluso IQ1_M — es lo que hace que el uso local sea viable, a costa de una pérdida de calidad medible pero a menudo aceptable en un MoE.

Q2_K_S (~245 GB)

Punto óptimo. ~5 % de degradación en los benchmarks de código, ~3 % en razonamiento. Recomendado si tienes 256 GB de RAM o un SSD rápido.

IQ2_XXS (~210 GB)

Aún más agresivo mediante una matriz de importancia. Cabe en 192 GB de RAM con algo de offload. Calidad un nivel por debajo.

IQ1_M (~155 GB)

Cuantización híbrida de 1 bit. Para configuraciones con recursos muy limitados. Degradación visible, pero el modelo sigue siendo coherente.

Q3_K_S (~320 GB)

Calidad casi equivalente a Q4, pero requiere 384 GB de RAM. Para estaciones de trabajo EPYC bien equipadas.

pip install -U "huggingface_hub[cli]"
huggingface-cli download \
  unsloth/Kimi-K2-Instruct-GGUF \
  --include "*Q2_K_S*" \
  --local-dir ./models/kimi-k2-q2ks

Los archivos GGUF de este tamaño se dividen en varios ficheros (split-00001-of-00007.gguf, etc.). llama.cpp detecta automáticamente los splits si apuntas al primer fichero.

#3. Iniciar Kimi K2 con mmap y offload

El comando básico utiliza llama-server, el servidor HTTP proporcionado por llama.cpp. Expone un endpoint compatible con OpenAI en el puerto 8080 por defecto.

./build/bin/llama-server \
  --model ./models/kimi-k2-q2ks/kimi-k2-Q2_K_S-00001-of-00007.gguf \
  --ctx-size 32768 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --threads 16 \
  --no-mmap=false \
  --host 0.0.0.0 --port 8080

Con una GPU de 24 GB, se trasladan las capas compartidas (atención) a la GPU y se dejan los expertos MoE en RAM o en SSD. La opción -ot permite seleccionar con precisión qué va a la GPU y qué va a la CPU.

./build/bin/llama-server \
  --model ./models/kimi-k2-q2ks/kimi-k2-Q2_K_S-00001-of-00007.gguf \
  --ctx-size 65536 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --n-gpu-layers 999 \
  -ot "\.ffn_.*_exps\.=CPU" \
  --threads 12 \
  --host 0.0.0.0 --port 8080

La expresión regular que se pasa a -ot significa: «Todas las capas FFN de los expertos (la mayor parte del modelo MoE) permanecen en CPU/RAM; el resto va a la GPU». Este truco hace viable el funcionamiento híbrido: se aprovecha la GPU para la atención sin tener que cargarlo todo en ella.

#4. Tokens/segundo reales medidos

Aquí tienes algunas cifras de referencia de rendimiento observadas en la práctica. Las cifras varían según el prompt (el prefill es lento; la generación, más estable) y el estado de la caché de páginas del sistema operativo.

EPYC 9354P, 384 GB DDR5, Q2_K_S, todo en RAM

Prefill ~80 tok/s, generación ~6-8 tok/s. Configuración de referencia para razonamiento en batch.

Threadripper 7960X, 256 GB DDR5, Q2_K_S

Prefill ~50 tok/s, generación ~4-6 tok/s. La latencia de memoria DDR5 domina.

Ryzen 9 7950X, 128 GB DDR5 + SSD NVMe Gen 4

Prefill ~15 tok/s, generación ~1,5-3 tok/s. El SSD se convierte en el factor limitante en cuanto se supera la capacidad de la RAM residente.

Mac Studio M2 Ultra 192 GB

Generación ~4-7 tok/s en IQ2_XXS. El ancho de banda de la memoria unificada (800 GB/s) ayuda enormemente con los MoE.

Estación de trabajo con 256 GB + RTX 4090 (híbrida)

Prefill ~60 tok/s, generación ~7-10 tok/s. La tarjeta gráfica en atención divide por 2 el tiempo de prefill.

#5. Casos de uso con un contexto de 128k

La gran ventaja de Kimi K2 frente a los modelos locales de 7B-70B es la ventana de 128k tokens. En concreto, puedes proporcionarle un informe anual completo, una base de código de tamaño medio o unas cien páginas de PDF y pedirle una síntesis global que tenga en cuenta el conjunto, sin recurrir al RAG por fragmentos.

Síntesis de documentos largos

Un informe de 300 páginas ocupa menos de 120k tokens. Kimi K2 produce una síntesis estructurada en una sola pasada, mientras que un RAG la compondría a partir de fragmentos.

Refactorización de la base de código

Cargar 50 archivos Python (~80k tokens), pedir una revisión de arquitectura coherente. Muy útil para una deuda técnica transversal.

Análisis de logs correlacionado

Pegar 50 MB de logs (tras filtrarlos) y pedir una cronología del incidente. El modelo ve todas las correlaciones, no solo las ventanas deslizantes.

Traducción de grandes documentos

Mantiene la coherencia terminológica en todo un libro, mientras que una traducción por bloques pierde el hilo.

#Solución de problemas

« failed to load model » o error de número mágico

Tu llama.cpp es demasiado antiguo para este GGUF. Actualiza a una compilación posterior a diciembre de 2025 y verifica la versión de arquitectura indicada por quien reempaquetó el GGUF.

Generación a 0,2 tok/s aunque la RAM sería suficiente

El kernel seguirá cargando páginas desde el GGUF hasta haber accedido a todas ellas. Una primera ejecución de calentamiento con un prompt corto precarga las páginas de uso frecuente. Si no, aumenta --threads para saturar antes el ancho de banda.

OOM repentino con un prompt largo

La caché KV ha explotado. Reduce --ctx-size a 32768 o activa la cuantización Q8 de la caché. La caché KV crece linealmente con el contexto, no con el tamaño del modelo.

Salida incoherente o lenguaje defectuoso

A menudo se debe a una plantilla de chat incorrecta. Comprueba --chat-template o que el GGUF incluya la plantilla oficial de Moonshot (jinja). Un token de fin incorrecto hace que la salida pierda coherencia y se repita en bucle.

SSD a 80 °C, tasa de transferencia que se desploma

Los NVMe de gama alta reducen su rendimiento por el calor si no tienen disipador. En una sesión larga, instala un disipador o reduce la carga pasando a una cuantización más pequeña que quepa en la RAM.

#Para ir más allá

Kimi K2 en local es un campo de experimentación con modelos muy grandes. Tres vías para ir más allá:

Dominar la compilación de llama.cpp

La guía "Compilar llama.cpp con CUDA" detalla los flags menos evidentes (offload de tensores, MMQ, Flash Attention) que afectan al rendimiento de este tipo de modelo.

Comprender las cuantizaciones

La guía "Elegir la cuantización" establece las bases conceptuales útiles antes de sumergirse en IQ2_XXS o Q3_K_S, y aclara lo que realmente se degrada.

Llevar la compresión más lejos

La guía TurboQuant detalla un método más reciente que los K-quants para conseguir que los modelos de frontera quepan en hardware de consumo, con distintas ventajas e inconvenientes.