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

Moonshot AI lanzó los pesos abiertos de Kimi K3 el 27 de julio, y el contador de descargas en Hugging Face ya se acerca a las 100.000. El atractivo es claro: un modelo de 2,8 billones de parámetros que superó a Claude Opus 4.8 en los benchmarks publicados por Moonshot, ahora disponible para autoalojar.

Prueba Apidog hoy

El coste de esa autonomía también es considerable. La inferencia a precisión completa requiere 1,57 TB de disco, mientras que los pesos MXFP4 ocupan 594 GB. Puedes ejecutar K3 en tu propia infraestructura, pero «local» tiene un significado muy distinto al de ejecutar un Llama de 8B.

Esta guía explica qué hardware necesitas, qué resultados ha obtenido la comunidad en equipos de consumo y cómo conectar un endpoint autoalojado de K3 a tu flujo de trabajo de API con Apidog.

Qué estás descargando

Antes de elegir una estrategia de despliegue, revisa el tamaño y la arquitectura del modelo. Para más contexto, consulta ¿Qué es Kimi K3?. Estos son los puntos esenciales:

• 2,8 billones de parámetros totales; 104 mil millones activos por token. K3 usa una arquitectura de Mezcla de Expertos (MoE) con 896 expertos. Cada token se enruta por 16 expertos seleccionados y 2 compartidos, por lo que el cómputo por token es menor que el número total de parámetros.
• 93 capas: 69 capas Kimi Delta Attention (KDA) y 24 capas Gated MLA. KDA permite que la ventana de contexto de 1 millón de tokens sea viable.
• Visión nativa mediante un codificador MoonViT-V2 de 401 millones de parámetros. Los pesos admiten texto, imágenes y vídeo.
• Pesos MXFP4 y activaciones MXFP8. Moonshot entrenó el modelo con cuantificación en mente. El formato de 4 bits es el formato previsto para servir el modelo, no una conversión posterior.
• Modo de razonamiento obligatorio. K3 razona antes de responder y ofrece niveles de esfuerzo bajo, alto y máximo. No tiene modo instantáneo.

Los pesos están sujetos a la Licencia Kimi K3 en el repositorio de Hugging Face. Acepta la licencia y descárgalos con huggingface-cli.

En una conexión de 1 Gbps, la descarga de 594 GB tarda aproximadamente entre 80 y 90 minutos.

Opción 1: servir Kimi K3 con vLLM o SGLang en un nodo de GPU

Moonshot recomienda vLLM, SGLang y TokenSpeed. La caché de prellenado KDA se integró en vLLM junto con los pesos, por lo que vLLM es la opción más directa.

Inicia el servidor con paralelismo tensorial:

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

Ten en cuenta estas decisiones antes de desplegar:

• Hardware: necesitas, de forma realista, un nodo con al menos 8 GPU y paralelismo tensorial. Moonshot evaluó el modelo en clústeres H20. Con hardware de clase B200, el rendimiento puede superar los 100 tokens/s.
• Ventana de contexto: el máximo es 1.048.576 tokens, pero solo la caché KV para ese contexto ocupa alrededor de 27 GB. Empieza con 131072 tokens y aumenta el valor únicamente si tu carga lo requiere.
• Muestreo: los valores predeterminados de Moonshot son temperature=1.0 y top_p=0.95. Para agentes, mantén temperature=1.0 y prueba top_p=1.0.

Este enfoque es «local» desde la perspectiva de soberanía de datos: controlas la infraestructura, los registros y el cumplimiento. No es una opción de portátil, y la cuantificación no cambia esa realidad para uso interactivo.

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

Unsloth publicó conversiones GGUF para llama.cpp. Sus cuantificaciones dinámicas son la alternativa práctica para reducir el tamaño por debajo de los pesos oficiales.

Cuantificación	Tamaño	Uso recomendado
UD-IQ1_M	~345 GB	Mínimo posible; cuantificación dinámica agresiva de 1 bit.
UD-IQ1_S	~650 GB	Punto de equilibrio recomendado por Unsloth.
UD-Q4_K_XL	~1,55 TB	Cercano a precisión completa.
UD-Q8_K_XL	~1,6 TB	Prácticamente sin pérdidas.

Como regla práctica, suma tu RAM y VRAM: el total debería aproximarse al tamaño de la cuantificación elegida. Si no alcanza, llama.cpp puede descargar parte de los pesos, pero cada GB faltante reduce notablemente la velocidad.

Una estación con 350 GB o más de memoria combinada es el punto de entrada razonable. Un Mac Studio con memoria unificada elevada o una DGX Station se sitúan en el extremo inferior práctico.

Ejemplo mínimo con llama.cpp y 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 puede acercarse a esos requisitos, no intentes forzarlo. La lista de mejores LLM locales de 2026 incluye modelos abiertos que caben en 24 a 128 GB y pueden responder en tiempo real.

El experimento con M1 Max: funciona, pero tarda 16 segundos por token

Un hilo de Hacker News documentó la ejecución de K3 en un M1 Max con 64 GB de RAM. La configuración transmite pesos desde un SSD de 2 TB en lugar de mantenerlos completamente en memoria.

Los resultados muestran tanto la posibilidad como la limitación:

• K3 tiene aproximadamente 115 GB de parámetros densos que se usan en cada token, más unos 25 GB de expertos enrutados por token.
• La parte densa ya excede los 64 GB de RAM, por lo que el SSD actúa como memoria extremadamente lenta.
• El resultado fue de alrededor de 16 segundos por token. Algunas configuraciones superaron un minuto por token.
• El rendimiento del disco es el factor dominante. Los SSD de la generación M1 son más lentos que los de chips Apple actuales, y transmitir expertos por red añade más latencia.

Como experimento técnico, demuestra que la dispersión de una arquitectura MoE y mmap pueden ejecutar un modelo de 2,8 billones de parámetros en un portátil. Como entorno de uso diario, no es una alternativa práctica.

Si necesitas respuestas de K3 desde un MacBook, los niveles gratuitos o la API alojada son opciones más adecuadas.

Integra tu K3 local en un flujo de trabajo de API

Tanto vLLM como el modo servidor de llama.cpp exponen un endpoint HTTP compatible con OpenAI. A partir de ahí, trátalo como cualquier otra API. Puedes aplicar el mismo flujo usado para probar LLM locales como APIs.

1. Configura el endpoint en Apidog

Crea un entorno y define la variable base_url:

base_url = http://localhost:8000/v1

Ese es el valor predeterminado de vLLM. Cuando migres a una instancia alojada de Moonshot, cambia solo la variable de entorno: puedes conservar las mismas solicitudes y pruebas.

Ejemplo de solicitud compatible con OpenAI:

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "moonshotai/Kimi-K3",
    "messages": [
      {
        "role": "user",
        "content": "Resume los riesgos de ejecutar un modelo MoE con descarga a disco."
      }
    ],
    "temperature": 1.0,
    "top_p": 0.95
  }'

2. Inspecciona las respuestas en streaming

K3 siempre genera razonamiento antes de responder. Al usar streaming, inspecciona los fragmentos SSE para verificar cómo cambia el comportamiento al modificar el nivel de esfuerzo de razonamiento.

La vista de depuración SSE de Apidog permite revisar el flujo conforme llega, lo que ayuda a detectar diferencias entre cuantificaciones, configuraciones de muestreo y motores de inferencia.

3. Añade pruebas de contrato y rendimiento

No valides el modelo solo por impresiones manuales. Añade pruebas automatizadas para comprobar:

• El esquema de la respuesta.
• La presencia de campos de uso de tokens.
• Los límites de latencia aceptables.
• El formato de errores.
• La compatibilidad entre el endpoint local y el endpoint alojado.

Por ejemplo, una prueba de contrato puede verificar que la respuesta incluya choices, usage y un mensaje válido:

pm.test("La respuesta incluye choices", () => {
  const body = pm.response.json();
  pm.expect(body.choices).to.be.an("array").that.is.not.empty;
});

pm.test("La respuesta incluye uso de tokens", () => {
  const body = pm.response.json();
  pm.expect(body.usage).to.have.property("total_tokens");
});

Así, un cambio de cuantificación o una actualización del motor que degrade la salida se detecta en CI antes de llegar a producción.

4. Simula las respuestas mientras el servidor carga

Cargar un modelo de 594 GB lleva tiempo. Guarda respuestas reales una vez y usa un servidor simulado para mantener el desarrollo de frontend desacoplado de la infraestructura de inferencia.

Puedes descargar Apidog para configurar simulaciones y pruebas con cualquier endpoint compatible con OpenAI.

El formato de solicitud coincide con el de la guía de la API de Kimi K3, por lo que las pruebas creadas contra la API alojada se pueden reutilizar en tu despliegue local.

Entonces, ¿deberías ejecutarlo localmente?

Usa esta tabla para decidir:

Tu situación	Recomendación
Nodo de 8 o más GPU y requisitos de soberanía de datos o cumplimiento	Sí. Usa vLLM con paralelismo tensorial y pesos MXFP4.
Estación de trabajo con más de 350 GB de RAM/VRAM	Factible. Usa GGUF de 1 bit de Unsloth y ajusta tus expectativas de rendimiento.
Mac o PC con 64 a 128 GB	No recomendable. Obtendrás segundos por token, no tokens por segundo.
Solo necesitas K3 dentro de tu producto	Usa la API alojada, compatible con OpenAI y Anthropic.

La conclusión práctica es simple: los pesos abiertos de K3 son importantes porque permiten auditar, ajustar y autoalojar un modelo de clase fronteriza. No significa que la mayoría de equipos deban ejecutarlo en sus propias máquinas.

Si cuentas con el hardware, vLLM ofrece un camino funcional y con buen rendimiento. Si no, el endpoint alojado sigue siendo la opción más directa para integrar K3 en una aplicación.

En ambos casos, trata el modelo como una API de producción: valida esquemas, inspecciona streaming y utiliza simulaciones para que el desarrollo no se detenga mientras el modelo carga o genera razonamiento.