Kimi K2.5 no se anunció con fuegos artificiales, pero sí con una ambición clara: ver, programar y coordinar enjambres de subagentes como flujo de trabajo normal.
Mientras buena parte del sector seguía comparando la última tanda de modelos “frontier” occidentales, Moonshot AI optó por una estrategia poco habitual: lanzar Kimi K2.5 con un “silent rollout” (despliegue silencioso), primero visible en su interfaz web y app, sin keynote ni campaña masiva. El efecto buscado es doble: iterar rápido con datos de uso real y, al mismo tiempo, comunicar confianza (si el producto es bueno, lo descubrirán los usuarios en el día a día). La compañía lo ha formalizado después con documentación técnica y repositorio abierto: K2.5 es un modelo open-source, nativamente multimodal y orientado a tareas agenticas.
La combinación de “visión nativa + agentes” importa porque apunta a un cambio de etapa: ya no basta con escribir texto mejor o programar más rápido. El objetivo se desplaza hacia sistemas que perciben (imágenes, vídeo), deciden (selección de herramientas, planificación) y ejecutan (múltiples tareas en paralelo) con menos supervisión humana. En el relato de Moonshot, Kimi K2.5 no es solo una actualización; es la presentación de lo que llaman “visual agentic intelligence”: la idea de que la multimodalidad deja de ser un complemento y pasa a ser el núcleo del trabajo autónomo.
1) La clave técnica: visión “nativa”, no injertada
Hasta hace poco, muchas soluciones multimodales se apoyaban en un patrón: un encoder visual externo convierte la imagen en vectores y el modelo lingüístico “interpreta” esa representación. En K2.5, Moonshot insiste en una diferencia: el modelo está entrenado como nativamente multimodal, con visión y lenguaje integrados desde el preentrenamiento (no como módulo añadido). La cifra que repite el equipo es enorme: ~15 billones (trillions) de tokens mezclando texto y visión durante el entrenamiento continuo sobre su base previa.
¿Por qué esto es más que una etiqueta de marketing? Porque, en teoría, reduce fricciones típicas de la “multimodalidad pegada con cinta”: pérdidas de fidelidad en detalles, lectura deficiente de layouts, fallos en OCR, o inconsistencias cuando una tarea exige razonar con imagen y luego producir código o pasos verificables. El salto que describen muchos usuarios tempranos (y que la propia documentación sugiere) no es “ve una imagen”, sino que la usa como input operativo: comprender una interfaz y replicarla, extraer estructura de un documento, o transformar un diseño en código funcional.
2) Del copiloto al “enjambre”: Agent Swarm como propuesta de producto
La segunda gran apuesta es la agentificación a escala. Moonshot no se conforma con “function calling” y herramientas: introduce un modo específico de agent swarm (enjambre de agentes) que permite dividir un objetivo en subtareas y ejecutarlas en paralelo con coordinación interna. En su blog, Kimi ofrece modos separados (instant, thinking, agent y agent swarm beta) y plantea el swarm como un patrón de ejecución para tareas largas o complejas.
Este enfoque no es solo “más agentes = más velocidad”. La promesa real es más cobertura: explorar rutas alternativas, validar hipótesis distintas, o hacer QA en paralelo (tests, lint, revisión de interfaz, comprobaciones). Un ejemplo típico en software: mientras un agente refactoriza, otro escribe tests, otro revisa edge cases y otro documenta. El usuario no “chatea”: gestiona un flujo de trabajo. En el material compartido por la comunidad se habla incluso de decenas de subagentes en paralelo; el punto relevante, periodísticamente, es que la interfaz y el modelo se diseñan pensando en esa multiplicación como comportamiento normal, no excepcional.
3) Arquitectura y eficiencia: el truco del MoE para no arruinarte en inferencia
K2.5 hereda el ADN de Kimi K2: arquitectura Mixture-of-Experts (MoE) con una cifra total gigantesca de parámetros, pero un subconjunto activado por petición. En el repositorio oficial, Moonshot vuelve a fijar el marco: del orden de un trillón total y decenas de miles de millones activados por inferencia (lo que reduce coste y latencia frente a modelos densos equivalentes).
En paralelo, el enfoque hacia cuantización (por ejemplo, INT4 en ciertos escenarios) aparece como parte del objetivo: mantener rendimiento alto sin disparar costes, algo crucial si quieres que “agent swarms” no sean un lujo. Un enjambre que hace 30 o 100 sub-tareas es inviable si cada sub-tarea cuesta como una sesión premium de un modelo propietario. Aquí Moonshot intenta competir donde duele: coste total por trabajo terminado, no coste por token aislado.
4) Benchmarks que importan: SWE, HLE y vídeo multimodal
En IA es fácil ahogarse en tablas, así que conviene separar señal de ruido. Kimi K2.5 se está empujando en tres frentes medibles:
-
Programación: aparece con fuerza en SWE-Bench Verified, una referencia de “arreglar issues reales” en repositorios. VentureBeat reporta una cifra concreta (76,8% en su cobertura, con comparaciones frente a modelos propietarios), aunque las tablas exactas dependen de configuración y “thinking modes”.
-
Razonamiento/agentificación: Kimi destaca resultados en “agentic benchmarks” y enfatiza que su rendimiento llega “a una fracción del coste” respecto a opciones propietarias.
-
Vídeo: TechCrunch recoge que el modelo entiende texto, imagen y vídeo, y que en benchmarks de vídeo supera a algunos pares propietarios en tareas de razonamiento multimodal.
Lo relevante aquí no es el “quién gana por décimas”, sino el patrón: si un open-source se acerca a los líderes en coding y además añade visión/vídeo con un modo swarm, entra en la conversación de herramienta de trabajo, no solo de “modelo interesante”.
5) Kimi Code: la ofensiva por el terminal y el IDE
Moonshot acompaña el modelo con un producto de distribución: Kimi Code, pensado para usarse desde terminal o integrarse con editores. TechCrunch menciona integración con herramientas como Visual Studio Code, Cursor y Zed, y la posibilidad de usar imágenes y vídeo como input en flujos de desarrollo.
Esto no es un detalle menor: los modelos compiten, sí, pero las “superficies” (CLI, IDE plugins, apps) son donde se gana cuota. Si consigues que K2.5 sea el motor detrás de un flujo habitual de desarrollo, el modelo deja de ser un evento y se convierte en infraestructura. Además, el vínculo “visión + código” abre un caso de uso muy buscado: mirar una UI (imagen/vídeo) y generar una interfaz equivalente, una tarea que hoy define buena parte del ROI del “coding con IA”.
6) El ángulo geopolítico y de mercado: China ya juega en multimodalidad y agentes
Kimi K2.5 también se entiende como movimiento de mercado chino hacia el “frontier” con una narrativa propia: open-source, coste bajo, multimodalidad fuerte y agentes. TechCrunch sitúa a Moonshot como empresa respaldada por actores relevantes del capital asiático, como Alibaba y HongShan (ex Sequoia Capital China), y recuerda su fundador, Yang Zhilin.
Esa base financiera explica por qué Moonshot puede apostar por investigación cara (15T tokens), tooling (Kimi Code, API, app) y distribución. Y, de paso, por qué el “silent rollout” tiene sentido: si tienes canal propio (Kimi.com) y comunidad amplia, puedes desplegar cambios sin depender de la prensa para generar tráfico.
7) Lo que no conviene exagerar: límites reales del “salto agente”
El discurso “agentic evolution” puede sonar a automatización total, pero incluso la documentación oficial sugiere una lectura más sensata: K2.5 mejora en orquestación, tool use y percepción, pero la calidad final depende de (1) herramientas disponibles, (2) permisos, (3) coste de ejecución y (4) evaluación. En agent swarms, el riesgo no es solo “que se equivoque”, sino que haga mucho trabajo equivocado en paralelo.
Por eso es importante que Moonshot insista en modos (instant vs thinking vs agent vs swarm) y en benchmarking reproducible vía API. Dicho de otro modo: el producto sugiere que han aprendido lo mismo que el resto del sector: cuando das autonomía, necesitas controles, trazabilidad y configuración, o el rendimiento percibido se hunde por errores acumulados.
8) Por qué este lanzamiento importa aunque “saliera sin ruido”
La foto final es clara: Kimi K2.5 consolida una tendencia que ya se está imponiendo en 2026: la carrera no es solo por “el mejor chat”, sino por el mejor trabajador digital. Y ese trabajador digital necesita tres piernas:
-
Percepción (vision nativa: entender pantallas, documentos, escenas, vídeos).
-
Ejecución (herramientas + código + control de entorno).
-
Paralelización (swarm/ subagentes para tareas complejas con plazos humanos).
Moonshot plantea que las tres encajan en un modelo open-source competitivo y, sobre todo, usable: web/app/API + herramienta de coding. Si el rendimiento real en proyectos se acerca a lo prometido por benchmarks, K2.5 no será recordado por su “silent rollout”, sino por algo más práctico: haber puesto multimodalidad y trabajo agentico al alcance de presupuestos que antes solo permitían autocompletar.
