Cómo evaluar modelos locales cuantizados: calidad y velocidad en tu hardware

Por qué medir antes de elegir

La cuantización reduce la memoria necesaria para cargar los pesos, pero no permite deducir por sí sola cuánto cambiará la calidad en una tarea concreta. Tampoco basta con saber cuántos parámetros tiene un modelo para anticipar la velocidad en tu equipo: influyen el procesador, la memoria disponible, la configuración de inferencia, el contexto y la carga del sistema. La decisión útil se obtiene midiendo las alternativas con entradas representativas del uso real.

Un estudio de 2025 sobre seis modelos ejecutados localmente con Ollama en un sistema de recuperación de información académica comparó precisión, latencia hasta el primer token y velocidad de generación. Ese trabajo muestra un enfoque empírico pertinente, pero no prueba que una cuantización GGUF concreta conserve la calidad en otros modelos, tareas o equipos. La guía siguiente convierte ese principio en un protocolo propio: define primero qué significa acertar y qué rendimiento necesitas; después compara cada configuración con una referencia explícita.

1. Define la tarea y la línea base

Empieza describiendo qué hará el modelo en producción: quién lo usa, qué recibe como entrada, qué salida debe producir, qué errores son costosos y cuánto tiempo puede tardar. Una evaluación de extracción de campos requiere medir coincidencia de valores; una de respuestas basadas en documentos necesita comprobar fidelidad a las fuentes; un generador de código exige ejecutar pruebas, no solo juzgar si la respuesta parece plausible. Si mezclas tareas distintas en una única nota, puedes ocultar fallos importantes.

Prepara un conjunto de pruebas que represente la distribución esperada: tipos de entrada frecuentes, casos límite, entradas ambiguas y ejemplos difíciles. Incluye una referencia verificable para cada caso —una respuesta correcta, campos esperados, pruebas automatizadas o una rúbrica de evaluación— y registra de dónde procede. Separa un conjunto de desarrollo, que puedes usar para ajustar prompts o parámetros, de otro de evaluación que no debes utilizar para optimizar repetidamente. Así reduces el riesgo de escoger una configuración que solo funciona bien en los ejemplos ya vistos.

2. Mide calidad según el trabajo real

La calidad no es una sola métrica. Para respuestas con una solución conocida, calcula exactitud o tasa de aciertos; para extracción, coincidencia exacta por campo y por registro; para clasificación, informa de precisión y exhaustividad cuando los falsos positivos y negativos tengan costes diferentes. En tareas de generación abierta, usa una rúbrica explícita —por ejemplo, factualidad, cobertura, claridad y utilidad— y conserva ejemplos de errores para interpretar la puntuación. Una valoración automática o basada en otro modelo puede ayudar a revisar muchos casos, pero no debe tratarse como verdad de referencia sin comprobar su validez para ese uso.

Mide el formato como un criterio independiente cuando el sistema requiera JSON, una estructura fija, una llamada a herramienta o límites de longitud. Comprueba si la salida se puede analizar con el validador real y si respeta campos obligatorios, tipos, enumeraciones y restricciones. Registra también coherencia entre ejecuciones cuando el muestreo no sea determinista: una única respuesta acertada no demuestra que el sistema sea fiable. Para tareas de riesgo, cuenta explícitamente errores graves y establece una regla de rechazo o revisión humana antes de evaluar.

3. Mide velocidad, latencia y memoria

Registra al menos la latencia hasta el primer token y la velocidad de generación en tokens por segundo. La primera aproxima cuánto espera una persona antes de ver respuesta; la segunda describe la producción posterior. Añade el tiempo total hasta completar la respuesta, porque una salida larga puede tardar mucho aunque la tasa de generación sea alta. Indica qué herramienta reporta cada medida y qué incluye: carga inicial del modelo, preparación del prompt, procesamiento de entrada o solo generación.

Anota el consumo de memoria durante la inferencia y el contexto probado. El tamaño del archivo GGUF no equivale automáticamente a la memoria total necesaria: el contexto, la caché de atención, el runtime y el sistema operativo también pueden influir. Compara el mismo modelo y la misma tarea con idéntico límite de contexto, parámetros de generación y hardware. Si una configuración no cabe en memoria y recurre a intercambio con almacenamiento o a una ruta distinta de ejecución, regístralo: ya no es una comparación equivalente.

4. Ejecuta una comparación controlada

Para atribuir diferencias a la configuración evaluada, mantén constantes el conjunto de entradas, la plantilla de prompt, el límite de tokens, la temperatura y los demás parámetros relevantes. Anota el nombre y la revisión del modelo, la procedencia del archivo GGUF y su cuantización exacta. Registra también versiones de Ollama o LM Studio, sistema operativo, procesador, acelerador, memoria y opciones de descarga de capas. En el protocolo, especifica si el modelo ya estaba cargado o si mides también la carga inicial.

Ejecuta primero una pasada de preparación si necesitas que el modelo se cargue y estabilice, y no la mezcles con las mediciones habituales salvo que el arranque forme parte del requisito operativo. Repite cada prueba varias veces; informa de la mediana y de la variabilidad, no de la ejecución más favorable. Si la aplicación utiliza salidas estocásticas, fija la semilla cuando la herramienta lo permita o evalúa varias muestras con la misma política. Alterna el orden de las configuraciones si la carga térmica o del sistema puede cambiar durante la sesión. Repite las pruebas en condiciones próximas al despliegue, no solo con el equipo recién reiniciado.

5. Decide entre cuantización y tamaño de modelo

Evalúa primero si cada opción cumple los requisitos de calidad y rendimiento definidos de antemano. Descarta configuraciones que incumplan un criterio crítico, aunque destaquen en otra métrica. Entre las que pasan, compara el tiempo total, la latencia inicial, la memoria y la estabilidad de formato. Si una cuantización más agresiva del modelo grande mantiene la calidad necesaria y cabe en el hardware, puede ser preferible; si pierde precisión en una tarea sensible, un modelo menor con cuantización más conservadora puede dar mejores resultados. No hay una regla general que resuelva esa elección sin medir.

También es razonable que la mejor opción sea un modelo distinto del inicialmente previsto, o que el flujo derive tareas sencillas a un modelo rápido y reserve uno más capaz para casos difíciles. El estudio académico de Ollama mencionado antes encontró diferencias de rapidez y precisión entre modelos en su propio sistema RAG; sus resultados no se deben trasladar como garantía a otra configuración. Para justificar una decisión técnica, conserva los resultados por tipo de tarea y explica qué compromisos acepta el equipo. Si dos alternativas quedan muy próximas, considera la incertidumbre de las mediciones y repite la prueba antes de fijar una conclusión.

6. Límites y buenas prácticas

Un conjunto pequeño puede pasar por alto errores raros; uno demasiado parecido a los ejemplos de desarrollo puede favorecer la configuración ajustada a esos casos. Una puntuación agregada también puede disimular fallos por idioma, longitud, tipo de documento o clase minoritaria. Examina resultados desglosados y conserva ejemplos de errores. Si una diferencia está dentro de la variación entre ejecuciones, no la describas como una mejora concluyente sin más repeticiones o evidencia.

Los resultados de una investigación publicada en un entorno RAG académico son evidencia sobre ese trabajo y su configuración, no una evaluación de GGUF ni una recomendación universal. Del mismo modo, las cifras genéricas sobre una supuesta pérdida fija de calidad por nivel de cuantización no sustituyen una prueba con el modelo y la tarea concretos. Documenta la procedencia de los archivos, evita incluir datos personales en prompts de prueba sin autorización y establece revisión humana o mecanismos de rechazo cuando un error pueda causar daño. Tras desplegar, revisa periódicamente una muestra de uso real y repite el protocolo si cambian el modelo, el runtime, el hardware o el patrón de entradas.

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.