70B em uma GPU de 4 GB? Eu testei (2 minutos por token)

Ver no idioma original →

Autoria: Prompt Engineer 48 · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: 70B on a 4GB GPU? I Tested It (2 Minutes Per Token) · Canal: Prompt Engineer 48 · 15:43 · Assistir no YouTube

Tópicos: Avaliação e benchmarks de IA, Inferência e otimização de modelos, Infraestrutura e hardware de IA, Modelos locais e open source

Resumo

O vídeo testa o Air-LLM com o modelo Qwen 2.5-72B Instruct e confirma que ele consegue rodar sem quantização usando menos de 4 GB de memória da GPU. No setup testado, porém, cada token levou cerca de 121,5 segundos, principalmente porque os pesos precisavam ser lidos do disco. Com 4-bit e cache aquecido, o Air-LLM chegou a 24,9 segundos por token; já o llama.cpp com um modelo 4-bit levou cerca de 3,4 segundos por token, mas exigiu muito mais memória do sistema. O Air-LLM pode ser útil para executar um modelo que não cabe em outros setups, desde que a lentidão e o espaço em disco não sejam um problema.

Pontos-chave

• O pico de memória medido no modo de 16 bits foi de 2.391 MB pelo Torch e 2.675 MB pelo NVIDIA-SMI, abaixo do limite de 4 GB.
• O Air-LLM divide o modelo em arquivos por camada e carrega uma camada por vez; para cada token, precisa processar as 80 camadas.
• O modelo ocupou 136 GB em arquivos de 16 bits, e a preparação inicial exigiu espaço livre em disco de aproximadamente o dobro do tamanho do download.
• No setup testado, a geração em 16 bits levou 121,5 segundos por token; o autor atribui a lentidão principalmente à leitura dos arquivos do disco.
• A execução 4-bit levou 24,9 segundos por token com cache aquecido, mas 117,5 segundos no primeiro token, sem aquecimento.
• O autor identificou no código do Air-LLM um possível bug na verificação de espaço para o modo 4-bit e contornou essa checagem apenas no próprio script de benchmark.
• O llama.cpp com um modelo 4-bit gerou cerca de 0,29 token por segundo, ou 3,4 segundos por token, usando aproximadamente 44 GB de memória do sistema.
• O teste foi limitado a um prompt, três tokens gerados, uma execução por configuração e uma GPU alugada; os resultados podem variar conforme disco, RAM e cache.
• O Air-LLM pode fazer sentido para tarefas pontuais ou em lote quando um modelo não cabe em outro lugar, mas não é adequado para chat interativo nesse setup.

Capítulos

Início	Capítulo	Resumo
00:00	A promessa de rodar um modelo de 70B em 4 GB	O apresentador introduz a medição de memória e a lentidão observada, e examina as alegações do Air-LLM.
02:06	Como o Air-LLM carrega o modelo e estimativa de velocidade	O vídeo explica o carregamento camada a camada, calcula o volume de dados lido por token e descreve o setup do teste.
04:47	Preparação, falhas e método de medição	O apresentador relata problemas com pods anteriores e mostra como monitorou memória, leitura do disco e tempo de geração.
08:29	Teste 4-bit e comparação com llama.cpp	O teste quantizado revela diferenças entre a execução fria e o cache aquecido, e é comparado com o llama.cpp.
12:36	Limites do teste e como reproduzi-lo	O apresentador separa as alegações que não testou, detalha como repetir o experimento e informa o custo dos pods.
14:10	Veredito: quando o Air-LLM faz sentido	O vídeo resume os resultados e recomenda o Air-LLM para execuções pontuais, não para chat interativo.

Citações

A alegação é verdadeira, mas esse também é o motivo pelo qual você provavelmente não deveria usar isso para chat. — 00:00

A alegação de memória se sustenta e ainda sobra margem. — 06:21

Dá para rodar um modelo de 70 bilhões em uma GPU de 4 GB sem quantização? Sim. Dá para conversar com ele? Não. — 07:27

É rápido? Não, cerca de 2 minutos por token em 16 bits neste setup. — 14:42

Conceitos e entidades

• Air-LLM (repo): Projeto que executa modelos grandes carregando uma camada por vez na GPU a partir de arquivos no disco.
• Qwen 2.5-72B Instruct (modelo): Modelo de 72,7 bilhões de parâmetros usado no teste do Air-LLM.
• llama.cpp (ferramenta): Ferramenta usada para comparar a geração com uma versão 4-bit do mesmo modelo.
• NVIDIA-SMI (ferramenta): Utilitário usado para monitorar a memória da GPU durante as execuções.
• RunPod (empresa): Serviço de nuvem usado para alugar pods com GPU para os testes.
• quantização de 4 bits (conceito): Representação comprimida do modelo testada como alternativa ao modo padrão de 16 bits.
• cache do sistema operacional (conceito): Memória que pode manter os arquivos do modelo disponíveis após a primeira leitura, reduzindo o custo de leituras posteriores do disco.

Tradução completa (pt-BR)

00:00 Este é um modelo com 72 bilhões de parâmetros, e o pico de memória da GPU durante a execução foi de 2.391 megabytes. Isso fica abaixo dos 4 gigabytes prometidos pelo projeto. Agora, veja a próxima linha do log. Três tokens levaram 364 segundos. Isso dá cerca de 2 minutos para cada token. Então, a afirmação é verdadeira — e também é o motivo pelo qual você provavelmente não deveria usar isso para conversar. No final, vou mostrar exatamente o que testei, com os logs reais na tela. Vou dizer em qual situação essa solução faz sentido e em qual situação um modelo comum de 4 bits é 35 vezes

00:32 mais rápido. E, antes de medir qualquer coisa, anotei uma estimativa da velocidade. Errei por um fator de dois, e vou mostrar por quê. Certo, vamos começar pelo repo. Este é o repo Air-LLM. Você pode ver que ele tem cerca de 36,9 mil estrelas, aproximadamente 3.800 forks, e a licença é Apache 2.0. A versão mais recente é a 4.0.0, de 5 de setembro. O projeto lançou três versões desde meados de agosto. E o primeiro parágrafo do readme diz: “O Air-LLM permite que modelos com 70 bilhões de parâmetros sejam executados em uma

01:04 única GPU de 4 gigabytes, sem quantização, destilação ou poda.” Depois, a coisa fica ainda maior. Kimi K3, com 2,8 trilhões de parâmetros, em menos de 4 gigabytes. QN 3.8 flash next, com 125 bilhões, em 6, e DeepSeek V3, com 671 bilhões, em cerca de 12. Vale lembrar que o readme diz que essas medições foram feitas de ponta a ponta em uma única RTX 4090, uma única RTX 3090 e uma única RTX 6000 Ada. São medições do próprio projeto. Não consegui encontrar um

01:34 benchmark independente para nenhum deles. Eis o que verifiquei. Pesquisei no readme por tokens por segundo, segundos por token, latência e throughput. Nenhum resultado. Não há nenhum número de velocidade para a afirmação sobre os 70 bilhões. O readme informa a memória. Não informa a velocidade. Mais um detalhe. Role até a seção sobre compressão do modelo. Ela diz que a compressão pode acelerar a inference em até três vezes e que é uma quantização em blocos. Então, a manchete sobre não usar quantização se refere ao modo padrão. O modo rápido é quantizado. Testei os dois e vou mostrar o que cada um faz. E a própria

02:06 lista de atualizações do readme traz duas observações antigas sobre velocidade. Em dezembro de 2023, a pré-busca proporcionou uma melhoria de velocidade de 10%, e a compressão era anunciada como uma aceleração de três vezes. Então, como um modelo com 72 bilhões de parâmetros cabe em menos de 4 GB? Ele não fica lá. O Air-LLM divide o modelo em um arquivo por camada no seu disco. Carrega uma camada na GPU, executa, descarta e carrega a próxima. São 80 camadas, uma de cada vez, para cada token. A seção de perguntas frequentes do readme diz que a etapa de divisão consome bastante espaço em disco, então confira se você tem

02:37 espaço suficiente. Tenha isso em mente, porque será importante mais adiante. Agora, vamos fazer as contas, porque é daí que vem meu ceticismo. Em 16 bits, este modelo ocupa cerca de 136 GB em arquivos de camada. Para produzir um token, todas as camadas precisam ser lidas do disco. Então, um token significa ler cerca de 136 GB. A GPU não é o gargalo; é o disco. Agora, este é um número que calculei por conta própria, então considere que é apenas minha conta. Este modelo tem 80 camadas. 136 GB divididos por 80 dá cerca de 1,7 GB por camada. Então, a manchete dos 4 GB

03:10 na verdade significa uma camada na GPU, mais a memória de trabalho. O pico que medi, cerca de 2,3 GB, corresponde aproximadamente a uma camada mais o restante do processo. Presumi que a unidade NVMe fosse rápida, por volta de 3,5 GB por segundo. 136 dividido por 3,5 dá cerca de 39 segundos. Então, minha previsão, anotada antes de executar qualquer coisa, foi de 30 a 60 segundos por token. Escreva sua própria estimativa nos comentários. No final, vou dizer quem chegou mais perto. Não executei isso no meu laptop. Meu laptop tem uma RTX 4060 com 8

03:43 GB e cerca de 120 GB de espaço livre em disco. Este modelo precisa de aproximadamente 145 GB só para ser baixado. Então, aluguei uma instância de GPU com uma RTX A5000 de 24 GB por US$ 0,27 por hora. Isso significa que a placa é muito maior do que 4 GB. Por isso, não avalio a afirmação pelo tamanho da placa. Avalio pelo pico de memória realmente usado pelo processo. Registrei dois números: o contador de pico do próprio Torch e o NVIDIA-SMI. Escolhi o Qwen 2.5-72B

04:14 Instruct porque ele não tem acesso restrito, então qualquer pessoa pode repetir o teste. São 72,7 bilhões de parâmetros, portanto não são exatamente 70. O download tem 37 arquivos e 145,4 GB. Nessa instância, terminou em 72 segundos. O disco é a parte que não é rápida. Medi com DD: 251 MB por segundo na gravação e 601 MB por segundo na leitura. Lembre-se disso: 601. A instalação é um comando de uma linha: pip install AirLLM, versão 4.0.0, com Torch 2.8 e Transformers 5.19. Depois,

04:47 a primeira execução divide o modelo em arquivos de camada. Isso levou 361 segundos para a versão de 16 bits e gravou 136 GB. Então, você precisa de aproximadamente o dobro do tamanho do modelo em espaço livre em disco para começar. Essa é a pegadinha mencionada nas perguntas frequentes do readme e o primeiro custo real da promessa dos 4 GB. Devo contar que a primeira tentativa falhou. Minha primeira instância era uma RTX 4090 na nuvem comunitária. O download e a divisão deram certo. Depois, quando o Air-LLM acessou a GPU, o Torch travou com a mensagem “CUDA unknown error.”

05:19 Chamei o driver diretamente, e ele retornou o código 999. Reiniciei uma instância, e o erro foi o mesmo. Criei uma segunda instância em outro host, e o erro foi o mesmo. Então, não era uma máquina com defeito. Excluí as duas e aluguei uma RTX A5000 na nuvem segura. Dessa vez, o Torch indicou que o CUDA estava funcionando, e tive que baixar e dividir tudo de novo. Então, os números que você vai ver vêm todos dessa terceira instância. Veja como fiz as medições. O script inicia uma thread de monitoramento. A cada segundo, ela consulta o NVIDIA-SMI para obter a memória usada e lê os

05:49 bytes que esse processo transferiu do armazenamento. Depois, cronometra a chamada de geração com um cronômetro simples e consulta o contador de pico de memória do próprio Torch. Dois números de memória independentes, um cronômetro, nada escondido. Primeiro, a afirmação sobre a memória: um prompt com 20 tokens, “explique em duas frases por que ler os pesos do modelo do disco é o gargalo”. Registrei o pico. O pico foi de 2.391 megabytes segundo o contador do Torch e de 2.675 segundo o NVIDIA-SMI. A afirmação era de 4 gigabytes, ou seja, 4.096 megabytes. Então, a afirmação sobre a memória se confirma, e

06:21 ainda sobra espaço. Então, os méritos são devidos: o projeto disse que caberia, e cabe. Quero deixar isso bem claro antes de chegar à parte menos agradável. E a resposta saiu como texto de verdade. O modelo produziu as palavras “lendo os pesos do modelo”; são três tokens, e já volto ao motivo de ter gerado apenas três. Agora, o número que ninguém informou: um novo token levou 107,7 segundos. Três novos tokens levaram 364,6 segundos, o que dá 121,5 segundos por token. Minha previsão foi de 30 a 60

06:53 segundos. O número real é cerca do dobro do limite superior da minha faixa, então errei. Por quê? Porque o disco dessa instância lê a 601 megabytes por segundo, não a 3,5 gigabytes que presumi. O monitor mostra leituras de até cerca de 2 gigabytes por segundo no pico e uma mediana de 710. Então, o disco é o gargalo, e a velocidade exata depende do seu disco e de quanto dele o sistema operacional deixou no cache. Agora, por que apenas três tokens? Porque veja só: uma resposta normal, com cerca de 200 palavras, tem aproximadamente 270 tokens. 270 vezes 121,5 segundos são 32.805 segundos,

07:27 ou seja, 9,1 horas para uma resposta. Então, se a pergunta é: uma GPU de 4 gigabytes consegue executar um modelo de 70 bilhões sem quantização? A resposta é sim. Se a pergunta é: dá para conversar com ele? A resposta é não. E quero ser justo sobre o que testei. Um prompt, três tokens gerados, uma execução, uma GPU alugada e um disco de rede. Então, considere os 121 segundos como o valor medido nessa configuração, não como uma lei da natureza. Se você tiver um NVMe local rápido, seu resultado pode ser menor. Adoraria ver o seu. Vou ler o log devagar, então

07:58 Nada está oculto. Carregar e dividir leva 361 segundos. Isso acontece uma vez; depois, execute com um token e, em seguida, com três tokens. Repare que as duas execuções mostram o mesmo pico: 2.391 e depois 2.393. A memória não aumenta com o número de tokens. Essa parte da alegação é sólida. Agora, deixa eu conferir se meus próprios números fazem sentido. 136 GB são cerca de 146 bilhões de bytes. Dividindo por 121,5 segundos, dá aproximadamente 1,2 GB por segundo. Isso é mais rápido do que os 601

08:29 MB por segundo que medi com DD. Então, o prefetching e o cache estão ajudando aqui, até mesmo com os arquivos de 16 bits. Sem eles, seria mais lento do que 121. Teste três. O README diz que a compressão de 4 bits oferece até três vezes mais velocidade. Então, executei o mesmo modelo, com o mesmo prompt, usando compressão de 4 bits, mas ele se recusou a iniciar. Veja este erro: espaço insuficiente. O tamanho total do modelo é 481 GB, mas os arquivos de 4 bits têm apenas cerca de 39 GB. Então, de onde vêm os 481? Abri o

09:00 código. Este é o utils.py no repo, linhas 447 a 468. Para 4 bits, a linha 458 divide o tamanho por 0,2813. Então, multiplica por cerca de três e meio, em vez de reduzir o tamanho. Isso parece um bug. Ignorei apenas essa verificação no meu próprio script de benchmark, e a execução funcionou. A divisão levou 352 segundos e gravou 39 GB, contra 136 GB para a versão de 16 bits. Agora, a velocidade. O primeiro token levou 117,5 segundos. Esse é

09:30 o tempo da execução a frio, e não é mais rápido do que em 16 bits. Na verdade, é um pouco mais lento. Depois, a execução com três tokens levou 74,8 segundos, ou 24,9 segundos por token. Isso é quase cinco vezes mais rápido do que 121. Então, a alegação de três vezes é verdadeira? Eis o que acho que está acontecendo. Este pod dá ao processo cerca de 50 GB de memória. Os arquivos de 4 bits têm 39 GB; então, depois da primeira passagem, ficam no cache do sistema operacional, e o token seguinte vem da memória, não do disco. Os arquivos de 16 bits têm 136 GB. Eles não cabem. Então,

10:03 cada token exige uma leitura do disco. Portanto, o aumento de velocidade é real, mas acontece porque os arquivos são pequenos o suficiente para permanecer na RAM. Se a sua máquina tem memória suficiente, ótimo. Se não, o número da execução a frio é o que você vai obter. E lembre-se: esse modo é quantizado, então a manchete “sem quantização” já não se aplica aqui. O pico de memória da GPU neste modo foi de 3.059 MB segundo o torch, ainda abaixo de 4 GB. Na execução de 4 bits, o monitor do disco mostra uma mediana de 449 MB por segundo. Os arquivos são menores, então o disco tem menos trabalho.

10:34 A pergunta justa é: o que mais daria para fazer com o mesmo hardware? Então, executei o llama.cpp com a versão Q4KM de 4 bits do mesmo modelo. Esse arquivo tem 44 GB. Deixei apenas sete camadas na GPU, o que usa cerca de 4,7 GB de memória da GPU; o restante fica na memória do sistema. O resultado: 0,29 token por segundo na geração. Isso dá cerca de 3,4 segundos por token. Com zero camadas na GPU, foi 0,28, quase igual. A GPU faz pouca diferença quando os pesos ficam na memória

11:04 porque o limite é a largura de banda da memória. Vamos comparar lado a lado: AirLLM em 16 bits, 121,5 segundos por token. AirLLM em 4 bits com o cache aquecido, 24,9. E llama.cpp em 4 bits, cerca de 3,4. Então, o llama.cpp é cerca de 35 vezes mais rápido do que o AirLLM em 16 bits e cerca de sete vezes mais rápido do que o AirLLM em 4 bits. Uma resposta de 200 palavras levaria cerca de 15 minutos no llama.cpp e mais de 9 horas no AirLLM em 16 bits. Mas esta não é uma

11:34 comparação justa. Então, veja o que cada um exige. O llama.cpp precisa de cerca de 44 GB de memória do sistema para esse arquivo. O AirLLM precisa de quase nenhuma memória do sistema e de cerca de 2,6 GB na GPU, mas precisa dos arquivos das camadas no disco: 136 GB em 16 bits. E o AirLLM mantém a precisão original, enquanto este arquivo do llama.cpp é de 4 bits. Então, é uma troca. Se você tem RAM, o llama.cpp vence por uma grande margem. Se não tem RAM, o AirLLM é o que

12:05 ainda funciona. O AirLLM poderia ser mais rápido? Não testei isso, então é um raciocínio meu, não um resultado. Cada token lê todas as 80 camadas uma vez, faça você o que fizer. Então, qualquer coisa que permita processar mais tokens por passagem pelo disco deve reduzir o custo de leitura do disco por token. Por exemplo, executar vários prompts juntos em um único lote. Não testei, então não vou dar um número. A outra alavanca é mais simples: um disco mais rápido ou mais RAM para o cache. A execução em 4 bits mostrou isso. Mesma GPU, mesmo código, e um cache aquecido reduziu o tempo de 117 para 25. O README

12:36 também alega que é possível executar o Kimi K3, com 2,8 trilhões, em menos de 4 GB, e treinar um modelo de 125 bilhões em menos de seis. Não testei nada disso. O modelo Qwen de 125 bilhões precisa de cerca de 360 GB de disco, como o próprio README informa. Então, considere esses números alegações do projeto, não minhas. E, mais uma vez, os limites do meu teste: 72,7 bilhões de parâmetros, não exatamente 71; um prompt de 20 tokens; três tokens gerados; uma execução de cada. Se você executar na sua máquina, seus números serão

13:07 diferentes, e quero ver quais são. Deixe nos comentários o tipo de disco e a quantidade de RAM. Se quiser repetir o teste, foi exatamente isto que executei: pip install AirLLM; depois, AutoModel.from_pretrained com o repo do Hugging Face e um caminho para salvar os fragmentos das camadas em um disco com bastante espaço. Para o modo de 4 bits, adicione compression equals 4-bit e instale bitsandbytes primeiro. Se aparecer o erro de espaço que mostrei, o problema é o bug da linha 458, não o seu disco. Depois, chame generate com um número pequeno de novos tokens. Três bastam para obter um número de velocidade.

13:38 Não comece com 200, a menos que queira deixar executando durante a noite. E anote o tipo de disco, a quantidade de RAM e se era a primeira execução ou uma repetição. Essas três coisas explicam a maior parte da diferença entre o seu número e o meu. Quanto custou tudo isso? A cobrança do RunPod mostra cerca de 47 centavos de tempo de pod para o projeto inteiro. Isso inclui os dois pods que falharam e o que funcionou. Então, você não precisa de um grande orçamento para conferir as alegações de um projeto. Precisa de alguns dólares, um plano e paciência para repetir o download quando um host dá problema. Antes do veredito, aqui está um quadro-resumo das alegações que consegui

14:10 testar. Modelo de 70 bilhões em 4 GB: confirmado nas medições. Sem quantização: confirmado no modo padrão. Até três vezes mais rápido com 4 bits: quase cinco vezes mais rápido com o cache aquecido e um pouco mais lento a frio; e o README nem sequer apresenta um número de velocidade. Não testei as grandes alegações sobre o Kimi e o modelo de 125 bilhões. Vou colocar tudo em uma tabela. Memória: 16 bits, 2,6 GB segundo o nvidia-smi. 4 bits, 3,2. llama.cpp, 4,7 com sete camadas na GPU. Velocidade: 121

14:42 segundos por token em 16 bits; 117 a frio e 25 com o cache aquecido em 4 bits; e 3,4 no llama.cpp. Então, a resposta: o AirLLM consegue executar um modelo de 70 bilhões em menos de 4 GB? Sim. Medi 2,3 GB pelo torch e 2,6 pelo nvidia-smi. É rápido? Não. Nesta configuração, leva cerca de 2 minutos por token em 16 bits. E eu estimei entre 30 e 60 segundos. Em que situação faz sentido? Quando você tem um modelo que não cabe em nenhum outro lugar, pode esperar e tem bastante espaço em disco.

15:12 Tarefas em lote durante a noite, verificações pontuais, experimentar um modelo enorme uma vez. Quando não faz sentido? Em chats, com agents, ou em qualquer situação em que você fique esperando a resposta. Um modelo de 4 bits no llama.cpp é cerca de 35 vezes mais rápido. E quem vence a aposta é quem tiver escrito nos comentários o número mais próximo de 121. Obrigado por arriscarem um palpite. Isso também me fez anotar o meu. Neste vídeo, vimos o que o AirLLM realmente faz em uma GPU pequena, com números que o README não informa. Se quiser experimentar no seu próprio sistema, o link do repo está na descrição e

15:43 me conte qual velocidade você obteve. Vejo você em outro vídeo. Confira o próximo vídeo.

Transcrição original

[00:00] This is a 72-billion parameter model and the GPU memory peak while it ran was 2391 megabytes. That is under the 4 gigabytes the project promises. Now, look at the next line in the log. Three tokens took 364 seconds. That is about 2 minutes for every single token. So, the claim is true and it is also the reason you probably should not use this for chat. I’ll show you exactly what I tested with the real logs on screen at the end. I’ll tell you the one setup where this makes sense and the setup where a plain 4-bit model is 35 times

[00:32] faster. And before I measured anything, I wrote down a guess for the speed. I was wrong by a factor of two and I’ll show you why. All right, let’s go ahead and start with the repo. This is the Air-LLM repo. You can see it has about 36.9 thousand stars, about 3,800 forks, and the license here is Apache 2.0. The latest release is version 4.0.0 from the 5th of September. The project has shipped three releases since the middle of August. And the first paragraph of the readme says, “Air-LLM lets 70-billion parameter models run on a

[01:04] single 4-gigabyte GPU without quantization, distillation, or pruning.” Then it goes bigger. Kimi K3 at 2.8 trillion parameters in under 4 gigabytes. QN 3.8 flash next 125 billion on 6 and DeepSeek V3 671 billion on about 12. Now, mind you, the readme says those were measured end-to-end on one RTX 4090, one RTX 3090, and one RTX 6000 Ada. Those are the projects’ own measurements. I could not find an

[01:34] independent benchmark for any of them. Here’s the thing I checked. I searched this readme for tokens per second, seconds per token, latency, and throughput. Zero matches. There is no speed number for the 70-billion claim. The readme tells you the memory. It does not tell you the speed. One more detail. Scroll down to model compression. It says compression can speed up inference by up to three times and it is block-wise quantization. So, the headline without quantization is the default mode. The fast mode is quantized. I tested both and I’ll show you what each one does. And the Readme’s

[02:06] own update list has two older speed notes. In December 2023, pre-fetching gave a 10% speed improvement and compression was advertised as a three times speed up. So, how does a 72 billion parameter model fit in under 4 GB? It does not stay there. RLLM splits the model into one file per layer on your disk. It loads one layer into the GPU, runs it, throws it away, and loads the next one. 80 layers one at a time for every single token. The Readme FAQ says the splitting step is very disk-consuming, so make sure you have

[02:37] the space. Keep that in mind because it matters later. Now, let’s do the math because this is where my skepticism comes from. In 16-bit, this model is about 136 GB of layer files. To produce one token, every layer has to come off the disk. So, one token means reading about 136 GB. The GPU is not the bottleneck, the disk is. Now, here is a number I worked out myself, so treat it as my arithmetic. This model has 80 layers. 136 GB divided by 80 is about 1.7 GB per layer. So, the 4 GB headline

[03:10] really means one layer on the GPU plus working memory. The peak I measured, about 2.3 GB, is roughly one layer plus the rest of the process. I assumed a fast NVMe drive around 3 and 1/2 GB per second. 136 / 3.5 is about 39 seconds. So, my prediction, written down before I ran anything, was 30 to 60 seconds per token. Write your own guess in the comments. I’ll tell you at the end who got closest. I did not run this on my laptop. My laptop has an RTX 4060 with 8

[03:43] GB and about 120 GB of free disk. This model needs about 145 GB just to download. So, I rented a GPU pod and RTX A5000 with 24 GB for $0.27 an hour. That means the card is much bigger than 4 GB. So, I do not judge the claim by the size of the card. I judge it by the peak memory the process actually used. I logged two numbers, Torch’s own peak counter and NVIDIA-SMI. I picked Qwen 2.5-72B

[04:14] instruct because it is not gated, so anybody can repeat this. It is 72.7 billion parameters, so it is not exactly 70. The download is 37 files, 145.4 GB. On this pod, it finished in 72 seconds. The disk is the part that is not fast. I measured it with DD, 251 MB per second writing and 601 MB per second reading. Remember that, 601. Install is one-line pip install AirLLM version 4.0.0 on Torch 2.8 with Transformers 5.19. Then,

[04:47] the first run splits the model into layer files that took 361 seconds for the 16-bit version and it wrote 136 GB. So, you need roughly double the model size in free disk to get started. That is the gotcha the README FAQ was talking about and it is the first real cost of the 4 GB headline. I should tell you the first attempt failed. My first pod was an RTX 4090 in the community cloud. The download and the split worked. Then, when AirLLM touched the GPU, Torch crashed with quote “CUDA unknown error.”

[05:19] I called the driver directly and she went in it returned 999. I restarted a pod, same error. I made a second pod on a different host, same error. So, it was not one bad machine. I deleted both and rented an RTX A5000 in the secure cloud. This time Torch printed CUDA okay and I had to download and split everything again. So, the numbers you will see all come from that third pod. Here’s how I measured. The script starts a monitor thread. Every second it asks NVIDIA-SMI for the memory used and it reads the

[05:49] bytes this process has pulled from storage. Then it times the generate call with a plain stopwatch and reads torches own peak memory counter. Two independent memory numbers, one clock, nothing hidden. First claim memory, one prompt 20 tokens long, explain in two sentences why reading model weights from disk is the bottleneck. I logged the peak. The peak was 2391 megabytes by torches counter and 2675 by Nvidia-smi. The claim was 4 gigabytes, that is 4096 megabytes, so the memory claim holds and

[06:21] it holds with room to spare. So, credit where it is due, the project said it fits and it fits. I want to say that clearly before I get to the part that is less nice. And the answer came out as real text. The model produced the words, quote, reading model weights, that is three tokens and I’ll come back to why I only generated three. Now, the number nobody printed one new token took 107.7 seconds. Three new tokens took 364.6 seconds, which is 121.5 seconds per token. My prediction was 30 to 60

[06:53] seconds. The real number is about double the top of my range, so I missed. Why? Because the disk on this pod reads 601 megabytes per second, not the three and a half gigabytes I assumed. The monitor shows reads up to about 2 gigabytes per second at the peak and a median of 710. So, the disk is the bottleneck and the exact speed depends on your disk and on how much of it your operating system has cached. Now, why only three tokens? Because look at this, a normal answer of about 200 words is around 270 tokens. 270 * 121.5 seconds is 32,805 seconds,

[07:27] that is 9.1 hours for one answer. So, if the question is, can a 4 gigabyte GPU run a 70 billion model without quantization? The answer is yes. If the question is, can you chat with it? The answer is no. And I want to be fair about what I tested. One prompt, three generated tokens, one run, one rented GPU, and a network disk. So, treat the 121 seconds as the measured number on this setup, not a law of nature. If you have a fast local NVMe, your number could be lower. I would love to see yours. Let me read the log slowly, so

[07:58] nothing is hidden. Load and split 361 seconds. That happens once, then run one one token, then run two three tokens. Notice both runs print the same peak. 2391 then 2393. The memory does not grow with the number of tokens. That part of the claim is solid. Now, let me sanity check my own numbers. 136 GB bytes is about 146 billion bytes. Divide that by 121.5 seconds, and you get about 1.2 GB per second. That is faster than the 601

[08:29] MB per second I measured with DD. So, prefetching and the cache are helping here, even for the 16-bit files. Without them, it would be slower than 121. Test three. The readme says 4-bit compression gives up to three times the speed. So, I ran the same model, same prompt, with compression set to 4-bit, and it refused to start. Look at this error. Not enough space. Model total size 481 GB, but the 4-bit files are only about 39 GB. So, where does 481 come from? I opened the

[09:00] code. This is utils.py in the repo, lines 447 to 468. For 4-bit, line 458 divides the size by 0.2813. So, it multiplies by about three and a half instead of shrinking it. That looks like a bug. I bypassed that one check only in my own benchmark script, and the run went through. The split took 352 seconds and wrote 39 GB versus 136 for the 16-bit version. Now, the speed. The first token took 117.5 seconds. That is

[09:30] the cold run, and it is no faster than 16-bit. It is actually a bit slower. Then, the three token run took 74.8 seconds, which is 24.9 seconds per token. That is almost five times faster than the 121. So, is the three times claim true? Here is what I think is going on. This pod gives the process about 50 GB of memory. The four-bit files are 39 GB, so after the first pass, they sit in the operating system cache, and the next token comes from memory, not from the disk. The 16-bit files are 136 GB. They cannot fit. So,

[10:03] every token is a disk read. So, the speed up is real, but it comes from the files being small enough to stay in RAM. If your machine has the memory, great. If not, the cold number is the one you get. And remember, this mode is quantized, so the headline, no quantization, no longer applies here. Peak GPU memory in this mode was 3,059 MB by torch, still under 4 GB. In the four-bit run, the disk monitor shows a median of 449 MB per second. The files are smaller, so the disk has less to do.

[10:34] The fair question is, what else could you do with the same hardware? So, I ran llama.cpp with the four-bit Q4KM version of the same model. That file is 44 GB. I kept only seven layers on the GPU, which uses about 4.7 GB of GPU memory, and the rest sits in system memory. The result, 0.29 tokens per second for generation. That is about 3.4 seconds per token. With zero layers on the GPU, it was 0.28, almost the same. The GPU hardly matters when the weights sit in memory

[11:04] because memory bandwidth is the limit. Put them side by side, air-llm 16-bit, 121.5 seconds per token. air-llm four-bit with a warm cache, 24.9. And llama.cpp four-bit, about 3.4. So, llama.cpp is about 35 times faster than air-llm in 16-bit, and about seven times faster than air-llm in four-bit. A 200-word answer would take about 15 minutes on llama.cpp on air-llm 16-bit, over 9 hours. But, this is not a fair

[11:34] fight. So, here is what each one costs. llama.cpp needs about 44 GB of system memory for this file. AirLLM needs almost no system memory and about 2.6 GB on the GPU, but it needs the layer files on disk. 136 GB in 16-bit and AirLLM keeps the original precision. While this llama.cpp file is 4-bit. So, it is a trade. If you have the RAM, llama.cpp wins by a huge margin. If you do not have the RAM, AirLLM is the one that

[12:05] still runs. Could AirLLM be faster? I did not test this, so it is my reasoning, not a result. Every token reads all 80 layers once, whatever you do. So, anything that gives you more tokens per pass over the disk should cut the disk cost per token. For example, running several prompts together as one batch. I have not tried it, so I will not give you a number. The other lever is simpler. A faster drive or more RAM for the cache. The 4-bit run showed it. Same GPU, same code, and a warm cache took the time from 117 to 25. The readme

[12:36] also claims Kimi K3 at 2.8 trillion in under 4 GB, and training a 125 billion model in under six. I did not test any of those. The Qwen 125 billion one needs about 360 GB of disk, which the readme says itself. So, treat those as the project’s claims, not mine. And the limits of my test, once more, 72.7 billion parameters, not exactly 71 prompt of 20 tokens, three generated tokens, one run each. If you run it on your machine, your numbers will be

[13:07] different, and I want to see them. Put them in the comments with your disk and your amount of RAM. If you want to repeat this, here is exactly what I ran. pip install AirLLM, then auto model from pre-trained pre-trained pre-trained with the huggingface repo and a layer shard saving path on a disk with lots of space. For the 4-bit mode, add compression equals 4-bit, and install bits and bytes first. If you hit the space error I showed you, that is the line 458 bug, not your disk. Then call generate with a small number of new tokens. Three is enough to get a speed

[13:38] number. Do not start with 200 unless you want to leave it running overnight. And write down your disk type, your RAM, and whether it was the first run or a repeat. Those three things explain most of the difference between your number and mine. What did all this cost? RunPod’s billing shows about 47 cents of pod time for the whole project. That includes the two pods that failed and the one that worked. So, you do not need a big budget to check a project’s claims. You need a few dollars, a plan, and the patience to repeat the download when a host breaks. Before the verdict, here is a scorecard of the claims I

[14:10] could test. 70 billion model in 4 GB measured true. Without quantization, true in the default mode. Up to three times faster with 4-bit, almost five times with a warm cache, and slightly slower cold, and no speed number in the readme at all. The big claims about Kimi and the 125 billion model, I did not test. Let me put everything in one table. Memory, 16-bit, 2.6 GB by nvidia-smi. 4-bit, 3.2. llama.cpp, 4.7 with seven layers on the GPU. Speed, 121

[14:42] seconds per token for 16-bit, 117 cold, and 25 warm for 4-bit, and 3.4 for llama.cpp. So, the answer, can AirLLM run a 70 billion model in under 4 GB? Yes, I measured 2.3 GB by torch and 2.6 by nvidia-smi. Is it fast? No, about 2 minutes per token in 16-bit on this setup. And I guessed 30 to 60 sec. Where it makes sense, you have a model that does not fit anywhere else, you can wait, and you have a lot of disk.

[15:12] Overnight batch jobs, one-off checks, trying a huge model once. Where it does not, chat, agents, anything where you sit and wait for the answer for that. A four-bit model in llama.cpp is about 35 times faster. And the guess winner is whoever wrote a number closest to 121 in the comments. Thanks for guessing. It made me write mine down, too. So, in this video, we have seen what air LM really does on a small GPU with the numbers the readme leaves out. If you want to try it on your own system, the repo link is in the description, and

[15:43] tell me what speed you get. I’ll see you in another one. Check out the next video.