O que travou: o pico do MLX não é a memória do Mac

O perfil planejado para o 7B era: batch 1, acumulação de gradiente 2, 16 camadas, rank 8, gradient checkpointing, teto declarado de 14 GB de pico.

O problema foi outro limite. O lemon-model tem uma trava que encerra o treino quando a memória livre do sistema cai abaixo de 15%. Num Mac de 18 GB, o sistema, o navegador e o resto também ocupam memória unificada. Duas tentativas com o 7B pararam nesse corte com o pico do MLX ainda abaixo de 14 GB.

A lição: o número que o framework reporta é só uma parte. O que derruba a máquina é a soma.

O piloto que passou

A solução foi reduzir a pressão sem mexer no resto:

Parâmetro	Planejado	Piloto
camadas adaptadas	16	8
rank	8	4
batch	1	1
acumulação de gradiente	2	2
tamanho máximo de sequência	2048	4096
gradient checkpointing	sim	sim

Dados: 6 exemplos de treino e 1 de validação, tirados de um conjunto curado de repositórios meus, com 14.066 tokens de treino planejados. Três exemplos acima de 4.096 tokens foram removidos inteiros, sem truncar.

Resultado registrado:

• 6 iterações, 199,87 segundos, cerca de 130 tokens/s de treino.
• Pico de memória de 11,139 GB.
• Perda de validação na única linha de validação: 0,893 no passo 1, 0,881 no passo 6.
• Adapter final de 11,5 MB.

Numa comparação direta no exemplo de validação, a perda foi de 1,0660 na base para 1,0482 com o adapter.

Depois, uma expansão registrou seis treinos com sementes e configurações diferentes, todos abaixo do teto de 14 GB. Um deles, com semente 7, chegou a perda de validação de 0,883 com pico de 11,58 GB. Esses resultados continuam sendo evidência de treino em dados de desenvolvimento, não de desempenho no holdout.

O custo de usar o adapter

Medi a mesma geração com e sem adapter: tempo até o primeiro token subiu de 8,4 s para 9,4 s, e tokens por segundo caíram 10,9% (de 30,6 para 27,3). A medição foi feita com a máquina já sob pressão de memória depois do treino, então é uma estimativa, não um número de produção.

O que esses números não dizem

O relatório do lemon-model é explícito, e eu repito aqui:

• Uma comparação com um exemplo de validação não mede generalização.
• Não há avaliação de qualidade de código nem holdout limpo nesses pilotos.
• Nenhum adapter foi promovido.
• A verificação das fontes segue pendente, a licença consta como NOASSERTION e o conjunto de dados e o adapter permanecem privados, locais e não elegíveis para promoção.

O registro mostra que este treino limitado terminou no Mac e produziu um adapter com hash registrado. Não comprova direitos liberados, testes de código aprovados, qualidade, generalização ou prontidão para produção. Qualidade é o próximo post.

Três proteções que eu recomendo

• Execução com limites. O treino roda como subprocesso com ambiente limpo e offline, diretório temporário vazio e travas de tempo e memória que registram a quebra em vez de travar a máquina.
• Portão de dados. Exemplos de treino que vazam do conjunto de holdout são rejeitados antes do treino.
• Paridade de quantização. Servir o adapter sobre uma base com quantização diferente da usada no treino é proibido sem nova avaliação, e um teste impede isso.

Checklist: antes de treinar LoRA no seu Mac

• Meça a memória livre do sistema, não só o pico do framework.
• Comece com poucas camadas e rank baixo; aumente depois.
• Use gradient checkpointing e batch 1.
• Remova exemplos longos inteiros em vez de truncar.
• Registre hash da base, do adapter e dos dados.
• Meça o custo de latência do adapter.
• Não chame queda de perda num exemplo de melhoria de qualidade.

Conclusão

Neste perfil, um treino LoRA sobre base quantizada terminou num Mac de 18 GB quando respeitei a memória do sistema inteiro, e não só a do framework. O piloto é pequeno de propósito: 8 camadas, rank 4, 6 exemplos. Ele registra uma execução, não prova que o modelo ficou melhor em código. Essa pergunta precisa de outra ferramenta.

Na sexta: evals antes de hype, e por que o lemon-model trava a promoção de qualquer modelo que não passe por elas.

Se o seu time quer adaptar modelos abertos com dados próprios sem mandar código para fora, montar esse pipeline com limites e rastreabilidade é um trabalho que faço na LEMON.DEV.

Referências

• LoRA: Low-Rank Adaptation of Large Language Models
• QLoRA: Efficient Finetuning of Quantized LLMs
• mlx-lm, documentação de LoRA

Leituras relacionadas

• Um modelo de código local no Mac
• Self-hosting de pesos abertos e VRAM