Qué se necesita para alojar Kimi K3 por cuenta propia

Qué implica alojar Kimi K3 por cuenta propia

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

Ese es el veredicto. Todo lo que sigue es la aritmética que lo sustenta, porque esos cálculos se pueden reutilizar en la próxima versión. Varios proveedores de infraestructura publicaron guías de despliegue de K3 durante las semanas posteriores al anuncio del 17 July 2026, y todas suponían que ya disponía de un clúster. Esta página parte del extremo opuesto: cuánto cuesta, qué puede ejecutar en su lugar y cómo determinar en cuál de esas dos situaciones se encuentra.

El número de parámetros totales y el 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 para cada token. La ficha del modelo indica 2.8T de parámetros totales y 104B activados por token, a partir de 896 expertos enrutados, de los cuales 16 se activan para cada token, distribuidos en 93 capas.

Esos dos recuentos de parámetros responden a preguntas diferentes. Confundirlos es el error más habitual en cualquier debate sobre si este modelo se puede ejecutar.

Los parámetros activos determinan el coste de cómputo. Cada token se procesa mediante unos 104B 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 un MoE.

Los parámetros totales determinan 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, pero un enlace PCIe sólo mueve 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 varios segundos.

Por tanto, el coste de cómputo es bajo y el 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ó con conocimiento de cuantización y se publicó con pesos MXFP4 y activaciones MXFP8, por lo que la fila de 4 bits es la válida. Las filas superiores 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 ocupa cerca de 1.5 TB, en lugar de 1.4 TB exactos.

Esto elimina la salida habitual. «Sólo hay que cuantizarlo» 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, pero tendría un coste de precisión que nadie ha medido en este checkpoint. Aun así, seguiría superando con mucho la capacidad de cualquier tarjeta individual.

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
  }
]

Tome estas cifras como un mínimo, no como un objetivo. Sólo cuentan los pesos: no incluyen la caché KV, los búferes de activaciones, la fragmentación del asignador ni el margen para una segunda solicitud simultánea. También suponen una división paralela uniforme, algo que no siempre permiten 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 para H100 formada por cuatro nodos de 8 GPU, con 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 activaciones 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 único SKU.

La caché KV es la parte que suele sorprender

Los pesos tienen un coste fijo. La caché KV (clave-valor) no: crece con la longitud del contexto y vuelve a crecer con cada usuario simultáneo. Para la atención ordinaria, la fórmula es bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element, y después hay que multiplicar por la longitud del contexto y por la concurrencia.

Este es un ejemplo calculado, sólo a modo de 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, más de lo que puede contener cualquier tarjeta individual, para una sola conversación.

K3 no utiliza atención ordinaria, y esa última cifra 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 la clave y el valor 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. Mida el valor en su propio 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 se mantiene en la próxima versión. Si un modelo anuncia un contexto de un millón de tokens y no explica su diseño de atención, suponga que la caché es la limitación principal hasta que se demuestre lo contrario.

Nivel 1: alquilar el clúster por horas

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 un presupuesto. Los precios 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. Tome la cifra real de su proveedor y vuelva a hacer la multiplicación: GPU por horas por tarifa. El objetivo del gráfico es mostrar la proporción. Activar 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 lanzamiento 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 modificar es el que se ejecuta en un clúster real. Añada los indicadores de paralelismo que correspondan a su hardware: SGLang usa --tp-size para el paralelismo tensorial 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 se ha cerrado, así que revise el registro del servidor antes de volver a intentarlo.

El fallo 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 no incluían en el momento del lanzamiento, y el síntoma es que el servidor se cierra durante el arranque con una línea de la forma Model architectures [...] are not supported for now. Ningún cambio de configuración soluciona esto, porque el código necesario para ejecutar esas capas no está incluido en su compilación. Instale la versión nightly que indica 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 consume unos 25 minutos de tiempo de clúster antes del 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 se ejecuta K3. Dígalo explícitamente antes de empezar, porque la mayoría de los hilos sobre «ejecutar K3 localmente» terminan aquí sin reconocerlo.

La regla de ajuste es la misma fórmula, aplicada 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, lo que permite estas combinaciones:

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

Todas las combinaciones anteriores suponen una petición cada vez. Cuando una segunda persona envía una solicitud, cada ranura simultánea necesita su propia caché KV. Ese es el equilibrio entre las ranuras paralelas, las peticiones en cola y la VRAM disponible que las opciones NUM_PARALLEL y MAX_QUEUE de Ollama gestionan por usted.

Ollama es la forma más rápida de 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 muestra un indicador de entrada. Si una etiqueta no existe, devuelve Error: model "..." not found. Por tanto, copie las etiquetas de la página de la biblioteca en lugar de escribirlas de memoria. El tutorial completo, 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, comparación directa.

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 arreglo choices. Un 401 indica que la clave es incorrecta o que falta el prefijo Bearer. Un error de modelo no encontrado suele indicar que cambió el id, porque los proveedores retiran ids entre checkpoints.

Ahora, el punto de equilibrio, usando la tarifa de alquiler indicada arriba. Un nodo con 8 GPU encendido de forma permanente cuesta 14,400 USD al mes. Con 15.00 USD por millón de tokens de salida, esa misma cantidad compra aproximadamente 960 millones de tokens de salida mediante la API. Para reducir el coste, debe generar cerca de mil millones de tokens de salida al mes, aproximadamente 30 millones al día, y mantener el clúster ocupado durante todo ese tiempo, porque las GPU inactivas se facturan al mismo precio que las que están ocupadas. Las cargas de trabajo de agentes con muchos prompts alejan aún más ese punto: el contexto repetido se factura según la tarifa de aciertos de caché de 0.30 USD por millón, en lugar de la tarifa de fallos de caché de 3.00 USD.

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

Qué stack de serving 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. Presuponen aceleradores de centro de datos y una interconexión rápida entre ellos. En una tarjeta de consumo individual 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, la descarga a 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 varios segundos por token. Demuestra que el archivo se puede analizar. No es un servicio que pueda ponerse a disposición de usuarios. La comparación completa está en Ollama frente a vLLM, y no cambia según el modelo: la cuestión es siempre si se atiende a muchos usuarios en hardware compartido o a un solo usuario en su propia máquina.

Los cuatro números que siguen siendo relevantes después de este punto

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 límite, y ningún método de cuantización lo reduce mucho cuando el lanzamiento ya usa 4-bit.
2. Los parámetros activos determinan la clase de rendimiento. Un MoE de 2.8T con 104B de parámetros activos realiza los cálculos como un modelo de 104B.
3. La caché KV por token, multiplicada por la longitud del contexto y la concurrencia, representa el coste que sigue creciendo 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 criterios 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 útil, 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 es un nodo con varias GPU, y las recetas publicadas utilizan 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 la clase GB300. Después debe añadir la caché KV y la memoria de activaciones. En agosto de 2026, Moonshot recomienda 64 aceleradores o más, y el recetario 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 útil. El checkpoint publicado ya utiliza 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, 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 constante. Con un coste supuesto de 2.50 USD por GPU y hora, un nodo de 8 GPU activo de forma permanente cuesta 14,400 USD al mes. La misma cantidad compra 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 activo 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 tener 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, no en la de 2.8T. Esto no indica cuánta memoria se necesita: los 2.8T parámetros permanecen en memoria, porque el router puede llamar a cualquier experto para cualquier token. Use la cantidad de parámetros activos para estimar los tokens por segundo y la cantidad total para dimensionar la VRAM.