El ruido alrededor de los modelos abiertos
Cuando un equipo directivo pregunta por primera vez por los LLMs open source, la conversación suele empezar con una promesa grande y una duda aún mayor. Los mitos circulan más rápido que la documentación técnica. Y las decisiones se toman, en muchos casos, con información de segunda mano. Este artículo no pretende vender la adopción de modelos abiertos, sino separar lo que se puede comprobar de lo que se repite sin evidencia.
Mito 1: «Lo open source es gratis»
El peso del modelo es descargable sin coste. Eso es cierto. Lo que no es gratis es todo lo que hace falta para que ese peso funcione de forma estable en producción. Los costes reales aparecen en cuatro frentes:
- Infraestructura: una GPU con memoria suficiente para servir un modelo de 70B con contexto largo no es un portátil. El alquiler por horas o la compra del hardware tienen un coste que se repite cada mes.
- Ingeniería: alguien tiene que montar el servidor de inferencia, ajustar el batching, monitorizar latencias y gestionar versiones del modelo.
- Evaluación: cada actualización del modelo o del prompt exige volver a medir calidad. Sin un banco de pruebas propio, se navega a ciegas.
- Mantenimiento: los repositorios de pesos y las librerías de inferencia evolucionan rápido. Lo que funcionaba hace seis meses puede requerir ajustes hoy.
En la práctica, el coste por token de un modelo abierto servido en propia infraestructura puede ser competitivo o incluso inferior al de una API cerrada, pero solo a partir de cierto volumen sostenido. Por debajo de ese umbral, la API suele ganar en coste total. Según documentación de proveedores de infraestructura cloud, la utilización media de las GPUs dedicadas a inferencia en empresas pequeñas rara vez supera el 30 %, lo que encarece cada token servido.
El error de contar solo el precio del token
Un patrón que se repite en equipos que dan el salto: comparan el precio por millón de tokens de la API con el precio por hora de la GPU y concluyen que el modelo abierto es más barato. Olvidan el coste de oportunidad del equipo de plataforma, las horas de integración y el tiempo dedicado a resolver incidencias. Un cálculo honesto incluye esas horas, aunque sea de forma aproximada.
Mito 2: «Si es abierto, mis datos están seguros por defecto»
Ejecutar el modelo en tu propia infraestructura elimina la salida de datos hacia un tercero, pero no convierte el sistema en seguro por arte de magia. La seguridad depende de cómo se despliega, no solo de dónde se ejecuta. Los puntos que suelen quedar fuera de la conversación inicial:
- Los registros de prompts y respuestas. Si se almacenan sin control, el dato sensible sigue expuesto, aunque el modelo sea local.
- El acceso al endpoint de inferencia. Sin autenticación y límites de uso, cualquiera dentro de la red puede consultar el modelo con los permisos del servicio.
- La cadena de suministro del modelo. Los pesos descargados de un repositorio público deben verificarse; un archivo corrupto o manipulado es un vector real.
- El filtrado de contenido. Un modelo abierto no trae por defecto las capas de moderación que un proveedor gestionado aplica en su API.
La ventaja de privacidad existe, pero es una condición necesaria, no suficiente. Requiere el mismo trabajo de gobierno de datos que cualquier otro sistema interno.
Mito 3: «Rinden peor que los modelos cerrados»
Aquí el matiz importa mucho, y generalizar es el error. En tareas de razonamiento complejo, matemáticas y código, los modelos cerrados de primera línea han mantenido durante buena parte de 2025 y principios de 2026 una ventaja en benchmarks públicos. Pero en tareas acotadas —clasificación de tickets, extracción de campos de un documento, resumen de conversaciones con formato fijo, generación de respuestas a partir de un contexto recuperado— los modelos abiertos de tamaño medio igualan o superan a modelos cerrados pequeños, con la ventaja de que puedes ajustarlos con tus propios datos.
Un caso concreto que ilustra bien la diferencia: una empresa de seguros que procesa partes de siniestros en PDF. Un modelo cerrado generalista cometía errores al extraer importes cuando el documento mezclaba tablas y texto libre. Tras hacer fine-tuning de un modelo abierto de 8B con 2.000 ejemplos anotados internamente, la precisión en ese formato específico subió de forma notable y el coste por documento se redujo. No porque el modelo abierto fuera mejor en general, sino porque estaba especializado en la distribución exacta de sus documentos. Ese es el terreno donde los modelos abiertos brillan.
Dónde no llegan (y conviene reconocerlo)
Un modelo abierto de 7B u 8B no va a resolver consultas que exijan razonamiento multi-paso sobre contextos de 200.000 tokens con la misma solidez que un modelo cerrado de gama alta. Tampoco es la opción natural para tareas creativas de largo alcance donde la coherencia estilística es crítica. Si tu caso de uso depende de eso, el modelo abierto no es la respuesta, y forzarlo genera frustración en el equipo y desconfianza en la tecnología.
Mito 4: «Basta con descargar el modelo y ya está»
La distancia entre descargar pesos y tener un servicio en producción es la parte que menos se documenta en los artículos introductorios. Los pasos intermedios incluyen:
- Elegir una librería de inferencia adecuada al hardware disponible.
- Definir el esquema de prompting y versionarlo junto al código.
- Montar una capa de recuperación (RAG) si el modelo necesita conocimiento actualizado de la empresa.
- Establecer métricas de calidad y un conjunto de evaluación representativo.
- Configurar límites de uso, colas y degradación controlada ante picos de demanda.
Según documentación oficial de las principales librerías de serving, el rendimiento por GPU varía mucho según la técnica de cuantización y el tamaño del lote. Un mismo modelo puede pasar de servir 10 peticiones por segundo a 40 según la configuración. Esa diferencia no aparece en la ficha del modelo; aparece al medir.
Mito 5: «El open source garantiza independencia total del proveedor»
Sustituir la dependencia de una API cerrada por la dependencia de un proveedor de GPU, de una librería de inferencia concreta o de un repositorio de pesos único no es independencia, es cambiar de dependencia. La libertad real llega cuando el equipo puede migrar el modelo sin reescribir la aplicación. Eso exige una capa de abstracción en el código, un formato de prompts portable y un banco de pruebas que permita comparar candidatos con el mismo criterio.
Las empresas que han hecho bien este paso suelen tener un catálogo interno de modelos evaluados, no un único modelo. Pueden cambiar de uno a otro según coste, latencia o calidad en una tarea concreta. El open source habilita esa flexibilidad; no la garantiza.
Realidad: cuándo tiene sentido y cuándo no
Después de ver varios despliegues, el patrón de decisión es bastante consistente:
Señales a favor
- Volumen alto y estable de inferencia que justifica la inversión en infraestructura.
- Datos que no pueden salir del perímetro por requisitos regulatorios o contractuales.
- Necesidad de especialización profunda en un dominio con datos propios etiquetados.
- Latencia crítica en entornos donde la red hacia un proveedor externo añade un salto inaceptable.
- Requisito de reproducibilidad: saber exactamente qué versión del modelo respondió qué.
Señales en contra
- Equipo sin perfil de plataforma o MLOps y plazos ajustados.
- Casos de uso muy variados que exigen un modelo generalista de máxima calidad.
- Volúmenes bajos o intermitentes donde la API cerrada sale más barata.
- Ausencia de datos propios para especializar: sin fine-tuning ni RAG, el modelo abierto compite en desventaja.
Una advertencia sobre las evaluaciones
Los benchmarks públicos son una referencia útil, pero no predicen el rendimiento en tu caso. Un modelo que lidera una tabla generalista puede quedar por debajo en la tarea concreta que te importa. La única medida fiable es construir un conjunto de evaluación con ejemplos reales de tu negocio, anonimizados si es necesario, y comparar candidatos con el mismo prompt y el mismo criterio de corrección. Sin ese banco de pruebas, cualquier decisión sobre modelos abiertos se apoya en opiniones, no en datos.
Y conviene recordar una limitación que no desaparece: ningún modelo, abierto o cerrado, garantiza resultados. La calidad del sistema depende del dato, del diseño del prompt, de la evaluación continua y del criterio humano que revisa las salidas en los puntos críticos. El open source añade control y opciones; no sustituye el trabajo.
Perfiles verificables: Sitio web
Publicado el 25 de October de 2026. Última revisión: 25 de October de 2026.