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

Resumo Técnico: Experimentos Pequenos, Decisões Mais Baratas

Definição do Problema
O artigo aborda o tradeoff operacional inerente ao uso de execuções de pré-treinamento curtas como filtros para orçamentos maiores. Embora as execuções curtas permitam a triagem de muitas configurações candidatas, elas correm o risco de promover configurações que parecem fortes apenas em orçamentos minúsculos, mas que falham ao sobreviver a horizontes de treinamento mais longos, diferentes sementes ou diferentes hosts de hardware. O estudo enquadra isso não como um problema geral de otimização de hiperparâmetros (HPO), mas como um problema de "promoção em estágios" para um executor de micro-pré-treinamento de nó único, GPU única e fixo. O objetivo é determinar se um cronograma de promoção de dois trabalhadores, pequeno e auditável, pode reter uma referência de longo horizonte conhecida enquanto identifica e interrompe alternativas plausíveis que falham em atender aos limiares de continuação congelados, sem podar excessivamente o conjunto de candidatos com base em sinais iniciais instáveis.

Metodologia
O estudo emprega um protocolo de promoção em estágios de fidelidade múltipla em um executor de micro-pré-treinamento fixo derivado de trabalho anterior [1]. O experimento utiliza uma matriz de candidatos de doze condições, incluindo uma "referência de ponte" (a melhor condição de uma triagem anterior), um comparador ganancioso, um controle de alta penalidade e várias variantes menores ou locais.

O protocolo procede através dos seguintes estágios em dois blocos de hosts heterogêneos (Windows com NVIDIA A100 e Linux com NVIDIA L40S):

1. Instrumentação (Estágio 0): Um teste de fumaça de 2 minutos para verificar a funcionalidade do executor.
2. Triagens Baratas (Estágios 1A–1C): Execuções com orçamentos de 5 e 10 minutos. A triagem de 10 minutos é replicada com uma nova semente (semente 43) para avaliar a estabilidade.
3. Confirmação Replicada (Estágios 2A–2B): Os quatro principais candidatos das triagens baratas são executados por 60 minutos usando as sementes 44 e 45.
4. Confirmação de Longo Horizonte (Estágios 3–3B): Os três principais candidatos do portão de 60 minutos são executados por 12 horas usando as sementes 46 e 47.

Regras de Decisão e Limiares
As decisões de promoção são governadas por "portões congelados" e limiares predeclarados, em vez de algoritmos de busca adaptativos:

• Política de Retenção: O protocolo retém explicitamente os valores da referência de ponte e de controle, independentemente do ranking em orçamentos curtos, para evitar o descarte da linha de base de longo horizonte.
• Critérios de Interrupção:
  • Comparador Ganancioso: Deve estar dentro de 0.010 val_bpb (bits por byte de validação) da ponte em todos os cells de host-semente (regra de quase-equivalência).
  • Sentinela Mais Barato (d8/ar48): Deve estar dentro de 0.020 val_bpb da ponte no gap médio de 12 horas (regra de arquitetura mais barata).
• Métricas: O endpoint primário é o val_bpb (menor é melhor), calculado sobre um shard de validação fixo. O estudo utiliza estatísticas descritivas (ranks, gaps, desvios padrão) em vez de p-valores, reconhecendo o número limitado de sementes e os blocos de hosts heterogêneos.

Resultados Principais

1. Instabilidade das Triagens Iniciais: Os rankings iniciais foram altamente instáveis e sensíveis ao host. Aos 5 minutos, as melhores condições diferiam entre Windows e Linux. Aos 10 minutos, a condição média-melhor era d8/ar48 (um modelo menor), não a referência de ponte. Uma poda rígida nesta fase teria eliminado o vencedor eventual.
2. Retenção da Ponte: O portão replicado de 60 minutos reteve com sucesso a referência de ponte, que classificou em primeiro lugar em todos os quatro cells de host-semente. Isso permitiu que a ponte procedesse para a confirmação de 12 horas.
3. Confirmação Final: No pacote de 12 horas, a referência de ponte classificou em primeiro lugar em todos os quatro cells de host-semente (Windows/Linux × sementes 46/47).
   • O comparador ganancioso falhou na regra de 0.010 val_bpb em todos os cells (gap máximo: 0.022927).
   • O sentinela mais barato (d8/ar48) falhou na regra de gap médio de 0.020 val_bpb (gap médio: 0.032786).
4. Fronteira Custo-Qualidade: Modelos menores processaram significativamente mais tokens dentro do mesmo orçamento de tempo de parede (ex: d8/ar48 processou ~10.09B tokens vs. os ~7.28B da ponte), mas ainda assim alcançaram um val_bpb final pior. Os resultados são observados como "confundidos por capacidade", já que a referência de ponte é o maior modelo (50.3M parâmetros) em comparação com as alternativas.
5. Contabilidade de Orçamento: A ramificação de 12 horas executada consumiu 144 GPU-horas. O protocolo completo em estágios (incluindo triagem) totalizou 169.2 GPU-horas. Isso é comparado contra contrafactuais de contabilidade: continuar todos os quatro candidatos de 60 minutos teria custado 192 GPU-horas, e continuar todos os nove candidatos de 10 minutos teria custado 432 GPU-horas.

Significância e Alegações
O artigo afirma explicitamente que sua contribuição é a disciplina metodológica, e não uma nova arquitetura ou um otimizador superior.

• Disciplina Operacional: O estudo demonstra que uma regra de promoção conservadora e em estágios (triagens baratas amplas, portões intermediários replicados, limiares congelados e interrupção explícita) pode reduzir efetivamente os gastos de longo horizonte enquanto retém uma referência de longo horizonte conhecida.
• Aviso de Estabilidade: Ele destaca que as triagens iniciais são insuficientes para podas agressivas; o vencedor de longo horizonte eventual não era o líder de orçamento curto.
• Complementaridade: O protocolo é apresentado como um registro de decisão de "praticante no loop", complementar, e não um substituto para sistemas de HPO automatizados como Hyperband, ASHA ou BOHB.
• Escopo Modesto: Os autores enfatem que os resultados são limitados ao executor, matriz de candidatos e blocos de hosts específicos utilizados. O estudo não alega provar a otimalidade global, nem afirma que a regra de promoção separa a qualidade do workflow da capacidade do modelo, já que a comparação final permanece confundida por capacidade. O valor principal é a "disciplina" de interromper quando ramos plausíveis não atendem aos critérios predeclarados.