El anuncio de Kimi K2.5 colocó a Moonshot AI en el centro de la conversación sobre IA de pesos abiertos: cualquiera puede descargar los pesos, ajustarlos y montar sus propios experimentos. La idea suena tan liberadora como tener las llaves de un coche de competición. El detalle es que ese coche viene sin garaje: el paquete ronda los 595 GB, un tamaño que convierte la “apertura” en una promesa difícil de materializar para quien trabaja con una o dos GPU de consumo.
Esa tensión explotó con naturalidad en Reddit, en r/LocalLLaMA, durante un Ask Me Anything de tres horas con miembros del equipo (bajo los usuarios ComfortableAsk4494, zxytim y ppwwyyxx). Lejos del tono pulido de un blog corporativo, el intercambio mostró el día a día real de la frontera: frustraciones de despliegue, explicaciones sobre por qué los modelos “se desvían” de su identidad, y una tesis clara sobre el próximo salto de capacidades, que no pasa solo por añadir parámetros.
La petición más repetida: modelos más pequeños y utilizables
La comunidad fue directa: si el objetivo es que lo abierto sea usable, hacen falta tamaños que entren en el hardware que la gente realmente tiene. Aparecieron propuestas concretas de rangos como 8B, 32B o 70B, y peticiones de variantes enfocadas a programación que no obliguen a montar un mini centro de datos.
La respuesta de Moonshot fue honesta, aunque no complaciente. Reconocieron que la demanda está ahí y que no es la primera vez que la escuchan. Señalaron que ya cuentan con algunos modelos más pequeños, incluidos enfoques tipo mezcla de expertos, publicados en plataformas como Hugging Face, y matizaron un punto que suele pasarse por alto: crear un modelo “pequeño pero muy bueno” no siempre es un simple recorte del grande, sino otra inversión de ingeniería.
Lo interesante fue el umbral mental que mostraron: cuando se les planteó un modelo alrededor de 100.000 millones de parámetros pensado para uso local, respondieron barajando un compromiso distinto, quizá de 200.000 o 300.000 millones, para mantenerse por encima de un “umbral de usabilidad” en tareas variadas. Traducido a lenguaje cotidiano, es como intentar cocinar para todos con una misma receta: si bajas demasiado los ingredientes, no alimenta; si mantienes el plato contundente, no todo el mundo puede pagarlo o prepararlo.
¿Se está agotando el truco de “más grande = mejor”?
Otro giro de la conversación atacó el corazón del debate actual: las leyes de escalado siguen funcionando, pero cada vez con rendimientos más modestos si el enfoque es el clásico “predicción del siguiente token con datos de Internet”. La explicación del equipo fue simple: el dato de alta calidad no crece al mismo ritmo que el cómputo disponible. Si tienes más hornos que harina, hornear más tiempo no soluciona el problema.
La salida que propusieron no fue “entonces hagamos un modelo aún más enorme”, sino cambiar la forma de escalar. Su apuesta es el test-time scaling apoyado en sistemas de agentes, donde parte de la mejora ocurre durante la inferencia: el modelo organiza trabajo, delega, verifica y luego esos aprendizajes se pueden integrar de vuelta en entrenamiento, a menudo vía refuerzo (RL). La unidad de progreso se desplaza: del tamaño del cerebro al método de trabajo.
Agent Swarm: coordinación sin ahogar al orquestador
El concepto estrella fue Agent Swarm, la capacidad de coordinar hasta 100 subagentes en paralelo. Suena bien hasta que recuerdas el problema típico de los sistemas multiagente: el orquestador se convierte en cuello de botella, la latencia crece y el contexto se llena de “ruido” hasta que el sistema se pierde, un fenómeno que muchos desarrolladores describen como desgaste del contexto.
Aquí apareció un detalle técnico con implicación práctica: Moonshot explicó que cada subagente mantiene su memoria de trabajo separada y solo devuelve resultados al coordinador, en lugar de volcar todo el proceso a un contexto compartido. Es la diferencia entre recibir un informe ejecutivo o sentarte a escuchar todas las llamadas internas de una empresa. Con informes, puedes escalar. Con llamadas, te saturas.
También hablaron del supuesto “acelerón” de rendimiento, citado en ocasiones como 4,5x. El matiz fue relevante: depende de cuánto se pueda paralelizar una tarea. El sistema, según describieron, puede decidir que no vale la pena lanzar un enjambre si el trabajo no lo requiere. Y, para que el enjambre no se convierta en gasto descontrolado, el orquestador gestiona presupuestos de tokens y asigna tareas acordes a cada agente. Es un patrón muy de ingeniería: control limpio, outputs acotados, señal por encima del ruido.
El siguiente gran gasto: refuerzo para entrenar agentes, no solo “chatbots”
En el AMA también se dejó caer un cambio de prioridades: más cómputo destinado a entrenamiento por refuerzo (RL), con objetivos nuevos “especialmente en el espacio de agentes”. Es una frase que pesa, porque implica que el dinero y el tiempo se están moviendo hacia formar modelos que actúen bien al planificar, usar herramientas, corregirse y terminar tareas, no solo al responder con fluidez.
Para equipos que evalúan modelos en empresa, este giro tiene dos caras. Por una parte, RL suele mejorar la capacidad de completar tareas multi-paso. Por otra, puede introducir comportamientos inesperados: modelos más “decididos”, más inclinados a usar herramientas, o más obedientes a señales de recompensa que no encajan con la cultura o el riesgo de una organización. La conversación no prometió una solución mágica; retrató el área como el campo de batalla inmediato.
Por qué a veces se llama “Claude”: deriva de identidad y gobernanza del prompt
Uno de los momentos más delicados fue el tema de la identidad: usuarios reportaron que el modelo a veces se presenta como “Claude”, lo que alimenta sospechas de contaminación de datos o distilación. Moonshot no lo negó como comportamiento; lo contextualizó. Con ciertos prompts de sistema, dijeron, la probabilidad de que responda “Kimi” es alta. Con un prompt de sistema vacío, el modelo entra en un área “indefinida” donde manda la distribución del preentrenamiento, y ahí aparecen asociaciones no deseadas.
La explicación concreta se apoyó en una decisión de datos: al “sobre-muestrear” código reciente de Internet, ese ecosistema estaría más cargado de menciones a Claude por la forma en que desarrolladores hablan de asistentes de programación. El punto operativo es muy útil: la gobernanza del prompt de sistema no es decoración, es higiene. Si dejas la identidad al azar, aceptas que el modelo improvise su tarjeta de presentación.
Cuando la gente echa de menos el “alma”: personalidad, gusto y deriva
Otro hilo fue más humano: varios usuarios sintieron que Kimi K2.5 suena más genérico que versiones anteriores, como el típico asistente “correcto” que responde sin chispa. El equipo admitió que la personalidad cambia con cada iteración y que medirla es difícil. Hablaron de “gusto” en escritura, de cómo los modelos de recompensa evolucionan y de que usan evaluaciones internas para no perder calidad creativa.
La metáfora aquí es sencilla: es como afinar un instrumento mientras tocas en concierto. Cada ajuste para mejorar una cosa puede mover otra. Y cuando el sistema se entrena para ser más eficaz en código o razonamiento, la sensación de estilo puede “aplanarse” si la recompensa castiga riesgos o tonos que antes daban carácter. La idea de permitir personalización por usuario, incluso guardando un “estado” de preferencias, sugiere una dirección: no un modelo con una personalidad fija, sino un modelo con “acento” configurable.
La verdad menos glamorosa: la frontera se construye depurando
Si hubo una palabra que resumió el oficio, fue “debugging”. La presentaron como prioridad constante tanto en preentrenamiento como en postentrenamiento. También contaron un ejemplo: intentaron incorporar una arquitectura experimental de atención lineal (Kimi Linear) y falló al escalar; tuvieron que retroceder y pasar por meses de depuración hasta hacerlo funcionar.
Esa sinceridad es valiosa porque rompe un mito frecuente. La innovación no siempre es un salto elegante; muchas veces es localizar un fallo que aparece solo cuando multiplicas el tamaño, el contexto o el número de agentes. La investigación, tal como la describieron, se parece más a gestionar fallos repetidos hasta que algo se sostiene, que a celebrar un único hallazgo brillante.
Lo que asoma en Kimi K3: atención lineal, optimizaciones y aprendizaje continuo
Aunque sin entrar en detalles finales, dejaron pistas sobre lo siguiente: es probable que atención lineal sea parte de K3, con otras optimizaciones, y mencionaron el aprendizaje continuo como una línea activa para mejorar la “agencia” y permitir que los agentes trabajen durante periodos más largos, algo especialmente relevante en empresa, donde las tareas no son un turno de chat, sino proyectos que duran semanas.
También apuntaron a publicar el andamiaje de orquestación de Agent Swarm cuando sea más estable. Si eso llega en forma usable, la conversación se moverá de “¿qué tan bueno es el modelo?” a “¿qué tan fácil es desplegar el sistema completo?”, porque en 2026 el producto real ya no es solo el motor, sino la transmisión, el tablero y los frenos.
Kimi K2.5, al final, expuso una paradoja moderna: lo open no se mide solo por licencias o pesos disponibles, sino por si cabe en la realidad de la gente. Y, mientras la comunidad pide modelos que funcionen en su escritorio, los laboratorios empujan hacia enjambres de agentes, refuerzo y arquitecturas que gestionen memoria como una oficina bien organizada: cada equipo con su carpeta, el coordinador con la bandeja de entrada limpia, y el ruido fuera de la sala de decisiones.