En resumen
Un modelo de pesos abiertos acaba de subir hasta lo más alto de un ranking de inteligencia independiente, por delante de casi todos los modelos propietarios. Motivo suficiente para preguntarse si la API de un único proveedor sigue siendo realmente la única opción razonable para un proyecto serio.
La respuesta tiene dos partes. Sobre el papel, la brecha de capacidad se ha reducido a unos pocos puntos. Sobre el terreno, «pesos abiertos» no significa ni «open source» en el sentido clásico del término, ni «autoalojable», ni «gratis». Son tres afirmaciones distintas, y confundir las tres lleva a malas decisiones de arquitectura.
La brecha medida: unos pocos puntos, no un abismo
En el Artificial Analysis Intelligence Index v4.1, Kimi K3 (Moonshot AI) muestra una puntuación de 57. Es el primer puesto entre los modelos de pesos abiertos que recoge Artificial Analysis, de entre 98 modelos de esta categoría.
Contando todos los modelos, el puesto exacto depende del día en que se mire. El tech report de Moonshot, cuyas evaluaciones de terceros se detienen el 23 de julio, sitúa a K3 en el 4.º puesto de 580 modelos. La instantánea del ranking de Artificial Analysis registrada el 28 de julio para este artículo sitúa a K3 en el 7.º puesto. Entre ambas fechas, Claude Opus 5 salió al mercado y ocupa ahora varios de los puestos superiores: Opus 5 con esfuerzo max (61), Opus 5 con esfuerzo xhigh (60), Claude Fable 5 (60), GPT-5.6 Sol con esfuerzo max (59), Opus 5 con esfuerzo high (59), GPT-5.6 Sol con esfuerzo xhigh (58), y luego Kimi K3 (57). Nada que ver con una intención de Moonshot: el tech report simplemente se cerró la víspera del lanzamiento de Opus 5.
Lo que importa es la diferencia bruta. Entre Kimi K3 y la mejor entrada del ranking (Opus 5, esfuerzo max, 61) hay 4 puntos. Entre K3 y la mejor entrada de OpenAI (GPT-5.6 Sol, esfuerzo max, 59) hay 2 puntos. En un índice construido a partir de nueve evaluaciones agregadas, con un intervalo de confianza del 95 % inferior a ±1 punto según Artificial Analysis, una diferencia de 2 a 4 puntos se lee como una diferencia real pero menor, no como un salto generacional.
«Pesos abiertos» no es ni «open source» ni «gratis»
Es el punto peor entendido del tema. Tres barreras distintas separan un modelo de pesos abiertos de un modelo realmente listo para adoptarse sin condiciones.
La licencia
La Kimi K3 License, publicada en el repositorio oficial, no es MIT ni una variante de MIT. En Hugging Face, el campo license de la ficha del modelo muestra además literalmente other. Se aplican dos cláusulas comerciales muy reales: por encima de 20 millones de dólares de facturación agregada en 12 meses consecutivos en Model-as-a-Service, se vuelve obligatorio un acuerdo aparte con Moonshot AI; por encima de 100 millones de usuarios activos mensuales o de 20 millones de dólares de ingresos mensuales, el nombre «Kimi K3» debe aparecer de forma visible en la interfaz del producto.
Otros modelos abiertos de primer nivel no imponen ninguna de estas dos condiciones.
| Modelo | Proveedor | Licencia | Restricción comercial |
|---|---|---|---|
| Kimi K3 | Moonshot AI | Kimi K3 License (licencia propia) | Acuerdo aparte por encima de 20 M$ de facturación en MaaS/12 meses; atribución visible por encima de 100 M MAU o 20 M$/mes |
| GLM-5.2 | Z.ai | MIT | Ninguna |
| DeepSeek-V4-Pro / V4-Flash | DeepSeek | MIT | Ninguna |
| Qwen3.5 | Alibaba / Qwen | Apache 2.0 | Ninguna |
| Mistral Medium 3.5 | Mistral AI | Modified MIT | No detallada en las fuentes consultadas |
MiniMax M2.5 y Mistral Large 3 sí publican pesos abiertos, pero el texto exacto de su licencia no se ha podido verificar para este artículo: hay que confirmarlo antes de cualquier uso comercial.
El hardware
Los pesos de Kimi K3 pesan alrededor de 1,56 TB, repartidos en 96 archivos safetensors. La documentación oficial de vLLM, el motor recomendado por Moonshot, exige un mínimo de 8 GPU GB300 para desarrollo, con un despliegue multinodo recomendado en producción; en el lado de ROCm, hacen falta al menos 8 GPU MI355X o MI350X. No existe soporte upstream en llama.cpp al 28 de julio de 2026: una discusión comunitaria abierta en el repositorio oficial del proyecto enumera los bloqueos técnicos pendientes, entre ellos una arquitectura que el código todavía no reconoce.
Dicho de otro modo: este modelo no es autoalojable por ninguna pyme. El billete de entrada se cuenta en clústeres de centro de datos, no en un servidor de sobremesa.
La operación
Cargar un modelo es solo el primer paso. Kimi K3 se entrega nativamente cuantizado (pesos MXFP4, activaciones MXFP8, quantization-aware training aplicado ya desde el SFT), lo que simplifica el despliegue frente a una cuantización posterior improvisada. Queda después elegir un motor de inferencia entre los tres recomendados (vLLM, SGLang, TokenSpeed), seguir las actualizaciones de ese motor, gestionar la disponibilidad y el failover de un clúster de GPU, y vigilar el rendimiento en el tiempo. No es un trabajo puntual, es una carga operativa continua, comparable a la que un proveedor de API ya absorbe por ti.
El cálculo económico real
Aquí es donde la relación de fuerzas realmente se invierte. El argumento de los modelos abiertos en 2026 casi nunca es el autoalojamiento: es el precio de la API y la independencia frente a un proveedor único.
| Modelo | Entrada ($/MTok) | Salida ($/MTok) |
|---|---|---|
| Kimi K3 (cache miss) | 3,00 | 15,00 |
| Claude Opus 5 | 5,00 | 25,00 |
| Claude Fable 5 | 10,00 | 50,00 |
Esta tarifa es casi la mitad de barata que Opus 5 y más de tres veces más barata que Fable 5, para una diferencia de unos pocos puntos en el índice de inteligencia. El tech report de Moonshot, con las tarifas de Artificial Analysis del 23 de julio (por tanto, antes del lanzamiento de Opus 5: las comparaciones siguientes se refieren a Opus 4.8 y Fable 5), cifra la relación calidad-precio con precisión: en Kimi Code Bench 2.0, K3 se queda 4 puntos por detrás de Fable 5 por un 38 % de su coste; con esfuerzo alto, K3 ya iguala la puntuación de Opus 4.8 con esfuerzo máximo por aproximadamente un tercio del coste. En BrowseComp, K3 obtiene la mejor puntuación de la tabla a 2,03 $ por tarea, es decir, la mitad del coste de GPT-5.6 Sol y un orden de magnitud menos que los modelos Claude con esfuerzo máximo. En GDPval-AA v2, K3 se mantiene a menos de 50 puntos de Elo de GPT-5.6 Sol por un 13 % menos de coste, y 2,6 veces más barato que Fable 5.
La segunda parte del argumento pesa igual: pasar una carga de trabajo a un modelo abierto servido por un segundo proveedor, o eventualmente autoalojado más adelante si el modelo se presta a ello, elimina la dependencia de un punto único de fallo. No es una cuestión de rendimiento bruto, es una cuestión de resiliencia de arquitectura.
Lo que aportan de más los modelos abiertos: la verificabilidad
El tech report de Kimi K3 documenta su arquitectura (atención híbrida Kimi Delta Attention y Gated MLA, MoE de 896 expertos, codificador de visión entrenado from scratch), su optimizador (Per-Head Muon, Quantile Balancing para el equilibrio de expertos) y su receta de post-entrenamiento completa: SFT, luego RL por dominio y por nivel de esfuerzo, luego destilación multi-teacher para fusionar los modelos expertos.
Los anuncios de los proveedores cerrados no hacen esto. El anuncio de Opus 5 presenta sus mejoras en forma de gráficos y expresiones relativas («duplica el rendimiento de Opus 4.8», «al 0,5 % de la mejor puntuación de Fable 5») sin detallar la receta de entrenamiento. Las system cards publican puntuaciones de seguridad y evaluaciones de riesgo con detalle, lo cual tiene su valor, pero ni Anthropic ni OpenAI publican un optimizador, un esquema de paralelismo o una curva de scaling law comparables a lo que Moonshot pone sobre la mesa. Esta es la verdadera diferencia estructural: un proveedor cerrado publica puntuaciones, un modelo abierto publica un método que se puede auditar, reproducir en parte, y criticar en el fondo.
El caso de la ciberseguridad
Este terreno ilustra un dilema real, sin respuesta evidente en un sentido ni en otro.
Los modelos de Anthropic y de OpenAI rechazan las tareas de desarrollo de exploits, lo que los excluye mecánicamente de las comparaciones numéricas sobre este tema. El tech report de Kimi K3 documenta su propia evaluación en una suite interna de 36 tareas ofensivas (16 en espacio de usuario, 20 en núcleo Linux, unas 540 horas-experto en total): K3 resuelve 14 de 36, frente a 8 de 36 de GLM-5.2. Una evaluación independiente conjunta del UK AI Security Institute y del NIST CAISI confirma que K3 supera a GLM-5.2 en desarrollo de exploits (32 % frente a 24 % en ExploitBench), pero no logra ejecución de código arbitrario en ninguna de las 41 tareas probadas, lejos de los modelos de frontera realmente capaces en este terreno.
En el lado cerrado, la lógica es inversa: los clasificadores de seguridad de Opus 5 bloquean la generación de exploits y el pentest a nivel de API, con una activación esperada un 85 % menos frecuente que en Fable 5; las barreras de ciberseguridad de GPT-5.6 Sol bloquean, según OpenAI, unas diez veces más actividad potencialmente dañina que los modelos anteriores.
El punto estructural que hay que retener: una barrera impuesta por un proveedor de API se aplica a cada solicitud, en todos los clientes, sin excepción posible por parte del usuario. Un modelo de pesos abiertos no tiene ninguna barrera imponible a distancia una vez descargado: nada impide a un usuario hacer fine-tuning del modelo para eliminar un comportamiento de rechazo. No es ni un argumento a favor ni un argumento en contra de la apertura: es una decisión de diseño que cada organización debe zanjar por sí misma según su uso real, no según una posición de principio.
Cuándo elegir qué
El techo de capacidad no es negociable
Razonamiento de frontera, codificación agéntica compleja, presupuesto que no es el criterio principal: un modelo cerrado (Opus 5, GPT-5.6 Sol) mantiene de 2 a 4 puntos de ventaja en el índice de inteligencia, con el soporte y las barreras del proveedor incluidos.
El coste por tarea o la independencia de proveedor son prioritarios
Kimi K3 vía su API oficial cuesta menos de la mitad del precio de Opus 5 tanto en entrada como en salida, para una diferencia de capacidad medida en puntos, no en generaciones. Es el argumento más sólido a favor de los modelos abiertos hoy en día, no el autoalojamiento.
El autoalojamiento se contempla realmente
Olvídate de los modelos de clase frontera como K3: 1,56 TB de pesos y un clúster GB300 no están al alcance de ninguna pyme. Si el objetivo es hacer funcionar un modelo en tu propia infraestructura, mira hacia los modelos abiertos de tamaño razonable (Qwen3.5 27B en Apache 2.0, por ejemplo), no hacia los modelos de 2,8 T de parámetros.
El flujo de trabajo toca la seguridad ofensiva
Los modelos cerrados rechazan por construcción el desarrollo de exploits. Un modelo abierto levanta esa barrera, lo que sirve tanto a la investigación defensiva legítima como a usos menos recomendables. Decide conscientemente, no dejes que esta elección se haga por defecto por no haber comprobado las barreras del modelo que conectas.
Próximos pasos
- Kimi K3: el primer modelo abierto de clase 3T, y lo que cambia de verdad: la identidad completa del modelo, su licencia en detalle y su arquitectura
- Opus 5 frente a los nuevos GPT: la comparativa numérica del lado de los modelos cerrados
- Costes reales de Claude Code: poner las tarifas de esta comparativa frente a tu uso diario
- Buenas prácticas de seguridad: las preguntas que hay que hacerse antes de conectar un nuevo modelo a flujos de trabajo sensibles