API vs autoalojamiento de un MoE abierto: la matemática de serving de Kimi K3

Kimi K3 es un modelo de pesos abiertos con 2,8 billones de parámetros y estableció el récord de parámetros entre modelos abiertos. Tu decisión es si servirlo en tus GPUs o llamar a la API alojada de Moonshot. El autoalojamiento mantiene la inferencia de prompts en tu infraestructura en lugar de enviar los prompts a los servidores de la API alojada de Moonshot. El equilibrio está entre memoria y cómputo: divide la memoria de pesos, la memoria de contexto, el cómputo activo y el coste de prompt ajustado por caché entre los tokens, y luego compara el resultado con el precio de la API. Los términos de licencia son una verificación aparte.

Coste, aislamiento y carga deciden el equilibrio

Mide ambas opciones en tres términos: coste, aislamiento y carga operativa. El coste es el precio por token tras la caché. El aislamiento pregunta si los prompts salen de tu red. La carga operativa es la memoria, la programación y la superficie de fallo que tú asumes. Mantén los términos separados; no se mueven juntos.

Para la API, el coste es el precio de entrada y salida del proveedor. El aislamiento es más débil porque los prompts salen de tu red. La carga operativa es baja, pero heredas los incidentes del proveedor. En abril de 2026, el servicio alojado de Kimi de Moonshot tuvo un fallo de aislamiento de datos entre usuarios en el que los detalles del currículum de un usuario se mostraron a otro.

Los costes del autoalojamiento son tu clúster amortizado sobre tokens. El aislamiento es más fuerte: los prompts se quedan en tu infraestructura. La carga operativa es alta: la memoria de pesos es la primera restricción, y también asumes el enrutamiento, el batching y el estado de contexto.

Solo el coste puede favorecer a la API cuando el aislamiento favorece al autoalojamiento. El tráfico intermitente permite a la API absorber picos sin GPUs inactivas. El tráfico constante y pesado en prompts permite que la caché cambie el resultado. Compara tu coste marginal con la factura de la API antes de comprar hardware.

El coste de inferencia MoE son los parámetros activos, no los totales

El Stable LatentMoE de Kimi K3 enruta cada token de entrada a través de 16 expertos activos de un pool de 896. La carga de cómputo a nivel de token es más comparable a un modelo denso de 50 mil millones de parámetros que al modelo completo. El entrenamiento consciente de cuantización del modelo usa pesos MXFP4 y activaciones MXFP8. MXFP4 es el formato detrás de la estimación de memoria de pesos a continuación.

La ventana de contexto es otro término de memoria. Kimi Delta Attention le da a Kimi K3 una ventana de contexto de un millón de tokens al emparejar una atención de coste cuadrático estándar con una alternativa de coste lineal. Un stack de serving de contexto máximo debe mantener el estado KV, el estado de enrutamiento y los metadatos de batch para prompts largos. Las cargas de trabajo de contexto corto convierten la capacidad de contexto máximo en una especificación, no en un coste.

El batching cambia la aritmética. Un tamaño de batch más alto puede reducir el coste por token, pero aumenta la latencia de cola. La caché de prompts cambia el lado de entrada. Los prefijos repetidos reducen tu coste efectivo de prompt. Las solicitudes novedosas dejan el descuento de caché pequeño. Sigue ambas palancas en tu modelo de costes.

Ejecuta la prueba de autoalojamiento antes de comprar GPUs

Limita la prueba a las entradas siguientes. Las entradas faltantes hacen que la API sea el valor predeterminado más seguro.

• Tamaño de pesos: aproximadamente 1,4 terabytes de memoria rápida en MXFP4.
• Parámetros activos: 104 mil millones por token.
• Memoria de contexto: presupuesta para solicitudes de contexto máximo.
• Descuento por acierto de caché: multiplica el coste de prompt por el complemento de tu tasa de acierto.
• Términos de licencia: la Kimi K3 License rige el código y los pesos del modelo.

El número de pesos es la entrada decisiva. Los pesos completos estaban programados para su publicación antes del 27 de julio de 2026. No lo incluyas en el modelo de costes hasta que los pesos estén disponibles.

Las entradas deciden al ganador

Para los constructores de plataformas, el autoalojamiento gana cuando tu clúster ya está pagado, tu tasa de acierto de caché es alta y tus términos de licencia son claros. La API gana cuando necesitas capacidad ahora, no puedes mantener la memoria de pesos, o no puedes cumplir los términos de licencia. Usa la API como línea base. Pon tu precio real en la fórmula. Si el coste marginal del autoalojamiento es menor, despliégalo. Si no, mantén la API y revísalo cuando cambie tu descuento de caché o la utilización del clúster.

Ejecuta una comparación lado a lado antes de comprometerte. Envía el mismo tráfico a la API y a tu stack autoalojado. Compara el precio por token, la latencia de cola y la tasa de error. No compres GPUs para abaratar el stack autoalojado con tu mezcla real. Deja la API como desbordamiento y como respaldo mientras resuelves los términos de licencia.