Baseten tiene soporte desde el día cero para Kimi K3 en nuestras Model APIs. Queremos agradecer a Moonshot AI por compartir los pesos de Kimi K3 con nosotros para acceso anticipado, así como a los equipos de Inferact y RadixArk por su colaboración durante todo el proceso de desarrollo.
Kimi K3 ya está disponible en las Model APIs de Baseten con entrada de visión y una ventana de contexto completa de 1 millón de tokens.
Kimi K3 es un nuevo modelo frontera abierto. Con 2,8 billones de parámetros, es mucho más grande que cualquier modelo abierto anterior, lo que introduce varios desafíos para construir una API de inferencia de alto rendimiento. Nuevas técnicas arquitectónicas permiten que Kimi K3 supere el umbral de los billones de parámetros de los modelos frontera abiertos anteriores:
- Kimi Delta Attention (KDA) y Attention Residuals (AttnRes) como columna vertebral escalable para la arquitectura de Kimi.
- Expertos extremadamente dispersos, con solo 16 de 896 expertos activos a la vez, organizados mediante Stable LatentMoE.
- Un nuevo codificador de visión para procesar entradas de imágenes y mapear la información visual al espacio latente.
Este artículo describe el trabajo técnico necesario para ejecutar la novedosa arquitectura del modelo Kimi K3 y sus enormes pesos a escala para el día del lanzamiento.
Hito 1: Generar un token
Después de recibir acceso anticipado a los pesos de Kimi K3 por parte del equipo de Moonshot AI, nuestra primera prioridad fue simplemente poner el modelo en funcionamiento.
Generar nuestros primeros tokens de Kimi K3 requirió:
- Aprovisionar hardware: Dado el tamaño de Kimi K3, decidimos ejecutar el modelo en sistemas NVIDIA GB300 NVL72.
- Cargar pesos: En MXFP4, los pesos de Kimi K3 superan 1,4 TB de datos.
- Poner en marcha un motor de inferencia: Trabajamos con los equipos detrás de vLLM y SGLang para ejecutar versiones previas al lanzamiento de los motores de inferencia para Kimi K3.
A menudo, al construir APIs desde el día cero, un paso temprano es convertir los pesos a NVFP4 para mejorar el rendimiento y la compatibilidad con NVIDIA Blackwell y nuestra pila de inferencia. Sin embargo, Kimi K3 utiliza pesos nativos MXFP4 con activaciones MXFP8, y pudimos usar estos pesos directamente.
Con los pesos en mano, trabajamos estrechamente con Inferact en vLLM y con RadixArk en SGLang. Antes de ejecutar Kimi K3 en la pila de inferencia de Baseten, necesitábamos establecer una base de referencia en colaboración con los motores de inferencia de código abierto líderes.
Agregar soporte para un modelo a un motor de inferencia no es trivial. Requiere implementar código de modelado central, kernels optimizados para nuevas arquitecturas como KDA, y construir compatibilidad de frontend para Kimi K3 en todo, desde la tokenización hasta la llamada a herramientas.
La imagen de acceso anticipado de vLLM para GPUs NVIDIA Blackwell nos ayudó a establecer una integridad de características básica, pasar evaluaciones iniciales y fijar un objetivo de rendimiento de referencia. Este trabajo para adaptar características arquitectónicas de Kimi K3 como KDA, AttnRes y Stable LatentMoE formó una base sólida sobre la cual construir. También realizamos una validación exhaustiva del motor de inferencia vLLM para Kimi K3 e hicimos contribuciones de vuelta al motor de código abierto basadas en nuestro trabajo.
La imagen de acceso anticipado de SGLang proporcionó una referencia para un servicio rápido y fiable de Kimi K3. SGLang tiene un historial de fuerte soporte para modelos de lenguaje con visión, y Kimi K3 no es una excepción. Con el equipo de RadixArk, nos centramos en la compatibilidad del frontend y la optimización de kernels, y nuestro equipo de ingeniería contribuyó con correcciones para errores de frontend relacionados con el manejo de llamadas a herramientas y salidas estructuradas para respaldar la preparación para el lanzamiento.
Gracias a los equipos de Inferact y RadixArk por construir codo a codo con nosotros durante el período de vista previa. Este trabajo proporcionó tanto una base esencial para nuestra API de Kimi K3 como una oportunidad para contribuir de vuelta a la comunidad de código abierto.
Hito 2: Validar el motor de inferencia
Kimi K3 es el modelo abierto más inteligente jamás creado. Es esencial ofrecer realmente esa inteligencia durante la inferencia.
Los benchmarks de Kimi K3 muestran un rendimiento sólido en tareas agentivas, que dependen de llamadas a herramientas precisas y salidas de modelo de alta calidad.
La validación de calidad puede ocurrir en diferentes niveles de rigor. Las comprobaciones de cordura simples, como llamar al modelo con un prompt conocido o ejecutar un benchmark ligero como gsm8k o BFCL y verificar si los resultados están dentro del margen de error, son puntos de control útiles durante el proceso de desarrollo para asegurarse de que las cosas no se descarrilen. Pero lanzar una API pública requiere un benchmarking más riguroso.
El equipo de Moonshot AI opera Kimi Vendor Verifier, que ayuda a los proveedores de inferencia a garantizar un servicio preciso y de alta fidelidad de los pesos del modelo. Pasar Kimi Vendor Verifier fue un hito temprano esencial en el desarrollo de nuestra API, y fue una herramienta extremadamente útil durante todo el proceso de desarrollo.
Hay muchas oportunidades de cometer errores al servir modelos. Si bien la narrativa popular es que la cuantización es la raíz de todos los problemas de calidad, en la práctica eso no es cierto. La mayoría de los problemas de calidad, especialmente con la llamada a herramientas y otros comportamientos estructurados del modelo, provienen del frontend del servidor de inferencia.
El frontend se sitúa delante del motor de inferencia y procesa las entradas y salidas.
El frontend es código determinista que se ejecuta en la CPU delante del bucle de inferencia. Es responsable de aceptar entradas y devolver salidas. El frontend debe:
- Operar y validar la API
- Tokenizar prompts y destokenizar salidas
- Renderizar la plantilla de chat
- Analizar razonamiento y llamadas a herramientas
- Formatear la salida a ChatCompletions, mensajes u otro estándar
Estas tareas son sutilmente diferentes de un modelo a otro, y es muy común introducir errores y degradación del rendimiento al construir rápidamente para soporte desde el día cero. Comprobaciones robustas como Kimi Vendor Verifier evalúan el rendimiento en modos de fallo comunes, como la llamada a herramientas, para garantizar que el modelo se sirva con un alto grado de fidelidad tanto en el bucle de inferencia como en la superficie de la API.
A medida que continuamos desarrollando la API, utilizamos Kimi Vendor Verifier en hitos posteriores para asegurarnos de que las optimizaciones de rendimiento no hubieran introducido errores que degradaran la precisión.
Hito 3: Encontrar la configuración adecuada
Los motores de inferencia ofrecen una amplia gama de opciones de configuración para ajustar el rendimiento a diferentes modelos, hardware, formas de tráfico y compensaciones entre latencia y rendimiento. Estas opciones, y las interacciones entre ellas, son complejas.
Para descubrir la configuración adecuada, realizamos un barrido de varias opciones como configuraciones de Tensor Parallelism (TP) y Expert Parallelism (EP), activación de Attention Data Parallelism (ADP), tamaño de lote, longitudes de borrador del decodificador especulativo, intervalos de almacenamiento en caché de capas lineales, parámetros de enrutamiento y configuraciones del motor de inferencia.
Tensor Parallelism y Expert Parallelism dividen modelos grandes en múltiples GPUs.
Ejecutar Kimi K3 requiere ocho GPUs NVIDIA GB300 para que los enormes pesos del modelo quepan en la VRAM. Sin embargo, a diferencia de muchas otras GPUs NVIDIA que vienen en nodos de ocho, las GB300 vienen en nodos de cuatro. Aunque esto podría parecer inicialmente que limita las estrategias de paralelismo posibles – Tensor Parallelism no es tradicionalmente posible entre nodos ya que las interconexiones lentas convierten las costosas operaciones all-reduce en un cuello de botella para la inferencia – el sistema GB300 NVL72 tiene una interconexión suficientemente rápida entre nodos como para que podamos ejecutar inferencia con Tensor Parallelism y Expert Parallelism a través de nodos.
Estas decisiones de configuración dependen de la elección del motor de inferencia. Los ingenieros trabajaron en paralelo para configurar vLLM, SGLang y nuestro propio motor interno, compartiendo hallazgos y aplicando aprendizajes a nuestro motor de inferencia interno, al mismo tiempo que contribuían con PRs a los motores de código abierto.
Hito 4: Optimizar el rendimiento
Una vez que un modelo está en funcionamiento con una configuración optimizada, existe una gran cantidad de técnicas de ingeniería de inferencia que pueden mejorar materialmente la latencia, el rendimiento (throughput) o una combinación de ambos. Para las APIs de modelos, generalmente analizamos:
- Especulación: Usar un modelo borrador pequeño para predecir múltiples tokens, luego validarlos como parte del pase hacia adelante. Esta optimización sin pérdidas mejora el TPS por usuario en decodificación.
- Desagregación: Mover la precarga (prefill) y la decodificación a trabajadores separados. Esto evita la competencia por recursos, permite una configuración más específica y hace que la relación entre cómputo de precarga y decodificación sea ajustable para coincidir con el tráfico.
- Caché: Asignar memoria para guardar los estados de KV cache y KDA entre solicitudes, permitiendo que solicitudes posteriores con prefijos compartidos en secuencias de entrada omitan toda o parte de la precarga. Esto mejora el TTFT y el rendimiento general del sistema.
Tener el modelo en funcionamiento a partir de hitos anteriores es un requisito previo para este trabajo. Por ejemplo, entrenar un modelo especulador usando un método como DSpark, DFlash o EAGLE-3 requiere generar estados ocultos del modelo objetivo (Kimi K3) usando un conjunto de prompts que se asemejen al uso real esperado. Para hacer esto, necesitas una instancia del modelo con un rendimiento razonablemente alto, activa y ejecutando inferencia.
Una optimización de rendimiento novedosa estuvo en el tokenizador. Durante años, los ingenieros de inferencia han podido ignorar el tiempo de tokenización por considerarlo insignificante. Para un modelo como Kimi K3 con secuencias de entrada largas y altas tasas de reutilización de KV cache, esto realmente cambia, y la tokenización puede volverse significativa para el tiempo de precarga, ya que la tokenización debe ocurrir independientemente de si la secuencia de entrada es un acierto de caché.
Construimos un tokenizador personalizado que es hasta 18 veces más rápido que tiktoken para secuencias de entrada largas y lo implementamos junto con nuestra API de Kimi K3.
Basetenkenizer es hasta 18 veces más rápido que Tiktoken para secuencias de entrada largas.
Todavía queda más trabajo por hacer en el rendimiento. Con cada modelo que lanzamos, continuamos invirtiendo en optimizaciones de latencia y rendimiento en las semanas posteriores al lanzamiento. Con el tamaño sin precedentes de Kimi K3, hay una enorme superficie para una mejora adicional del rendimiento en cada técnica principal de ingeniería de inferencia y en cada capa de la pila de inferencia.
Hito 5: Desplegar a escala
Hay una enorme emoción en toda la industria por Kimi K3. Esto será acompañado por una gran ola de demanda de la API en el lanzamiento. En consecuencia, el rendimiento de todo el sistema, no solo la latencia por usuario, es una prioridad principal.
En un sistema GB300 NVL72, un nodo son 4 GPUs individuales, lo que significa que hay 18 nodos. Como instancia, Kimi K3 ocupa 2 nodos (8 GPUs); cada rack NVL72 puede alojar 9 réplicas del modelo. Cada clúster tiene múltiples racks GB300 NVL72, y servimos el modelo en múltiples regiones y proveedores de nube para acceder a más capacidad.
Cada sistema NVL72 puede ejecutar nueve réplicas de Kimi K3.
El factor más determinante para el rendimiento de una réplica dada es la tasa de aciertos de la caché de prefijo. Dada la escala del despliegue, esto convierte al enrutamiento consciente de KV en el principal desafío a resolver en la infraestructura. Cuando un usuario envía una secuencia de tokens de entrada que ya hemos visto antes, necesitamos enrutar esa solicitud a una réplica que pueda acceder a la KV cache guardada para omitir la precarga.
Nuestro sistema de enrutamiento consciente de KV, construido con el kit de herramientas NVIDIA Dynamo, asegura que podamos enrutar el tráfico a réplicas con cachés calientes para consultas repetidas. Dado que la codificación y los agentes de múltiples turnos son casos de uso comunes para Kimi K3, este sistema de enrutamiento consciente de caché es crítico para ahorrar dinero a los usuarios y mantener un alto rendimiento total del sistema.
Construye con Kimi K3 en Baseten
Estamos emocionados de ofrecer acceso desde el día cero a través de las Model APIs, y esperamos continuar optimizando nuestra implementación de este modelo para alcanzar los más altos estándares de rendimiento y fiabilidad.
El anuncio de Kimi K3 del equipo de Moonshot AI incluye una serie de pruebas interesantes para el modelo, incluyendo tareas de codificación como optimización de kernels y desarrollo de juegos con visión en el bucle, tareas de investigación y tareas agentivas como edición de video y trabajo de conocimiento. El martes 28 de julio a las 11 a.m. (hora del Pacífico), estaré organizando una sesión informativa ejecutiva sobre casos de uso de Kimi K3 junto con Joey Zwicker, quien lidera toda la ingeniería desplegada en el terreno en Baseten.
Kimi K3 ya está disponible en las Model APIs de Baseten. Bienvenido a la nueva frontera en inteligencia de pesos abiertos.
Agradezco a los muchos ingenieros detrás de nuestra API de Kimi K3 por permitirme documentar su arduo trabajo en este artículo, incluyendo a demasiadas personas para nombrar en los equipos de rendimiento de modelos, infraestructura, capacidad, entrenamiento, producto e ingeniería desplegada en el terreno. También, gracias a los equipos de Moonshot AI, Inferact y RadixArk por su colaboración y apoyo.
