Small Experiments, Cheaper Decisions: A Case Study in Staged Promotion for Micro-Pretraining

Resumen Técnico: Experimentos Pequeños, Decisiones más Baratas

Planteamiento del Problema
El artículo aborda el compromiso operativo inherente al uso de ejecuciones de preentrenamiento cortas como filtros para presupuestos mayores. Si bien las ejecuciones cortas permiten el cribado de muchas configuraciones candidatas, corren el riesgo de promover configuraciones que parecen sólidas solo en horizontes de entrenamiento diminutos, pero que no logran sobrevivir a horizontos más largos, diferentes semillas o diferentes hosts de hardware. El estudio plantea esto no como un problema general de optimización de hiperparámetros (HPO), sino como un problema de "promoción por etapas" para un ejecutor de micro-preentrenamiento de nodo único y GPU única, fijo y auditable. El objetivo es determinar si un esquema de promoción de dos trabajadores, pequeño y auditable, puede retener una referencia de largo horizonte conocida e identificar y detener alternativas plausibles que no cumplan con los umbrales de continuación congelados, sin podar excesivamente el conjunto de candidatos basándose en señales tempranas inestables.

Metodología
El estudio emplea un protocolo de promoción por etapas de fidelidad múltiple sobre un ejecutor de micro-preentrenamiento fijo derivado de un trabajo previo [1]. El experimento utiliza una matriz de candidatos de doce condiciones, incluyendo una "referencia puente" (la mejor condición de un cribado previo), un comparador codicioso (greedy comparator), un control de alta penalización y varias variantes más pequeñas o locales.

El protocolo procede a través de las siguientes etapas en dos bloques de hosts heterogéneos (Windows con NVIDIA A100 y Linux con NVIDIA L40S):

1. Instrumentación (Etapa 0): Una prueba de humo de 2 minutos para verificar la funcionalidad del ejecutor.
2. Cribados Baratos (Etapas 1A–1C): Ejecuciones con presupuestos de 5 y 10 minutos. La pantalla de 10 minutos se replica con una nueva semilla (semilla 43) para evaluar la estabilidad.
3. Confirmación Replicada (Etapas 2A–2B): Los cuatro mejores candidatos de los cribados baratos se ejecutan durante 60 minutos utilizando las semillas 44 y 45.
4. Confirmación de Largo Horizonte (Etapas 3–3B): Los tres mejores candidatos de la puerta de 60 minutos se ejecutan durante 12 horas utilizando las semillas 46 y 47.

Reglas de Decisión y Umbrales
Las decisiones de promoción se rigen por "puertas congeladas" y umbrales predeclarados en lugar de algoritmos de búsqueda adaptativos:

• Política de Retención: El protocolo retiene explícitamente los valores de la referencia puente y de control independientemente del ranking de presupuesto corto para evitar descartar la línea base de largo horizonte.
• Criterios de Parada:
  • Comparador Codicioso: Debe estar dentro de 0.010 val_bpb (bits por byte de validación) de la referencia en todas las celdas de host-semilla (regla de casi equivalencia).
  • Centinela más Barato (d8/ar48): Debe estar dentro de 0.020 val_bpb de la referencia en la brecha media de 12 horas (regla de arquitectura más barata).
• Métricas: El punto final principal es val_bpb (menor es mejor), calculado sobre una partición de validación fija. El estudio utiliza estadísticas descriptivas (rangos, brechas, desviaciones estándar) en lugar de valores p, reconociendo el número limitado de semillas y los bloques de hosts heterogéneos.

Resultos Clave

1. Inestabilidad de los Cribados Tempranos: Los rankings tempranos fueron altamente inestables y sensibles al host. A los 5 minutos, las mejores condiciones diferían entre Windows y Linux. A los 10 minutos, la condición media mejor fue d8/ar48 (un modelo más pequeño), no la referencia puente. Una poda dura en esta etapa habría eliminado al ganador eventual.
2. Retención de la Referencia Puente: La puerta replicada de 60 minutos retuvo con éxito la referencia puente, que ocupó el primer lugar en las cuatro celdas de host-semilla. Esto permitió que la referencia puente procediera a la confirmación de 12 horas.
3. Confirmación Final: En el paquete de 12 horas, la referencia puente ocupó el primer lugar en las cuatro celdas de host-semilla (Windows/Linux × semillas 46/47).
   • El comparador codicioso falló la regla de 0.010 val_bpb en todas las celdas (brecha máxima: 0.022927).
   • El centinela más barato (d8/ar48) falló la regla de brecha media de 0.020 val_bpb (brecha media: 0.032786).
4. Frontera Costo-Calidad: Los modelos más pequeños procesaron significativamente más tokens dentro del mismo presupuesto de tiempo de ejecución (por ejemplo, d8/ar48 procesó ~10.09B de tokens frente a los ~7.28B de la referencia puente) pero aun así lograron un peor val_bpb final. Los resultados se anotan como "confundidos por capacidad", ya que la referencia puente es el modelo más grande (50.3M de parámetros) en comparación con las alternativas.
5. Contabilidad de Presupuesto: La rama ejecutada de 12 horas consumió 144 GPU-horas. El protocolo por etapas completo (incluyendo el cribado) totalizó 169.2 GPU-horas. Esto se compara contra contrafácticos contables: continuar los cuatro candidatos de 60 minutos habría costado 192 GPU-horas, y continuar los nueve candidatos de 10 minutos habría costado 432 GPU-horas.

Significancia y Reivindicaciones
El artículo reivindica explícitamente que su contribución es la disciplina metodológica en lugar de una nueva arquitectura o un optimizador superior.

• Disciplina Operativa: El estudio demuestra que una regla de promoción conservadora y por etapas (cribados baratos amplios, puertas intermedias replicadas, umbrales congelados y parada explícita) puede reducir eficazmente el gasto de largo horizonte mientras retiene una referencia de largo horizonte conocida.
• Advertencia de Estabilidad: Destaca que los cribados tempranos son insuficientes para podas agresivas; el ganador de largo horizonte eventual no fue el líder de presupuesto corto.
• Complementariedad: El protocolo se presenta como un registro de decisión de un practicante en el bucle que es complementario, no un reemplazo, de los sistemas de HPO automatizados como Hyperband, ASHA o BOHB.
• Alcance Modesto: Los autores enfatizan que los resultados están limitados al ejecutor, la matriz de candidatos y los bloques de hosts utilizados. El estudio no pretende probar la optimalidad global, ni afirma que la regla de promoción separe la calidad del flujo de trabajo de la capacidad del modelo, ya que la comparación final sigue estando confundida por la capacidad. El valor principal es la "disciplina" de detenerse cuando las ramas plausibles no cumplen con los criterios predeclarados.