Para un equipo regulado, la pregunta rara vez es “qué modelo es el más inteligente”. Es “qué modelo podemos ejecutar donde se permite que residan nuestros datos, demostrar qué hizo y mantener en funcionamiento cuando un proveedor cambia una política”. En esa prueba, los modelos de pesos abiertos se ganan un lugar en el stack: tú tienes los pesos, fijas la versión y los sirves dentro de tu propio perímetro. No son la opción correcta para todos los flujos de trabajo. Esta es una guía práctica sobre dónde encajan, cómo ejecutarlos y la regla de decisión que te mantiene honesto.
¿Qué significa realmente “pesos abiertos” y en qué se diferencia del código abierto?
Los dos términos se usan de forma intercambiable en el marketing y no deberían. La distinción no es pedante: cambia tu revisión legal.
Pesos abiertos significa que el proveedor publica los parámetros del modelo entrenado (los pesos). Puedes descargarlos, ejecutar inferencia en tu propio hardware y, por lo general, ajustarlos. Lo que normalmente no obtienes es el conjunto de datos de entrenamiento completo, el pipeline de procesamiento de datos o el código de entrenamiento completo. Puedes usar el modelo, pero no puedes reproducirlo por completo.
Código abierto, en sentido estricto, es un listón más alto. En octubre de 2024 la Open Source Initiative publicó la Definición de IA de código abierto (OSAID 1.0), que exige que un sistema de IA conceda cuatro libertades (usar, estudiar, modificar, compartir) “para cualquier propósito y sin tener que pedir permiso”. Para cumplir, un proveedor debe publicar no solo los pesos sino también “información suficientemente detallada sobre los datos usados para entrenar el sistema de modo que una persona cualificada pueda construir un sistema sustancialmente equivalente” y “el código fuente completo usado para entrenar y ejecutar el sistema”. La mayoría de los modelos “abiertos” populares no cumplen ese listón.
El ejemplo más claro es Llama. La OSI y la Free Software Foundation han declinado clasificarlo como código abierto. La Licencia Comunitaria de Llama 3.1 es una licencia comercial personalizada, no una aprobada por la OSI: lleva una Política de Uso Aceptable, un requisito de atribución (“Built with Meta Llama”) y una restricción de campo de uso (las empresas con más de 700 millones de usuarios activos mensuales deben solicitar una licencia separada a Meta). Esas restricciones son comercialmente razonables, pero infringen la libertad de “cualquier propósito, sin permiso” de la OSI, que es exactamente la razón por la que Llama es de pesos abiertos y no de código abierto.
Otros lanzamientos se sitúan en lugares distintos. Mistral y Qwen, de Alibaba, mezclan lanzamientos permisivos con Apache 2.0 con otros bajo licencia personalizada, así que hay que leer cada ficha de modelo. Y en agosto de 2025, OpenAI publicó gpt-oss-120b y gpt-oss-20b bajo Apache 2.0, sus primeros modelos de pesos abiertos desde GPT-2. La lección para un equipo regulado es sencilla: no asumas la licencia a partir de la etiqueta. Léela por cada modelo, porque la licencia determina lo que tu equipo legal tiene que aprobar.
¿Por qué preferiría un equipo regulado los pesos abiertos?
El argumento a favor de los pesos abiertos en un entorno regulado no tiene que ver con el coste ni con la ideología. Tiene que ver con el control, y se corresponde directamente con las preocupaciones que plantea una revisión de seguridad.
- Residencia y el perímetro. Cuando sirves los pesos tú mismo, el prompt, el documento y la respuesta nunca salen de tu entorno. No hay transferencia a un tercero que justificar bajo el RGPD, ni una API externa en tu ruta de datos. Esta es la base de mantener la IA dentro del perímetro de confianza.
- Fijación de versión. Un modelo de frontera alojado puede quedar obsoleto o actualizarse de forma silenciosa. Un checkpoint de pesos abiertos que has descargado no cambia por debajo de ti. Tú decides cuándo actualizar y vuelves a ejecutar tus evaluaciones antes de hacerlo. Para un flujo de trabajo que tiene que comportarse de forma idéntica a lo largo de un periodo de auditoría, un checkpoint local fijado es un control real, no una preferencia.
- Sin ambigüedad sobre retención o uso para entrenamiento. Cuando la inferencia se ejecuta en tu hardware, no hay duda sobre si los prompts se registran, se retienen o se usan para entrenar un modelo futuro. La respuesta es estructural: no lo hacen, porque nunca salieron.
- Despliegue aislado (air-gapped) y soberano. Algunos entornos (defensa, ciertas infraestructuras críticas) no tienen ninguna ruta de salida a internet. Allí, una API alojada no es una opción y un modelo de pesos abiertos servido localmente es la única manera de tener IA capaz dentro del perímetro.
También hay un viento de cola regulatorio. Bajo la Ley de IA de la UE, los proveedores de modelos publicados bajo una licencia genuinamente libre y de código abierto obtienen un conjunto más reducido de obligaciones de transparencia que los proveedores de modelos cerrados (artículo 53(2)), aunque la política de derechos de autor y las obligaciones de resumen de los contenidos de entrenamiento siguen aplicando, y la exención decae para los modelos clasificados como de riesgo sistémico. Eso es un matiz del lado del proveedor, pero indica que el marco trata de forma diferente a los modelos genuinamente abiertos.
El mejor argumento a favor del proveedor de frontera es legítimo: una API gestionada te da la capacidad más reciente, el ajuste de seguridad y el escalado sin un equipo de MLOps. La preocupación legítima de la empresa lo es igual de: esa misma relación gestionada es justo lo que no controlas. Ambas cosas son ciertas. La cuestión es elegir por flujo de trabajo, no por empresa.
¿Cómo se sirve de forma privada un modelo de pesos abiertos?
Esta es la parte que antes era difícil y ahora es rutinaria. A principios de 2026, un pequeño número de motores de inferencia representa la gran mayoría del servicio de modelos abiertos en producción, y todos son de código abierto y autoalojables.
| Stack de servicio | Optimiza para | Buen encaje cuando | Notas |
|---|---|---|---|
| vLLM | Flexibilidad y rendimiento | La mayoría de equipos, la mayoría de modelos | Amplio soporte de modelos, intercambio de adaptadores en tiempo de ejecución, comunidad grande. La opción por defecto habitual. |
| TensorRT-LLM (NVIDIA) | Rendimiento máximo en GPU NVIDIA | Escala extrema, equipo de GPU dedicado | Requiere un paso de compilación por modelo y arquitecturas de GPU específicas. El rendimiento absoluto más alto, la complejidad más alta. |
| TGI (Hugging Face) | Simplicidad | Puestas en marcha rápidas | Ahora en modo de mantenimiento; la propia Hugging Face dirige a los usuarios hacia vLLM o SGLang. |
| Ollama / llama.cpp | Local y edge | Portátiles, nodos edge pequeños, prototipado | La barrera de entrada más baja, menor rendimiento. Bueno para desarrollo y trabajo en el propio dispositivo. |
Los benchmarks independientes de 2025 dan una idea de las diferencias de rendimiento. Una comparativa en un clúster 8xH100 situó a TensorRT-LLM, vLLM y TGI en ese orden en rendimiento con lotes grandes, con TensorRT-LLM el más alto y TGI el más bajo. La conclusión práctica no es la clasificación exacta, que cambia con el modelo, la precisión y el tamaño del lote. Es que vLLM te da la mayor parte del rendimiento con el menor dolor operativo, que es la razón por la que es el punto de partida recomendado para la mayoría de las empresas. Recurre a TensorRT-LLM solo cuando hayas medido una necesidad de rendimiento que justifique las restricciones de compilación y hardware.
¿Cómo de grande es la brecha de calidad y se está reduciendo de verdad?
Aquí es donde importa una documentación cuidadosa, porque la respuesta honesta es “más pequeña de lo que la mayoría de directivos asume, pero no nula, y se mueve”.
La medición más limpia procede de Epoch AI, que sigue la capacidad de los modelos en su Epoch Capabilities Index (ECI). Su análisis de octubre de 2025 encontró que, de media entre enero de 2023 y esa fecha, los modelos de pesos abiertos iban por detrás del estado del arte cerrado en torno a 3,5 meses (un intervalo de confianza del 90% de aproximadamente 1 a 5 meses), una brecha media de alrededor de 7 puntos ECI. Una actualización posterior situó la cifra más cerca de cuatro meses. Para anclarlo: Epoch señala que la brecha de ECI tiene un tamaño similar a la diferencia entre dos versiones recientes de una sola línea de modelos de frontera, no un abismo generacional.
La tendencia a más largo plazo es la historia más útil. El Stanford AI Index ha seguido cómo la ventaja del mejor modelo cerrado sobre el mejor modelo abierto se reducía desde dos dígitos en benchmarks de conocimiento en 2023 hacia un dígito bajo en 2026. El punto de inflexión que citan la mayoría de los analistas es el lanzamiento en enero de 2025 de DeepSeek-R1, un modelo de razonamiento de pesos abiertos que rindió cerca de la frontera cerrada a una fracción del coste, seguido de lanzamientos sólidos de Qwen, Llama y gpt-oss de OpenAI.
Dos matices mantienen esto honesto. Primero, estos son benchmarks agregados; tu flujo de trabajo no es un benchmark. Un modelo que encabeza MMLU todavía puede quedar por detrás en tu tarea específica de extracción de cláusulas legales o de resolución de reclamaciones. El único número que importa es cómo puntúa un modelo en tus evaluaciones, ejecutadas contra tus casos reales con trazas. Segundo, la brecha es desigual: tiende a ser menor en conocimiento y razonamiento y mayor en tareas agénticas de horizonte largo, uso de herramientas y las capacidades más nuevas, donde los laboratorios de frontera publican primero. Así que el encuadre correcto no es “los pesos abiertos han alcanzado a los cerrados”. Es “los pesos abiertos están lo bastante cerca como para que, en muchos flujos de trabajo regulados, el control que ganas pese más que los pocos puntos que cedes. Para otros, no, y deberías pagar por el modelo de frontera”.
Entonces, ¿cuál es la regla de decisión?
Mantenla concreta y aplícala por flujo de trabajo, no por organización. Ejecuta el modelo candidato (abierto o cerrado) contra tu propia batería de evaluación de casos reales con trazas, y luego sopesa la capacidad frente al control.
| Elige pesos abiertos cuando… | Elige un modelo de frontera aprobado cuando… |
|---|---|
| La residencia de datos o un entorno aislado (air-gapped) descarta una API externa | La tarea exige la cima de la frontera de capacidad y tus evaluaciones confirman que los pesos abiertos se quedan cortos |
| Necesitas una versión fijada e inmutable a lo largo de un periodo de auditoría | Careces de capacidad de MLOps para servir y mantener modelos, y el flujo de trabajo es de sensibilidad lo bastante baja para permitir una API |
| El flujo de trabajo es de alto volumen y sensible al coste (clasificación, extracción, enrutamiento, redacción) | El flujo de trabajo es de bajo volumen pero de altas implicaciones, donde unos pocos puntos de precisión justifican el sobrecoste y la sensibilidad de los datos es manejable |
| Tus evaluaciones muestran que el modelo abierto supera tu listón de calidad para esta tarea | Necesitas la capacidad agéntica o de uso de herramientas más nueva que los laboratorios de frontera publican primero |
Las dos columnas no son una división permanente. Un flujo de trabajo puede empezar en un modelo de frontera para salir rápido y luego pasar a un modelo de pesos abiertos una vez que tienes trazas contra las que evaluar y el volumen para justificar el autoservicio. Lo contrario también ocurre: un flujo de trabajo de pesos abiertos que alcanza un techo de capacidad se enruta a un modelo de frontera solo para los casos difíciles. Por eso importa el gateway agnóstico al modelo. Convierte el “qué modelo” de una apuesta arquitectónica de una sola vez en una decisión de enrutamiento que puedes revisar con evidencia.
Lo que no cambia es el perímetro. Sea cual sea el modelo que sirva una llamada dada, los prompts, documentos, embeddings, trazas y evaluaciones permanecen en tu entorno. Eso es lo que hace que la elección sea reversible y el rastro de auditoría quede intacto. Para los controles que mantienen todo esto unido, consulta nuestra postura de confianza y seguridad y la torre de control más amplia.
En resumen
Los modelos de pesos abiertos no son un compromiso presupuestario y no son una bala de plata. Son un mecanismo de control. Permiten a un equipo regulado conservar la versión, mantener los datos dentro del perímetro y eliminar a un tercero de la ruta de datos, a costa de unos pocos puntos de capacidad en las tareas más difíciles y de la responsabilidad de servirlos tú mismo. Haz la revisión de licencia primero, ejecuta tus propias evaluaciones después, enruta todo a través de un único gateway y deja que la evidencia (no el marketing) decida qué modelo sirve a qué flujo de trabajo. Para más sobre la elección de destinos de despliegue y dónde se permite que residan los datos, consulta Dentro del perímetro de confianza y nuestros otros análisis.
Preguntas frecuentes
¿Es un modelo de pesos abiertos lo mismo que un modelo de código abierto?
No. Pesos abiertos significa que el proveedor te da los parámetros entrenados para ejecutar y, normalmente, ajustar, pero típicamente no los datos de entrenamiento completos ni el código de entrenamiento. Código abierto, según la definición de 2024 de la OSI, exige uso para cualquier propósito sin permiso, además de información detallada sobre los datos y el código de entrenamiento completo. La mayoría de los modelos populares (incluido Llama) son de pesos abiertos bajo licencias personalizadas, no de código abierto. Lee siempre la licencia específica del modelo.
¿Son los modelos de pesos abiertos lo bastante buenos para sustituir a los modelos de frontera?
Para muchos flujos de trabajo regulados, sí; para los más difíciles, todavía no. A finales de 2025, Epoch AI midió que los mejores modelos de pesos abiertos iban por detrás del estado del arte cerrado en aproximadamente tres a cuatro meses, con brechas de un solo dígito en conocimiento y razonamiento. La respuesta honesta depende de la tarea, así que evalúa los candidatos contra tus propios casos con trazas en lugar de basarte en benchmarks públicos.
¿Cómo ejecutamos un modelo de pesos abiertos de forma privada?
Sírvelo con un motor de inferencia dentro de tu propio entorno. vLLM es el punto de partida habitual por su equilibrio entre rendimiento y simplicidad operativa; TensorRT-LLM ofrece mayor rendimiento en hardware NVIDIA a costa de más complejidad; Ollama y llama.cpp encajan para uso local y edge. Pon el motor que elijas detrás de un único gateway de IA de modo que la identidad, los presupuestos, la redacción y el registro se apliquen en un solo lugar.