Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
Wenn man ein 744B MoE-Modell wie GLM-5.2 lokal auf einer Standard-Workstation oder einem MacBook betreibt, stoßen die Engpässe eher auf die Speicherbandbreite und die Richtlinien für den virtuellen Arbeitsspeicher des Betriebssystems als auf die VRAM-Kapazität. colibrì von JustVugg, eine leichtgewichtige Inferenz-Engine auf C-Basis, hält nur die residente Schicht mit 17B (9,9 GiB bei int4) im RAM fest und streamt die in 21.504 Teile unterteilten Routing-Experten-Gewichte (~370 GB) in Echtzeit tokenweise von einer externen SSD.
Das Problem ist, dass bei Ausführung mit den Standard-OS-Einstellungen Swap-Thrashing auftritt oder der Kernel OOM Killer den Prozess gewaltsam beendet. Man muss von den Kompilierungs-Flags über NVMe-I/O-Warteschlangen bis hin zu den Kernel-Parametern alles selbst anpassen, damit die Generierung von Tokens nicht stoppt.
Die Kern-Rechen-Engine von colibrì ist eine einzelne C11-Datei mit rund 1.300 Zeilen ohne externe Abhängigkeiten. Der Durchsatz von Matrizenmultiplikationsoperationen variiert je nachdem, welche SIMD-Vektorbefehle der Compiler verwendet. Anstelle des Standard--O2-Builds müssen die Integer-Rechenerweiterungsbefehle der Ziel-CPU direkt angegeben werden.
Für x86_64-Linux-Umgebungen wird AVX-512 VNNI unter GCC 12 oder höher aktiviert, während Apple Silicon NEON DotProduct über Clang anbindet.
Für Ubuntu und Debian werden zuerst die Build-Tools installiert.
`bash
sudo apt-get install gcc-12 libomp-dev
`
Unter macOS wird die OpenMP-LgetRuntime über Homebrew bezogen.
`bash
brew install libomp
`
Auf x86_64-Linux-Maschinen wird für AVX-512-VNNI-Befehle gebaut.
`bash
gcc -O3 -march=native -mtune=native
-mavx512f -mavx512bw -mavx512vnni -mavx512dq
-fopenmp -funroll-loops -ffast-math
-o colibri_engine colibri_glm52.c -lm
`
In der Umgebung von Apple Silicon (M-Serie) wird unter direkter Angabe des Bibliothekspfads kompiliert.
`bash
clang -O3 -mcpu=native
-march=armv8.4-a+dotprod+fp16
-Xpreprocessor -fopenmp
-I/opt/homebrew/opt/libomp/include
-L/opt/homebrew/opt/libomp/lib -lomp
-o colibri_engine colibri_glm52.c -lm
`
Wenn Warnungen im Zusammenhang mit Strukturen auftreten, können diese durch das Hinzufügen des Flags -std=c11 behoben werden.
| Plattform | Compiler | Vektorbefehls-Flag | Thread-Parallelisierung |
|---|---|---|---|
| x86_64 (Linux) | GCC 12+ | -mavx512vnni -mavx512bw |
-fopenmp |
| ARM64 (macOS) | Apple Clang | -march=armv8.4-a+dotprod |
-Xpreprocessor -fopenmp |
| Ältere x86 | GCC / Clang | -mavx2 -mfma |
-fopenmp |
Die Latenz beim Dekodieren in colibrì wird durch die 1-MB-Zufallslesegeschwindigkeit der Festplatte bestimmt. Die Routing-Experten-Parameterdatei von GLM-5.2 ist in Stücke von jeweils ca. 19 MB unterteilt, sodass der asynchrone I/O-Thread bei jeder Token-Erstellung den benötigten Chunk von der SSD liest.
Installieren Sie fio über den Paketmanager.
`bash
sudo apt-get install fio
brew install fio
`
Messung der Zufallslesebandbreite mit 1 MB Blockgröße und Direct I/O.
`bash
fio --name=colibri_stream_bench
--filename=/Volumes/ExternalSSD/glm52_test.tmp
--size=10G
--rw=randread
--bs=1m
--iodepth=32
--numjobs=4
--ioengine=posixaio
--direct=1
--group_reporting
--runtime=60
`
Schnittstellen wie Thunderbolt 4 oder USB4 (40 Gbps) halten eine gemessene Bandbreite von 2.800–3.200 MB/s bei einer Dekodiergeschwindigkeit von 0,08–0,10 tok/s aufrecht. Wird das externe Laufwerk hingegen an einen USB-3.2-Gen2-Anschluss (10 Gbps) angeschlossen, dessen Bandbreite nur 900–1.050 MB/s beträgt, dauert das Generieren von 100 Tokens über 80 Minuten.
`
+-------------------------------------------------------------------------+
| colibrì C Inference Engine |
| +--------------------------+ +-------------------------------------+ |
| | Dense Weights (9.9 GiB) | | Multi-Token Prediction (MTP) Head | |
| | Resident in RAM (mlock) | | int8 Quantized | |
| +------------+-------------+ +------------------+------------------+ |
+---------------+-----------------------------------+---------------------+
| |
v v
+-------------------------------------------------------------------------+
| Memory & Storage I/O Layer |
| +--------------------------+ +-------------------------------------+ |
| | Async Expert Readahead | | 21,504 Routed Experts (370 GB) | |
| | I/O Queue Depth 3264 | | Streamed from NVMe SSD via mmap | |
| +--------------------------+ +-------------------------------------+ |
+-------------------------------------------------------------------------+
`
Durch das Erhöhen der I/O-Warteschlangentiefe (iodepth) des asynchronen Prefetching (Async Expert Readahead) auf Werte zwischen 32 und 64 können alle parallelen Kanäle des NVMe-Controllers genutzt werden, um die Festplatten-Wartezeit zu verringern.
Wenn auf einem System mit 32 GB RAM die residenten Gewichte von 9,9 GiB, der KV-Cache und der Dateisystem-Seiten-Cache gleichzeitig geladen werden, kommt es zu Speicherkonflikten im Kernel. Unter Standard-Linux-Einstellungen schlägt die Zuweisung des virtuellen Adressraums bei einem mmap-Aufruf von 370 GB fehl oder der OOM Killer beendet die Engine.
Erstellen Sie die Datei /etc/sysctl.d/99-colibri-memory.conf und fügen Sie den folgenden Inhalt ein:
`ini
vm.swappiness = 1
vm.overcommit_memory = 1
vm.min_free_kbytes = 2097152
vm.vfs_cache_pressure = 50
vm.max_map_count = 524288
`
Speichern Sie die Datei und übernehmen Sie die Parameter sofort:
`bash
sudo sysctl --system
`
Heben Sie die Speichersperren-Grenzwerte in der Shell-Sitzung auf, um mlock()-Aufrufe für die residente Schicht zu erlauben.
`bash
ulimit -l unlimited
`
| Parameter | Standardwert | Empfohlener Wert | Zweck der Einstellung |
|---|---|---|---|
| vm.swappiness | 60 | 1 | Verhindert, dass die im RAM fixierten 9,9-GiB-Gewichte in den Swap-Bereich verdrängt werden |
| vm.overcommit_memory | 0 | 1 | Verhindert die Verweigerung von Kernel-Speicher beim mmap-Mapping von 370 GB |
| vm.vfs_cache_pressure | 100 | 50 | Verlängert die Lebensdauer des Dateicaches zur Wiederverwendung wiederholt aufgerufener Expertengewichte |
| vm.max_map_count | 65530 | 524288 | Aufhebung des Limits für die Zuordnung von 21.504 Parameterdateien |
| ulimit -l | 64 (KB) | unlimited | Gewährt Berechtigung zum Fixieren der Dense-Layer im physischen Speicher (mlock) |
In macOS-Umgebungen führt die Erschöpfung des freien Speichers dazu, dass dynamic_pager im Hintergrund eine Speicherkomprimierung ausführt, was die CPU-Auslastung beeinträchtigt. Vor dem Ausführen sollten speicherintensive Apps geschlossen werden, um das Einsetzen der Komprimierungs-Engine zu verhindern.
MoE-Dekodierung strapaziert den CPU-Cache und den Speicherbus permanent. Wird bei einer Workstation mit mehreren Sockeln der falsche NUMA-Node erwischt, halbiert sich die Token-Generierungsgeschwindigkeit aufgrund von Interconnect-Bus-Engpässen.
Prüfen Sie zuerst mit numactl --hardware die physische CPU-Knotennummer, die direkt mit dem externen NVMe-Controller verbunden ist. Schreiben Sie danach ein Shell-Skript, das Hyper-Threading-Duplikate vermeidet und Threads ausschließlich an physische Kerne bindet.
`bash
#!/usr/bin/env bash
set -euo pipefail
sudo sysctl -w vm.swappiness=1 > /dev/null
sudo sysctl -w vm.overcommit_memory=1 > /dev/null
sudo sysctl -w vm.max_map_count=524288 > /dev/null
sudo sysctl -w vm.vfs_cache_pressure=50 > /dev/null
sudo sync && echo 3 | sudo tee /proc/sys/vm/drop_caches > /dev/null
ulimit -l unlimited
export OMP_NUM_THREADS=16
export OMP_PROC_BIND=TRUE
export OMP_PLACES=cores
ENGINE_BIN="./colibri_engine"
MODEL_PATH="/mnt/nvme_ext/GLM-5.2-colibri-int4-g64-with-int8-mtp"
exec numactl --physcpubind=0-15 --membind=0
"${ENGINE_BIN}"
--model "${MODEL_PATH}"
--threads "${OMP_NUM_THREADS}"
`
Auf Apple-Silicon-MacBooks muss verhindert werden, dass der QoS-Daemon von macOS die Worker-Threads auf Effizienzkerne (E-Cores) verschiebt. Starten Sie das Programm mit erzwungen hoher Priorität:
`bash
sudo nice -n -20 taskpolicy -c default ./colibri_engine --model /Volumes/SSD/glm52_i4
`
Nach Abschluss dieser vier Einstellungen lässt sich das 744B-MoE-Modell auf Workstations oder MacBooks mit 32 GB RAM auch über lokales Disk-Streaming fehlerfrei und ohne OOM-Abstürze betreiben.
