Cómo ejecutar Kimi K3 localmente: hardware, memoria y límites de implementación

Ejecutar el Kimi K3 completo localmente es posible con los pesos publicados, pero el despliegue práctico aún requiere memoria, aceleradores e interconexiones a escala de clúster.

Después del lanzamiento de pesos abiertos del 27 de julio, la pregunta ya no es si existe un punto de control, sino si tu sistema puede descargarlo, cargarlo y servirlo a una velocidad útil. El repositorio público tiene alrededor de 1.56 TB en 96 fragmentos safetensor, mientras que el modelo contiene 2.8 billones de parámetros totales y activa 104 mil millones por token. Esos números mantienen a una PC normal, Mac, NAS doméstico o servidor de GPU única fuera del rango práctico para el modelo completo, por lo que las secciones a continuación separan almacenamiento, memoria, topología de aceleradores, soporte en tiempo de ejecución y rutas de respaldo realistas.

¿Qué está disponible ahora que se han publicado los pesos de Kimi K3?

El lanzamiento de pesos abiertos Kimi K3 incluye el punto de control completo del modelo y el informe técnico. El repositorio público del modelo muestra actualmente alrededor de 1.56 TB de archivos y 96 fragmentos safetensor numerados. Esa cifra es útil para planificar descargas y capacidad de disco, pero no es una especificación mínima de VRAM.

El resumen del modelo publicado confirma 2.8T parámetros totales, 104B parámetros activados, 93 capas, 69 capas de Atención Kimi Delta y 24 capas Gated MLA. Su enrutamiento Stable LatentMoE selecciona 16 de 896 expertos enrutados por token y también usa dos expertos compartidos. Los pesos son MXFP4, las activaciones son MXFP8, y el contexto máximo anunciado es de 1,048,576 tokens.

El soporte de despliegue también es más concreto que antes del lanzamiento. vLLM, SGLang y TokenSpeed están listados como motores de inferencia recomendados, pero cada uno requiere kernels conscientes de K3, código del modelo, fragmentación y configuraciones de memoria. Un comando genérico mostrado por una biblioteca cliente no convierte el punto de control en un modelo local a escala de consumidor.

¿Por qué MoE disperso aún requiere una memoria enorme?

Kimi K3 realiza el cálculo con 104B parámetros activados para cada token, pero todos los expertos MoE aún consumen almacenamiento y memoria de servicio. El enrutador puede seleccionar diferentes expertos para el siguiente token, por lo que el conjunto completo de pesos de 2.8T debe permanecer accesible en algún lugar del despliegue.

Seleccionar 16 de 896 expertos enrutados reduce el trabajo de expertos realizado para un token. No significa que una máquina pueda mantener solo 16 expertos, descartar el resto y aún así ejecutar el modelo liberado sin cambios. La poda de expertos, destilación o transmisión crearían un compromiso operativo diferente y no deben confundirse con la activación dispersa normal.

La cifra de 104B parámetros activados es por lo tanto una descripción de la escala de cómputo, no un atajo para estimar el tamaño del punto de control. Multiplicar 104B por cuatro bits y afirmar que el modelo necesita solo unos 52 GB ignoraría los pesos de expertos inactivos pero aún necesarios, componentes densos, expertos compartidos, capas de atención, pesos de visión y el estado en tiempo de ejecución.

¿Cuál es el mínimo piso de memoria para pesos?

Con 2.8 billones de parámetros, el cálculo más simple del límite inferior es el total de parámetros multiplicado por los bits almacenados por parámetro. MXFP4 ofrece un piso de carga útil de cuatro bits: 2.8T × 4 bits es aproximadamente 1.4 TB, o alrededor de 1.27 TiB, solo para la carga útil de pesos en bruto.

El repositorio publicado tiene aproximadamente 1.56 TB, lo que muestra por qué la memoria de servicio se extiende más allá de un simple cálculo de pesos. El empaquetado del punto de control, escalas de bloque, alineación de tensores, archivos de configuración, activos del tokenizador, componentes de visión y otros datos del modelo elevan la descarga real por encima del límite teórico de cuatro bits.

Se deben planificar por separado cuatro presupuestos diferentes: almacenamiento persistente de descarga, espacio temporal de preparación, RAM del host y HBM o VRAM del acelerador. Un servicio en ejecución necesita además espacio para estado KDA, caché MLA KV, activaciones, buffers de comunicación, núcleos, captura de gráficos y margen para fallos. Por lo tanto, el tamaño del repositorio de 1.56 TB no es un requisito completo de RAM ni de memoria GPU.

¿Qué hardware puede ejecutar realmente Kimi K3 localmente?

No existe una lista honesta de GPU mínima orientada al consumidor para el modelo completo. Un sistema que técnicamente pueda mapear o transmitir el punto de control no es automáticamente capaz de un servicio estable e interactivo. Los requisitos prácticos de hardware para Kimi K3 dependen de la residencia de pesos, núcleos MXFP4 soportados, ancho de banda de interconexión, capacidad de caché, longitud de contexto, concurrencia y el motor de servicio.

El soporte publicado day-zero Kimi K3 de vLLM sitúa la clase inicial realista en un nodo empresarial con ocho aceleradores. Los materiales actuales de vLLM describen aceleradores clase GB300 o MI350X/MI355X como puntos de partida, mientras que SGLang publica ejemplos conscientes de topología incluyendo B300 1×8, GB300 2×4, B200 2×8, H200 2×8, H100 4×8 y MI350X/MI355X 1×8.

Estas son recetas de tiempo de ejecución publicadas y configuraciones iniciales, no un mínimo certificado único para cada carga de trabajo. Aceleradores más antiguos o pequeños pueden requerir más nodos, diferentes núcleos de cuantización, contexto reducido o paralelismo experto adicional. El tráfico de producción también necesita capacidad para solicitudes concurrentes, trabajadores fallidos y margen de rendimiento, no solo para alojar el punto de control una vez.

¿Por qué sigue siendo incorrecta la topología de una sola estación de trabajo o NAS?

La división de capacidad bruta subestima el problema. Incluso si se ensambla suficiente memoria agregada, el paralelismo experto convierte el enrutamiento en tráfico de red. Los tokens deben llegar a los aceleradores que contienen sus expertos seleccionados y luego regresar al resto de la tubería del modelo.

Los nodos aceleradores empresariales ofrecen más que memoria. Combinan enlaces GPU de alto ancho de banda, redes con capacidad RDMA, bibliotecas de comunicación colectiva y núcleos diseñados para paralelismo tensorial, experto, de datos o de tuberías. Una colección de GPUs de consumo conectadas mediante PCIe ordinario o una red doméstica puede mostrar suficiente capacidad nominal pero ser demasiado lenta o frágil para un servicio útil.

Un NAS es valioso para almacenar fragmentos de puntos de control, registros, conjuntos de datos, índices de recuperación y datos de aplicaciones, pero el almacenamiento en red no reemplaza el ancho de banda de memoria del acelerador. El mejor papel para un servidor doméstico suele ser mantener los datos privados y la recuperación cerca del usuario mientras se deja la inferencia de modelos avanzados a un clúster adecuado o punto final alojado. En ese diseño, un servidor doméstico separa la capa de datos local de la inferencia avanzada.

¿Cómo elevan el presupuesto el estado KDA, la caché MLA KV y la longitud del contexto?

Kimi K3 no utiliza una caché de atención completa uniforme en las 93 capas. Sus 69 capas KDA y 24 capas MLA con compuertas crean dos demandas diferentes de memoria de servicio: un grupo de estado KDA con geometría fija del modelo para solicitudes admitidas, y un grupo MLA KV paginado que crece con los tokens almacenados.

Esta división significa que KDA puede reducir el crecimiento de contexto largo que se encuentra en la atención convencional, pero no hace que una solicitud de un millón de tokens sea gratuita. Como el estado KDA y la memoria MLA KV compiten por la capacidad del acelerador, el lado KDA puede limitar las solicitudes admitidas mientras que el lado MLA limita el total de tokens almacenados en caché.

El tamaño del lote, la concurrencia, la longitud promedio del prompt, la longitud del razonamiento generado, las entradas multimodales, la precisión de la caché y la estrategia de precarga/decodificación cambian la capacidad utilizable. La cifra de 1 millón de tokens es una capacidad máxima del modelo, no un valor predeterminado recomendado. Un primer despliegue debe comenzar con un contexto máximo más corto, tamaño de lote uno y baja concurrencia antes de medir fallos por falta de memoria, tiempo de precarga, velocidad de decodificación y tráfico entre nodos.

¿Cómo puedes ejecutar Kimi K3 localmente después del lanzamiento del peso abierto?

Ejecutar Kimi K3 localmente ahora significa construir un servicio de inferencia distribuida alrededor del punto de control liberado, no instalar una aplicación de escritorio normal. La secuencia más segura es validar el almacenamiento, el soporte del entorno de ejecución, la topología y un punto operativo pequeño antes de aumentar el contexto o el tráfico.

1. Prepara el almacenamiento. Reserva al menos el espacio aproximado de 1,56 TB del repositorio más espacio extra para descargas parciales, cachés, imágenes de contenedores, registros y archivos temporales.
2. Selecciona un motor compatible. Usa una ruta de implementación específica para Kimi K3 con vLLM, SGLang o TokenSpeed con el código del modelo, los kernels y la versión del contenedor o rama requeridos.
3. Iguala la topología. Elige una configuración empresarial de múltiples GPU o múltiples nodos con suficiente HBM y el enlace NVLink, MNNVL o RDMA esperado por sus configuraciones de paralelismo tensorial y experto.
4. Comienza por debajo de los límites principales. Reduce la longitud máxima del modelo, el tamaño del lote y la concurrencia, luego verifica la carga, el comportamiento por falta de memoria (OOM), la corrección de la salida, la velocidad de precarga, la velocidad de decodificación y el tráfico entre nodos.
5. Escala solo después de medir. Añade contexto, solicitudes concurrentes, funciones de caché, entradas multimodales o decodificación especulativa una variable a la vez.

Un comando como vllm serve o sglang serve describe cómo iniciar un entorno de ejecución distribuido compatible; no elimina el requisito de hardware. Cuando la clase de acelerador requerida no está disponible, las opciones realistas son una API alojada, una arquitectura híbrida que mantiene los archivos y la recuperación local, o un modelo local más pequeño que se ajuste al presupuesto real de memoria y fiabilidad del servidor doméstico.

Preguntas frecuentes

¿Puedo ejecutar Kimi K3 localmente en un PC normal, Mac o NAS doméstico?

No a la velocidad práctica del modelo completo. El repositorio ocupa aproximadamente 1,56 TB antes de los gastos generales de servicio, mientras que un sistema local normal también carece de la memoria aceleradora y la topología de alta velocidad esperadas por los entornos de ejecución actuales. La transmisión experimental avanzada o la descarga pesada pueden demostrar que un lanzamiento es técnicamente posible, pero no equivale a un servicio receptivo o listo para producción.

¿Cuánto almacenamiento y memoria requiere Kimi K3?

El piso transparente de carga útil de peso MXFP4 es de aproximadamente 1.4 TB, mientras que el repositorio público es de alrededor de 1.56 TB. Luego necesita espacio extra en disco, RAM del host, HBM o VRAM del acelerador, estado KDA, caché KV MLA, activaciones, espacio de trabajo para comunicación y margen operativo. No existe un solo número que represente todas esas capas.

¿Cuál es la configuración mínima publicada de GPU para Kimi K3?

Las configuraciones publicadas más pequeñas del día cero son nodos empresariales con ocho tarjetas aceleradoras, con las rutas actuales vLLM y SGLang centradas en hardware clase B300, GB300 o MI350X/MI355X. Considere esos como puntos de partida para la ejecución, no como un mínimo garantizado universal; el contexto, concurrencia, versión del motor y objetivos de producción pueden requerir más recursos.

¿Puede Kimi K3 ejecutarse desde descarga en SSD o NAS?

El almacenamiento SSD o NAS puede contener fragmentos del punto de control, y los entornos experimentales pueden transmitir pesos a través de la memoria del host. El problema limitante es el movimiento repetido de pesos expertos y estado a través del almacenamiento, red, RAM y enlaces PCIe. Esos caminos son mucho más lentos que la HBM del acelerador y las telas GPU de alta velocidad, por lo que un lanzamiento experimental puede ofrecer una latencia inutilizable.

¿Ollama ejecuta el modelo completo Kimi K3 localmente?

La entrada actual de Ollama Kimi K3 usa la etiqueta kimi-k3:cloud. Ejecutar un cliente Ollama local no significa que el punto de control de 1.56 TB esté cargado en la máquina local; la ruta listada está respaldada en la nube.

Conclusión final

Kimi K3 ahora está realmente disponible como un modelo de pesos abiertos, por lo que los operadores de clúster pueden descargar y desplegar el punto de control completo en lugar de depender de estimaciones previas al lanzamiento. La publicación cambia la verificación y la disponibilidad de herramientas, pero no cambia la escala física de un modelo de 2.8T parámetros.

Los números de memoria más útiles de Kimi K3 responden a diferentes preguntas: alrededor de 1.4 TB es el piso transparente de solo pesos de cuatro bits, alrededor de 1.56 TB es la huella actual del repositorio, y 104B es la escala de cómputo activada por token. Ninguno de esos números por sí solo describe la memoria completa requerida para un servicio en ejecución.

Para la mayoría de las personas y usuarios de servidores domésticos, el límite para detenerse es claro: sin un nodo empresarial con ocho aceleradores o un clúster distribuido, use inferencia alojada, mantenga los datos privados y la capa de recuperación local, o seleccione un modelo más pequeño. Esa es la forma práctica de beneficiarse de Kimi K3 sin tratar un NAS, estación de trabajo o GPU única como un supernodo de modelo frontera.