Kimi K3 en 4 GB: la verdad de los 2.8 billones de parámetros

¿Se puede ejecutar Kimi K3 en un GPU de 4 GB? No en el sentido ordinario de "ejecutar localmente". Los pesos nativos MXFP4 de Kimi K3 necesitan aproximadamente 1.4 TB antes de metadatos y overhead de ejecución. Una tarjeta de 4 GB solo puede actuar como un pequeño dispositivo de almacenamiento temporal si el software transmite pequeños fragmentos del modelo desde disco o memoria del host. Eso es técnicamente interesante, pero no es lo mismo que cargar Kimi K3 en 4 GB de VRAM, y ninguna receta actual de Kimi K3 lo convierte en un setup práctico.^[1][2]

La distinción importa porque tres hechos verdaderos a menudo se combinan en una conclusión engañosa: Kimi K3 es disperso, solo 104B parámetros están activos por token, y las herramientas de descarga por capas han ejecutado modelos 70B más pequeños en GPUs de 4 GB. Ninguno de esos hechos hace que un checkpoint de 2.8T quepa en 4 GB. Esta guía hace la matemática de memoria, explica qué cambia realmente la descarga, verifica el soporte actual del software y muestra la ruta de hardware bajo que funciona hoy.

TL;DR

• Kimi K3 realmente tiene 2.8T parámetros totales. Es un modelo Mixture-of-Experts disperso con 104B parámetros activados por token, 93 capas, 896 expertos, y una ventana de contexto de 1M tokens.^[1]
• MXFP4 no lo hace pequeño. Cuatro bits por parámetro coloca el piso de peso bruto alrededor de 1.4 TB decimal, o 1.27 TiB, antes de escalas, metadatos, tensores no-4-bit y estado en tiempo de ejecución.
• Los 104B activos es una cifra de cómputo, no de almacenamiento. El router puede elegir expertos diferentes en el siguiente token, por lo que todos los expertos deben permanecer accesibles en algún lugar.
• Un GPU de 4 GB solo puede ser un área de almacenamiento temporal. La descarga a disco o CPU mueve fragmentos del modelo a través de VRAM; no elimina la necesidad de almacenar el modelo completo.
• AirLLM no documenta actualmente soporte para Kimi K3. Su ejemplo publicado de 4 GB tiene como objetivo Llama 3 70B, mientras que Kimi K3 usa una nueva arquitectura MoE multimodal personalizada.^[4]
• La ruta práctica es una API. Una laptop de gama baja puede llamar a Kimi K3 a través de un endpoint OpenAI-compatible mientras el modelo se ejecuta en infraestructura remota.

Realidad de hardware de Kimi K3 de un vistazo

Moonshot describe Kimi K3 como un modelo agentic multimodal de peso abierto construido sobre Kimi Delta Attention, Residuales de Atención y Stable LatentMoE. Activa 16 de 896 expertos enrutados para cada token e incluye un codificador de visión MoonViT-V2.^[1][2]

Esas elecciones arquitectónicas reducen el costo de cómputo y contexto largo. No convierten un checkpoint a escala de billones en un modelo GPU de consumidor.

Por qué 2.8 billones de parámetros MXFP4 aún necesitan aproximadamente 1.4 TB

El primer cálculo es simple:

2.8 billones de parámetros × 4 bits
= 11.2 billones de bits
= 1.4 billones de bytes
= aproximadamente 1.27 TiB

Este es un límite inferior, no una estimación de implementación completa. Los checkpoints reales también llevan escalas de cuantización, índices, configuración, embeddings, tensores almacenados en otras precisiones, y el codificador de visión de 401M parámetros. El tiempo de ejecución agrega activaciones, memoria de trabajo de expertos seleccionados, estado de atención, kernels CUDA o NPU, y un presupuesto KV o de estado recurrente que crece con concurrencia y configuraciones de contexto.^[1]

El checkpoint oficial de Hugging Face se divide en muchos shards safetensor grandes; los shards individuales listados se miden en decenas de gigabytes. Un shard solo puede exceder la capacidad completa de una tarjeta de 4 GB antes de que el motor de inferencia haya asignado un único buffer de activación.^[3]

Para comparación, una tarjeta de 4 GB teóricamente puede sostener alrededor de 8 mil millones de parámetros planos de 4-bit si cada byte estuviera disponible para pesos. En la práctica puede sostener menos porque el tiempo de ejecución también necesita memoria. Kimi K3 es aproximadamente 350 veces más grande en términos de conteo total de parámetros.

Por qué "104B parámetros activos" no significa un modelo de 52 GB

La dispersión MoE reduce aritmética, no el checkpoint que debes mantener disponible. Kimi K3 enruta cada token a través de un pequeño subconjunto de sus 896 expertos, por lo que solo 104B de los 2.8T parámetros participan en el pase hacia adelante de ese token. A cuatro bits cada uno, los parámetros 104B solos representan aproximadamente 52 GB de datos de peso antes del overhead en tiempo de ejecución.

Incluso esa estimación de 52 GB no debe confundirse con un mini-checkpoint estático. El siguiente token puede elegir un conjunto diferente de expertos. A menos que la carga de trabajo fije las elecciones de expertos—lo que cambiaría el comportamiento del modelo—el tiempo de ejecución necesita acceso al conjunto completo de expertos en la secuencia.

Hay tres números separados:

• 2.8T parámetros totales determinan el almacenamiento completo del checkpoint.
• 104B parámetros activos aproximan el cómputo y acceso de datos por token.
• 4 GB de VRAM es solo la cantidad que puede residir en la GPU en un momento.

La activación dispersa hace Kimi K3 más eficiente que un modelo denso de 2.8T. No hace que el modelo completo sea una descarga de 104B, y 104B aún está muy lejos de un GPU de 4 GB.

Cómo la descarga capa por capa puede usar un GPU de 4 GB

La descarga por capas cambia dónde esperan los pesos, no cuántos pesos existen. Un bucle de descarga básico se ve así:

1. Mantén la mayoría de los pesos del modelo en SSD o en RAM del sistema.
2. Carga la siguiente capa o fragmento de experto requerido en la memoria de GPU.
3. Ejecuta esa parte del pase hacia adelante.
4. Desaloja el fragmento y carga el siguiente.
5. Repite la secuencia para cada capa y cada token generado.

Así es cómo un modelo más grande que VRAM puede ejecutarse en absoluto. AirLLM popularizó el patrón con una demostración Llama 3 70B en un GPU de 4 GB, descomponiendo un modelo en shards en el nivel de capas y solapando carga con cómputo.^[4]

Kimi K3 hace el patrón mucho más difícil. Tiene 93 capas, cientos de expertos posibles, un stack de atención KDA/Gated-MLA personalizado, multimodalidad nativa, y más de un terabyte de pesos cuantizados. Una capa MoE completa puede ella misma ser más grande que 4 GB, por lo que un motor compatible necesitaría transmisión en el nivel de subcapa o experto—no meramente descarga de capas ordinaria.

El cuello de botella de rendimiento entonces se vuelve movimiento de datos. Generar un token puede provocar muchas lecturas de expertos aleatorias o semi-aleatorias en docenas de capas. Incluso un SSD NVMe rápido es órdenes de magnitud más lento que memoria del acelerador, y el mismo proceso se repite para el siguiente token. La descarga puede hacer que un experimento comience; no lo hace interactivo.

¿Puedes ejecutar Kimi K3 en un GPU de 4 GB con AirLLM hoy?

No según su soporte publicado y ejemplos a partir del 1 de agosto de 2026. AirLLM documenta Llama, Mixtral, Qwen, ChatGLM, Baichuan, Mistral, InternLM y familias de modelos relacionadas. Su resultado de 4 GB destacado es Llama 3 70B, no Kimi K3.^[4]

Esta ausencia importa. Kimi K3 no es un checkpoint Llama más grande que un cargador existente pueda identificar automáticamente. Una implementación funcional debe entender:

• Configuración de modelo personalizado de Kimi K3 y nombres de tensores;
• Enrutamiento Stable LatentMoE a través de 896 expertos;
• pesos nativos MXFP4 y activaciones MXFP8;
• Capas de atención KDA y Gated MLA periódicas;
• salida de razonamiento preservado y la torre de visión multimodal;
• particionamiento consciente de expertos lo suficientemente pequeño para la VRAM disponible.

Moonshot actualmente recomienda vLLM, SGLang y TokenSpeed para la implementación de Kimi K3. No lista AirLLM como un motor soportado.^[1]

Eso no prueba que un puerto comunitario de 4 GB sea imposible. Significa que un ejemplo Llama copiado de AirLLM no es un tutorial reproducible de Kimi K3 hoy. Una reclamación creíble debe proporcionar una rama pública, commit exacto, detalles de almacenamiento y RAM, prompt, salida, tokens por segundo, y prueba de que los pesos oficiales completos se usaron.

Qué parece una implementación de Kimi K3 validada en su lugar

Las recetas de producción de Kimi K3 operan a escala de clúster. Una guía vLLM-Ascend actual valida un despliegue de 131K-contexto en cuatro nodos Atlas 800 A3, cada uno con dieciséis NPUs de 64 GB. Su configuración de 1M-contexto requiere al menos ocho nodos de este tipo.^[5]

Eso no es un mínimo universal—diferentes aceleradores, motores, concurrencia y límites de contexto cambian el requisito—pero es una verificación de realidad útil. La configuración validada mide memoria de acelerador agregada en terabytes, no gigabytes.

La respuesta de hardware correcta depende de si el objetivo es prueba de ejecución, uso interactivo, servicio multi-usuario o rendimiento de producción. La frase "se ejecuta en 4 GB" es sin sentido sin ese objetivo.

Una lista de verificación para evaluar cualquier reclamación de Kimi K3 de 4 GB

Antes de seguir un tutorial, busca evidencia que responda estas preguntas:

1. ¿Es el checkpoint oficial de 2.8T? Una destilación, proxy o modelo más pequeño que lleva el nombre Kimi no es Kimi K3.
2. ¿Dónde se almacenan los pesos completos? La respuesta debe dar cuenta de bien más de un terabyte de almacenamiento local o de red.
3. ¿Cuánta RAM del sistema se requiere? "GPU de 4 GB" no dice nada sobre 512 GB o 1 TB de memoria del host sentada junto a él.
4. ¿Qué commit de motor de inferencia soporta K3? Un comando pip install genérico no es suficiente para una nueva arquitectura.
5. ¿Se admite visión, o solo lenguaje? Saltar el codificador de visión de 401M cambia la superficie del modelo probado.
6. ¿Qué longitud de contexto se usó? Una demostración de 64-token y una sesión de 1M-token tienen necesidades de tiempo de ejecución radicalmente diferentes.
7. ¿Cuál es el rendimiento medido? Requiere tokens por segundo—o por minuto—más tiempo al primer token.
8. ¿Se verificó la respuesta? Un proceso iniciado exitosamente no es prueba de que cargó los pesos correctos o generó salida coherente de K3.

Si un post reporta solo VRAM, ha omitido los recursos que hacen el truco posible.

La forma práctica de usar Kimi K3 desde una computadora GPU de 4 GB

La ruta que funciona hoy es mantener la inferencia remota y usar la computadora de gama baja como cliente. El GPU local es irrelevante; todo lo que necesita es una conexión de red y una clave de API.

reAPI expone Kimi K3 a través de un endpoint Chat Completions OpenAI-compatible:

curl https://api.reapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $REAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "kimi-k3",
    "messages": [
      {
        "role": "user",
        "content": "Explain how expert routing changes memory access in a sparse MoE model."
      }
    ],
    "reasoning_effort": "high",
    "stream": true
  }'

Esto no es inferencia local, y no debe comercializarse como tal. Es la respuesta práctica para desarrolladores que quieren capacidad de Kimi K3 sin adquirir y operar un clúster de aceleradores de múltiples nodos. El contrato de solicitud completo está en la documentación de la API de Kimi K3, con tasas en vivo en la página del modelo.^[6]

Si aún quieres experimentar con offloading local

Trátalo como investigación de sistemas, no como una instalación de un comando. Una lista de preflight realista es:

• al menos 1.5–2 TB de almacenamiento rápido libre para el checkpoint, cachés y artefactos de conversión;
• suficiente ancho de banda y paciencia para descargar muchos shards grandes;
• una rama de motor de inferencia que explícitamente soporta la arquitectura de Kimi K3 y formato MXFP4;
• un plan para RAM del host, memory mapping, page cache y resistencia del SSD;
• modo solo lenguaje si el tiempo de ejecución experimental no ha implementado visión;
• contexto corto y salidas minúsculas para la primera validación;
• instrumentación para lecturas de disco, utilización de GPU, tiempo al primer token y corrección de salida.

No inventes un comando funcional reemplazando un ID de modelo Llama con moonshotai/Kimi-K3. Hasta que el motor de offloading explícitamente soporte K3, el resultado más probable es una configuración no soportada, desajuste de tensores o fallo de memoria insuficiente durante la conversión.

FAQ

¿Puede Kimi K3 realmente ejecutarse en un GPU de 4 GB?

No como un modelo local autosuficiente y práctico. Un tiempo de ejecución especializado futuro podría usar 4 GB de VRAM como un buffer de almacenamiento mientras transmite pesos desde almacenamiento o RAM mucho más grandes, pero el modelo completo no cabe y las recetas actuales de 4 GB mainstream no documentan soporte para Kimi K3.

¿Cuán grandes son los pesos de Kimi K3?

El piso teórico para 2.8T parámetros a cuatro bits cada uno es aproximadamente 1.4 TB decimal, o 1.27 TiB. El checkpoint real y el tiempo de ejecución requieren más debido a metadatos de cuantización, tensores de otras precisiones, el codificador de visión y estado de ejecución.

¿Por qué Kimi K3 dice que solo 104B parámetros están activos?

Kimi K3 es un modelo MoE disperso. Cada token usa un subconjunto de expertos, reduciendo cómputo, pero los tokens futuros pueden elegir expertos diferentes. El conjunto completo de 2.8T expertos aún necesita permanecer accesible.

¿MXFP4 significa que cualquier GPU con 4 GB puede ejecutarlo?

No. MXFP4 significa que los pesos principales usan aproximadamente cuatro bits por valor. Cuatro bits por 2.8 billones es aún aproximadamente 1.4 TB antes de overhead.

¿Puede AirLLM ejecutar Kimi K3?

AirLLM no lista actualmente Kimi K3 entre sus familias de modelos documentadas ni proporciona una receta de Kimi K3. Su ejemplo de 4 GB es para Llama 3 70B. El soporte podría agregarse más tarde, pero no debe asumirse del cargador de modelo genérico.

¿Cuál es la forma más barata y práctica de usar Kimi K3?

Para uso ocasional o de desarrollo, usa una API alojada de pago por token. El auto-alojamiento solo se vuelve racional cuando el control, volumen sostenido o necesidades de ubicación de datos justifican hardware de múltiples nodos y trabajo de operaciones.

¿Puedo ejecutar una versión más pequeña de Kimi K3 localmente?

Pueden aparecer destilaciones comunitarias, pero son modelos separados con pesos diferentes y capacidad. Si el requisito es un asistente local de 4 GB, elige un modelo diseñado para ese presupuesto de memoria e etiquétalo con precisión.

El significado honesto de ejecutar Kimi K3 en un GPU de 4 GB

Ejecutar Kimi K3 en un solo GPU de 4 GB es creíble solo bajo una definición estrecha: el GPU sostiene un pequeño pedazo mientras el resto de un checkpoint de aproximadamente 1.4 TB vive en otro lugar y transmite a través de él. Eso puede convertirse en una demostración valiosa de investigación, pero no es un despliegue local práctico hoy.

El título es increíble porque omite la máquina alrededor del GPU: SSD, RAM del sistema, tiempo de transferencia de tiempo de ejecución personalizado, e infraestructura remota. Cuenta todos esos recursos antes de juzgar la reclamación. Si el objetivo es usar Kimi K3 en lugar de estudiar offloading extremo, la API es la ruta que funciona en una laptop de 4 GB ahora.

Divulgación: reAPI publica este artículo y ofrece acceso a la API de Kimi K3 alojada. Los hechos de arquitectura y cuantización provienen del repositorio oficial de Moonshot e informe técnico. La evaluación de 4 GB se deriva de esas especificaciones, documentación de motor actual y aritmética de almacenamiento básica; no es una reclamación de que reAPI reprodujo una generación completa de Kimi K3 en un GPU de 4 GB.

References

1. Moonshot AI. Kimi K3 official repository — architecture, model summary, native MXFP4, and recommended inference engines. Retrieved August 1, 2026. github.com/MoonshotAI/Kimi-K3
2. Kimi Team. Kimi K3: Open Frontier Intelligence. Published July 2026. arxiv.org/abs/2607.24653
3. Moonshot AI. Kimi K3 official weights and model card. Retrieved August 1, 2026. huggingface.co/moonshotai/Kimi-K3
4. AirLLM. Supported model families and 4GB Llama 3 70B layer-offloading example. Retrieved August 1, 2026. github.com/lyogavin/airllm
5. vLLM Ascend. Validated Kimi K3 multi-node deployment guide. Retrieved August 1, 2026. docs.vllm.ai/projects/ascend/tutorials/models/Kimi-K3
6. reAPI. Kimi K3 API reference and current model page. Retrieved August 1, 2026. reapi.ai/docs/kimi-k3 and reapi.ai/models/kimi-k3

Further reading

• reAPI. Kimi K3: The Complete Guide to Moonshot's 2.8T Flagship. reapi.ai/blog/kimi-k3-complete-guide
• reAPI. Best Open-Source AI Video Models for Local GPUs. reapi.ai/blog/best-open-source-ai-video-models-local-gpu-2026
• Moonshot AI. Kimi K3 official repository. github.com/MoonshotAI/Kimi-K3