Bug de CPU-Offload do DeepSpeed Corrompeu Benchmarks de RLHF em Três Grandes Frameworks

Um bug no otimizador de CPU-offload do DeepSpeed vinha corrompendo silenciosamente pipelines de fine-tuning por reforço no TRL, OpenRLHF e Llama-Factory — três dos frameworks open-source de RLHF mais amplamente implantados — invalidando comparações de benchmark publicadas e revertendo conclusões de pesquisa que favoreciam o treinamento de política mista em detrimento das abordagens padrão SFT-then-RL.

A descoberta vem de um artigo no arXiv, "SFT-then-RL Outperforms Mixed-Policy Methods for LLM Reasoning", de Alexis Limozin, Eduard Durech, Torsten Hoefler, Imanol Schlag e Valentina Pyatkin. O artigo identifica dois bugs distintos. O defeito principal é um bug no otimizador com CPU-offload do DeepSpeed que descarta silenciosamente micro-batches intermediários durante a acumulação de gradiente — modelos treinados nessa configuração nunca recebem o sinal de gradiente completo. Um segundo defeito, menor, é um bug de agregação de loss no OpenRLHF que pondera incorretamente os losses por mini-batch. Ambos suprimem o desempenho do SFT sem gerar erros ou avisos, tornando-os quase impossíveis de detectar sem uma comparação controlada.

O bug do otimizador do DeepSpeed responde pela maior parte do dano. Por estar na camada de infraestrutura — dentro do tratamento de estado do otimizador acionado quando o CPU offloading está ativo — ele se propaga a qualquer framework que envolva o DeepSpeed com CPU offload habilitado. TRL, OpenRLHF e Llama-Factory se enquadram nessa categoria, o que significa que qualquer resultado de benchmark produzido nas configurações padrão ou comuns desses frameworks deve ser tratado como potencialmente comprometido.

A consequência prática é uma caracterização sistematicamente equivocada do baseline SFT-then-RL. Inúmeros artigos publicados relataram que métodos de política mista — que intercalam ou mesclam sinais de aprendizado supervisionado e por reforço — superavam o pipeline sequencial padrão. Uma vez corrigidos os bugs, os autores encontram o oposto: um pipeline SFT-then-RL limpo supera todos os métodos de política mista avaliados em +3,8 pontos nos benchmarks de matemática com Qwen2.5-Math-7B, e em +22,2 pontos com Llama-3.1-8B. Uma variante truncada do SFT-then-RL rodando apenas 50 passos de RL ainda supera os métodos de política mista nos benchmarks de matemática com menos FLOPs totais.

Para equipes de engenharia de ML corporativo, a implicação imediata é a necessidade de auditoria. Qualquer comparação interna de benchmark executada contra um baseline de política mista usando TRL, OpenRLHF ou Llama-Factory com CPU offload do DeepSpeed habilitado é suspeita. Jobs de treinamento que pareciam convergir corretamente podem ter aprendido a partir de atualizações de gradiente sistematicamente incompletas. O risco não é apenas que os números do leaderboard estejam errados — é que decisões de arquitetura tomadas com base nesses números (qual framework adotar, se investir em infraestrutura de política mista, como dimensionar orçamentos de computação) foram feitas sobre uma fundação corrompida.

A remediação exige identificar se o CPU offload estava ativo em execuções anteriores, aplicar patches ou versões atualizadas dos frameworks que corrijam o comportamento de acumulação de gradiente do DeepSpeed, e re-executar avaliações de baseline com configurações corrigidas. O artigo não especifica números de versão para o código corrigido; as equipes devem monitorar as notas de versão do DeepSpeed, TRL, OpenRLHF e Llama-Factory em busca de correções e verificar com execuções de referência controladas.

O problema mais profundo é a falha silenciosa na camada de infraestrutura. Ao contrário de um loss NaN ou de uma divergência óbvia, bugs de acumulação de gradiente que descartam micro-batches produzem curvas de treinamento com aparência plausível — os modelos aprendem, o loss diminui, e nada sinaliza o problema. Pesquisas publicadas que usaram esses frameworks como baselines não tinham mecanismo para detectar a corrupção. A correção dos autores não exige novos algoritmos; exige medição precisa. O pipeline padrão estava vencendo o tempo todo — uma vez medido corretamente. Esse resultado valida a abordagem clássica e alerta sobre como ferramentas silenciosamente quebradas podem distorcer a trajetória de um subcampo inteiro.