Capítulo 6: LoRA, QLoRA y especialización. En este capítulo aprenderás qué cambia un adaptador, por qué la memoria no decide la calidad y cómo diseñar una comparación justa.

Especializar un modelo no significa volver a entrenarlo desde cero. LoRA congela los pesos base e introduce matrices pequeñas de bajo rango en módulos seleccionados. Durante el entrenamiento se actualizan esas matrices. El resultado puede conservarse como adaptador separado o fusionarse después, si la licencia y el proceso de validación lo permiten. La ventaja práctica es reducir la cantidad de parámetros entrenables, pero el ahorro no garantiza una mejor respuesta para la tarea elegida.

QLoRA aplica la misma idea sobre una base congelada cuantizada, normalmente a cuatro bits, y mantiene el cálculo del adaptador en una precisión mayor. Su objetivo es bajar el consumo de memoria. Esa reducción abre experimentos que quizá no cabrían con LoRA sobre BF16, pero introduce otra variable: la representación cuantizada usada durante el ajuste. En una arquitectura híbrida como Qwen3.5, esa variable merece una comparación explícita.

Para Ornith, LoRA BF16 es la referencia de calidad propuesta para un A/B futuro. QLoRA es una alternativa de menor VRAM. Ninguna de las dos es un resultado local conseguido. Existen ejecuciones comunitarias de QLoRA sobre Ornith, con configuraciones y pérdidas de entrenamiento publicadas, pero no ofrecen una evaluación downstream suficiente para declarar calidad preservada. Además, la documentación de Unsloth advierte sobre discrepancias de cuantización en Qwen3.5. La ejecutabilidad y la calidad son preguntas distintas.

También importa dónde se insertan los adaptadores. Copiar una lista típica de Llama, limitada a unas cuantas proyecciones de atención, puede dejar fuera partes esenciales. Ornith hereda proyecciones propias de la ruta híbrida, entre ellas componentes de atención lineal, además de atención completa y MLP. Los runs comunitarios incluyeron módulos como in_proj_qkv, in_proj_z, in_proj_a, in_proj_b y out_proj. Esa lista orienta una inspección; no reemplaza leer el árbol real del modelo y verificar nombres, dimensiones y gradientes.

El punto de partida debe ser el checkpoint BF16 original, no el GGUF cuantizado que sirve hoy. El servidor activo usa Ornith Q4_K_L con KV Q4, tres slots y sin mmproj externo. Ese baseline sirve para inferencia y para medir resultados, pero no es la base correcta para improvisar entrenamiento. El archivo DFlash sigue presente y apagado, y MTP no ha sido evaluado funcionalmente. AWQ W4A16 conserva una prueba cercana a 261K, sin concurrencia triple ni calidad equivalente demostrada. Las métricas históricas permanecen pendientes de trazabilidad. Conviene mantener todas estas rutas fuera del primer experimento de especialización para no añadir variables.

La procedencia debe oírse con claridad. Fuente A reúne la arquitectura, los runs comunitarios y la advertencia técnica sobre QLoRA, además del estado operativo local. Fuente B coincide en que LoRA y QLoRA deben partir de BF16 y compararse bajo un protocolo común. Consenso quiere decir que ambas investigaciones recomiendan prudencia; no convierte una ejecución ajena en un logro local. El audio organiza estas fuentes, pero el audio no vuelve una fuente evidencia local. Solo un entrenamiento reproducible, con artefactos y evaluación guardados, puede hacerlo.

Una especialización útil empieza por definir una conducta medible. Puede ser producir JSON conforme a un esquema, llamar herramientas con argumentos válidos o resolver un conjunto de tareas de código. El dataset debe tener procedencia, permiso de uso, separación de entrenamiento y validación, y controles contra secretos o datos personales. Si se entrena con ejemplos privados sin autorización, una buena métrica no arregla el problema.

La comparación justa usa el mismo dataset, split, longitud de secuencia, módulos objetivo, rango cuando sea técnicamente comparable, número de pasos y batería de evaluación. Se guardan el hash del checkpoint base, tokenizer, plantilla de chat, configuración, semilla, versiones, curvas de pérdida y checkpoints del adaptador. LoRA BF16 y QLoRA deben evaluarse contra el modelo sin adaptar. Una pérdida descendente solo indica que el optimizador ajustó el objetivo de entrenamiento; no prueba generalización.

Los gates tienen dos lados. El primero mide la especialidad: exactitud, ejecución de pruebas, JSON válido o éxito de herramientas. El segundo protege capacidades que no queríamos sacrificar: razonamiento general, español e inglés, contexto largo, seguridad y estabilidad. Si mejora la tarea estrecha, pero aumenta las llamadas inválidas o cae la calidad fuera del dominio, el adaptador no está listo.

La decisión tampoco debe descansar en una sola media. Hay que registrar resultados por ítem, variación entre semillas, fallos y casos límite. Cuando las diferencias sean pequeñas, se conserva la opción más simple hasta reunir más evidencia. Menos VRAM puede ser decisivo para investigar, pero no debe ocultar una degradación que aparece en tareas largas o raras.

Finalmente, fusionar o redistribuir requiere una puerta separada. La licencia efectiva de los pesos Ornith todavía necesita aclaración documental. El dataset y las herramientas tienen licencias propias. Hasta resolver ese ledger, un adaptador puede evaluarse de forma interna, con acceso controlado, sin asumir permiso para publicarlo.

Confirmado hoy… LoRA y QLoRA tienen fundamento técnico, existen runs comunitarios de QLoRA y el baseline operativo continúa en llama.cpp con Q4_K_L, KV Q4, tres slots y sin mmproj externo.

Falta demostrar… una comparación local LoRA BF16 contra QLoRA con el mismo dataset, módulos, secuencia y gates, además de la calidad downstream, la seguridad y los permisos de redistribución.

Siguiente capítulo… separaremos destilación, poda y supresión de idiomas para entender qué puede investigarse y qué límites no deben presentarse como resultados.