Un modelo cerrado te da una API y una garantía. Un modelo open weight te da control y asumes la operación. La pregunta útil no es cuál es mejor, sino qué trabajo va a cada uno.
Tres etiquetas que se mezclan
«Modelo cerrado» significa que solo accedes a él por una API. No tienes los pesos, no lo puedes ejecutar en tu hardware y dependes del proveedor para las actualizaciones, los límites y el precio. «Modelo open weight» significa que los pesos están disponibles para descargar y ejecutar, dentro de los límites de la licencia y de tu infraestructura. Puedes ajustarlo, cuantizarlo y servirlo en tu infraestructura.
«Open source» es otra cosa. La definición de IA de código abierto (OSAID 1.0) exige el código completo, los parámetros y una descripción suficiente de los datos de entrenamiento (procedencia, alcance y filtrado) para poder reconstruir un sistema equivalente. La mayoría de los modelos que se llaman open source son open weight: publican los pesos, pero no la receta. Esa diferencia importa cuando alguien de cumplimiento pregunta qué datos vio el modelo.
Lo que compras con un modelo cerrado
Contratas una API mantenida y, según el proveedor y el contrato, un nivel de servicio, soporte y controles de seguridad; revisa el SLA antes de darlo por hecho. También compras una factura por token y la posibilidad de empezar hoy sin montar GPUs.
A cambio, dependes del proveedor. El modelo puede cambiar, el precio puede subir, el límite puede bajar o el proveedor puede dejar de servir en tu región. Tus datos salen de tu infraestructura y las condiciones las marca otro. Para muchos proyectos, ese intercambio es razonable. Para otros, no.
Lo que compras con un modelo abierto
Compras control. Puedes ejecutar el modelo en tu nube, en tu centro de datos o en un entorno sin salida a internet. Puedes ajustarlo con tus datos, elegir la versión y mantenerla cuando el proveedor cambie la suya. También puedes inspeccionar el comportamiento y medir el coste en GPU.
A cambio, asumes la operación. Elegir el motor de inferencia, dimensionar las GPU, gestionar la cola, actualizar, monitorizar y responder a las caídas. El coste por token puede ser menor, pero el coste total incluye personas, hardware y tiempo. A poco volumen, casi nunca sale a cuenta.
El coste real
Comparar el precio por millón de tokens es fácil y engañoso. En un modelo cerrado, el precio incluye la infraestructura, el mantenimiento y el soporte. En uno abierto, el precio de la GPU no lo incluye todo: falta la persona que lo opera, la redundancia, el almacenamiento y el tiempo de ingeniería.
La cuenta cambia con el volumen y con la carga. Un modelo abierto en un servidor dedicado puede ser muy barato si la GPU está ocupada todo el día. Si la carga es intermitente, pagas hardware parado. La inferencia gestionada de modelos abiertos existe justamente para evitar ese problema: mantienes el control del modelo sin operar la máquina.
El cambio no es solo una cadena
Cambiar de modelo no es cambiar un identificador. Los prompts están ajustados a un modelo concreto. Las llamadas a herramientas se formatean de una manera. Las salidas estructuradas se fuerzan con mecanismos distintos. La moderación que incluía el proveedor desaparece. Todo eso hay que volver a probarlo.
La forma barata de cambiar es tener una capa de enrutamiento y una suite de evals propia. Así puedes probar el candidato con tu tráfico real, comparar calidad, latencia y coste, y decidir con datos. Sin esa capa, el cambio se convierte en un proyecto de integración.
Enrutamiento por riesgo
La decisión no tiene que ser única para todo el producto. Puedes usar un modelo abierto y barato para clasificar, resumir o atender el volumen, y un modelo de vanguardia para las decisiones que llevan consecuencias. Esa mezcla suele dar mejor coste que elegir un solo modelo para todo.
La regla es el riesgo de equivocarse. Si una respuesta incorrecta cuesta poco y se detecta rápido, un modelo barato puede bastar. Si una respuesta incorrecta afecta a dinero, salud o legal, el coste de la equivocación manda. Ahí no se optimiza el token.
Cómo decidir
Empieza por el trabajo, no por el modelo. Define el resultado, el volumen, la latencia, el coste máximo y las restricciones de datos. Después prueba dos o tres candidatos con tus propios casos. Mira la calidad, la latencia y el coste por tarea. Y revisa la licencia del modelo exacto que vas a usar, no la de la familia.
La respuesta cambia con el tiempo. Un modelo que hoy es la referencia puede dejar de serlo en tres meses. La decisión importante no es el modelo de hoy, sino tener una forma de cambiarlo sin rehacer el producto.
Fuentes
Sigue leyendo