Qué se necesita para alojar Kimi K3 por cuenta propia

Requisitos para el alojamiento propio de Kimi K3

El alojamiento propio de Kimi K3 implica encontrar espacio para 2.8 billones de parámetros. Moonshot publicó los pesos abiertos en formato MXFP4, lo que equivale a aproximadamente medio byte por peso; por lo tanto, los pesos por sí solos suman cerca de 1.4 TB antes de asignar un solo token de caché. Ningún acelerador a la venta hoy en día puede albergar esa cantidad por sí solo. Para una sola GPU, la respuesta es no. Para un servidor, la respuesta es sí, bajo dos configuraciones. La primera es un nodo de 8 GPU con aceleradores de 288 GB, que es lo que utilizan las recetas de servicio multiusuario más pequeñas publicadas. La segunda es una máquina con aproximadamente 1.6 TB de RAM y VRAM combinadas ejecutando el formato Q8 GGUF sin pérdida de Unsloth en llama.cpp, con o sin GPU, para atender a un usuario a la vez.

Ese es el veredicto. Todo lo que sigue es la aritmética detrás de esto, ya que la aritmética es la parte que reutilizará en la próxima versión. Varios proveedores de infraestructura publicaron guías de despliegue de K3 en las semanas posteriores al anuncio del 16 de julio de 2026, y cada uno asumió que usted ya poseía un clúster. Esta página comienza desde el otro extremo: cuánto cuesta, qué puede ejecutar en su lugar y cómo determinar en cuál de esos dos casos 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 enrutador 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 que 16 se activan para cada token, distribuidos en 93 capas.

Esos dos recuentos de parámetros responden a preguntas distintas, y confundirlos es el error más común en cualquier hilo de «¿puedo ejecutar esto?».

Los parámetros activos determinan el coste de cómputo. Un token se procesa mediante aproximadamente 104B de parámetros, por lo que 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 crear un MoE.

Los parámetros totales determinan el coste de memoria. El enrutador puede seleccionar cualquier experto para cualquier token, por lo que todos los expertos deben estar almacenados en algún medio rápido antes de que llegue la primera solicitud. Es posible mantener sólo los expertos más utilizados en VRAM y cargar el resto bajo demanda: llama.cpp --moe-cache-mib conserva una caché de expertos en la GPU; los demás permanecen en la RAM del sistema y los expertos que faltan se cargan cuando el enrutador los selecciona. Sin embargo, esto no reduce el total. El resto de los expertos sigue teniendo que residir en la RAM, y un enlace PCIe mueve decenas de gigabytes por segundo frente a los terabytes por segundo de HBM, por lo que cada fallo de caché añade latencia. Transmitir los expertos desde NVMe porque el modelo tampoco cabe en la RAM es aún más lento, y la guía de K3 de Unsloth advierte de que la descarga al disco funciona mucho más despacio.

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 provienen los terabytes

El recuento de parámetros multiplicado por los bytes por peso. Esa es la fórmula completa para los pesos.

[
  {
    "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 cuantización consciente y se publicó con pesos MXFP4 y activaciones MXFP8, por lo que la fila de 4 bits es la real. Las filas superiores están ahí como referencia: en bf16, el mismo modelo requeriría 5.6 TB. MXFP4 también almacena una escala compartida de 8 bits por cada bloque de 32 pesos, lo que añade aproximadamente un 6 por ciento. Además, la configuración de Moonshot excluye del formato de 4 bits la atención, los expertos compartidos y la torre de visión, por lo que el checkpoint completo ocupa cerca de 1.56 TB según el cálculo de Unsloth, en lugar de unos limpios 1.4 TB.

Esto reduce la vía de escape habitual sin cerrarla por completo. El checkpoint publicado ya está en 4 bits, por lo que el ahorro sencillo ya se ha aplicado, pero reducir aún más el formato sigue modificando la cifra. A fecha de 27 de octubre de 2026, las cuantizaciones GGUF dinámicas de K3 que Unsloth ha medido van desde los 861.3 GB para el UD-Q2_K_XL de 2 bits hasta los 594 GB para el UD-IQ1_S de 1 bit. Unsloth publica el coste de esto: la concordancia de tokens top-1 con el modelo completo es del 90.390 por ciento en UD-Q2_K_XL, del 84.127 por ciento en el UD-IQ2_XXS de 711.1 GB y del 78.875 por ciento en UD-IQ1_S. Su repositorio en Hugging Face también contiene archivos de 1 bit más pequeños, hasta 466 GB para UD-Q1_0, sin cifras de concordancia publicadas. Se trata de una pérdida de precisión medida, e incluso el archivo más pequeño sigue siendo aproximadamente 1.6 veces mayor que la tarjeta individual más grande.

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 estas cifras como un mínimo, no como un objetivo. Solo contabilizan los pesos: no incluyen la caché KV, los búferes de activación, la fragmentación del asignador ni espacio para una segunda solicitud concurrente. La división no tiene por qué ser equitativa: el paralelismo de pipeline de vLLM divide el modelo por capas y admite divisiones desiguales, y las recetas de prefill K3 de SGLang ejecutan 8 y 16 etapas de pipeline sobre 93 capas.

Las recomendaciones publicadas se sitúan por encima de este mínimo. La guía de lanzamiento de Moonshot recomendaba un supernodo de 64 o más aceleradores. A fecha de 27 de octubre de 2026, el recetario de SGLang incluye una configuración H100 construida a partir de cuatro nodos de 8-GPU, 32 GPU y 2.560 GB de memoria agregada, frente a un mínimo de 18 tarjetas; también enumera recetas de nodo único en un nodo B300 de 8-GPU y un nodo MI350X o MI355X de 8-GPU, con 2.304 GB a 288 GB por tarjeta. Esa diferencia sobre el mínimo no es un desperdicio. Es memoria para la caché KV, activaciones y el margen operativo que permite al servidor procesar muchas solicitudes simultáneamente. La fila más favorable, 5 tarjetas de clase GB300, se redondea en la práctica exactamente a ese tipo de nodo de 8-GPU, que es la máquina más pequeña para la que alguien publica una receta de servicio multiusuario de K3.

La caché KV es la parte que suele sorprender

Los pesos representan un coste fijo. La caché KV (key value) no: crece con la longitud del contexto y también 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 se multiplica por la longitud del contexto y por la concurrencia.

Este es un ejemplo práctico, y sólo es un ejemplo: 64 capas, 8 cabezales KV, dimensión de cabezal 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. Esto representa casi la mitad de una tarjeta de 288 GB para una sola conversación, antes de cargar un solo peso.

K3 no usa 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 práctico. El archivo config.json publicado por Moonshot indica que el tamaño de ese latente es un kv_lora_rank de 512 más una clave rotatoria de 64 elementos (qk_rope_head_dim), es decir, 576 valores por token y por capa MLA. En 24 capas y con 2 bytes por valor, son 27,648 bytes, aproximadamente 27 KiB por token, o unos 27 GiB para una conversación completa de 1,048,576 tokens, además del estado KDA fijo. Considérelo una estimación, no una medición: los motores rellenan y distribuyen la caché de formas distintas, y una caché de 8 bits reduce aproximadamente el consumo a la mitad.

Para comprobar qué contiene su propio despliegue, no supervise nvidia-smi mientras aumenta --max-model-len. vLLM preasigna su grupo de caché KV. Su tamaño se calcula a partir de --gpu-memory-utilization (0.92 de forma predeterminada en la documentación actual) o de un presupuesto explícito de caché por GPU. Por eso, la memoria total de la GPU muestra el grupo preasignado y no una sola conversación. Consulte el registro de inicio. Allí vLLM informa del tamaño de la caché KV en tokens y de la concurrencia máxima para la longitud de contexto configurada.

La lógica sigue siendo válida 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: alquiler del clúster por horas

Este es el nivel que sirve K3 con su precisión de lanzamiento a muchos usuarios simultáneamente. Una máquina con suficiente RAM también puede alojar K3 con su precisión de lanzamiento mediante el formato Q8 GGUF de Unsloth, que Unsloth etiqueta como precisión completa sin pérdidas, pero esa ruta sirve a un usuario a la vez y se trata en el nivel 2. Aquí no compra el hardware. Lo alquila por las horas que lo 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 estimación, no una cotización. Las tarifas bajo demanda varían ampliamente según el proveedor y la generación de GPU; las piezas de 288 GB que requieren las recetas de nodo único cuestan más por hora que una H100, y la capacidad reservada es más económica. Tome el número real de su proveedor y rehaga la multiplicación: GPUs por horas por tarifa. El objetivo de la tabla 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 la configuración de 32 GPU H100 dimensionada para SGLang cuesta 57,600 USD.

Ambos servidores principales publican un comando de lanzamiento en la tarjeta 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 comandos básicos es lo que se ejecuta en un clúster real. Añada las flags de paralelismo que coincidan con su hardware: SGLang utiliza --tp-size para paralelismo de tensores, --pp-size para paralelismo de pipeline y --ep-size para paralelismo de expertos. El paralelismo de tensores multiplicado por el paralelismo de pipeline debe ser igual a las GPU que tiene realmente, y el paralelismo de expertos divide a los expertos dentro de ese grupo, razón por la cual la receta de 32 GPU H100 establece tanto --tp-size 32 como --ep-size 32.

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 enumera el id del modelo. Connection refused significa que el proceso aún está cargando pesos o ya ha finalizado, así que lea el registro del servidor antes de volver a intentarlo.

El fallo común en las primeras semanas fue un tiempo de ejecución (runtime) más antiguo que el modelo. K3 se lanzó con KDA y una nueva capa MoE que las versiones estables de vLLM y SGLang no incluían en el lanzamiento, y el síntoma es que el servidor se cierra durante el inicio 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 para ejecutar esas capas no está en su compilación. Eso ha cambiado desde entonces: a fecha de 27 de octubre de 2026, SGLang incluye soporte para K3 en sus versiones desde la v0.5.17, siendo la v0.5.22 la más reciente, y las notas de la versión de vLLM desde la v0.28.0 hasta la v0.32.0 incluyen trabajo sobre K3. Instale una versión actual. Algunas rutas específicas de hardware todavía nombran una imagen dedicada, por ejemplo las compilaciones NVFP4 de SGLang en Blackwell, así que consulte la receta para su tarjeta.

Una nota sobre costes que suele pasar desapercibida. El contador comienza cuando se inicia la instancia, no cuando el modelo está listo. Una descarga de 1.56 TB a 1 GB/s supone unos 26 minutos de tiempo de clúster antes del primer token. Almacene los pesos en un volumen que sobreviva a la instancia, para que la segunda ejecución comience en minutos.

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

Usted no está ejecutando K3 en este nivel. Diga esto en voz alta antes de comenzar, ya que la mayoría de los hilos sobre "ejecutar K3 localmente" terminan aquí sin admitirlo.

La regla de ajuste sigue la misma fórmula en miniatura: los parámetros multiplicados por los bytes por peso, más la caché KV, más unos 2 GB de sobrecarga en tiempo de ejecución, deben caber en su VRAM. A 4 bits, esto equivale aproximadamente a medio byte por parámetro, lo que permite combinaciones cómodas:

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

Cada combinación anterior asume una solicitud a la vez. En el momento en que una segunda persona envía un prompt, cada ranura concurrente requiere su propia caché KV. Este es el compromiso que los ajustes NUM_PARALLEL y MAX_QUEUE de Ollama gestionan por usted entre ranuras paralelas, solicitudes en cola y la VRAM restante.

Existe una forma de ejecutar K3 en una sola máquina grande, y se sitúa entre este nivel y el anterior. Unsloth documenta compilaciones GGUF de K3 en llama.cpp, desde cuantizaciones de 1 y 2 bits hasta UD-Q8_K_XL, que etiqueta como precisión completa sin pérdidas, y menciona una NVIDIA DGX Station como hardware capaz de ejecutarlas. Su regla general es que la RAM más la VRAM deben ser aproximadamente iguales al tamaño de la cuantización, desde unos 610 GB para la compilación UD-IQ1_S de 1 bit hasta unos 1.6 TB para la Q8; por debajo de eso, el modelo recurre al disco y su velocidad cae drásticamente. Una GPU es opcional: las instrucciones de compilación de Unsloth desactivan CUDA "si no tiene una GPU o simplemente desea inferencia por CPU". Las compilaciones de 1 y 2 bits son K3 altamente cuantizado, con el coste de precisión medido anteriormente. La compilación Q8 es K3 a su precisión de lanzamiento, servido a un usuario a la velocidad de la RAM. Ninguno de ellos es un modelo más pequeño.

Ollama es el camino más corto para tener un servidor funcional en un VPS con una GPU conectada:

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

ollama run descarga el modelo en el primer uso y luego le deja en un prompt. Una etiqueta que no existe devuelve Error: model "..." not found, así que copie las etiquetas de la página de la biblioteca en lugar de escribirlas de memoria. El tutorial completo, incluyendo la unidad de systemd y el acceso remoto, se encuentra en ejecutar Ollama en un VPS.

llama.cpp le 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 cada capa se cargue en la GPU. Lea el registro de carga: imprime cuántas capas se descargaron. Las capas que se desbordan hacia la RAM del sistema se ejecutan al ancho de banda de la RAM en lugar del ancho de banda HBM, por lo que la velocidad de generación cae un orden de magnitud en el momento en que el modelo deja de caber. Los compromisos entre ambas herramientas se tratan en Ollama y llama.cpp comparados.

Nivel 3: API alojada, orquestación autohospedada

[
  {
    "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 tras 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 una matriz choices. Un 401 significa que la autenticación falló: verifique que la clave sea correcta, que no haya caducado o sido deshabilitada, y que la cabecera contenga Authorization: Bearer seguido de la clave. Un error de modelo no encontrado suele significar que el id cambió, ya que los proveedores retiran ids entre puntos de control.

Ahora, el punto de equilibrio, utilizando la tarifa de alquiler supuesta anteriormente. Un nodo de 8 GPU siempre activo cuesta 14,400 USD al mes, y a 15.00 USD por millón de tokens de salida, el mismo dinero compra cerca de 960 millones de tokens de salida de la API. Para que sea rentable, debe 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, ya que las GPU inactivas se facturan a la misma tarifa que las ocupadas. Las cargas de trabajo de agentes con muchos prompts alejan aún más este límite: el contexto repetido se factura a la tarifa de acierto de caché de 0.30 USD por millón, en lugar de la tarifa de fallo de caché de 3.00 USD.

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

Qué pila de servicio pertenece a cada nivel

Los servidores de clase vLLM y SGLang pertenecen al nivel 1. Su propósito es atender muchas peticiones simultáneamente, mediante procesamiento por lotes continuo (continuous batching) y caché KV paginada, además de paralelismo de tensores y de expertos distribuido en varios nodos. Requieren aceleradores de centro de datos y una interconexión rápida entre ellos. En una sola tarjeta de consumo, su instalación es más compleja y ofrecen pocas ventajas perceptibles.

llama.cpp y Ollama pertenecen al nivel 2. Están orientados a una sola máquina, cuantización GGUF, descarga de tareas a la CPU cuando el modelo no cabe en memoria y baja concurrencia. llama.cpp carga modelos MoE enormes manteniendo los pesos de los expertos en la RAM del sistema (--cpu-moe o --n-cpu-moe) y, con --moe-cache-mib, almacenando en caché los expertos utilizados en la GPU; así es como las compilaciones K3 GGUF de Unsloth funcionan en una sola máquina. La velocidad depende entonces del ancho de banda de la RAM y de la frecuencia con la que el enrutador no encuentra datos en la caché; si el archivo es mayor que la suma de RAM y VRAM, el sistema recurre al disco. Es una configuración viable para un solo usuario. No es un servicio apto para múltiples usuarios. La comparativa completa se encuentra en Ollama frente a vLLM, y no varía según el modelo: la cuestión siempre es si se está dando servicio a muchos usuarios en hardware compartido o a un solo usuario en un equipo propio.

Los cuatro números que sobreviven a este punto de control

1. El total de parámetros multiplicado por los bytes por peso determina el requisito mínimo de memoria. Nada se ejecuta por debajo de este umbral con la precisión de lanzamiento; cuantizar por debajo de una versión de 4 bits ofrece una ganancia de hasta un 70 por ciento a costa de la precisión, no de un orden de magnitud.
2. Los parámetros activos definen la clase de rendimiento. Un modelo MoE de 2.8T con 104B activos computa como un modelo de 104B.
3. La caché KV por token, multiplicada por la longitud del contexto y la concurrencia, es el coste que sigue aumentando después de haber pagado por los pesos.
4. Los tokens por segundo por dólar son el único número que define un nivel. Todo lo anterior es un dato de entrada para este cálculo.

Aplique estos cuatro puntos a cualquier versión y obtendrá la respuesta correcta antes de abrir la guía del proveedor. La siguiente ya ha sido anunciada: Moonshot lanzó K3.1 Pro, construido sobre K3 con entrenamiento posterior adicional, en Kimi Code el 23 de octubre de 2026, y su guía de inicio rápido de la API indica que los pesos completos se publicarán antes del 4 de noviembre. Por tanto, feche cada cifra que anote. Los precios y las listas de arquitecturas compatibles cambiaron en las dos semanas posteriores al lanzamiento de K3. Las cifras de lanzamiento de esta página se publicaron en julio de 2026, y las recetas de servicio, las versiones del entorno de ejecución y los números de cuantización se revisaron el 27 de octubre de 2026.

FAQ

¿Puedo ejecutar Kimi K3 en una sola GPU?

No. Los pesos ocupan aproximadamente 1.4 TB en la precisión MXFP4 que distribuye Moonshot. Incluso la cuantización más pequeña publicada de K3, el archivo UD-Q1_0 de 466 GB de Unsloth, es aproximadamente 1.6 veces los 288 GB de los aceleradores más grandes disponibles. llama.cpp puede mantener los expertos en la RAM del sistema y almacenar en caché los activos en la GPU, pero eso requiere aproximadamente el tamaño de la cuantización en RAM más VRAM; por debajo de eso, el modelo recurre al disco y su ejecución es mucho más lenta. Las recetas de servicio más pequeñas publicadas utilizan un nodo de 8 GPU con tarjetas B300 o MI350X/MI355X, y la receta para H100 utiliza 32.

¿Cuánta VRAM necesita Kimi K3?

Comience con 1.4 TB solo para los pesos, lo cual equivale a 18 tarjetas H100 de 80 GB o 5 tarjetas de clase GB300. Luego, añada la caché KV y la memoria de activación. La guía de lanzamiento de Moonshot recomendaba 64 aceleradores o más. A fecha de 27 de octubre de 2026, el recetario de SGLang publica configuraciones de nodo único en 8 tarjetas B300 o 8 MI350X/MI355X, con un total de 2,304 GB, y una configuración de 32 GPU H100 con 2,560 GB en total, por lo que debe considerar la cifra de los pesos como un mínimo y no como un requisito.

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

El punto de control de 4 bits distribuido ya cabe en un nodo si este cuenta con ocho tarjetas de 288 GB, que es lo que utilizan las recetas de SGLang para B300 y MI355X, y en una máquina con aproximadamente 1.6 TB de RAM más VRAM mediante el formato Q8 GGUF sin pérdida de Unsloth. Reducir la precisión ayuda a máquinas más pequeñas: las compilaciones GGUF dinámicas medidas por Unsloth oscilan entre 861.3 GB a 2 bits y 594 GB a 1 bit, y su repositorio lista archivos de 1 bit de hasta 466 GB, frente a aproximadamente 1.56 TB sin pérdida. El coste en precisión ha sido medido: la concordancia top-1 con el modelo completo cae al 90.390 por ciento en UD-Q2_K_XL y al 78.875 por ciento en UD-IQ1_S. Ninguno de ellos cabe en una sola tarjeta.

¿Es más barato alquilar GPU que usar la API de Kimi K3?

Solo con un volumen alto y constante. Asumiendo un coste de 2.50 USD por hora de GPU, un nodo de 8 GPU siempre activo cuesta 14,400 USD al mes; esa misma cantidad permite obtener unos 960 millones de tokens de salida a la tarifa publicada de 15.00 USD por millón. También debe pagar las horas de inactividad, las descargas de pesos y el personal que mantiene el clúster operativo. Alquile por horas para picos de carga y compare con su propio volumen de tokens medido en lugar de hacer estimaciones.

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

Significa que la aritmética por token es la de un modelo de 104B, por lo que el rendimiento se sitúa en esa clase y no en la de 2.8T. Esto no dice nada sobre la memoria: los 2.8T de parámetros permanecen residentes, ya que el enrutador puede llamar a cualquier experto para cualquier token. Utilice el recuento de parámetros activos para predecir los tokens por segundo y el recuento total para dimensionar la VRAM.