Modelos abiertos frente a cerrados: cómo elegir para un proyecto real

El debate de "abierto frente a cerrado" suele plantearse como si fuera una cuestión de valores. En un proyecto real es una cuestión de compromisos: quién controla el modelo, dónde se ejecuta, cuánto cuesta a tu volumen y qué pasa cuando algo se rompe a las 2 de la madrugada. Tratada así, la decisión se vuelve abordable. Esta guía te da una forma de tomarla sin unirte a una tribu.

Primero, una aclaración que evita la mayor parte de la confusión. "Abierto" casi siempre significa pesos abiertos (open-weights): puedes descargar los parámetros del modelo y ejecutarlos tú mismo. Rara vez significa código abierto en el sentido estricto que define la Open Source Initiative, porque los datos de entrenamiento y el código de entrenamiento completo normalmente no se liberan. "Cerrado" significa que los pesos se quedan con el proveedor y tú accedes al modelo a través de una API alojada. Ambos pueden ser excelentes. Ninguno es automáticamente más seguro, más barato o más capaz.

Entre qué estás eligiendo realmente

Cuando eliges un modelo de pesos abiertos, asumes el modelo y la responsabilidad de ejecutarlo. Obtienes los parámetros, eliges el hardware, te haces dueño del tiempo de actividad, el escalado, el parcheo de seguridad y el camino de actualización. Cuando eliges una API cerrada, alquilas capacidad y entregas la carga operativa al proveedor. Cambias control por comodidad.

Ese único compromiso —control frente a comodidad— está debajo de casi todas las demás consideraciones. Tenlo en mente mientras lees el resto, porque la mayoría de los argumentos de "lo abierto es mejor" o "lo cerrado es mejor" son en realidad solo alguien ponderando el control y la comodidad de forma distinta a como deberías hacerlo para tu proyecto.

Control y residencia de datos

La razón más fuerte para ejecutar pesos abiertos es el control sobre adónde van los datos y cómo se comporta el sistema con el tiempo.

• Residencia de datos. Si tus entradas no pueden, legal o contractualmente, salir de tu infraestructura, un modelo que alojas tú mismo elimina la cuestión por completo. Nada se envía a un tercero. Para dominios regulados esto es a veces toda la decisión.
• Estabilidad de versión. Un modelo que alojas no cambia por debajo de ti. Un modelo alojado puede actualizarse, quedar obsoleto o retirarse según el calendario del proveedor, y un cambio silencioso de comportamiento puede romper un prompt cuidadosamente ajustado. El autoalojamiento congela el comportamiento hasta que tú eliges moverte.
• Uso sin conexión y aislado. Si el sistema debe ejecutarse sin acceso a internet, los pesos abiertos son en la práctica la única opción.

El coste de este control es que todo lo que el proveedor solía hacer —escalado, parcheo, monitorización— es ahora trabajo de tu equipo.

Comodidad, capacidad y rapidez para lanzar

Las razones más fuertes para elegir una API cerrada son la imagen reflejada.

• Lanzas más rápido. Un endpoint alojado está disponible en el momento en que tienes una clave. Sin GPU que adquirir, sin servidor de inferencia que ajustar, sin autoescalado que diseñar. Para un prototipo o un producto temprano, esto por sí solo puede justificar la elección.
• La frontera tiende a aparecer primero ahí. Los modelos de propósito general más grandes y capaces suelen estar disponibles como servicios alojados antes de —o en lugar de— ser liberados como pesos abiertos. Si tu tarea necesita de verdad la cima del rango de capacidad, la opción cerrada puede ser simplemente la única que supera el listón.
• La madurez operativa viene incluida. La limitación de tasa, la monitorización, el filtrado de seguridad y el escalado de infraestructura están resueltos para ti. Los pagas dentro del precio por token, pero no tienes que construirlos.

El coste es la dependencia: del precio, la disponibilidad y la hoja de ruta del proveedor, y de un viaje de ida y vuelta por la red que no controlas.

La cuestión del coste, con honestidad

Las comparaciones de coste son donde la mayoría de los equipos se engañan, en ambas direcciones.

Una API alojada tiene un coste fijo casi nulo y un coste variable claro por unidad de uso. Eso es maravilloso a volumen bajo e irregular y puede volverse doloroso a volumen alto y sostenido, porque pagas el precio completo por cada llamada para siempre.

El autoalojamiento invierte la curva. Pagas un coste grande y mayormente fijo —hardware o capacidad reservada, más el tiempo de ingeniería para operarlo— que se desperdicia cuando el tráfico es bajo y se amortiza maravillosamente cuando el tráfico es alto y predecible. El punto de equilibrio es real pero específico de cada proyecto.

Unos cuantos principios que se sostienen al margen de los números:

• La capacidad ociosa es el impuesto oculto del autoalojamiento. Una GPU que alquilas por hora cuesta lo mismo tanto si atiende mil peticiones como ninguna. Si tu tráfico es a picos, el precio alojado suele ganar a pesar de una tarifa por llamada más alta de titular.
• El tiempo de ingeniería es parte del coste de inferencia. El salario de las personas que mantienen sano tu stack de inferencia es una partida real. Los equipos lo olvidan rutinariamente y luego se preguntan por qué los pesos "gratis" salieron caros.
• El coste total depende de la utilización, no del precio de lista. No compares un precio de API por token con un precio de GPU por hora directamente. Convierte ambos a coste por petición útil bajo tu carga esperada.

La licencia no es una nota al pie

Para los modelos de pesos abiertos, lee la licencia antes de construir, no después. La palabra "abierto" cubre un amplio rango de términos, y algunos conllevan obligaciones que importan comercialmente.

Algunos lanzamientos de pesos abiertos usan licencias permisivas cercanas en espíritu a MIT o Apache, que permiten un uso comercial amplio. Otros usan licencias personalizadas o comunitarias que restringen el uso por encima de cierta escala, prohíben ciertas aplicaciones o adjuntan condiciones a los modelos derivados. La Open Source Initiative mantiene la definición canónica de código abierto si quieres una vara contra la que medir una licencia, y los hubs de modelos como Hugging Face muestran la licencia junto a cada modelo para que puedas comprobarla pronto.

La regla duradera: un modelo que puedes descargar no es automáticamente un modelo que tienes licencia para usar de la forma que pretendes. Trata la licencia como un requisito de filtro, a la par de la capacidad y el coste.

Un marco de decisión

Recorre estas preguntas en orden. La primera que dé una respuesta firme suele decidir el asunto.

1. ¿Hay un requisito firme de residencia de datos o de uso sin conexión? Si las entradas no pueden salir de tu infraestructura, inclínate con fuerza hacia los pesos abiertos y el autoalojamiento.
2. ¿La tarea necesita la mismísima cima del rango de capacidad? Si es así, comprueba si un modelo de pesos abiertos realmente supera el listón. Si solo lo hace un modelo alojado de frontera, eso estrecha tu elección deprisa.
3. ¿Cuál es tu perfil de volumen? Bajo o a picos favorece lo alojado. Alto, sostenido y predecible favorece el autoalojamiento, si tienes el equipo para operarlo.
4. ¿Tienes la capacidad operativa? Ejecutar inferencia de forma fiable es ingeniería de verdad. Si no tienes o no quieres esa capacidad, una API alojada no es un compromiso; es la elección correcta.
5. ¿La licencia permite tu uso previsto a tu escala prevista? Un "no" aquí anula cualquier otra preferencia.

Fíjate en que la capacidad es solo una de cinco puertas, y rara vez la decisiva. La mayoría de los proyectos reales se deciden por reglas de datos, volumen y capacidad del equipo mucho antes de que la calidad bruta del modelo entre en escena.

No tienes que elegir solo uno

El encuadre de una única elección binaria es en sí mismo una trampa. Los sistemas maduros mezclan ambos con frecuencia. Un patrón común y sensato es enrutar el grueso de las peticiones fáciles y de alto volumen a un modelo abierto autoalojado más barato, y escalar solo los casos genuinamente difíciles a una API alojada más capaz. Otro es prototipar en una API alojada para validar el producto, y luego migrar la carga de trabajo de estado estable a pesos autoalojados una vez que el volumen y los requisitos estén claros. Las dos opciones son herramientas, no equipos. Usa la que encaje en cada parte de la carga de trabajo.

En resumen

Abierto frente a cerrado es un compromiso entre control y comodidad, no un concurso de virtud. Los pesos abiertos te dan residencia de datos, estabilidad de versión y operación sin conexión al precio de hacerte dueño de las operaciones y de la revisión de la licencia. Las API cerradas te dan rapidez, capacidad de frontera e infraestructura gestionada al precio de la dependencia y el coste por llamada. Decide con el marco de las cinco puertas —residencia, listón de capacidad, perfil de volumen, capacidad operativa, licencia— y deja que los requisitos firmes hablen primero. Y recuerda que puedes mezclar los dos: la mejor arquitectura a menudo enruta el trabajo barato a uno y el trabajo difícil al otro.

Nota sobre las fuentes: los términos de licencia y la disponibilidad de lanzamientos específicos de pesos abiertos cambian con frecuencia, así que esta guía describe principios duraderos en lugar de nombrar modelos actuales. Lee siempre la licencia real en la página del modelo antes de construir.