Modelos de pesos abiertos en tus propias GPUs

Las tablas de clasificación de modelos de frontera son algo genuinamente útil de leer. En razonamiento puro, programación y memoria de contexto largo, las mejores APIs cerradas de los grandes laboratorios siguen arriba, y para mucho trabajo la respuesta honesta es llamar a una de ellas y seguir.

Solo que, en una empresa regulada, la tabla responde a una pregunta que no hiciste. La pregunta que decide tu arquitectura no es "¿qué modelo puntúa más alto en un benchmark público?". Es "¿qué modelo puedo correr sobre el expediente regulado de un cliente sin que ese expediente salga de mi perímetro?". En esa pregunta, un modelo de pesos abiertos — Llama, Mistral, Qwen o alguno de sus descendientes — corriendo en GPUs que controlas, gana con frecuencia. No por ser más inteligente. Porque está ahí, dentro de tus muros, donde la API de frontera no está.

Este es un eje de comparación distinto del que el mercado te entrena a usar. La capacidad es un eje. El lugar de ejecución es otro. En un negocio no regulado, el primero domina. En uno regulado, el segundo se impone a menudo.

Qué te da de verdad "pesos abiertos"

Empieza por el término, porque se usa con ligereza. Un modelo de pesos abiertos es aquel cuyos parámetros entrenados puedes descargar y correr en tu propio hardware. No es necesariamente open source en sentido pleno: los datos y el código de entrenamiento pueden ser cerrados, y la licencia puede tener condiciones. Lo que recibes es el artefacto que importa operativamente, los pesos, para poder cargarlos en tus GPUs y correr inferencia sin una llamada de red a nadie.

Esa única propiedad, inferencia bajo tu propio techo, es lo que cambia el cuadro de cumplimiento.

Cuando llamas a una API de frontera, el prompt y su contenido salen de tu perímetro y se procesan en infraestructura que no es tuya ni homologaste. Las garantías contractuales de no retención y no entrenamiento ayudan, y cuentan, pero son promesas sobre los sistemas de otro. Cuando corres un modelo de pesos abiertos en tus propias GPUs, no hay salida sobre la que prometer. Los datos regulados se leen, se razonan y se descartan dentro de una frontera que tu función de seguridad ya controla. La residencia de datos deja de ser una cláusula que auditas en el contrato de un proveedor y pasa a ser un hecho físico sobre por dónde fueron los electrones.

Para trabajo sobre datos personales, expedientes de crédito, historiales médicos o cualquier cosa que tu regulador trate como categoría especial, esa distinción no es un matiz. Es con frecuencia la decisión entera.

La brecha de capacidad es real, y se está cerrando donde importa

Ser honesto sobre el compromiso es la única forma de que este argumento valga la pena.

En el razonamiento general más difícil, los mejores modelos de frontera cerrados siguen por delante de los mejores pesos abiertos, y fingir lo contrario condena un proyecto. Pero dos cosas suavizan esa brecha en un contexto regulado.

Primera, la brecha se estrecha, y se estrecha más rápido precisamente en las tareas que corre un back office regulado: extracción estructurada, clasificación contra una política, resumen con cita, razonamiento condicionado sobre un conjunto documental acotado. No son tareas creativas abiertas donde la escala de frontera luce. Son estrechas, repetibles y evaluables, que es donde un modelo de pesos abiertos afinado o bien instruido cierra casi toda la distancia.

Segunda, en producción el modelo nunca es todo el sistema. Un modelo de pesos abiertos de gama media envuelto en recuperación, validación y un gate humano en los casos difíciles supera a menudo a un modelo de frontera llamado a pelo, porque la precisión que sobrevive hasta producción viene de la arquitectura alrededor del modelo, no de la puntuación bruta del modelo. El replanteamiento que viene del terreno se aplica aquí: estructura más un modelo suficientemente bueno gana a un modelo excelente sin estructura.

Así que la pregunta práctica no es "¿es el modelo abierto tan listo como el de frontera?". Es "¿es el modelo abierto suficientemente bueno en esta tarea concreta y acotada, una vez está dentro de un sistema que atrapa sus errores?". Para una porción grande del trabajo regulado, la respuesta es sí.

La factura que pagas de verdad: carga operativa y capacidad de GPU

Correr tus propios pesos no es gratis, y el coste no es principalmente la licencia. Es operativo.

Ahora eres dueño de una stack de inferencia. Eso significa planificación de capacidad de GPU, servicio de modelos, batching y cuantización para caber en los presupuestos de memoria, gestión de versiones a medida que salen nuevos pesos abiertos, y el endurecimiento de seguridad de las máquinas donde corren los pesos. La API de frontera escondía todo eso detrás del equipo de SRE de otro. Trae el modelo a casa y ese trabajo es tuyo.

La capacidad de GPU en particular es una restricción real, no una nota al pie. Las APIs de frontera te dan un rendimiento prácticamente elástico bajo demanda. Un clúster on-premise tiene un techo fijo, y un pico de carga que una API habría absorbido en silencio pasa a ser una cola que tienes que planificar. Es un coste de ingeniería genuino, y cualquier construcción honesta lo contabiliza de antemano en lugar de descubrirlo en el primer cierre de mes.

Nada de esto es argumento contra los modelos en GPU propias. Es argumento contra fingir que son una casilla que marcar. Las organizaciones que tienen éxito tratan la stack de inferencia como infraestructura que se opera con la misma disciplina que cualquier otro sistema regulado, y las que fracasan tratan un modelo descargado como un producto acabado.

Agnóstico respecto al proveedor es lo que te deja enrutar, no elegir

Esta es la parte que resuelve la tensión. La elección no es pesos abiertos contra frontera. Es una decisión de enrutado tomada carga a carga, y lo que hace posible el enrutado es un gateway agnóstico respecto al proveedor.

Un gateway de modelos es una única interfaz interna que todos los agentes llaman, detrás de la cual los modelos son intercambiables. Un modelo de pesos abiertos en tus GPUs, una API de frontera y un modelo alojado en región europea están todos tras la misma puerta, y el agente no sabe cuál respondió. El valor de esa puerta es que deja que una política, y no la costumbre de quien desarrolla, decida dónde corre cada carga.

La regla que aplica la política es el enrutado por sensibilidad de los datos, y falla cerrado. Un paso que lee un expediente regulado queda fijado al modelo en GPU propia y no puede alcanzar físicamente una API externa. Un paso que redacta un resumen genérico a partir de material no sensible, o razona sobre información ya pública, puede enrutarse a una API de frontera por su capacidad extra, pero solo porque una política permitió explícitamente que esa clase de datos saliera. Cuando la clasificación es incierta, los datos se tratan como sensibles y se quedan en casa. El valor por defecto te protege; relajarlo exige una decisión deliberada y registrada.

Eso es lo que hace la brecha de capacidad manejable en lugar de fatal. No tienes que renunciar al razonamiento de frontera en todas partes para mantener los datos regulados dentro de tus muros. Enrutas las cargas sensibles al modelo que vive en tu perímetro, y las no sensibles a lo que sea mejor para el trabajo, bajo una regla que tu función de cumplimiento escribió y puede demostrar.

La pregunta que merece la pena llevar a tu próxima revisión de arquitectura, entonces, no es "¿qué modelo es mejor?". Es cuáles de nuestras cargas no pueden salir nunca del edificio, y tenemos un modelo suficientemente bueno para servirlas dentro de casa. Responde a eso clase de datos a clase de datos, y el debate frontera contra abierto se disuelve en una tabla de enrutado. Sáltatelo, y estás a una llamada de API cómoda de enviar un expediente regulado a un sitio al que nunca se le permitió ir.

Si quieres mapear cuáles de tus cargas pertenecen a tus propias GPUs y cuáles pueden enrutarse a otro sitio con seguridad, reserva una reunión y tráenos la más sensible.