¿Cómo desplegar Kimi K3 localmente?

TL;DR

Kimi K3 es de pesos abiertos pero no de escala para estaciones de trabajo: servir el modelo nativo requiere GPUs de clase centro de datos y memoria distribuida. Use vLLM para la ruta de producción más directa, o SGLang cuando importen la topología, el paralelismo de expertos y el control de caché. Las compilaciones comunitarias GGUF bajan el umbral de hardware, pero aún requieren aproximadamente 500 GB a más de 1 TB de memoria direccionable y sacrifican velocidad o calidad por viabilidad. En PCs y Macs ordinarios, pruebe primero mediante una API alojada y autohospede solo cuando la privacidad, la utilización sostenida o el control de la infraestructura justifiquen el costo.

¿Qué es Kimi K3?

Kimi K3 es el modelo insignia multimodal nativo de pesos abiertos de Moonshot AI para programación de largo horizonte, trabajo de conocimiento con agentes, razonamiento y comprensión visual.

Moonshot lo describe como el primer modelo abierto de clase 3T del mundo. Su arquitectura combina Kimi Delta Attention and Attention Residuals con un diseño MoE disperso que selecciona solo un subconjunto de expertos para cada token.

La escala es inusual incluso para estándares de modelos punteros. En lugar de activar todos los 2.8T parámetros para cada token, K3 selecciona 16 de 896 expertos enrutados, más expertos compartidos. Esto reduce sustancialmente el cómputo por token, aunque todos los pesos del modelo aún deben estar disponibles en algún lugar del sistema de inferencia.

K3 también aplica entrenamiento consciente de cuantización desde la etapa SFT, en lugar de tratar el servicio en baja precisión únicamente como un paso de compresión posterior al entrenamiento.

Su arquitectura, por tanto, está optimizada para servir a gran escala; pero “cómputo disperso” no debe confundirse con “huella de memoria pequeña”. Solo una parte de la red computa cada token, pero el conjunto completo de expertos aún debe ser accesible.

¿Cómo rinde Kimi K3?

El conjunto oficial de benchmarks de Kimi K3 de Moonshot sitúa el modelo cerca de los modelos propietarios punteros, particularmente en ingeniería de software de largo horizonte y cargas de trabajo agenticas.

La siguiente selección cubre razonamiento, programación, agentes y visión. Para todos los puntajes mostrados, un valor más alto es mejor.

Los puntajes oficiales sitúan a Kimi K3 cerca de GPT-5.6 Sol, Claude Fable 5 y Claude Opus 4.8 en tareas de razonamiento, programación, agentes y visión. Trate estos resultados reportados por el proveedor como contexto de capacidades más que como un ranking universal; el análisis detallado de benchmarks se cubre por separado. Para esta guía, el punto operativo es que el autohospedaje ofrece capacidades de frontera y control de infraestructura, pero no un atajo de bajo costo en escritorio.

¿Realmente se puede ejecutar Kimi K3 localmente?

Sí, pero hay dos definiciones muy diferentes de “local”.

• Servidor local / centro de datos privado: realista.
• Escritorio o portátil normal: técnicamente experimentable con compilaciones comunitarias agresivamente cuantizadas, pero generalmente impráctico para uso interactivo.

La receta actual de vLLM para Kimi K3 establece un listón muy alto:

• NVIDIA: al menos 8× GB300
• AMD ROCm: al menos 8× MI355X o MI350X
• Controlador NVIDIA: R580+ para la imagen K3 de CUDA 13 actual
• Infraestructura multinodo recomendada para tráfico real de producción

La guía original de vLLM del día 0 también demostró una ruta de inicio rápido con 8 GPUs B300 o 8 GPUs MI355X. Para un despliegue de producción nuevo, siga la receta más reciente porque refleja la pila de servicio tras las optimizaciones del lanzamiento.

Este es el punto clave: K3 es de pesos abiertos, pero no es un modelo abierto a escala de consumidor.

Pesos oficiales vs cuantizaciones GGUF comunitarias

Hay otra forma de reducir el umbral de hardware: la cuantización comunitaria.

El repositorio actual de Unsloth para K3 proporciona varias variantes GGUF que pueden ejecutarse con software compatible con llama.cpp.

Comparación consolidada. Las cifras de memoria direccionable son estimaciones de planificación (tamaño de descarga más aproximadamente un 10–15% de margen en tiempo de ejecución), no garantías; la configuración de contexto, caché, visión y offload puede requerir más.

Esta distinción también explica por qué algunos artículos tempranos de despliegue local citan 594 GB: 594 GB corresponde ahora a la compilación comunitaria GGUF UD-IQ1_S, no a una descripción útil del checkpoint nativo actual completo.

Un modelo de 466–649 GB es dramáticamente más pequeño que la huella de despliegue original, pero sigue siendo enorme para estándares de estaciones de trabajo. También debe reservar memoria para el estado en tiempo de ejecución, contexto, cachés, el proyector de visión, procesos del sistema operativo y otros gastos generales.

La capacidad de disco no es lo mismo que la memoria de inferencia. Tener un SSD de 1 TB no significa que un modelo de 600 GB se ejecutará rápidamente en una máquina con 64 GB de RAM. El offloading a SSD puede hacer posibles experimentos extremos, pero la generación de tokens puede volverse dolorosamente lenta.

Cómo desplegar Kimi K3 con vLLM

Para autohospedaje serio, vLLM es el punto de partida más sencillo.

Moonshot enumera actualmente a vLLM como uno de sus motores de inferencia recomendados para K3, y vLLM proporciona soporte específico para K3 en KDA, MoE MXFP4, análisis de razonamiento, llamadas de herramientas, caché de prefijos y despliegue distribuido.

Verifique los requisitos previos

Para despliegue de producción con NVIDIA, la receta probada actual usa el contenedor vllm/vllm-openai:kimi-k3.

Compruebe las GPUs:

nvidia-smi

Confirme Docker:

docker --version

Confirme que NVIDIA Container Toolkit ve los aceleradores:

docker run --rm --gpus all nvidia/cuda:13.0.0-base-ubuntu24.04 nvidia-smi

Si el último comando no puede ver todas las GPUs, arregle el runtime de GPU del host/contenedor antes de descargar un modelo de varios terabytes.

Configure su token de Hugging Face

Si el repositorio del modelo requiere autenticación, guarde el token en una variable de entorno en lugar de incrustarlo en scripts.

export HF_TOKEN="YOUR_HUGGING_FACE_TOKEN"

Descargue el contenedor de vLLM para K3

docker pull vllm/vllm-openai:kimi-k3

La receta actual especifica una compilación CUDA 13 y un controlador NVIDIA R580 o más reciente.

Lance Kimi K3

Plantilla inicial actual para Blackwell TP8 (receta de vLLM actualizada 2026-09-10): úsela como base y luego regenere o evalúe el perfil para su hardware y tráfico exactos.

docker run --rm \
  --gpus all \
  --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HF_TOKEN="$HF_TOKEN" \
  -e VLLM_USE_V2_MODEL_RUNNER=1 \
  vllm/vllm-openai:kimi-k3 \
  --model moonshotai/Kimi-K3 \
  --tensor-parallel-size 8 \
  --gpu-memory-utilization 0.95 \
  --kv-cache-dtype fp8 \
  --attention-backend TOKENSPEED_MLA \
  --attention-config '{"use_prefill_query_quantization":true,"mla_prefill_backend":"TOKENSPEED_MLA"}' \
  --prefix-match-unit 128 \
  --enable-prefix-caching \
  --max-model-len 131072 \
  --enable-auto-tool-choice \
  --tool-call-parser kimi_k3 \
  --reasoning-parser kimi_k3

La receta actual requiere la imagen K3 de CUDA 13 y un controlador NVIDIA R580 o más reciente. El caché KV en FP8 debe emparejarse con un backend MLA de prefill/decodificación compatible; evalúe alternativas antes de cambiar la configuración de atención.

Fuente: receta de vLLM para Kimi K3. Esto reemplaza el comando del día 0 en lugar de presentarlo como la receta de producción actual.

Para una primera ejecución de validación, considere limitar la longitud máxima del modelo en lugar de asignar de inmediato los ~1,048,576 tokens completos. La receta actual de vLLM recomienda explícitamente ajustar max-model-len al tipo de carga.

Por ejemplo:

--max-model-len 131072

Esto no cambia el límite de contexto arquitectónico de K3. Simplemente da al motor de servicio un entorno operativo más manejable para sus pruebas iniciales.

Pruebe el endpoint local

vLLM expone una API compatible con OpenAI en el puerto 8000.

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "moonshotai/Kimi-K3",
    "messages": [
      {
        "role": "user",
        "content": "Explain the difference between tensor parallelism and expert parallelism."
      }
    ],
    "max_tokens": 512
  }' 

O use el SDK de OpenAI para Python:

python

from openai import OpenAI

 client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="EMPTY",
    timeout=3600,
 )

response = client.chat.completions.create(
    model="moonshotai/Kimi-K3",
    messages=[
        {
            "role": "user",
            "content": "Write a Python function that validates a JSON schema.",
        }
    ],
    max_tokens=1024,
 )

print(response.choices[0].message.content)

La receta oficial de vLLM usa el mismo patrón localhost compatible con OpenAI, lo que facilita cambiar una aplicación entre inferencia local y alojada.

Cómo desplegar Kimi K3 con SGLang

SGLang es la otra ruta de despliegue principal recomendada oficialmente por Moonshot.

Es particularmente relevante cuando desea un control más profundo sobre el servicio distribuido, el paralelismo de expertos, kernels específicos de hardware o topologías de producción complejas.

Use el Cookbook dedicado de SGLang para Kimi K3 y seleccione una topología específica de hardware. Lo siguiente es el perfil verificado de un solo nodo 8×B300 Unified/Balanced del cookbook; se midió con SGLang v0.5.18 en el commit 71de97b2.

Instale una compilación compatible con K3:

pip install --upgrade pip
pip install uv
uv pip install --prerelease=allow sglang

Lance el perfil verificado B300 TP8/DCP8:

sglang serve \
  --trust-remote-code \
  --model-path moonshotai/Kimi-K3 \
  --tp-size 8 \
  --dcp-size 8 \
  --mem-fraction-static 0.85 \
  --mamba-full-memory-ratio <value-from-official-calculator> \
  --reasoning-parser kimi_k3 \
  --tool-call-parser kimi_k3 \
  --host 0.0.0.0 \
  --port 30000

--mamba-full-memory-ratio depende de la carga: calcúlelo a partir de la longitud media de entrada más salida en el cookbook oficial. No copie esta topología B300 a H100/H200, GB200/GB300, AMD o despliegues multinodo; esos perfiles usan disposiciones diferentes de TP/PP/DCP/EP.

Pruebe el servidor:

curl http://localhost:30000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "moonshotai/Kimi-K3",
    "messages": [{"role": "user", "content": "Give me a five-step debugging plan for a distributed Python application."}]
  }'

Para un despliegue real, valide capacidad, calidad de salida y recuperación ante fallos en la versión, topología, longitud de contexto y mezcla de tráfico exactas de SGLang que pretende ejecutar.

vLLM vs SGLang vs llama.cpp

La elección del motor de inferencia depende principalmente de su hardware y del propósito del despliegue.

Si posee un servidor con 8 GPUs Blackwell/MI35x, comience con vLLM.

Si está diseñando un clúster de inferencia distribuida especializado y desea más controles de bajo nivel de servicio, evalúe también SGLang. assistant_message

Si su objetivo es simplemente “quiero demostrar que K3 puede ejecutarse en el hardware que poseo”, GGUF más llama.cpp es mucho más abordable—siempre que su máquina tenga una cantidad verdaderamente excepcional de memoria.

Cómo ejecutar un Kimi K3 cuantizado con llama.cpp u Ollama

El repositorio comunitario de Kimi K3 GGUF ya proporciona variantes compatibles con llama.cpp.

Esta ruta baja drásticamente la barrera de entrada en comparación con un despliegue nativo de pesos en centro de datos, pero “drásticamente” es relativo: incluso las compilaciones más pequeñas son de cientos de gigabytes.

Instale llama.cpp en macOS o Linux

La tarjeta de modelo GGUF actual proporciona:

curl -LsSf https://llama.app/install.sh | sh

En Windows:

winget install llama.cpp

Inicie un servidor compatible con OpenAI

El repositorio documenta actualmente UD-Q4_K_XL como ejemplo:

llama serve \
  -hf unsloth/Kimi-K3-GGUF:UD-Q4_K_XL

También puede ejecutar el CLI directamente:

llama cli \
  -hf unsloth/Kimi-K3-GGUF:UD-Q4_K_XL

Esos comandos provienen directamente de la tarjeta de modelo GGUF actual de Kimi K3.

Sin embargo, UD-Q4_K_XL ocupa aproximadamente 1.51 TB, por lo que no es la variante con la que la mayoría de usuarios de estaciones de trabajo empezarían. Si su prioridad es reducir los requisitos de memoria más que preservar la mayor calidad posible, investigue primero las variantes más pequeñas de 1 y 2 bits.

Por ejemplo:

llama serve \
  -hf unsloth/Kimi-K3-GGUF:UD-IQ1_M

El directorio actual de UD-IQ1_M es de aproximadamente 649 GB.

Un modelo de 649 GB sigue sin ser un modelo para un portátil normal. Idealmente, el estado del modelo de acceso frecuente debería residir en memoria rápida. El offloading intenso a SSD puede hacer técnicamente posible un experimento extremo sin que sea útil para trabajo interactivo.

Ejecute la misma compilación GGUF con Ollama

Ollama es una capa de conveniencia para la misma ruta de despliegue GGUF, no un cuarto método independiente de autohospedaje.

El repositorio de K3 GGUF también expone una ruta a través de Ollama.

Por ejemplo:

bash

ollama run hf.co/unsloth/Kimi-K3-GGUF:UD-Q4_K_XL

Ollama simplifica la gestión del modelo y la experiencia de API, pero no elimina los requisitos de memoria de K3.

Cambiar el lanzador de llama.cpp a Ollama no puede convertir una cuantización de varios cientos de gigabytes en un modelo de 24 GB de GPU. Los datos subyacentes del modelo aún deben almacenarse y accederse.

Por esta razón, Ollama debe verse como un contenedor de runtime conveniente, no como una solución de hardware.

¿Qué cuantización de Kimi K3 debería elegir?

Para experimentos, la elección es principalmente una compensación entre tamaño del modelo y fidelidad.

Comportamientos importantes al servir Kimi K3

Hay un detalle de implementación específico de K3 fácil de pasar por alto.

K3 usa historial de pensamiento preservado. Moonshot indica que las conversaciones multi-turno y los flujos de llamadas de herramientas deben enviar el mensaje completo previo del asistente de vuelta al modelo, incluyendo reasoning_content y tool_calls, en lugar de preservar solo el contenido visible.

Un patrón de aplicación simplificado se ve así:

messages = [
    {
        "role": "user",
        "content": "Inspect this project and propose a migration plan.",
    }
 ]

first = client.chat.completions.create(
    model="moonshotai/Kimi-K3",
    messages=messages,
    max_tokens=2048,
 )

assistant_message = first.choices[0].message

 # Preserve the whole message object, not just assistant_message.content.
 messages.append(
    assistant_message.model_dump(exclude_none=True)
 )

messages.append(
    {
        "role": "user",
        "content": "Now identify the riskiest part of that plan.",
    }
 )

second = client.chat.completions.create(
    model="moonshotai/Kimi-K3",
    messages=messages,
    max_tokens=2048,
 )

Esto se vuelve especialmente importante para agentes de programación, bucles de herramientas y sesiones autónomas de larga duración.

K3 también mantiene el razonamiento habilitado y soporta esfuerzo de razonamiento bajo, alto y máximo. Cuando su capa de servicio exponga esos parámetros, trate el esfuerzo de razonamiento como otro control de latencia/calidad en lugar de maximizarlo siempre para cada solicitud.

Cómo optimizar un despliegue local de Kimi K3

No asigne inmediatamente el contexto completo de 1M

K3 soporta 1,048,576 tokens, pero la capacidad máxima del modelo y una configuración sensata del servidor son cosas distintas.

Para desarrollo, comience con algo como:

--max-model-len 131072

Luego aumente el contexto solo después de medir memoria disponible, tiempo al primer token, throughput y concurrencia esperada.

Habilite el caché de prefijos

Los agentes de programación reutilizan con frecuencia instrucciones de repositorios, esquemas de herramientas, prompts del sistema y prefijos largos.

Con vLLM:

--enable-prefix-caching

La arquitectura de atención híbrida de K3 requirió tratamiento especial para el caché de prefijos, y vLLM implementó soporte específico del modelo.

Use los parsers de K3

Para cargas de trabajo con agentes, incluya:

--tool-call-parser kimi_k3 \
--reasoning-parser kimi_k3

Esto mantiene las llamadas de herramientas y la salida de razonamiento alineadas con el formato de servicio de K3.

Mantenga el almacenamiento rápido

Un modelo de esta escala ejerce una presión inusual sobre el almacenamiento local durante la primera descarga, carga de checkpoints, actualizaciones y recuperación.

El almacenamiento NVMe es preferible a discos lentos montados en red. Si varias máquinas comparten archivos del modelo, la topología de caché del modelo y el ancho de banda de red pasan a formar parte de la arquitectura de inferencia más que simples detalles de despliegue.

Monitoree más que la utilización de GPU

Rastree:

• Utilización de HBM/VRAM
• RAM de CPU
• Tasa de aciertos de caché
• Tiempo al primer token
• Tokens de decodificación por segundo
• Profundidad de la cola de solicitudes
• Comunicación inter-GPU
• Ancho de banda entre nodos
• Fallos de parseo de llamadas de herramientas
• Tiempo de carga del modelo

A escala K3, una cifra aparentemente saludable de utilización de GPU no le dice si la topología de servicio es eficiente.

Kimi K3 local vs Kimi K3 alojado

El autohospedaje da a los equipos máximo control sobre la ruta de datos, el runtime y los pesos del modelo, pero también los hace responsables de la capacidad de GPU, escalado, actualizaciones, monitoreo y recuperación. El acceso alojado elimina la mayor parte del trabajo de infraestructura y suele ser la ruta más rápida para evaluación o demanda variable.

Para el análisis completo de hardware y punto de equilibrio, lea Kimi K3 Self-Hosting vs API. Para precios por token, caché y comparaciones con K2.7, use la guía de precios de Kimi K3. Por lo tanto, este artículo mantiene la comparación breve y se concentra en comandos de despliegue, configuración y resolución de problemas.

Problemas comunes en despliegues locales de Kimi K3

El modelo no cabe en la memoria de la GPU

Este es el fallo más predecible.

No calcule la memoria a partir de los 104B parámetros activados. Esa cifra describe el cómputo por token, no la cantidad de datos de pesos de expertos que el sistema de servicio debe poner a disposición.

Use una topología distribuida compatible, una cuantización GGUF más pequeña o un servicio alojado.

Errores de CUDA o del controlador NVIDIA

La imagen actual de vLLM para K3 se basa en CUDA 13 y requiere un controlador de host R580+.

Si el host aún está en una pila R575/CUDA 12.9, actualícelo o siga la ruta de compilación desde el código fuente descrita por vLLM en lugar de asumir que el contenedor resolverá la incompatibilidad del controlador del host.

La primera solicitud es extremadamente lenta

Compruebe si el checkpoint aún se está cargando, compilando kernels, calentando cachés o descargando archivos.

Con activos de varios terabytes, “proceso del servidor iniciado” y “modelo listo para tráfico de producción” no son estados equivalentes.

Las llamadas de herramientas fallan intermitentemente

La receta actual de vLLM señala que K3 puede producir ocasionalmente una forma de llamada de herramienta que su parser no espera. Los sistemas de producción deben, por tanto, validar esquemas de llamadas de herramientas e implementar reintentos en lugar de confiar ciegamente en cada llamada generada.

Las conversaciones largas se vuelven menos estables

Asegúrese de devolver el mensaje completo del asistente—incluyendo información de razonamiento y herramientas—a los turnos subsecuentes de K3.

Omitir campos ocultos del estado de razonamiento puede romper el patrón de historial de pensamiento preservado para el cual K3 fue entrenado.

Entonces, ¿cuál es la mejor manera de desplegar Kimi K3 localmente?

Para la mayoría de organizaciones con hardware adecuado, vLLM es la mejor primera ruta de despliegue. Tiene soporte dedicado para K3, una API compatible con OpenAI, parsers específicos del modelo, caché de prefijos, soporte de decodificación especulativa y recetas actuales para hardware.

Elija SGLang cuando la ingeniería de inferencia distribuida y el control fino del servicio sean más importantes que la ruta de configuración más corta.

Elija llama.cpp más una cuantización GGUF comunitaria solo cuando su objetivo sea la experimentación en estaciones/servidores y entienda que incluso las versiones de 1 bit siguen siendo de cientos de gigabytes.

Para una estación de trabajo de desarrollador convencional, la conclusión más práctica es distinta: no compre cientos de gigabytes de RAM solo para forzar K3 en un escritorio. Pruebe Kimi K3 a través de CometAPI primero, cuantifique su beneficio en sus propias tareas y pase al autohospedaje solo cuando la privacidad, la utilización sostenida o el control de infraestructura hagan que la economía valga la pena.

Preguntas frecuentes

¿Puede Kimi K3 ejecutarse en una única GPU de consumo?

No, de forma realista. El modelo está muy por encima de la capacidad de VRAM de GPUs de consumo. Las cuantizaciones GGUF comunitarias de bajo bit reducen la huella sustancialmente, pero las variantes actuales más pequeñas siguen siendo de cientos de gigabytes.

¿Puedo ejecutar Kimi K3 en un Mac?

La ejecución experimental en CPU/Apple Silicon con GGUF y offloading a almacenamiento es posible en principio, pero el rendimiento interactivo y la capacidad de memoria son los factores limitantes. Un MacBook típico no debe tratarse como una plataforma práctica para servir K3.

¿Kimi K3 soporta Ollama?

Las compilaciones GGUF comunitarias pueden lanzarse a través de Ollama. El runtime simplifica la configuración pero no cambia el requisito subyacente de memoria.

¿Es mejor vLLM o SGLang para Kimi K3?

vLLM es el predeterminado más fácil para un despliegue de producción nuevo. SGLang resulta atractivo para equipos que construyen topologías de servicio distribuido sofisticadas. Ambos están entre los motores de inferencia recomendados por Moonshot para K3.

¿Cuánto contexto soporta Kimi K3?

La especificación oficial del modelo soporta 1,048,576 tokens. Un servidor local no tiene que exponer toda la ventana de contexto; establecer un max-model-len más bajo puede ser más práctico para despliegues tempranos y mayor concurrencia.

¿Kimi K3 es de código abierto?

Una descripción más precisa es de pesos abiertos. Moonshot ha publicado los pesos del modelo bajo la Licencia Kimi K3. Revise esa licencia directamente antes de redistribución comercial u otros usos en los que los términos de licencia sean relevantes.

¿Cuál es la manera más fácil de usar Kimi K3 sin GPUs locales?

Una API alojada es la ruta más simple. Kimi K3 está disponible a través de CometAPI con una interfaz de chat-completions compatible con OpenAI, por lo que el código de la aplicación puede permanecer cercano a lo que usaría contra un servidor local vLLM o SGLang.