El mercado de los modelos de inteligencia artificial descargables ha cambiado lo suficiente como para que muchas empresas ya no necesiten recurrir siempre a una API propietaria. En julio de 2026 existen opciones capaces de ejecutarse en un portátil, una única GPU profesional o un clúster completo, pero la elección no debería basarse en el modelo que encabeza la última tabla publicada en redes sociales.

Las claves de los modelos de IA abiertos en 20 segundos

• Muchos modelos llamados abiertos publican sus pesos, pero no los datos ni todo el proceso de entrenamiento.
• Apache 2.0 y MIT suelen simplificar el uso comercial.
• Un modelo pequeño puede ofrecer mejor coste, velocidad y estabilidad.
• La decisión debe basarse en pruebas propias, hardware disponible, privacidad y licencia.

Los pesos pueden descargarse gratuitamente, pero eso no convierte la inferencia en gratuita. Ejecutar un modelo exige memoria, capacidad de cálculo, almacenamiento, electricidad, personal técnico y un sistema capaz de atender a varios usuarios sin degradar la respuesta.

También importa qué se intenta resolver. Un asistente interno para consultar documentación no necesita necesariamente el mismo modelo que un agente encargado de modificar repositorios, interpretar imágenes o resolver problemas matemáticos. Elegir el modelo más grande por defecto suele trasladar el gasto de la API al centro de datos sin demostrar una mejora proporcional.

Abierto no significa siempre código abierto

La expresión «modelo de código abierto» se utiliza con demasiada facilidad. En muchos casos, el fabricante permite descargar los parámetros entrenados, ejecutar el modelo y adaptarlo, pero no publica los datos utilizados, el código completo de entrenamiento, los criterios de filtrado ni los puntos de control intermedios.

La Open Source Initiative (OSI) considera que un sistema de IA abierto debe permitir usarlo, estudiarlo, modificarlo y compartirlo. Para ejercer esas libertades también debería existir información suficiente sobre los datos, el código empleado para entrenar y ejecutar el sistema y los parámetros resultantes. Bajo esa definición, buena parte de los modelos populares son realmente modelos de pesos abiertos.

La distinción no es únicamente académica. Una empresa puede descargar un modelo y tener permiso para usarlo comercialmente, aunque no sea capaz de reproducir su entrenamiento. Para muchos proyectos eso será suficiente, pero no ofrece el mismo grado de transparencia que una publicación completa.

OLMo 3, desarrollado por el Allen Institute for AI, representa una de las propuestas más abiertas. El proyecto publica pesos, conjuntos de datos, herramientas de limpieza, código de entrenamiento, evaluaciones y artefactos de las distintas fases. Su familia incluye variantes de 7.000 y 32.000 millones de parámetros orientadas a uso general, conversación y razonamiento.

La licencia debe comprobarse antes de integrar cualquier modelo en un producto. Apache 2.0 y MIT permiten normalmente utilizar, modificar y distribuir el software con pocas restricciones, además de ofrecer cláusulas claras sobre atribución y patentes. Las licencias propias pueden incorporar límites territoriales, condiciones para grandes plataformas, políticas de uso o restricciones sobre el entrenamiento de modelos competidores.

Incluso dentro de una misma familia pueden convivir modelos con condiciones diferentes. No basta con saber que «Qwen es abierto» o que «Mistral permite descargar sus modelos». Hay que revisar la licencia exacta de la versión, el repositorio del que procede y las condiciones asociadas al despliegue.

Los modelos que cubren cada nivel de hardware

La parte alta del mercado está dominada por arquitecturas de mezcla de expertos, conocidas como MoE. Estos modelos contienen cientos de miles de millones de parámetros, pero solo activan una fracción para procesar cada token. Esto reduce el cálculo respecto a un modelo denso del mismo tamaño, aunque no elimina la necesidad de almacenar los pesos ni simplifica automáticamente el despliegue.

GLM-5.2, de Z.ai, es uno de los modelos más ambiciosos disponibles con licencia MIT. Ofrece una ventana de contexto de un millón de tokens y está orientado a programación, agentes y trabajos prolongados. Esa capacidad permite introducir grandes repositorios o colecciones documentales, aunque el contexto anunciado no garantiza que el modelo aproveche con la misma precisión toda la información situada dentro de la ventana.

DeepSeek-V3.2 mantiene una posición destacada en razonamiento y uso de herramientas. Su repositorio publica los pesos bajo licencia MIT y emplea un mecanismo de atención dispersa pensado para reducir el coste de los contextos largos. Sus 685.000 millones de parámetros lo sitúan lejos de una instalación doméstica convencional, por lo que normalmente se ejecutará en infraestructura especializada o mediante un proveedor.

Mistral Large 3 utiliza 675.000 millones de parámetros totales y activa alrededor de 41.000 millones. Mistral lo distribuye bajo Apache 2.0 y ofrece formatos comprimidos, pero su propia documentación sitúa el despliegue en sistemas de clase Blackwell o en nodos con ocho GPU A100 o H100. No es un modelo para instalar en cualquier servidor sobrante.

OpenAI también participa en este segmento con gpt-oss-120b y gpt-oss-20b, publicados bajo Apache 2.0. El primero está diseñado para funcionar en una GPU con 80 GB de memoria, mientras que la versión de 20.000 millones puede ejecutarse dentro de unos 16 GB mediante su cuantización MXFP4. Esa segunda variante resulta más accesible para estaciones de trabajo y equipos de gama alta.

Qwen3.6-35B-A3B ocupa un espacio intermedio. Aunque contiene unos 35.000 millones de parámetros, activa una cantidad menor por token y admite texto e imágenes. Alibaba lo distribuye bajo Apache 2.0, lo que lo convierte en una alternativa atractiva para organizaciones que quieren un modelo multimodal adaptable sin asumir las necesidades de los gigantes de varios cientos de miles de millones de parámetros.

Google ha diseñado Gemma 4 para cubrir desde dispositivos móviles hasta ordenadores personales. La familia incluye variantes E2B y E4B centradas en eficiencia, además de modelos de 12.000, 26.000 y 31.000 millones de parámetros para razonamiento y cargas multimodales. Google también ha publicado versiones preparadas mediante entrenamiento consciente de cuantización para reducir el consumo de memoria.

Microsoft mantiene la familia Phi para situaciones en las que el tamaño y la ejecución local pesan más que obtener el máximo resultado en una prueba general. Phi-4-mini cuenta con 3.800 millones de parámetros, amplía el soporte multilingüe e incorpora llamadas a funciones. Microsoft publica la familia con licencia MIT y la orienta a aplicaciones locales y dispositivos sin conexión permanente con la nube.

Mistral ofrece también Ministral 3 en tamaños de 3.000, 8.000 y 14.000 millones de parámetros. Estas versiones incluyen comprensión de imágenes y variantes preparadas para instrucciones o razonamiento, todas ellas bajo Apache 2.0. Cubren aplicaciones en estaciones de trabajo, sistemas periféricos y dispositivos en los que un modelo de gran tamaño no tendría sentido económico.

Este abanico muestra por qué ya no existe un único modelo abierto recomendable para todo. Los modelos pequeños pueden responder con menos latencia, atender a más usuarios por GPU y resultar más fáciles de actualizar. Los grandes aportan más capacidad en trabajos complejos, pero obligan a invertir en infraestructura, paralelización y sistemas de inferencia especializados.

Cómo elegir sin convertir el ahorro en otro coste

El primer paso consiste en definir una prueba real. Un equipo que quiera resumir contratos debería preparar documentos representativos, preguntas esperables y respuestas revisadas por especialistas. Quien busque un modelo para programación necesita repositorios propios, incidencias reales, pruebas automáticas y tareas que obliguen a comprender varios archivos.

Los resultados publicados por los fabricantes sirven para elaborar una lista inicial, pero no sustituyen esa evaluación. Un modelo puede destacar en SWE-bench y fallar al seguir las convenciones de una base de código concreta. Otro puede obtener buenos resultados en inglés y perder precisión al redactar en castellano o trabajar con terminología jurídica.

La evaluación debería medir calidad, latencia, tokens generados por segundo, memoria utilizada, coste por consulta y porcentaje de respuestas que requieren corrección. También conviene comprobar el seguimiento de instrucciones, la estabilidad del formato JSON, las llamadas a herramientas y la tendencia a inventar datos.

La longitud del contexto merece una prueba independiente. Cargar un millón de tokens puede ser técnicamente posible y, al mismo tiempo, resultar lento, caro o poco preciso. En muchas aplicaciones funciona mejor un sistema de generación aumentada por recuperación (RAG) que seleccione únicamente los fragmentos relevantes antes de consultar al modelo.

La cuantización permite reducir el tamaño de los pesos utilizando formatos de menor precisión. Un modelo de 20.000 o 30.000 millones de parámetros puede pasar de requerir varias decenas de gigabytes a funcionar en una GPU de consumo, pero el ahorro puede afectar a la calidad, sobre todo en razonamiento, matemáticas y generación estructurada. Cada cuantización debe probarse como si fuera una versión diferente.

La privacidad local tampoco aparece de forma automática. Ejecutar los pesos en un servidor propio evita enviar las consultas al fabricante del modelo, pero la aplicación, el entorno de inferencia, las extensiones y las herramientas de observabilidad pueden seguir transmitiendo telemetría. La organización debe revisar toda la cadena.

Para experimentar en un ordenador personal, aplicaciones como Ollama y LM Studio reducen el trabajo inicial. En servidores, vLLM y SGLang permiten ofrecer interfaces compatibles con APIs conocidas, gestionar lotes y mejorar el aprovechamiento de las GPU. La herramienta adecuada dependerá del modelo, la arquitectura y la concurrencia esperada.

Cuando el volumen es irregular, una API alojada puede resultar más barata que mantener varias GPU encendidas. El alojamiento propio gana sentido cuando existe una carga constante, requisitos estrictos de privacidad, necesidad de adaptar el modelo o suficiente escala para amortizar el hardware.

El modelo tampoco debería quedar fijado para siempre. La velocidad de publicación obliga a separar la aplicación de la tecnología de inferencia mediante interfaces estables. De esta forma, una empresa puede comparar nuevas versiones o sustituir el modelo sin rehacer todo el producto.

La oportunidad de 2026 no consiste en descargar el modelo más grande disponible. Está en poder escoger entre familias abiertas, alojarlas donde convenga y cambiarlas cuando otra opción ofrezca mejor calidad o menor coste. Esa libertad solo produce ahorro cuando se acompaña de pruebas propias, revisión de licencias y una estimación completa de la infraestructura necesaria.

Preguntas frecuentes

¿Cuál es el mejor modelo abierto para ejecutar en un ordenador personal?

Depende de la memoria y de la tarea. Phi-4-mini, las versiones pequeñas de Gemma 4 y Ministral 3 son opciones ligeras, mientras que gpt-oss-20b o Qwen3.6 requieren equipos con más memoria y normalmente una cuantización adecuada.

¿Los modelos de pesos abiertos pueden utilizarse comercialmente?

Muchos sí, pero debe revisarse la licencia de cada versión. Apache 2.0 y MIT suelen permitir usos comerciales amplios, mientras que las licencias propias pueden añadir restricciones.

¿Descargar un modelo elimina el coste de utilizar IA?

No. Desaparece o se reduce el pago por API, pero siguen existiendo costes de GPU, electricidad, almacenamiento, administración, seguridad y mantenimiento.

¿Es mejor un modelo local que una API en la nube?

El modelo local ofrece más control sobre los datos y la configuración. Una API puede ser más sencilla y económica cuando el uso es bajo o variable. La decisión depende del volumen, la privacidad y los recursos técnicos disponibles.