So führt man GLM-5.2 lokal aus

 (unsloth.ai)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Das neue Open-Model GLM-5.2 von Z.ai ist vor allem deshalb bemerkenswert, weil es ein Beispiel dafür ist, wie sich ein großes Modell mit 744B Parametern, 40B aktiven Parametern und einem Kontextfenster von 1M lokal handhaben lässt
  • Unsloth bietet mit Dynamic GGUF einen Pfad für die lokale Ausführung; die empfohlene 2-Bit-Quantisierung UD-IQ2_M erfordert 239 GB Speicherplatz und eine Umgebung mit mindestens 245 GB RAM
  • Dynamic 1-Bit zeigt etwa 76,2 % Top-1-Accuracy bei 86 % Größenreduktion, Dynamic 2-Bit etwa 82 % Accuracy bei 84 % Größenreduktion; das entspricht also nicht der Interpretation „die Leistung wird genau in dem Maß schlechter, wie das Modell kleiner wird“
  • Es gibt zwei Wege zur Ausführung: Unsloth Studio und llama.cpp; Studio unterstützt unter MacOS, Windows und Linux Modellsuche, Download und Ausführung, RAM-Offloading sowie die Erkennung von Multi-GPU-Setups
  • Um lange Kontexte praktisch zu nutzen, muss man in llama.cpp den Speicher per KV-Cache-Quantisierung reduzieren; q4_0 ermöglicht etwa 3,5-fach, q4_1 etwa 3,2-fach längere Kontexte

Überblick über das GLM-5.2-Modell

  • GLM-5.2 ist ein neues Open-Model von Z.ai und lässt sich über Unsloth Dynamic GGUF auf lokaler Hardware ausführen
  • Die Modellspezifikationen sind wie folgt
    • Gesamtparameter: 744B
    • Aktive Parameter: 40B
    • Maximales Kontextfenster: 1.048.576
  • Es wird als Modell mit SOTA-Leistung für long-horizon coding, reasoning und agentic tasks vorgestellt
  • Laut Artificial Analysis und mehreren Benchmarks soll es eine Leistung auf dem Niveau von Claude 4.8 Opus, GPT-5.5 und Gemini 3.1 Pro zeigen
  • Unsloth erklärt, von Z.ai day-zero access erhalten zu haben
  • GGUF-Modelldateien für GLM-5.2 gibt es auf Hugging Face unter GLM-5.2-GGUF

Empfohlene Quantisierung und Speicheranforderungen

  • Für ein ausgewogenes Verhältnis von Zugänglichkeit und Genauigkeit wird die 2-Bit Dynamic Quant UD-IQ2_M empfohlen
    • Speicherplatzbedarf: 239 GB
    • Passt direkt in einen Mac mit 256 GB Unified Memory
    • Mit MoE-Offloading soll es auch auf 1x24GB GPU + 256GB RAM gut laufen
  • Die 1-Bit-Quantisierung passt in 223 GB RAM, 8-Bit benötigt 810 GB RAM
  • In der Tabelle zu den Inferenz-Hardwareanforderungen bedeutet Gesamtspeicher RAM + VRAM oder Unified Memory
    • Genannte Gesamtwerte: 223 GB, 245 GB, 290–360 GB, 372–475 GB, 570 GB, 810 GB
  • Für optimale Leistung sollte der verfügbare Speicher aus VRAM und System-RAM die Größe der quantisierten Modelldatei deutlich übersteigen

Thinking-Modus und Sampling-Einstellungen

  • GLM-5.2 bietet 3 Thinking-Modi
    • non-thinking
    • thinking High
    • thinking Max
  • Für komplexe Aufgaben wird Max Thinking empfohlen
  • In Unsloth Studio lassen sich High/Max Thinking und non-Thinking per UI umschalten
  • Für die meisten Anwendungsfälle werden folgende Einstellungen genannt
    • temperature = 1.0
    • top_p = 0.95
    • In anderen Modi top_p = 1.0
  • GLM-5.2 verwendet standardmäßig reasoning; bei reasoning_effort kann "high", "max" oder Deaktivierung gewählt werden
  • Beispiele zum Deaktivieren von Thinking
    • Normale Shell: --chat-template-kwargs '{"enable_thinking":false}'
    • Windows PowerShell: --chat-template-kwargs "{\"enable_thinking\":false}"
  • Auch in llama.cpp lassen sich --reasoning on oder --reasoning off verwenden
  • Beispiele für reasoning effort
    • --chat-template-kwargs '{"reasoning_effort":"max"}'
    • --chat-template-kwargs '{"reasoning_effort":"high"}'
    • --chat-template-kwargs '{"enable_thinking":false}'

Genauigkeit von Dynamic GGUF und Interpretation von KLD

  • Unsloth verwendet den KLD(KL Divergence)-Benchmark, um die Quantisierungsgenauigkeit von GLM-5.2-GGUF zu bewerten
  • Dynamic 4-Bit UD-Q4_K_XL und Dynamic 5-Bit UD-Q5_K_XL werden als weitgehend lossless beschrieben
  • Auch kleinere Quantisierungen arbeiten mit einer dynamischen Präzisionsverteilung, bei der wichtige Layer in höherer Präzision und weniger wichtige Layer mit weniger Bits gehalten werden
  • Die Werte nach purem Top-1-%-Accuracy-Maßstab sind wie folgt
    • Dynamic 1-Bit: etwa 76,2 % Accuracy, 86 % Größenreduktion
    • Dynamic 2-Bit: etwa 82 % Accuracy, 84 % Größenreduktion
    • Genauigkeitsvergleich: {b:76,82}
  • 86 % kleiner bedeutet nicht 86 % schlechter; für Dynamic 1-Bit wird die Interpretation ergänzt, dass die Genauigkeit gegenüber dem gesamten 1,5-TB-Modell um etwa 24 % niedriger liegt
  • „76 % Accuracy“ bedeutet nicht, dass bei einer Frage wie „The capital of France is“ zu 76 % Paris und zu 24 % Sydney gewählt wird
    • In diesem Beispiel wäre Paris laut Beschreibung immer 100 %, Sydney 0 %
    • Die 76-%-Zahl umfasst auch Veränderungen in der Verteilung von filler words und stop words über den gesamten Korpus
  • Bei Prompts wie „Create a novel“, bei denen mehrere richtige Anfänge möglich sind, kann sich die Tokenverteilung zwischen Baseline und quantisiertem Modell unterscheiden
    • Die Baseline kann [I] mit 100 % wählen, während das quantisierte Modell die Verteilung etwa auf [I] 76 % und [The] 24 % aufteilen kann
    • Das bedeutet nicht, dass mit 24 % Wahrscheinlichkeit unsinnige oder falsche Ausgaben erzeugt werden
  • KLD ist die Distanz zwischen den Wahrscheinlichkeiten der Baseline BF16 oder Q8_0 und der quantisierten Version
    • Ziel der Quantisierung ist es, die mittlere KL-Divergenz zwischen f(q(W)) und f(W) zu minimieren
    • f ist der language model forward, q die quantization operation und W die Modellparameter beziehungsweise weights
    • Bei KLD = 0 wäre das Modell perfekt rekonstruiert
  • Da die Ausführung von KLD über den gesamten Trainingskorpus von 15T Tokens zu teuer wäre, optimiert Unsloth mit mean KLD und kleinem repräsentativem Subset-Sampling
  • Auch 99,9 % KLD gelte allgemein als gut; ab 4 Bit gebe es einen größeren uplift, daher sei Dynamic 4-Bit für massive out-of-distribution tasks vermutlich am besten geeignet

Ausführung mit Unsloth Studio

  • Unsloth Studio ist eine Open-Source-Web-UI für lokale AI und unterstützt die Ausführung von GLM-5.2
  • Wichtige Funktionen sind
    • Lokale Modellausführung auf MacOS, Windows und Linux
    • Suche, Download und Ausführung von GGUF- und safetensor-Modellen
    • Automatische Erkennung von RAM-Offloading und Multi-GPU-Setups
    • Schnelle CPU- + GPU-Inferenz über llama.cpp
  • Die Installationsbefehle sind wie folgt
  • Der Startbefehl lautet
    • unsloth studio -H 0.0.0.0 -p 8888
    • Danach öffnet man im Browser http://127.0.0.1:8888 oder die benutzerspezifische URL
  • Es gibt auch eine Methode, Studio sicher per HTTPS zu betreiben
    • Unter Windows, Mac und Linux mit unsloth studio --secure
    • Verwendet einen kostenlosen Cloudflare-Tunnel
  • Beim ersten Start muss zur Kontosicherheit ein Passwort erstellt werden; danach ist eine erneute Anmeldung erforderlich
  • Im Studio-Chat-Tab sucht man nach GLM-5.2 und lädt anschließend das gewünschte Modell und die passende Quantisierung herunter
  • Vor dem Start des Modells sollte geprüft werden, ob genügend Compute-Ressourcen vorhanden sind
  • In Studio sollten die Inferenzparameter automatisch gesetzt werden, der Benutzer kann jedoch Kontextlänge, Chat-Template und weitere Einstellungen manuell ändern
  • Weitere Informationen finden sich im Unsloth Studio inference guide

Ausführung mit llama.cpp

  • Das llama.cpp-Tutorial behandelt die Ausführung der Quantisierung UD-IQ2_M und setzt mindestens 245 GB RAM voraus
  • Für schnelle lokale Inferenz wird llama.cpp verwendet
  • Wenn keine GPU vorhanden ist oder nur CPU-Inferenz gewünscht wird, ändert man -DGGML_CUDA=ON zu -DGGML_CUDA=OFF
  • Bei Apple-Mac-/Metal-Geräten verfährt man ebenfalls mit -DGGML_CUDA=OFF; Metal-Support ist standardmäßig aktiviert
  • Der Build-Prozess folgt diesem Ablauf
    • apt-get update
    • apt-get install pciutils build-essential cmake curl libcurl4-openssl-dev -y
    • git clone https://github.com/ggml-org/llama.cpp
    • cmake ... -DGGML_CUDA=ON
    • cmake --build ... --target llama-cli llama-mtmd-cli llama-server llama-gguf-split
    • cp llama.cpp/build/bin/llama-* llama.cpp
  • llama.cpp kann ähnlich wie ollama run Modelle direkt laden und herunterladen
  • Als Beispiel für den gewünschten Quantisierungstyp wird UD-IQ2_M gewählt; mit export LLAMA_CACHE="unsloth/GLM-5.2-GGUF" lässt sich der Speicherort erzwingen
  • Der direkte Downloadprozess von llama.cpp kann sehr langsam sein, daher wird ein manueller Download als bessere Option genannt

Beispiel für manuellen Download und Ausführung

  • Für schnelleren manuellen Download wird huggingface_hub verwendet
    • pip install huggingface_hub
    • hf download unsloth/GLM-5.2-GGUF --local-dir unsloth/GLM-5.2-GGUF --include "*UD-IQ2_M*"
  • Für near full precision kann --include "*UD-Q8_K_XL*" verwendet werden
  • Falls der Download hängen bleibt, wird auf Hugging Face Hub, XET debugging verwiesen
  • Der Downloadbefehl für Dynamic 1-Bit lautet
    • hf download unsloth/GLM-5.2-GGUF --local-dir unsloth/GLM-5.2-GGUF --include "*UD-IQ1_S*"
  • Die Modellpfade im conversation mode sind
    • 2-Bit: unsloth/GLM-5.2-GGUF/UD-IQ2_M/GLM-5.2-UD-IQ2_M-00001-of-00006.gguf
    • 1-Bit: unsloth/GLM-5.2-GGUF/UD-IQ1_S/GLM-5.2-UD-IQ1_S-00001-of-00006.gguf
  • Im Beispiel für llama-cli wird der erste Shard des 2-Bit-GGUF bei --model angegeben und mit folgenden Parametern gestartet
    • --temp 1.0
    • --top-p 0.95
    • --min-p 0.01
  • Im direkten Ausführungsbeispiel wird auch -hf unsloth/GLM-5.2-GGUF:UD-IQ2_M verwendet

Verhalten anhand eines Generierungsbeispiels

  • Die Dokumentation enthält ein Beispiel, in dem 2-Bit-GLM-5.2 Tool-Calling und SVG-Generierung ausführt
  • Nach dem Start von llama-cli folgt ein Beispiel, in dem die Erstellung eines „short Flappy Bird game“ angefragt wird
  • Das erzeugte einzelne HTML/JavaScript-Spiel trägt den Namen Sunset Flier
    • Es enthält canvas, Startbildschirm, Game-over-Bildschirm, HUD-Punktestand, NEW BEST! und eine RETRY-Schaltfläche
    • Ohne externe Assets erzeugt es Soundeffekte für flap, score, hit und die über die Web Audio API
    • Der Spielzustand wird in vier Phasen verwaltet: READY, PLAYING, DYING, OVER
    • Der Highscore wird über localStorage.getItem('sunsetFlierBest') und localStorage.setItem() gespeichert
  • Die Spielmechanik umfasst Schwerkraft, Flap-Impuls, zufällige Rohre, Kollisionen, Partikel, Bildschirmerschütterung und ein Medaillensystem
    • GRAVITY = 0.42
    • MAX_FALL = 9
    • PIPE_W = 68
    • PIPE_GAP = 180
    • PIPE_SPEED = 2.6
    • PIPE_SPACING = 220
  • Unterstützt werden Maus, Touch sowie die Tastaturtasten Space, ArrowUp und Enter
  • Dieses Spielbeispiel wird im Kontext gezeigt, dass es auch mit 1-Bit-Quantisierung gut funktionierte und der Sound korrekt arbeitete

Lange Kontexte und KV-Cache-Quantisierung

  • Um in llama.cpp lange Kontexte zu nutzen, muss man den Speicherverbrauch per KV-Cache-Quantisierung senken
  • llama.cpp hat kürzlich Techniken für höhere Genauigkeit bei der KV-Cache-Quantisierung ergänzt; der zugehörige PR ist https://github.com/ggml-org/llama.cpp/pull/21038
  • Unterstützte KV-Cache-dtypes sind
    • f32
    • f16
    • bf16
    • q8_0
    • q4_0
    • q4_1
    • iq4_nl
    • q5_0
    • q5_1
  • Standard ist f16
  • q4_0 verwendet etwa 4,5 Bit pro Gewicht und kann damit die Kontextlänge auf 16 / 4.5, also etwa das 3,5-Fache, erhöhen
    • Ein Modell, das bisher 10K unterstützte, könnte damit zum Beispiel in einen Bereich bis 35K kommen
  • q4_1 hat zusätzlich einen shifting parameter, könnte daher besser sein und bietet mit 5 Bit pro Gewicht etwa das 3,2-Fache an Kontextlänge
  • Das Ausführungsbeispiel für KV-Cache-Quantisierung nutzt das GLM-5.2-GGUF-Modell und folgende Sampling-Parameter
    • Modellpfad: unsloth/GLM-5.2-GGUF/UD-IQ2_M/GLM-5.2-UD-IQ2_M-00001-of-00006.gguf
    • --temp 1.0
    • --top-p 0.95
    • --min-p 0.01
    • --cache-type-k q4_1
    • --cache-type-v q4_1

Zahlen aus den Benchmark-Tabellen

  • Im Dokument folgt zwar eine Benchmark-Tabelle für GLM-5.2, in den bereitgestellten Inhalten fehlen jedoch die Spaltenüberschriften, sodass nicht überprüft werden kann, welchem Modell oder welcher Einstellung die einzelnen Zahlen entsprechen
  • Der Reasoning-Benchmark enthält folgende Zeilen und Werte
    • HLE: 40.5, 49.8*, 41.4*, 45, 31, 41.4, 37, 37.7
    • AIME 2026: 99.2, 95.7, 98.3, 98.2, 95.3, 97, -, 94.6
    • GPQA-Diamond: 91.2, 93.6, 93.6, 94.3, 86.2, 90, 93, 90.1
  • Der Coding-Benchmark enthält folgende Zeilen und Werte
    • SWE-bench Pro: 62.1, 69.2, 58.6, 54.2, 58.4, 60.6, 59, 55.4
    • NL2Repo: 48.9, 69.7, 50.7, 33.4, 42.7, 47.2, 42.1, 35.5
    • Terminal Bench 2.1 (Terminus-2): 81.0, 85, 84, 74, 63.5, 75, 65, 64
  • Der Agentic-Benchmark enthält folgende Zeilen und Werte
    • MCP-Atlas (Public Set): 76.8, 77.8, 75.3, 69.2, 71.8, 76.4, 74.2, 73.6
    • Tool-Decathlon: 48.2, 59.9, 55.6, 48.8, 40.7, -, -, 52.8

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Hacker-News-Kommentare

  • Läuft bei mir mit Q4_K_XL. Für etwa 6 tk/sec reichen 512 GB RAM und zwei RTX 3090 mit llama.cpp -cmoe
    Im Moment liegt es an miesem DDR4 mit 2400 MHz; mit 3200 MHz käme ich wohl auf etwa 9 tk/sec. Die CPU ist auch okay, ein 32-Core-EPYC, aber mit einem besseren 64-Core-Modell wären wohl bis zu 11 tk/sec drin
    Ich habe das als Budget-Setup zusammengestellt, bevor die Hardwarepreise völlig verrückt wurden, und bereue es zwar jeden Tag, aber es ist trotzdem großartig, so ein Modell zu Hause laufen lassen zu können. Gut für Planung oder wenn man allen nötigen Kontext gesammelt hat und dann einen One-Shot-Prompt absetzt
    Die gesamte Hardware hat mich beim Zusammenbau 2.400 Dollar gekostet, und wenn man gezielt sucht, gibt es Wege, solche Modelle auch zu Hause zu betreiben. Ich werde oft gefragt, warum man das macht oder wie viel man mit einer Cloud-API sparen würde, aber ich finde, die Fable-Sache hat den Wert von unabhängigem Betrieb gezeigt
    Danke an das unsloth-Team, und Q4_K_XL ist solide. Wenn man ein quantisiertes Modell lädt, sollte man, sofern es hineinpasst, die K_XL-Variante nehmen

    • Applaus für alle, die mit solchen Homebrew-Experimenten die Grenzen des Machbaren verschieben. Wie bei Krypto wird auch AI von viel Geschäftsleute-Lärm überdeckt, aber über Resilienz spricht kaum jemand
      Dasselbe gilt für Forschende, die Open-Source-Modelle in elektrische Zahnbürsten oder Tamagotchis quetschen wollen
    • Wenn du diese Last dauerhaft laufen lässt, bist du bei mindestens 600 W, also etwa 14 kWh pro Tag. Bei 0,2 Dollar pro kWh sind das 2,80 Dollar am Tag und allein rund 1.000 Dollar Stromkosten pro Jahr
      Wenn man nicht unbedingt Privacy oder das Gefühl braucht, alles selbst zu besitzen, ist Bezahlen beim Hyperscaler günstiger, bequemer und bei Tokens pro Sekunde auch deutlich schneller
      Trotzdem gefällt mir die Richtung, und ich bin gespannt, was für Self-Hosting-Hardware es in zwei Jahren geben wird
    • Ich habe fast dieselbe Konfiguration: zwei RTX 3090, 512 GB etwas schnelleres DDR4 und einen 64-Core-EPYC [0]
      Ich nutze das mit ziemlich viel Freude und will dieses Modell auch bald ausprobieren
      Außer zum Ausführen lokaler Modelle nutze ich die Maschine auch als meine primäre Remote-Entwicklungsplattform. Alle Claude-Code-Sessions laufen dort inzwischen in tmux
      Meine Finger sind glücklich, weil ich nicht ständig ein heißes Laptop anfassen muss. Dazu kommt, dass Claude Code den Akku brutal leerzieht
      [0] https://medium.com/@rathko/i-built-an-epyc-64-core-512gb-ram...
    • Die Formulierung „das ist alles, was man dafür braucht“ mag stimmen, wenn man das für 2.400 Dollar gekauft hat, aber heute liegt der Gesamtpreis viel näher bei 10.000 Dollar
      Allein der RAM kostet fast 5.000 Dollar, und die GPUs liegen bei jeweils ungefähr 2.000 Dollar, also ist das nach heutigem Stand ziemlich teure Hardware
    • Soweit ich es verstehe, fehlt der llama.cpp-Implementierung für dieses Modell noch die Unterstützung für DSA Sparse Attention, also ist sie noch ziemlich unvollständig
      Dadurch läuft das Modell mit anderen Mechanismen als denen, die im Training verwendet wurden, und es gab Berichte über geringere Qualität und schlechtere Performance
      Unabhängig davon finde ich GLM 5.2 in vielerlei Hinsicht weniger interessant als die DeepSeek-V4-Familie. DeepSeek V4 nutzt einen fortschrittlicheren Attention-Mechanismus und spart dadurch vor allem bei langen Kontexten viel KV-Cache-Speicher
      Das ermöglicht wiederum auch auf Consumer-Plattformen breitere Batch-Verarbeitung. GLM hat das nicht, und von der grundlegenden Performance-Architektur her wirkt es auf mich weitgehend ähnlich wie Kimi 2.6. Beide sind für Full-Quality auf normaler Hardware etwas zu schwer

  • Fast geschafft. Mein System hat 192 GB RAM + RTX 3090 24 GB, und ich war fast in der Lage, das laufen zu lassen
    Für MoE-Offloading werden wohl 24 GB VRAM und 256 GB RAM benötigt
    https://unsloth.ai/docs/models/glm-5.2#usage-guide
    In einem früheren Thread meinte jemand, die Hardware würde 500.000 Dollar kosten
    https://news.ycombinator.com/item?id=48629970

    • 500.000 Dollar sind eine massive Überschätzung. Wenn man auf FP8 oder BF16 mit hoher Parallelität abzielt, kann das hinkommen
      Mit NVFP4 sind ordentliche Geschwindigkeiten, grob 120 tok/s, plus Parallelität nach aktuellen Preisen schon für 80.000 bis 90.000 Dollar machbar, vielleicht sogar weniger
      Dafür bekommt man sechs RTX 6000 PRO Blackwell, eine vernünftige CPU und ein Mainboard sowie ein Netzteil. Das ergibt 576 GB VRAM
      Wenn 40 tok/s beim Decode und etwa 1.200 tok/s beim Prefill reichen, kommt man auch unter 50.000 Dollar weg
    • Mit 2 Bit sind gute Ergebnisse kaum zu erwarten. Für Coding liegt der ideale Bereich mindestens bei Q8
    • Ich hoffe, dieser Boom stößt wieder Fortschritte bei Computing-Hardware an wie in den 90ern
      Einer der Gründe, warum Hardware in den letzten 20 Jahren relativ stagniert hat, ist meiner Meinung nach, dass Unternehmen zu wenige Anwendungsfälle hatten, um Hardware-Upgrades zu rechtfertigen
      In den letzten 15 Jahren ist der Großteil von Geld und Energie in Mobile geflossen
      Günstige lokale Inferenz könnte genau die Einnahmequelle sein, die Server-, Desktop- und Notebook-Hersteller brauchen, um wieder in Bewegung zu kommen
    • RAM habe ich, aber kein VRAM. Welche Geschwindigkeit oder tok/s kann man mit einer 3090 mit 24 GB RAM erwarten?
      Ich bin ein bisschen versucht, mir mal eine GPU mit 24 GB RAM zu kaufen
    • Ich habe Gemini spaßeshalber gefragt, und es meinte, für ordentlichen Durchsatz ohne Quantisierung brauche man 500.000 Dollar

  • Mit „passt rein“ ist gemeint, dass es in 256 GB RAM passt, aber nur in stark quantisiertem Zustand, und selbst dann wird es weiterhin sehr langsam laufen
    Die Zahl in der Überschrift ist nicht die Token-Generierungsgeschwindigkeit, sondern die Prompt-Verarbeitungsgeschwindigkeit
    Wenn 10 tok/s herauskommen und die API 20–30 tok/s liefert, wirkt das auf den ersten Blick nicht so schlecht, aber ein Mac Studio oder Hardware, bei der nicht alles auf die GPU geladen wird, ist bei der Prompt-Verarbeitung 20- bis 50-mal langsamer als eine reine GPU-Konfiguration
    Genau das ist am Ende der Punkt, der es praktisch unbenutzbar macht, wenn man nicht 50.000 Dollar für GPUs ausgibt. Dazu kommt, dass man immer noch ein stark quantisiertes Modell verwendet

    • Hardware wie Nvidias Spark hat 128 GB Unified RAM
      Es gibt auch eine Dual-Port-Version für solche Geräte: https://www.nvidia.com/content/dam/en-zz/Solutions/networkin...
      Also 2 x 100 GB/s Ports, vielleicht auch 2 x 200 GB/s. Wenn man das Gerät tatsächlich in die Hände bekommt, weiß man vermutlich mehr
      Solche Geräte lassen sich auch clustern. Bei 2 oder 3 Geräten ist das mit 2 IP-Subnetzen ziemlich klar. Ab 4 Geräten könnte je nach Einfluss der Netzwerklatenz ein Switch nötig sein
      Apple scheint M-Serien mit viel RAM vergessen zu haben. Im Apple Store finde ich keine Konfiguration mit mehr als 96 GB Unified RAM, und selbst das kostet gefühlt eine Niere

  • Es wird gleichzeitig an mehreren Fronten vorangetrieben: Neue AI-Desktops mit GB10 sind relativ günstig, und per Clustering lässt sich 1 TB VRAM aufbauen
    Nvidia, AMD, Intel, Cerebras und andere treiben neue Hardware voran, und Open-Source-Modelle wie GLM 5.2 werden absurd gut
    Auch Flash-Modelle wie DeepSeek V4 Flash werden immer besser, und die Quantisierung entwickelt sich ebenfalls weiter
    Es wird außerdem möglich, Harnesses zu bauen, die je nach Aufgabe unterschiedliche Modelle verwenden, etwa große Modelle für schwierige Aufgaben und kleine Modelle für Routinekram
    Deshalb hoffen Leute, die von APIs wegwollen, bald zu Hause AI-Desktop-Cluster zu vernünftigen Preisen hosten zu können und dabei Leistung auf Opus-Niveau zu bekommen

    • Das Wort „relativ“ leistet hier allerdings ziemlich viel Arbeit. Wenn ein GB10 etwa 4.000 Dollar kostet, dann kostet ein 1-TB-Cluster 36.000 Dollar
      Im Vergleich zu einem vergleichbaren H200 ist das billig, aber für ein Homelab ohne Finanzierung durch OpenAI- oder Anthropic-RSUs bleibt es trotzdem außer Reichweite

  • Es fühlt sich an, als würde sich die Lücke so weit schließen, dass man lokal Modelle betreiben kann, die sogar fürs Programmieren gut genug sind, und einige Unternehmen dürften dadurch nervös werden. Liege ich falsch?

    • Ohne den aktuellen RAM-/GPU-Mangel wären diese Unternehmen wahrscheinlich noch nervöser als jetzt
      Stand heute gibt es aber nur sehr wenige Menschen, die sich Hardware leisten können, auf der solche Modelle effektiv laufen. Das dürfte sich in den nächsten Jahren nicht grundlegend ändern
      Wenn Z.ai eine auf Coding spezialisierte Version wie GLM-5.2 Flash im Bereich von etwa 80B Parametern herausbringt, würden sich die führenden US-Labore mehr Sorgen machen
      Insgesamt zeigen chinesische AI-Unternehmen, wie man mit weniger Ressourcen, teils mit deutlich weniger Ressourcen, das Gleiche erreicht, und wenn sich dieser Trend fortsetzt, wird das die Frontier-Labore nervös machen
      Allerdings werden auch chinesische AI-Unternehmen versuchen, ihren Burggraben zu schützen, indem sie keine Modelle veröffentlichen, die deutlich kleiner als ihre aktuellen Flaggschiffmodelle und gleichzeitig sehr leistungsfähig sind
      Alibaba Qwen scheint gerade an diesem Punkt zu sein. In letzter Zeit ist es recht still geworden, und das aktuelle 395B-Modell ist für die meisten Menschen viel zu groß, um es zu Hause zu betreiben. Es sieht diesmal auch nicht danach aus, dass ein kleineres Modell kommt
    • Ich glaube nicht. Ich kann mir gut vorstellen, dass Unternehmen entscheiden, solche Modelle für die eigene Entwicklung selbst zu hosten und zu betreiben
      Bei einem Entwicklerteam von etwa 10 Leuten kann eine einmalige Investition von 50.000 Dollar in einen LLM-Server ziemlich attraktiv sein
      Man bekommt unbegrenzte Tokens, ordentliche Performance, Upgrade-Optionen und die Möglichkeit zur Integration ins eigene Produkt
      Generell dürfte ein lokaler LLM-Ansatz für Unternehmen, die LLMs in Produkte einbauen wollen, noch attraktiver sein. Selbst ein etwas dümmeres Modell ist für viele Produktintegrationen immer noch gut genug
    • Um eine Bedrohung zu sein, muss es nicht einmal lokal laufen. Viele Unternehmen schauen auf das Modell, bei dem man Drittanbieter fürs Hosting solcher Modelle bezahlt, und die Preise liegen bei einem Bruchteil der Frontier-Labore
    • Der RAM-Bedarf ist immer noch ziemlich schmerzhaft
    • Lokal zu betreiben ist wirtschaftlich nicht sinnvoll. Für Privatsphäre ist es großartig und als Hobby macht es Spaß
      Aber die Auswahl ist im Wesentlichen: ein extrem langsamer CPU-Build mit 10.000 Dollar RAM, GPUs im Wert von 90.000 Dollar oder ein stark quantisiertes Modell, dessen Qualität schwer einzuordnen ist
      Zum Spaß kann man so etwas bauen, aber allein dadurch wird es noch nicht wirtschaftlich. Interessant ist trotzdem, dass es überhaupt möglich ist

  • OpenAI und Anthropic dürften das Timing des Releases von GLM 5.2 nicht mögen
    Es zeigt ziemlich deutlich, dass es keinen magischen Burggraben gab, sondern nur einen Vorsprung beim Start

  • Ich könnte einen Mac Studio mit 192 GB RAM verwenden, das liegt aber unter dem angegebenen Mindest-RAM
    Gerade weil es ein MoE ist: Könnte man das mit Swapping auf eine schnelle Disk irgendwie zum Laufen bringen?

    • So viel Swapping wäre wohl eine gute Methode, die gesamte Schreiblebensdauer (TBW) einer NVMe-SSD zu verbrauchen und ihre Lebensdauer massiv zu verkürzen
      Die Performance wäre außerdem mit etwa 0,1 tok/s katastrophal

  • Ich habe großen Respekt vor der Arbeit von unsloth, die Millionen Menschen den Einstieg in lokale AI erleichtert hat, aber dieser Beitrag wirkt etwas wie Download-Bait
    Wenn man zu viele Layer auf die CPU auslagert, funktioniert es überhaupt nicht gut. Ich habe es mehrfach ausprobiert und musste am Ende die schweren Hugging-Face-Cache-Ordner mit rm -rf löschen
    Ich bezweifle auch, dass eine 1-Bit- oder 2-Bit-Quantisierung von GLM 5.2, die größtenteils außerhalb des VRAM läuft, in der Praxis nützlicher ist als ein vollständig im VRAM liegendes Qwen3.6-27B Q8_0

  • Unabhängig davon, was im Artikel steht: Wer versucht, das auf einer Maschine mit 256 GB RAM zu betreiben, wird wahrscheinlich keine gute Zeit haben
    Die deutlich realistischere Untergrenze sind 512 GB
    Zum Glück stehen in meinem Homeoffice zwei Dual-Xeon-Workstations mit 512 GB RAM, die ich noch günstig gekauft habe, bevor die Preise gestiegen sind, sodass ich ein bisschen experimentieren kann