Ein paar Worte zu DS4

• DwarfStar 4 verbreitete sich schneller als erwartet und machte die Nachfrage nach einer lokalen AI-Erfahrung rund um ein einzelnes Modell sichtbar
• Zur schnellen Verbreitung trugen DeepSeek v4 Flash und eine asymmetrische 2/8-Bit-Quantisierung bei, wodurch der Betrieb mit 96 GB oder 128 GB RAM möglich wurde
• DS4 ist kein an ein bestimmtes Modell gebundenes Projekt, sondern will schnelle aktuelle Open-Weights-Modelle auf „GPU in a box“-Geräten ins Zentrum stellen
• Bei lokaler Inferenz scheint ein Ansatz sinnvoll, bei dem je nach Frage spezialisierte Modelle wie ds4-coding, ds4-legal oder ds4-medical geladen werden
• Künftige Schwerpunkte sind Qualitäts-Benchmarks, Coding-Agents, CI auf Heim-Hardware, mehr Portierungen sowie serielle und parallele verteilte Inferenz

---

Die schnelle Verbreitung von DS4 und ihr Hintergrund

• DwarfStar 4 gewann schneller als erwartet an Popularität und zeigte die Nachfrage nach einer lokalen AI-Erfahrung mit Fokus auf Integration eines einzelnen Modells
• Zur schnellen Verbreitung trugen das Erscheinen quasi-frontierartiger Modelle wie DeepSeek v4 Flash, deren Leistung und Geschwindigkeit groß genug sind, um die Lage bei lokaler Inferenz zu verändern, sowie die Kombination mit starker asymmetrischer 2/8-Bit-Quantisierung gemeinsam bei
• Durch diese Kombination wurde der Betrieb des Modells bereits mit 96 GB oder 128 GB RAM möglich
• Die in den vergangenen Jahren angesammelte Erfahrung der Local-AI-Bewegung beeinflusste das Entwicklungstempo von DS4, und ohne die Hilfe von GPT 5.5 wäre es wohl schwer gewesen, es in nur einer Woche zu bauen
• Die erste Woche war unterhaltsam, aber anstrengend; es wurde im Schnitt 14 Stunden pro Tag gearbeitet, mit einer Intensität ähnlich den ersten Monaten von Redis

Die künftige Richtung

• DS4 ist kein Projekt, das mit DeepSeek v4 Flash beginnt und endet; mit der Zeit kann sich das zentrale Modell ändern
• Ziel ist es, aktuelle Open-Weights-Modelle, die auf leistungsstarken Macs oder „GPU in a box“-Geräten wie dem DGX Spark tatsächlich schnell laufen, ins Zentrum von DS4 zu stellen
• Der nächste Kandidat ist DeepSeek v4 Flash, das als neuer Checkpoint veröffentlicht werden soll; auch eine Coding-Version oder Expertenvarianten für Recht und Medizin sind möglich
• Bei lokaler Inferenz scheint ein Ansatz sinnvoll, bei dem je nach Frage Modelle wie ds4-coding, ds4-legal, ds4-medical geladen werden
• Es ist wohl das erste Mal, dass ernsthafte Aufgaben, die man sonst Claude oder GPT gestellt hätte, an ein lokales Modell übergeben werden
• Durch Vector Steering wurde auch eine Erfahrung möglich, bei der sich LLMs freier nutzen lassen, und DS4 bietet ein Erlebnis, das Online-Frontier-Modellen weit näher kommt als kleinen lokalen Modellen
• Nach einigen chaotischen Anfangstagen will sich das Projekt auf Qualitäts-Benchmarks, Coding-Agents, CI-Tests auf Heim-Hardware, mehr Portierungen und verteilte Inferenz konzentrieren
• Verteilte Inferenz umfasst sowohl serielle (serial) als auch parallele (parallel) Verfahren und bleibt eine wichtige künftige Aufgabe
• AI ist zu wichtig, um nur ein bereitgestellter Service zu bleiben

[GN⁺]

Hacker-News-Kommentare

• DwarfStar4 ist eine kleine LLM-Inferenz-Runtime, mit der sich DeepSeek 4 ausführen lässt, und dem Blogpost nach werden derzeit 96 GB VRAM benötigt.
  Das ist als Erklärung für Leute gedacht, denen der Kontext fehlt :-)

  • Das ist nicht das vollständige Modell, sondern die Flash-Version, und die Quantisierung liegt auch nur ungefähr auf Q2- bis Q3-Niveau, also beeindruckend, aber doch ziemlich anders als das vollständige Modell.
  • Es wird erwähnt, dass 96 GB VRAM nötig sind; ich frage mich, ob das schon jemand auf einem Mac mit weniger RAM getestet hat.
    Es könnte vielleicht funktionieren, aber etwas langsamer werden, wenn Modellschichten aus dem Speicher nachgeladen werden.
  • Ich frage mich, wie sich DwarfStar4 von llama.cpp unterscheidet.

• Ich bin sehr gespannt, ab welchem Punkt die für das Programmieren nötige Intelligenz „gut genug“ ist.
  Ab einem gewissen Punkt könnte man ein weniger intelligentes Modell einfach länger an einem Problem arbeiten lassen und zum selben Ergebnis kommen, und wenn ich nicht eingreifen muss, ist das im Endeffekt dasselbe.
  DeepSeek V4 Pro fühlt sich an, als wäre es fast an diesem Punkt, und vielleicht gilt das auch für Flash.
  Ich frage mich auch, wie viel von Anthropics aktuellem Geschäftsmodell zusammenbrechen würde, sobald dieser Punkt erreicht ist.
  Bisher war es offensichtlich sinnvoll, für das intelligenteste Modell zu zahlen, aber inzwischen scheint klar, dass das Wachstumspotenzial dieser Idee begrenzt ist.
  Die Frage ist, wie lang die verbleibende Startbahn noch ist, und ich frage mich, ob Anthropics hektische Ausweitung in Richtung Enterprise und Produktivität daher kommt, dass sie diesen Trend bereits sehen.

  • Intelligentere Modelle schaffen Dinge, die kleinere Modelle einfach nicht können.
    Es scheint nicht bloß eine Frage davon zu sein, länger zu warten.
  • Am Ende wird es immer auf die Kosten hinauslaufen.
    Es geht um die Balance zwischen Entwicklerzeit, Entwicklerkosten, AI-Kosten und Produktivität der Entwickler.
    Wenn man sich 4.6 ansieht, scheint das für normale Unternehmen nahe an der Grenze des Tragbaren zu liegen, also müssten sich andere Variablen ändern.
  • Der Open-Source-Coding-Agent Kilo hat Deepseek v4 Pro und Flash gegen Opus 4.7 und Kimi K2 getestet[1].
    Die Ergebnisse waren ordentlich, aber deutlich schlechter als bei Opus, und selbst mit den aktuellen Einführungsrabattpreisen von Deepseek lagen die Kosten fast gleichauf.
    Diese Kostenstruktur ist interessant; ich habe Ähnliches auch bei Sonnet und Opus gesehen, und beim eigenen Benchmarking gab es Modelle, bei denen der Preis gut aussah, die aber so viele Tokens verbrauchten, dass sie am Ende genauso viel kosteten wie ein „teureres“ Modell.
    [1] https://blog.kilo.ai/p/we-tested-deepseek-v4-pro-and-flash
  • Für Hobby-Programmierer wird das wohl ziemlich schnell gut genug sein, aber Unternehmen werden vermutlich weiterhin für schnellere und intelligentere Modelle zahlen.
    Warum sollte man Programmierer warten lassen?

• Ich finde es gut, so ein eng fokussiertes Tool zu sehen.
  Unterstützte Backends zielen primär auf Metal und beginnen bei MacBooks mit 96 GB RAM.
  NVIDIA CUDA achtet speziell auf DGX Spark, und AMD ROCm wird nur im rocm-Branch unterstützt.
  Weil antirez selbst keinen direkten Hardwarezugang hat, ist das von main getrennt, und die Community rebased es bei Bedarf.
  Ohne llama.cpp und GGML würde dieses Projekt nicht existieren, und es wird auch dazu geraten, den Dankesabschnitt zu lesen.
  Allerdings scheint Offloading in den Systemspeicher noch nicht unterstützt zu werden[0].
  Deshalb werde ich wohl auch das llama.cpp-Issue weiter im Auge behalten[1].
  [0] https://github.com/antirez/ds4/issues/108
  [1] https://github.com/ggml-org/llama.cpp/issues/22319

  • AMD ROCm wird also nur im rocm-Branch unterstützt; ich frage mich, ob das schon jemand tatsächlich ausprobiert hat.
    In diesem Thread geht es viel um MacBook Pro, aber ich würde es gern auf einem AMD Halo Strix mit 128 GB Unified Memory testen.
  • Es wäre schon gut, wenn man sich überhaupt noch einen Mac mit so viel RAM kaufen könnte.

• Ich habe die Q4-Version über das lokale Netzwerk auf einem Mac Studio ausprobiert, und sie war gut.
  Zusammen mit mehreren Agenten eingesetzt, hatte ich sogar zum ersten Mal das Erlebnis, zu vergessen, dass es sich um ein lokales Modell handelt, weil es die Aufgaben so gut erledigt hat.
  Ich frage mich allerdings, ob wirklich noch ein weiterer Agent nötig ist.
  Ich habe es mit Pi betrieben, aber der Systemprompt von Claude Code ist angesichts der Prefill-Geschwindigkeit zu schwergewichtig, auch wenn die Ergebnisse hervorragend waren.
  OpenCode ist ebenfalls eine gute Option.
  Ich frage mich, ob es wirklich einen zusätzlichen Nutzen bringt, noch ein ähnliches Tool speziell für Deepseek 4 zu bauen.

  • Funktional braucht man nicht noch einen weiteren Agenten.
    Wenn man aber der Idee hinter DS4 folgt, zwingt man API-Agenten dazu, merkwürdige Dinge zu tun, etwa DSML-Syntax in JSON zu übersetzen, und dadurch entstehen Probleme bei der Normalisierung oder beim KV-Cache-Checkpointing.
    Unabhängig davon, ob das in der Praxis wirklich so ist, ergibt es Sinn, eine normalere Alternative anzubieten.
    Ich verstehe auch nicht ganz, warum in diesem Bereich nicht mehr in C/Go/Rust geschrieben wird, um mehr Kontrolle, Geschwindigkeit und weniger Abhängigkeiten zu bekommen.
    Auch auf der TUI-Seite kann man sich noch viel vorstellen.
    Die meisten Projekte leiden darunter, dass einfach kopiert wird, was man schon gesehen hat; ich habe zum Beispiel in 20 Minuten so etwas gebaut: https://x.com/antirez/status/2055190821373116619
    Code ist jetzt billig, und der Wert von Ideen ist gestiegen.
    Ich bin mir nicht sicher, ob man heute noch in Kategorien wie „Brauchen wir wirklich noch ein weiteres XYZ?“ denken sollte.
    Schon allein, um neue Ideen zu erkunden, kann es sich lohnen.
    Ich persönlich arbeite ungern mit dem JavaScript-/Node-Ökosystem für Code, daher führen angenehmere Werkzeuge beim Erkunden neuer TUI- oder Agent-Workflows zu anderen Ergebnissen und Iterationen.
  • DS4 ist eine Inferenz-Engine, kein Execution-Harness.
    Es stellt einen Inferenz-API-Server bereit, und daran hängt man dann den Coding-Harness.

• Im Moment kann ich es wegen meiner Hardware nicht nutzen, aber es gefällt mir. Ich habe nur ein M2 Max mit 96 GB.
  Ich verstehe auch, warum es für normale Nutzer oder Mainstream-Rechner unbrauchbar oder schlechter wirken könnte.
  Es erinnert mich daran, wie frühe Heimcomputer als Spielzeug angesehen wurden, bevor sie zu Personal Computern wurden.
  Die halbwegs brauchbare Kombination auf meiner aktuellen Hardware ist pi agent + llama.cpp + nemotron cascade-2.
  Damit sind bis zu 1 Mio. Kontext möglich, und durch die Hybridarchitektur bricht es bei den für Code-Agenten typischen Kontexttiefen von 10K, 50K oder 100K nicht wie 1/N² zusammen.
  Vor ein paar Tagen konnte ich im Flugzeug sogar ohne Internet pi agent mit llama.cpp-Serving betreiben, und mit etwa 40–30 Token/s war es gerade noch benutzbar, was ich ziemlich lustig fand.
  Normalerweise liegt die API-Geschwindigkeit meines Wissens eher beim Doppelten, also etwa 60–80 Token/s.
  Während der Inferenz zeigten die Sensoren 60 W Verbrauch, und der Akku würde vermutlich kaum länger als drei Stunden halten.
  Das Modell ist nur 30B groß, daher gibt es reichlich Platz für KV-Cache und andere Programme, und selbst mit großzügiger 8-Bit-Quantisierung ist es noch okay.
  Ein MoE A3B, bei dem jeweils nur 3B Parameter aktiv sind, scheint das Maximum zu sein, das ein alterndes M2 Max noch bewältigen kann.

  • Ich weiß nicht, ob es sich unter macOS anders verhält, aber mit CUDA und DeepSeek-V4-Flash-IQ2XXS-w2Q2K-AProjQ8-SExpQ8-OutQ8-chat-v2-imatrix.gguf passt es inklusive Kontext in 96 GB VRAM.
    Wenn macOS also nicht standardmäßig ein paar GB RAM/VRAM für OS oder Display reserviert, müsste es theoretisch möglich sein.
  • Es sollte auch auf diesem Computer funktionieren.
    Dazu gibt es einige positive Berichte.
  • Mit 96 GB sollte es insbesondere bei begrenztem Kontext laufen.
    Das M2 Max ist dabei allerdings etwas langsam.

• Es fühlt sich erstaunlich nah an Claude an.
  Natürlich ist es viel langsamer, aber ich bin mir nicht sicher, ob es wirklich so viel dümmer ist.
  Interessanterweise scheint die imatrix-Quantisierung besser zu sein als jede Quantisierung, die das zdr-Inferenz-Backend von OpenRouter verwendet.
  Gestern hat es sogar selbst erkannt, dass sein eigener Serverprozess es selbst ist, ohne dass ich es ihm sagen musste; so etwas habe ich bei einem lokalen Modell noch nie erlebt.

  • Ich frage mich, welchen Prompt du verwendet hast.
  • Das ist zwar klar anekdotisch getestet, aber DeepseekV4 Pro war beim Coden besser als Sonnet.
    Es ist viel langsamer, aber mit der aktuellen Promo auch um ein Mehrfaches günstiger.

• Es scheint nicht erklärt zu werden, warum man eine neue Inferenz-Engine pro Modell baut.
  Man könnte einfach llama.cpp verwenden, und viele Leute arbeiten bereits an Integrationen in llama.cpp.
  Es wird viel Aufwand in ein einzelnes Modell gesteckt, das schnell veraltet sein könnte, sobald ein besseres anderes Modell erscheint.
  In manchen Diskussionen erstellen Leute PRs sowohl für den llama.cpp-Branch als auch für ds4, sodass die knappen Entwicklerressourcen, die in dieses Modell investiert werden, zersplittert werden.

  • Es ist viel einfacher, in einer fokussierten C-Codebasis zu arbeiten, die man selbst besitzt, als in einer reifen, sperrigen C++-Codebasis, die einem nicht gehört.
    Das ist aber okay. Die Leute werden diese Arbeit nach llama.cpp portieren, und alle profitieren.
    Auch die Nutzererfahrung von ds4 ist hervorragend. Geprüfte Modelle und gute Quantisierungen bekommt man sehr leicht.
    Bei llama.cpp gibt es so viele Stellschrauben, dass es sich viel mehr nach Hacking im Niemandsland anfühlt.
  • Die Annahme scheint zu sein: „Code ist billig, Zusammenarbeit, etwa Upstreaming, ist teuer.“
    Ob das stimmt, werden wir in ein paar Jahren sehen.
  • Wie der Autor mehrfach gesagt hat, wollen die Maintainer von llama.cpp nicht, dass massenhaft von AI geschriebener, ungeprüfter Code einfließt.
    Wenn jemand Support für dieses Projekt upstreamen will, kann er das gern tun, und der Code steht unter der MIT-Lizenz.
  • Ab einem gewissen Punkt führt das Maß an Abstraktion und Verallgemeinerung, das große flexible Projekte wie llama.cpp oder Linux brauchen, zu einer enormen Zahl an Dateien.
    Neuere und kleinere Projekte können sich schneller bewegen.

• DeepSeekV4 Pro ist wirklich ein sehr fähiges Modell, und gerade wegen seines Preispunkts sehr gut.
  Ich bastle in C an einer 2.5D-Engine auf Basis von raylib und nutze DeepSeek als Assistenten.
  In OpenaCode sieht man den Denkprozess transparent protokolliert, und es ist erstaunlich, diesen Gedankengang zu beobachten.
  Das ist beim Lesen zwar sehr lang, aber nichts davon war nutzlos oder bedeutungslos.
  DeepSeek weist in seinem Denkprozess immer auf Annahmen hin, die ich nicht bedacht habe oder bei denen ich falschlag, und richtet die finale Ausgabe dann trotzdem an meiner fehlerhaften Anfrage aus.
  Dann antworte ich: „Moment, du hast das also auch so gesehen, und das stimmt, ich lag falsch, also berücksichtigen wir auch diesen Aspekt.“

• Es wäre schön, so etwas nicht nur auf meinem Rechner, sondern auch in Kundenprojekten oder auf Cloud-GPUs einsetzen zu können.
  Die Kernidee, starke Modelle effizient und ohne Cluster zu nutzen, gilt weiterhin auch für viele Business-Anwendungsfälle.
  Ich hoffe, dass dieser Ansatz auch im Batch-Modus funktioniert.
  Momentan wirkt auf H200 für agentische Tool-Calls bei intelligenten Sprachagenten Qwen 3.6 27B in 4 Bit mit MTP wie eine der besten Optionen.
  Wenn DS4 Flash ein 2-Bit-80B mit 13B aktiv und MTP-Struktur ist, frage ich mich, ob es schneller und intelligenter sein könnte und zugleich mehr gleichzeitige Sequenzen zulässt.
  Diese spezielle 2-Bit-Quantisierung scheint ziemlich bedeutend zu sein.

• Wenn man sieht, wie bei lokalen Modellen Leistung und Geschwindigkeit – oder was auch immer man hier „Intelligenz“ nennen will – so schnell steigen, fragt man sich, wo die Wachstumsrate und die Obergrenze in diesem Bereich liegen.
  Wird ein solches Niveau an Intelligenz und Leistung in ein paar Jahren zum Beispiel auch mit 16 GB RAM möglich sein?
  Kann man hier eine neue Art von Mooreschem Gesetz definieren?

  • Solche Modelle inklusive ihres „Large-Model-Gefühls“ in 16 GB zu pressen, ist ehrlich gesagt heute nicht oder nicht realistisch möglich.
    Dafür bräuchte es Architekturinnovationen, Hardwareinnovationen oder einen Durchbruch bei Quantisierungstechniken.
    Das Problem ist, dass selbst nicht aktivierte Parameter im Speicher liegen müssen.
    Selbst bei Mixture-of-Experts-Modellen ist das Austauschen von Parametern in den und aus dem RAM viel zu langsam.
  • Leute an der Spitze dieses Feldes scheinen zu glauben, dass man parallele Modelle braucht, die unterschiedliche Probleme lösen.
    Krähen zeigen im Vergleich zum Menschen mit sehr kleinen Gehirnen bereits ein gewisses Maß an Intelligenz, und zwischen den Problemlösefähigkeiten des dümmsten Menschen und der intelligentesten Krähe gibt es Überschneidungen.
    Daher ist die Frage, was genau das ausmacht.
    Yann LeCun scheint zu glauben, dass es das ist, was wir heute Weltmodell nennen.
    Ein Weltmodell sagt nicht strukturierte Daten wie Sprache voraus, sondern Handlungen.
    Wenn man vorhersagen kann, wie eine Welt funktioniert, könnte man theoretisch Ursache und Wirkung ableiten.
    Wenn sich Ursache-Wirkung-Schlussfolgerungen mit Sprache verbinden lassen, könnte etwas entstehen, das echter Intelligenz nahekommt.
    Es scheint in diese Richtung zu gehen.
    Sobald Prototypen solcher Systeme auftauchen, werden viele Fragen dazu entstehen, wie viele Daten tatsächlich nötig sind.
    Wir haben bereits gesehen, dass selbst auf 1 Bit quantisierte LLMs noch ein ziemlich starkes Sprachverständnis zeigen.
    Ich halte es nicht für unvernünftig, dass wir in den nächsten Jahren hochintelligente AI-Systeme mit vergleichsweise wenig Speicher sehen werden.