O Soup 0.74.0 corrige um erro de gestão de memória que podia fazer um treino com LoRA parecer muito mais exigente em GPU do que a configuração fazia prever. Publicada a 4 de setembro, a versão altera três caminhos de carregamento que colocavam o modelo base congelado em fp32, embora esses pesos não fossem atualizados pelo otimizador.
Nas notas da versão 0.74.0, o projeto afirma que um ensaio num H100 com Llama-3.1-8B e LoRA reduziu o pico de memória de 48 241 MiB para 18 658 MiB. O Soup descreve o resultado como uma redução de 2,59 vezes e indica que três repetições produziram resultados idênticos ao nível dos bytes. São medições do próprio projeto e a Aipolix não encontrou uma reprodução independente deste resultado específico. O pacote soup-cli 0.74.0 também está disponível no PyPI.
O problema estava no carregamento, não no tamanho do modelo
O ponto técnico decisivo é que o modelo base congelado era carregado com uma precisão numérica superior à necessária. Segundo o Soup, os três caminhos from_pretrained usados para texto, visão e áudio não definiam explicitamente o tipo de dados, pelo que a base acabava materializada em fp32. Num treino com LoRA, essa base permanece congelada e apenas um conjunto muito menor de parâmetros de adaptação é treinado.
A versão 0.74.0 passa a carregar uma base congelada com a precisão prevista pelo ficheiro de pesos do modelo. Quando o próprio modelo base é treinado integralmente, fp32 continua a ser usado de forma intencional. A redução de memória não resulta, portanto, de uma nova técnica de compressão nem de uma alteração de arquitetura; resulta de corrigir a representação de pesos que não precisam de ser otimizados.
O projeto também unificou a lógica que distingue um ajuste completo. Antes, o treinador e a verificação prévia de memória tinham implementações separadas e podiam chegar a conclusões diferentes. Agora usam a mesma decisão sobre se o modelo base é treinável.
Uma diferença de 28,9 GB pode mudar a escolha do GPU
A principal conclusão de engenharia da Aipolix é que os valores assumidos pelo software de treino devem fazer parte do planeamento de capacidade. Uma equipa pode escolher corretamente o modelo, a quantização e a configuração LoRA e, ainda assim, obter uma estimativa enganadora se o software de treino alterar silenciosamente a precisão efetiva no momento do carregamento.
No ensaio H100 publicado pelo Soup, a diferença indicada no pico de memória foi de 28,9 GB. É uma margem suficiente para alterar a decisão sobre o acelerador, obrigar a uma instância maior ou mudar as contas económicas de um processo de ajuste eficiente em parâmetros.
A consequência prática vai além do Soup. O dimensionamento deve confirmar o tipo de dados efetivamente carregado e se a base está congelada, e depois comparar o pico de memória medido com a estimativa inicial. O que está escrito na configuração não é prova suficiente quando o software de treino ou uma dependência podem alterar a forma como os pesos são colocados em memória.
A versão também reforça limites de segurança
O Soup 0.74.0 inclui outras alterações relevantes nas superfícies de serviço e ferramentas.
O projeto voltou a ativar /v1/tools/bash, agora com isolamento por espaços de nomes e isolamento adicional ao nível do sistema operativo. Como esse caminho executa código, soup serve passa a terminar com código 2 quando é exposto num endereço que não seja local sem --tool-auth-token; anteriormente emitia apenas um aviso. A versão também bloqueia quatro formas alternativas de representar endereços IPv4 que podiam contornar a validação de destinos de telemetria, webhooks e OTLP. Na integração SGLang, o carregamento de código remoto passa ainda a respeitar --trust-remote-code em vez de ficar implicitamente ativo.
Estes comportamentos são descritos nas notas da própria versão. Do ponto de vista operacional, a mudança importante é transformar algumas condições de risco que antes geravam aviso ou dependiam de um valor implícito em recusa explícita ou consentimento deliberado.
Há mais compatibilidade, mas uma limitação continua em aberto
A versão acrescenta compatibilidade com Transformers 5.x, TRL 0.29 e PEFT 0.20, volta a permitir a combinação de extras train,mlx e admite descodificadores de texto da família Qwen3.5 no caminho Transformers. Surge também um comando de treino para Lambda que prepara primeiro o plano, mantém a chave de API no sistema local e deixa a terminação da instância sob controlo de um processo local.
As mesmas notas reconhecem uma limitação concreta: o mínimo declarado torch>=2.5.0 não funciona, na prática, com trl>=0.29. O projeto mediu a falha no torch 2.5.1 devido à ausência de FSDPModule. Uma instalação nova que resolva uma versão mais recente de Torch pode não ser afetada, mas um ambiente fixo em 2.5.x pode perder suporte para DPO, KTO, GRPO e BCO.
É um detalhe importante para operações: o facto de o gestor de pacotes conseguir resolver as dependências não significa que aquela combinação tenha sido validada em execução.
A redução de 2,59 vezes não deve ser generalizada
O resultado de memória é relevante, mas pertence a um cenário concreto. Foi medido pelo próprio projeto num H100 com Llama-3.1-8B e LoRA. O Soup relata três repetições idênticas, mas não há reprodução independente identificada pela Aipolix para o resultado da versão 0.74.0.
Por isso, não é defensável prometer a mesma redução em todos os modelos, GPUs, modos de quantização ou percursos de treino. A afirmação sustentada é mais limitada: o Soup corrigiu um caminho de carregamento em fp32 e mediu uma redução grande numa configuração documentada.
O carregamento por camadas, outra funcionalidade do Soup destinada a treinar grandes modelos base congelados em GPUs pequenas, continua explicitamente em fase beta.
O que convém verificar depois da atualização
As equipas que já usam Soup devem repetir o trabalho que serviu de base ao dimensionamento original. Convém registar o tipo de dados realmente carregado, os picos de memória GPU alocada e reservada, se o modelo base está congelado, a configuração LoRA e as versões exatas de Soup, Torch, Transformers, TRL e PEFT.
A pergunta útil não é apenas se a versão 0.74.0 usa menos memória. É perceber se o consumo real passou a corresponder suficientemente às premissas de capacidade para confiar na escolha da instância e na estimativa de custos.
Esta versão mostra como uma técnica eficiente pode perder essa vantagem abaixo da camada do algoritmo. LoRA pode reduzir o número de parâmetros treináveis, mas uma escolha implícita do software de treino pode materializar os pesos congelados com uma precisão desnecessariamente cara. Corrigir esse limite pode ter um impacto económico tão importante como alterar o método de treino.