Modelos abiertos y cerrados

docs.scrimba.com

Por debajo, un modelo es un enorme conjunto de pesos entrenados (los números que aprendió durante el entrenamiento) que predice el siguiente token. Este capítulo trata sobre las dos formas en que esos pesos llegan a ti: los modelos cerrados, que alquilas a través de una API, y los modelos de peso abierto, que puedes ejecutar tú mismo; y también sobre dónde corre cada uno realmente. La opción predeterminada a la que todos te empujan es un modelo cerrado alojado, y los proveedores tienen pocos motivos para destacar las alternativas, así que vale la pena conocer todo el panorama y saber cuándo importa cada parte de él.

Pesos abiertos, pesos cerrados

Hay dos formas de acceder a un modelo de IA, y la diferencia se reduce a dónde vive realmente el modelo.

La primera forma es un modelo cerrado, a veces llamado propietario. Solo puedes acceder a él a través de la API de la empresa, que es una especie de puerta de entrada en línea: envías texto, recibes texto de vuelta, y ese es todo el trato. Los pesos del modelo, ese enorme conjunto de números entrenados que hace que funcione, quedan guardados bajo llave en los servidores de la empresa. Estás alquilando acceso, no eres dueño de nada.

La segunda forma es un modelo de peso abierto. Aquí la empresa publica esos pesos, así que puedes descargar tu propia copia y ejecutarla en el hardware que tú controlas. Piénsalo como la diferencia entre alquilar un departamento cuyo cableado nunca podrás ver, y ser dueño de una copia de los planos del edificio.

La mayoría de la gente empieza con una API cerrada porque es la puerta de entrada más fácil, y es un buen punto de partida. La opción abierta es real y vale la pena conocerla, para que entiendas que alquilar es una elección y no el único camino.

JunoPesos abiertos, pesos cerrados Un modelo cerrado vive en los servidores de la empresa y accedes a él a través de su API, así que estás alquilando acceso. Un modelo de peso abierto tiene sus números publicados, así que puedes descargar una copia y ejecutarla tú mismo. Empezar con una API cerrada está perfectamente bien, pero ayuda saber que existe la otra puerta.

Toda la distinción se reduce a una pregunta: ¿quién tiene los pesos? Con un modelo cerrado o propietario, los pesos nunca salen del proveedor y solo te comunicas con el modelo a través de una API. Con un modelo de peso abierto, los pesos se publican bajo una licencia que te permite descargarlos y ejecutarlos donde quieras.

Ten cuidado aquí, porque "peso abierto" no es lo mismo que "código abierto". Casi todos los LLM "abiertos" publican los pesos entrenados pero mantienen en privado los datos y el código de entrenamiento, así que no puedes reproducir el modelo desde cero por completo. Algunas licencias también tienen restricciones de uso, como un límite al tamaño de la empresa que puede usarlo comercialmente, o límites sobre los usos permitidos. Lee la licencia antes de comprometerte; "abierto" es un espectro, no una categoría binaria.

En cuanto a capacidad, los modelos cerrados de frontera (los modelos más capaces disponibles en un momento dado) suelen liderar los benchmarks públicos. Pero los modelos de peso abierto más sólidos están lo bastante cerca para gran parte de las tareas reales, y la brecha se sigue reduciendo con el tiempo. La estrategia práctica es no asumir que necesitas el modelo absolutamente mejor. Muchos trabajos se resuelven bien con uno abierto, y lo descubres probándolo contra tu propia tarea, no contra una tabla de clasificación.

JunoPesos abiertos, pesos cerrados Cerrado significa solo API, con los pesos quedándose en el proveedor; peso abierto significa pesos publicados que puedes descargar y ejecutar. Peso abierto no es código abierto, porque los datos y el código de entrenamiento suelen quedar en privado y la licencia puede restringir el uso, así que léela. Los modelos cerrados de frontera lideran los benchmarks, pero un modelo de peso abierto sólido resuelve mucho trabajo real, así que elige según la tarea.

Lo que "abierto" realmente te da es control y el fin de la dependencia de un solo proveedor. Puedes fijar los pesos exactos para que el modelo nunca cambie en silencio debajo de ti, inspeccionar su comportamiento, y ejecutarlo donde tengas hardware disponible. Eso es una ventaja real cuando la reproducibilidad o la residencia de datos importan.

Lo que no te da es nada gratis. Peso abierto casi siempre significa pesos más licencia, no código abierto: sin datos de entrenamiento, y a menudo con términos de licencia nada triviales. Así que la revisión de cumplimiento y licenciamiento se convierte en trabajo real que te toca hacer, y un modelo que suena permisivo aún puede restringir el uso comercial o la redistribución de formas que salen a la luz tarde si te saltas la lectura.

La brecha de capacidad de frontera también es real para las tareas más difíciles, aunque se va reduciendo. Así que elige según la tarea que tienes enfrente, no según la etiqueta. Para el grueso del trabajo cotidiano, un modelo de peso abierto es más que suficiente; para el límite de dificultad, el modelo cerrado de frontera todavía puede ganar.

Lo que tengo que seguir recordándome: trata "abierto" como una propiedad de los pesos y la licencia juntos, y lee ambos. "Puedo descargarlo" no es lo mismo que "puedo hacer lo que quiera con él", y esa diferencia ya me ha mordido antes.

JunoPesos abiertos, pesos cerrados Los pesos abiertos te dan control y una salida de la dependencia de un proveedor: versiones fijas, comportamiento que puedes inspeccionar, ejecución donde quieras. No te dan código abierto, así que presupuesta la revisión de licencia y cumplimiento, porque una licencia que se ve amigable aún puede prohibir el uso comercial. Elige según la tarea, no según la etiqueta, y nunca leas "puedo descargarlo" como "puedo hacer lo que quiera con él".

Dónde corre el modelo

Circula la creencia de que elegir un modelo abierto significa tener que montar tus propios servidores y ejecutarlo tú mismo. Eso no es cierto, y vale la pena aclararlo desde el principio.

Un modelo puede correr en uno de dos lugares. Con un modelo alojado, alguna empresa lo ejecuta en sus máquinas y tú accedes a él por internet con una llamada a la API, que es una pequeña solicitud que tu código envía y de la cual recibe una respuesta. Nunca tocas la computadora donde corre. Con el autoalojamiento, ejecutas el modelo tú mismo, en tu propia computadora o tu propio servidor.

Aquí está la parte que la gente pasa por alto. Un modelo abierto no te obliga a autoalojarlo. Puedes usar un modelo abierto a través de una empresa de hosting de la misma forma cómoda en que usarías uno cerrado: envías una solicitud, recibes una respuesta, y otra persona se encarga de mantener la máquina funcionando. El autoalojamiento es una opción que puedes tomar, no una regla que tengas que seguir.

JunoDónde corre el modelo Un modelo corre en la máquina de otra persona a la que accedes por internet, o en una máquina que ejecutas tú mismo. Los modelos abiertos pueden ir en cualquiera de las dos direcciones, así que elegir uno no significa que de repente tengas que administrar servidores. Puedes dejar que una empresa de hosting ejecute un modelo abierto por ti, exactamente igual que harías con uno cerrado.

Ayuda dejar de pensar en dos casillas, porque dónde corre un modelo es en realidad un espectro. En un extremo, un modelo cerrado al que accedes a través de la API de su proveedor. En el medio, un modelo de peso abierto que un tercero ejecuta por ti. En el otro extremo, un modelo de peso abierto que ejecutas tú mismo, que es el autoalojamiento: tú aportas la máquina y ejecutas el programa que sirve el modelo.

La razón por la que moverte a lo largo de ese espectro es barato es que una forma de API de mensajes de chat ampliamente adoptada se ha convertido en un estándar de facto, y muchos hosts de modelos abiertos y servidores autoalojados exponen esa misma forma. Así que cambiar de proveedor suele ser, sobre todo, un cambio de URL base y nombre de modelo, no una reescritura (ver cómo llamar modelos desde código). Nada de lo que aprendas sobre cómo llamar a un modelo queda atado a un solo proveedor.

En resumen, el autoalojamiento significa que tú aportas el hardware (una GPU capaz, o un servidor GPU alquilado) y ejecutas un programa de servicio frente al modelo. Trátalo como el trabajo real que estás asumiendo. Aquí nos quedamos a nivel de decisión y no profundizamos más en la configuración.

JunoDónde corre el modelo Piénsalo como un espectro: cerrado a través del proveedor, abierto a través de un host externo, o abierto autoalojado. Como tantos endpoints comparten una misma forma de API de mensajes de chat, saltar entre ellos suele ser un cambio de base_url y nombre de modelo, no una reescritura. El autoalojamiento es el extremo lejano, donde tú eres dueño del hardware y del servicio, así que recúrrelo a propósito, no por defecto.

El autoalojamiento es infraestructura, no una tarea secundaria. En el momento en que ejecutas el modelo tú mismo, te haces responsable de la planificación de capacidad, el escalamiento bajo carga, el tiempo de actividad, los parches de seguridad y las actualizaciones del modelo. "Corre en mi laptop" es una demo; producción es una cuenta distinta.

El camino intermedio que la mayoría de los equipos se salta es un host administrado de modelos abiertos. Obtienes las ventajas del modelo abierto (menor costo que la frontera cerrada, la capacidad de fijar una versión específica del modelo, opciones sobre dónde reside tu dato, sin dependencia de un solo proveedor) sin tener que montar GPUs tú mismo. La forma de API de chat de facto es tu seguro: mantén tu código apegado a esa interfaz y cambiar de host, o traer un modelo internamente más adelante, sigue siendo un cambio de configuración en lugar de una migración.

He visto un "autoalojamiento rápido" tragarse un trimestre completo, así que reservo el autoalojamiento de verdad para cuando una presión concreta realmente lo exige: reglas de residencia de datos, una economía de escala que se vuelve favorable, o un modelo que debes controlar de principio a fin. En ausencia de eso, la respuesta es un modelo abierto administrado o uno cerrado alojado.

JunoDónde corre el modelo Ejecutar tu propio modelo significa hacerte responsable de la capacidad, el tiempo de actividad, los parches y las actualizaciones, así que no entres en eso sin pensarlo. El camino que los equipos suelen ignorar es un host administrado de modelos abiertos: la economía y el control de un modelo abierto sin tener que cuidar GPUs. Programa contra la API de chat estándar y los cambios de proveedor siguen siendo configuración, no migración. Reserva el autoalojamiento real para una razón concreta, como residencia de datos, cálculos de escala, o control estricto del modelo.

Cuándo tiene sentido cada opción

Aquí hay una forma sencilla de resumir toda la decisión. Un modelo cerrado y alojado es como alquilar: no hay nada que configurar, obtienes la mejor calidad disponible, y pagas un poco cada vez que lo usas. Un modelo abierto que ejecutas tú mismo se acerca más a ser propietario: obtienes más control y más privacidad, y no hay una factura por uso que le llegue a un proveedor, pero asumes el trabajo de mantenerlo funcionando.

La mayoría de la gente hace bien en empezar alquilando a través de una API, y la mayoría nunca necesita nada más que eso. Alquilar primero es el camino normal y sensato.

El punto de este capítulo no era que debieras cambiarte a ejecutar tu propio modelo. Era solo que debías saber que la elección es tuya, para que si un día tus necesidades cambian, reconozcas la opción por lo que es.

Con un modelo elegido, la siguiente pregunta es cómo le hablas. El próximo capítulo, Prompting, trata sobre cómo guiar al modelo que hayas elegido para que te dé lo que realmente quieres.

JunoCuándo tiene sentido cada opción Piénsalo como alquilar versus ser propietario: un modelo cerrado alojado es alquilar, un modelo abierto que ejecutas tú mismo se acerca más a ser propietario. Alquilar a través de una API es el lugar correcto para empezar, y la mayoría de la gente se queda ahí felizmente. Ahora sabes que existe la otra puerta, que es todo el punto. Lo siguiente es Prompting, donde aprendemos a guiar el modelo que elegiste.

Cuando de verdad tengas que elegir, sopesa los factores más o menos en este orden. Primero, capacidad: ¿un modelo de frontera alojado realmente se justifica para esta tarea, o ya basta con un modelo de peso abierto sólido? Segundo, sensibilidad de los datos: ¿puede este dato salir de tu perímetro bajo los términos de un proveedor, o la residencia de datos (las reglas sobre dónde pueden vivir y procesarse físicamente los datos) lo descarta?

Tercero, la curva de costos. Una API por token es barata para empezar y sigue siendo barata a bajo volumen, pero puede volverse costosa a un volumen alto y constante, que es donde el autoalojamiento de costo fijo puede ganar. Cuarto, control: ¿necesitas fijar un comportamiento exacto a través de las versiones, o evitar quedar atado a un solo proveedor?

La jugada suele ser la misma casi siempre. Empieza con una API alojada, porque es el camino más rápido para tener algo funcionando. Luego reconsidera solo cuando aparezca una presión concreta: costo a escala, un requisito de privacidad o cumplimiento, o una necesidad real de capacidad o control.

Decide con evidencia, no con opciones por defecto ni por ideología. Una vez que tu modelo esté resuelto, Prompting te muestra cómo obtener resultados confiables de él.

JunoCuándo tiene sentido cada opción Sopesa cuatro cosas en orden: la capacidad necesaria, la sensibilidad de los datos, la curva de costos y el control. Empieza con una API alojada porque te pone a funcionar más rápido, y reconsidera solo cuando aparezca una presión concreta, como costo a alto volumen o una regla de residencia de datos. Cambia con evidencia, no con una corazonada. Luego pasa a Prompting para hacer que lo que elegiste se comporte bien.

La versión simple. Para la mayoría de los equipos, una API cerrada alojada es la opción correcta por defecto, y autoalojar un modelo de peso abierto es una decisión de costo y control, no una insignia de seriedad. Vale la pena pasada cierta escala, o bajo una restricción de cumplimiento o residencia de datos, y no mucho antes de eso.

Así que conoce más o menos dónde se cruza la curva de costos para tu volumen, porque ese punto de cruce es todo el argumento financiero. Conoce lo que tus reglas de datos realmente exigen, no lo que sientes vagamente que exigen, que es donde entran seguridad y límites y la pregunta de qué envías. Y sabe que los pesos abiertos también son lo que te permite hacer fine-tuning libremente en tus propios términos sin pedirle permiso a un proveedor (ver fine-tuning). Evitar la dependencia de un proveedor, es decir, quedar atado a los precios, términos y ciclo de vida del modelo de un solo proveedor, es parte del mismo cálculo.

La razón para aprender todo esto no es para que salgas a autoalojar. He visto a gente montar su propia infraestructura para demostrar un punto y arrepentirse desde la segunda semana de guardia. Es que el camino por defecto es el modelo cerrado alojado, y los proveedores tienen pocos motivos para señalarte las alternativas, así que un ingeniero que conoce todo el panorama toma una decisión deliberada en lugar de una heredada.

Con la cuestión del modelo resuelta por sus méritos, Prompting es donde empieza el trabajo diario de obtener buenos resultados.

JunoCuándo tiene sentido cada opción Para la mayoría de los equipos, la API cerrada alojada es la opción correcta por defecto, y autoalojar un modelo de peso abierto es una decisión de costo y control que vale la pena pasada cierta escala o bajo una restricción de cumplimiento, no un rasgo de personalidad. Conoce dónde se cruza tu curva de costos, conoce lo que tus reglas de datos realmente exigen, y recuerda que los pesos abiertos te dan fine-tuning gratis y una salida de la dependencia de un proveedor. He visto el autoalojamiento para demostrar un punto, y el arrepentimiento es real. Aprende todo el panorama para elegir a propósito, y luego sigue a Prompting.