Das Ausführen lokaler Modelle ist jetzt gut geworden

 (vickiboykis.com)
3 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Selbst auf einem M2 Mac von 2022 sind lokale LLMs inzwischen leistungsfähig genug, um praktisch für Entwicklungsfragen, Code-Arbeit und das Prüfen von Dokumentation eingesetzt zu werden
  • Frühe lokale Modelle waren langsam, schwer zu nutzen und bei Programmieraufgaben ungenau, aber seit GPT-OSS muss deutlich seltener mit API-Modellen gegengeprüft werden
  • Mit den neuesten Releases der Gemma-4-Familie läuft ein lokaler Agentic-Coding-Loop mit etwa 75 % Genauigkeit und Geschwindigkeit im Vergleich zu Frontier-Modellen
  • Die Kombination aus Pi und LM Studio führt Agent-Workflows über lokale Inferenz-Endpunkte, Modellartefakte und eine per Docker isolierte Konfiguration aus
  • Lokale Modelle haben weiter Grenzen bei Inferenzlatenz, kleinen Kontextfenstern und Hardwarebeschränkungen, dafür lassen sich Token-Verarbeitung, System-Prompts, Quantisierung und Harness direkt beobachten und verändern

Wo lokale Modelle heute stehen

  • Frühe lokale Modelle waren bei den meisten Programmieraufgaben langsam, schwer zu verwenden und ungenau
  • Die Einschätzung, dass lokale Modelle deutlich hinterherhinken, war aus Sicht der persönlichen Nutzung bis vor der Veröffentlichung von GPT-OSS im Großen und Ganzen zutreffend
  • Der persönliche Maßstab für ein „ausreichend gutes Modell“ war, ob noch einmal mit einem API-Modell gegengeprüft werden musste, und GPT-OSS war das erste Modell, das diese Prüfungen stark reduzierte
  • Bis vor Kurzem wurden lokale Modelle vor allem wie ein schnelles, personalisiertes Google für Entwicklungsfragen ohne Aktualitätsbedarf genutzt
  • Seit den neuesten Releases der Gemma-4-Familie läuft ein Agentic-Coding-Loop lokal mit etwa 75 % der Genauigkeit und Geschwindigkeit von Frontier-Modellen {p:75}

Verwendete Modelle und Laufzeitumgebung

Konkrete Beispiele für lokale Agent-Arbeit

  • Ein Python-Skript im Notebook-Stil wurde in ein Repository mit 5 bis 6 Modulen refaktoriert
  • Diese Module wurden so gelintet, dass sie generische Type Hints gemäß PEP 585 verwenden
  • Auch für das Korrekturlesen von Blogposts, das Schreiben von Unit-Tests und den initialen Aufbau eines Repositories für ein Two-Tower-Empfehlungsmodell wurde die lokale Konfiguration verwendet
  • Das vom Agenten aus dem Nichts erzeugte Repository für das Two-Tower-Modell war zwar grundlegend, lag aber über dem, was im vergangenen Jahr noch für möglich gehalten worden wäre
  • Alle Agent-Workflows liefen in Docker-Containern mit eingeschränkten Ausführungsrechten

Ressourcennutzung und aktuelle kleine Modelle

  • Die ausgeführten Aufgaben waren weniger bahnbrechend als vielmehr mit personalisiertem Google oder Dokumentenabfrage vergleichbar
  • Während der Arbeit stiegen GPU- und RAM-Auslastung stark an, und der K-V-Cache wuchs bis auf 64 GB RAM
  • Selbst einfache Aufgaben dieser Art mit lokalen Modellen wären noch vor sechs Monaten nicht möglich gewesen
  • Gemma-4-12b-qat war schon direkt nach dem Release in Bezug auf das Verhältnis von Größe zu Leistung beeindruckend
  • Die Modellarchitektur wirft die Frage auf, welche architektonischen Kompromisse bei Leistungs- und Preisbeschränkungen nötig sind

Konfiguration zum Ausführen lokaler Agent-Modelle

  • Um einen lokalen Agent-Flow auszuführen, werden eine lokale Modell-Inferenz-Engine, ein Agent-Harness und lokale Modellartefakte benötigt
  • Das Harness muss so konfiguriert werden, dass es auf einen lokalen Inferenz-Endpunkt zeigt, und die heruntergeladenen Modellartefakte müssen über die Inferenz-Engine bereitgestellt werden
  • In der aktuellen lokalen Konfiguration dient Pi als Agent-Harness und LM Studio als Inferenzserver
  • Dabei wurde dem Artikel Gemma 4 Agent Coding mit Pi und LM Studio einrichten gefolgt, allerdings mit einigen geänderten Einstellungen
    • Statt Gemma 26B A4B aus dem Artikel wurde das neuere, kleinere und schnellere gemma-4-12b-qat verwendet, ohne große Einbußen bei der Genauigkeit
    • Aus Sicherheitsgründen wurden alle Pi-Sitzungen in Docker-Containern ausgeführt und nur mit bash-Rechten versehen, sodass Python-Code-Ausführung und Web-Browsing blockiert waren
    • Für ein separates Image für Forschungsaufgaben ist geplant, curl zu erlauben
    • Da Pi innerhalb von Docker läuft, wurde models.json von Pi angepasst, damit Pi mit dem Modell kommunizieren kann

Docker-basierte Isolierung

  • In der Pi-Konfiguration wurde baseUrl auf http://host.docker.internal:1234/v1 gesetzt und als API openai-completions konfiguriert
  • Die Docker-Compose-Konfiguration mountet models.json, das Arbeitsverzeichnis, die Pi-Konfiguration und das Sitzungsverzeichnis in den Container
  • Das Startskript verbindet das aktuelle Arbeitsverzeichnis mit dem Workspace des Containers und fügt bei Bedarf eine zusätzliche, sicherere Sandbox-Compose-Datei hinzu
  • Pi wird im aktiven Repository ausgeführt und startet Docker, kann dadurch aber Dateien oder Verzeichnisse auf dem physischen Datenträger nicht direkt löschen
  • Benutzerdefinierte Modell-json-Konfigurationen konnten in den Container übergeben werden und funktionierten in der Experimentierumgebung vergleichsweise gut

Verbleibende Grenzen

  • Lokale Modelle können bei der Inferenz noch immer langsam sein, die Kontextfenster sind klein, und der nutzbare Kontext ist durch die vorhandene Hardware begrenzt
  • Das Ökosystem ist dank Tools wie LM Studio und dem Use This Model Button von Hugging Face deutlich einfacher geworden
  • Frühe Releases leiden unter Problemen wie nicht passenden Prompt-Templates, doch solche Probleme werden normalerweise sehr schnell gepatcht
  • Es ist noch schwer, mit Sicherheit zu sagen, dass sie bereits direkt für die Entwicklung von Produktionssoftware bereit sind

Vorteile lokaler Modelle und Experimentiermöglichkeiten

  • Bei lokalen Modellen lässt sich fast alles einsehen, einschließlich des Token-Inferenzprozesses in Echtzeit
  • Der Ein- und Ausgabefluss von Tokens kann direkt überprüft werden
  • Es lässt sich beobachten, wie sich Änderungen am lokalen Kontextfenster positiv oder negativ auf die Leistung auswirken
  • Man kann sich damit beschäftigen, wie Tokens auf der GPU verarbeitet werden, und auch System-Prompts sowie Quantisierungseinstellungen verändern
  • Modelle lassen sich gegeneinander antreten, und auch Harness-seitige Einstellungen können verändert und beobachtet werden, wodurch die Experimentiermöglichkeiten weiter wachsen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Hacker-News-Kommentare

  • Ich weiß nicht, ob es wirklich besser geworden ist. Ich nutze viele lokale Modelle, aber lokale Ausführung ist immer noch ziemlich schmerzhaft
    Dichte Modelle wie Qwen 27B und Gemma 31B sind ziemlich klug, aber langsam, und Mixture-of-Experts-(MoE)-Modelle wie Gemma 26B, Qwen 35B und North Mini Code 30B sind schnell, machen aber viele Fehler
    Um sie ordentlich zu betreiben, braucht man viel Speicher, und durch Quantisierung wird Tool-Calling schwächer. Die meisten lassen sie in 4-Bit-Quantisierung laufen und wundern sich dann, warum sie nicht besonders gut sind, aber im Grunde hat man das Modell damit lobotomiert. Ich empfehle Unsloth-Quantisierung; für MoE 6 Bit, für dichte Modelle 5 Bit
    Für schnelles Prefill braucht man Rechenleistung, für schnelles Decoding Bandbreite, und damit alles hineinpasst, braucht man außerdem viel Speicher. Dazu kommt, dass Laptops zu heißen und lauten Maschinen werden und dadurch beim Arbeiten unangenehm sind
    Also, ist es gut? Eher nicht. Es funktioniert
    Ergänzend: Ich glaube, dass Open Models die Zukunft sind, und ich trage weiter zum Ökosystem bei. Es wäre gut, wenn Leute mit solchen Modellen herumspielen und mit pi lernen, wie sie funktionieren, aber man sollte nicht erwarten, dass es sofort gut ist, nur weil man ein Modell herunterlädt. Um das zu ersetzen, was die meisten als „Coding Agent“ wollen, braucht es viel Tuning und Konfiguration

    • Meine Erfahrung ist fast identisch. Ich habe vor ein oder zwei Monaten auf einem relativ aktuellen High-End-Desktop (Radeon 6900 XT 16GB VRAM, Ryzen 9 7900X mit 12 Kernen, 64GB System-RAM) mit ollama empfohlene Modelle ausprobiert
      Modelle ohne Coding-Fokus blieben oft dabei hängen, keine echten Tool-Calls auszuführen, sondern nur zu sagen: „Ich würde jetzt so handeln“, und selbst wenn ich fragte, was ich konfigurieren müsse, um dieses Verhalten zu ändern, half das nicht. Qwen glaubte partout nicht, dass es in ollama lief, und beharrte darauf, auf der Alibaba-Cloud zu laufen und keinen Zugriff auf das lokale System zu haben
      Auch Coding-Modelle dachten nur knapp schneller als ich tippen konnte, und selbst wenn sie ihren Denkprozess zeigen konnten, war das nur eingeschränkt möglich
      Die beste „kostenlose“ Erfahrung, die ich bisher gefunden habe, ist OpenCode + Big Pickle. Es ist nicht besonders klug, daher ist das erste Ergebnis oft falsch, aber der Free-Tier ist großzügig genug, dass ich selbst bei häufiger Nutzung über jeweils mehrere Stunden im Monat nur etwa zweimal an ein Limit gestoßen bin. Wenn echtes lokales Ausführen das Ziel ist, passt das nicht, aber wenn das Ziel „die beste Erfahrung ohne Abo- oder Token-Kosten“ ist, war das bisher die am wenigsten schlechte Wahl
    • Ich denke, um lokale Modelle „gut“ zu betreiben, braucht man immer noch eine teure Hardware-Investition. Um solche Modelle mit einem angemessenen KV-Cache zu fahren, wird man auf aktueller Blackwell-Architektur eher 96GB VRAM haben wollen
      Der Versuch, das auf Geräten wie einem Mac mit Unified Memory, einem AMD-Prozessor mit AI Max oder etwas DGX-Spark-Ähnlichem zu betreiben, kommt eher einer selbst gewählten Leidensgeschichte gleich. Prefill ruiniert die Performance
      Mit passenden GPUs wird es deutlich besser, aber selbst dann bleibt es noch hinter Sonnet oder DeepSeek 4 Flash zurück und erst recht hinter Opus / DeepSeek Pro oder Mythos/Fable/GPT-5.5
      Wenn Budget, Stromversorgung und Kühlung ausreichen, kann man eine ziemlich gute Datenpipeline betreiben, aber für Code ist es in den meisten Fällen noch vernünftiger, einen API-Anbieter zu bezahlen
    • Man sollte solche Modelle vielleicht nicht auf thermisch stark eingeschränkten Laptops laufen lassen, und man sollte auch nicht erwarten, bei Inferenzgeschwindigkeit auf dem Niveau großer Cloud-Plattformen eine Qualität nahe am State of the Art zu bekommen
      Trotzdem ist es einen Versuch wert, wenn man sich nicht zu stark auf zentralisierte Dienste verlassen will
    • Gemma 4 ist besonders gut für Pipeline-/Automatisierungsaufgaben
      Meiner Erfahrung nach übertrifft es bei Regelbefolgung oder Automatisierungsaufgaben die Qwen-Modelle, sogar 100B+, und die Bildinterpretation ist ebenfalls sehr gut und liegt laut Benchmarks über Opus
      Qwen neigt dazu, Anweisungen zu ignorieren, und wenn man das Format der Token-Generierung nicht explizit einschränkt, gibt es beständig ein falsches Format aus
      Auf DGX Spark läuft Gemma 31B Q4 + MTP allerdings nur mit etwa 20 Token/s und Gemma 26B A4B mit etwa 60 Token/s, also immer noch ziemlich langsam. Auf High-End-Nvidia-Karten würde es viel schneller laufen und auch in den Speicher passen
      Wer mit lokalen Modellen anfängt, sollte sich meiner Meinung nach eher auf Speicherbandbreite als auf RAM konzentrieren. Modelle unter 100B reichen inzwischen für Automatisierung aus und sind sehr nützlich
      Ich stimme zu, dass es für Coding/kreative Arbeit noch keinen starken Grund gibt, lokale Modelle zu nutzen. Aber für Aufgaben wie Aktienlisten durchgehen, News per Hochpass filtern, Logs interpretieren oder Screenshots auswerten reichen lokale Modelle schon jetzt aus
    • Ich frage mich, ob es nicht besser wäre, irgendwo eine Maschine für die Modelle stehen zu haben und sie mit ein paar Leuten zu teilen
      Ein M6 Mac Studio mit etwa 256GB RAM, auf den mehrere Leute für ein gemeinsam ausgewähltes Modell zugreifen, könnte man vielleicht rechtfertigen. Für diesen Zweck wirken Laptops zu heiß und zu träge

  • Ich habe Qwen3.6-27B einige Wochen lang zufrieden genutzt, bin aber gerade von meiner Hardware getrennt und muss daher derzeit Claude Sonnet 4.6 verwenden, und es fühlt sich wie ein gewaltiges Downgrade an.
    Ich verstehe nicht, wie das möglich ist. Es hat viel zu viele ungefragte starke Meinungen, ist viel zu wortreich und wirkt insgesamt dümmer.
    Klar, es ist ein viel größeres Modell und hat daher vermutlich mehr Wissen enkodiert, aber das hilft nicht, wenn man sich nicht gern mit ihm unterhält. Außerdem kostet die Unterhaltung damit tatsächlich Geld.
    Ich frage mich, warum ich es so sehr nicht mag. Vielleicht, weil es sich nicht als Werkzeug sieht, sondern fast als gleichrangiges Gegenüber. Es benimmt sich, als hätten seine Meinungen Gewicht.
    Qwen kann sich auch wie ein übereifriger Praktikant verhalten, aber wenn man ihm sagt, dass es Unsinn redet, lässt es sein Ego fallen. Bei Claude war das meiner Erfahrung nach nicht so.
    Insgesamt stimme ich dem Titel voll zu.

    • Ich habe nie auch nur einen Cent für Cloud-Inferenz ausgegeben, daher kann ich keinen direkten Vergleich ziehen, aber ich kann mit Sicherheit sagen, dass Qwen3.6-27B ein sehr kompetentes lokales Modell für Coding-Aufgaben ist.
      Ich habe es in den letzten anderthalb Monaten fast täglich auf einem M2 Ultra oder einer RTX-5090-Maschine benutzt. Ich verwende es für kleine, alltägliche Aufgaben bei ggml-org [0]; nichts Spektakuläres, aber als Werkzeug für einen Maintainer definitiv hilfreich.
      Wenn ich nicht so viel Zeit für PR-Reviews aufwenden würde, hätte ich es wahrscheinlich noch deutlich mehr genutzt. Im Moment verwende ich ein sehr leichtes Harness, im Grunde nur den völlig abgespeckten pi-Agenten (pi -nc --offline) und einen kurzen System-Prompt [1], um ihn an meinen Stil anzupassen.
      Die Generierungsgeschwindigkeit liegt bei etwa 100–150 Tokens/s auf der RTX 5090 und etwa 40 Tokens/s auf dem Mac. Ich bevorzuge klar die RTX-Maschine, weil sie viel schneller ist, aber ich lasse es auch oft auf dem Mac laufen, um lokale Setups zu testen und mehr Praxiserfahrung zu sammeln.
      [0] - https://github.com/search?q=%22Assisted-by%22+user%3Aggml-or...
      [1] - https://github.com/ggml-org/llama.cpp/blob/master/.pi/gg/SYS...
    • Ich nutze Qwen3.6-27B täglich, auch als Hauptwerkzeug bei der Arbeit, und praktisch durchgehend seit kurz nach dem Release. Für mich ist es das einzige kleine lokale Modell, das wirklich brauchbar ist, wenn man es ausführen kann.
      Für Dinge wie „füge große Funktion X hinzu“ ist es vielleicht schlechter als Opus, aber genau so etwas will ich gar nicht vom Modell. Ich will denken, und das Modell soll tippen. Für diesen Zweck ist Qwen 3.6 27B völlig ausreichend. In meiner Erfahrung waren 35A3B und die Gemma-Familie ein deutliches Downgrade.
      Außerdem gibt es keine Sorgen wegen Rate Limits, Quoten oder Warteschlangen zu Stoßzeiten. Man kann immer den vollständigen Denkprozess sehen, muss sich keine Gedanken machen, wohin die Daten geschickt werden, und es wird einem nicht heimlich verschlechtert.
      Ich nutze auf 2×3090 llama.cpp mit Q6_K_XL + MTP und komme auf 500–1000 Tokens/s beim Prefill, 60 Tokens/s bei der Ausgabe und ein Kontextfenster von 220.000 Tokens. Ab etwa 160.000 Tokens wird es langsam etwas dümmer, und ich nutze keine KV-Quantisierung.
    • Dieses „es ist viel zu wortreich“ ist wirklich nervig. Es soll bitte einfach die Klappe halten und knapp antworten.
      Vielleicht ist das ein Nebenprodukt der Denkfunktion, aber ich wünschte, es würde seinen Denkprozess viel knapper zusammenfassen. Es gibt Situationen, in denen ein Antwortsatz völlig reicht, und trotzdem schreiben moderne Topmodelle mindestens fünf Absätze und versuchen, drei bis fünf neue Richtungen vorzuschlagen.
      Selbst wenn man ausdrücklich darum bittet, nur einen Schritt auf einmal zu machen, immer nur eine Option zu nennen und nicht proaktiv nächste Richtungen vorzuschlagen, ist das per Prompt wirklich schwer zuverlässig zu steuern.
      Wobei ich gerade selbst genau das gemacht habe, worüber ich mich beschwert habe.
    • Ich würde nicht allein auf Basis meiner Sonnet-Erfahrung verallgemeinern. Die Flaggschiff-Modelle der Claude-Familie, also das Äquivalent zu Opus, sind deutlich besser.
    • Es ist lustig, dass auch Coding-Agenten eine Persönlichkeit haben. Sogar so eine Persönlichkeit wie „dieser Kollege“, den man lieber vermeiden möchte, obwohl man weiß, dass er seine Arbeit ziemlich gut macht.

  • Programmierer sind daran gewöhnt, kein Geld für Werkzeuge auszugeben. Schon ein normales Notebook (SSD, Multicore, 16 GB RAM) ist für C/C++/Rust und sogar für Python-Entwicklung unglaublich leistungsfähig.
    Und plötzlich reicht das nicht mehr aus, und man ist wieder in einer Situation, in der man fremde Computer benutzt und sich täglich Werkzeuge leiht. Noch schlimmer ist, dass man jeden Tag ein anderes Modell verwendet und dass man an manchen Tagen vielleicht nicht einmal das gute Werkzeug leihen kann, weil irgendeine mafiöse Macht den Hersteller unter Druck setzt.
    Die meisten anderen Berufe müssen erheblich in Werkzeuge investieren. Wenn man gute Werkzeuge will, braucht man etwa 64 GB GPU-Speicher (z. B. 2×5090) und rund 96 GB RAM. Wenn man einem erfahrenen Ingenieur 200.000 Dollar zahlt, wirken 50.000 Dollar für Werkzeuge alle zwei Jahre eigentlich ziemlich vernünftig.

  • Das ist ein Trend, über den sich Unternehmen wie Anthropic Sorgen machen sollten. Je einfacher die Ausführung lokaler Modelle wird, desto niedriger wird die Preisobergrenze, die sie durchsetzen können.
    Es wird zwar nicht so sein, dass niemand mehr $$$$$ pro Monat zahlen will, aber viele werden die Monatsgebühr mit 12 oder 24 multiplizieren und sich fragen: „Kann ich für weniger Geld ein lokales Modell-Setup aufbauen und die Kosten in 1–2 Jahren wieder hereinholen?“
    Wenn sich ein erheblicher Teil der Kunden für Kauf statt Miete entscheidet, könnten Unternehmen mit mietzentriertem Geschäftsmodell plötzlich unter Kundenmangel leiden.

    • In den letzten 20 Jahren ist im Cloud Computing genau das Gegenteil passiert. Bei AI-Modellen wird sich das nicht ändern.
      Das ist inzwischen fast in das amerikanische Geschäftsmodell eingebrannt: Alles wird ausgelagert. Niemand will selbst den Serverraum betreiben, und selbst wenn es 2–3x mehr kostet, lagern die Leute lieber auch den Ärger und die Verantwortung aus.
      Bei AI wird es genauso sein. Ob man diese Prämie nun an Anthropic oder an AWS zahlt, ist letztlich dasselbe.
      Ich arbeite in einem eher kleinen Unternehmen, und wir hatten kürzlich einen Ausfall bei lokaler Infrastruktur. Obwohl unsere gesamte interne Downtime der letzten 5 Jahre deutlich geringer war als bei einem einzigen großen AWS-Ausfall in jüngster Zeit, macht der CEO jetzt Druck, dass das Hosting eigener Infrastruktur nicht vertrauenswürdig sei.
      Alle wollen lästige Arbeit und Verantwortung loswerden.
    • Ich dachte, das könnte ähnlich sein wie der Unterschied zwischen dafür zu zahlen, Netflix zu nutzen, oder per Torrent herunterzuladen und Plex zu betreiben.
      Normale Mainstream-Nutzer zahlen wahrscheinlich eher für etwas, das schon eingerichtet ist und sofort funktioniert. Technisch versiertere oder entschlossenere Leute werden es selbst machen, aber ich frage mich, wie das Verhältnis zwischen diesen beiden Gruppen ausfallen wird.
    • Ich frage mich, wann Unternehmen mit hohem Coding-Anteil anfangen werden, selbst On-Premise-AI-Cluster zu betreiben.
      Ich weiß nicht, ob es die Idee schon gab, so etwas wie eine 4-GPU-Maschine zu verkaufen, die ein Engineering-Team irgendwo in einen Schrank stellt und darauf die gewünschten Modelle laufen lässt.
      Das wäre nicht für alle attraktiv, aber nachdem es Vertrauensprobleme damit gibt, dass Hyperscaler die Daten der Leute absaugen und zum Modelltraining verwenden, werden manche wohl Wert auf Maschinen und Modelle legen, die man transparent kontrollieren und bei Bedarf sogar selbst vom Strom trennen kann.
    • Solche lokalen Modelle können zwar einen Teil dessen leisten, was nicht ganz State-of-the-Art-Modelle tun, aber für mich hat das wenig Wert.
      Schon mit Sonnet 4.6 kann man im 20-Dollar-Monatsabo fast den ganzen Tag arbeiten. Und Sonnet ist immer noch deutlich leistungsfähiger als Modelle, die man auf einem M2 Mac selbst hosten kann.
      Vielleicht würde ich anders denken, wenn alle auf tokenbasierte Abrechnung umsteigen würden, aber auf Abo-Basis geht die Rechnung finanziell für mich nicht auf.
      Es macht Spaß. Aber wirtschaftlich sinnvoll ist es nicht.
    • Sie arbeiten mit Hochdruck daran, dass lokal gar nichts laufen kann.
      OpenAI kauft den gesamten RAM am Spotmarkt auf, wodurch die RAM-/VRAM-Preise auf das Sechsfache steigen und GPUs sowie brauchbare Computer für die meisten unerreichbar werden.
      Einige Wohlhabende werden vielleicht einen 512GB Mac Studio oder eine RTX Pro 6000 für 13.000 Dollar kaufen und darauf recht brauchbare lokale Modelle laufen lassen können, aber die meisten werden APIs nutzen müssen.
      Irgendwann könnte Nvidia sagen: „Wir verkaufen von der 6000 ohnehin nicht so viele, und mit reinen Datacenter-GPUs machen wir den vierfachen Gewinn, also streichen wir sie einfach.“ Dann wäre sie praktisch nicht mehr zu bekommen, und für Privatleute könnte es unmöglich werden, lokal brauchbare Modelle zu betreiben, die dem neuesten Stand nur etwa ein Jahr hinterherhinken.

  • Ich würde gern den Code sehen, der damit entstanden ist. Ich möchte lokale Modelle verwenden und habe auch die Hardware, aber als Ersatz für State-of-the-Art-Modelle wie GPT 5.5 xhigh oder Opus sind sie nach meiner Erfahrung noch nicht bereit.
    Wegen Qualitätsproblemen und Reibungsverlusten wird der Arbeitsablauf zu langsam, und manchmal verhauen sie sogar noch die Syntax für Tool-Calls.
    Für kleinere, klar definierte Abläufe oder für Edits wie „ändere genau diesen Teil auf genau diese Weise“ scheinen sie aber auszureichen. Ich warte darauf, dass sie reif genug werden, um den aktuellen Stand der Technik zu ersetzen, und dann wäre für mich der Zeitpunkt zum Umstieg gekommen.
    Wenn wir schon über lokale Modelle sprechen, sollte man DiffusionGemma und Diffusionsmodelle generell für den lokalen Einsatz nicht unterschätzen. Das Problem bei lokalem Einsatz ist meist, dass LLMs die Hardware nicht effizient ausnutzen, solange sie Requests nicht bündeln und mehrere gleichzeitig ausführen — und dafür müsste man den gesamten Ansatz ändern. Diffusionsmodelle sind bei einem einzelnen Prompt dagegen deutlich schneller, und der Unterschied ist nicht klein.
    Heute habe ich zufällig den Support für diffusiongemma-26B-A4B-it von Transformers nach Candle portiert und noch ein paar Optimierungen ergänzt, sodass die Inferenz in Candle jetzt mit ungefähr 450 Tokens/s (etwa 19 Iterationen/s) förmlich fliegt. In der HF-Transformers-Bibliothek waren es ungefähr 180 Tokens/s (etwa 11 Iterationen/s). Selbst mit vLLM habe ich bei einem ähnlich großen LLM mit einem einzelnen Prompt wohl nie mehr als 250 Tokens/s erreicht, also ist das für ein lokales Modell ziemlich interessant.

    • Diffusionsmodelle sind ab einer niedrigen bis mittleren Größe aufwärts schwer sauber zu trainieren und liefern bei gleicher Größe eine niedrigere Qualität als typische Token-für-Token-generierende Modelle.

  • Für 2600 Dollar bekommt man zwei AMD-9700-GPUs mit je 32GB RAM und etwa 285W Leistungsaufnahme pro Karte. Sowohl Kosten als auch Stromverbrauch liegen unter einer 5090.
    Mit einem VLLM-Build mit AITER-Patch kann man Qwen3.6 27B FP8 in echten Coding-Sessions mit Opencode oder PI über das gesamte Kontextfenster hinweg mit etwa 45–50 TPS laufen lassen.
    Ich hoffe wirklich, dass weiterhin mehr dichte Modelle in der 30B-Klasse erscheinen, aber schon mit Qwen3.6 kann man ziemlich viele Agenten-Tasks abdecken.
    Der ROCm-Stack ist allerdings nichts für Leute, die nicht bereit sind, selbst tief einzusteigen und Patches einzuspielen.

  • Ich frage mich, warum die Maßstäbe dafür, was „gutes“ Agent Coding ist, von Person zu Person so stark variieren.
    Einerseits ist es wirklich erstaunlich, dass wir von einer Intelligenz auf dem Niveau von „Spiele in Apple Music ‚Set a Timer‘ ab“ bis hin zu einem Stand gekommen sind, der den Turing-Test bestehen könnte. Praktisch betrachtet sind kleine Modelle aber noch weit davon entfernt, mehr als nur eine Tech-Demo zu sein, die man als „gut“ bezeichnen könnte.
    Für mich ist ein 7B-Modell nur ein verschwommenes Echo von Wikipedia. Ein 4-Bit-Gemma-Modell ist viel zu unbeholfen, um zuverlässig JSON für Tool-Calling zu erzeugen oder auch nur eine einzelne Codezeile zum Anwenden eines Patches zu kopieren.
    Qwen braucht so viele detaillierte Anweisungen und so viel Betreuung, damit es nicht in Endlosschleifen gerät oder den Kontext verliert, dass die Anweisungen, die ich geben muss, am Ende oft länger sind als der Code, der dabei herauskommt.
    Gibt es da irgendeinen magischen Prompt, den ich nicht kenne? Oder sind andere Leute einfach viel geduldiger oder haben deutlich niedrigere Erwartungen?

    • Ich hatte eine ähnliche Frage. Ich denke, die unterschiedlichen Erwartungen kommen daher, dass sich die Workloads unterscheiden.
      Bei kleinen Skripten, Glue Code und einfachen CRUD-Änderungen können kleine Modelle wie Qwen3.6-27B deutlich besser funktionieren als in größeren und unordentlicheren Codebasen.
    • Die Messlatte ist zwar niedrig und sinkt mit der Zeit weiter, aber das geschilderte Setup ist meiner Erfahrung nach immer noch zu niedrig.
      Wenn man Qwen/Gemma in der 27/35B-Klasse mit FP8 betreibt, sind sie besser als gemini-2.5, aber schlechter als gemini-3.1. DS4-flash FP8 lässt sich auf zwei DGX Spark betreiben, und die Lage verbessert sich ständig. DiffusionGemma hat zuletzt eine 4-fache Token-Generierungsgeschwindigkeit gezeigt.
      Kurz gesagt wirken die verwendeten Modelle zu klein oder zu stark quantisiert.

  • Ich betreibe gern zwei Modelle lokal: qwen3.6 27B 8-Bit (dense) und qwen3.6 35B 4-Bit (Mixture of Experts).
    Das 27B ist klüger und verlässlicher, aber langsamer. Das 35B ist schneller und immer noch sehr klug, liegt aber unter dem 27B und ist etwas weniger stabil. Der Grund ist die Mixture-of-Experts-(MoE-)Architektur: Es werden nur einige Parameter aktiviert, wodurch das Modell viel schneller wird.
    Das 27B lasse ich auf einem MacBook Pro M5 Max + 40 GPU-Kernen + 128 GB RAM laufen. Auf diesem Monster kann ich sowohl 27B als auch 35B gleichzeitig im Speicher halten und habe trotzdem noch Luft für andere Aufgaben. Aber weil es ein Laptop ist, kann ich lokale LLMs nicht ständig laufen lassen. Er wird zu heiß und zu laut.
    Noch interessanter ist es, das 35B-Modell auf einem MacMini M4 mit 64 GB RAM laufen zu lassen. Es ist schnell und erledigt viele Dinge. Zum Beispiel scannt, extrahiert und klassifiziert es E-Mails und überwacht dabei fortlaufend den Posteingang. Ich nutze es auch als persönlichen Hermes-Assistenten und frage Dinge wie „Wann ist der nächste Starship-Start?“, „Wer spielt heute bei der Weltmeisterschaft? Erzähl mir auch ein paar Trivia dazu.“
    Der nächste Plan ist eine RTX Pro 6000 Blackwell-Workstation im Keller. Ich möchte Qwen sehr schnell mit mehreren Threads/Prompts/Agenten gleichzeitig laufen lassen. Wenn das Budget es zulässt, hätte ich gern ein 2×RTX Pro 6000-Setup, um DeepSeek v4 flash zu betreiben und für Forschung zu nutzen.

    • Hast du für dieses „Hermes“ etwas wie einen Brave-Search-API-Key besorgt?
    • Ich hätte wirklich gern eine RTX 6000 Pro, aber wie soll man das rechtfertigen, wenn sie so viel kostet wie 10 Jahre Claude Max?

  • Im Alltag hoste ich Qwen3.6:27b, aber ich würde wirklich gern deepseekv4 flash hosten. Es ist ein so „gutes“ Modell in Bezug auf Größe/Geschwindigkeit/Preis.
    Ich frage mich, wann Unternehmen anfangen werden, statt für jeden Entwickler Abogebühren zu zahlen, Modelle für Alltagsaufgaben on-premises zu hosten. Sie sind gut genug und relativ günstig.

  • Zwar wurde nicht danach gefragt, aber ich glaube nicht, dass irgendjemand von uns für das Schreiben von Code oder fast irgendetwas anderem die neuesten Spitzenmodelle verwenden sollte.
    Stattdessen sollten wir offene Modelle für bestimmte Aufgaben entwickeln und lernen, mit knöchernen Fingern und einem Gehirn aus Fleisch zu programmieren, zu schreiben und zu zeichnen.
    Große Unternehmen und Forschungseinrichtungen könnten sie vielleicht nutzen, um Code, Mathematik und Ähnliches zu erzeugen, wenn Experten dabeisitzen, die prüfen, ob die Ergebnisse stimmen, aber selbst dann könnte es den Preis nicht wert sein. OpenAI hat zum Beispiel letztes Jahr netto 36 Milliarden Dollar Verlust gemacht, offene Modelle sind bereits ziemlich nah dran, und dem gesamten AI-Plan geht allmählich der Betrug aus, den man noch herauspressen könnte.
    Es gibt viele Dinge, die man auch mit sehr kleinen Modellen tun kann, und viele Aufgaben, die keine wahnsinnige Rechenleistung und keinen riesigen Speicher brauchen, aber es gibt viel zu wenige Leute, die diese Richtung ernsthaft erforschen.