Requisitos para alojar Kimi K3 por cuenta propia

Qué se necesita para alojar Kimi K3 por cuenta propia

Alojar Kimi K3 por cuenta propia implica disponer de espacio para 2.8 billones de parámetros. Moonshot publicó los pesos abiertos en MXFP4, que ocupa aproximadamente medio byte por peso. Por tanto, sólo los pesos requieren aproximadamente 1.4 TB antes de reservar espacio para un solo token de caché. Ningún acelerador disponible actualmente puede alojar esa cantidad por sí solo. K3 es un modelo multinodo. En un solo servidor, la respuesta es no.

Ese es el veredicto. Todo lo que sigue muestra los cálculos que lo sustentan, porque esos cálculos se pueden reutilizar con la próxima versión. Varias empresas de infraestructura publicaron guías de despliegue de K3 en las semanas posteriores al anuncio del 17 de julio de 2026, y todas partían de que ya disponías de un clúster. Esta página parte del otro extremo: cuánto cuesta, qué puedes ejecutar en su lugar y cómo determinar en cuál de esas dos situaciones te encuentras.

El número total de parámetros y el número de parámetros activos no son iguales

K3 es un modelo de mezcla de expertos. MoE (mezcla de expertos) divide la red en muchas subredes y permite que un router seleccione algunas por token. La tarjeta del modelo indica 2.8T de parámetros totales y 104B activados por token, a partir de 896 expertos dirigidos, de los cuales se activan 16 para cada token, distribuidos en 93 capas.

Estas dos cantidades de parámetros responden a preguntas distintas. Confundirlas es el error más habitual en cualquier debate sobre si un modelo se puede ejecutar.

Los parámetros activos determinan el coste de cómputo. Cada token se procesa con aproximadamente 104B de parámetros. Por tanto, el rendimiento esperado se parece al de un modelo denso de 104B, no al de uno de 2.8T. Esa es precisamente la razón para usar una arquitectura MoE.

El número total de parámetros determina el coste de memoria. El router puede seleccionar cualquier experto para cualquier token. Por eso, todos los expertos deben estar residentes antes de que llegue la primera solicitud. No se pueden mantener 104B en la VRAM y cargar el resto bajo demanda. La carga tendría que completarse en microsegundos, mientras que un enlace PCIe transfiere decenas de gigabytes por segundo. Hay personas que lo intentan. Transmitir los expertos desde NVMe convierte un modelo que debería generar decenas de tokens por segundo en uno que genera un token cada pocos segundos.

Por tanto, el coste de cómputo es bajo, pero el coste de almacenamiento es alto. Dimensione el hardware para 2.8T. Base sus expectativas de velocidad en 104B.

Bytes por peso y de dónde salen los terabytes

Número de parámetros multiplicado por bytes por peso. Para los pesos, esa es toda la fórmula.

[
  {
    "label": "bf16",
    "bytes_per_weight": 2,
    "weights_tb": 5.6
  },
  {
    "label": "fp8",
    "bytes_per_weight": 1,
    "weights_tb": 2.8
  },
  {
    "label": "4-bit (MXFP4, as shipped)",
    "bytes_per_weight": 0.5,
    "weights_tb": 1.4
  },
  {
    "label": "2-bit",
    "bytes_per_weight": 0.25,
    "weights_tb": 0.7
  }
]

K3 se entrenó teniendo en cuenta la cuantización y se publicó con pesos MXFP4 y activaciones MXFP8, por lo que la fila de 4 bits es la relevante. Las filas anteriores sirven como referencia: con bf16, el mismo modelo necesitaría 5.6 TB. MXFP4 también almacena una escala compartida de 8 bits por cada bloque de 32 pesos. Esto añade aproximadamente un 6 por ciento, por lo que el repositorio publicado se acerca más a 1.5 TB que a unos 1.4 TB exactos.

Esto elimina la salida habitual. «Simplemente cuantízalo» no sirve en este caso, porque el checkpoint publicado ya usa 4 bits. Bajar a 2 bits reduciría los pesos a 0.7 TB y tendría un coste de precisión que nadie ha medido en este checkpoint. Aun así, seguiría siendo mucho más de lo que admite una sola tarjeta.

Cuántas GPU necesita Kimi K3

[
  {
    "config": "H100 80GB",
    "hbm_per_gpu_gb": 80,
    "gpus_for_weights": 18
  },
  {
    "config": "H200 141GB",
    "hbm_per_gpu_gb": 141,
    "gpus_for_weights": 10
  },
  {
    "config": "B200 192GB",
    "hbm_per_gpu_gb": 192,
    "gpus_for_weights": 8
  },
  {
    "config": "GB300 288GB",
    "hbm_per_gpu_gb": 288,
    "gpus_for_weights": 5
  }
]

Considere esas cifras como un mínimo, no como un objetivo. Sólo cuentan los pesos: no incluyen la caché KV, los búferes de activación, la fragmentación del asignador ni margen para una segunda solicitud simultánea. Además, suponen una división paralela uniforme, algo que no siempre es posible con 93 capas y 896 expertos.

Las recomendaciones publicadas están muy por encima de ese mínimo. En agosto de 2026, Moonshot recomienda un supernodo con 64 aceleradores o más, y el manual de SGLang incluye una configuración con H100 formada por cuatro nodos de 8 GPU: 32 GPU y 2,560 GB de memoria agregada, frente a un mínimo de 18 tarjetas. Esa diferencia no es un desperdicio. Corresponde a la caché KV, la memoria de activación y el margen necesario para que el servidor procese muchas solicitudes por lotes al mismo tiempo. Incluso la opción más favorable, 5 tarjetas de clase GB300, describe una máquina que la mayoría de los proveedores no alquilan como un SKU individual.

La caché KV es la parte que sorprende a muchos

Los pesos tienen un coste fijo. La caché KV (key value) no: crece con la longitud del contexto y también con cada usuario concurrente. Para la atención convencional, la fórmula es bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element, y después se multiplica por la longitud del contexto y por la concurrencia.

Este es un ejemplo calculado, y sólo es un ejemplo: 64 capas, 8 cabezas KV, dimensión de cabeza 128 y fp8. El resultado es 2 64 8 128 1 = 131,072 bytes, es decir, 128 KiB por token.

[
  {
    "label": "8k context",
    "kv_gib_per_user": 1
  },
  {
    "label": "32k context",
    "kv_gib_per_user": 4
  },
  {
    "label": "128k context",
    "kv_gib_per_user": 16
  },
  {
    "label": "1M context",
    "kv_gib_per_user": 128
  }
]

Un usuario con un contexto de 128k consume 16 GiB. Un usuario con el millón completo consume 128 GiB, una cantidad superior a la capacidad de cualquier tarjeta individual, para una sola conversación.

K3 no usa atención convencional, y ese último número explica el motivo. Sus 93 capas son 69 capas KDA (Kimi Delta Attention) y 24 capas Gated MLA (multi-head latent attention). KDA mantiene un estado recurrente de tamaño fijo en lugar de una caché que crece con cada token, y MLA comprime las claves y los valores en un único vector latente de rango bajo. Por eso, el coste real por token es muy inferior al del ejemplo calculado. Moonshot no ha publicado las dimensiones latentes, así que no indicaré una cifra por usuario para K3. Mídala en su sistema: inicie el servidor con un --max-model-len pequeño, supervise la memoria con nvidia-smi y aumente el límite hasta que falle la asignación.

La lógica del análisis seguirá siendo válida en la próxima versión. Si un modelo anuncia un contexto de un millón de tokens y no proporciona información sobre su diseño de atención, suponga que la caché es la restricción determinante hasta que se demuestre lo contrario.

Nivel 1: alquilar el clúster por hora

Este es el único nivel que ejecuta K3 directamente. No compra el hardware. Lo alquila durante las horas que necesita y lo detiene después.

[
  {
    "label": "1 GPU, always on",
    "gpu_hours": 720,
    "usd_cost": "1,800"
  },
  {
    "label": "8 GPUs, 4 hours a day",
    "gpu_hours": 960,
    "usd_cost": "2,400"
  },
  {
    "label": "8 GPUs, always on",
    "gpu_hours": 5760,
    "usd_cost": "14,400"
  },
  {
    "label": "32 GPUs, always on",
    "gpu_hours": 23040,
    "usd_cost": "57,600"
  }
]

La tarifa es una suposición, no una cotización. Los precios públicos bajo demanda de los aceleradores para centros de datos se situaron aproximadamente entre 2 y 5 USD por hora de GPU hasta 2026, y la capacidad reservada es más barata. Use el valor real de su proveedor y vuelva a calcular la multiplicación: número de GPU por horas por tarifa. El objetivo del gráfico es mostrar la proporción. Ejecutar un nodo de 8 GPU durante cuatro horas al día cuesta 2,400 USD al mes, mientras que mantener en ejecución la configuración de 32 GPU dimensionada para SGLang cuesta 57,600 USD.

Los dos servidores principales publican un comando de inicio en la ficha del modelo.

pip install vllm
vllm serve "moonshotai/Kimi-K3"

pip install sglang
python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K3" --host 0.0.0.0 --port 30000

Ninguno de los dos comandos sin modificaciones sirve para un clúster real. Añada las opciones de paralelismo que correspondan a su hardware: SGLang usa --tp-size para el paralelismo de tensores y --ep-size para el paralelismo de expertos, y el producto de ambos debe ser igual al número real de GPU disponibles.

Compruebe que el servidor se haya iniciado antes de enviar tráfico real:

curl http://127.0.0.1:30000/v1/models

Un servidor en buen estado responde con un objeto JSON que muestra el identificador del modelo. Connection refused significa que el proceso todavía está cargando los pesos o que ya terminó, por lo que debe revisar el registro del servidor antes de volver a intentarlo.

El fallo más habitual el primer día es usar un runtime más antiguo que el modelo. K3 se publicó con KDA y una nueva capa MoE que las versiones estables de vLLM y SGLang todavía no incluían en el momento del lanzamiento. El síntoma es que el servidor termina durante el inicio y muestra una línea con el formato Model architectures [...] are not supported for now. Ningún cambio de configuración lo corrige, porque el código necesario para ejecutar esas capas no está incluido en su compilación. Instale la versión nightly indicada en la ficha del modelo o espere a la versión que la incluya.

Hay un detalle de costes que suele pasar desapercibido. El contador empieza cuando se inicia la instancia, no cuando el modelo está listo. Descargar 1.5 TB a 1 GB/s requiere unos 25 minutos de tiempo de clúster antes de generar el primer token. Prepare los pesos en un volumen que sobreviva a la instancia, para que la segunda ejecución empiece en minutos.

Nivel 2: ejecutar un modelo más pequeño en un acelerador

En este nivel no ejecutará K3. Déjelo claro antes de empezar, porque la mayoría de los hilos sobre «ejecutar K3 localmente» terminan aquí sin reconocerlo.

La regla de ajuste usa la misma fórmula, a menor escala: los parámetros multiplicados por los bytes por peso, más la caché KV y unos 2 GB de sobrecarga del entorno de ejecución, deben caber en la VRAM. Con 4 bits, el cálculo aproximado es de medio byte por parámetro. Esto permite estas combinaciones:

• Tarjeta de 16 GB: un modelo 7B a 4 bits, con espacio para un contexto largo
• Tarjeta de 24 GB: un modelo 14B a 4 bits
• Tarjeta de 48 GB: un modelo 32B a 4 bits
• Tarjeta de 80 GB: un modelo 70B a 4 bits, o un MoE de clase 30B a 8 bits

Ollama es la ruta más corta para poner en funcionamiento un servidor en un VPS con una GPU conectada:

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14b

ollama run descarga el modelo durante el primer uso y después muestra un prompt. Una etiqueta inexistente devuelve Error: model "..." not found. Copie las etiquetas de la página de la biblioteca en lugar de escribirlas de memoria. La guía completa, incluida la unidad de systemd y el acceso remoto, está en ejecutar Ollama en un VPS.

llama.cpp ofrece más control sobre la cuantización y la descarga de capas:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

./build/bin/llama-server -m model.gguf -c 8192 -ngl 99 --host 0.0.0.0 --port 8080

-ngl 99 solicita que todas las capas se ejecuten en la GPU. Revise el registro de carga: muestra cuántas capas se han descargado. Las capas que pasan a la RAM del sistema se ejecutan con el ancho de banda de la RAM en lugar del ancho de banda de HBM. Por eso, la velocidad de generación cae un orden de magnitud en cuanto el modelo deja de caber. Las diferencias entre ambas herramientas se explican en Ollama y llama.cpp en paralelo.

Nivel 3: API alojada y orquestación autogestionada

[
  {
    "label": "Input, cache hit",
    "usd_per_million_tokens": "0.30"
  },
  {
    "label": "Input, cache miss",
    "usd_per_million_tokens": "3.00"
  },
  {
    "label": "Output",
    "usd_per_million_tokens": "15.00"
  }
]

El endpoint es compatible con OpenAI, por lo que un cliente existente funciona después de cambiar la URL base.

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "Say hello."}]}'

Una clave válida devuelve un objeto JSON con un array choices. Un 401 indica que la clave es incorrecta o que falta el prefijo Bearer. Un error de modelo no encontrado normalmente significa que el id cambió, porque los proveedores retiran ids entre checkpoints.

Este es el punto de equilibrio con la tarifa de alquiler asumida anteriormente. Un nodo con 8 GPU siempre encendido cuesta 14,400 USD al mes. A 15.00 USD por cada millón de tokens de salida, el mismo importe compra aproximadamente 960 millones de tokens de salida mediante la API. Para que resulte más barato, hay que generar cerca de mil millones de tokens de salida al mes, aproximadamente 30 millones al día, y mantener el clúster ocupado todo el tiempo. Las GPU inactivas se facturan al mismo precio que las que están ocupadas. Las cargas de trabajo de agentes con mucho contenido en los prompts alejan todavía más ese punto: el contexto repetido se factura a la tarifa de aciertos de caché de 0.30 USD por cada millón, no a la tarifa de fallos de caché de 3.00 USD.

En este nivel, lo que se autohospeda es todo lo que rodea al modelo: una puerta de enlace que conserva la clave de API para que nunca llegue al cliente, registros de solicitudes y respuestas, reintentos, límites de tasa y presupuestos por usuario. Esto se ejecuta en un VPS pequeño sin GPU. La misma separación se aplica a los pesos cerrados: autohospedar Claude no es posible en el nivel del modelo, por lo que la orquestación es la única parte que se controla.

Qué pila de servicio corresponde a cada nivel

Los servidores de la clase vLLM y SGLang pertenecen al nivel 1. Están diseñados para atender muchas solicitudes a la vez, con batching continuo y una caché KV paginada, además de paralelismo de tensores y de expertos distribuido entre varios nodos. Suponen el uso de aceleradores de centro de datos y una interconexión rápida entre ellos. En una sola tarjeta de consumo, son más pesados de instalar y ofrecen pocas ventajas apreciables.

llama.cpp y Ollama pertenecen al nivel 2. Están orientados a una sola máquina, la cuantización GGUF, el uso de la CPU cuando el modelo no cabe y una concurrencia baja. llama.cpp puede cargar técnicamente un MoE enorme manteniendo la mayoría de las capas en la RAM del sistema, pero con un modelo de 2.8T ese método alcanza tiempos de varios segundos por token. Esto demuestra que el archivo se puede analizar correctamente. No es un servicio que se pueda poner a disposición de los usuarios. La comparación completa está en Ollama frente a vLLM, y no cambia según el modelo: la cuestión siempre es si se atiende a muchos usuarios con hardware compartido o a un solo usuario en su propia máquina.

Los cuatro números que seguirán siendo válidos después de este punto de control

1. El número total de parámetros multiplicado por los bytes por peso determina el mínimo de memoria. Nada puede ejecutarse por debajo de ese mínimo. Una vez que el lanzamiento ya es de 4-bit, ningún truco de cuantización lo reduce mucho.
2. Los parámetros activos determinan la categoría de rendimiento. Un MoE de 2.8T con 104B de parámetros activos calcula como un modelo de 104B.
3. La caché KV por token, multiplicada por la longitud del contexto y por la concurrencia, representa el coste que sigue aumentando después de asignar memoria a los pesos.
4. Los tokens por segundo por dólar son el único número que determina el nivel adecuado. Todo lo anterior sirve como entrada para calcularlo.

Aplique esos cuatro valores a cualquier lanzamiento y obtendrá la respuesta correcta antes de abrir la guía de un proveedor. Después, indique la fecha de cada cifra que anote. Los precios y las listas de arquitecturas compatibles cambiaron durante las dos semanas posteriores al lanzamiento de K3, y todas las cifras de esta página se publicaron en julio de 2026.

FAQ

¿Puedo ejecutar Kimi K3 en una sola GPU?

No. Los pesos ocupan aproximadamente 1.4 TB con la precisión MXFP4 que distribuye Moonshot, y el acelerador individual más grande disponible tiene 288 GB. Un modelo MoE no puede transmitir sus expertos inactivos desde el disco a una velocidad utilizable, porque el router puede seleccionar cualquier experto para cualquier token y una lectura mediante PCIe tarda mucho más de lo que permite el presupuesto de tiempo por token. El despliegue más pequeño razonable de K3 requiere un nodo con varias GPU, y las recetas publicadas usan 32 aceleradores o más.

¿Cuánta VRAM necesita Kimi K3?

Empiece con 1.4 TB sólo para los pesos. Esto equivale a 18 tarjetas H100 de 80GB o a 5 tarjetas de clase GB300. Después, añada la memoria de la caché KV y de las activaciones. En agosto de 2026, Moonshot recomienda 64 aceleradores o más. Además, el manual de SGLang publica una configuración de 32 GPU H100 con 2,560 GB agregados. Por tanto, considere la cifra de los pesos como un mínimo, no como un requisito suficiente.

¿La cuantización permite ejecutar Kimi K3 en un solo nodo?

No de forma práctica. El checkpoint publicado ya usa 4 bits y entrenamiento consciente de la cuantización, por lo que el ahorro sencillo ya está aplicado. Reducirlo de nuevo a 2 bits deja los pesos en 0.7 TB, una cifra que sigue siendo más del doble de la capacidad de la tarjeta más grande. Además, el coste de precisión de 2 bits no se ha medido en este modelo.

¿Alquilar GPU es más barato que usar la API de Kimi K3?

Sólo con un volumen alto y estable. Con un coste supuesto de 2.50 USD por hora y GPU, un nodo con 8 GPU encendido permanentemente cuesta 14,400 USD al mes. Por el mismo importe se compran aproximadamente 960 millones de tokens de salida al precio publicado de 15.00 USD por millón. También debe pagar las horas inactivas, las descargas de los pesos y a la persona que mantiene operativo el clúster. Alquile por horas para cargas puntuales y compare el coste con su volumen de tokens medido, no con una estimación.

¿Qué significa que tenga 104B parámetros activos para la velocidad?

Significa que el cálculo por token corresponde al de un modelo de 104B. Por tanto, el rendimiento se sitúa en esa categoría y no en la de 2.8T. Esto no indica cuánta memoria necesita: los 2.8T parámetros permanecen residentes, porque el router puede llamar a cualquier experto para cualquier token. Use el número de parámetros activos para estimar los tokens por segundo y el número total para dimensionar la VRAM.