Capítulo 8: Plan seguro de experimentos y gates de calidad. En este capítulo aprenderás a convertir hipótesis sobre Ornith en pruebas aisladas, reproducibles y reversibles.

Un buen plan no empieza por la técnica más llamativa. Empieza por congelar el punto de comparación. Hoy el baseline operativo es llama.cpp con Ornith Q4_K_L, KV Q4, tres slots y sin mmproj externo. Antes de cambiarlo hay que registrar hash del modelo, procedencia, licencia disponible, versión y commit del runtime, comando completo, drivers, hardware, plantilla de chat, sampler y límites de contexto. Las métricas históricas que no incluyan esa trazabilidad permanecen fuera del baseline.

La primera fase no acelera ni entrena nada. Construye el paquete de medición. Debe incluir tareas ejecutables de código, validación de JSON contra esquemas exactos, llamadas de herramientas, preguntas pareadas en español e inglés, contexto largo con posiciones variables, estabilidad prolongada y pruebas de seguridad. Cada ítem necesita una regla de aprobación verificable. Las preferencias humanas pueden acompañar el conjunto, pero no sustituir los tests automáticos cuando existe una salida objetiva.

La segunda fase inspecciona artefactos. Hay que confirmar qué tensores contiene el GGUF activo, si conserva MTP y qué componentes visuales quedan separados. El archivo DFlash solo está presente y apagado; se registra su hash y origen sin cargarlo todavía. MTP no ha sido evaluado funcionalmente. También se documenta AWQ W4A16 como una prueba cercana a 261K, sin atribuirle concurrencia triple ni calidad equivalente con el servidor llama.cpp.

La tercera fase compara pesos sin cambiar el KV. Q4_K_L se enfrenta a otra variante usando prompts, semillas, muestreo, contexto y concurrencia iguales. Se guardan salidas por ítem, memoria, errores y tiempos cold y steady-state. Solo después se abre la cuarta fase: comparar KV Q4 con otra precisión sobre el mismo quant ganador provisional. Pesos y KV son ejes separados; modificarlos juntos impediría explicar una regresión.

La quinta fase estudia aceleración especulativa. MTP, un draft clásico y DFlash ocupan perfiles distintos. En cada perfil se mide tasa de aceptación, tokens propuestos y aceptados, latencia, throughput, VRAM, estabilidad y calidad. Un runtime que reconoce un método no demuestra utilidad en esta combinación. DFlash no se enciende en producción durante el ensayo. Primero se prueba en un entorno aislado, sin tráfico real y con rollback inmediato.

La sexta fase aborda especialización. LoRA BF16 funciona como referencia experimental y QLoRA como alternativa de menor memoria. Ambas parten del checkpoint BF16, usan el mismo dataset autorizado, split, targets, longitud y batería. QLoRA no se trata como avance conseguido. Una pérdida de entrenamiento favorable no abre el gate; hacen falta resultados downstream, retención general, seguridad y repetición entre semillas.

La poda queda después. Antes de retirar estructura se validan dependencias de la arquitectura híbrida, visión, MTP y estado recurrente. Ornith-1.5-9B es denso, por lo que la poda de expertos se descarta. Cualquier prueba estructural ocurre sobre una copia, con recovery y rollback. La eliminación de idiomas tampoco entra como objetivo de optimización. Si existe una necesidad de producto, se prefieren controles externos reversibles y se habla de supresión conductual bajo un protocolo definido.

Los gates deben ser explícitos. Código exige cero regresiones nuevas en pruebas ejecutables. JSON exige cero errores nuevos contra el esquema. Herramientas exige cero llamadas inválidas nuevas. Español e inglés requieren evaluación pareada, intervalo de confianza y margen acordado antes de correr. Contexto largo mantiene la misma longitud y concurrencia, sin nuevos OOM ni corrupción. Estabilidad exige repeticiones, percentiles y una prueba prolongada. Safety bloquea cualquier variante que aumente acciones no autorizadas, obediencia a inyección o exposición de secretos.

La procedencia acompaña cada celda. Fuente A sostiene el estado local y la prueba aislada de AWQ. Fuente B aporta propuestas y detalle histórico que aún necesitan reproducción. Consenso identifica puntos donde ambas investigaciones coinciden, como separar pesos, KV, MTP y DFlash. La coincidencia no promueve una hipótesis a resultado. Este audiolibro organiza el razonamiento, pero el audio no vuelve una fuente evidencia local. Solo el paquete de ejecución, con artefactos verificables, puede cambiar el estado.

Cada corrida debe producir un expediente pequeño: identificador, hipótesis, única variable modificada, configuración, hashes, logs, salidas, resultados por ítem, incidentes y decisión. Las decisiones posibles son avanzar, repetir o rechazar. Repetir no es fallar; corresponde cuando la variación, un error del harness o la falta de datos impiden decidir. Rechazar conserva el resultado negativo y evita que reaparezca meses después como una idea sin historial.

La licencia y la privacidad también son gates. No se redistribuyen pesos, adaptadores fusionados, quants o drafts hasta aclarar la licencia efectiva de los pesos y las obligaciones heredadas. Los datasets deben excluir secretos y datos privados no autorizados. El sandbox usa permisos mínimos, red denegada por defecto y aprobación humana para acciones irreversibles. La búsqueda de velocidad nunca elimina estas condiciones.

Al final, el Atlas no elige una tecnología por entusiasmo. Construye una cadena de evidencia. Cada fase hereda un baseline aprobado y cambia una variable. Si una variante es más rápida pero rompe herramientas, queda fuera. Si usa menos memoria pero degrada español o seguridad, queda fuera. Si mejora bajo el mismo protocolo y supera todos los gates, pasa a una prueba limitada antes de producción.

Confirmado hoy… existe un baseline operativo claro en llama.cpp y una taxonomía de gates para código, JSON, herramientas, idiomas, contexto largo, estabilidad y safety.

Falta demostrar… hashes y trazabilidad completos del baseline, comparaciones controladas de pesos y KV, MTP, DFlash, LoRA, QLoRA y cualquier poda, además de la reproducibilidad de las métricas históricas.

Siguiente capítulo… la próxima iteración del Atlas deberá escuchar estos guiones junto con los expedientes de prueba y actualizar cada estado solo cuando aparezca evidencia reproducible.