Mide el equipo antes de elegir modelo
Anota RAM instalada y disponible, memoria de la GPU si existe, espacio libre real y versión de Windows. Registra también qué aplicaciones están abiertas durante la prueba. La cifra instalada no equivale a la memoria que puede utilizar el proceso en ese momento.
Guarda una línea base sin modelo: tiempos de apertura, consumo en reposo y una tarea documental hecha con tus herramientas actuales. Después podrás comparar la configuración local con algo concreto, en lugar de confundir novedad con mejora.
RAM y VRAM no son casillas intercambiables
La VRAM disponible puede favorecer ciertas ejecuciones en GPU; la RAM del sistema interviene en el resto del proceso y en configuraciones que no cargan todo en la gráfica. La distribución depende del runtime y del modelo. No sumes ambas cifras como si formaran un único depósito universal.
Observa el monitor de recursos y los registros de la herramienta durante una carga conocida. Si aparece uso compartido, intercambio o una caída de velocidad, documéntalo con esa versión concreta. El dato describe tu PC y esa ejecución, no una ley para cualquier equipo.
Cuantización y contexto cambian dos variables distintas
La cuantización reduce la precisión numérica con la que se almacenan o calculan partes del modelo. Puede reducir requisitos y alterar calidad o compatibilidad, pero el efecto depende del modelo y del runtime. El contexto, por su parte, limita cuánta entrada puede considerarse de una vez y también influye en recursos.
Compara una variable cada vez. Mantén modelo, prompt, documentos y temperatura si ese parámetro está disponible; cambia solo la cuantización. Después repite con otra longitud de contexto. Si cambias todo a la vez, no podrás atribuir la diferencia a una decisión concreta.
Registro de configuración de muestra
- Equipo: identificador propio · versión de Windows · programas abiertos.
- Modelo: nombre y versión · licencia consultada · runtime y versión.
- Prueba A: cuantización registrada · contexto fijo · corpus sintético 01.
- Prueba B: solo cambia contexto · mismas preguntas · mismas referencias.
- Resultado: calidad por rúbrica · latencia observada · recursos y errores.
La prueba de calidad también va en español
Prepara preguntas con tildes, nombres propios ficticios, fechas y tablas. Incluye un documento cuya respuesta no consta y otro con una contradicción. Una ejecución rápida que inventa referencias no supera el criterio de aceptación.
Evalúa recuperación y respuesta por separado. Si el fragmento correcto no llega al contexto, el problema puede estar en la indexación; si llega pero se interpreta mal, corresponde revisar generación o instrucciones. Esta separación evita cambiar de modelo para resolver un fallo de RAG.
Prueba sin conexión y plan de salida
«Local» no debe darse por supuesto. Documenta qué deja de funcionar al desconectar la red y qué procesos siguen activos. Revisa también opciones de registros y telemetría de cada programa; la arquitectura de ejecución no responde por sí sola a todas las preguntas de privacidad.
Antes de adoptar la configuración, ensaya actualización, copia y desinstalación. Conserva instaladores o versiones cuando sus licencias lo permitan y anota dónde quedan modelos, índices y documentos. Si la calidad no es suficiente, una opción híbrida con aprobación humana puede ser más controlable que forzar todo el flujo en local.