IA de 35B em um laptop com 15 GB de RAM — direto do SSD

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: 35B AI on a Laptop With 15GB RAM — Straight From the SSD · Canal: Prompt Engineer 48 · 13:57 · Assistir no YouTube

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

Resumo

O vídeo apresenta o Edge0, método de um artigo para executar um modelo MoE de 35 bilhões de parâmetros mantendo os pesos no SSD e buscando especialistas antes de serem necessários. No Apple Silicon, o artigo relata até 20,4 tokens por segundo usando 2,9 GB de memória ativa, mas também aponta perda de qualidade e limites no método. Em um laptop Windows com 15 GB de RAM, o modelo roda a partir do SSD a cerca de 7 a 10 tokens por segundo. Nesse computador, os testes não mostram uma vantagem consistente do Edge0 sobre o llama.cpp sem os patches.

Pontos-chave

O modelo de 35 bilhões de parâmetros ocupa cerca de 20 GB, mais do que a RAM disponível no laptop testado.
O modelo é uma mistura de especialistas com 40 camadas e 256 especialistas por camada, dos quais quatro são usados para cada token.
O Edge0 mantém os pesos no SSD e usa uma cabeça de predição para antecipar os especialistas do próximo token.
A predição determina o roteamento efetivo: o modelo usa os especialistas antecipados, sem uma etapa de fallback.
Um adapter de recuperação separado busca compensar perdas de qualidade causadas pela quantização em 4 bits e pelo roteamento previsto.
No Mac Mini com 24 GB, o artigo relata 20,4 tokens por segundo e 2,9 GB de memória ativa, contra 3,9 tokens por segundo e 18,2 GB no carregamento completo.
Em um MacBook com 16 GB, o prefetching aumenta a velocidade em cerca de 80% em relação ao streaming sob demanda sem prefetching.
O modelo de 35 bilhões teve média de 79,2 em cinco benchmarks, ante 83,2 para a versão em precisão total; a diferença foi maior no benchmark de matemática AIME.
No laptop Windows testado, o modelo rodou a cerca de 7 a 10 tokens por segundo, mas os resultados frente ao llama.cpp variaram conforme as configurações.
A implementação Windows descrita no vídeo não executa o pre-router do artigo; é uma versão modificada do llama.cpp.

Capítulos

Início	Capítulo	Resumo
00:00	O desafio de executar um modelo de 35 bilhões	O vídeo apresenta o laptop e o tamanho do modelo, além de resumir os resultados atribuídos ao artigo Edge0.
03:05	Por que carregar especialistas do SSD é lento	O vídeo compara quantização, offloading e streaming sob demanda, explicando a espera causada pela busca de especialistas a cada camada.
06:41	Resultados, qualidade e limites do artigo	São apresentados os resultados em velocidade e memória, a perda de qualidade e as limitações dos testes do artigo.
08:16	Testes do Edge0 no laptop Windows	O apresentador explica a diferença entre a implementação Windows e a do artigo e testa modelos de 8 e 35 bilhões de parâmetros.
11:21	Comparação com llama.cpp e conclusão	A comparação no laptop não aponta um vencedor consistente, e o vídeo conclui que o modelo roda no Windows, mas a vantagem do método do artigo ainda não aparece ali.

Citações

O truque é que a maior parte do modelo nem fica na memória. Ela permanece no SSD. — 00:30

Precisamos de uma forma de buscar os livros antes que o estudioso saiba que vai precisar deles. — 04:08

Isso não é o pre-router do artigo rodando no Windows. — 08:47

Sinceramente, neste laptop, dá empate. — 11:53

A máquina na sua mesa já é grande o bastante. Só faltava um lugar para os pesos ficarem. — 13:27

Conceitos e entidades

Edge0 (ferramenta): Framework apresentado no vídeo para executar modelos MoE com pesos armazenados no SSD e predição de roteamento.
AutoArc (empresa): Equipe responsável pelo artigo e pelo framework apresentados no vídeo.
The Other Half of the Memory Wall: Serving 35 Billion from SSD with Trained Routing Prediction (conceito): Artigo que descreve o método de predição de roteamento para servir um modelo de 35 bilhões de parâmetros a partir de um SSD.
Mixture of Experts (conceito): Arquitetura em que cada camada contém vários especialistas, mas apenas alguns são usados para cada token.
pre-router (conceito): Cabeça de predição que estima quais especialistas a camada seguinte usará no próximo token.
recovery LoRA (conceito): Adapter treinado com o roteamento previsto ativo para recuperar parte da qualidade perdida.
llama.cpp (ferramenta): Projeto usado no vídeo para executar o modelo no Windows, incluindo uma versão modificada fornecida pelo projeto.
MLX (ferramenta): Framework usado nos testes do artigo em Apple Silicon.
RTX 4060 (modelo): GPU do laptop usado nos testes locais, com 8 GB de memória de vídeo.

Tradução completa (pt-BR)

00:00 Certo. Olha só este laptop. Ele tem uma RTX 4060 com 8 GB de memória de vídeo e 15 GB de RAM. Agora, aqui temos um modelo de 35 bilhões de parâmetros. Só o arquivo tem cerca de 20 GB. Isso é mais do que toda a minha RAM. Então, isso não deveria funcionar, certo? Pois bem, este artigo diz que funciona. Ele se chama Edge Zero. E, nos testes deles, um modelo de 35 bilhões de parâmetros decodifica a 20 tokens por segundo usando menos de 3 GB de memória ativa. Agora compare isso com a maneira normal de executá-lo, em que todos os pesos ficam na

00:30 memória. Mesma máquina, mesmo modelo, que chega a 3,9 tokens por segundo e ocupa 18 GB. Então, de 3,9 para 20,4. E o truque é que a maior parte do modelo nem fica na memória. Ela permanece no SSD. Neste vídeo, vou explicar como isso funciona. Vou mostrar o que o artigo realmente comprova e, depois, vamos executá-lo neste laptop para eu mostrar o que acontece de verdade. Vamos começar. Isso vem de uma equipe chamada AutoArc. O artigo se intitula “A outra metade do muro da memória: servindo 35 bilhões a partir do SSD

01:00 com previsão de roteamento treinada”. Eu sei, é um baita título. E o que eu realmente gosto aqui é que tudo é aberto. O framework está no GitHub. Os checkpoints estão no Hugging Face. Os adapters também, e a licença é Apache 2.0. Então, você pode baixar tudo por conta própria, que foi exatamente o que eu fiz. Agora, vale lembrar que esta é uma versão de prévia, e vou ser sincero quanto a isso ao longo do vídeo, porque há algumas coisas no artigo e no repo que você deveria saber antes de ficar empolgado. Certo, antes de entrarmos no truque, precisamos

01:31 entender o problema. Quando um modelo de IA escreve uma resposta, ele escreve uma palavra por vez. E, para cada palavra, o computador precisa ler os pesos do modelo na memória. Basicamente, o que é lento não são os cálculos. É buscar os bytes. O artigo explica bem: o modelo realiza apenas algumas operações para cada byte que lê. Portanto, o limite é a memória, não a capacidade de processamento. Agora, a memória armazena duas coisas. Uma é o cache KV. São as anotações de curto prazo do modelo, e ele cresce a cada palavra. A indústria trabalhou bastante para reduzir essa parte. Mas a segunda parte são os

02:02 pesos. Os pesos são fixos. Eles simplesmente ficam ali, ocupando dezenas de gigabytes. E a resposta de sempre era simplesmente colocá-los em um data center. Então, vamos simplificar. Imagine um estudioso escrevendo uma redação. Ele está sentado a uma pequena mesa de leitura. Essa mesa é a sua RAM, e todos os livros de que ele talvez precise estão em um enorme armazém do outro lado da rua. Esse armazém é o seu SSD. Agora, este modelo é uma mistura de especialistas. Em termos de IA, cada camada tem muitas redes pequenas e especializadas, e apenas algumas delas são usadas para cada palavra. Este tem 40 camadas e 256 especialistas em cada

02:34 camada, e apenas quatro são escolhidos para cada palavra. Então, na nossa história, a redação tem 40 capítulos. Cada capítulo tem 256 livros de referência. E, para cada palavra, o estudioso abre apenas quatro deles. Agora, você talvez esteja pensando: ótimo, só quatro livros. Então, a mesa só precisa comportar quatro, certo? Bem, aí está o problema. O estudioso não sabe de antemão quais serão esses quatro. Então, normalmente, você mantém o armazém inteiro dentro do prédio. Isso dá 19,5 GB em 4 bits. E, em uma máquina de 24 GB, quase não sobra espaço para mais nada. É por isso que a configuração normal

03:05 se arrasta a 3,9 tokens por segundo. Então, como as pessoas lidam com isso hoje? Existem basicamente três maneiras, e todas têm um problema. Opção um: encolher os livros. Isso é quantização. Basicamente, você faz fotocópias em resolução mais baixa, reduzindo para 4 bits. Isso funciona bem. Mas, abaixo de 4 bits, o erro aumenta até o modelo se tornar inutilizável. Então, esse é o limite mínimo. Opção dois: descarregar para outro lugar. Ferramentas como llama.cpp, com seu modo de CPU, mantêm os especialistas na memória do sistema, enquanto outras identificam os especialistas populares. Mas

03:37 o artigo apresenta um bom argumento aqui. Tudo isso muda onde fica a carga. Não a reduz. Os pesos continuam ocupando dezenas de gigabytes em algum lugar. E os métodos que os colocam no disco não sabem de quais especialistas a próxima etapa vai precisar. O que nos leva à opção três: transmitir os especialistas do SSD sob demanda. Parece bom, certo? Bem, é aqui que dá errado. Veja como o modelo funciona. O capítulo 12 precisa escolher seus quatro livros com base no que aconteceu no capítulo 11. Então, o estudioso termina o capítulo 11. Só então ele sabe quais livros pedir ao mensageiro. E o mensageiro precisa ir até o armazém e voltar. E

04:08 isso acontece em cada capítulo, para cada palavra. Então, o estudioso passa a maior parte do tempo apenas esperando. Resumindo: os pesos são grandes demais para a mesa. Encolhê-los tem um limite. Movê-los apenas muda o problema de lugar. E buscá-los sob demanda faz você esperar em cada camada. Precisamos de uma maneira de buscar os livros antes que o estudioso saiba que precisa deles. E é exatamente isso que o Edge Zero faz com algo que eles chamam de prefetcher. A ideia é a seguinte. Em vez de esperar o capítulo 11 terminar, uma pequena cabeça de previsão observa o que o

04:39 modelo fez na palavra anterior e prevê de quais livros o capítulo 12 vai precisar na próxima palavra. Então, na nossa história, há um mensageiro que observa o estudioso e pensa: da última vez que ele estava no capítulo 11, usou estes livros. Então, da próxima vez, provavelmente vai querer estes para o capítulo 12. E o mensageiro começa a ir ao armazém imediatamente. Quando o estudioso chega lá, os livros já estão no carrinho. Agora, se formos um pouco mais a fundo, é assim que funciona em termos técnicos. Cada camada tem uma pequena cabeça que prevê o roteamento da camada seguinte, mas com um token inteiro de antecedência.

05:10 Não uma camada de antecedência, mas um token. E isso importa: o artigo testa a outra abordagem, fazendo previsões dentro do mesmo token, e descobriu que a sincronização custava de 30 a 100 milissegundos por etapa. Isso é mais do que o tempo de carregamento que você estaria tentando ocultar. Portanto, é essa antecedência de um token inteiro que permite sobrepor as leituras ao processamento. E aqui está a parte que considero realmente inteligente. A previsão é o roteamento. Então, o estudioso só pode abrir os livros que o mensageiro trouxe. Outros métodos fazem previsões e, quando erram, voltam a carregar os dados ou descartam o especialista. Aqui, a previsão

05:41 se torna a regra de verdade. Então, não há nada a que recorrer e nada é descartado. Mas talvez você esteja pensando: espera, se o modelo for obrigado a usar especialistas previstos, as respostas não vão piorar? Bem, na verdade, sim. E essa é a segunda parte. A quantização para 4 bits custa um pouco de qualidade, e o roteamento por previsão custa mais um pouco. Então, eles treinam um adapter pequeno chamado LoRA de recuperação para compensar essa perda. Ele é treinado enquanto o roteamento por previsão já está ativo, usando o modelo original de precisão total como professor. Agora, há um detalhe de que gosto muito. O adapter permanece sem ser mesclado. Então, na

06:11 nossa história, a página original fica intacta, e as correções são notas adesivas por cima. Por que não simplesmente mesclá-lo? Porque o artigo testou isso e constatou que as alterações do adapter são menores do que a diferença entre dois valores de 4 bits. Então, ao mesclar e quantizar de novo, apenas cerca de 18% do efeito permanece na saída. É como reescrever uma página com um marcador grosso. Os detalhes em letras pequenas desaparecem, e as notas adesivas custam 42 megabytes, sem nenhuma perda de velocidade mensurável. Um design muito bom. O treinamento em si tem três etapas. Primeiro, treinam as cabeças de previsão

06:41 e, depois, fazem fine-tuning do adapter com o roteamento por previsão ativo, usando cerca de 2 milhões de linhas. Em seguida, fazem uma última etapa com as próprias saídas do modelo. Eles dizem que a ordem não era negociável. É técnico demais para este vídeo, mas o artigo explica isso em detalhes. Agora, vamos olhar os números, porque é aqui que a coisa fica interessante. Em um Mac Mini com 24 GB, o Edge0 chega a 20,4 tokens por segundo usando 2,9 GB, contra 3,9 tokens por segundo e 18,2 GB na versão totalmente carregada. Isso é cerca de cinco vezes mais rápido, usando um sexto da

07:12 a memória. Mas há algo que quero destacar. Na mesma tabela, o artigo diz que, se você desligar o pré-carregador, obtém 19,9. Então, naquela máquina, o pré-carregador não acrescenta muito. O grande ganho veio de não carregar tudo na memória. O pré-carregador mostra seu valor em uma máquina mais limitada, em um MacBook com 16 GB, onde o modelo não cabe. Eles comparam o streaming sob demanda simples com o pré-carregamento. E dá para ver que 3,5 tokens por segundo sobe para 6,4; nas outras configurações, vai de 4,8 para 8,6 e de 1,8 para 3,3.

07:45 Isso representa cerca de 80% mais velocidade. E, quanto à qualidade, o modelo de 35 bilhões tem uma média de 79,2 em cinco benchmarks, contra 83,2 do modelo de precisão total. Então, são cerca de quatro pontos a menos, mas veja o AIME, o de matemática difícil: 86,6 contra 92,7. São seis pontos. O próprio artigo diz que a perda aparece em longas cadeias de raciocínio. E há mais duas limitações que vale mencionar. Palavras adjacentes concordam sobre os especialistas em apenas cerca de um quarto das vezes. Então, muita coisa que

08:16 o executor busca nunca mais é usada, e ele processa uma solicitação por vez. Além disso, tudo no artigo é executado em Apple Silicon. A parte de CUDA, nas palavras deles, é arquitetura, não código. Então, esse é o artigo. E quanto ao meu laptop? Certo. Agora vamos testar isso no meu próprio laptop. E vale lembrar que tudo aqui está sendo executado localmente. Esta é uma GPU de laptop RTX 460 com 8 GB de memória de vídeo, 15 GB de RAM e um SSD NVMe de 1 TB. Agora, antes de mostrar os

08:47 números, preciso esclarecer uma coisa. Os resultados do artigo são em Apple Silicon Max, usando um framework chamado MLX. Eu não tenho um Mac. Para Windows, o projeto disponibiliza uma versão diferente. É uma versão modificada do llama.cpp. Os pesos do modelo grande. Os especialistas ficam no lado da CPU e são mapeados da memória em disco, enquanto a GPU, por meio do Vulkan, cuida do restante. E o próprio README para Windows diz que, em comparação com o llama.cpp simples, essas modificações não alteram a velocidade. Portanto, este não é o

09:17 pré-carregador do artigo sendo executado no Windows. Tenha isso em mente, porque acho importante ser honesto. De todo modo, a configuração foi simples. Baixei os modelos do Hugging Face, compilei o mecanismo a partir do código-fonte, e o aplicativo converte os pesos em um arquivo GGUF na sua máquina. Isso levou cerca de 11 minutos para o modelo de 35 bilhões. Vamos começar pelo menor, o modelo de 8 bilhões. Ele tem cerca de 5 GB, então cabe sem problema. E dá para ver que consigo cerca de 30 tokens por segundo. Para ser exato, a mediana de três execuções é de 30,8 tokens por segundo. O README para Windows

09:48 mostra 44,8 na máquina de referência deles, que tem 48 GB de RAM e uma GPU mais recente. Então, é um pouco mais lento no meu laptop, mas muito bom para um laptop. O processamento do prompt é mais lento: cerca de 26 tokens por segundo aqui. Por isso, a primeira resposta leva alguns segundos para começar. Agora, o principal: o modelo de 35 bilhões. Veja o arquivo: ele tem cerca de 20 GB. Minha RAM é de 15 GB. Então, o modelo inteiro não pode ficar na memória, mas, mesmo assim, ele carrega e funciona. Agora, vamos ver o que esses modelos realmente fazem. Dou a cada um deles três prompts simples: uma

10:19 explicação curta, um pouco de código e uma resposta em JSON. E executei o código para conferir. A função em Python passou nos meus cinco casos de teste nos dois modelos. E o JSON era válido nos dois. Mas veja o que a máquina está fazendo. No modelo de 8 bilhões, o SSD fica praticamente ocioso enquanto ele responde, com cerca de 5 megabytes por segundo, porque tudo cabe na RAM. No modelo de 35 bilhões, o SSD lê cerca de 220 megabytes por segundo em média, chegando a aproximadamente 630, e a RAM fica completamente cheia: 15,3 de 15,3 GB.

10:50 Isso acontece porque os especialistas são carregados do disco, e dá para sentir a diferença. A primeira resposta levou 29 segundos para exibir a primeira palavra. Depois disso, estabiliza em cerca de 7 a 9 tokens por segundo. E, usando o benchmark do próprio repo, consigo cerca de 6,9 tokens por segundo. Mais lento que o modelo de 8 bilhões, claro, mas é um modelo de 35 bilhões rodando em um laptop onde ele não deveria caber. E os 20 tokens por segundo do artigo são em um Mac com 24 GB e memória unificada rápida. Então, não é uma comparação justa com a minha

11:21 máquina. Agora, a pergunta que eu realmente queria responder: o artigo diz que o truque é melhor do que a abordagem normal. Então, peguei o llama.cpp simples, compilado exatamente com a mesma versão do código-fonte, sem nenhum patch do Edge Zero, e executei o mesmo arquivo do modelo de 35 bilhões com o mesmo adaptador e as mesmas configurações. Alternei qual dos dois rodava primeiro, porque, nesse tipo de máquina, os números variam bastante. E foi isto que aconteceu com as configurações do aplicativo: o Edge0 teve uma mediana de 9,7 tokens por segundo, e o llama.cpp simples, de oito. O Edge0 venceu duas

11:53 rodadas de três. Mas depois executei de novo com o comprimento total do context window do modelo, e o llama.cpp simples foi mais rápido nas três rodadas: 11,6 contra 7,4. Então, qual é mais rápido? Sinceramente, neste laptop, dá empate. O resultado se inverte conforme as configurações, e o próprio artigo diz que essas execuções podem variar cerca de 40%. Então, esta é a minha conclusão: hoje, no Windows, o Edge0 permite que um modelo de 35 bilhões rode em uma máquina que não consegue comportar o modelo inteiro. Essa parte é muito legal. Mas isso também é algo que o llama.cpp simples consegue fazer. O que

12:24 há de especial no artigo é que, por enquanto, o pré-carregador é um resultado para Mac. Eu adoraria ver alguém portá-lo para CUDA porque, nas palavras do próprio artigo, essa parte é arquitetura, não código. Então, vamos juntar as peças. Temos um modelo grande demais para a memória rápida. Os pesos ficam no SSD. Um pequeno cabeçalho treinado prevê quais especialistas a próxima palavra vai precisar, com um token inteiro de antecedência. Assim, as leituras se sobrepõem ao processamento. A previsão é o roteamento. Portanto, nada é descartado, e um pequeno adaptador mantido separado recupera a qualidade perdida por causa da

12:56 quantização de 4 bits e das previsões. Quatro pontos a menos na média, seis a menos na matemática mais difícil. E o resultado do artigo é um modelo de 35 bilhões a 20,4 tokens por segundo, usando 2,9 GB de memória ativa, contra 3,9 tokens por segundo e 18 GB da abordagem normal. Em um Mac mais limitado, com 16 GB, o pré-carregamento acrescenta cerca de 80%. E o que descobri no meu próprio laptop é que o modelo realmente roda a cerca de 7 a 10 tokens por segundo, mas, no Windows, ainda não há vantagem sobre o llama.cpp simples.

13:27 Mas gosto muito da ideia por trás disso. O artigo termina com esta frase: a máquina na sua mesa já é potente o bastante. Os pesos só precisavam de um lugar para ficar. Então, neste vídeo, vimos o que o Edge Zero faz, como funciona o pré-carregador e como ele roda em um laptop comum com 15 GB de RAM. Se tiver interesse, você pode testar isso no seu próprio sistema e me dizer como foi, especialmente se experimentar em um Mac ou em outra máquina Windows. O artigo, o código e os modelos estão todos vinculados na descrição abaixo. Vejo você em

13:57 outro vídeo. Confira o próximo vídeo.

Transcrição original

[00:00] All right. So, look at this laptop. It has an RTX 4060 with 8 GB of video memory and 15 GB of RAM. Now, here’s a 35 billion parameter model. The file alone is about 20 GB. That is bigger than my entire RAM. So, this should not run, right? Well, this paper says it does. It’s called edge zero. And in their tests, a 35 billion parameter model decodes at 20 tokens a second while using under 3 GB of active memory. Now compare that to the normal way of running it where all the weights sit in

[00:30] memory. Same machine, same model that gets 3.9 tokens a second and holds 18 GB. So 3.9 up to 20.4. And the trick is that most of the model is not in memory at all. It stays on the SSD. In this video, I’ll explain how that works. I’ll show you what the paper actually proves and then we will go ahead and run it on this laptop and I’ll show you what really happens. Let’s get started. So this is from a team called AutoArc. The paper is titled the other half of the memory wall serving 35 billion from SSD

[01:00] with trained routing prediction. It’s a mouthful I know. And the thing I really like here is that it is all open. The framework is on GitHub. The checkpoints are on hugging phase. The adapters too and the license is Apache 2.0. So you can go ahead and download everything yourself which is exactly what I did. Now, mind you, this is a preview release and I’ll be honest about that as we go cuz there are a few things in the paper and in the repo that you should know before you get excited. Okay, so before we go into the trick, we need to

[01:31] understand the problem. When an AI model writes an answer, it writes one word at a time. And for every single word, the computer has to read the model’s weights out of memory. Basically, it’s not the math that is slow. It’s fetching the bytes. The paper puts it nicely. The model does only a few operations for every bite it reads. So the limit is memory, not compute. Now memory holds two things. One is the KV cache. That’s the model’s short-term nodes and it grows with every word. The industry has done a lot of work on shrinking that part. But the second part is the

[02:02] weights. The weights are fixed. They’re just there tens of gigabytes. And the usual answer was just put that in a data center. So let’s make this simple. Think of a scholar writing an essay. He sits at a small reading desk. That desk is your RAM and all the books he might need are in a giant warehouse across the road. That warehouse is your SSD. Now, this model is a mixture of experts. In AI terms, each layer has a lot of small specialist networks and only a few of them are used for each word. This one has 40 layers and 256 experts in every

[02:34] layer and only four get picked for each word. So, in our story, the essay has 40 chapters. Each chapter has 256 reference books. And for every word, the scholar opens only four of them. Now, you might be thinking, great, only four books. So, the desk only needs to fit four, right? Well, that’s the catch. The scholar doesn’t know ahead of time which four. So, normally you keep the whole warehouse inside the building. That’s 19.5 GB at 4bit. And on a 24 GB machine, that leaves almost nothing for everything else. That’s why the normal

[03:05] setup crawls at 3.9 tokens a second. So, how do people deal with this today? There are really three ways and they all have a problem. Option one, shrink the books. That’s quantization. Basically, you photocopy them at a lower resolution down to 4bit. That works fine. But go below 4 bits and the error grows until the model is not usable. So, that’s a floor. Option two is offloading. Tools like Llama CPP with its CPU mo option keep the experts in system memory and others catch the popular experts. But

[03:37] the paper makes a good point here. All of these move the footprint. They don’t shrink it. The weights still take tens of gigabytes somewhere. And the ones that do go to disk don’t know which experts the next step needs. Which brings us to option three. Just stream the experts from the SSD on demand. Sounds good, right? Well, here’s where it breaks. Look at how the model works. Chapter 12 needs to pick its four books based on what happened in chapter 11. So, the scholar finishes chapter 11. And only then does he know which books to send the runner for. and the runner has to walk to the warehouse and back. And

[04:08] that happens at every chapter for every single word. So the scholar spends most of his time just waiting. So to sum things up, the weights are too big for the desk. Shrinking them has a floor. Moving them just moves the problem. And fetching them on demand makes you wait at every layer. We need a way to fetch the books before the scholar knows he needs them. And that is exactly what edge zero does with something they call the preotterer. Here’s the idea. Instead of waiting for chapter 11 to finish, a small prediction head looks at what the

[04:39] model did on the previous word and guesses which books chapter 12 will need on the next word. So in our story, there’s a runner who watches the scholar and thinks last time he was in chapter 11, he used his books. So next time he’ll probably want these for chapter 12. And the runner starts walking to the warehouse right away. By the time the scholar gets there, the books are already on the trolley. Now if we go a bit deeper, here’s how it works in technical terms. Each layer has a small head and it predicts the routing of the next layer, but one whole token ahead.

[05:10] Not one layer ahead, one token. And that matters the paper tests the other way predicting inside the same token and found it cost between 30 and 100 milliseconds per step to synchronize. That is more than the load time you’d be hiding. So a full token of lid is what makes the reads overlap with the compute. And here’s the part I think is really smart. The prediction is the routing. So the scholar is only allowed to open the books the runner brought. Other methods guess and when they guess wrong they fall back to loading again or they drop the expert here. The guess

[05:41] becomes the actual rule. So there’s nothing to fall back to and nothing drop. But you might be thinking wait if the model is forced to use guest experts won’t the answers get worse? Well actually yes. And that is the second piece. Quantization to 4bit costs some quality and the guest routing costs some more. So they train a small adapter called a recovery Laura to pay that back. It’s trained while the guest routing is already in place with the original full precision model as a teacher. Now there’s one detail I really like. The adapter stays unmmerged. So in

[06:11] our story, the original page is untouched and the corrections are sticky notes on top. Why not just merge it? Because the paper tested that the adapter’s changes are smaller than the gap between two 4-bit values. So when you merge and re-quantise, only about 18% of the effect survives at the output. That’s like rewriting a page with a thick marker. The fine print is gone and the sticky notes cost 42 megabytes and no measurable speed. Quite a good design. The training itself is three steps. Train the prediction heads

[06:41] first, then fine-tune the adapter with the guest routing active on about 2 million rows. Then a last pass on the model’s own outputs. They say the order was not negotiable. It’s a bit too technical for this video, but the paper goes through it in detail. Now, let’s look at the numbers because this is where it gets interesting. On a Mac Mini with 24 GB, Edge0 gets 20.4 tokens a second using 2.9 GB versus 3.9 and 18.2 for the fully loaded version. That’s about five times faster using a six of

[07:12] the memory. But here’s something I want to point out. In that same table, the paper says if you switch the pre router off, you get 19.9. So on that machine, the pre-outer doesn’t add much. The big win there came from not loading everything into memory at all. The pre-outer shows its value on a tighter machine on a MacBook with 16 GB where the model doesn’t fit. They compare the plane on demand streaming against pre-fetching. And you can see 3.5 tokens a second goes up to 6.4 and at the other settings 4.8 to 8.6 and 1.8 to 3.3.

[07:45] That’s about 80% more speed. And the quality, the 35 billion model averages 79.2 across five benchmarks versus 83.2 for the full precision one. So about four points lower, but look at aime, the hard math one. 86.6 versus 92.7. That’s six points. The paper itself says the loss shows up in long chains of reasoning. And two more honest limits. Adjacent words only agree on about a quarter of the experts. So a lot of what

[08:16] the runner fetches never gets used again and it handles one request at a time. Also everything in the paper runs on Apple silicon. The cuta part in their words is architecture not code. So that is the paper. Now what about my laptop? Okay. So now let’s go ahead and test this out on my own laptop. And mind you everything here is running locally. This is an RTX 460 laptop GPU with 8 GB of video memory, 15 GB of RAM, and a 1 TB NVME SSD. Now, before I show you the

[08:47] numbers, one thing I need to be upfront about. The paper’s results are on Apple Silicon Max using a framework called MLX. I don’t have a Mac. What the project gives us for Windows is a different build. It’s a patched version of Llama CPP. the big model weights. The experts stay on the CPU side and get memory mapped from disk and the GPU through Vulcan handles the rest. And the Windows readme itself says that compared to plain llama CPP, these patches don’t change the speed. So, this is not the

[09:17] papers pre-outer running on Windows. Keep that in mind because I think it’s important to be honest here. Anyway, setup was straightforward. I downloaded the models from hugging face, built the engine from source, and the app converts the weights to a GB GUF file on your machine. That took about 11 minutes for the 35 billion model. Let’s start with the small one, the 8 billion model. It’s about 5 GB, so it fits fine. And you can see I get about 30 tokens a second. To be exact, the median of three runs is 30.8 tokens a second. The Windows readme

[09:48] shows 44.8 8 on their reference machine which has 48 GB of RAM and a newer GPU. So a bit lower on my laptop but really good for a laptop. Now the prompt processing is slower about 26 tokens a second here. So the first answer takes a few seconds to start. Now the main thing the 35 billion model look at the file it’s about 20 GB. My RAM is 15. So the whole thing cannot sit in memory and yet it loads and it runs. Now let’s look at what these models actually do. I give both of them three simple prompts. a

[10:19] short explanation, a bit of code, and a JSON answer. And I ran the code to check it. The Python function passed all five of my test strings on both models. And the JSON was valid on both. But look at what the machine is doing. On the 8 billion model, the SSD is basically idle while it answers about 5 mgabytes a second because everything fits in RAM. On the 35 billion model, the SSD is reading about 220 megabytes a second on average up to about 630 and the RAM is completely full, 15.3 out of 15.3 GB.

[10:50] That is the experts being paged in from disk and you can feel it. The very first answer took 29 seconds before the first word appeared. After that, it settles at around 7 to 9 tokens a second. And the speed with the repo’s own benchmark, I get about 6.9 tokens a second. Slower than the 8 billion model, of course, but it’s a 35 billion model running on a laptop where it should not fit. And the paper’s 20 tokens a second is on a Mac with 24 GB and fast unified memory. So that isn’t a fair comparison with my

[11:21] machine. Now, the question I really wanted to answer, the paper says the trick is better than the normal approach. So, I took plain llama CPP built from the exact same source version without any edge zero patches and ran the same 35 billion file with the same adapter and the same settings. And I alternated which one ran first because on this kind of machine the numbers jump around a lot. And here’s what happened with the apps settings. Edge0 got a median of 9.7 tokens a second and plain llama CPP got eight. Edge0 won two

[11:53] rounds out of three. But then I ran it again with the model’s full context length and plane llama CPP was faster in all three rounds 11.6 against 7.4. So which one is faster? Honestly on this laptop it’s a tie. The result flips with the settings and the paper itself says these runs can vary by about 40%. So here’s my takeaway. On Windows today Edge0 lets a 35 billion model run on a machine that cannot hold it. That part is really cool. But that is something plain llama CPP can also do. The thing

[12:24] that is special about the paper, the train parer is a MAC result for now. I’d love to see someone port it to CUDA because in the paper’s own words, that part is architecture, not code. So let’s put the pieces together. We have a model that’s too big for fast memory. The weights live on the SSD. A small train head predicts which experts the next word needs one whole token ahead. So the reads overlap with the compute. The prediction is the routing. So nothing is dropped and a small adapter kept separate pays back the quality lost from

[12:56] 4bit and from the guessing. Four points lower on average, six on the hardest math. And the result in the paper is a 35 billion model at 20.4 tokens a second inside 2.9 GB of active memory against 3.9 tokens a second and 18 GB a normal way. On a tighter 16 GB Mac, prefetching adds about 80%. And what I found on my own laptop is that the model does run around 7 to 10 tokens a second, but the win over plain llama CPP isn’t there on

[13:27] Windows yet. But I really like the idea behind it. The paper ends with this line. The machine on your desk is already big enough. The weights just needed somewhere to live. So in this video, we have seen what Edge Zero does, how the pre-outer works, and how it runs on a normal laptop with 15 GB of RAM. If you’re interested, you can go ahead and check this out on your own system and let me know how it goes, especially if you try it on a Mac or a different Windows machine. The paper, the code, and the models are all linked in the description below. I’ll see you in

[13:57] another one. Check out the next video.