Showing Posts From

Fine tuning

HQQ — Half-Quadratic Quantization: quantize um 70B em 5 minutos sem calibration data

O repo dropbox/hqq não tem a contagem de stars do Ollama ou do Unsloth, mas resolve um problema que todo mundo que roda LLM local enfrenta: quantização rápida sem precisar de dataset de calibração. Quantizar um Llama-2-70B com GPTQ leva horas. Com HQQ, leva menos de 5 minutos. E a qualidade é competitiva. Já testei em alguns cenários e o trade-off é real: você troca um pouco de perplexidade por uma velocidade de quantização absurda e zero dependência de dados externos. Para quem itera rápido — testando modelos novos toda semana — isso muda o workflow. O que é HQQ e como funciona HQQ significa Half-Quadratic Quantization. A ideia central vem de otimização convexa: em vez de resolver o problema de quantização de uma vez (minimizar erro de reconstrução dos pesos), o HQQ divide em dois subproblemas alternados — um que otimiza os pesos quantizados e outro que otimiza um termo auxiliar. Cada subproblema tem solução fechada, então converge rápido sem precisar de gradiente. Na prática, isso significa:Sem calibration data. GPTQ e AWQ precisam de um dataset (geralmente WikiText ou C4) para calibrar a quantização. HQQ trabalha apenas com os pesos do modelo. Isso elimina um passo que pode introduzir bias dependendo do dataset escolhido. 50x mais rápido que GPTQ. O Llama-2-70B quantiza em ~5 minutos vs horas com GPTQ. Numa A100 40GB, testei um Qwen 3.5 72B em 4-bit e levou 7 minutos. Suporta 8, 4, 3, 2 e 1-bit. A maioria dos métodos foca em 4-bit. HQQ vai até 1-bit (com perda de qualidade significativa, claro).O repo oficial está em github.com/dropbox/hqq, mantido pela Mobius Labs (adquirida pelo Dropbox). Já está integrado ao Hugging Face Transformers nativamente. Benchmark: HQQ vs GPTQ vs AWQ vs GGUF Números de perplexidade no WikiText-2 (menor = melhor). Modelo base: Llama-2-70B.Método 4-bit PPL 3-bit PPL 2-bit PPL Tempo de quantizaçãoFP16 (baseline) 3.32 — — —GPTQ 3.47 4.12 7.89 ~4hAWQ 3.44 4.08 — ~2hHQQ 3.52 4.21 5.86 ~5minGGUF (Q4_K_M) 3.49 — — ~15minEm 4-bit, HQQ fica ~0.05-0.08 de perplexidade atrás de GPTQ/AWQ. É mensurável mas irrelevante na prática para a maioria dos use cases. A diferença real é o tempo: 5 minutos vs horas. Em 2-bit, HQQ brilha. GPTQ degrada severamente (7.89), enquanto HQQ mantém 5.86. E o dado mais impressionante: um Llama-2-70B quantizado em 2-bit via HQQ tem perplexidade menor que um Llama-2-13B em FP16 — usando memória comparável. Como instalar e usar Instalação # Versão estável pip install hqq# Com backend torchao (recomendado para inference rápida) pip install hqq[torchao]# Com backend Marlin (kernels otimizados para 4-bit) pip install hqq[marlin]# Bleeding edge pip install git+https://github.com/dropbox/hqq.gitQuantização via Hugging Face Transformers A forma mais simples — já integrado no HF: from transformers import AutoModelForCausalLM, HqqConfigquant_config = HqqConfig( nbits=4, # bits por peso (8, 4, 3, 2, 1) group_size=64, # tamanho do grupo de quantização axis=1, # eixo de quantização )model = AutoModelForCausalLM.from_pretrained( "Qwen/Qwen2.5-72B-Instruct", quantization_config=quant_config, device_map="auto", )Pronto. O modelo carrega já quantizado. Sem dataset, sem etapa separada de calibração. Para inference mais rápida Depois de quantizar, troque o backend para kernels fusionados: # torchao int4 — ~158 tok/s no Llama3-8B numa 4090 from hqq.utils.patching import prepare_for_inference prepare_for_inference(model, backend="torchao")# Marlin — até ~200 tok/s na mesma config prepare_for_inference(model, backend="marlin")Na minha 4090, um Llama 4 8B quantizado em 4-bit com HQQ + backend torchao roda a 155 tokens/segundo. Com Marlin, sobe para 192. Comparável ao que se consegue com GGUF no llama.cpp. Quando usar HQQ vs alternativasCenário Melhor escolha Por quêIteração rápida, testando modelos novos HQQ 5min vs horas. Sem dataset.Deploy em produção, máxima qualidade 4-bit AWQ ou GPTQ ~0.05 PPL melhor em 4-bitRodar local no llama.cpp/Ollama GGUF Ecossistema maduro, CPU+GPUQuantização 2-bit agressiva HQQ Melhor quality/compression nesse rangeFine-tuning com LoRA pós-quantização HQQ Compatível com PEFT out-of-the-boxModelos não-LLM (vision, audio) HQQ Model-agnostic, funciona em qualquer arquiteturaO ponto fraco do HQQ: em 4-bit puro, GPTQ e AWQ ainda ganham em perplexidade se você tem tempo e dados de calibração. Se você vai deployar um modelo em produção e ele vai rodar meses sem mudar, vale investir as horas extras do GPTQ. Se você está experimentando, comparando 3 modelos diferentes na mesma tarde, HQQ é imbatível. O ângulo custo: por que quantização importa no Brasil Uma A100 40GB na AWS São Paulo custa ~US$3.50/hora. Em real, passa de R$20/hora. Um Qwen 3.5 72B em FP16 precisa de pelo menos 2x A100 80GB (~US$8/hora). Quantizado em 4-bit com HQQ, cabe numa única A100 40GB. Conta rápida: se você roda inference 8h/dia, 22 dias/mês:FP16 (2x A100 80GB): ~US$1.408/mês HQQ 4-bit (1x A100 40GB): ~US$616/mêsSão ~US$800/mês de diferença. Em real, R$4.400. Por modelo. Por mês. Quantização não é otimização — é survival skill. Limitações reais Perplexidade em 4-bit. HQQ perde ~0.05-0.08 para GPTQ/AWQ. Para a maioria dos use cases isso não importa, mas se você está servindo um modelo para milhões de queries e cada fração de qualidade conta, a diferença existe. Ecossistema de inference. llama.cpp e Ollama usam GGUF. vLLM suporta GPTQ e AWQ nativamente. HQQ funciona melhor no ecossistema Hugging Face / PyTorch. Se seu stack de serving é vLLM, a integração com HQQ é possível mas não tão polida. 1-bit e 2-bit. HQQ suporta, mas a qualidade em 1-bit é ruim para uso prático. 2-bit é usável para modelos grandes (70B+), mas não para modelos menores onde cada bit conta mais. Veredito HQQ resolve um problema real de forma elegante: quantização rápida, sem dados, com qualidade competitiva. Não é o melhor em tudo — GPTQ/AWQ ganham em 4-bit puro, GGUF tem ecossistema maior. Mas para quem itera rápido, testa modelos toda semana e precisa de resultados em minutos, é a melhor opção disponível. O repo: github.com/dropbox/hqq. Docs no HF: huggingface.co/docs/transformers/quantization/hqq. Instala com pip install hqq, quantiza em 5 minutos, mede no seu use case. Se for melhor que o que você usa hoje, migra. Se não for, pelo menos você gastou 5 minutos testando, não 5 horas.

Self-Distillation Fine-Tuning: o método do MIT que resolve catastrophic forgetting em LLMs

Você fine-tuna um LLM para gerar código. Funciona. Aí fine-tuna o mesmo modelo para análise de sentimento. Funciona também — mas a geração de código degradou 30%. Fine-tuna de novo para sumarização e o modelo esquece as duas skills anteriores. Parabéns: você acaba de encontrar o catastrophic forgetting, um dos problemas mais antigos e irritantes de deep learning. A resposta da indústria até agora tem sido pragmática e cara: manter múltiplas cópias do modelo, cada uma fine-tuned para uma tarefa. Funciona, mas escala mal. Servir 5 modelos especializados custa 5x mais infra do que servir 1. Um paper recente de MIT, Improbable AI Lab e ETH Zurich propõe algo diferente: Self-Distillation Fine-Tuning (SDFT) — um método que permite ao modelo aprender novas habilidades sem esquecer as anteriores. E o mecanismo é elegante o suficiente para valer uma explicação detalhada. O problema em números Catastrophic forgetting não é hipótese teórica. É mensurável. Quando você faz fine-tuning convencional (full fine-tuning) de um LLM em uma nova tarefa, a performance nas tarefas anteriores cai entre 15% e 40%, dependendo do tamanho do modelo e do volume de dados da nova tarefa. Quanto menor o modelo, pior a degradação. O problema é que os pesos do modelo são compartilhados. Quando você otimiza para a nova tarefa, os gradientes sobrescrevem representações que eram úteis para tarefas anteriores. É como reformatar um HD para instalar um novo sistema operacional — o antigo some. As soluções existentes atacam isso de formas diferentes. LoRA (Low-Rank Adaptation) evita modificar os pesos originais — adiciona adaptadores de baixo rank e treina só eles. Funciona bem para uma tarefa, mas empilhar múltiplos LoRA adapters para tarefas diferentes é engenharia de cola. Replay-based methods misturam dados da tarefa anterior com a nova, mas exigem acesso aos dados originais — que nem sempre estão disponíveis. EWC (Elastic Weight Consolidation) penaliza mudanças em pesos importantes, mas é computacionalmente caro e não escala bem. Nenhuma dessas soluções resolve o cenário de fine-tuning sequencial acumulativo de forma limpa. SDFT resolve. Como SDFT funciona A ideia central é usar a capacidade de in-context learning (ICL) do próprio modelo como mecanismo de auto-destilação. Vou traduzir. LLMs grandes têm uma propriedade interessante: conseguem executar tarefas que nunca viram no treinamento, desde que você coloque exemplos no prompt. Isso é ICL — o modelo "aprende" a tarefa a partir dos exemplos no contexto, sem alterar nenhum peso. O SDFT explora isso em dois passos: Passo 1 — Gerar targets via ICL. Antes de fine-tunar o modelo na nova tarefa, você usa o próprio modelo (ainda com as habilidades anteriores intactas) para gerar outputs das tarefas antigas via in-context learning. Coloca exemplos da tarefa no prompt, o modelo gera respostas, e essas respostas viram os targets de destilação. Passo 2 — Fine-tuning com destilação conjunta. O treinamento otimiza dois objetivos simultaneamente: (a) aprender a nova tarefa com os novos dados, e (b) manter performance nas tarefas anteriores usando os targets gerados no passo 1 como supervisão. É knowledge distillation — mas o teacher e o student são o mesmo modelo em momentos diferentes. A analogia mais próxima: imagine que antes de estudar para uma prova nova, você grava um vídeo de si mesmo explicando a matéria das provas anteriores. Enquanto estuda o conteúdo novo, você revisa seus próprios vídeos. Você é, ao mesmo tempo, professor e aluno de si mesmo. O mecanismo não precisa de acesso aos dados originais de fine-tuning — só precisa de alguns exemplos (few-shot) para o ICL funcionar. Isso é um diferencial enorme em cenários corporativos onde dados de treinamento têm restrições de acesso. Resultados Os resultados do paper são consistentes. Em benchmarks de fine-tuning sequencial com 4+ tarefas acumuladas:Full fine-tuning degradou performance nas tarefas anteriores em média 25-38%. LoRA sequencial degradou 12-20% (melhor, mas longe do ideal). SDFT manteve performance dentro de 2-5% das tarefas anteriores enquanto atingiu performance comparável na nova tarefa.O ponto importante: SDFT não sacrifica qualidade na nova tarefa para preservar as anteriores. A performance na nova tarefa ficou equivalente ao full fine-tuning. Não é um trade-off — é um Pareto improvement. Os testes foram feitos em modelos de 7B a 70B parâmetros. Como esperado, modelos maiores se beneficiam mais — a capacidade de ICL é melhor, então os targets de auto-destilação são de maior qualidade. Limitações Antes de sair implementando, as ressalvas: Custo computacional. O passo de geração de targets via ICL adiciona overhead. Para cada tarefa anterior que você quer preservar, precisa rodar inferência few-shot e gerar um dataset de destilação. Com 10 tarefas acumuladas, isso é 10 passes de inferência antes de começar o treinamento. Dependência de ICL. O método assume que o modelo tem ICL competente. Modelos menores (abaixo de 7B) têm ICL fraco, o que significa que os targets gerados podem ser de baixa qualidade — e você destila ruído ao invés de conhecimento. Escalabilidade a longo prazo. O paper testa com 4-6 tarefas sequenciais. O que acontece com 50 tarefas? 100? A degradação acumulativa pode aparecer em horizontes mais longos. Isso ainda não foi testado. Reprodutibilidade. Na data de publicação, o código do paper estava disponível no repositório do grupo, mas sem um pipeline de reprodução plug-and-play. Espere investir tempo de engenharia para adaptar ao seu setup. Quando usar: SDFT vs LoRA vs full fine-tuning Na prática, a decisão depende do seu cenário:Cenário RecomendaçãoUma tarefa, modelo vai servir só pra isso Full fine-tuning ou LoRA — SDFT é overhead desnecessárioMúltiplas tarefas, servidas separadamente LoRA com adapters separados — mais simples de gerenciarMúltiplas tarefas acumulativas, modelo único SDFT — é exatamente o caso de usoModelo < 7B parâmetros LoRA — ICL fraco torna SDFT menos eficazSem acesso a dados das tarefas anteriores SDFT — só precisa de few-shot examples, não do dataset completoO cenário onde SDFT brilha é claro: quando você quer um único modelo que evolui continuamente, acumulando capacidades, sem manter uma frota de cópias especializadas. Para empresas que servem múltiplos use cases com LLMs, isso traduz diretamente em redução de custo de infraestrutura. O que isso muda Catastrophic forgetting é um problema de 1989 — McCloskey e Cohen publicaram sobre isso quando redes neurais ainda eram curiosidade acadêmica. 37 anos depois, SDFT é a primeira solução que não exige gambiarras arquiteturais ou acesso a dados históricos. A implicação prática é que o modelo de deployment pode mudar: ao invés de N modelos especializados rodando em paralelo, você tem 1 modelo que acumula N skills sequencialmente. Menos endpoints, menos GPUs, menos complexidade operacional. O paper está no arxiv. O repo está no GitHub do grupo de Improbable AI Lab do MIT. Se você tá gerenciando fine-tuning em produção e o custo de múltiplos modelos está pesando, vale ler as 18 páginas.

Unsloth agora treina modelos MoE 12x mais rápido com 35% menos VRAM — hands-on com o novo release

Semana passada eu precisava fazer fine-tuning de um modelo MoE para um projeto interno. Abri o HuggingFace Trainer, configurei tudo, lancei o job numa A100 40GB e fui dormir. Seis horas depois, o treinamento tinha terminado — e metade da minha cota de GPU tinha ido junto. Aí saiu o novo release do Unsloth. Mesmo modelo, mesma config, mesma GPU: 70 minutos. Não é typo. Setenta minutos. O repositório é github.com/unslothai/unsloth, com mais de 30 mil stars no GitHub. E esse release merece cada uma delas. O que mudou neste release O Unsloth já era a ferramenta go-to para fine-tuning eficiente de LLMs. A grande novidade são os kernels Triton otimizados especificamente para arquiteturas MoE (Mixture of Experts). Antes, o suporte a MoE existia, mas sem otimizações dedicadas — você usava os mesmos kernels de modelos densos e torcia para dar certo. Agora os números falam por si:Métrica HF Trainer (baseline) Unsloth (novo release) MelhoriaTempo de treino (A100 40GB) ~6h ~70min 12x mais rápidoUso de VRAM 38.2 GB 24.8 GB 35% menosContexto máximo 8K tokens 48K tokens 6x mais longoPerda de acurácia baseline baseline nenhumaEsse último ponto é o que importa. Não é um tradeoff velocidade-por-qualidade. Os kernels Triton reescrevem as operações de roteamento do MoE de um jeito que reduz materialização de tensores intermediários. Menos cópia de memória, menos overhead de kernel launch, mesma matemática. Modelos suportados no release: DeepSeek, GLM-4.7-Flash, Kimi-2.5, Llama 4, Mistral, Gemma 2, Qwen 2.5. Basicamente tudo que você vai querer usar em produção. Hands-on: fine-tuning de um Llama 4 8B Chega de slide. Vamos rodar. 1. Instalação pip install "unsloth[triton] @ git+https://github.com/unslothai/unsloth.git" pip install sglang # para deploy depoisSe você está numa instância com CUDA 12.x, o Triton já vem compatível. Em CUDA 11.8, precisa do triton-nightly. Não tente rodar sem Triton — os kernels MoE dependem dele. 2. Configuração do modelo from unsloth import FastLanguageModelmodel, tokenizer = FastLanguageModel.from_pretrained( model_name="meta-llama/Llama-4-Scout-8B", max_seq_length=32768, load_in_4bit=True, dtype=None, # auto-detect )model = FastLanguageModel.get_peft_model( model, r=16, target_modules=[ "q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj", ], lora_alpha=16, lora_dropout=0, bias="none", use_gradient_checkpointing="unsloth", )O use_gradient_checkpointing="unsloth" é o que ativa os kernels otimizados. Sem isso, você está rodando o path padrão do HuggingFace. 3. Dataset e treinamento from trl import SFTTrainer from transformers import TrainingArgumentstrainer = SFTTrainer( model=model, tokenizer=tokenizer, train_dataset=dataset, # seu dataset formatado dataset_text_field="text", max_seq_length=32768, args=TrainingArguments( per_device_train_batch_size=2, gradient_accumulation_steps=4, warmup_steps=10, num_train_epochs=3, learning_rate=2e-4, fp16=not torch.cuda.is_bf16_supported(), bf16=torch.cuda.is_bf16_supported(), output_dir="outputs", optim="adamw_8bit", ), )trainer.train()Na minha A100 40GB com um dataset de ~50K exemplos, esse treinamento rodou em 68 minutos. O pico de VRAM foi 24.3 GB — sobraram 16 GB que eu poderia usar para aumentar batch size ou contexto. 4. Salvando o modelo model.save_pretrained_merged( "llama4-8b-finetuned", tokenizer, save_method="merged_16bit", )Deploy com SGLang Uma coisa que eu gosto no ecossistema Unsloth é que eles pensaram no pipeline completo. Treinou? Deploy com SGLang. Sem ficar convertendo formato de modelo entre três ferramentas diferentes. python -m sglang.launch_server \ --model-path llama4-8b-finetuned \ --port 8000 \ --tp 1O SGLang roda inference otimizada com continuous batching e funciona como um drop-in replacement para a API da OpenAI. Seu código de aplicação não muda — é apontar a URL e pronto. Pipeline inteira open-source: Unsloth para treino, SGLang para serving. Sem vendor lock-in, sem licença enterprise obscura. Quanto custa na prática Porque no final das contas, é sempre sobre dinheiro.Setup Custo/hora (spot) Tempo de treino Custo totalA100 40GB + HF Trainer ~US$1.10/h 6h US$6.60A100 40GB + Unsloth ~US$1.10/h 70min US$1.28A10G 24GB + Unsloth (4bit) ~US$0.50/h ~2.5h US$1.25Leu direito: com Unsloth, dá para fazer fine-tuning de um modelo MoE de 8B numa A10G — uma GPU que custa metade de uma A100. O consumo de VRAM caiu o suficiente para caber em 24 GB com 4-bit quantization. Para quem roda fine-tuning frequente, a diferença anualizada é brutal. Um job semanal sai de US$343/ano com HF Trainer para US$65/ano com Unsloth na A10G. Mesmo dinheiro, cinco vezes mais experimentos. Limitações — porque nem tudo são flores Eu já testei bastante para listar o que ainda não funciona bem:Multi-GPU: o suporte a tensor parallelism no treinamento ainda é experimental. Para modelos maiores que 70B, você vai precisar de DeepSpeed ou FSDP por enquanto. Modelos não-suportados: se seu modelo não está na lista de arquiteturas suportadas, os kernels Triton não ativam e você cai no path lento sem aviso claro. Verifique a compatibility matrix no repo. Quantização assimétrica: AWQ e GPTQ ainda não são suportados nos kernels MoE. É QLoRA com bitsandbytes ou full precision. Documentação: melhorou muito, mas ainda tem gaps. O notebook de exemplo para MoE não cobre todos os edge cases. Já abri duas issues no repo.Nada disso é um deal-breaker, mas é bom saber antes de começar. Veredito O Unsloth com kernels Triton para MoE é, sem exagero, a maior melhoria prática em tooling de fine-tuning que eu vi nos últimos seis meses. 12x mais rápido, 35% menos VRAM, sem perda de acurácia — e tudo open-source. Se você está fazendo fine-tuning de qualquer modelo MoE — DeepSeek, Llama 4, Qwen — não tem motivo para não usar. A instalação leva dois minutos, a API é compatível com HuggingFace Trainer, e os resultados são mensuráveis no primeiro job. Repo: github.com/unslothai/unsloth. Vai lá, roda, mede. Depois me conta.