Kimi K2.6: modelo que anteriormente mantenía Gonka

Kimi K2.6 — es un gran modelo de lenguaje (LLM) de la serie Kimi, desarrollado por la empresa con sede en Pekín Moonshot AI. Moonshot AI es uno de los principales laboratorios de IA de China, fundado en 2023 por un equipo de investigadores liderado por Yang Zhilin. La compañía ha recibido financiación de Alibaba, Tencent y otros grandes inversores, y forma parte de la lista de los «tigres de la IA china»: empresas que marcan el ritmo del desarrollo de la IA en Asia.

La serie Kimi es conocida desde 2024. Las primeras versiones (K1, K1.5) llamaron de inmediato la atención por su ventana de contexto excepcionalmente larga, de hasta 200 000 tokens en una sola petición, lo que en el momento del lanzamiento era un récord entre los modelos de acceso público. Un contexto largo significa la posibilidad práctica de analizar en una sola petición un libro entero, una base de código de tamaño medio o un conjunto de documentos jurídicos. En el momento del lanzamiento de Kimi, esta característica era una potente ventaja competitiva.

La versión K2 apareció en 2025 y trajo consigo un salto arquitectónico fundamental: el paso a MoE (Mixture of Experts). Esta misma arquitectura es la base de Qwen3-235B y DeepSeek-R1, y se ha convertido en el estándar de facto para los mayores modelos de 2025—2026. MoE permite tener cientos de miles de millones de parámetros «en total», pero activar solo un subconjunto en cada petición (normalmente el 5—10 %), lo que reduce drásticamente el coste computacional de la inferencia con una calidad comparable.

K2.6 es la última iteración de la serie K2 en el momento de escribir este artículo. De las declaraciones públicas de Moonshot AI se desprende que en esta versión se han mejorado las capacidades del modelo en reasoning (razonamiento lógico), generación de código y llamada nativa de herramientas (tool calling). Mientras el modelo fue servido por la red Gonka, estaba disponible bajo el identificador moonshotai/Kimi-K2.6; ahora la pasarela no acepta este identificador — la lista actualizada de modelos siempre la devuelve GET /v1/models.

Ambos modelos representan desarrollos emblemáticos de los laboratorios de IA más grandes de China; mientras ambos fueron mantenidos por la red, estaban disponibles a través de una única interfaz compatible con OpenAI, JoinGonka Gateway; hoy, de este par, solo MiniMax M2.7 está disponible a través de la puerta de enlace. Al mismo tiempo, tienen diferentes fortalezas y legados, lo que hace que elegir entre ellos no sea una cuestión de «cuál es mejor», sino de «cuál se adapta a la tarea».

En los benchmarks de reasoning (MATH-500, GSM8K, AIME), la serie Kimi K2 muestra históricamente resultados en el grupo superior de modelos open-weights, compitiendo con DeepSeek-R1 y modelos de estilo o1. En tareas de generación de código (HumanEval, MBPP), ambos modelos se mantienen en niveles similares. La fortaleza de MiniMax M2.7 es la atención efectiva (lineal) para secuencias muy largas, mientras que Kimi es conocida por su fuerte reasoning y el contexto largo de la serie Kimi.

Una advertencia importante sobre los benchmarks en 2026: la brecha entre los modelos principales en las pruebas públicas se ha reducido a unos pocos puntos porcentuales, y esta diferencia a menudo resulta estar dentro del margen de error estadístico de los propios benchmarks. Para el trabajo práctico, lo que importa no es «quién es un 2% superior en MMLU», sino la naturaleza de las tareas: qué contexto le das al modelo, qué tan complejas son las cadenas lógicas, si se necesita un historial de diálogo largo, qué idiomas se utilizan. Por lo tanto, la tabla anterior no clasifica los modelos, sino que ayuda a comprender rápidamente para qué perfil de tareas está optimizado cada uno.

Para una elección práctica hoy: el nicho de Kimi K2.6 (contexto largo para análisis de documentos extensos, lectura de bases de código grandes, diálogos largos con mantenimiento de historial) y tareas de reasoning complejas está cubierto en la composición actual de la red por dos modelos. De los razonamientos se encarga GLM-5.3 Flash: piensa antes de responder y es la que debe elegirse para lógicas enrevesadas; además, tiene el contexto más largo de la red (390K). Para prompts grandes sin razonamiento y sesiones de agentes largas: DeepSeek V4 Flash (380K, el segundo contexto más largo). Si la prioridad es el procesamiento de secuencias de entrada muy largas y datos en streaming con una respuesta rápida: MiniMax M2.7 con su atención efectiva. Una buena estrategia en producción no ha cambiado: mantener varios modelos de la red en su código. El cambio rápido a través del parámetro model permite alternar entre ellos dependiendo de la tarea sin cambiar la arquitectura de la aplicación.

Hasta la primavera de 2026, toda la red Gonka daba servicio a exactamente un modelo: Qwen3-235B. Desde el punto de vista de la arquitectura, era una decisión sensata: la inferencia distribuida mediante DiLoCo exige que todos los participantes de la red mantengan el mismo modelo en memoria de video, de lo contrario es imposible garantizar que cualquier nodo pueda procesar cualquier solicitud. La Qwen3-235B completa en formato FP8 ocupa unos 640 GB de VRAM, lo que ya de por sí es un compromiso enorme para cada ML-node.

Para pasar a una red multimodelo hacía falta un mecanismo que permitiera mantener varios modelos a la vez sin exigir que cada host los ejecutara todos. Ese mecanismo son los DevShards: shards separados de la red, cada uno especializado en un modelo. Los nodos dentro de un mismo shard trabajan sobre el mismo modelo, y el enrutador de la red dirige la solicitud al shard con el modelo necesario.

La idea no surgió de la nada: se formalizó en la Gonka Improvement Proposal #800 «Multi-Model PoC», sometida a votación de la comunidad en la primavera de 2026. La propuesta recibió el apoyo de los participantes y validadores de la red y se implementó entre abril y mayo de 2026. Kimi K2.6 fue el primer modelo lanzado en un DevShard independiente, es decir, en la práctica una implementación de prueba del nuevo enfoque. La experiencia fue un éxito: tras ella llegaron a sus propios shards MiniMax M2.7, DeepSeek V4 Flash y GLM-5.3 Flash, cada uno con su propio conjunto de hosts y su propia economía. El mismo mecanismo funciona también a la inversa: un modelo que los hosts dejan de soportar se retira de la red por votación; así fue precisamente como se marchó la propia Kimi K2.6 en septiembre de 2026.

Qué significa esto para usuarios y desarrolladores:

• Una sola API, varios modelos. A través de JoinGonka Gateway no hace falta cambiar el endpoint ni las claves: basta con indicar otro model en el cuerpo de la solicitud. El formato compatible con OpenAI se mantiene por completo.
• El mismo precio. Mientras Kimi K2.6 estuvo en servicio, se facturaba a la misma tarifa que MiniMax M2.7; la tarifa única de la red se mantiene también para los modelos actuales: $0.0069 por 1M de tokens a través del Gateway. Un precio único es una decisión consciente para simplificar la migración de los usuarios entre modelos.
• La estabilidad depende de la carga del shard. En la fase inicial, el shard de un modelo nuevo tiene menos hosts, por lo que al concentrarse las solicitudes el modelo puede devolver temporalmente 429 too many concurrent requests. Es una fase normal para un modelo nuevo: a medida que crece el interés, los hosts se van conectando a su shard y los límites aumentan. También ocurre lo contrario: si los hosts abandonan el shard, el modelo pierde capacidad; así terminó precisamente la historia de Kimi K2.6 en la red.
• El tool calling es distinto en cada modelo. En Kimi K2.6, al inicio en la red Gonka se registraron pequeños problemas con la selección automática de herramientas (tool_choice: "auto"), resueltos después con una actualización de los nodos. La lección sigue siendo válida para cualquier modelo de la red: el formato de llamada a herramientas es una propiedad de cada modelo concreto en cada nodo concreto, así que para escenarios críticos en producción conviene probar de antemano el comportamiento del modelo elegido con tus propias solicitudes.

Respuesta directa: Kimi K2.6 ya no está disponible a través de la red Gonka. Los hosts dejaron de darle servicio a principios de septiembre de 2026, y la propuesta de governance #101 retiró definitivamente el modelo de la lista de modelos de la red — el gateway rechazará cualquier solicitud con model: "moonshotai/Kimi-K2.6". Como los pesos del modelo son abiertos, todavía puedes obtenerlo en hostings externos de modelos open-weights (por ejemplo, a través de OpenRouter) o desplegarlo por tu cuenta.

Pero si lo que buscas es ese inference descentralizado y muchas veces más barato por el que la gente llega a Gonka, sigue estando ahí, solo que ahora funciona sobre los modelos activos de la red. A través del JoinGonka API Gateway, con API compatible con OpenAI y Anthropic, hay tres modelos disponibles, y cada uno cubre una parte de lo que se valoraba en Kimi:

• GLM-5.3 Flash (zai-org/GLM-5.3-Flash) — el modelo de reasoning de Z.ai: razona antes de responder, así que es la opción para lógica compleja, análisis de código y tareas de «pensar»; además tiene el contexto más largo de la red (390K). El razonamiento entra dentro del límite de respuesta — pon max_tokens con margen y activa el stream.
• DeepSeek V4 Flash (deepseek-ai/DeepSeek-V4-Flash-0731) — uno de los contextos más largos de la red (380K), la salida más extensa y un agentic coding potente: repositorios grandes, cadenas largas de llamadas a herramientas.
• MiniMax M2.7 (MiniMaxAI/MiniMax-M2.7) — el modelo por defecto del gateway: respuestas rápidas y uniformes en tareas cotidianas, documentos largos y procesamiento en streaming.

Migrar desde Kimi K2.6 es cambiar una sola línea. Cualquier código escrito para OpenAI funciona sin modificaciones: basta con cambiar la URL, la API key y el nombre del modelo.

curl https://gate.joingonka.ai/v1/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MiniMaxAI/MiniMax-M2.7",
    "messages": [{"role": "user", "content": "Explain the difference between MoE and dense models"}]
  }'

En las herramientas de desarrollo la regla es la misma: dondequiera que en la configuración tengas moonshotai/Kimi-K2.6, sustituye el identificador de uno de los modelos activos. En Cursor es el campo Custom Model; en Claude Code, la variable de entorno ANTHROPIC_MODEL o el flag --model; en OpenClaw, Cline y Continue.dev, el nombre del modelo en la config del proveedor; en LangChain y n8n, el parámetro model al inicializar el cliente. El instalador npx @joingonka/setup escribirá el gateway y el modelo actual en la config de la herramienta con un solo comando. La lista de modelos disponibles siempre está al día en el endpoint GET /v1/models — desde ahí es cómodo cargarla dinámicamente en la UI de tu aplicación, para que la salida o llegada de un modelo a la red no rompa tu producto.

Puedes probarlo sin registrarte en el chat gratuito de la página /try — ahí están disponibles los modelos activos de la red. Al registrarte en JoinGonka Gateway obtienes 3M tokens gratis para probar cualquier modelo de la red — suficiente para pasar tus tareas por cada uno de los tres y elegir el reemplazo con criterio.

Lo que la historia de Kimi K2.6 demostró para la red Gonka: el mecanismo DevShards funcionó en ambos sentidos. Permitió añadir modelos sin detener la red — tras Kimi llegaron MiniMax M2.7, DeepSeek V4 Flash y GLM-5.3 Flash — y también permitió retirar sin dolores un modelo que los hosts dejaron de mantener. Una red atada a un solo modelo es fundamentalmente frágil; una red capaz de cambiar su composición mediante votación evoluciona de forma suave y continua. Para el desarrollador, de esto se desprende una regla simple: no «elegir un modelo para siempre», sino mantener el nombre del modelo en la configuración y consultar la lista en vivo.