Modelos de lenguaje locales y privados: cuándo tienen sentido

Para ejecutar un modelo con soltura, sus pesos tienen que caber en la memoria del acelerador, normalmente una o varias GPU, junto con la memoria que consume cada conversación en curso. El tamaño del modelo, medido en número de parámetros, y la precisión con que se almacenan esos parámetros determinan cuánta memoria hace falta. A partir de ahí, el número de usuarios simultáneos y la longitud de los textos que se procesan añaden necesidades.

Por eso dimensionar el hardware empieza por el caso de uso y no por el catálogo de servidores. Diez técnicos que hacen consultas esporádicas no se parecen a un proceso que resume miles de documentos cada noche. Antes de comprar nada es razonable hacer pruebas en una máquina alquilada, con el modelo candidato y una carga parecida a la real, y medir tiempo de respuesta y consumo de memoria.

La cuantización consiste en almacenar los pesos del modelo con menos precisión numérica, por ejemplo con enteros de 8 o 4 bits en lugar de números de coma flotante de 16 o 32 bits. La documentación de la biblioteca Transformers de Hugging Face la describe como una forma de reducir la memoria necesaria para cargar y usar un modelo intentando conservar la mayor exactitud posible. Gracias a ella, modelos que no cabrían en un equipo concreto pueden ejecutarse en él.

El intercambio no es gratuito. Cuanto más agresiva es la cuantización, más probable es que el modelo pierda calidad en tareas exigentes: razonamientos largos, idiomas con menos presencia en el entrenamiento o formatos de salida estrictos. La pérdida varía según el método, el modelo y la tarea, así que la única forma fiable de conocerla es repetir la evaluación propia con la versión cuantizada, y no dar por buena una cifra genérica.

• Compara siempre la versión cuantizada con la de mayor precisión sobre el mismo conjunto de casos reales.
• Fíjate en los errores de formato: una salida JSON rota es un fallo de integración, no de estilo.
• Comprueba el comportamiento en español y con la terminología propia del sector, no solo en inglés.

Que los pesos de un modelo se puedan descargar no implica que se puedan usar para cualquier fin. Algunos modelos se publican con licencias de código abierto reconocidas; otros, con licencias propias que restringen usos, imponen condiciones a partir de cierto número de usuarios o exigen aceptar políticas de uso aceptable. La Open Source Initiative publicó en su Definición de IA de código abierto los requisitos para que un sistema pueda llamarse así: libertad de usarlo, estudiarlo, modificarlo y compartirlo, con acceso a información sobre los datos, al código y a los parámetros.

La interpretación de una licencia concreta corresponde al cliente y a su asesoría jurídica. Desde el diseño técnico, lo que conviene es registrar qué modelo y qué versión se usan, con qué licencia, y revisar la licencia de nuevo cuando se actualiza el modelo.

Un modelo que cabe en un servidor razonable suele ser más pequeño que los modelos frontera ofrecidos como servicio, y en tareas abiertas y complejas lo normal es que rinda menos. En tareas acotadas (clasificar, extraer campos, resumir un documento corto, responder sobre fragmentos recuperados de una base documental) la diferencia puede ser pequeña o irrelevante para el proceso. Por eso la pregunta no es si el modelo local es tan bueno como el mejor disponible, sino si alcanza el nivel que la tarea necesita.

Una forma práctica de responder es usar el mismo conjunto de evaluación con un modelo frontera, como referencia de techo, y con los candidatos locales. Si el local queda cerca en lo que importa, es una opción seria; si queda lejos, puede que haya que rediseñar la tarea para que sea más acotada, combinarlo con recuperación de documentos o aceptar que ese proceso concreto no encaja en local. La guía sobre cómo seleccionar modelos frontera explica cómo montar esa evaluación.

Con un servicio externo, el proveedor se ocupa de la infraestructura del modelo. En local, esa responsabilidad pasa a quien opera el sistema, y conviene repartirla por escrito antes de empezar.

• Actualizaciones del servidor de inferencia, de los controladores y del sistema operativo, probadas antes de llegar a producción.
• Monitorización de tiempo de respuesta, errores, uso de memoria y temperatura de los equipos.
• Gestión de versiones del modelo: cuándo se adopta una nueva, con qué evaluación y cómo se vuelve atrás.
• Control de acceso al servicio del modelo y registro de peticiones, con la retención que se haya decidido.
• Plan ante la avería de una GPU o de un servidor: redundancia, degradación aceptable o parada temporal.

Imaginemos, como ejemplo ilustrativo, un fabricante que quiere que sus técnicos de mantenimiento consulten manuales y procedimientos internos desde tabletas en planta. Parte de la documentación procede de proveedores con cláusulas de confidencialidad y la conexión a internet de la planta no es fiable. Un planteamiento posible sería un servidor en la propia planta con un modelo de tamaño medio cuantizado, un índice de los documentos aprobados y respuestas siempre acompañadas de la referencia al manual.

Antes de decidir, el equipo compararía el modelo local con uno frontera sobre doscientas preguntas reales recogidas de los técnicos. Si el local acierta en lo esencial y cita bien las fuentes, el proyecto sigue; si falla en procedimientos con muchos pasos, se podría limitar el sistema a localizar la sección correcta del manual en lugar de redactar respuestas.

1. ¿Existe una razón concreta (contractual, legal, de conectividad o de control) para no usar un servicio externo?
2. ¿La tarea es lo bastante acotada como para que un modelo de tamaño manejable la resuelva con la calidad necesaria?
3. ¿Se ha medido esa calidad con casos reales, incluida la versión cuantizada que se va a desplegar?
4. ¿Se ha revisado la licencia del modelo para el uso previsto?
5. ¿Hay alguien que vaya a operar, actualizar y vigilar el sistema durante toda su vida útil?

Si las cinco respuestas son afirmativas, un modelo local puede ser una opción sólida. Si falla la segunda o la tercera, quizá convenga una modalidad dedicada en nube con condiciones contractuales adecuadas, o un diseño híbrido donde solo los datos sensibles se procesen en local. Podemos ayudarte a evaluar el caso con datos reales antes de invertir en hardware.