La pregunta ya no es si un modelo abierto puede competir con uno propietario, sino en qué tareas concretas lo hace y a qué coste real. Durante 2025 muchos equipos migraron parte de su stack de IA a pesos descargables y descubrieron dos cosas: que el ahorro en API no siempre compensa el coste de infraestructura, y que la licencia importa más de lo que parece cuando el producto sale a producción.
Aquí no encontrarás un ranking plano. Encontrarás qué familias de modelos abiertos están dando resultados defendibles, dónde se quedan cortas frente a los de pago y cómo decidir con criterios que sobrevivan al próximo lanzamiento.
El mapa real: qué significa «open source» en modelos de lenguaje
Antes de comparar conviene desmontar una ambigüedad que genera decisiones equivocadas. Casi ningún modelo llamado abierto cumple la definición estricta de la OSI. Lo habitual es encontrar pesos descargables con licencias de uso comunitario que imponen restricciones: límites de usuarios mensuales, prohibición de uso competitivo, obligación de mostrar el nombre del modelo en la interfaz o cláusulas de escalado comercial.
Esto tiene una consecuencia práctica: un modelo puede ser gratis para prototipar y caro —legalmente— al crecer. La familia Llama es el ejemplo clásico de licencia con umbral de usuarios; Qwen y DeepSeek publican buena parte de sus pesos bajo Apache 2.0, lo que facilita la integración comercial sin fricción legal; Mistral combina licencias Apache en sus modelos pequeños con licencias de investigación en los grandes. Antes de elegir por benchmarks, revisa la licencia del modelo concreto que vas a desplegar, no la del repositorio en general.
Modelos abiertos que merecen una prueba en 2025
Llama (Meta) sigue siendo el estándar de facto del ecosistema. Su ventaja no es el rendimiento bruto sino la madurez del tooling: cuantizaciones listas, soporte en Ollama, vLLM y llama.cpp, y una comunidad que resuelve dudas rápido. La variante de 8B es un caballo de batalla para clasificación, extracción y resúmenes; los tamaños mayores compiten en razonamiento pero exigen hardware que rara vez está en el escritorio de un desarrollador.
Qwen ha ganado terreno en tareas multilingües y de código. Sus versiones pequeñas sorprenden en generación de SQL y en comprensión de instrucciones con formato estricto, y la licencia Apache en muchos de sus pesos elimina el debate legal. En pruebas de extracción de datos estructurados desde texto desordenado, un modelo Qwen de tamaño medio suele bastar donde un modelo propietario grande sería sobredimensionado.
DeepSeek ha demostrado que un laboratorio con menos recursos puede publicar modelos competitivos en razonamiento matemático y código. La contrapartida es la opacidad sobre los datos de entrenamiento y la necesidad de validar sesgos en dominios regulados.
Mistral mantiene una propuesta europea con buenos resultados en tareas de instrucción y una comunidad activa en torno a sus formatos de cuantización.
Gemma (Google) ofrece pesos abiertos con un enfoque conservador en seguridad, útil cuando necesitas un modelo que no genere contenido problemático por defecto, aunque su licencia también tiene condiciones de uso.
Dónde el modelo abierto gana sin discusión
Hay escenarios donde la comparación ni siquiera tiene sentido porque el propietario no puede ofrecer lo que necesitas.
Datos que no pueden salir de tu infraestructura
Si procesas historiales clínicos, expedientes legales o datos personales bajo normativa estricta, enviar prompts a una API externa exige un análisis de riesgos que muchos equipos jurídicos no aprueban. Un modelo abierto ejecutado en local elimina la transferencia de datos. No elimina la responsabilidad: sigues necesitando registrar qué modelo usaste, con qué versión y qué prompts, porque la trazabilidad también es una obligación.
Volumen alto y predecible
Cuando tu carga es constante y el modelo cabe en una GPU que ya tienes, el coste marginal por token tiende a cero. Un caso típico: clasificar miles de tickets diarios en categorías fijas. Un modelo de 7-8B cuantizado a 4 bits corre en una GPU de consumo y hace esa tarea con una precisión que, tras un ajuste fino ligero con ejemplos propios, iguala a modelos propietarios mucho mayores en ese dominio estrecho. La clave es que la tarea sea acotada; si necesitas razonamiento abierto, el cálculo cambia.
Latencia controlada y sin dependencia de terceros
Para aplicaciones interactivas donde 300 ms de más arruinan la experiencia, o para productos que no pueden permitirse una caída del proveedor, el despliegue propio da control. También da la obligación de monitorizarlo, algo que muchos equipos subestiman.
Dónde el modelo de pago sigue siendo la opción sensata
La honestidad obliga a decirlo: en razonamiento complejo de varios pasos, en seguimiento de instrucciones largas y en tareas que requieren contexto de cientos de miles de tokens, los modelos propietarios de frontera mantienen ventaja. Un modelo abierto de tamaño medio puede escribir una función correcta; pedirle que razone sobre un repositorio entero y proponga una refactorización coherente suele producir resultados frágiles.
También hay un factor que rara vez aparece en las comparativas: el coste de mantenimiento. Elegir un modelo abierto implica versionar pesos, gestionar actualizaciones, montar evaluación continua y asumir que un día la comunidad deja de mantener la cuantización que usas. Ese trabajo tiene un precio en horas de ingeniería que, en equipos pequeños, supera el gasto en API durante meses.
Un error común que he visto repetirse
Equipos que migran a un modelo abierto porque en un benchmark público saca buena puntuación y luego descubren que su caso de uso concreto —por ejemplo, extraer campos de facturas escaneadas con plantillas heterogéneas— falla sistemáticamente. El benchmark medía razonamiento general, no la capacidad de respetar un esquema JSON con campos anidados y valores nulos. La lección: monta un conjunto de evaluación con 50-100 ejemplos reales de tu dominio antes de decidir. Si el modelo abierto no supera ese test, el ahorro es ficticio.
Cómo comparar sin caer en el ruido de los rankings
Los leaderboards cambian cada semana y mezclan tareas que no se parecen. Un enfoque más útil es construir tu propia matriz de decisión con cuatro ejes:
- Licencia y cumplimiento: ¿permite uso comercial sin umbrales? ¿exige atribución? ¿qué pasa si superas cierto volumen?
- Encaje en hardware: ¿cabe en tu GPU con la cuantización que necesitas? ¿qué throughput real obtienes con vLLM o llama.cpp?
- Calidad en tu dominio: resultados en tu set de evaluación, no en MMLU.
- Coste total: API frente a infraestructura más horas de mantenimiento.
Un detalle técnico que marca diferencias y que se pasa por alto: la cuantización degrada unas tareas más que otras. La generación creativa aguanta bien 4 bits; el razonamiento matemático y la extracción precisa de datos sufren más. Probar la misma tarea con el modelo en fp16 y en cuantizado te dirá si el ahorro de VRAM justifica la pérdida.
Estrategia híbrida: lo que funciona en la práctica
La dicotomía gratis contra pago es engañosa. La arquitectura que más rendimiento da en proyectos reales combina ambos: un modelo abierto pequeño para el grueso del tráfico (clasificación, filtrado, resúmenes cortos, respuestas de FAQ) y un modelo propietario como respaldo para las consultas que el pequeño deriva por baja confianza. Este patrón reduce coste sin sacrificar calidad en los casos difíciles, y es más fácil de justificar ante negocio que una migración total.
También conviene recordar que «gratis» no existe en inferencia: alguien paga la electricidad, la GPU y el tiempo de quien mantiene el despliegue. La pregunta correcta no es cuál es gratis, sino cuál tiene un coste total menor para tu volumen y tu equipo.
Qué vigilar en los próximos meses
El ritmo de publicación de pesos abiertos no baja, y la brecha con los modelos de frontera se cierra en algunas tareas mientras se mantiene en otras. Dos frentes merecen atención: las licencias, que tienden a endurecerse cuando el modelo se vuelve popular, y las herramientas de evaluación, que siguen siendo el eslabón débil. Un modelo sin un buen sistema de evaluación propio es una caja negra con buena prensa.
Si tuviera que resumir el criterio: prueba modelos abiertos primero en tareas acotadas y medibles, reserva los propietarios para lo que exige razonamiento amplio, y no tomes ninguna decisión sin un set de evaluación construido con tus propios datos. Esa es la única comparativa que no caduca al mes siguiente.
Perfiles verificables: Sitio web
Publicado el 25 de October de 2026. Última revisión: 25 de October de 2026.