Esa tensión explotó con naturalidad en Reddit, en r/LocalLLaMAdurante un Ask Me Anything de tres horas con miembros del equipo (bajo los usuarios ComfortAsk4494, 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 usablehacen 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 obligan 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 alrededor modelo de 100.000 millones de parámetros pensados para uso local, respondieron barajando un compromiso distinto, quizás 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 escalada 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 datos de alta calidad no crece al mismo ritmo que el cómputo disponible. Si tienes más hornos que harina, hornea más tiempo no solucionará 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 escala de tiempo de prueba 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 Enjambre de agentesla capacidad de coordinar hasta 100 subagentes en paralelo. Suena bien hasta que recuerdas el típico problema 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 separado 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 sentarse 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 lo descrito, 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, salidas acotadas, 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 en varios pasos. Por otro, 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 inmediata.
Por qué a veces se llama “Claude”: deriva de identidad y gobernanza del pronto
Uno de los momentos más delicados fue el tema de la identidad: los usuarios reportaron que el modelo a veces se presenta como “Claude”, lo que alimenta sospechas de contaminación de datos o destilación. Moonshot no lo empresarial como comportamiento; lo contextualizó. Con ciertas indicaciones del sistema, dijeron, la probabilidad de que responda “Kimi” es alta. Con un 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 los desarrolladores hablan de asistentes de programación. El punto operativo es muy útil: la Gobernanza del sistema rápido 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 las 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 evolucionan los modelos de recompensa 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 la 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 “depuración”. La presentada 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 multiplica 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 períodos 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 Enjambre de agentes cuando sea más estable. Si eso llega en forma utilizable, 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 abierto 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 funcionan 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.
