Cómo elegir, cuantizar y evaluar un modelo de lenguaje local

1. Define el problema antes de elegir el modelo

Un modelo local ejecuta la inferencia en hardware que controlas, en vez de enviar cada solicitud a un servicio remoto. Eso puede reducir la exposición de datos a terceros y permitir operar sin conexión después de descargar el modelo y sus dependencias. No garantiza por sí solo privacidad: una interfaz, un complemento, un registro de actividad o una herramienta conectada todavía puede transmitir información.

Empieza por describir la tarea, los datos permitidos, la calidad mínima y el volumen previsto. Un modelo pequeño puede bastar para clasificar mensajes o extraer campos; un asistente que use herramientas, interprete documentos complejos o sostenga conversaciones largas necesita pruebas más exigentes. El tamaño de parámetros no predice por sí solo el resultado en tu caso.

2. Selecciona modelo, licencia y formato

Compara modelos candidatos que puedan ejecutarse en tu entorno y cuya licencia permita el uso previsto. Comprueba la ficha oficial del modelo: arquitectura, tamaño, límites de contexto, idiomas, capacidades multimodales y condiciones de redistribución. Confirma también que el runtime elegido admite esa arquitectura y la variante concreta de pesos; que un modelo tenga muchos parámetros o una comunidad activa no demuestra que sea adecuado para producción.

GGUF es un formato habitual en flujos basados en llama.cpp y herramientas compatibles, pero no es requisito universal para ejecutar inferencia local. Otras pilas usan formatos y motores diferentes. Para cada candidato, registra el identificador exacto, la revisión de pesos, el formato, la cuantización, el runtime y la configuración. Así podrás reproducir una prueba y detectar cambios al actualizar.

3. Cuantiza solo después de establecer una referencia

La cuantización reduce la precisión numérica de pesos u otros valores del modelo para ahorrar memoria y, según el hardware y el runtime, puede cambiar la velocidad de inferencia. El ahorro suele hacer posible cargar modelos que no cabrían en su representación de mayor precisión, pero puede degradar la calidad. El efecto depende del modelo, del método, de la tarea y del backend: no se debe prometer una pérdida fija ni asumir que una etiqueta de cuatro o cinco bits predice por sí sola el resultado.

Q4_0, Q5_1 y Q4_K_M no son nombres intercambiables. Las variantes pertenecen a formatos y esquemas distintos; antes de descargar, comprueba la descripción de la cuantización y el tamaño real del archivo. LoRA, por su parte, es una técnica de adaptación mediante parámetros adicionales, no un nivel de cuantización. Puede combinarse con ciertos flujos de cuantización, pero no es una alternativa equivalente a Q4 o Q5.

4. Dimensiona memoria y hardware con margen

Una estimación inicial del espacio de pesos se obtiene multiplicando el número de parámetros por el número de bytes usado para representarlos. Por ejemplo, un modelo de siete mil millones de parámetros en FP16 requiere alrededor de catorce mil millones de bytes para los pesos, antes de contar otros consumos. En una cuantización de cuatro bits, el cálculo ideal de los pesos sería menor, pero el archivo y la memoria ocupada no equivalen exactamente a ese mínimo: intervienen metadatos, escalas, tensores que conservan otra precisión y requisitos del runtime.

La VRAM es importante cuando se descargan capas a una GPU; la RAM del sistema permite ejecutar por CPU o alojar partes que no caben en la GPU. También reserva memoria el contexto de la conversación, la caché KV, las activaciones y, en servicio concurrente, las solicitudes simultáneas. Por eso un archivo que aparentemente cabe en la VRAM puede fallar al iniciar o quedarse sin memoria con contextos largos. El tamaño del archivo sirve para filtrar opciones, no para cerrar el dimensionamiento.

5. Configura privacidad y operación sin red

La inferencia local puede mantener los datos en el dispositivo, pero «local» no significa automáticamente «aislado». Descargas de modelos, actualizaciones, telemetría, interfaces web, proxies, extensiones y registros pueden generar comunicaciones. Identifica cada componente y define qué destinos de red necesita. Si el sistema debe funcionar sin internet, descarga y verifica previamente pesos, dependencias y licencias; luego prueba el bloqueo de salida en el entorno real.

Usa segmentación de red y reglas de firewall de mínimo privilegio. Limita quién puede acceder al endpoint de inferencia, evita exponerlo directamente a redes públicas y protege los registros. Trata los prompts, respuestas y documentos como datos sensibles si contienen información interna. Una prueba de desconexión debe confirmar que la aplicación funciona sin llamadas externas, no solo que el modelo ya está descargado.

6. Valida calidad, latencia y rendimiento

Evalúa cada configuración con un conjunto de pruebas representativo y estable, separado de los ejemplos usados para ajustar prompts. Para calidad, define métricas según la tarea: exactitud o F1 para clasificación, tasa de campos correctos para extracción y revisión humana con criterios comunes para respuestas abiertas. BLEU y ROUGE pueden ser útiles en algunos problemas de comparación textual, pero no sustituyen una evaluación de factualidad, cumplimiento de instrucciones o riesgo; una coincidencia léxica alta no demuestra que la respuesta sea correcta.

Mide latencia de carga, tiempo hasta el primer token, tiempo total y tokens por segundo. Distingue una ejecución en frío de una con el modelo ya cargado. Registra hardware, driver, runtime, versión del modelo, cuantización, contexto, tamaño de lote y concurrencia. La inferencia local elimina parte de la latencia de red, pero no garantiza menor latencia total: depende del equipo, el modelo y la carga.

7. Versiona y mantén el servicio

Fija versiones de pesos, cuantización, runtime, bibliotecas y configuración. Conserva sumas de comprobación de los artefactos cuando estén disponibles y almacena los modelos en ubicaciones controladas. Antes de actualizar, ejecuta de nuevo las pruebas de calidad, rendimiento, compatibilidad y aislamiento. Una actualización puede cambiar respuestas, uso de memoria o comportamiento de herramientas aunque el nombre comercial del modelo siga siendo parecido.

Monitoriza errores, saturación de memoria, latencia y disponibilidad. Define un procedimiento de reversión a una versión probada y una política para retirar artefactos vulnerables o sin licencia adecuada. Si el sistema usa herramientas, aplica permisos mínimos y valida llamadas antes de ejecutarlas; un modelo local también puede producir instrucciones incorrectas o contenido manipulado.

8. Checklist y criterios prácticos de decisión

La elección correcta es la configuración más pequeña y sencilla que satisface los requisitos medidos, no necesariamente el modelo más grande ni la cuantización más agresiva. Si una opción no alcanza la calidad mínima, cambia el modelo o la configuración y repite la evaluación; si excede memoria o latencia, revisa primero el contexto, la concurrencia y la distribución entre CPU y GPU.

Las fuentes disponibles respaldan los principios generales de cuantización y documentan opciones de una plataforma concreta, pero no establecen una pérdida universal de calidad para pasar de FP16 a una cuantización determinada ni unos requisitos universales de VRAM para modelos de 7B o 13B. Esos valores deben verificarse en el artefacto, runtime, tarea y hardware específicos.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.