Large language models like GLM 5.2 can run on consumer laptops by leveraging the mixture-of-experts architecture, where only a small subset of experts (approximately 40 billion parameters) activates per token, allowing the model to be partitioned into hot (dense components in RAM) and cold (expert bank on disk) parts, with only about 11 GB of expert weights changing per token, enabling efficient memory management through tiered storage and adaptive caching.
Deep Dive
Prerequisite Knowledge
- No data available.
Where to go next
- No data available.
Deep Dive
This 744GB Model Shouldn't Fit on Your Laptop. It Does
Added:Can you fit a GLM 5.2 class model on consumer laptop?
Well, this shouldn't be possible, but now thanks to this new project called Colibri, you can do this.
And in this video, I'm going to explain how exactly does this work.
Okay, but first we need to talk about memory wall. In order to load these models for fast inference, you need fast memory. Think about several H100s that you would need. Each one of them costs about 20 to 30,000 dollars.
Now, even to serve this model in four bit, you will need multiple of these.
Which essentially means you're renting compute from an inference provider.
However, the trick is that you don't need to have the entire network in memory most of the time. And mostly the memory remains idle.
Now, this is thanks to the mixture of experts architecture that most frontier models use today.
So, in case of GLM 5.2, there are 256 experts per layer.
However, for every token, you don't need all of them to be active. There is a router which picks top K for every token.
Which means most of the network is not used at all.
And essentially, that 744 billion total parameters squishes down to only 40 billion active parameters per token.
Now, in order to understand how Colibri takes advantage of this, let's look at what happens when you move token to token across a sentence.
The first token lights up one small subset of experts and ignores the rest.
The next token lights up mostly different subset.
There might be some overlap, but the sets uh keep shifting for every token.
Now, as you can see, most of the network is going to remain idle for uh the tokens that are coming in.
Now, each of these expert is about 9 MB of weights, which raises the obvious question, if most of them are idle, do they even need to be in the working memory or RAM?
Okay, so if you think about it, we can split the model into two different parts. One is going to be the hot part and the other going is going to be the cold part.
So, the hot part is the dense stuff. Uh think about attention, shared experts, embeddings, which are small and used on every single token.
Now, the cold part is that giant bank of routed experts, which are enormous in size, but they're going to be mostly idle at any instant, as we saw before.
Now, here's an interesting fact about GN5.2.
Only about GB of routed experts actually change from one token to the next.
So, theoretically, you just need 11 GB that changes from token to token.
Okay, so if you think about this, you need to just keep the hot part close to yourself, and then the cold part is going to be fetched as it's needed on demand.
Okay, so the trick that this Kelby project uses is that it divides the memory into three different tiers.
Tier one is RAM. Uh it's the small dense part of the network that lives there.
Uh and you need about 9.9 GB in total, which needs to be always ready.
Now, tier two is the NVMe SSD, where the full 370 GB expert bank are going is going to reside on disk.
Now, tier three is optional. It's a hot slice of GPU memory if you have a GPU available. Otherwise, this could theoretically work on a CPU as well.
Okay, so the simple idea is that you have a workbench and then you have the warehouse as your disk. Workbench is your working memory.
Now, you are making a trade-off of speed in order to run this model. And this is a big discussion right now. However, this idea is very similar to the Dwarf Star 4 video for DeepSeek models that we looked at before. I highly recommend to watch that video after this.
Okay, one more important detail. How the 744 billion parameter fits into that 370 GB in the first place.
So, we are actually using 4-bit quantization instead of the full precision.
Now, this is different than the 2-bit quantization that is used by Dwarf Star. It shrinks the model about 4x and you pay for a few point reduction in accuracy. So, it's lossy.
However, it does preserve the performance.
Now, thanks to this quantization, we can actually keep the experts in the memory.
All right, but there are some things that you actually need to keep it in 8-bits of For example, if you're using the multi-token prediction head, that needs to be in 8-bit, otherwise it's going to collapse completely and you're not going to get that performance.
All right, so this is a very important distinction to keep. Otherwise, if you're running this model in 16-bits full precision, you're going to be needing 1.5 TB, but thanks to this 4-bit quantization, we can reduce it to manage size that can run on an SSD.
Okay, but that's only the part of the story. Okay, so you are able to load the model. However, you need to think about KV cache because that enables how much uh context window you can actually use.
Now, as the model reads your context, it stores the KV cache that grows with every token it sees.
Now, that KV cache is going to grow as you're introducing more and more tokens.
So, GLM's 5.2 multi-latent attention compresses that cache down to 576 numbers per token instead of 32,786.
That's roughly uh 57 times smaller, which is what keeps a million token context affordable on 25 GB.
Now, the trick is that Colibri writes the compressed cache to disk. So, reopening a chat is warm instead of starting cold. Okay, so let's actually talk about Colibri, which is Italian for hummingbird. It's a pretty nice name.
So, the whole thing is one uh C file, which is about 2,400 lines.
Uh it's very similar to the Dwarf Star um inference engine that we looked at in the previous video.
Now, the interesting thing is there are zero dependencies. Uh you don't need any Python uh runtime environment, and it doesn't even need a GPU or CUDA. It's just C and the operating system that you are running this on.
And that's kind of the beauty, right?
So, you have that 370 GB model file that lives on your disk, and this engine is going to load the appropriate parts into memory.
So, this is going to only fetch that 11 GB of expert that changes.
Now, keep in mind, the goal of this is not to to these models at high infant speed.
It's just an open source project that actually shows you that you can run these humongous model on consumer hardware.
Now, this part is extremely important because there is a lot of interest in this area. So, for example, today Prism ML announced uh that they can run that 27 billion parameter model on a phone, which wasn't possible before.
Now, it may not give you the same level of performance, but just having this direction is critical.
Which means in future we're going to have much better algorithms which are going to run these bigger models at much better performance.
All right. So, here's how this whole thing actually works.
So, the router names the expert it wants and the memory map reads those weights straight off the NVMe or your SSD into memory.
There's also a caching mechanism which basically caches the recently used experts. Uh so, repeats don't hit the disk twice.
But, the main problem is that it reads about 11 GB from the disk per token. So, this is going to be excruciatingly slow.
You cannot interact with it because the model is going to take forever to generate responses. So, this is essentially useful as a proof of concept or for running async tasks that you don't care about in terms of speed.
Okay, but it doesn't mean that it's going to always remain slow. The longer you use this, the faster this is going to get.
Now, the idea is that they use a file that quietly records which experts you actually uh your actual prompts are getting routed to.
And then it pins the hottest ones into any uh spare RAM you have got.
So, they never touch the disk again.
So, in theory, the more you use it, the more it's going to learn about the experts that it needs and that it's going to keep them resident.
And you're going to have fewer and fewer 1 GB read per token. Now, this is going to work provided you have enough VRAM or uh RAM in general.
So, there are some reports where you can get about one token per second on M5 Max.
So, it's kind of really nice, right? So, the hummingbird that learns your flowers and comes back to them first when you need them.
Okay. So, there are some other tricks as well which can actually improve the generation speed. So, if every uh forward pass already costs 11 GB of disk, the fix is to emit more than one token per pass. Uh this is basically the idea of speculative decoding we looked at it.
Uh there are is a very interesting approach from DeepSeek DeepSpark.
I created a video on it recently, so I'll link to that. Now, the idea is that you can draft several tokens cheaply, then verify all of them in one expensive pass.
So, GLM 5.2 actually ships natively uh with a head for this.
And it can land you 2.2 to 2.8 tokens per forward pass.
But again, there is one caveat that the head has to be in 8-bit.
If you want to use it in 4-bit, the acceptance collapses from 39 to 60% down to almost zero. So, one thing to be clear, you're not going to be doing inference for multiple That's out of the question. However, just to be able to run a frontier level model which outperforms any open-weight model uh it's actually on par with some of the closed frontier models. It's pretty incredible.
Now again, you're not going to be breaking any speed records, but keep in mind you can get a sense of how a frontier model running on consumer hardware feels like.
Now, if you are brave enough to try this, make sure that you have more than 25 GB of VRAM with a fast SSD disk and you can download the weights from Hugging Face.
Now, there are some concerns about its impact on your SSD. The main question is going to be can you wait for the response generation speed and how long it's going to take.
Now, I personally really like these ideas, these novel techniques in order to run these frontier models on consumer hardware. In some cases, they may not be practical right now, but this is a really great research direction.
Anyways, do let me know if you are going to be trying this on your own hardware.
Link to everything is going to be in the video description. Anyways, I hope you found this video useful. Thanks for watching. And as always, see you in the next one.
Related Videos

Expanding Stikbot thumbnails
leopoldshorts
2K views•2023-09-24

Digital Discrimination: Cognitive Bias in Machine Learning
redmonktechevents2974
4K views•2019-12-18

Evolutionary Approach to Clustering by Ujjwal Maulik
ICTStalks
279 views•2019-06-26

Rose Yu "Learning from Large-Scale Spatiotemporal Data"
networkscienceinstitute
2K views•2019-03-04

Stanford Seminar - Generalization through Task Representations with Foundation Models
stanfordonline
4K views•2025-07-14

Satellite-Based Wheat Yield Forecasting using GEE & Transformer Neural Network
gisrsinstitute
634 views•2025-06-15

Paradigm Shifts in Data Processing for the Generative AI Era: Robert Nishihara of Anyscale & Ray.io
GradientFlow
2K views•2025-01-02

How to Build Your Own GenAI-Based Knowledge Management System
2150GmbH
360 views•2025-06-03
Trending

WOW! Judge TURNS THE TABLES on Trump in His OWN $10B LAWSUIT!!!
MeidasTouch
197K views•2026-07-23

Playstation NO DISC/NO BUY Fight Is Over...
DavidJaffeGames
4K views•2026-07-23

Steam and Xbox Just Dropped The Hammer On PlayStation
OhNoItsAlexx
9K views•2026-07-23

Americans Confused in Australia for 17 Minutes Straight
IWrocker
17K views•2026-07-23