TL;DR
En 2026, Kimi K3 puede autoalojarse, pero el repositorio público de pesos ocupa aproximadamente 1.56 TB y la receta oficial de vLLM comienza en 8 GPU NVIDIA GB300 o 8 GPU AMD MI355X/MI350X. Moonshot recomienda 64 aceleradores o más en una configuración de supernodo para una inferencia en producción eficiente. Para la mayoría de los equipos, una API alojada sigue siendo el punto de partida de menor riesgo.
Kimi K3: autoalojamiento vs API de un vistazo
El autoalojamiento de Kimi K3 implica descargar los pesos abiertos del modelo de Moonshot y ejecutarlos en infraestructura gestionada por tu propio equipo o cuenta en la nube. Tu organización es responsable de la capacidad de GPU, servicio del modelo, escalado, seguridad, actualizaciones, monitorización y fiabilidad.
El acceso a la API de Kimi K3 implica enviar solicitudes a un endpoint gestionado por el proveedor sin operar el clúster de GPU subyacente. El proveedor gestiona el servicio del modelo y la capacidad, mientras tu equipo paga según el uso y se centra principalmente en la integración de la aplicación.
Moonshot presentó Kimi K3 en su blog técnico oficial el 16 de julio de 2026 y publicó los pesos completos el 27 de julio. El modelo ya está disponible como un checkpoint de pesos abiertos, pero “pesos abiertos” no debe confundirse con “fácil de ejecutar localmente”. Para una visión más amplia de capacidades y benchmarks, consulta la guía de acceso a Kimi K3 de CometAPI.
La diferencia práctica no es solo el acceso al modelo. Es quién posee la infraestructura, la planificación de capacidad, las actualizaciones y el riesgo operativo.
| Factor de decisión | Kimi K3 autoalojado | Kimi K3 alojado vía API |
|---|---|---|
| Acceso al modelo | Acceso completo a los pesos publicados y a la configuración de servicio | Acceso a través de un endpoint gestionado por el proveedor |
| Huella de los pesos | Aproximadamente 1.56 TB en el repositorio público del modelo | No se requiere descarga ni almacenamiento del modelo |
| Mínimo oficial | 8x NVIDIA GB300, o 8x AMD MI355X/MI350X | No se requiere adquisición de GPU |
| Guía de producción | Multinodo con un dominio de comunicación de alto ancho de banda | El proveedor gestiona capacidad y escalado |
| Estructura de costos | Infraestructura fija más ingeniería y operaciones | Facturación variable basada en uso |
| Riesgo de utilización | La capacidad ociosa sigue generando costo | El gasto generalmente sigue el uso real |
| Responsabilidad de upgrade | Tu equipo valida runtimes, pesos y cambios en el servicio | El proveedor gestiona las actualizaciones del stack de servicio |
| Control de la ruta de datos | Mayor control sobre despliegue, logging y retención | Depende de la arquitectura y términos del proveedor |
| Revisión de licencia | La Licencia Kimi K3 rige directamente el uso de los pesos | Los términos del proveedor rigen el acceso alojado |
| Mejor ajuste | Cargas sostenidas, experiencia en inferencia distribuida, requisitos estrictos de control | Evaluación, demanda variable, despliegue más rápido, personal de infraestructura limitado |
La pregunta central no es si el autoalojamiento es técnicamente posible. Es si tu equipo puede mantener la infraestructura necesaria lo suficientemente ocupada—y operarla con suficiente fiabilidad—como para superar el acceso alojado en costo total por tarea aceptada.
¿Se puede autoalojar Kimi K3?
Sí. Moonshot ha publicado los pesos completos en el repositorio oficial de Kimi K3 bajo la Licencia Kimi K3. Las rutas públicas de despliegue incluyen vLLM, SGLang y TokenSpeed.
Sin embargo, Kimi K3 no es un modelo de clase workstation. Es un modelo Mixture-of-Experts de 2.8 billones de parámetros con 104 mil millones de parámetros activados por token, 896 expertos enrutados, capacidades multimodales nativas, pesos MXFP4, activaciones MXFP8 y una ventana de contexto de hasta 1,048,576 tokens.
La cifra de 104B de parámetros activados describe la cantidad de capacidad del modelo utilizada durante cada paso de token. No significa que solo sea necesario almacenar 104B parámetros. El enrutador puede seleccionar diferentes expertos durante la generación, por lo que el conjunto completo de expertos sigue formando parte del modelo desplegado.
Kimi K3: autoalojamiento vs API: requisitos de infraestructura
Autoalojar Kimi K3 requiere un entorno grande de GPU distribuidas, mientras que el acceso vía API elimina la necesidad de operar el clúster de servicio del modelo subyacente. En 2026, la base oficial para autoalojamiento comienza en ocho GPU NVIDIA GB300 o AMD MI355X/MI350X, mientras que los usuarios de API solo necesitan infraestructura de aplicación estándar.
La diferencia no es simplemente quién posee las GPU. El autoalojamiento también hace que tu equipo sea responsable del almacenamiento del modelo, la red multinodo, la planificación de capacidad, el despliegue, el escalado, la monitorización, las actualizaciones y la recuperación ante fallos. Con una API alojada, la mayor parte de esa responsabilidad pasa al proveedor.
Requisitos de hardware para el autoalojamiento
La receta oficial de vLLM enumera los siguientes prerrequisitos para ejecutar el checkpoint completo de Kimi K3:
- NVIDIA: al menos 8x GPU GB300
- AMD ROCm: al menos 8x GPU MI355X o MI350X
- Tráfico de producción: se recomienda despliegue multinodo
- vLLM: versión 0.27.0 o posterior, usando la imagen de Kimi K3 y los perfiles de despliegue documentados
Estos requisitos representan un piso de servicio documentado, no una garantía de que un sistema de ocho GPU satisfaga cualquier carga de trabajo en producción.
La documentación de lanzamiento de Moonshot va más allá. Para mayor eficiencia de inferencia, recomienda desplegar Kimi K3 en configuraciones de supernodo con 64 aceleradores o más. Esa recomendación es especialmente relevante para equipos que apunten a alta concurrencia, cargas de trabajo de contexto largo o latencias previsibles bajo carga.
El cuello de botella no es solo la memoria de GPU agregada. Kimi K3 activa 16 de 896 expertos enrutados por token, por lo que los despliegues con paralelismo entre expertos generan un tráfico todo a todo sustancial entre aceleradores.
La receta oficial de vLLM recomienda backends de comunicación como deepep_v2 para entornos RDMA y flashinfer_nvlink_one_sided para comunicación cruzada entre nodos basada en NVLink. En consecuencia, ocho GPU conectadas a través de una red más lenta no son operativamente equivalentes a ocho GPU dentro de un sistema estrechamente interconectado y de alto ancho de banda.
¿Cuánto almacenamiento y memoria en tiempo de ejecución necesita el autoalojamiento?
El checkpoint público de Kimi K3 es de aproximadamente 1.56 TB, según el repositorio oficial en Hugging Face.
Un cálculo teórico de límite inferior para 2.8 billones de parámetros almacenados a cuatro bits por parámetro es:
2.8 trillion parameters × 4 bits ÷ 8
= 1.4 trillion bytes
= about 1.4 TB, or 1.27 TiB
¿Por qué es más difícil servir Kimi K3 que un modelo estándar?
Kimi K3 es más difícil de servir porque su arquitectura MoE distribuida combina tráfico entre expertos todo a todo, planificación de caché para contextos largos, historial de razonamiento específico del modelo y validación de llamadas a herramientas. Los equipos deben evaluar el rendimiento del interconector, el paralelismo, el comportamiento de prefill y decode, la concurrencia y el manejo de reintentos en lugar de tratarlo como un endpoint de modelo convencional de un solo nodo.
La receta oficial de vLLM destaca varias consideraciones de producción:
- El tráfico entre nodos requiere un backend todo a todo adecuado y una malla de comunicación de alto ancho de banda.
- El backend MoE cambia con la estrategia de paralelismo y la topología de hardware.
- El paralelismo tensorial, el paralelismo entre expertos y los perfiles desagregados de prefill/decode documentados deben compararse con la carga de trabajo real.
max-model-len, la concurrencia y la utilización de memoria requieren ajuste explícito en lugar de valores por defecto.- K3 puede emitir ocasionalmente un formato de llamada a herramienta que su propio analizador no espera; la receta recomienda validación de esquema y manejo de reintentos.
¿Es gratuito usar el contexto de 1M tokens?
No. Moonshot no aplica un nivel por token más alto únicamente porque una solicitud use un contexto más largo, pero los prompts largos siguen consumiendo tokens de entrada y aumentan el trabajo de prefill, la demanda de KV cache, la latencia y la presión de concurrencia. Configura max-model-len en torno a la carga de trabajo que realmente piensas atender en lugar de habilitar el máximo por defecto.
La compatibilidad de la aplicación también importa. Según el quickstart de la API de Kimi K3 de Moonshot, K3 siempre razona y admite valores de reasoning_effort de low, high y max, con max como predeterminado. Esto puede aumentar el volumen de tokens generados, pero la sobrecarga varía según la tarea y el ajuste de esfuerzo. Mide el razonamiento y los tokens de salida en tu propio conjunto de evaluación en lugar de asumir un multiplicador fijo. Para conversaciones de varios turnos y llamadas a herramientas, devuelve el mensaje completo del asistente, incluyendo reasoning_content y tool_calls, en lugar de conservar solo la respuesta visible.
Un endpoint alojado elimina la mayor parte del trabajo a nivel de clúster, pero no elimina la validación a nivel de aplicación, la lógica de reintentos, la medición de latencia ni el manejo del estado en múltiples turnos.
¿Cuánto cuesta la API de Kimi K3?
A julio de 2026, Moonshot cobra $0.30 por 1M tokens de entrada con acierto de caché, $3.00 por 1M tokens de entrada con fallo de caché y $15.00 por 1M tokens de salida. El costo efectivo depende en gran medida de la reutilización del caché de prefijo y de la longitud de la salida, por lo que los equipos deben medir el uso facturado con solicitudes que reflejen la producción en lugar de comparar solo la tarifa principal de entrada.
La página oficial de precios de Kimi K3 de Moonshot muestra:
| Uso de la API | Precio oficial por 1M tokens |
|---|---|
| Entrada con acierto de caché | $0.30 |
| Entrada con fallo de caché | $3.00 |
| Salida | $15.00 |
La fórmula directa del costo de la solicitud es:
Costo de la API =
(tokens de entrada con acierto de caché ÷ 1M × $0.30)
- (tokens de entrada con fallo de caché ÷ 1M × $3.00)
- (tokens de salida ÷ 1M × $15.00)
Por ejemplo, una solicitud con 300,000 tokens de entrada y 30,000 tokens de salida cuesta:
- $1.35 si toda la entrada se factura como fallo de caché
- $0.54 si toda la entrada recibe el precio de acierto de caché
Las cargas de trabajo reales suelen situarse entre esos dos casos. El rendimiento de la caché depende de cuán consistentemente la aplicación reutilice un prefijo sin cambios y de cómo el proveedor implemente el caché.
Los precios alojados también varían según el proveedor. A julio de 2026, CometAPI lista Kimi K3 a $2.40 por 1M tokens de entrada y $12.00 por 1M tokens de salida—un 20% por debajo de las tarifas estándar de Moonshot de $3.00 para la entrada y $15.00 para la salida cuando hay fallo de caché. Sin embargo, esto no es un ahorro universal del 20%. Moonshot cobra solo $0.30 por 1M tokens de entrada con acierto de caché, por lo que las cargas con una alta tasa de aciertos en caché pueden costar menos a través de la API oficial.
Usa la página en vivo del modelo de CometAPI como fuente de precios actual, y consulta la guía de precios de la API de Kimi K3 para ejemplos de costos. Compara ambas rutas usando uso realmente facturado del mismo conjunto de evaluación, incluyendo aciertos de caché, salida de razonamiento, reintentos y tasa de tareas aceptadas.
¿Cuánto cuesta el autoalojamiento de Kimi K3?
Kimi K3 no tiene un precio universal de autoalojamiento. El costo completo depende del tamaño del clúster, condiciones del contrato, utilización productiva, red, almacenamiento, ingeniería y objetivos de fiabilidad. Un escenario de planificación con ocho GPU ya puede superar los $58,000 al mes solo en infraestructura, mientras que la topología de producción recomendada por Moonshot de 64+ aceleradores requiere un modelo de costos aparte, mucho mayor.
Usa un modelo mensual completo:
Costo mensual autoalojado =
costo del acelerador o clúster
- ingeniería de plataforma
- operaciones de inferencia
- red y almacenamiento
- observabilidad y seguridad
- redundancia y margen de inactividad
Escenarios ilustrativos de infraestructura con ocho GPU
La siguiente tabla usa 730 horas por mes y tres tarifas hipotéticas para un clúster siempre disponible de tamaño mínimo. Estas cifras son insumos de planificación, no cotizaciones. Tampoco representan la recomendación de producción de Moonshot de 64+ aceleradores.
| Tarifa de clúster asumida | Costo mensual de infraestructura | Solicitudes equivalentes al gasto a $1.35 cada una | Solicitudes equivalentes al gasto a $0.54 cada una |
|---|---|---|---|
| $80/hora | $58,400 | 43,300 | 108,100 |
| $120/hora | $87,600 | 64,900 | 162,200 |
| $160/hora | $116,800 | 86,500 | 216,300 |
Sumar ingeniería, monitorización, redundancia, red y capacidad ociosa eleva el umbral del autoalojamiento. Una topología de producción mayor lo eleva aún más.
La utilización importa, pero no hay un umbral universal
No existe un porcentaje universal de utilización de GPU a partir del cual el autoalojamiento sea más barato. El nivel requerido depende del rendimiento medido, el costo del hardware, los objetivos de latencia, la redundancia y de si el hardware es un gasto nuevo o ya está en propiedad.
En su lugar, sigue la utilización productiva:
Utilización productiva =
horas de clúster dedicadas a carga aceptada
÷ horas totales de clúster aprovisionadas
Un número alto de utilización no basta si las solicitudes incumplen objetivos de latencia o calidad. Del mismo modo, un número menor puede ser aceptable cuando el hardware ya está comprometido con otras cargas. Usa la utilización como insumo del modelo de TCO, no como regla decisoria independiente.
El denominador más útil no son las solicitudes brutas. Es el trabajo equivalente aceptado:
Punto de equilibrio de tareas aceptadas =
costo mensual total autoalojado
÷ costo alojado por tarea equivalente aceptada
Incluye fallos, reintentos, violaciones de latencia, revisión humana y salidas degradadas en ambos lados. Dos endpoints que usan los mismos pesos no son económicamente equivalentes si uno incumple el objetivo de fiabilidad o calidad de la aplicación.
¿Qué permite la Licencia Kimi K3?
La Licencia Kimi K3 personalizada concede amplios derechos para usar, copiar, modificar, afinar, desplegar, distribuir, sublicenciar y vender el software y los pesos del modelo. También incluye condiciones relevantes para grandes empresas de Modelo como Servicio y productos comerciales de alto volumen.
| Pregunta sobre la licencia | Condición publicada |
|---|---|
| ¿Puede una empresa usar y modificar los pesos? | Sí, sujeto a las condiciones de la licencia y la ley aplicable |
| ¿Qué es “Model as a Service”? | Acceso de terceros a inferencia o fine-tuning que otorga control significativo sobre entradas, parámetros o datos de entrenamiento |
| ¿Qué queda excluido de esa definición? | Funciones integradas del producto y la mera retransmisión a modelos alojados por otros |
| ¿Qué activa el requisito de acuerdo MaaS? | Más de $20 millones de ingresos agregados en cualquier período continuo de 12 meses para la licenciataria y filiales que operen un negocio MaaS |
| ¿Qué sucede por encima de ese umbral? | Se requiere un acuerdo separado con Moonshot antes del uso comercial del software o derivados |
| ¿Cuándo se requiere atribución visible? | Un producto o servicio comercial con más de 100 millones de usuarios activos mensuales o más de $20 millones de ingresos mensuales debe mostrar de forma destacada “Kimi K3” |
| ¿Qué usos están exentos de las Secciones 2 y 3? | Uso interno y acceso a través de productos oficiales de Moonshot o socios certificados de inferencia |
Para la mayoría de los despliegues internos y aplicaciones comerciales ordinarias, la licencia no prohíbe el uso por defecto. Los equipos que vendan acceso directo al modelo, operen una API del modelo o se acerquen a los umbrales indicados deberían pedir a su asesoría que revise el diseño exacto del producto y la estructura corporativa.
“Pesos abiertos” es una descripción más precisa que “código abierto completo” porque el uso se rige por esta licencia personalizada en lugar de una licencia de software permisiva estándar.
API vs Kimi K3 autoalojado: ¿cuál deberías elegir?
Para la mayoría de los equipos en 2026, el acceso vía API alojada es el mejor primer paso porque la demanda, el comportamiento del caché y el costo por tarea aceptada siguen siendo inciertos. Elige el autoalojamiento solo cuando la utilización sostenida, los requisitos de control de datos o la personalización del runtime se hayan medido frente al costo completo de un despliegue fiable equivalente en producción.
Elige una API alojada cuando:
- El tráfico es nuevo, variable o difícil de pronosticar.
- Necesitas acceso a producción sin un ciclo de adquisición de GPU.
- Tu equipo no opera inferencia MoE distribuida.
- El uso está muy por debajo de tu umbral de equilibrio calculado.
- El escalado gestionado, las actualizaciones y la capacidad valen más que el control del runtime.
- El manejo de datos y los términos del servicio del proveedor satisfacen tus requisitos.
Elige autoalojamiento cuando:
- La demanda es lo suficientemente sostenida y predecible como para mantener el clúster muy utilizado.
- Tu organización ya cuenta con infraestructura de GPU distribuida e ingenieros de inferencia.
- Una ruta de datos controlada, un entorno dedicado o una política de retención personalizada es un requisito estricto.
- Necesitas control directo sobre versiones del modelo, planificación, ajustes de runtime o pesos afinados.
- El gasto alojado medido se acerca al costo interno completo de un despliegue fiable equivalente.
- La revisión legal confirma que el uso previsto encaja en la Licencia Kimi K3.
Considera un despliegue híbrido cuando:
- La demanda base es predecible pero el tráfico tiene grandes picos.
- La capacidad autoalojada puede servir cargas estables mientras una API absorbe los excedentes.
- Necesitas un respaldo gestionado para mantenimiento o fallos regionales.
- Los prompts, esquemas de herramientas, pruebas de aceptación y comportamiento del modelo siguen siendo portables en ambas rutas.
Una estrategia híbrida añade complejidad de enrutamiento y observabilidad, así que debería resolver un problema medido de capacidad o resiliencia en lugar de existir solo como preferencia arquitectónica.
¿Cómo deberías probar el punto de equilibrio entre API y autoalojamiento?
Ejecuta el mismo conjunto de evaluación con forma de producción por rutas alojadas y autogestionadas, luego compara el costo por tarea aceptada—no solo el precio por token ni el alquiler de GPU. Una prueba creíble debería medir aciertos de caché, tokens de salida, latencia, reintentos, calidad, concurrencia, tiempo de ingeniería, capacidad ociosa y recuperación ante fallos durante al menos un período operativo representativo.
- Crea un conjunto de evaluación representativo. Incluye de 30 a 50 tareas que cubran la mezcla real de solicitudes de código, contexto largo, visión y llamadas a herramientas.
- Mide el uso alojado durante al menos una semana. Registra tokens de entrada, tokens con acierto de caché, tokens de salida, latencia, reintentos, errores y tasa de tareas aceptadas.
- Prueba la topología autoalojada propuesta. Usa los límites de contexto, concurrencia, paralelismo y ajustes de fiabilidad previstos—no una demostración de un solo usuario.
- Calcula el costo mensual completo. Incluye tiempo de clúster, ingeniería, observabilidad, redundancia, almacenamiento, red, seguridad y margen de inactividad.
- Compara la economía por tarea aceptada. Confirma que calidad, latencia y fiabilidad sean equivalentes antes de comparar costos.
- Ejecuta escenarios de fallo. Prueba pérdida de nodos, rollback de despliegue, crecimiento de la cola, picos de contexto largo y llamadas a herramientas malformadas.
- Aprueba el autoalojamiento solo cuando el caso operativo sea medible. El control estratégico puede justificar un costo mayor, pero el trade-off debe ser explícito.
Como línea base alojada, el inicio rápido de CometAPI ofrece una ruta compatible con OpenAI. Mantén prompts, herramientas y criterios de aceptación sin cambios al probar otro proveedor o un endpoint autoalojado.
Preguntas frecuentes
¿Puede Kimi K3 ejecutarse en una sola GPU?
No bajo la guía oficial de servicio del modelo completo. La receta de vLLM comienza en ocho GPU NVIDIA GB300 o ocho GPU AMD MI355X/MI350X y recomienda infraestructura multinodo para tráfico real de producción. La topología final depende de la longitud de contexto, la concurrencia, la latencia y los objetivos de redundancia.
¿Cuánto almacenamiento requiere el autoalojamiento de Kimi K3?
El repositorio público en Hugging Face es de aproximadamente 1.56 TB. Los requisitos de memoria en tiempo de ejecución son mayores porque el servicio también necesita metadatos de cuantización, activaciones, KV cache, buffers de comunicación y margen para la concurrencia.
¿Kimi K3 es de código abierto?
Kimi K3 se describe mejor como de pesos abiertos bajo la Licencia Kimi K3 personalizada. Los pesos están disponibles públicamente y pueden modificarse y desplegarse, pero los grandes operadores MaaS y los productos comerciales muy grandes enfrentan condiciones adicionales.
¿El autoalojamiento de Kimi K3 es más barato que el acceso por API?
Puede serlo con utilización alta y sostenida, pero no hay un punto de equilibrio universal. Compara el costo mensual completo de un despliegue fiable equivalente con el costo alojado por tarea aceptada, incluyendo comportamiento del caché, reintentos, latencia y capacidad ociosa.
¿Qué motores de inferencia son compatibles con Kimi K3?
Moonshot recomienda actualmente vLLM, SGLang y TokenSpeed. La receta de vLLM proporciona la base de hardware público más clara, aunque cada motor sigue necesitando validación específica de la carga de trabajo.
Prueba la ruta alojada antes de comprar infraestructura
Los pesos abiertos de Kimi K3 crean una opción real de autoalojamiento, pero el tamaño del checkpoint y los requisitos de servicio distribuido lo convierten en un proyecto de infraestructura más que en un despliegue rutinario de modelo.
Comienza con un conjunto de evaluación fijo. Mide uso de tokens, comportamiento del caché, latencia, reintentos y calidad de tareas aceptadas a través de un endpoint alojado. Luego compara esos resultados con una topología autoalojada sometida a carga usando el costo mensual completo—no solo la factura de GPU.
CometAPI proporciona una ruta compatible con OpenAI para establecer esa línea base. Usa la guía “Cómo usar la API de Kimi K3” para detalles de implementación, el inicio rápido de CometAPI para pasos de migración, y la página del modelo Kimi K3 y la página de precios en vivo para disponibilidad y tarifas actuales.