Cómo ejecutar Kimi K3 localmente (y cuándo no deberías)

Moonshot AI lanzó los pesos abiertos para Kimi K3 el 27 de julio, y el contador de descargas en Hugging Face ya está cerca de los 100.000. El atractivo es obvio: un modelo de 2,8 billones de parámetros que superó a Claude Opus 4.8 en todos los benchmarks publicados por Moonshot, y ahora puedes alojarlo tú mismo.

El inconveniente también es obvio una vez que miras los números. La inferencia de precisión completa necesita 1,57 TB de disco. Incluso los pesos MXFP4 lanzados son una descarga de 594 GB. Este es un modelo que puedes poseer, pero "local" significa algo diferente a esta escala de lo que significaba para un Llama de 8B.

Esta guía cubre lo que se necesita para ejecutar K3 en tu propio hardware, lo que la comunidad ha logrado en máquinas de consumo, y cómo integrar un endpoint de K3 autoalojado en tu flujo de trabajo API con Apidog una vez que esté en funcionamiento.

Qué estás descargando

Primero, la forma de la cosa. Si quieres el contexto completo, empieza con ¿Qué es Kimi K3?; la versión corta:

• 2,8 billones de parámetros totales, 104 mil millones activados por token. K3 es un modelo de Mezcla de Expertos con 896 expertos. Cada token se enruta a través de 16 expertos seleccionados más 2 compartidos, por lo que el cómputo por token es una fracción del número principal.
• 93 capas: 69 capas Kimi Delta Attention (KDA) y 24 capas Gated MLA. El diseño KDA es la razón por la que la ventana de contexto de 1 millón de tokens es utilizable en absoluto.
• Visión nativa a través de un codificador MoonViT-V2 de 401M de parámetros. Los pesos lanzados manejan entrada de texto, imágenes y video.
• Pesos MXFP4, activaciones MXFP8. Moonshot realizó un entrenamiento consciente de la cuantificación, por lo que la versión de 4 bits es el formato de servicio previsto, no una idea de último momento. Esto también significa que los pesos se comprimen mal más allá de eso; el margen de bits bajos ya está gastado.
• Solo pensamiento. K3 siempre razona antes de responder, con niveles de esfuerzo bajo, alto y máximo. No hay modo instantáneo.

Los pesos están restringidos por la Licencia Kimi K3 en el repositorio de Hugging Face. Acepta la licencia, luego descarga con huggingface-cli. En una conexión de 1 Gbps, calcula entre 80 y 90 minutos para los 594 GB.

Opción 1: Servicio de clase de centro de datos con vLLM o SGLang

Moonshot recomienda tres motores: vLLM, SGLang y TokenSpeed. Su contribución de caché de prellenado KDA se envió en vLLM junto con los pesos, por lo que vLLM es el camino de menor resistencia:

vllm serve moonshotai/Kimi-K3 \
  --tensor-parallel-size 8 \
  --max-model-len 131072

Notas del campo:

• Hardware. Moonshot evaluó en clústeres H20. De manera realista, necesitas un nodo de 8 GPU con paralelismo tensorial como mínimo. En hardware de clase B200, se puede lograr un rendimiento superior a 100 tokens/s.
• Contexto. El modelo soporta hasta 1.048.576 tokens, pero la caché KV con contexto completo es de alrededor de 27 GB por sí sola. Empieza en 131K y auméntala solo si tu carga de trabajo lo necesita.
• Muestreo. Los valores predeterminados de Moonshot son temperatura 1.0 y top-p 0.95. Para cargas de trabajo de agentes, mantén la temperatura en 1.0 y mueve top-p a 1.0.

Esto es "local" en el sentido de la soberanía de los datos: tu infraestructura, tus registros, tu historial de cumplimiento. No es local en el sentido de un portátil, y ninguna cantidad de cuantificación cambia eso para el uso interactivo.

Opción 2: Cuantificaciones GGUF en una estación de trabajo grande

Unsloth publicó conversiones GGUF para usuarios de llama.cpp, y sus cuantificaciones dinámicas son la única forma realista de reducir K3 por debajo de la versión oficial:

La regla práctica: tu RAM más VRAM debería ser aproximadamente igual al tamaño de la cuantificación. Si te quedas corto, llama.cpp seguirá funcionando mediante descarga, pero cada gigabyte que falte te costará velocidad. Un Mac Studio conectado a una máquina de 128 GB, o una DGX Station, se sitúa en el extremo inferior práctico.

Una invocación mínima de llama.cpp, incluyendo el proyector de visión:

./llama.cpp/llama-cli \
    --model unsloth/Kimi-K3-GGUF/UD-IQ1_S/Kimi-K3-UD-IQ1_M-00001-of-00015.gguf \
    --mmproj unsloth/Kimi-K3-GGUF/mmproj-F16.gguf \
    --temp 1.0 \
    --top-p 0.95

Si tu hardware no llega a esto, no lo fuerces. La lista de los mejores LLM locales de 2026 tiene modelos abiertos que caben en 24 a 128 GB y responden en tiempo real; K3 a 1 bit con RAM inadecuada no lo hará.

El experimento M1 Max: sí, pero 16 segundos por token

Un hilo de Hacker News esta semana documentó el funcionamiento de K3 en un M1 Max de 64 GB mediante la transmisión de pesos desde un SSD de 2 TB en lugar de mantenerlos en memoria. Los números explican tanto por qué funciona como por qué no lo usarías:

• K3 contiene aproximadamente 115 GB de parámetros densos que cada token toca, además de unos 25 GB de pesos de expertos enrutados por token. La parte densa por sí sola excede la RAM de la máquina, por lo que el SSD se convierte en memoria a cámara lenta.
• Resultado: alrededor de 16 segundos por token. Algunas configuraciones informaron más de un minuto por token. Eso es un párrafo por hora.
• El rendimiento del disco es lo principal. Los SSD de la era M1 leen mucho más lento que los actuales chips de Apple, y la transmisión de expertos a través de una red es aún más lenta.

Como prueba de que la escasez de MoE más mmap puede ejecutar un modelo de 2.8 billones en un portátil, es un resultado genuinamente divertido. Como forma de usar K3, no lo es. Si quieres respuestas de K3 en un MacBook, los niveles gratuitos o la API alojada te servirán mejor.

Integrando tu K3 local en un flujo de trabajo API

Ya sea que sirvas a través de vLLM o el modo de servidor de llama.cpp, terminas con lo mismo: un endpoint HTTP compatible con OpenAI en localhost. Desde aquí es una API como cualquier otra, y se aplica el mismo flujo de trabajo que usamos para probar LLM locales como APIs:

1. Apuntar Apidog al endpoint. Crea un entorno con base_url configurado en http://localhost:8000/v1 (el predeterminado de vLLM) y cámbialo por el endpoint alojado de Moonshot más tarde. Las mismas solicitudes, dos backends, una variable.
2. Inspeccionar el flujo de pensamiento. K3 solo piensa, por lo que las respuestas contienen contenido de razonamiento antes de la respuesta. La vista de depuración SSE de Apidog renderiza el flujo a medida que llega, lo que facilita mucho ver cómo cambian los niveles de esfuerzo de razonamiento.
3. Validar la estructura, no las sensaciones. Añade pruebas automatizadas que validen el esquema de respuesta, los presupuestos de latencia y los campos de uso de tokens, para que un cambio de cuantificación o una actualización del motor que degrade la salida aparezca en una prueba fallida en lugar de un informe de usuario.
4. Simular K3 mientras las GPU están ocupadas. Un modelo de 594 GB tarda un tiempo en cargarse. Registra las respuestas reales una vez, luego deja que un servidor simulado las devuelva para que el trabajo de frontend nunca espere a la caja de inferencia. Descarga Apidog para configurarlo gratis; las herramientas de simulación y prueba funcionan con cualquier servidor compatible con OpenAI.

El formato de la solicitud en sí coincide con lo que cubrimos en la guía de la API de Kimi K3, por lo que las pruebas escritas para la API alojada se transfieren directamente a tu implementación local.

Entonces, ¿deberías ejecutarlo localmente?

Una tabla de decisiones rápida:

El resumen honesto: los pesos abiertos de K3 importan porque puedes auditar, ajustar y autoalojar un modelo de clase fronteriza, no porque la mayoría de la gente deba hacerlo. Para los equipos con el hardware, el camino de vLLM funciona hoy y rinde bien. Para todos los demás, el lanzamiento abierto sigue dando sus frutos indirectamente, a través de un acceso alojado más barato y de proveedores externos que compiten por servirlo.

Sea cual sea el lado de la tabla en el que te encuentres, el endpoint es donde el modelo se encuentra con tu código. Pruébalo como tal: comprobaciones de esquema, inspección de streaming y simulaciones que mantienen el desarrollo en marcha mientras el modelo piensa.