Soup promete fine-tuning de modelo 8B em GPU de notebook com 4 GB

Uma ferramenta chamada Soup apareceu no Show HN prometendo algo que costuma exigir infraestrutura cara: fazer fine-tuning de um modelo de 8 bilhões de parâmetros em uma GPU de notebook com apenas 4 GB de VRAM. O projeto é open source sob licença Apache 2.0 e está publicado no GitHub.

A proposta do Soup é reduzir a fricção do fine-tuning de LLMs a um fluxo enxuto: um arquivo de configuração YAML e um comando. Segundo o README, a instalação e o primeiro treino ficam em três passos:

pip install "soup-cli[train]"
soup init --template chat
soup train

Como cabe um 8B em 4 GB

O truque central é o que o projeto chama de layer streaming. Em vez de manter todo o modelo base congelado na VRAM, a técnica alimenta a GPU com uma camada (decoder layer) por vez, direto da RAM do host, mantendo na placa apenas o adaptador que está sendo treinado. Combinado com quantização em 4 bits (NF4), isso faz um modelo de 8B, como o Llama-3.1-8B-Instruct, caber em uma placa de 4 GB.

A configuração relevante no soup.yaml:

training:
  stream_layers: true    # base sai da VRAM; só o adapter treina
  quantization: 4bit     # NF4, cabe 8B em 4 GB
  batch_size: 4
  stream_source: auto    # RAM quando cabe, disco NVMe quando não

Do SFT para os métodos de preferência

A novidade da versão v0.72.4 é que o layer streaming, antes restrito a supervised fine-tuning, agora roda também as perdas de preferência: DPO, ORPO, SimPO e KTO. O ponto delicado do DPO é que ele precisa de um modelo de referência para comparação, e uma segunda cópia dobraria o consumo de memória. O Soup resolve reaproveitando a mesma base transmitida, com os adaptadores desligados.

O projeto documenta os números medidos com honestidade, inclusive o custo real. Em uma RTX 3050 de 4 GB, o DPO com streaming teve pico de VRAM de 0,914x o pico do supervised fine-tuning; forçar um segundo modelo real no mesmo teste custou +730 MB (exatamente uma cópia dos pesos). Em contrapartida, a referência é de graça em memória, mas não em tempo: o DPO lê a pilha de camadas 1,52x mais vezes por passo que o SFT.

Segundo o README, os métodos grpo e ppo seguem propositalmente de fora, porque a geração relê cada camada por token, algo que o streaming não consegue amortizar. O autor também afirma que os resultados são bit-exatos contra uma execução normal, não transmitida, da mesma perda (diferença 0,0).

O que muda para quem constrói no Brasil

Para o desenvolvedor brasileiro, o gargalo de custo em IA raramente é a ideia, e sim a conta de GPU na nuvem em dólar. Uma ferramenta que roda fine-tuning localmente em uma placa de entrada abaixa a barreira de entrada para experimentação séria: dá para adaptar um modelo a um dataset próprio (atendimento, código, domínio jurídico ou médico) sem provisionar instância cloud.

A tabela de VRAM do projeto ajuda a calibrar expectativa com QLoRA 4-bit:

• 8 GB: até ~7B (Llama-3.1-8B, Mistral-7B)
• 16 GB: até ~14B (Phi-4, Qwen2.5-14B)
• 24 GB: até ~34B
• 48 GB: até ~70B

O fluxo vai além do treino: há comandos para exportar em GGUF (para uso com Ollama e llama.cpp), rodar um servidor compatível com a API da OpenAI (soup serve) e mesclar o LoRA na base (soup merge). Também há imagem Docker publicada no GHCR, para quem prefere não instalar CUDA e PyTorch localmente.

Ressalvas

O próprio projeto se descreve como BETA e é transparente quanto aos limites. Cenários como multi-GPU, validação em modelos maiores que 8B e Apple Silicon ficam atrás de gates de 'requires', porque, nas palavras do mantenedor, o Soup é construído e mantido em um único notebook de 4 GB, o que garante que os números de performance sejam medidos em vez de alegados. A técnica de layer streaming está descrita em um preprint no Zenodo, com os registros de medição no diretório benchmarks/, incluindo as falhas e suposições que se mostraram erradas.

Fonte: Hacker News