Moonshot abre Kimi K2: un MoE de 1 billón de parámetros diseñado para agentes

Moonshot AI ha publicado los pesos de Kimi K2, un modelo de tipo Mixture-of-Experts con 1 billón de parámetros, de los cuales se activan 32 mil millones por cada token. Hay dos versiones: Kimi-K2-Base, para quienes quieran ajustar el modelo por su cuenta, y Kimi-K2-Instruct, para chat y escenarios agénticos. Instruct no razona de forma prolongada: responde de inmediato. Más tarde llegó la actualización 0905, con mejor programación agéntica y un contexto de 256K. Según la compañía, entre los modelos sin modo thinking, K2 obtiene el mejor resultado en conocimiento, matemáticas y programación.

MuonClip: cómo entrenar un billón de parámetros sin fallos

La principal novedad técnica no está en el tamaño, sino en el optimizador. El equipo de Moonshot lleva tiempo apostando por Muon. En su trabajo anterior, Moonlight, superó con claridad al habitual AdamW en eficiencia de uso de tokens. Para K2 escalaron ese enfoque a una arquitectura próxima a la de DeepSeek-V3. Tras analizar las scaling laws, los ingenieros redujeron el número de cabezas de atención para ganar eficiencia con contextos largos y aumentaron la dispersión del MoE para mejorar la eficiencia por token.

A gran escala apareció un problema: con Muon, los logits de atención explotan con más frecuencia. Ni el logit soft-capping ni la normalización de query y key lo resolvieron. La solución fue qk-clip. Tras cada paso de Muon, los pesos de las proyecciones query y key se escalan por un coeficiente η, igual a min(t / max(qᵀk), 1), donde t se fija de antemano. Así, la escala de los logits se limita en su origen y no después de que el problema aparezca. El resultado: el preentrenamiento con 15.5 billones de tokens transcurrió sin un solo pico de loss. Moonshot señala además que el método es general y puede resultar útil en otras tareas de estabilización.

De dónde salen las habilidades agénticas

El modelo se entrenó para actuar en dos etapas. Primero se construyó un pipeline de datos sintéticos inspirado en ACEBench. Abarca cientos de dominios y miles de herramientas, tanto MCP reales como sintéticas, y genera cientos de agentes con distintos conjuntos de herramientas. Los agentes interactúan con un entorno simulado y con usuarios simulados. Las tareas se evalúan con rúbricas y un LLM actúa como juez para descartar las trayectorias débiles. Las trayectorias restantes pasan a rejection sampling y RL.

La segunda etapa es un RL general, donde lo más difícil son las tareas sin recompensa verificable, como redactar un informe de investigación. Aquí el modelo actúa como su propio crítico y evalúa el resultado según rúbricas. El crítico se ajusta de forma continua con on-policy rollouts con recompensas verificables (matemáticas, código competitivo), para que la evaluación no se quede atrás respecto a la política.

En las demostraciones, K2 elige las herramientas por sí sola. El análisis de salarios requirió 16 llamadas a IPython. El plan de un viaje a un concierto de Coldplay en Londres se armó con 17 llamadas a través de búsqueda, calendario, Gmail, billetes de avión, Airbnb y restaurantes. En la demo Flask-to-Rust, el modelo reescribe el proyecto y ejecuta benchmarks.

Parámetros clave

• Arquitectura: MoE, 1 billón de parámetros, 32 mil millones activos
• Preentrenamiento: 15.5 billones de tokens, optimizador MuonClip, sin fallos
• Lanzamiento: Kimi-K2-Base y Kimi-K2-Instruct
• Contexto tras la actualización 0905: 256K
• Motores de inferencia: vLLM, SGLang, KTransformers, TensorRT-LLM
• API: compatible con las interfaces de OpenAI y Anthropic

Qué probar y dónde están los obstáculos

Para una prueba rápida, el modelo está disponible gratis en Kimi web y móvil. Allí las funciones MCP siguen en desarrollo y no hay soporte de visión. A los desarrolladores les resultará más sencillo conectarse mediante la API, que acepta clientes de OpenAI y Anthropic: apenas habrá que cambiar el código de la aplicación, basta con cambiar el endpoint y el modelo. Para desplegarlo en hardware propio, los autores recomiendan los motores mencionados y remiten a las instrucciones en GitHub. Un billón de parámetros exige un clúster considerable, así que, por ahora, el despliegue propio solo encaja en equipos que ya cuentan con la infraestructura.

Las limitaciones las reconoce la propia Moonshot. En razonamientos complejos o cuando las herramientas están descritas de forma imprecisa, el modelo puede generar tokens de más, y entonces la respuesta se corta o la llamada a la herramienta queda incompleta. Con las herramientas activadas, la calidad cae en algunas tareas. Un proyecto de software completo a partir de un único prompt sale peor que dentro de un entorno agéntico. La conclusión práctica: conviene prever límites de tokens, describir con claridad los esquemas de las herramientas y dar a K2 un ciclo con tests y logs en lugar de una sola petición grande. La compañía promete añadir más adelante el modo thinking y la visión.