Baseten tiene soporte desde el día cero para Kimi K3 en nuestras API de modelos. Queremos agradecer a Moonshot AI por compartir los pesos de Kimi K3 con nosotros para acceso temprano, 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 API de modelos 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 a Kimi K3 escalar más allá del umbral de billones de parámetros de los modelos frontera abiertos anteriores:
- Atención Delta Kimi (KDA) y Residuales de Atención (AttnRes) como una columna vertebral escalable para la arquitectura 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 información visual en el 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, justo a tiempo para el día de lanzamiento.
Hito 1: Generar un token
Después de recibir acceso temprano 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ó:
- Aprovisionamiento de hardware: Dado el tamaño de Kimi K3, decidimos ejecutar el modelo en sistemas NVIDIA GB300 NVL72.
- Carga de pesos: En MXFP4, los pesos de Kimi K3 superan los 1,4 TB de datos.
- Puesta en marcha de 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 API desde el día cero, un paso temprano es portar los pesos a NVFP4 para mejorar el rendimiento y la compatibilidad con NVIDIA Blackwell y nuestra pila de inferencia. Sin embargo, Kimi K3 usa pesos MXFP4 nativos 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 nuestra pila de inferencia, necesitábamos establecer una línea base 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 frontend para Kimi K3 en todo, desde la tokenización hasta la llamada de herramientas.
La imagen de acceso temprano de vLLM para GPU NVIDIA Blackwell nos ayudó a establecer una funcionalidad básica completa, pasar evaluaciones iniciales y establecer un objetivo de rendimiento de referencia. Este trabajo para adaptar las características arquitectónicas de Kimi K3, como KDA, AttnRes y Stable LatentMoE, formó una base sólida sobre la que construir. También realizamos una validación exhaustiva del motor de inferencia vLLM para Kimi K3, e hicimos contribuciones al motor de código abierto basadas en nuestro trabajo.
La imagen de acceso temprano de SGLang proporcionó una referencia para un servicio rápido y confiable de Kimi K3. SGLang tiene un historial de fuerte soporte para modelos de lenguaje y visión, y Kimi K3 no es la excepción. Con el equipo de RadixArk, nos enfocamos en la compatibilidad del frontend y la optimización del kernel, y nuestro equipo de ingeniería contribuyó con correcciones para errores del frontend relacionados con el manejo de llamadas de herramientas y salidas estructuradas para respaldar la preparación para el lanzamiento.
Gracias a los equipos de Inferact y RadixArk por construir lado a lado 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 cumplir realmente con esa inteligencia durante la inferencia.
Los benchmarks de Kimi K3 muestran un rendimiento sólido en tareas agentivas, que dependen de llamadas precisas a herramientas y salidas de modelo de alta calidad.
La validación de calidad puede ocurrir en diferentes niveles de rigor. Verificaciones simples de cordura, 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 estén desviando. Pero lanzar una API pública requiere evaluaciones comparativas más rigurosas.
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 para 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 encuentra frente al motor de inferencia y procesa las entradas y salidas.
El frontend es código determinista que se ejecuta en la CPU frente al 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 el razonamiento y las llamadas a herramientas
- Formatear la salida como 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. Verificaciones robustas como Kimi Vendor Verifier evalúan el rendimiento en modos de falla 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, usamos 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 correcta
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 correcta, realizamos un barrido sobre varias opciones como configuraciones de Paralelismo de Tensores (TP) y Paralelismo de Expertos (EP), activación de Paralelismo de Datos de Atención (ADP), tamaño de lotes, longitudes de borrador de decodificador especulativo, intervalos de almacenamiento en caché de capas lineales, parámetros de enrutamiento y configuraciones del motor de inferencia.
El Paralelismo de Tensores y el Paralelismo de Expertos dividen modelos grandes en múltiples GPU.
Ejecutar Kimi K3 requiere ocho GPU NVIDIA GB300 para que los enormes pesos del modelo quepan en la VRAM. Sin embargo, a diferencia de muchas otras GPU NVIDIA que vienen en nodos de ocho, las GB300 vienen en nodos de cuatro. Si bien esto podría parecer inicialmente que limita las posibles estrategias de paralelismo (tradicionalmente, el Paralelismo de Tensores no es posible entre nodos, ya que las interconexiones lentas convierten las costosas operaciones de reducción total en un cuello de botella para la inferencia), el sistema GB300 NVL72 tiene una interconexión entre nodos suficientemente rápida como para que podamos ejecutar inferencia con Paralelismo de Tensores y Paralelismo de Expertos entre 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, mientras también contribuían con PRs a los motores de código abierto.
Hito 4: Optimizar el rendimiento
Una vez que un modelo está funcionando con una configuración optimizada, hay una gran cantidad de técnicas de ingeniería de inferencia que pueden mejorar materialmente la latencia, el rendimiento o una combinación de ambos. Para las API de modelos, generalmente consideramos:
- Especulación: Usar un modelo borrador pequeño para predecir múltiples tokens y luego validarlos como parte del paso forward. Esta optimización sin pérdidas mejora los TPS por usuario en decode.
- Desagregación: Mover el prefill y el decode a trabajadores separados. Esto evita la competencia por recursos, permite una configuración más específica y hace que la proporción de cómputo de prefill a decode sea ajustable para coincidir con el tráfico.
- Caching: Asignar memoria para guardar el caché KV y los estados de KDA entre solicitudes, permitiendo que solicitudes posteriores con prefijos compartidos en secuencias de entrada omitan todo o parte del prefill. Esto mejora el TTFT y el rendimiento general del sistema.
Tener el modelo en funcionamiento desde 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, en funcionamiento 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 del caché KV, esto cambia, y la tokenización puede volverse relevante para el tiempo de prefill, 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 mejoras adicionales de 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 expectación en toda la industria por Kimi K3. Esto se verá igualado por una gran ola de demanda de la API en el lanzamiento. Por lo tanto, el rendimiento general del sistema, no solo la latencia por usuario, es una prioridad máxima.
En un sistema GB300 NVL72, un nodo tiene 4 GPU individuales, lo que significa que hay 18 nodos. Como instancia, Kimi K3 ocupa 2 nodos (8 GPU); 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 importante para el rendimiento de una réplica determinada es la tasa de aciertos del caché de prefijo. Dada la escala del despliegue, esto hace que el enrutamiento consciente de KV sea 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 al caché KV guardado para omitir el prefill.
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 cálidos para consultas repetidas. Como los agentes de codificación y de múltiples turnos son casos de uso comunes para Kimi K3, este sistema de enrutamiento consciente de caché es fundamental 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 API de modelos, y esperamos continuar optimizando nuestra implementación de este modelo para alcanzar los más altos estándares de rendimiento y confiabilidad.
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 frente en Baseten.
Kimi K3 ya está disponible hoy en las API de modelos de Baseten. Bienvenido a la nueva frontera en inteligencia de pesos abiertos.
Agradecimientos 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 frente. También, gracias a los equipos de Moonshot AI, Inferact y RadixArk por su colaboración y apoyo.
