Show HN: GLM 5.2 auf langsamen Computern ausführen

 (github.com/JustVugg)
2 Punkte von GN⁺ 5 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • colibrì ist eine reine C-Engine, die GLM-5.2 744B MoE auf Consumer-Maschinen mit rund 25 GB RAM ausführt; sie streamt geroutete Experts von der Festplatte und funktioniert ohne GPU
  • Die Kernarchitektur hält den dense Anteil mit rund 17B Parametern als int4 im RAM resident und nutzt dafür 9,9 GB; die 21.504 gerouteten Experts liegen auf etwa 370 GB Festplatte und werden bei Bedarf gelesen
  • Die Implementierung umfasst GLM-5.2 Forward, MLA Attention mit komprimiertem KV-Cache, einen Router im DeepSeek-V3-Stil, MTP Speculative Decoding, int8/int4/int2-Quantisierungskernels und einen Byte-Level-BPE-Tokenizer
  • In einer WSL2-Umgebung mit 12 Kernen, 25 GB RAM und NVMe-VHDX liegt die Ladezeit bei etwa 30 Sekunden, der Peak-RSS im Chat bei rund 20 GB, und Cold Decode erreicht mit ca. 11 GB Festplattenlesevorgängen pro Token 0,05–0,1 tok/s
  • Auf schnellen NVMe-Systemen und mit mehr RAM sind Cache und Pinning wichtig; eine reale Community-Messung auf einem Apple M5 Max mit 128 GB ergab bei deaktiviertem MTP 1,06 tok/s

Welches Problem colibrì lösen will

  • colibrì versteht sich als „Tiny engine, immense model“ und ist eine Engine, die das GLM-5.2-MoE-Modell mit 744B Parametern auf Consumer-Maschinen mit etwa 25 GB RAM ausführt
  • Die Runtime ist reines C und hat keine Abhängigkeiten von Python, BLAS oder GPU
  • Die Engine besteht aus einer einzelnen C-Datei c/glm.c mit etwa 1.300 Zeilen sowie kleinen Headern
  • Ein Beispielaufruf ist ./coli chat; die Beispielausgabe zeigt colibrì v1.0 — GLM-5.2 · 744B MoE · int4 · streaming CPU, etwa 32 Sekunden Vorbereitungszeit und 9,9 GB residenten Speicher

MoE-Ausführung per Disk-Streaming

  • Beim 744B Mixture-of-Experts-Modell GLM-5.2 werden pro Token nur etwa 40B Parameter aktiviert
  • Die pro Token wechselnden gerouteten Experts entsprechen etwa 11 GB
  • Der dense Anteil bleibt im RAM resident
    • umfasst Attention, Shared Experts und Embeddings
    • etwa 17B Parameter
    • nutzt bei int4 etwa 9,9 GB RAM
  • Die gerouteten Experts werden auf der Festplatte gespeichert
    • 75 MoE-Layer × 256 Experts inklusive MTP Head
    • insgesamt 21.504 routed Experts
    • etwa 19 MB pro Expert bei int4
    • gesamte Festplattennutzung etwa 370 GB
  • Das Laden der Experts nutzt einen per-Layer-LRU-Cache, einen optionalen pinned Hot-Store und den OS-Page-Cache

Implementierte Hauptfunktionen

  • GLM-5.2 Forward ist passend zur Struktur glm_moe_dsa implementiert und wurde token-genau gegen ein transformers-Oracle validiert
    • Teacher-Forcing 32/32 auf einem tiny-random-Modell
    • Greedy Generation 20/20
  • MLA Attention umfasst q/kv-LoRA und interleaved partial RoPE
    • Der komprimierte KV-Cache nutzt 576 Floats pro Token
    • 57-mal kleiner als bisherige 32.768 Floats/Token
    • GLM-5.2 hat 64 Heads und kein GQA
  • Implementiert ist ein Sigmoid-Router im DeepSeek-V3-Stil
    • noaux_tc
    • routed_scaling_factor
    • Shared Expert
    • first-3-dense Layers
  • Native MTP Speculative Decoding nutzt den Multi-Token-Prediction-Head von GLM-5.2 (Layer 78), um Draft Tokens zu erzeugen, die das Hauptmodell per batched Forward verifiziert
    • Der MTP Head muss int8 sein
    • Bei int4 fällt die Draft Acceptance auf 0–4 %, sodass Speculation nicht funktioniert
    • Bei int8 wurden 39–59 % Acceptance und 2,2–2,8 Tokens/Forward gemessen
    • Durch Rejection Sampling bleibt es auch beim Sampling lossless
    • Bei Cold Cache können verifizierte Drafts zusätzliche Experts routen, wodurch expert-loads/token von etwa 660 auf rund 1100 steigen können
    • In diesem Fall kann es vor dem Warm-up von Cache und Pins länger dauern; deshalb gibt es einen Adaptive Guard und die Option DRAFT=0
  • True Sampling unterstützt Temperature und Nucleus
    • Standardwerte sind 0,7 / 0,90
    • Die offiziellen Einstellungen 1,0 / 0,95 werden so beschrieben, dass sie in int4-Umgebungen Quantisierungsrauschen im Tail sampeln
  • Der Integer-Dot-Kernel nutzt Q8_0-artige int8 Activations und AVX2 maddubs
    • int8 Matmul ist 1,4- bis 2,5-mal schneller
    • Gemessene Leistung: 119 GFLOP/s
    • int4 ist im Batch 1,8-mal schneller
    • int4 Single-Row ist in Messungen langsamer und bleibt daher f32
  • MLA Weight Absorption vermeidet im Decode die per-Token-Rekonstruktion von k/v
    • Die Query absorbiert kv_b, der Context wird nach der Attention projiziert
    • Auch in einer Umgebung mit erzwungener Absorption wurde mit TF 32/32 und Generation 20/20 validiert
  • Expert-Readahead liest während der Multiplikation eines Expert Blocks den nächsten Block mit WILLNEED
  • Die Quantisierungskernels unterstützen int8, packed int4, packed int2, per-row Scales, AVX2 und Dequant-on-use
  • DSA Sparse Attention ist in Arbeit
    • Lightning-Indexer Weights werden aus dem FP8-Repo in einer Größe von etwa 108 GB extrahiert
    • Indexer Forward ist als nächster Schritt geplant
    • Bis dahin ist Attention bei Context ≤ 2048 Tokens dense und exakt
  • Bei Prefill und MTP Verification liest Batch-union MoE jeden im Batch eindeutigen Expert nur einmal und wendet ihn auf alle Positionen an, die zu diesem Expert geroutet wurden
  • Der Tokenizer ist ein in C implementierter Byte-Level-BPE-Tokenizer mit GPT-2-artiger Unicode-Property-Regex und 320k Merges
  • RAM-Sicherungen passen beim Start den Expert Cache automatisch anhand von MemAvailable an
    • berücksichtigen die Peak-Projektion von Working Set, KV, MTP Row und Reconstruction Buffer
    • so ausgelegt, dass der Kernel-OOM-Killer nicht anspringt
  • Der Offline-Converter wird als c/convert_fp8_to_int4.py bereitgestellt
    • lädt GLM-5.2-FP8-Shards einzeln herunter
    • dequantisiert mit 128×128 Block-Scales und requantisiert anschließend in den Engine-Container
    • löscht Shards während des Vorgangs, sodass der gesamte 756-GB-FP8-Checkpoint nicht gleichzeitig auf der Festplatte liegen muss
    • die Konvertierung ist fortsetzbar

Gemessene Basisleistung und Einschränkungen

  • Die Entwicklungsumgebung ist WSL2, 12 Kerne, 25 GB RAM, NVMe via VHDX
  • Die Messwerte sind wie folgt
    • int4-Container-Modellgröße: etwa 370 GB
    • residenter RAM: 9,9 GB
    • Ladezeit: etwa 30 Sekunden
    • Peak-RSS im Chat: etwa 20 GB, automatisch begrenzt
    • Cold-Decode-Kosten: etwa 11 GB Disk Reads pro Token
    • VHDX-Random-Disk-Ceiling: etwa 1 GB/s
    • Cold-Decode-Geschwindigkeit: etwa 0,05–0,1 tok/s
    • MTP Speculation: 2,2–2,8 tok/forward mit int8 Head
  • Es wird ausdrücklich erwähnt, dass dies kein schnelles System ist; Warm Cache, pinned Hot Experts und MTP reduzieren die Useful-Response-Latenz
  • Zu SSDs gibt es zwei Hinweise
    • colibrì-Streaming ist read-only, daher beeinflussen die Lesevorgänge selbst die SSD-Abnutzung nicht nennenswert
    • Wenn wegen RAM-Mangel Swap-Traffic entsteht, fallen Schreibvorgänge an, die das Laufwerk abnutzen können
    • Ein dauerhafter Full-Read-Duty-Cycle kann günstige Laufwerke erhitzen, daher sind Temperatur- und Health-Monitoring nötig

Modelldownload und Ausführung

  • Ein vorab konvertiertes GLM-5.2 int4-Modell ist auf Hugging Face verfügbar
  • Wer das vorab konvertierte Modell lädt, kann den Schritt FP8 → int4 überspringen
  • Zur Ausführung wird COLI_MODEL auf das Modellverzeichnis gesetzt
COLI_MODEL=/path/to/GLM-5.2-colibri-int4 ./coli chat
  • Der Quick Start führt im Verzeichnis c mit ./setup.sh gcc/OpenMP-Prüfung, Build und Self-Test aus
  • Für eine eigene Konvertierung wird ./coli convert --model /nvme/glm52_i4 verwendet
    • benötigt einen ext4/NVMe-Pfad mit etwa 400 GB freiem Speicher
    • die Konvertierung benötigt Python sowie torch, safetensors, huggingface_hub und numpy
    • die Runtime-Engine selbst ist reines C; Python wird nur für den einmaligen Converter genutzt
  • Nützliche Optionen sind
    • --temp T: Sampling Temperature, Standard 0,7 und Nucleus 0,90; 0 ist greedy
    • --topp 0.7: adaptives Expert Top-p, reduziert Disk-Nutzung um 30–40 %
    • --ngen N: maximale Tokenzahl pro Antwort
    • AUTOPIN=0: Learning-Cache-Auto-Pin deaktivieren
    • THINK=1: GLM-5.2-Reasoning-Block aktivieren
    • DRAFT=n: MTP Draft Depth
    • TF=1: Teacher-Forcing Validation

Learning Cache und Erwartungen je Hardware

  • Der Learning Cache protokolliert die im realen Gebrauch gerouteten Experts neben dem Modell in .coli_usage
  • Beim Start werden die heißesten Experts automatisch in den freien RAM gepinnt
  • Die Projektbeschreibung sagt, dass colibrì mit zunehmender Nutzung schneller wird
  • Erforderlich sind Linux oder WSL2, ein gcc mit OpenMP-Unterstützung, AVX2, mindestens 16 GB RAM und lokale NVMe mit einem int4-Modell von etwa 370 GB
    • ext4-Pfade werden empfohlen
    • von Network-/9p-Mounts wird abgeraten
  • Die Testreihenfolge lautet: Build und Self-Test, Disk-Messung mit iobench, in chat tok/s, Expert-Hit-Rate und RSS prüfen, Expert Usage aufzeichnen und pinnen, Qualitätsbenchmark ausführen
  • Die erwarteten Werte je Hardware sind Schätzungen, keine Messwerte
    • Entwicklungsmaschine WSL2 VHDX, etwa 1 GB/s, 25 GB RAM: 0,05–0,1 tok/s cold
    • Native Linux, PCIe4-NVMe 3–5 GB/s random, 32 GB: 0,5–1 tok/s
    • PCIe5-NVMe oder 2×NVMe RAID0 8–12 GB/s, 64 GB, PIN etwa 40 GB: 2–4 tok/s
    • 128–256 GB RAM, 12 Kerne, Hot Experts cached: 2–4 tok/s
    • gleicher RAM mit 24–32 Kernen oder AVX-512/VNNI Kernels: 5–15 tok/s

Community-Benchmarks

  • Auf einem Intel Core Ultra 7 270K Plus, 24 Threads, WSL2, 24 GB RAM und NVMe-VHDX erzielte die Standardeinstellung 0,07 tok/s
    • Disk iobench: 1,96 GB/s buffered, 2,74 GB/s O_DIRECT
    • Expert Hit: 3–4 %
    • RSS: 14,1 GB
  • In derselben Umgebung erreichte --topp 0.7 0,11 tok/s
    • Expert Hit: 11 %
    • RSS: 14,7 GB
    • End-to-End-Geschwindigkeit 1,6-mal höher
  • Auf einem Apple M5 Max, 18 Cores, macOS, 128 GB Unified Memory und interner SSD wurden 1,06 tok/s gemessen
    • Disk iobench: 14,2 GB/s O_DIRECT
    • Default, MTP off
    • Expert Hit: 23 %
    • RSS: 21,8 GB
  • Auf Maschinen mit 24 GB RAM wird der Expert Cache automatisch auf 2 Slots pro Layer begrenzt; trotz 2- bis 2,7-mal schnellerer Disk als auf der Entwicklungsmaschine bleibt der Decode kalt
  • Auf Maschinen mit wenig RAM wird eher die RAM-Grenze als die Festplatte zum Bottleneck
  • Der M5-Max-Wert zeigt einen 744B-Modelllauf mit etwa 1 tok/s auf einer Laptop-SSD; eine 14-GB/s-Disk verschiebt den Bottleneck zurück zu RAM-Budget und Kernel

Qualitätsbenchmarks und ausstehende Messungen

  • Die Kosten der int4-Quantisierung für die Genauigkeit wurden noch nicht gemessen
  • Das Benchmark Harness ist implementiert, aber auf der Entwicklungsmaschine mit etwa 1 GB/s Disk dauert ein vollständiger Lauf einen erheblichen Teil eines Tages
  • Die bereitgestellten Benchmark-Befehle führen hellaswag, arc_challenge und mmlu aus
cd c
./coli bench
./coli bench hellaswag --limit 200
./coli bench mmlu arc_challenge --ram 100
  • Die Ausgabe ist die Accuracy pro Task und nutzt Log-Likelihood-Scoring im Stil des EleutherAI-Harness
  • Die öffentlichen Scores von Full-Precision GLM-5.2 werden für diese Tasks mit etwa 85–95 % angegeben
  • Wenn der int4-Container nur wenige Punkte davon entfernt liegt, ist die Quantisierung validiert; andernfalls wäre das ein Grund, in Mixed oder Grouped-Scale Quantization zu investieren

Repository-Struktur und Lizenz

  • Die wichtigsten Dateien sind
    • c/glm.c: Engine mit GLM-5.2 Forward, Streaming MoE, MTP und Serve Mode
    • c/st.h: Safetensors-Reader auf Basis von pread und fadvise, ohne mmap
    • c/tok.h: C Byte-Level-BPE-Tokenizer
    • c/coli: CLI für chat, run, bench, convert und info
    • c/iobench.c: paralleler Disk-Microbenchmark aus Sicht der Engine
    • c/convert_fp8_to_int4.py: disk-sicherer Converter von FP8 nach int4
    • c/make_glm_oracle.py: tiny-random Oracle Generator für die Validierung
    • c/olmoe.c: Stage-A-Engine und erstes Validation Target
  • Der Name colibrì leitet sich vom Kolibri ab, der mit wenig Gewicht auf der Stelle fliegt und täglich viele Blüten besucht
  • Die Projektlizenz ist Apache 2.0; die GLM-5.2 Weights wurden von Z.ai unter MIT veröffentlicht

Verwandte Beiträge

1 Kommentare

 
GN⁺ 5 시간 전
Meinungen auf Hacker News

  • Am meisten interessiert mich, ob das in der Praxis in Token/Sekunde messbar ist oder eher bei 1 Token pro Minute liegt.
    Selbst wenn ein lokales LLM so langsam ist wie 1 Token/Sekunde, war es ziemlich nützlich, ihm über Nacht ein Projekt zu überlassen und nach 6–8 Stunden das Ergebnis anzusehen.
    Dagegen wirken die 0,05–0,1 Token/Sekunde auf der im Link genannten Minimal-Hardware für kaum einen Zweck brauchbar.
    Das Gesamtkonzept ist trotzdem großartig, und ich hoffe, dass es mehr Versuche geben wird, Modelle der 350B- bis 900B-Klasse lokal auf für normale Nutzer bezahlbarer Hardware laufen zu lassen, selbst wenn es nur 1 Token/Sekunde ist.
    Mir gefällt die Richtung: „Wir haben eine NVMe-SSD mit schneller Leseleistung und ein riesiges Modell auf der lokalen Platte; laden wir also nicht alles, sondern lesen bei Bedarf jeweils 11 GB/Token.“

    • Es ist lustig, dass man sich dank Claude Cowork daran gewöhnt hat, auf Antwortzeiten zu warten.
      Ich denke, spätestens etwa 2028 werden wir das lokal laufen lassen.
      Das Budget würde ich unter 10.000 Dollar ansetzen, und ich möchte ein Modell ausführen, das mit heutigen Spitzenmodellen vergleichbar ist.
    • Für langsame lokale Modelle oder manche Projekte könnte ein Chat-Interface der falsche Ansatz sein; vielleicht passt eher etwas wie ein Ticketsystem.
      Ich habe einen Weg festgelegt, diese Idee mit meiner vorhandenen Hardware zu validieren, bevor ich Geld für einen Mac Studio oder GPUs ausgebe, und ich denke, ich kann diese Woche einen Proof of Concept bauen.
      Die Idee ist nicht neu; ich brauche nur Zeit, um sie so zum Laufen zu bringen, dass sie zu meiner Arbeitsweise passt.
    • Im README gibt es Benchmarks für Colibrì auf verschiedener Hardware, und ich habe schon ziemlich gute Zeiten gesehen.
      Wir versuchen, es weiter zu verbessern.
    • Für die meisten Projekte ist es praktischer, eine Cloud zu nutzen, die GLM 5.2 kostenlos anbietet.
      1 Token pro Minute ist selbst im Vergleich zu kostenlosen Nutzungslimits viel zu wenig.
    • Ich frage mich, ob „normale Nutzer“ heutzutage 24 GB RAM und eine 0,5-TB-NVMe-SSD bezahlen können.

  • Ich baue etwas Ähnliches für macOS auf Apple Silicon.
    Der Ansatz geht in Richtung Unsloth split GGUF, komprimierte Teile resident im Unified Memory, native Metal-Kernel und natives komprimiertes KV nur im RAM.
    Mit 128 GB dürfte das mehr Sinn ergeben als mit meinen 64 GB, und wenn es bereit ist, will ich es auf GitHub stellen.

    • Ein 128-GB-MacBook Pro M4 wartet hier, ich würde es gern testen.

  • Für Bild-/Videogenerierung habe ich mit https://github.com/cretz/thinfer eine ähnliche Strategie ausprobiert.
    Im video-Branch steckt viel Arbeit.
    Ich brauchte immer wieder eine Inferenz-Engine, die Gewichte bei Bedarf per LRU hinein- und herausladen kann, also habe ich schließlich per Vibe Coding ein Tool gebaut, das --vram-budget annimmt und innerhalb dieses Budgets bleibt.
    Es stellte sich heraus, dass das Verschieben von mmap-ten Bytes in den VRAM und wieder heraus im Vergleich zur Berechnung ziemlich billig ist; mit Pipelining und Double Buffering ist fast immer nicht der Speicher, sondern die Berechnung der Engpass.
    Natürlich verwende ich dabei deutlich kleinere Modelle.

    • Sieht so aus, als hättest du wirklich viele Modelle integriert, etwa krea, wan, hunyan usw.
      Ich frage mich, ob du ein gemeinsames Harness gebaut hast, mit dem sie alle laufen.
      Mich interessiert auch, welche Modelle konsistenter innerhalb des VRAM-Budgets bleiben.

  • llama.cpp unterstützt verschiedene Quantisierungen mit 4 Bit und weniger und mmap-t Modelle standardmäßig, sodass nicht alle Gewichte im Speicher gehalten werden müssen.
    Das Betriebssystem holt sie bei Bedarf aus dem Storage.
    Es ist cool, dass das mit sehr wenig Code und ohne Abhängigkeiten umgesetzt wurde, aber ich frage mich, ob es in der Praxis einen Performance-Vorteil gibt.

  • Ziemlich cool.
    Ich habe diese Woche mit GLM 5.2 gearbeitet und war ebenfalls beeindruckt.
    In der Firma testen wir lokale Ausführung auf extrem teurer Hardware, bevor wir das nächste Projekt starten; schön zu sehen, dass Leute diese riesige Open-Source-Modellveröffentlichung auf durchschnittlichen Maschinen laufen lassen.
    Auch wenn es noch nicht besonders praktikabel ist: gute Arbeit.

    • Welche Hardware ist das?

  • Ich kenne die interne Struktur von LLMs nicht besonders gut, frage mich aber, ob man eine ähnliche Architektur auch für andere Modelle mit „Schichten“ verwenden kann.
    Also etwa: Wenn eine Schicht ihre Arbeit beendet hat, entfernt man sie aus dem RAM, lädt die nächste Schicht von der Platte und aktiviert sie dann auf dem Ergebnis der ersten Schicht.

  • Ich habe eine Maschine mit 64 GB RAM und 24 GB VRAM und frage mich, ob man das so anpassen kann, dass mehr RAM genutzt wird.
    Oder vielleicht könnte man Gemma/Qwen auf der GPU laufen lassen und GLM-5.2 kleinere Aufgaben dorthin delegieren lassen.
    Möglicherweise müsste GLM-5.2 dafür ein Stück weit nachtrainiert werden.
    Ich frage mich auch, ob man die Geschwindigkeit erhöhen kann, indem man mehrere Laufwerke parallel nutzt und so die Bandbreite steigert.
    In der SSD-Verschleißwarnung steht, dass ein Cold Start mit etwa 11 GB/Token an zufälligen Lesezugriffen schwergewichtig ist, dass das Lesen selbst sicher ist, das Page Cache des Betriebssystems aber Schreibzugriffe verursachen kann und übermäßige Nutzung den Verschleiß günstiger SSDs beschleunigen kann.
    Ein sicherer Weg könnte sein, eine separate Partition für die Modellgewichte anzulegen und sie schreibgeschützt zu setzen.
    Ich weiß nicht, ob der Page Cache partitions- oder laufwerksbezogen ist, aber falls er laufwerksbezogen ist, könnte man vielleicht auch eine schreibgeschützte data.iso wie eine Partition formatieren und als Laufwerk mounten.

    • Ich nutze einen kleinen Laptop.
      Wenn ich weitere Laufwerke hätte, könnte ich das tatsächlich testen.
      Wenn du Benchmarks hast, stell sie gern als Pull Request oder Issue ein, dann können wir gemeinsam daran arbeiten.
    • Ich frage mich, ob „das Page Cache des Betriebssystems kann Schreibzugriffe verursachen“ eine Halluzination ist.
      Was übersehe ich? Warum sollten massive Lesezugriffe Schreibzugriffe verursachen?
    • Das könnte eine gute Idee sein, und wir können gemeinsam daran arbeiten.

  • Auf der Seite gibt es eine SSD-Verschleißwarnung: https://github.com/JustVugg/colibri#ssd-wear-warning
    Wenn man einen selbst zusammengebauten Desktop-PC nutzt, kann man die SSD ersetzen, aber was sollen Nutzer mit verlöteter SSD tun?
    Solche Anwendungen vermeiden oder das Risiko akzeptieren, dass der Speicher frühzeitig ausfällt, und trotzdem weitermachen?
    Vermutlich sollte man einen externen Speicher wie eine Verbrauchs-SSD nutzen.

    • Vermeiden ist richtig.
      Bei Laptops mit verlöteter SSD sollte man die Nutzung definitiv überwachen und vorsichtig sein.
      Dieses Projekt wirkt eher wie ein Experiment als etwas, das jeder laufen lassen sollte, ist aber trotzdem ziemlich cool.
    • Nach meinem Verständnis geht es in der Warnung um Swap-Out bei übermäßigem Speicherverbrauch.
      Man muss das hier nicht abergläubisch betrachten.
      Plattenaktivität, insbesondere Schreibzugriffe, kann man messen.
      Unter Linux zum Beispiel mit iostat oder vmstat.
    • Das ist eine ziemlich konservative Warnung.
      Die Anwendung führt keine Schreibzugriffe aus, daher verschleißt die Anwendung selbst die SSD in der Praxis nicht.
      Der Rest sind eher allgemeine Verwaltungsregeln, die nichts mit der Anwendung zu tun haben.
    • Für so einen Zweck wäre vermutlich ein externes Laufwerk richtig.

  • Technisch beeindruckend, aber ich frage mich, ob es tatsächlich praktisch nutzbar ist.

  • Ich habe eigentlich an derselben Sache gebaut, bin aber den Weg gegangen, das gesamte Modell per mmap in den Speicher einzublenden, um zusätzlichen RAM-Verbrauch zu vermeiden.
    Außerdem habe ich Claude Medusahttps://arxiv.org/abs/2401.10774 für das Modell implementieren lassen, um die Vorteile von Multi-Token Prediction zu bekommen, ohne ein zusätzliches Modell in den Speicher zu laden.
    Gerade bin ich nach Hause gekommen; ergänzend: Alle Änderungen mache ich in llama.cpp, und das Endziel ist, es auf etwas wie einen Single-Board-Computer zu bringen, der eine mmap-Datei von NVMe verarbeitet.
    Auf Basis früherer Tests scheint die theoretische Grenze meiner aktuellen Konfiguration bei etwa 1,8 Token/Sekunde zu liegen, aber die zusätzlichen Medusa-Heads sind nicht vollständig trainiert, und ehrlich gesagt weiß ich nicht genau, ob das als generierte Tokens gezählt wird.
    Letztlich wirkt die Idee ähnlich, aber ich kann noch keinen LLM-Parser/Runner von Grund auf schreiben, also habe ich es dem Linux-Kernel überlassen, statt festzulegen, was im Speicher bleiben soll.
    Zum Schluss: Ich habe die Nutzung von llama.cpp auf 16 GB meiner 32 GB begrenzt, also könnte man sie möglicherweise noch weiter senken.

    • Colibrì muss weiter verbessert werden; Ideen, Pull Requests, Issues und Benchmarks sind alle willkommen.
    • Genau dieser Ansatz war es, über den ich mich gewundert hatte.