AirLLM: um 70B em uma GPU de 4 GB, de verdade? Teste e limites

#A promessa do AirLLM: um 70B em 4 GB de VRAM

Um modelo 70B com quantização Q4 exige aproximadamente 40 GB de VRAM para ser carregado completamente na memória — ou seja, uma RTX 4090 (24 GB) mais uma segunda placa, ou um Mac Studio com grande capacidade de memória unificada. O AirLLM afirma que consegue fazer o mesmo modelo caber em uma placa de 4 GB, incluindo uma modesta GTX 1650 ou uma T4 gratuita do Google Colab. Isso não é um truque de marketing sobre o tamanho do modelo: é realmente o modelo 70B completo, em FP16 ou em 4/8 bits, que gera as respostas.

O segredo está em três palavras: o modelo nunca é carregado inteiro na VRAM. O AirLLM divide a rede em camadas (layers), armazena-as no disco e carrega apenas uma camada de cada vez no GPU durante o cálculo. A VRAM contém, portanto, apenas os pesos de uma camada mais as ativações atuais — daí a necessidade de apenas alguns gigabytes.

#Como funciona o streaming de camadas

Um LLM de tipo transformer é uma pilha de camadas idênticas em sua estrutura (atenção + feed-forward), percorridas uma após a outra. Um Llama 70B conta com 80. A inferência clássica carrega as 80 camadas na VRAM de uma só vez e mantém todas elas na memória durante toda a geração. AirLLM inverte esse princípio.

Divisão em disco

No primeiro carregamento, AirLLM divide os pesos do modelo em arquivos separados, um por camada, armazenados no SSD. Este passo de conversão é realizado apenas uma vez por modelo.

Carregamento on-demand

Para gerar um token, o motor carrega a camada 1 na GPU, calcula, libera a VRAM, carrega a camada 2, calcula e assim por diante até a camada 80.

VRAM constante

A qualquer momento, apenas uma camada reside na VRAM. O pico de memória depende da maior camada e do comprimento do contexto, e não do tamanho total do modelo.

Prefetch e quantização em disco

AirLLM pré-carrega a camada seguinte durante o cálculo da camada atual e pode compactar os pesos no disco (quantização por blocos) para reduzir o volume de dados lidos.

O gargalo fica evidente: a cada token gerado, é necessário ler todos os pesos do modelo a partir do disco. Para um modelo de 70B, isso representa várias dezenas de gigabytes transferidos do SSD para a GPU para um único token. É aí que se concentram todo o desempenho — e toda a limitação — do AirLLM.

#Pré-requisitos e instalação

AirLLM é uma biblioteca Python que se baseia em PyTorch e no ecossistema Hugging Face. Ela não é usada como Ollama (sem daemon, sem comando run): importa-se em um script Python. Veja o que é necessário antes de começar.

GPU

Qualquer placa NVIDIA com no mínimo 4 GB de VRAM (CUDA). Também há suporte a Apple Silicon (MPS) e CPU, mas essas opções são ainda mais lentas.

Disco

Um SSD NVMe rápido é indispensável, além de espaço para armazenar o modelo descomprimido (≈40 GB para um 70B, mais em FP16).

RAM do sistema

16 GB são suficientes; o AirLLM não carrega o modelo na RAM, ao contrário de um offload clássico para a CPU.

Python

Um ambiente Python 3.10+ com PyTorch e CUDA corretamente instalados

pip install airllm

#Executar um 70B com 4 GB: o teste

O código mínimo para carregar e consultar um Llama 70B cabe em cerca de quinze linhas. O AirLLM cuida da divisão em camadas na primeira chamada (reserve vários minutos para a conversão e o download do modelo do Hugging Face).

from airllm import AutoModel

# Le modèle est découpé en couches au premier chargement
model = AutoModel.from_pretrained("meta-llama/Meta-Llama-3.1-70B-Instruct")

input_text = ["Explique le layer streaming en une phrase."]
input_tokens = model.tokenizer(input_text,
                               return_tensors="pt",
                               truncation=True,
                               max_length=128,
                               padding=False)

generation_output = model.generate(
    input_tokens['input_ids'].cuda(),
    max_new_tokens=64,
    use_cache=True,
    return_dict_in_generate=True)

output = model.tokenizer.decode(generation_output.sequences[0])
print(output)

1. 01
   1. Primeiro carregamento

   AirLLM baixa o modelo e depois o converte em arquivos por camada no SSD. Essa etapa é demorada, mas só precisa ser realizada uma vez: as execuções seguintes reutilizam o cache de disco.
2. 02
   2. Configuração da compressão

   O parâmetro compression='4bit' (ou '8bit') reduz o volume lido do disco e, portanto, acelera a inferência, ao custo de uma leve perda de qualidade — a mesma troca entre desempenho e qualidade da quantização clássica.
3. 03
   3. Geração

   Cada token aciona uma leitura completa das 80 camadas a partir do SSD. A barra de progresso avança camada por camada: é visualmente lento, e é normal.
4. 04
   4. Medição

   Medir o tempo total e dividir pelo número de tokens gerados para obter sua taxa real em tokens/s. Esse é o único número que importa para decidir se a ferramenta é utilizável em seu caso.

#Benchmark real: quantos tokens por segundo?

É aqui que a promessa encontra a realidade física. Em um modelo de 70B carregado por streaming a partir de um SSD NVMe, muitas vezes não se fala em tokens por segundo, mas em segundos por token. A ordem de grandeza a ter em mente, segundo as configurações relatadas e nossos testes:

70B / NVMe PCIe 4.0 rápido

Em torno de 0,1 a 0,5 token/s, ou seja, 2 a 10 segundos para produzir uma única palavra. Uma resposta de 200 tokens leva vários minutos.

70B / SSD SATA

Ainda de 2 a 5 vezes mais lento: a taxa de transferência do disco fica limitada a cerca de 500 MB/s, e a geração cai para menos de 0,1 token/s.

Comparação: modelo 70B carregado na VRAM (2x RTX 4090)

15 a 30 tokens/s. A diferença em relação ao AirLLM é de um fator de 30 a 300, dependendo do disco.

Modelo 8B em Q4 em uma única RTX 3060 de 12 GB

40 a 80 tokens/s, sem nenhum streaming — para lembrar a dimensão da perda de conforto.

A fórmula é simples: a cada token, é necessário reler todo o modelo a partir do disco. Um 70B em 4 bits pesa cerca de 40 GB; a 5 GB/s de leitura em NVMe, isso já dá 8 segundos de entrada/saída pura por token, antes mesmo do cálculo. Nenhuma otimização de software pode contornar essa barreira enquanto os pesos estiverem no disco. A execução fica de 5 a 30 vezes mais lenta no melhor dos casos (modelos pequenos, disco muito rápido, compressão agressiva) e muito mais lenta nos modelos grandes.

#Casos de uso sem exageros

A 0,2 token/s, o AirLLM é inviável para conversar. Mas existem cenários reais em que a lentidão não é um problema, porque ninguém fica esperando diante da tela.

Processamento em lote (batch) off-line

Para um script que precisa processar 500 documentos com um modelo de 70B durante a noite, não importa que um documento leve 3 minutos: o resultado está pronto pela manhã. Esse é o caso de uso mais legítimo.

Experimentação pontual

Verificar o que um modelo específico de 70B responde a alguns prompts, sem alugar uma GPU na nuvem nem comprar hardware, para decidir se ele vale o investimento.

Extração estruturada não urgente

Gerar um conjunto de dados, anotar um corpus, produzir embeddings ou sínteses em segundo plano, quando a velocidade de processamento importa pouco.

Acesso a um modelo gigante sem orçamento

Estudante, pesquisador ou curioso com apenas uma pequena placa, que quer experimentar um modelo que não conseguiria rodar de outra forma.

#Quando é marketing

A fórmula 'um 70B em 4 GB' é tecnicamente verdadeira, mas é enganosa em termos editoriais sempre que se sugere um uso normal. Aqui estão as situações em que o AirLLM não cumpre suas promessas implícitas.

Chat interativo

Esperar vários minutos por uma resposta mata qualquer conversa. Para conversar, um modelo local de 8B ou 14B que responde instantaneamente é infinitamente mais útil do que um 70B que responde à velocidade de um fax.

Assistente de código em tempo real

A autocompletação e a programação em pares exigem respostas em poucos segundos. O AirLLM está a anos-luz de conseguir isso.

Servidor multiusuário

Impossível atender várias pessoas: cada token já monopoliza toda a largura de banda do disco para uma única requisição.

Produção

Nenhum serviço online pode depender do AirLLM. A latência e o desgaste do SSD (leituras massivas contínuas) o excluem de forma imediata.

#Alternativas: quantização clássica primeiro

Antes de recorrer ao streaming de camadas, esgote as soluções que mantêm o modelo na memória — elas são quase sempre preferíveis. A pergunta não é “como fazer um 70B caber em 4 GB”, mas “qual modelo realmente atende à minha necessidade”.

Reduzir a precisão da quantização

Um 70B em Q4_K_M cabe em ~40 GB; em Q2/Q3, cabe em muito menos. Mas um 70B quantizado de forma excessivamente agressiva perde qualidade: muitas vezes, é melhor um 32B em Q4 carregado adequadamente.

Escolher um modelo menor e recente

Um modelo de 32B (≈19 GB de VRAM) ou de 14B (≈9 GB) de 2026 rivaliza com um de 70B de 2024 na maioria das tarefas, enquanto roda instantaneamente em uma única placa.

Offload CPU/GPU do Ollama ou llama.cpp

Esses motores descarregam parte das camadas para a RAM do sistema quando a VRAM está escassa. Isso é mais lento que um carregamento completo na GPU, mas muito mais rápido que o AirLLM, pois a RAM é cem vezes mais rápida que um SSD.

Alugar um GPU na nuvem para necessidades pontuais

Para testar um verdadeiro 70B rapidamente uma única vez, uma hora de uso de uma GPU alugada custa pouco e oferece uma taxa de geração normal — muitas vezes mais econômico do que passar horas esperando com execução local.

#Para se aprofundar

AirLLM é uma ferramenta para contornar limitações: antes de usá-la, é melhor dominar as formas tradicionais de gerenciar a VRAM e escolher o modelo. Três guias do site complementam o panorama.

Escolher sua quantização (Q4, Q5, Q8, FP16)

Entender quanta qualidade um modelo perde em Q4 ou Q3 e como fazer um modelo grande caber em uma VRAM limitada sem recorrer ao streaming de disco.

Escolher sua GPU para IA local

Os compromissos entre VRAM, orçamento e desempenho, da RTX 3060 de 12 GB ao Mac Studio Ultra, para saber qual tamanho de modelo seu hardware realmente consegue suportar.

llama.cpp vs vLLM vs Exllama

Os motores de inferência e sua gestão do offload entre CPU e GPU, a alternativa séria ao AirLLM quando falta um pouco de VRAM.