PEFT não resolve memória em dispositivos: entenda o problema

O mito da eficiência de memória em fine-tuning

Você já assumiu que reduzir parâmetros treináveis automaticamente economiza memória? A pesquisa Parameter Efficiency Is Not Memory Efficiency mostra que essa suposição é falsa, especialmente quando o objetivo é rodar fine-tuning em dispositivos como celulares ou Raspberry Pi. Métodos populares como LoRA e IA3 diminuem os parâmetros ajustáveis, mas o consumo de memória ainda escala com o comprimento da sequência devido aos tensores intermediários. Na prática, isso significa que mesmo com poucos parâmetros, você pode estourar a memória de um dispositivo edge ao processar textos longos.

O fato: LARS propõe uma abordagem diferente

O artigo introduz o LARS (Low-memory Activation-Rank Subspace), um framework que ataca a causa raiz do alto consumo de memória: o espaço de ativação durante o treinamento. Enquanto LoRA e IA3 aplicam restrições de baixo rank nos parâmetros do modelo, o LARS restringe o subespaço de ativação, desacoplando o consumo de memória do comprimento da sequência. Os resultados são expressivos: redução de 33.54% na memória em GPUs e 51.95% em CPUs comparado ao LoRA, mantendo acurácia e throughput competitivos. O método foi testado em tarefas de raciocínio, compreensão e contextos longos, com modelos variados e também em hardware real como Raspberry Pi.

Como funciona: visão de operador

Para quem trabalha com deploy de LLMs, o gargalo não está nos parâmetros, mas nos tensores de ativação que crescem linearmente com o comprimento da sequência. Em LoRA, durante o forward pass, as ativações ocupam O(batch * seq_len * hidden_dim) de memória. Se você ajusta um modelo 7B com sequência de 2048 tokens, cada ativação consome ~16MB por camada, acumulando rapidamente. O LARS contorna isso projetando as ativações em um subespaço de baixo rank durante o treinamento, de forma que a memória fique O(batch * rank * hidden_dim), onde rank é muito menor que seq_len. Isso não é mágica: é uma mudança arquitetural que corta o principal consumidor de memória. O custo adicional é uma operação de projeção que o artigo mostra ser leve, com throughput similar ao LoRA. A implementação provavelmente usa operadores customizados para a projeção low-rank, mas o paper não detalha a API pública.

O que isso muda na prática

Quem ganha? Desenvolvedores de aplicações mobile e IoT que querem personalizar LLMs no próprio dispositivo, sem depender de nuvem. Quem perde? Talvez ninguém, mas o LARS pode não se aplicar bem a cenários onde a sequência já é curta (ex: sumarização de uma frase), pois o overhead da projeção pode não compensar. A ação prática imediata: se você está usando LoRA para fine-tuning on-device e bate em OOM, experimente substituir por LARS — o código está disponível nos repositórios do artigo (provavelmente). Mas cuidado: a acurácia pode variar dependendo da tarefa; os testes mostraram competitividade, mas não superioridade universal.

Tensão: escala e custo

O LARS resolve o gargalo de memória, mas introduz complexidade adicional na pipeline de treinamento. A projeção low-rank adiciona uma etapa de pré-processamento das ativações, o que pode aumentar a latência em dispositivos com pouca capacidade de computação paralela (como uma CPU de Raspberry Pi). O artigo reporta throughput competitivo, mas em cenários de produção com múltiplos usuários, será que o LARS escala? E o custo de implementar essa projeção em kernels otimizados para cada hardware? Pode ser que a redução de memória venha com um aumento no tempo de treinamento, trocando um gargalo por outro. Vale a pena testar com seu cenário específico.

Conclusão

PEFT não é sinônimo de eficiência de memória, e o LARS mostra que é possível atacar o verdadeiro vilão: as ativações. Se você está construindo aplicações de edge AI, essa pesquisa é um sinal para repensar suas suposições. Mas lembre: o diabo está nos detalhes de implementação. Leia o artigo original em arxiv.org/abs/2604.22783 e veja se o LARS se encaixa no seu stack.