Kimi K3 vs K2: qué cambió y si conviene migrar ya

En cuanto aterrizó Kimi K3 de Moonshot, la mayoría de los equipos que ya usaban K2 / K2.x tuvieron la misma primera reacción: ¿vale la pena migrar? La respuesta no es «actualizar sin pensar», sino que depende de si tu caso de uso realmente aprovecha las nuevas capacidades de K3 y de si puedes asumir su precio de salida más alto. A continuación desplegamos ambas generaciones lado a lado y damos un veredicto por escenario.

Ambas generaciones en una tabla

Dimensión	Kimi K2 / K2.x	Kimi K3
Ventana de contexto	256K tokens	1M (1 048 576) tokens
Visión	Ninguna / externa	Visión nativa (imagen + vídeo)
Razonamiento	K2-thinking como modelo aparte	Razonamiento siempre activo, controlado con reasoning_effort
Arquitectura	MoE, ~1T de parámetros	MoE 2.8T, 896 expertos, 16 activados
Atención	Atención MoE estándar	KDA + Attention Residuals
Eficiencia de escalado	Base	~2.5× frente a K2
Precio de salida (ref. oficial)	~¥8–16 / 1M	¥100 / 1M

En qué gana K3 de verdad

El contexto salta de 256K a 1M. Es la mejora más tangible. Una base de código mediana entera, un contrato largo completo o decenas de páginas de PDF ahora caben en una sola petición de un turno, sin tener que trocear con esfuerzo ni montar RAG. La diferencia se nota especialmente en los agentes de largo alcance que ejecutan cadenas largas de llamadas a herramientas y mantienen historiales extensos.

La visión nativa pasa a ser ciudadana de primera clase. En la era de K2, ver imágenes implicaba básicamente OCR externo o llamar a otro modelo de visión; K3 ingiere imágenes y vídeo directamente, así que tareas como «montar el frontend a partir de este mockup» o «editar código desde una captura de un juego / CAD» tienen soporte nativo. Ten en cuenta que la entrada visual debe usar un array de objetos vía base64 o una referencia de archivo ms:// — no admite URLs públicas de imágenes.

El razonamiento está activo por defecto. Con K2, pensar en profundidad significaba cambiar a un modelo dedicado como kimi-k2-thinking; K3 integra el razonamiento en el modelo principal y ajusta la intensidad con reasoning_effort (por ahora solo max), de modo que el razonamiento complejo y la planificación multipaso funcionan de fábrica.

La eficiencia de la nueva arquitectura. Un MoE de 2.8T combinado con KDA (Kimi Delta Attention) + Attention Residuals ofrece, según Moonshot, alrededor de 2.5× la eficiencia global de escalado de K2 — dicho de otro modo, el mismo presupuesto de cómputo entrena / sirve de forma más económica, y eso es justo lo que le da margen para llevar el contexto a 1M.

El coste: el precio de salida es notablemente más alto

K3 se posiciona como buque insignia, y su precio lo es también. En el precio de referencia oficial, la salida llega hasta ¥100 / 1M, y la entrada cuesta ¥20 con fallo de caché y ¥2 con acierto. Frente al precio de salida de unos pocos yuanes de la serie K2, la brecha de coste es grande en escenarios de puro volumen. La ventaja: K3 activa la caché de contexto por defecto, así que los system prompt largos y los documentos fijos llamados repetidamente pueden comprimir la entrada hasta una décima parte — con lo que los agentes de largo alcance salen beneficiados. Los precios fluctúan constantemente, así que consulta la tarifa en tiempo real antes de contratar — el precio unitario en tiempo real de toda la gama Kimi en GetModel está en la página de precios.

Veredicto por escenario: cuál usar

Quédate en K2 / K2.x si:

• Tareas generales de puro volumen y alta concurrencia (clasificación, extracción, reescritura, atención al cliente) donde no necesitas el techo máximo de capacidad — el precio unitario de K2 es mucho más bajo;
• El contexto rara vez supera los 256K y no necesitas visión;
• El coste es una restricción dura.

Actualiza a K3 si:

• Necesitas tragarte una base de código entera / documento ultralargo de una vez, y 256K ya te queda justo;
• Tienes necesidades de código a partir de imágenes / multimodalidad (frontend, juegos, CAD, reproducción de mockups);
• Ejecutas agentes de largo alcance que requieren razonamiento potente y estabilidad con historiales extensos;
• Tus prompts son muy repetitivos, así que los descuentos de caché entran en juego y diluyen el precio de buque insignia.

El punto medio pragmático: ten una única pasarela de agregación con K2 y K3 conectados a la vez — envía las tareas baratas a K2, las difíciles a K3, y cambia en el código modificando solo el campo model. Con una interfaz de agregación como GetModel, una sola clave te permite repartir libremente entre ambas generaciones, y de paso comparar con GPT y Claude.

Claves de la migración (K2 → K3)

Si de verdad actualizas, esquiva tres trampas en el código:

• Elimina el parámetro thinking — K3 usa en su lugar reasoning_effort (por ahora solo max);
• En multiturno / llamadas a herramientas, devuelve el assistant message completo tal cual — no dejes solo content;
• El presupuesto de contexto es 4× mayor, pero no lo llenes a ciegas — cuanto más largo, más caro y lento.

Para el código de integración completo, ejemplos de curl / Python y resolución de errores, consulta el tutorial de integración de la API de Kimi K3. Para usar K2, K3 y modelos de otros proveedores desde una sola base de código, lo más sencillo es empezar obteniendo una clave en el panel de GetModel.