antirez/ds4 - Lokale Inferenz-Engine für DeepSeek V4 Flash auf Metal

• Eine lokale Inferenz-Engine speziell für DeepSeek V4 Flash, optimiert für Apple-Metal-GPUs; eine native C-Implementierung, die sich auf ein einzelnes Modell konzentriert statt ein universeller GGUF-Runner zu sein
• DeepSeek V4 Flash bietet dank weniger aktiver Parameter hohe Geschwindigkeit und erzeugt im Thinking-Modus im Vergleich zu anderen Modellen nur etwa ein Fünftel so lange Denkphasen
• Durch ein Kontextfenster von 1 Million Token und einen extrem stark komprimierten KV-Cache ist Long-Context-Inferenz auch lokal möglich; unterstützt wird zudem persistenter Disk-KV-Cache
• Ein integrierter HTTP-API-Server, kompatibel mit OpenAI und Anthropic, ermöglicht die sofortige Anbindung an verschiedene Coding-Agenten wie Claude Code, opencode und Pi
• Aufgebaut auf dem Fundament des llama.cpp- und GGML-Ökosystems; ein Projekt, das mit starker Coding-Unterstützung von GPT 5.5 entwickelt wurde

---

Projektüberblick und Designphilosophie

• ds4.c ist eine kompakte native Inferenz-Engine ausschließlich für DeepSeek V4 Flash und weder ein universeller GGUF-Runner noch ein Wrapper für andere Runtimes
• Der Kernpfad ist ein auf DeepSeek V4 Flash spezialisierter Metal-Graph-Executor; dazu kommen DS4-spezifisches Laden, Prompt-Rendering, KV-Status und Glue-Code für die Server-API
• Im Bereich lokaler Inferenz gibt es viele hervorragende Projekte, doch durch das ständige Auftauchen neuer Modelle wird die Aufmerksamkeit zersplittert
  • Dieses Projekt konzentriert sich bewusst auf jeweils ein Modell und führt dafür offizielle Vektorvalidierung (Logits), Long-Context-Tests und Agent-Integration durch
• Die Vision lokaler Inferenz: A) eine Inferenz-Engine mit HTTP-API + B) ein für eine bestimmte Engine optimiertes GGUF + C) Tests und Validierung über Implementierungen von Coding-Agenten — diese drei Elemente sollen zusammenarbeiten
• Nur für Metal; eine spätere CUDA-Unterstützung ist möglich, aber nicht fest zugesagt
  • Der CPU-Pfad existiert nur zur Korrektheitsprüfung; wegen eines Implementierungsbugs der virtuellen Speicherverwaltung in der aktuellen macOS-Version führt das Ausführen des CPU-Codes derzeit zu Kernel-Crashes
• Entwickelt mit starker Unterstützung von GPT 5.5, wobei Menschen Ideen, Tests und Debugging anführten

Warum DeepSeek V4 Flash eine eigene Engine bekommen hat

• Wenige aktive Parameter sorgen für höhere Inferenzgeschwindigkeit
• Im Thinking-Modus erzeugt es im Vergleich zu anderen Modellen nur etwa ein Fünftel so lange Denkphasen, wobei die Länge der Denkphase proportional zur Problemkomplexität ist
  • Selbst in Situationen, in denen andere Modelle im Thinking-Modus praktisch unbrauchbar sind, bleibt DeepSeek V4 Flash nutzbar
• Unterstützung für ein Kontextfenster von 1 Million Token
• Mit 284B Parametern kennt es im Vergleich zu 27B- und 35B-Modellen mehr Informationen an den Wissensgrenzen
  • Unterschiede zeigen sich etwa bei Fragen zu italienischen TV-Programmen oder Politik
• Die Schreibqualität in Englisch und Italienisch liegt auf dem Niveau eines Beinahe-Frontier-Modells
• Der KV-Cache ist extrem stark komprimiert, sodass Long-Context-Inferenz auf lokalen Rechnern möglich ist; unterstützt wird außerdem persistenter Disk-KV-Cache
• Mit spezieller Quantisierung funktioniert es selbst mit 2-Bit-Quantisierung gut und kann auf einem MacBook mit 128 GB RAM laufen
• Künftige V4-Flash-Updates von DeepSeek werden erwartet

Dank an llama.cpp und GGML

• ds4.c linkt nicht gegen GGML, steht aber auf dem von llama.cpp erschlossenen Weg
• Die Kernel von llama.cpp, Quantisierungsformate, das GGUF-Ökosystem und das Hard-won-Engineering-Wissen sind unverzichtbare Referenzen
• Ein Teil des Quellcodes wurde auf Source-Level unter MIT-Lizenz beibehalten oder übernommen: GGUF-Quant-Layouts und -Tabellen, CPU-Quant-/Dot-Logik, bestimmte Metal-Kernel usw.
• Die Copyright-Hinweise der GGML-Autoren bleiben in der LICENSE-Datei erhalten

Modellgewichte

• Es funktionieren nur die speziell für dieses Projekt veröffentlichten DeepSeek V4 Flash GGUFs; beliebige DeepSeek-/GGUF-Dateien sind nicht kompatibel
• Die 2-Bit-Quantisierung nutzt asymmetrische Quantisierung
  • Quantisiert werden nur die MoE-Experten: up/gate mit IQ2_XXS, down mit Q2_K
  • Gemeinsame Experten, Projektionen, Routing und andere Komponenten bleiben unquantisiert, um die Qualität zu sichern
• Mit ./download_model.sh q2 wird das Modell für Maschinen mit 128 GB RAM heruntergeladen, mit ./download_model.sh q4 für Maschinen mit mindestens 256 GB RAM
  • Der Download erfolgt von Hugging Face (antirez/deepseek-v4-gguf); unterstützt wird das Fortsetzen teilweiser Downloads via curl -C -
• Mit ./download_model.sh mtp lässt sich optional ein GGUF mit Unterstützung für speculative decoding herunterladen
  • Der MTP-/speculative-decoding-Pfad ist noch experimentell und bringt derzeit nur einen geringen Geschwindigkeitsgewinn

Geschwindigkeits-Benchmarks

• Einzelmessungen der Metal-CLI mit --ctx 32768, --nothink, greedy decoding und -n 256
• MacBook Pro M3 Max, 128 GB (q2)
  • Kurzer Prompt: Prefill 58.52 t/s, Generierung 26.68 t/s
  • Prompt mit 11709 Token: Prefill 250.11 t/s, Generierung 21.47 t/s
  • q4: wegen Speichermangel N/A
• Mac Studio M3 Ultra, 512 GB (q2)
  • Kurzer Prompt: Prefill 84.43 t/s, Generierung 36.86 t/s
  • Prompt mit 11709 Token: Prefill 468.03 t/s, Generierung 27.39 t/s
• Mac Studio M3 Ultra, 512 GB (q4)
  • Kurzer Prompt: Prefill 78.95 t/s, Generierung 35.50 t/s
  • Prompt mit 12018 Token: Prefill 448.82 t/s, Generierung 26.62 t/s

CLI-Verwendung

• Mit der Option -p wird ein One-shot-Prompt ausgeführt; ohne -p startet der Modus für interaktiven Multi-Turn-Chat
• Die interaktive CLI hält das gerenderte Chat-Transkript und Live-Metal-KV-Checkpoints vor, sodass jede Runde das vorherige Gespräch erweitert
• Nützliche Befehle: /help, /think, /think-max, /nothink, /ctx N, /read FILE, /quit
  • Mit Ctrl+C wird die aktuelle Generierung abgebrochen und zur Eingabeaufforderung zurückgekehrt
• Standardmäßig ist der Thinking-Modus aktiv; mit /nothink oder --nothink wird in den Modus für direkte Antworten gewechselt
• Mit --mtp MTP.gguf --mtp-draft 2 kann optional der spekulative MTP-Pfad aktiviert werden
  • Nützlich nur bei greedy decoding; das Confidence-Gate (--mtp-margin) verhindert die Annahme langsamer Abschnitte

Server

• Es kann ein lokaler HTTP-Server ausgeführt werden, der mit OpenAI und Anthropic kompatibel ist
• Nur für Metal; im Speicher wird ein einzelner veränderbarer Graph/KV-Checkpoint gehalten
  • Sendet ein zustandsloser Client eine längere Version desselben Prompts erneut, kann ein gemeinsames Präfix wiederverwendet werden
• Request-Parsing und Sockets laufen im Client-Thread, die eigentliche Inferenz wird jedoch über einen einzelnen Metal-Worker serialisiert
  • Der Server verarbeitet derzeit keine mehreren unabhängigen Requests im Batch; gleichzeitige Anfragen warten der Reihe nach

• Unterstützte Endpunkte

  • GET /v1/models, GET /v1/models/deepseek-v4-flash
  • POST /v1/chat/completions, POST /v1/completions, POST /v1/messages

• /v1/chat/completions (OpenAI-kompatibel)

  • Unterstützt messages, max_tokens/max_completion_tokens, temperature, top_p, top_k, min_p, seed, stream, stream_options.include_usage, tools, tool_choice
  • Tool-Schemata werden im DSML-Tool-Format von DeepSeek gerendert, erzeugte DSML-Tool-Calls werden zurück in OpenAI-Tool-Calls umgewandelt

• /v1/messages (Anthropic-kompatibel)

  • Endpunkt für Clients im Stil von Claude Code
  • Unterstützt system, messages, tools, tool_choice, max_tokens, temperature, top_p, top_k, stream, stop_sequences und Thinking-Steuerung
  • Tool-Nutzung wird als Anthropic-tool_use-Block zurückgegeben
• Beide APIs unterstützen SSE-Streaming; im Thinking-Modus wird der Inferenzprozess in nativer API-Form gestreamt

Integration von Agent-Clients

• ds4-server kann mit lokalen Coding-Agenten integriert werden, die OpenAI-kompatible Chat-Completions verwenden
• Bei Ausführung der 2-Bit-Quantisierung (81 GB) auf 128 GB RAM ist ein Kontextfenster von 100k bis 300k Token sinnvoll
  • Das vollständige Kontextfenster von 1 Mio. Token benötigt etwa 26 GB Speicher (davon rund 22 GB nur für den komprimierten Indexer)
• Mit einer Ausgabelimit-Einstellung von 384000 lässt sich ein Token-Cap vermeiden (das Modell kann bis zu 384k Token generieren)

• opencode-Integration

  • Konfiguration durch Hinzufügen von Provider- und Agent-Einträgen in ~/.config/opencode/opencode.json
  • baseURL auf http://127.0.0.1:8000/v1 setzen

• Pi-Integration

  • Provider-Konfiguration in ~/.pi/agent/models.json ergänzen
  • Enthält Kompatibilitätsoptionen wie das Thinking-Format von DeepSeek, Unterstützung für Reasoning Effort und Streaming-Usage
  • Kann in ~/.pi/agent/settings.json als Standardmodell gesetzt werden

• Claude-Code-Integration

  • Verwendet den Anthropic-kompatiblen Endpunkt; Umgebungsvariablen werden per Wrapper-Skript ~/bin/claude-ds4 gesetzt
  • ANTHROPIC_BASE_URL auf den lokalen Server setzen und alle Modellvariablen auf deepseek-v4-flash stellen
  • Claude Code sendet anfangs einen großen Prompt mit etwa 25k Token; daher ist --kv-disk-dir zwingend erforderlich
    • Nach dem ersten teuren Prefill kann der Disk-KV-Cache das gespeicherte Präfix wiederverwenden, sodass das gesamte Prompt in Folgesitzungen nicht erneut verarbeitet werden muss

Thinking-Modus

• DeepSeek V4 Flash unterstützt drei Modi: non-thinking, thinking und Think Max
• Standard auf dem Server ist der Thinking-Modus
• Mit reasoning_effort=max kann Think Max angefordert werden, allerdings nur dann, wenn die Kontextgröße groß genug für die Empfehlungen der Model Card ist
  • Bei kleinem Kontext erfolgt ein Fallback auf normales Thinking
• OpenAI reasoning_effort=xhigh wird auf normales Thinking gemappt, nicht auf Think Max
• Wenn eine direkte Antwort benötigt wird, können thinking: {"type":"disabled"}, think:false oder ein non-thinking-Modellalias wie deepseek-chat verwendet werden

Disk-KV-Cache

• Die Chat-/Completion-APIs sind zustandslos, daher senden Agent-Clients bei jeder Anfrage den gesamten bisherigen Dialog erneut
• ds4-server verarbeitet dies, indem der gerenderte Token-Stream mit dem gecachten Token-Präfix verglichen wird
  • Ein Live-Checkpoint im Speicher bedient die aktuelle Sitzung
  • Der Disk-KV-Cache ist der Mechanismus, um nützliche Präfixe über Sitzungswechsel und Server-Neustarts hinweg zu erhalten
• Derzeit gibt es im Speicher nur einen einzigen Live-KV-Cache; wenn eine neue, nicht verwandte Sitzung ihn ersetzt, kann die vorherige Sitzung nur dann ohne erneutes Prefill fortgesetzt werden, wenn ihr Checkpoint in den Disk-KV-Cache geschrieben wurde
• Aktivierung über --kv-disk-dir und --kv-disk-space-mb

• Cache-Key und Dateistruktur

  • Der Cache-Key ist ein SHA1-Hash der exakten Token-IDs, nicht des Rohtexts
  • Jede Token-ID wird als 32-Bit-Integer im Little-Endian-Format gehasht; Dateinamen haben die Form <sha1>.kv
  • Es wird mit gewöhnlichem read/write-I/O geschrieben, ohne mmap (um zusätzliche VM-Mappings in einem Prozess zu vermeiden, der das Modell bereits mapped)

• Layout der Disk-Cache-Datei

  • Fester KVC-Header mit 48 Byte: magic(KVC), Version, Quantisierungs-Bits der gerouteten Experten, Speichergrund, Anzahl gecachter Token, Hit-Count, Kontextgröße, Unix-Zeitstempel für Erstellung/letzte Nutzung, Anzahl der Bytes der DS4-Session-Payload
  • Gerenderter Text: tokenizer-dekodierter Text des gecachten Token-Präfixes (nur zur Beobachtung, nicht als Schlüssel verwendet)
  • DS4-Session-Payload: beginnt mit 13 u32-Feldern im Little-Endian-Format, darunter magic(DSV4), Payload-Version, Kontextgröße, Prefill-Chunk-Größe, KV-Ring-Kapazität usw.
    • Gespeichert werden Checkpoint-Token-IDs, float32-Logits für das nächste Token, die Zahl komprimierter Attention-Zeilen pro Layer, Live-Raw-Sliding-Window-KV-Zeilen, KV-Zeilen komprimierter Layer sowie Compressor-Frontier-Tensoren

• Zeitpunkte zum Speichern von Checkpoints

  • cold: nachdem ein langer Initial-Prompt ein stabiles Präfix erreicht hat, vor der Generierung
  • continued: wenn Prefill oder Generierung um ein konfiguriertes Intervall fortgeschritten sind
  • evict: bevor eine nicht verwandte Anfrage die Live-Session im Speicher ersetzt
  • shutdown: beim sauberen Herunterfahren des Servers
• Beim cold-Speichern wird ein kleines Token-Suffix abgeschnitten und an Prefill-Chunk-Grenzen ausgerichtet, um bei künftigen Requests Retokenisierungsfehler an BPE-Grenzen zu vermeiden
  • Standardwerte: minimales Präfix von 512 Token, maximal 30000 Token beim cold-Speichern, Tail-Trim von 32 Token, Chunk-Ausrichtung auf 2048 Token
• Standardmäßig können Checkpoints zwischen 2-Bit- und 4-Bit-Varianten mit gerouteten Experten wiederverwendet werden, wenn das Token-Präfix identisch ist
  • Mit --kv-cache-reject-different-quant lässt sich die Wiederverwendung auf identische Quantisierung beschränken

Backend

• Standard-Backend ist Metal (--metal)
• Ein CPU-Pfad für Referenz/Debugging existiert ebenfalls (--cpu), ist aber nicht für den Produktionseinsatz gedacht
  • Der Server ist ausschließlich für Metal; die optimierte Implementierung befindet sich im Metal-Graph-Pfad

• MIT-Lizenz, Implementierung in C/Objective-C/Metal

[GN⁺]

Hacker-News-Kommentare

• Ich habe es zusammen mit Claude Code auf einer bestehenden Codebasis ausprobiert, und obwohl es ein 2-Bit-quantisiertes Modell ist, scheint es seinen Zweck zu erfüllen.
  Die Prompt-Verarbeitung dauert einige Minuten, aber das eigentliche Editieren ist mit über 20 Token/s ziemlich schnell.
  Bei kleinen Aufgaben hat es die Code-Erkundung, das Anwenden von Änderungen und das Schreiben von Tests geschafft, konnte aber auf einen kleinen Hinweis hin nichts reparieren.
  Noch schlimmer war, dass es mitten beim Lösen eines anderen Problems halluziniert eine parallele Unterhaltung über „The Duck“ hineingezogen hat. Vermutlich ist das eines der Beispiele aus dem initialen Prompt von Claude Code.

• Ich habe früher etwas sehr Ähnliches für ein Qwen3-Modell gebaut. Es führt nur Qwen3 aus, unterstützt nur einige Quantisierungen, lädt aus GGUF und verwendet eine von Claude iterativ optimierte Inferenz.
  Das Ganze war nur ein paar Dateien groß und leicht zu verstehen, also war es ein Projekt, mit dem Studierende experimentieren und lernen konnten, etwa durch das Hinzufügen von Decoding-Strategien oder Dingen wie Abliteration. Bekannte Frameworks sind groß und komplex und daher schwer zu hacken, und Lehrprojekte bleiben oft bei alten Dingen wie GPT-2 stehen.
  Es begann als Lehrprojekt, aber seitdem geht mir eine Idee nicht mehr aus dem Kopf. Wie wäre es mit einer extrem optimierten Inferenz-Engine, die auf eine bestimmte GPU+Modell-Kombination zugeschnitten ist? GPUs sind teuer und werden immer schwerer zu bekommen, also könnte man vermutlich einiges optimieren, wenn man genügend Abstraktion entfernt und direkt auf die genaue Hardware und das konkrete Modell zielt.
  Das Problem ist nur, dass man alles von Grund auf neu machen müsste, sobald das Modell veraltet ist.

  • Bereits verwendete Inferenz-Engines enthalten Backend-Komponenten, die für unterschiedliche Hardware optimiert sind.
    Auf weniger populären Plattformen gibt es noch relativ leicht mitzunehmende Performance-Gewinne, aber es bleibt nicht viel Raum, deutlich bessere Leistung zu erreichen, indem man einen hyperoptimierten Modelläufer nur für eine bestimmte GPU-Familie baut. Die Kernberechnungen werden bereits von hochoptimierten, auf die jeweilige GPU abgestimmten Kernels erledigt.
    Es gibt auch llama.cpp-Forks, die für bestimmte CPU-Architekturen besser optimiert sind, aber sofern sich die Maintainer nicht grundsätzlich uneinig sind, ist es wahrscheinlich besser investierte Zeit, solche Verbesserungen upstream zu mergen, statt für ein bestimmtes Modell+GPU-Setup einen separaten Runner zu bauen.
  • Das erinnert mich an die berühmte FizzBuzz-High-Performance-Codegolf-Antwort. Wenn man so eine Art Optimierung auf Inferenz anwenden könnte, ließe sich die Geschwindigkeit vielleicht um mehr als das Zehnfache steigern.
    https://codegolf.stackexchange.com/questions/215216/high-thr...
  • Darüber hinaus frage ich mich, wie es wäre, Chips direkt passend zum Modell zu entwerfen. Was wäre, wenn man von digital auf analog wechselt und Vektoren nicht als Bits, sondern als Spannungen darstellt?
    Könnte man die rechenintensive Matrixmultiplikation mit Operationsverstärkern ausführen? Und könnte so ein analoger Ansatz viel effizienter sein als die Grenzen bitbasierter Darstellung?
  • Mojo scheint genau auf so etwas wie hyperoptimierte, hardware-spezifische Engines abzuzielen, aber hier wird es kaum erwähnt.
  • Ich habe etwas Ähnliches gebaut. Ein Problem ist, dass LLMs wirklich furchtbar darin sind, gute Shader zu schreiben. Ich habe viel zu viel Zeit darauf verwendet, sie dazu zu bringen, weniger schlechten Code zu erzeugen.

• Jetzt, da aktuelle KI sogar Kernel-Optimierung leisten kann, finde ich, dass mehr Leute selbst bessere Inferenz für ihre eigene Hardware bauen sollten.
  Ich habe eine alte W7900 (RDNA3), und abgesehen von 48 GB VRAM sehen Kennzahlen wie 123 FP16 TFLOPS/INT8 TOPS und 864 GB/s Speicherbandbreite ziemlich gut aus. Aber sowohl AMDs ROCm-Support als auch die llama.cpp-Unterstützung waren berüchtigt schlecht.
  Vor Kurzem habe ich angefangen, W8A8-INT8-Modelle zu tunen, um diese Karte als dedizierten Agenten-/Coding-Endpunkt zu nutzen. Ich habe über einige Tage hinweg etwa 800 automatische Iterationen laufen lassen und verschiedene Frontier-/SOTA-Modelle ausprobiert; überraschenderweise hat sich Kimi K2.6 sehr gut geschlagen. Am Ende war es bei Qwen3.6 MoE beim Prefill 20 % und beim Decode 50 % schneller als die besten bisherigen llama.cpp-Werte.
  Derzeit arbeite ich weiter an MTP- und DFlash-Optimierungen, und die Ergebnisse sind ziemlich zufriedenstellend. Als Nächstes will ich Gemma 4 ausprobieren.

  • Bei mir ist es mit einer 7900xtx ähnlich. 24 GB VRAM und auf dem Papier ordentliche Leistung, aber in der Praxis läuft das meiste nicht richtig.
    Trotzdem kann llama.cpp, auch wenn es vielleicht nicht die höchste Leistung bietet, die meisten Modelle konsistent ausführen. Es fehlt wohl an MTP und es gibt Probleme mit Cache-Invalidierung bei Hybridmodellen, aber immerhin weiß man wenigstens, was überhaupt läuft.
    Python-basierte Inferenzsysteme sind mit uv/venv, meinem venv, der Systemumgebung, Python und den Bibliotheken so durcheinander, dass man fast einen Agenten braucht, um herauszufinden, was tatsächlich gerade läuft. Ich weiß, dass das Skill-Issue oder Benutzerfehler sein kann, aber ich habe schlicht keine Zeit mehr dafür.
    Selbst wenn es nicht perfekt ist: Wenn man es auf GitHub oder Hugging Face hochlädt, kann ein anderer Agent dort ansetzen, statt bei null zu beginnen. Mit Ling-2.6-flash (107B-A7B4 MoE) habe ich das genauso gemacht, und auf meiner anderen Hardware für lokale LLMs, einem M2 Max, ist das das größte LLM, das sich noch praktikabel betreiben lässt.
    Auch wenn MTP nicht gut funktioniert, ist es immer noch besser als der aktuelle Zustand, in dem llama.cpp Ling-2.6-flash gar nicht ausführen kann. Die Diskussion dazu findet sich unter https://huggingface.co/inclusionAI/Ling-2.6-flash/discussion..., die 4-Bit-Quantisierung unter https://huggingface.co/ljupco/Ling-2.6-flash-GGUF und der Branch unter https://github.com/ljubomirj/llama.cpp/tree/LJ-Ling-2.6-flas....
  • Es wäre gut, wenn du dein Wissen und deine Ergebnisse teilen würdest.
    Ich finde, llama.cpp hätte PC-Support deutlich besser machen können. Ein Teil davon liegt sicher an schlechtem Vendor-Support, aber angesichts der vielen Nutzer überrascht es, dass man auf Standard-PCs nicht mehr stärker optimierte Inferenz sieht.

• Wirklich cool. Ich frage mich, was passiert, wenn man sich mehrere Monate lang intensiv auf die Optimierung eines einzelnen Open-Source-Modells konzentriert.
  Nicht nur auf das Inference Serving, sondern auch auf Harness-Optimierung und angepasste Workflows. Es wäre interessant zu sehen, wie weit man die Lücke schließen kann bei Dingen, die Frontier-Modelle dank Inferenz und Ableitung leisten, während Open-Source-Modelle aufgrund von Größen- oder Trainingsgrenzen von Haus aus schwächer sind.

  • Zwischen Frontier-Modellen und Open-Source-Modellen wird es immer eine große Lücke geben. Das gilt umso mehr, wenn man nicht extrem reich ist, und die ganze Branche ignoriert derzeit die Unit Economics, was absurd ist.
    Kimi 2.6 mit brauchbarer Token/s-Leistung zu betreiben kostet 20.000 Dollar im Monat; um diese Token mit Gewinn zu verkaufen, müssten die Hardwarekosten unter 1.000 Dollar im Monat liegen.
    Wenn du deine Fähigkeiten auf eine Zukunft setzt, in der Milliardäre großzügig Token für ein Zehntel bis ein Zwanzigstel der Kosten verkaufen oder in der Fantasie, dass leistungsfähige Open-Source-Modelle auf Consumer-Hardware laufen, dann ist es ohnehin schon vorbei.

• Es gibt einen lustigen, interessanten und ziemlich aussagekräftigen Datenpunkt: Mein MacBook M3 Max geht bei maximaler Token-Erzeugung mit DS4 auf bis zu 50 W Leistungsaufnahme hoch.

  • Das Internet scheint noch nicht bereit zu sein, den Datenpunkt zu akzeptieren, dass „LLM-Rechenzentren dank Skaleneffekten pro Nutzer technisch energieeffizienter sind als selbstgehostete LLMs“.
  • Es ist interessant, darüber nachzudenken, wie viel Strom diese Maschinen zum „Denken“ brauchen. Ich war vage davon ausgegangen, dass es „viel“ ist, aber es einmal als Zahl zu sehen, ist gut.
    Wenn DS4 Flash bei 50 W seinen Peak hat und 280B Parameter besitzt, würde DS4 Pro mit 1,6T Parametern dann grob bei 300 W liegen? GPT 5 und Opus in aktueller Form fühlen sich ähnlich wie etwa 500 W an.
    Wenn ich Claude Code benutze und das Modell allein vor sich hin monologisiert, kann ich dann davon ausgehen, dass irgendwo in einem Rechenzentrum 500 W verbrannt werden?
  • Das merkt vielleicht nicht jeder sofort, aber das ist wirklich ein hervorragendes und beeindruckendes Ergebnis. Auf meinem M4 Max verbrauchen die meisten Modelle 150 W.
  • Ich frage mich, ob diese Zahl wirklich stimmt. Und wenn man sich mit Hardware nicht auskennt, wie misst man so etwas überhaupt?
  • Das entspricht ungefähr dem Stromverbrauch von zwei bis drei menschlichen Gehirnen. Eine beeindruckende Leistung.

• Beim Mac Studio kann man keine Konfiguration mit mehr als 96 GB RAM bestellen. Das gilt auch für M3 Ultra oder M4 Max. Ich weiß nicht, ob das nur in Australien so ist.
  Beim MacBook Pro kann man dagegen beim M5 Mac 128 GB auswählen.
  https://www.apple.com/au/shop/buy-mac/mac-studio

  • Es fällt schwer zu glauben, dass dieser Speicher aus Unobtanium besteht.
    Apple hat sich womöglich entschieden, ihn lieber gar nicht erst zu bepreisen, statt Kontroversen über Wucherpreise oder Gegenwind wegen knapper Verfügbarkeit auszulösen.
  • Das ist nicht nur in Australien so: https://9to5mac.com/2026/05/05/apples-most-powerful-mac-stud...
    Alle Mac-Studio-Konfigurationen über 96 GB und das Basismodell des Mac mini wurden gestrichen. Es gibt auch Gerüchte, dass man erwägt, die Neo-Basiskonfiguration vom Markt zu nehmen.
    Offenbar geht man so mit den Fab-Kapazitäten und der RAM-Lieferknappheit um.
  • Das Studio ist inzwischen ein ziemlich altes Produkt. Wenn irgendwann ein neues Modell kommt, ist es sehr wahrscheinlich, dass es mehr Speicheroptionen gibt. Trotzdem ist ein 128GB M5 Max MBP hervorragend.

• Vielleicht übersehe ich eine einfache motivierende Benchmark oder ein Ziel.
  Ich nehme an, dass es schneller ist als die Nutzung normaler Toolchains oder dass es erlaubt, größere und intelligentere Modelle auszuführen, aber es scheint nicht klar aufgeschrieben zu sein, wie groß die bisherigen oder erwarteten Verbesserungen gegenüber der Baseline sind.
  Wenn man die relevanten Vergleichswerte kennt, kann man das vermutlich aus den genannten Zahlen berechnen.

• Sehr beeindruckend. Allerdings wirken etwa 4 Minuten, bis bei großen Eingaben die Antwort startet, merkwürdig.
  Ich nutze LLMs nicht auf Mac-Hardware, aber das ist ziemlich überraschend und scheint für den praktischen Einsatz eine erhebliche Hürde zu sein.
  Für die normale Nutzung ergibt die Erklärung mit dem Caching aber deutlich mehr Sinn. Claude Code kann typischerweise einen großen initialen Prompt von etwa 25k Tokens senden, bevor es mit nützlicher Arbeit beginnt, und wenn --kv-disk-dir aktiviert ist, kann nach dem ersten teuren Prefill der gespeicherte Prefix aus dem Disk-KV-Cache wiederverwendet werden, sodass nicht jedes Mal der gesamte Prompt neu verarbeitet werden muss.

  • Das passiert, wenn Coding-Agenten sehr große Systemprompts senden. Dasselbe gilt später, wenn Tool-Calls große Dateien oder Diffs einfügen.
    Auf dem M3 Ultra liegt die Prefill-Geschwindigkeit aber bei fast 500 Token/s, also klar im praktikablen Bereich. Beim M3 Max braucht man etwas mehr Geduld, aber es funktioniert gut, und wenn man den pi agent nutzt, gibt das Modell seinen Denkprozess aus, sodass man statt nur zu warten den unzensierten chain of thought lesen kann.
    Ich habe gestern auf X ein Video gepostet, in dem ich es auf einem M3 Max nutze, und es spuckt Tokens in ziemlich ordentlichem Tempo aus.
  • Auf dem M5 ist der Prefill schneller, frühere Generationen sind etwas schwächer.

• Auf dem MacBook ist die Token-Erzeugung bei großen LLMs akzeptabel schnell, das Problem ist aber das Einlesen des Kontexts.
  Nicht das inkrementelle Lesen mit KV-Cache wie in einer Chat-Sitzung, sondern das Einlesen großer Eingaben, etwa wenn man eine große Datei hineinkopiert. Das kann mehrere Minuten dauern.

  • DS4 kann Prompt-Tokens mit 460 pro Sekunde verarbeiten. Das ist nicht herausragend, aber auch nicht besonders langsam. Gilt für M3 Max; siehe die Benchmarks im README.
  • Kann jemand einfach erklären, warum das bei lokaler Inferenz so langsam ist, während gehostete Modelle so schnell wirken?
  • Wenn ich mich nicht irre, geht es in diesem Repository darum, mit 2-Bit-Quantisierung zu laufen.
    Das dürfte ziemlich weit von der ursprünglichen Intelligenz entfernt sein, die ein Cloud-Anbieter liefert.
    Trotzdem zeigt es besser, was mit lokalen LLMs in agentischen Workflows möglich ist.
  • Warum passiert das?
    Gibt es Architekturen, die nicht darauf beruhen, den gesamten Gesprächsverlauf erneut einzuspeisen? So etwas wie rekurrente LLMs?