Colibrì executa GLM‑5.2 de 744B sense GPU: com funciona i per què 25 GB de RAM no expliquen tota la història
Fahd Mirza prova Colibrì, un motor en C que manté la part densa de GLM‑5.2 a la RAM i carrega experts MoE des d’un SSD. Això permet iniciar un model gegant sense GPU, però no elimina els 372 GB de pesos ni el coll d’ampolla del disc: a la demostració, la velocitat passa de 0,03 a 0,15 tokens per segon quan s’escalfa la memòria cau.
Executar localment un model de més de set-cents mil milions de paràmetres sembla exigir un centre de dades. Colibrì qüestiona aquesta intuïció: manté només una part de GLM‑5.2 en memòria ràpida i carrega des del disc els experts que necessita cada token.
Fahd Mirza ho demostra en una màquina amb 132 GB de RAM i sense utilitzar la GPU. El model arrenca, respon i augmenta de velocitat a mesura que la memòria cau aprèn quins experts es repeteixen.
La demostració és real, però el titular necessita context. «Sense GPU» no vol dir «sense maquinari important», i «amb poca RAM» no vol dir que el model ocupi poc:
- la versió quantitzada necessita uns 372–383 GB de disc;
- un SSD ràpid és la peça crítica;
- la primera resposta pot ser extremadament lenta;
- la qualitat no és idèntica als pesos originals;
- 0,15 tokens per segon continua lluny d’una conversa interactiva.
Colibrì amplia qui pot experimentar amb un model gegant. No converteix un portàtil normal en un servidor de producció.
Per què un model de 744B no activa 744B a cada token
GLM‑5.2 utilitza una arquitectura Mixture of Experts o MoE. En lloc de fer passar cada token per tots els paràmetres, un encaminador tria un subconjunt d’experts.
La família GLM‑5 es descriu habitualment amb uns 744.000 milions de paràmetres totals i al voltant de 40.000 milions d’actius per token. El catàleg actual de Hugging Face mostra una xifra total lleugerament diferent per a GLM‑5.2, però la propietat important és la mateixa: la majoria dels pesos no participa en cada pas.
Segons la documentació de Colibrì:
- la part densa —atenció, experts compartits i embeddings— ocupa uns 9,9 GB en int4 i es queda a la RAM;
- hi ha 256 experts encaminables per capa;
- el model n’activa vuit per token;
- els experts ocupen aproximadament 370 GB en conjunt;
- només uns 11 GB d’experts canvien activament de token a token.
La idea és tractar els pesos com una jerarquia d’emmagatzematge, no com un bloc que ha d’entrar sencer a la VRAM.
El recorregut d’un token
Cada token segueix, simplificant, aquest procés:
- travessa les capes denses residents a RAM;
- l’encaminador decideix quins experts necessita cada capa;
- Colibrì comprova si aquests experts ja són a RAM o VRAM;
- si falten, els llegeix de l’SSD;
- executa els càlculs i genera el token;
- actualitza la memòria cau segons la freqüència d’ús.
El projecte compara aquest sistema amb un compilador JIT. Un JIT observa quines parts d’un programa s’executen sovint i n’optimitza els camins calents. Colibrì observa quins experts apareixen i els promociona cap a memòria més ràpida.
No és que la resta del model desaparegui. Continua al disc i pot haver de carregar-se en qualsevol moment.
El disc, no la CPU, és el coll d’ampolla inicial
A la prova, la GPU roman sense càrrega. Els pesos entren per l’SSD, passen per la RAM i el càlcul es fa a la CPU. Quan l’expert necessari no és a la memòria cau, el sistema queda limitat per lectura de disc.
La primera pregunta produeix tres tokens a 0,03 tokens per segon i mostra una taxa d’encert d’experts del 21%. Això equival a més de mig minut per token.
Amb una segona pregunta curta:
- l’encert de la memòria cau puja al 65%;
- la velocitat arriba a 0,15 tokens per segon;
- el sistema reté uns 107 GB a RAM.
És una millora de cinc vegades, però encara són gairebé set segons per token. Una resposta de 300 tokens podria trigar més de mitja hora si mantingués aquesta taxa.
La frase «es fa més ràpid com més l’utilitzes» és certa només quan les consultes reutilitzen experts similars i caben a la memòria cau. Un canvi de domini pot provocar nous errors de cau i lectures lentes.
Quanta memòria i disc es necessiten
El vídeo utilitza 132 GB de RAM i un model d’uns 383 GB. El projecte ha demostrat una configuració mínima d’uns 25 GB de RAM, però aquest és el terra funcional, no la recomanació de rendiment.
La documentació actual publica aquests ordres de magnitud:
| Configuració | Velocitat aproximada |
|---|---|
| 25 GB, CPU i disc, cau fred | 0,05–0,1 tok/s |
| Escriptori amb 128 GB, CPU, cau calent | ~1,8 tok/s |
| RTX 5070 Ti amb experts a GPU | ~1,07 tok/s |
| 6 × RTX 5090, residència completa | 5,8–6,8 tok/s |
Són resultats de versions, equips i càrregues diferents. No s’han de comparar com un benchmark controlat únic, però mostren el patró: més experts en memòria ràpida redueixen el trànsit de disc i acceleren la descodificació.
Per començar calen, com a mínim:
- uns 372 GB lliures per al contenidor int4;
- espai addicional temporal si es descarrega o converteix;
- SSD preferiblement NVMe;
- uns 25 GB de RAM com a mínim tècnic;
- CPU amb OpenMP per a la compilació recomanada;
- temps per baixar centenars de gigabytes.
Una unitat mecànica pot executar lectures, però la latència aleatòria i l’amplada de banda faran que el sistema sigui molt menys pràctic.
Per què l’SSD importa tant
Cada token pot demanar experts repartits per desenes de capes. Si no són a la memòria cau, Colibrì necessita moltes lectures.
El rendiment depèn de:
- amplada de banda sostinguda;
- latència de lectura;
- paral·lelisme;
- quantitat de RAM reservada al cau;
- patrons d’experts del text;
- temperatura i limitació del disc;
- sistema de fitxers;
- altres processos que competeixen per E/S.
El projecte admet dues còpies del model en dos SSD. Distribueix experts entre les unitats i suma part de l’amplada de banda. El cost és evident: calen més de 740 GB només per duplicar els pesos.
També convé vigilar l’ús intensiu. Les lectures no gasten una unitat com les escriptures, però escalfament, consum, caché del sistema i saturació poden afectar tota la màquina.
Int4 fa possible la mida, però és quantització
Els pesos originals tenen més precisió. La versió utilitzada els comprimeix a int4 perquè ocupin aproximadament mig byte per paràmetre, més metadades i excepcions.
El vídeo diu que és «el model real» i que l’únic compromís és la mateixa compressió que en altres formats. La primera part és correcta en el sentit que no és una destil·lació ni un model petit amb el mateix nom. Manté l’arquitectura i els experts de GLM‑5.2.
No obstant això, quantitzar sí que pot alterar la qualitat. El repositori publica proves i ablacions per mesurar la pèrdua; no afirma que int4 sigui matemàticament idèntic a FP8 o BF16.
També adverteix sobre els caps MTP per a descodificació especulativa. Una versió antiga els guardava en int4 i podia produir un 0% d’acceptació d’esborranys. El contenidor recomanat utilitza MTP int8.
Per tant, abans de baixar el model cal comprovar:
- versió del contenidor;
- suma o integritat dels fitxers;
- precisió dels pesos principals;
- versió dels caps MTP;
- compatibilitat amb el binari.
Què és la descodificació especulativa
Un model o cap auxiliar proposa diversos tokens futurs. El model principal els verifica en paral·lel i accepta els correctes. Si n’accepta prou, genera més text per cada passada.
No canvia la resposta final quan està implementat correctament, perquè el model principal valida les propostes. Però si el model d’esborrany és massa imprecís, gairebé totes es rebutgen i no hi ha acceleració.
El vídeo instal·la la variant adequada abans d’iniciar Colibrì. És un detall essencial que una demostració superficial podria ometre.
«Zero dependències» necessita una precisió
El nucli d’inferència és C i no necessita Python durant l’execució. El projecte intenta mantenir-lo petit i auditable.
L’experiència completa, però, pot utilitzar:
- Python per al llançador;
- Python i biblioteques per convertir o descarregar pesos;
- compilador GCC o Clang;
- OpenMP;
- una passarel·la Python per a l’API compatible amb OpenAI;
- controladors CUDA si s’activa la capa GPU.
«Sense dependències» descriu el motor central, no necessàriament tota la instal·lació.
Pot funcionar amb Kimi, Qwen o DeepSeek?
La tècnica general es pot aplicar a altres models MoE perquè també activen només alguns experts. El codi d’inferència, en canvi, ha d’implementar l’arquitectura exacta:
- tipus d’atenció;
- normalització;
- encaminador;
- forma dels pesos;
- tokenitzador;
- caps de predicció;
- precisió i quantització.
Colibrì admet GLM‑5.2 i OLMoE en la documentació actual i situa Kimi K2, Qwen3 MoE i MiniMax al full de ruta. No es pot apuntar qualsevol fitxer MoE al mateix binari i esperar que funcioni.
Un model dens és encara menys adequat per a aquesta estratègia. Si cada token necessita tots els paràmetres, llegir centenars de gigabytes del disc a cada pas seria prohibitiu.
Per a què serveix a la pràctica
En la configuració lenta del vídeo, els casos útils són experimentals:
- inspeccionar l’encaminament dels experts;
- validar que un model arrenca;
- estudiar quantització;
- fer preguntes molt curtes;
- executar processos nocturns;
- desenvolupar optimitzacions;
- provar privadesa local sense enviar prompts a una API.
No és una substitució directa d’un servei al núvol per a xat interactiu, agents ràpids o diversos usuaris.
Amb 128 GB, SSD ràpid i un cau calent, els resultats actuals del projecte són molt millors que els de la gravació. Amb GPU i residència parcial o completa, es pot superar diversos tokens per segon. Però en cada salt també augmenta el cost del maquinari.
Privadesa local i seguretat
Executar els pesos localment permet que prompts i documents no surtin de la màquina per inferència. Cal comprovar, tanmateix, tot l’entorn:
- d’on es descarrega el model;
- codi que es compila;
- passarel·les web exposades;
- ports oberts;
- registres;
- extensions;
- actualitzacions;
- permisos sobre fitxers.
Una API compatible amb OpenAI vinculada a totes les interfícies de xarxa i sense autenticació podria exposar el model o les dades igualment. Local no vol dir segur per defecte.
Conclusió
Colibrì no fa desaparèixer un model de 744B. El redistribueix. Manté uns 10 GB densos a RAM, conserva els experts més útils en una memòria cau i deixa centenars de gigabytes al disc fins que l’encaminador els demana.
La demostració de Fahd Mirza il·lustra molt bé el mecanisme: la GPU queda inactiva, la RAM puja i la velocitat millora quan els encerts de cau passen del 21% al 65%. També mostra el límit: 0,03–0,15 tokens per segon és una prova de possibilitat, no una experiència fluida.
El valor del projecte és obrir l’arquitectura a persones que no tenen un clúster. Permet mesurar, modificar i entendre un MoE gegant amb maquinari accessible, sempre que s’acceptin 372 GB de pesos, un SSD exigent, quantització i molta paciència.
Contrast i context
Fonts consultades
- 01
-
02
JustVugg Colibrì: repositori oficial
-
03
JustVugg Colibrì benchmarks
-
04
Z.ai GLM‑5.2 model card
-
05
Hugging Face GLM‑5, GLM‑5.1 and GLM‑5.2 architecture
-
06
mateogrgic GLM‑5.2 Colibrì int4 amb caps MTP int8
Font de treball
Transcripció amb marques de temps
Consulta la transcripció
-
0:00
, obre el vídeo en una pestanya nova
This is GLM 5.2, a 744 billion parameter model. This is like the dream gun you can only watch on the silver screen or this is the Bugatti in the showroom window the one with the little do not touch sign. The ones you normally need are data center and someone else is budget to drive. Today, I am taking it for a spin on a single machine, no cluster, no rack of GPUs, one box, one disk, and a tiny piracy engine called Colibre. The whole thing is one C file. This is the engine, zero dependencies, no python at runtime. The idea is simple. A 744 billion mixture of expert model. only actually uses a small slice of itself but token. So, coli-free keeps that hot sliced in RAM and streams the rest from this gone demand. I will show you exactly how that works in a second. This is for Hathmisa.
-
1:00
, obre el vídeo en una pestanya nova
and i welcome you to the channel. Recently i have started this free weekly AI news letter which you can subscribe at fastmiss.substack.com. This is my terminal where i am running this open to and we are dealing with this much memory and this much disk space. Notice the cap. The model needs about 370 chip you want to test but only a fraction of that in memory at any point that cap is the entire trick. Let me kick off the model download from Huggingface. Okay, so I would need to install my Huggingface oblibrary. It's a new VM and now it is being downloaded. While it downloads, let me try to explain what exactly is happening here and by the way this model which I'm showing you is also available on the hacking phase at this location and I will drop the link in video description. So look at this diagram this unpacked this whole stuff in very very simple words. So let me explain it. So remember GLM 5.2 is 744 billion parameter mixture of expert and the keyword here is mixture.
-
2:01
, obre el vídeo en una pestanya nova
It never uses all of itself at once. For any single token, only a small slice actually fires. Follow the flow left to right. A token comes in one at a time. It hits the dense part of the model, the attention layers, which stay resident in RAM, the whole time at about 10GB. Then the router does its job. At each layer, it picks just 8 experts out of 256. That's the whole idea. Out of a massive pile of experts, you only light up a handful partoken. Now the interesting part. Those experts have to come from somewhere. If an expert is already cached in RAM, it's basically free instant. If it's not, colabri stream street of the disk and that's the slow bath. Because all 21,000 5,010 experts live in that 370gb file on disk.
-
3:01
, obre el vídeo en una pestanya nova
that disc read is the real bottleneck of the whole system, not the CPU, not the GPU that is. Once experts are gathered, the model made the next token and the loop starts over. And here is the payoff. The thing that makes this watchable, equilibrium members, which experts you keep hitting and pins them in the RAM. So the first few tokens are gold and slow, but the more you check, the more of the hot experts. they gashed and it literally gets faster as you use it. You will see that happen live in a minute when I take you back to the terminal. One last thing to point out and it is counter-intuitive one. Notice that GPU isn't really in the picture here. The spurts streamed from disk. Not from VRAM.
-
4:02
, obre el vídeo en una pestanya nova
For this one I'm using a GPU because it comes with this box. It will set idle while a 744 billion parameter model is generating. That's not a bug. That's a whole point. That's a mechanism. Let's check on the download and get it running. It's a big download by the way. So still sometime left. Let's wait for it. And the model is downloaded. And I'm just checking your speculative recording. had is in tape version because that's a place that gives a suffrey speed boost later get this wrong and it's silently does nothing if you don't know what speculative decoding is what empty piece I have done heaps of videos on the channel that's done now let's get cloned the repo of colibri and as I said earlier I'm going to drop the link in video description that's done now let's set it up and it is going to take some time in order to build this
-
5:03
, obre el vídeo en una pestanya nova
which is done depending upon your system. Built clean 20 cores 132 GB RAM detected open MP good the circular dependency drop line is harmless the binary is built now Another thing which I would highly recommend you to do is to run this command before you do anything else this reads the model headers and shows the memory hierarchy without loading anything and it actually is quite useful because this just shows us how collaborate plans to split the model across this. Can if there are any errors it will go with it. So you see it is telling you the split of the model across this RAM and GPU no inference yet just the blueprint. And just to rehash it you can see the full picture here. 383 gig of model it will cache about 100 gig of experts in RAM and everything else streams from this notice the bottom line.
-
6:03
, obre el vídeo en una pestanya nova
where it says disk expert message that is what decides our speed. Let's now run the chat to see. This is a simple command which we are going to use. The first run will be slow because it forms up. It is telling us that it is waking the giant. Let's wait the giant to be broken up. And the whole model is loaded as you can see. Let me quickly show you the V-Ramp consumption. So there you go. Nothing is running on my GPU. Nothing at all. Everything is ideal and now let me just give it a promise. I'm just going to say explain what is the purpose of life in simple words. There's a type of a door very about it and GLM is thinking and meanwhile nothing is happening on Vira because GPU simply is not in the picture at all and this is my RAM at the moment as you can see it is just climbing very steadily up as it loads and offloads as I explained earlier
-
7:04
, obre el vídeo en una pestanya nova
in this diagram. So keep that diagram in my mind and your mind. But that is why I spend so much time on it just to explain this whole architecture. And there you go. Sterely slowly it is dripping the response while the memory jumps up very steadily. Earlier one was taking a bit longer so just to showcase what exactly is happening here I just gave it this very short prompt. We see the answer has come back. 3 tokens. 0.03 tokens a second expert hit rate. 21% look at this line. This is what I'm talking about and it is holding a 107 gig in RAM that 21% is a cold cache. Most experts still had to come off the disk and as you keep talking it is going to climb. So for example let's say name 3 colors. I'm just keeping it short just to showcase the concept here and look at this output.
-
8:04
, obre el vídeo en una pestanya nova
Hit rate jumped from 21% to 65% and the speed went 0.03 up to 0.15 5 times faster. Just from warming the cache, the machine say model it's learning what I use. Let's do another one. I'm just asking it to say thank you in few languages. And the model has come back with answer. You can see looks really good to me in terms of multilinguality and the hit rate has gone up and so is. the rest of the matrices looks pretty good. Now remember that this is the GLM 5.2 real thing. Nothing removed, the only trade office that this is in for compression same as any GGUFR AWQ build no worse. Not a step down model the actual thing. I'm more than sure you're going to ask in the comment that can we do this with Q and or Deepseek only if it is Mr. of experts. That's the whole trade.
-
9:05
, obre el vídeo en una pestanya nova
a few experts fired per token so the rest sits on disk. A dense model would have to read every parameter, every token hopeless and even for Moe, Colibri is handwritten for GLM 5.2s, exact architecture. So another model needs its own converter and forward pass that this technique is general, the code is not yet, but I am very much hopeful. this project is going to fly or similar ones because this makes things very very promising that's it let me know what do you think if you want to help out the channel please become a member thank you for all the support
