Kimi K3 en casa: la verdad sobre el hardware necesario (2.8T parámetros)

#Kimi K3 en local: lo que realmente publicó Moonshot

La ficha de Hugging Face de Moonshot describe Kimi K3 como un modelo multimodal de pesos abiertos de 2,8 billones de parámetros, con una ventana de contexto de un millón de tokens. Es un Mixture-of-Experts: 896 expertos, de los cuales se seleccionan 16 para cada token, lo que supone 104 mil millones de parámetros activados. Los pesos se distribuyen en MXFP4 (pesos) con activaciones MXFP8, y se aplicó un entrenamiento consciente de la cuantización desde la fase de fine-tuning supervisado. El código y los pesos se rigen por la «Kimi K3 License»: lee este texto antes de cualquier uso comercial, ya que no es una licencia MIT o Apache estándar. El modelo llegó a Hugging Face alrededor del 27 de julio de 2026 según la prensa especializada.

Parámetros totales / activos

2,8 T en total, 104 Md activos por token (ficha Moonshot).

Expertos

896 expertos, 16 seleccionados por token, más 2 expertos compartidos

Formato publicado

MXFP4 para los pesos, MXFP8 para las activaciones. No es un GGUF.

Contexto

1 048 576 tokens, con un caché KV que se suma a la memoria de los pesos.

Motores recomendados

vLLM, SGLang y TokenSpeed. llama.cpp utiliza los GGUF de la comunidad.

#Lo que realmente pesan los pesos

Circulan dos cifras y hay que distinguirlas. Algunos artículos estiman «del orden de 1,4 TB» multiplicando 2,8 T de parámetros por medio byte. El tamaño medido de los archivos es mayor: Unsloth y Runpod indican 1,56 TB para la versión nativa, porque las capas ajenas a los expertos (atención, enrutadores, expertos compartidos) se mantienen en una precisión superior. El BF16 sin cuantizar alcanzaría aproximadamente 5,6 TB, según Runpod. Por tanto, la cifra de 1,4 TB que daba la versión de esta guía era aproximadamente un 10 % demasiado baja.

La tabla refuta una idea errónea de la versión anterior: un Q2 no es «siempre del orden del terabyte». Unsloth sí ofrece archivos GGUF de menos de 900 GB. Pero 594 GB siguen siendo casi quince veces la memoria de una RTX 5090 de 32 GB, y la diferencia de calidad es real: la cuantización dinámica de 1 bit solo reproduce la elección del modelo original en el 78,9 % de los casos del conjunto de evaluación de Unsloth. Para entender cómo afectan los bits a la calidad, consulta nuestra guía de cuantización.

#El hardware: lo que se recomienda, lo que es posible

Moonshot no publica una configuración mínima en la página del modelo: redirige a las recetas vLLM, SGLang y TokenSpeed y a su API. La referencia documentada para el autohospedaje nativo proviene de Runpod: un nodo con ocho GPUs B300 de 288 GB cada uno, es decir, aproximadamente 2,3 TB, o dieciséis B200 distribuidos en dos nodos. El número de «64 aceleradores o más» que esta página citaba no aparece en ninguna fuente primaria consultada: se ha eliminado.

Con un GGUF de Unsloth, la regla que establece su documentación es sencilla: la suma de RAM y VRAM debe ser aproximadamente igual al tamaño de la cuantización; de lo contrario, el modelo funciona, pero pasa a utilizar el disco y lo hace mucho más lentamente. Unsloth también cita unos 20 tokens por segundo en generación cuando el modelo cabe en las B200. Es una tasa de generación indicada por un proveedor en hardware de centro de datos, no una medición aplicable a un equipo doméstico.

#¿Y en un Mac? El cálculo en lugar de los rumores

No se ha encontrado ninguna fuente verificable para la cifra de «16 segundos por token en un MacBook Pro M1 Max» que esta página recogía: no la presentamos como un hecho. Lo que las fuentes establecen es más claro. Kingy AI señala que el punto de partida (checkpoint de 1,56 TB) ya superaba la capacidad de memoria de un Mac Studio de 512 GB, y que incluso el archivo de 553,2 GiB de la versión de 1 bit supera la capacidad de esa máquina antes de contar el consumo adicional de memoria. Los 128 GB de un Mac representan aproximadamente una quinta parte de los 610 GB recomendados.

En cambio, puedes estimar por ti mismo el orden de magnitud. Si la memoria no es suficiente, cada token vuelve a leer desde el SSD los expertos que activa: 104 mil millones de parámetros a aproximadamente 4 bits, lo que equivale a unos 50 GB leídos por token. Con un SSD que proporciona 3 GB/s, se obtienen alrededor de 17 segundos por token; a 7 GB/s, alrededor de 7 segundos. Es un cálculo teórico de un límite superior, no una medición, pero explica por qué los testimonios sobre la ejecución «en disco» hablan de segundos por token y no de tokens por segundo.

#Ollama, LM Studio, llama.cpp: qué permite cada herramienta

Ollama

La biblioteca oficial lista una sola variante, kimi-k3:cloud: el modelo se ejecuta en los servidores de Ollama, no en tu máquina. El comando ollama run kimi-k3:cloud sirve para probar el modelo con la interfaz habitual, con las limitaciones de confidencialidad y facturación de un servicio remoto.

LM Studio

Carga GGUF locales. Para K3, esto supone descargar varios cientos de GB de archivos Unsloth y disponer de la memoria correspondiente. En un equipo de consumo, la respuesta es no.

llama.cpp

Es el motor al que están destinados los GGUF de Unsloth, que se apoyan en una rama derivada de llama.cpp con soporte de visión. Gestiona la ejecución de los expertos en la CPU y los archivos divididos en varias partes: es la vía realista para una estación de trabajo con varios cientos de GB de RAM.

vLLM y SGLang

Los dos motores recomendados por Moonshot para un servicio multi-GPU con formato nativo.

#Las opciones realistas para probar Kimi K3

1. 01
   1. La API oficial de Moonshot

   El modelo se llama kimi-k3 en platform.kimi.ai, con una API compatible con OpenAI y Anthropic. Es la forma más rápida de evaluar la calidad, con un parámetro reasoning_effort ajustable en low, high o max.
2. 02
   2. Ollama cloud

   ollama run kimi-k3:cloud utilise vos habitudes Ollama avec l'inférence déportée. La page de la bibliothèque affiche les tarifs par million de tokens : vérifiez-les avant d'automatiser. Notre guide sur Ollama Cloud détaille les limites.
3. 03
   3. Un alquiler de GPU

   Alquilar un nodo multi-GPU por horas durante una prueba, con vLLM. Haz primero el cálculo de rentabilidad (coste por hora dividido por la tasa sostenida de tokens por segundo), que Runpod formula en sus preguntas frecuentes.
4. 04
   4. Una estación con mucha RAM

   Solo si ya tienes 700 GB de memoria: GGUF UD-IQ1_S y llama.cpp, aceptando una calidad reducida y una baja velocidad de generación.

#Que un modelo tenga pesos abiertos no significa que se pueda ejecutar en casa

Los pesos abiertos garantizan el derecho a descargar, auditar, ajustar y, según la licencia, redistribuir. No garantizan que alguien pueda ejecutarlos. Un modelo de 30 mil millones de parámetros en una tarjeta de 24 GB te pertenece realmente; uno de 2,8 T que solo puede cargar un clúster sigue siendo, en la práctica, un servicio. Kimi K3 es una buena noticia para la auditabilidad y para las organizaciones que ya tienen un clúster, sin cambiar lo que un particular puede hacer en casa.

#Alternativas que tu hardware puede realmente cargar

El catálogo QuelLLM estima las necesidades de memoria en Q4, sin incluir la memoria del contexto: DeepSeek V4 Flash 284B, aproximadamente 170 GB; GLM 5.2 753B-A40B, aproximadamente 437 GB; Kimi K3, aproximadamente 1 624 GB. Para uso diario, un modelo de 30 a 70 mil millones de parámetros en Q4 sigue ofreciendo la mejor relación entre calidad y viabilidad.

DeepSeek V4 Flash 284B

Aproximadamente 170 GB en Q4 según el catálogo: posible en un Mac Studio con mucha memoria o una estación de trabajo. Ver la guía específica.

GLM 5.2 753B-A40B

Aproximadamente 437 GB en Q4: es el tamaño más cercano a K3 accesible en una estación bien equipada.

Kimi K2.5 y K2.7

Aproximadamente 600 GB en Q4: más pequeños que K3, pero todavía requieren infraestructura de estación de trabajo.

Modelos de 30 a 70 mil millones

En una tarjeta de 24 a 32 GB o en un Mac de 64 GB: la opción razonable para un uso real. El calculador de VRAM proporciona el valor exacto.

#Veredicto: Kimi K3 en local, casi nunca

Pesos nativos de 1,56 TB, cuantizaciones de 594 a 861 GB, 610 GB de memoria para la más pequeña: Kimi K3 es un modelo de servidor. Para evaluarlo, usa la API o kimi-k3:cloud. Para un uso real en casa, elige un modelo que quepa en tu memoria con margen para el contexto.

#Para ir más allá

• DeepSeek V4 Flash 284B: el primer modelo de vanguardia en Mac Studio
• GLM-5.2 en local: Ollama y LM Studio
• Elegir tu cuantización (Q4, Q5, Q8, FP16)
• MoE explicado: por qué un 30B-A3B funciona como un modelo pequeño
• Ollama Cloud: precios, opiniones y límites
• Calculadora de VRAM

• Fuente: ficha de Hugging Face de Kimi K3
• Fuente: Unsloth, Kimi K3 en local
• Fuente: Preguntas frecuentes técnicas de Runpod
• Fuente: biblioteca Ollama, kimi-k3