Ask HN: Hat jemand im alltäglichen Coding Claude/GPT durch lokale Modelle ersetzt?

 (news.ycombinator.com)
6 Punkte von GN⁺ 9 시간 전 | 2 Kommentare | Auf WhatsApp teilen
  • Entwickler verlassen zunehmend Cloud-Modelle vollständig – aus Gründen des Datenschutzes und der kostenlosen Nutzung von LLMs – und können mit containerisierten, sandboxed Offline-Coding-Harnesses ohne externe Netzwerkaufrufe arbeiten
  • Die wichtigsten Modelle sind Qwen3.6 35B-A3B (schnell durch 3b aktive Parameter) und 27B-Dense-Modelle; es gibt einen Trade-off zwischen Coding-Genauigkeit und Token-Generierungsgeschwindigkeit
  • Die am häufigsten genannte Kombination ist Pi Harness und llama.cpp; dass Tool Calling auf lokalen Modellen erstmals konsistent funktioniert, hat die User Experience stark verbessert
  • Im Vergleich zu Claude Opus entsprechen lokale Modelle eher dem Unterschied zwischen einem „Junior, der Anleitung braucht, und einem Senior, der gemeinsam entwirft“; präzise Prompts und die Zerlegung von Aufgaben sind unerlässlich
  • Aktuell werden lokale Modelle als etwa 8–18 Monate hinter dem Frontier-Niveau eingeschätzt, bieten aber reale Vorteile: kostenlos, privat und ohne Sorgen um Quotas

Beispiele für den Wechsel zu lokalen Modellen und Hardware-Setups

  • Qwen3.6 35B-A3B wird auf einem Mac Studio mit 128 GB oder einem MacBook mit 36 GB RAM über Pi Harness betrieben; damit wurde eine komplette Neugestaltung der Homepage und des Blogs einer auf Django + Wagtail basierenden Website umgesetzt
    • Ohne Internetzugang weiß das Modell bei weniger verbreiteter Wagtail-Entwicklung nicht immer, wie es vorgehen soll
    • Für komplexe Aufgaben wird Qwen3.5 122b verwendet, ist mit 10b aktiven Parametern aber deutlich langsamer
  • In einer Strix Halo 128GB-Umgebung mit Unified Memory wird Pi in einem Container isoliert; erlaubt ist nur Zugriff auf das Arbeitsverzeichnis, ohne Credentials
    • Für Chat und Übersetzung wird Gemma 4 31B, für Audio Gemma 4 12B verwendet
    • Vorhanden sind viele Modelle wie Qwen 3.5 122B-A10B, Nemotron 3 Super 122B-A12B, Step 3.7 Flash und GPT-OSS 120B, aber für Coding ist 35B-A3B optimal
  • Auf einer vor fünf Jahren gebauten Dual-RTX3090-Maschine werden Qwen- und Gemma-Modelle mit UD-Q4_K_XL-Quantisierung mit ~150 tok/s betrieben; der volle 300k-Kontext passt in den VRAM
    • Damit wurde ein Claude-Abonnement für $100/Monat ersetzt; für private Nutzung hat kostenlos Vorrang
    • Umgesetzt wurden u. a. ein Android-TV-Launcher, ein k8s-Managementportal, Home-Assistant-Integrationen sowie Einkaufs- und Ernährungsverwaltung
  • Mit einer RTX 6000 wird die Kombination aus Qwen 3.6 27b + Open Code genutzt; sie deckt 90 % des Codings ab, bei sehr komplexen Aufgaben und UI-Polishing geht es aber zurück zu Codex
    • Bei 256k Kontext sinken Qualität und Geschwindigkeit oberhalb von 100k; ab 150k wird es deutlich problematisch
  • Auf einer RTX 5090 läuft Qwen 3.6 27b (Q6-Quantisierung) + llama.cpp; die GPU wird zur Geräuschreduktion von 600 W auf 450 W begrenzt
    • Eingesetzt wird das auch für Alltagsaufgaben wie Branch-Commits und PR-Erstellung, Stripe-CLI-Rechnungsabgleich und Lastanalyse in Elasticsearch

Modelltypen und Leistungsmerkmale

  • Die Unterscheidung MoE vs. Dense-Modelle beeinflusst die Coding-Qualität direkt
    • Qwen3.5-122B ist tatsächlich ein 122B-A10B-MoE, bei dem nur 10B aktiv sind, während bei Qwen3.6-27B alle 27B eines Dense-Modells immer aktiv sind
    • Über das geometrische Mittel aus aktiven und Gesamtparametern eines MoE lässt sich die Dense-äquivalente Qualität grob annähern, sqrt(35×10)≈18.7
    • MoE bietet bei gleicher Größe geringere Qualität, ist aber schneller; große MoEs lassen sich zudem durch Offloading in CPU-RAM betreiben
  • Der Quantisierungsgrad beeinflusst Loops und Genauigkeit
    • Q8-Quantisierung ist langsamer, reduziert aber Schleifen und spart dadurch insgesamt Zeit
    • Besonders empfindlich ist die Quantisierung des K-Teils des KV-Cache; mit F16 K + Q8 V gehen Schleifen stark zurück
  • Zusätzliche Dual-GPUs dienen nicht der Inferenzgeschwindigkeit, sondern der VRAM-Kapazität
    • Gemma-4 31B Dense und 26B MoE liefern bei Q4-Quantisierung ähnliche Qualität, das MoE ist aber etwa 3× schneller (150 tok/s vs. 46 tok/s)

Grenzen lokaler Modelle und Gegenstrategien

  • Präzise Prompts sind nötig

    • Lässt man Annahmen offen, wählt das Modell oft den kürzesten Weg, etwa CSS direkt in HTML, was architektonisch nicht optimal ist
    • Ohne explizite Architekturvorgaben produziert es schnelle, unsaubere Änderungen; ohne Anweisung entfernt es Debug-Ausgaben nicht
    • Claude Opus erschließt eher die Nutzerabsicht, kleinere Qwen-Modelle tun nur das explizit Geforderte; Designwissen muss ausdrücklich „aktiviert“ werden

  • Loops und Fehler bei Edit-Tools

    • Aufrufe von Edit-Tools schlagen oft fehl; statt einfach neu zu versuchen, verbraucht das Modell Thinking-Tokens und liest Dateien erneut ein
    • Direktes Retries behebt den Edit-Call oft, aber das Modell nimmt stattdessen ein grundlegenderes Problem an und verbraucht unnötig Tokens
    • Ein hashbasierter Edit-Ansatz, bei dem jede Codezeile per Hash referenziert wird, kann Edit-Fehler verringern, bricht aber nach Erschöpfung der Kontextqualität auf andere Weise zusammen
    • Regeln in AGENTS.md, die Edits statt Umschreiben erzwingen, bringen teilweise Verbesserungen

  • Management des Kontextfensters

    • Ein Fenster von 65.000 Tokens wird schon durch das Lesen der Struktur von Code-Dateien überschritten; nötig sind eher 200k+
    • Qwen3.6-35b verarbeitet 256k Kontext auf 16 GB VRAM in der Praxis stabil bei 128k
    • Qwen3.6-27B unterstützt 1 Million Tokens Kontext; auf DGX Spark benötigt das mit f16-KV-Cache rund 100 GB Speicher

Probleme mit Prompt-Caching und Erhalt von Reasoning

  • Bei hybriden Qwen-Modellen gibt es ein Problem damit, dass Prompt-Caching nicht korrekt funktioniert und pro Turn der gesamte Kontext neu verarbeitet wird
    • Die meisten lokalen Modelle sind nicht darauf trainiert, vollständiges Reasoning über mehrere Turns hinweg zu erhalten; nach langen Tool-Calling-Ketten muss daher oft ohne erhaltenes Reasoning neu verarbeitet werden
    • Qwen 3.6 ist auf den Erhalt von Reasoning trainiert; mit chat-template-kwargs = {"preserve_thinking": true} lässt sich die Wiederverwendung des Cache verbessern
  • Moderne LLMs nutzen nicht nur Full Attention, sondern auch lokale Attention wie Sliding Windows oder State-Space-Modelle à la Mamba-2
    • Full Attention hat O(n²)-Kosten und ist schwach bei Reasoning, dessen Werte sich über die Zeit verändern
    • Lokale Attention speichert Snapshots und beginnt bei der Cache-Neuberechnung beim letzten Snapshot; sind die Snapshots zu groß, entstehen jedoch Speichergrenzen
    • Qwen 3.5 und neuer verwendet Gated DeltaNet mit abwechselnden Attention- und SSM-Layern
  • Vulkan ist paradoxerweise schneller als ROCm, und es ist wichtig, bei llama.cpp auf dem neuesten Stand zu bleiben, um Probleme mit erneuter Verarbeitung zu lösen
  • Eine Divergenz des Tokenizers, bei der autoregressiv generierte Tokens beim Prefill anders geparst werden, ist schwer zu beheben

Debatte über Kosten- und Stromökonomie

  • 2× RTX3090 kosten etwa $4400; bei $100/Monat für Claude entspricht das 3,6 Jahren, Strom und übrige Hardware nicht eingerechnet
    • Auch in 3,6 Jahren dürften GPUs mit großem Speicher teuer bleiben
    • In Regionen mit hohen Stromkosten liegt der Break-even teils eher bei etwa einem Jahr
  • Der Stromverbrauch ist geringer als erwartet
    • Bei 1,2 kW Volllast liegen die Kosten bei etwa $0.12/Stunde, mit Solar noch günstiger
    • Inferenzlast ist anders als Gaming-Last, daher ist Strom oft kein großes Problem; das System liegt bei etwa 200 W idle und 350–450 W bei Inferenz
  • Zum Zeitpunkt des Hardwarekaufs
    • Derzeit sei kein idealer Kaufzeitpunkt; die nächste gute Gelegenheit werde eher in 24–36 Monaten gesehen
    • Ein M4 Pro Mac mini mit 48 GB Unified RAM für ~$2k wird als günstige Inferenzmaschine empfohlen, mit ~150 tok/s und potenziell 10 Jahren Nutzungsdauer
    • Eine AMD R9700 mit 32 GB VRAM für ~$1200–1400 sei für AI-Zwecke attraktiver als 2× 9070
  • Auch Miete in Form von Cloud-Abos ist eine legitime Strategie; nicht jeder kann viel Geld in Hardware investieren

Einordnung gegenüber Frontier-Modellen

  • Wiederholt wird lokale Modelle auf dem Niveau von „Edge-Modellen von vor 8–12 Monaten“ eingeordnet
    • Laut Benchmarks übertrifft Qwen 3.6 35B-A3B Claude 4 Opus, wobei bei einigen Open-Source-Modellen Benchmark-Gaming vermutet wird
    • In einem YouTube-Test zum Browser-OS erzeugte Qwen 3.6 mehr funktionierende Features als Claude 4 Opus
    • Das entspreche allerdings Frontier-Modellen von vor einem Jahr; ein MoE mit 3B aktiven Parametern sei mit aktuellem Opus oder Sonnet nicht vergleichbar, lautet der Einwand
  • Im Kern der Debatte steht die uneinheitliche Definition von „Opus-Niveau“
    • Der Begriff wird seit Claude 3 Opus von 2024 verwendet; zu den aktuellen Modellen Opus 4.8 und 4.6 besteht weiterhin Abstand
    • Mit Opus 4.5 und GPT 5.2 im vergangenen November habe es einen stufenweisen Sprung bei Frontier-Modellen gegeben; mit „Opus-Niveau“ sei üblicherweise eher die Zeit ab 4.5 gemeint
    • Die größten Open-Weights-Modelle benötigen Hardware auf dem Niveau von Servern mit 8× H100; Heim-Setups liegen noch darunter
  • Manche ordnen lokale Modelle zwischen Haiku 4.5 und Sonnet 4.5 ein; mit starkem Micromanagement liefern sie gute Resultate
  • Die Lücke zwischen Frontier- und lokalen Modellen dürfte wohl bestehen bleiben, für viele Nutzer sind lokale Modelle aber bereits praktisch nutzbar

Harness- und Workflow-Strategien

  • Pi Harness wird am häufigsten empfohlen und hat den Charakter eines Agent Development Kits; beschrieben als „neovim zu Claudes VSCode“
    • Es bringt Basis-Tools für Dateizugriff, Bearbeitung und bash mit; erweiterbar durch MCP-Adapter und Websuche
    • Mit dem Befehl /tree lässt sich der Kontext auf den Stand vor einem fehlgeschlagenen Tool-Call zurücksetzen, mit /new komplett neu starten
  • Hierarchische, rollengetrennte Workflows gleichen Grenzen aus
    • Ein Frontier-Modell erstellt Spezifikation, Design und Ausführungsplan, das lokale Modell übernimmt die Implementierung
    • Agenten werden nach Rollen verbunden, etwa Projektmanager, Schema-Agent und Coding-Agent; ein Orchestrator mit Playwright reicht nur Fehler an die nächste Stufe weiter
    • Aufgaben werden in atomare TODOs zerlegt und Referenzdateien explizit genannt, um Kontext zu sparen
  • OpenCode ändert pro Turn den System-Prompt und ist damit teils nicht KV-Cache-kompatibel; die Unterstützung lokaler LLMs ist manuell und komplex
  • Ollama wird wegen der Ergänzung von Cloud-Modellen und Monetarisierung kritisiert; empfohlen werden llama.cpp und llama-swap, unter macOS ist llm-mlx 10–15 % schneller

Beispiele für konkrete Konfigurationen

  • In einer Umgebung mit AMD 7900xtx 24gb + 5950x + 64gb DDR4 läuft Qwen3.6-27B-MTP-UD-Q4_K_XL mit llama.cpp Vulkan
    • Wichtige Flags: -ngl 99 (alle Layer auf die GPU ausgelagert), -c 80000 (80K Kontext), --cache-type-k q8_0 --cache-type-v q8_0 (8-Bit-KV-Cache), -fa on (Flash Attention), --spec-type draft-mtp (MTP-Draft)
    • Sampling: --temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.0 (empfohlene Werte für Qwen beim Coding)
    • Leistung: Token-Generierung ~65 t/s, Prompt-Verarbeitung ~600 t/s, Cold Start ~30 Sekunden
    • Die Kombination aus Crush Harness + Headroom + Exa MCP Websuche ersetzte ein persönliches Claude-Code-Abonnement
  • Auf einer V100 32GB läuft Qwen3.6-27B-UD-Q4_K_XL + Pi mit dem Fork llama-cpp-turboquant und MTP-Patch
    • Mit 200.000 Kontext und --spec-type mpt --cache-type-k turbo3 --cache-type-v turbo3 werden 45–60 t/s erreicht
  • Auf Strix Halo 128GB liefert Qwen3.6-35B-A3B etwa ~800 tps bei der Prompt-Verarbeitung und 50 tps bei der Token-Generierung; im Idle ist der Stromverbrauch fast null
    • Bedauert wird, dass es keine 122B-Version gibt; in Unified-Memory-Umgebungen sind Dense-Modelle wegen begrenzter Speicherbandbreite langsam
  • Es wird auch Unmut über fehlende Details geäußert; gefordert werden konkrete Angaben zu Quantisierung, Parametern, Kontext, GPU, VRAM und Harness-Konfiguration

Verwandte Beiträge

2 Kommentare

 
b89kim 1 시간 전

Als ich Pi-coding-agent + Qwen3.6-27B-MTP-GGUF verwendet habe, lag die Leistung ungefähr auf dem Niveau von Sonnet 4.5. Für das Erstellen einfacher Apps reicht das völlig aus, und bei Bedarf habe ich gelegentlich eine kostenlose API (z. B. GLM5.1) angebunden. Der Stromverbrauch von GPUs der Klasse 4090/5090 ist zwar hoch, aber bei einem ordentlich gebauten Agenten kommt es nicht oft vor, dass man ihn stundenlang laufen lassen muss.
 
GN⁺ 9 시간 전
Hacker-News-Kommentare

  • Greenpants: Datenschutz und kostenlose LLMs sind mir wichtig, deshalb nutze ich das Pi-Coding-Harness in einem Container/Sandbox komplett offline.
    Auf einem Mac Studio mit 128 GB oder einem MacBook mit 36 GB nutze ich Qwen3.6 35B; da nur 3B Parameter aktiv sind, ist es ziemlich schnell. Ich habe Homepage und Blog mit Django + Wagtail komplett neu gestaltet, aber Wagtail ist weniger bekannt, daher kennt sich der Agent ohne Internet nicht immer gut damit aus.
    Für komplexere Aufgaben habe ich auch Qwen3.5 122B verwendet, aber mit 10B aktiven Parametern ist es deutlich langsamer. Im Vergleich zu großen Modellen wie Claude muss man Fragen sehr präzise formulieren, und unausgesprochene Annahmen werden meist auf dem einfachsten Weg gelöst, was zu architektonisch fragwürdigen Entscheidungen führt, etwa CSS direkt ins HTML zu schreiben.
    Auch Tool-Aufrufe zum Bearbeiten gehen oft schief und landen in Schleifen. Qwen3.6 35B ist von seinem Allgemeinwissen her wie ein Junior, den man ständig führen muss, während Claude Opus eher einem Senior entspricht, der gemeinsam über die Architektur nachdenkt. Wenn Opus einer 15-fachen Beschleunigung entspricht, bringt vollständig offline laufendes Qwen eher eine 5-fache Beschleunigung, ist dafür aber kostenlos und immer noch beeindruckend.

    • lambda: Ähnlich hier: Ich lasse Pi in einem Container laufen und verbinde es mit llama.cpp in einem anderen Container.
      Netzwerkzugriff ist erlaubt, aber Zugangsdaten sind gesperrt, und Zugriff gibt es nur auf das Arbeitsverzeichnis und ~/.pi. Ich nutze ein Strix-Halo-Notebook mit 128 GiB Unified Memory und bevorzuge es, nicht mit proprietären Tools zu programmieren, daher kann ich keinen ernsthaften Vergleich mit Frontier-Modellen ziehen.
      Ich bin noch immer AI-Skeptiker und verbringe mehr Zeit damit, Modelle kaputtzutesten und ihre Stärken und Schwächen auszuloten, als sie produktiv zu nutzen, aber für Agent-Coding wähle ich am häufigsten Qwen 3.6 35B-A3B. Für allgemeine Chats und Übersetzungen nutze ich oft Gemma 4 31B, für Audio Gemma 4 12B.
      Ich habe auch Qwen 3.5 122B-A10B, Qwen 3.6 27B, Nemotron 3 Super 122B-A12B, Step 3.7 Flash, Minimax M2.7 und GPT-OSS 120B lokal, aber in diesem Setup ist Qwen 3.6 35B-A3B fürs Coden derzeit am ehesten der Sweet Spot.
    • geophile: Fast exakt die gleiche Erfahrung. Man muss sehr sorgfältig planen, alles in kleine unabhängige Schritte zerlegen, und auch das Design muss der Mensch klar aufschreiben.
      Wenn man qwen die Details selbst ausfüllen lässt, gerät es direkt vor dem Schreiben in Schleifen. Das Problem mit den fehlgeschlagenen Edits fand ich auch seltsam, deshalb habe ich in AGENTS.md die Bearbeitung gegenüber vollständigem Neuschreiben stärker eingeschränkt; das hilft etwas.
    • adyavanapalli: Für Edit-Tools könnte man einen hashbasierten Ansatz erwägen, bei dem jede Codezeile gehasht wird und Ersetzungen über diesen Hash referenziert werden.
      Der Ansatz wird hier beschrieben: https://blog.can.ac/2026/02/12/the-harness-problem/. Ich habe es nicht sauber benchmarked, aber gefühlt gibt es weniger Edit-Fehler; je nach Umgebung kann das unterschiedlich ausfallen.

  • horsawlarway: Für den privaten Gebrauch habe ich mein Claude-Abo für 100 Dollar im Monat gekündigt und durch pi harness mit Verweis auf unsloth studio sowie Qwen- und Gemma-Modelle ersetzt.
    Auf einer Dual-RTX3090-Maschine von vor etwa fünf Jahren lasse ich unsloth/Qwen3.6-35B-A3B-MTP-GGUF und unsloth/gemma-4-26B-A4B-it-GGUF mit UD-Q4_K_XL-Quantisierung laufen; beide schaffen etwa 150 tok/s und den vollen Kontext von 300k innerhalb des VRAM.
    Es ist nicht so gut wie Claude, aber kostenlos, und für den privaten Einsatz ist der Unterschied kein großes Problem. Ich nutze außerdem OpenClaw am selben Inferenzserver; das ist ein ziemlich passender Anwendungsfall für lokale Modelle.
    Beispiele sind ein alternativer Android-TV-Launcher, ein Admin-Portal für k8s-Services, Home-Assistant-Integrationen und -Automatisierungen, Einkaufs- und Essensplanung sowie ComfyUI-Workflows zur Erstellung von 3D-Assets. Für Software, mit der man Geld verdient, würde ich weiterhin bezahlte Anbieter empfehlen, aber auch lokale Modelle können ziemlich coole Dinge leisten.

    • rootlocus: Zwei RTX3090 kosten etwa 4.400 Dollar, das entspricht selbst ohne Stromkosten und weitere Komponenten bei 100 Dollar pro Monat für Claude rund 3,6 Jahren.
    • kpw94: Wenn du gemma mit UD-Q4_K_XL quantisiert betreibst, lohnt sich vielleicht auch ein Blick auf QAT-Modelle wie unsloth/gemma-4-26B-A4B-it-qat-GGUF.
      Siehe https://huggingface.co/unsloth/gemma-4-26B-A4B-it-qat-GGUF und https://blog.google/innovation-and-ai/technology/developers-.... Mit dem Update vom 9. Juni kam auch MTP-Support hinzu.
    • twothreeone: Ich habe dasselbe unsloth/Qwen3.6-35B-A3B-MTP-GGUF auf einer einzelnen 3090 mit 128k Kontext und Q4_K-Quantisierung ausprobiert und kam auf etwa 40–60 tok/s.
      Am störendsten war für mich bei realen Coding-Aufgaben mittlerer Komplexität die Ausgabequalität. Ich musste ständig zwischen „mit Prompts schieben“ und „selbst direkt implementieren“ wechseln, was eine hohe kognitive Umschaltlast erzeugt hat, und alle paar Minuten neu beurteilen, ob ich es schlecht angeleitet habe oder das Modell einfach nicht ausreicht.
      Auch der Sprung von Low-Level-Implementierungsdetails zu High-Level-Design gelingt ihm schlecht, und selbst Dinge wie Tabellen rendert es nicht zuverlässig. Bei Claude habe ich diese Probleme nicht; deshalb sehe ich es aktuell noch nicht als Ersatz, hoffe aber, dass das in ein paar Monaten anders aussieht. Ich habe Claude CLI durch aider ersetzt, wobei auch diese Entscheidung nicht unbedingt optimal sein muss.

  • bluejay2387: Ich erledige etwa 90 % meiner Programmierarbeit mit Qwen 3.6 27B, Open Code, benutzerdefinierten Skills und Semble
    Es ist zwar nicht so intelligent wie CC oder Codex, aber für die meisten Aufgaben reicht es aus. Ich habe eine RTX 6000, daher ist die TPS schnell genug, und ursprünglich war diese GPU für andere Arbeiten gedacht
    Das begann als Experiment, um zu sehen, wie nah man an Frontier-Modelle herankommt, aber es war gut genug, dass ich dabei geblieben bin. Für wirklich komplexe Aufgaben oder Feinschliff an der UI gehe ich immer noch zu Codex zurück, und bei Qwen wirkt die UI am schwächsten
    Das ist keine Empfehlung. Nicht viele Leute haben eine RTX 6000, und die Kosten entsprechen mehreren Jahren MAX-CC- oder Codex-Abos. Trotzdem sieht man das Potenzial, und in ein paar Jahren könnte es praktikabel sein
    Bei 256k Kontext habe ich das Compact Target auf 75 % gesetzt; wenn Gespräche über 100k gehen, fangen Qualität und Geschwindigkeit an nachzulassen, und nach 150k wird es sehr problematisch. Ich habe auch Qwen 3.5 122B ausprobiert, aber beim Programmieren war es deutlich schlechter als 3.6 27B. Gemma 4 31B ist für andere Aufgaben gut, aber beim Programmieren liegt Qwen vorn, und überraschenderweise ist auch Nemotron Super 120B beim Programmieren schwächer als Qwen

    • heipei: Ich lasse auf einer RTX 5090 per llama.cpp Qwen 3.6 27B Q6 laufen und nutze inzwischen nur noch pi agent
      Weil alles lokal läuft, muss ich mir über Tokenpreise, Quoten, Zeitzonen oder Datensensibilität überhaupt keine Gedanken machen. Ich habe die GPU-Leistung von 600 W auf 450 W begrenzt, und selbst während der Inferenz ist sie sehr leise
      Ich nutze es nicht nur zum Programmieren, sondern auch viel für alltägliche Kleinarbeit. Ich lasse es auf einem Branch committen und einen PR erstellen, mit der Stripe CLI offene und überfällige Rechnungen abrufen und mit einer Bank-CSV abgleichen, mit Elasticsearch-Zugangsdaten die Ursachen der aktuellen Last zusammenfassen oder prüfen, ob die Codebasis X unterstützt und wo das implementiert ist
    • bo1024: Qwen3.5-122B ist in Wirklichkeit Qwen3.5-122B-A10B
      A10B ist ein Mixture-of-Experts-Modell, bei dem jeweils nur 10B Parameter gleichzeitig aktiv sind, während Qwen3.6-27B ein dichtes Modell ist, bei dem alle 27B Parameter immer aktiv sind. Deshalb kann ein dichtes 27B-Modell bei vielen Aufgaben besser sein als 122B-A10B
    • user43928: Ich werde auf der Arbeit gezwungen, Qwen 3.6 27B zu verwenden, und finde es fast nutzlos
      Es ist besser, Dinge selbst zu machen; Implementierungen vermurkst es oder beim Debugging liegt es komplett daneben. Abgesehen von einer etwas intelligenteren Suche fühlt sich alles unterhalb von Sonnet wie Zeitverschwendung an
      Auch dass jemand Codex für UI-Feinschliff nutzt, wirkt seltsam. Codex ist bekannt dafür, schlecht bei UI zu sein, und liegt weit hinter Claude Opus zurück. Altman hat auch gepostet, dass sie das im nächsten Modell verbessern

  • pierotofy: Die Kombination Llama.cpp + Qwen3.6-35B(MTP) + OpenCode ist auf einer einzelnen RTX 3090 ziemlich leistungsfähig und schneller als die meisten Cloud-Modelle
    Qualitativ fühlt es sich an, als würde man ein Spitzenmodell von vor 8 bis 12 Monaten verwenden. Das Setup habe ich unter https://github.com/pierotofy/LocalCodingLLM/ dokumentiert

    • jacobgold: Wenn „Qualität eines Spitzenmodells von vor 8 bis 12 Monaten“ der Maßstab ist, ist das für Hobbynutzung großartig, aber für professionelle Entwickler als primäres Coding-Agent-Setup lag die Schwelle meiner Ansicht nach ungefähr vor 6 Monaten, als Opus 4.6 erschien
    • trueno: Ich habe ein MacBook Pro mit 128 GB M4 Max und würde gern damit herumspielen, finde aber kaum Zeit
      Mich würden Erfahrungen von Mac-Nutzern mit einem ähnlichen Setup interessieren. Ich sehe viele Debatten über lokale Modelle, aber die Vergleichsbasis verschiebt sich ständig, und auch die Begriffe sind mir nicht vertraut. Ich möchte ein objektives Gefühl dafür bekommen, was man gewinnt und verliert, wenn man lokal geht
    • atomicnumber3: Ich habe inzwischen überhaupt keine Lust mehr, Claude zu benutzen

  • codinhood: Auf diese Frage wird es wohl nicht viele „echte“ Antworten geben. Im Moment sind die Opportunitätskosten, nicht die neuesten und besten Modelle zu verwenden, einfach zu hoch
    Ich prüfe das jeden Monat, und das Fazit ist immer dasselbe. Zeit, Aufwand und Kosten, um lokale Modelle und das umliegende Coding-Tooling in die Nähe von Sonnet/Opus in Claude Code zu bringen, sind es derzeit noch nicht wert
    Wenn es das wert wäre, wäre es längst so disruptiv, dass es schon in den Nachrichten wäre. Ich will nicht ausschließen, dass es jemand gelöst hat, aber es ist eher ein Fall für Ockhams Rasiermesser, um nicht in einem tiefen Kaninchenbau zu verschwinden

    • pyeri: Auch dieser Opportunitätskosten-FOMO-Zug wird einen Sättigungspunkt erreichen, und ich denke, wir sind schon darüber hinaus
      Modelle auf Mythos-Niveau sind zwar State of the Art beim Reasoning, aber für den Problembereich, den die meisten Entwickler lösen wollen, bringen sie nicht besonders viel. Wahrscheinlich werden am Ende Modelle rund um Sonnet/Opus 4.8 das Niveau sein, das sich in Unternehmen breit durchsetzt
      Lokale Modelle sind noch nicht ganz dort, aber die DeepSeek-, Kimi-, GPT- und MiniMax-Familien kann man günstig über APIs wie NVIDIA, OpenRouter und Groq nutzen, und sie sind ziemlich nah an Sonnet-Niveau
    • mark_l_watson: Dasselbe Fazit scheint richtig zu sein. Ich möchte auf ein mehrstufiges System umsteigen: lokal, dann kommerzielle APIs wie OpenCode + DeepSeek v4 flash und schließlich DeepSeek v4 Pro
      So kann ich weiter alles erledigen, was nötig ist, und schrittweise immer mehr lokal verlagern. Schon auf derselben Hardware ist ein lokales Setup heute deutlich besser als vor 2 Monaten und im Vergleich zu vor 6 Monaten dramatisch besser
    • gunapologist99: Statt an Ockham könnte man eher an Pareto denken
      Wenn man wirklich glaubt, dass wir das in ein paar Jahren erreichen, ist es besser, schon jetzt damit herumzuspielen, und gerade bei kurzen oder kleinen Projekten sowie gut modularisierten großen Projekten kann man ziemlich überrascht sein

  • sosodev: Diese Frage deckt eine viel zu große Bandbreite an Fähigkeiten und Erwartungen ab. Wenn man nur ein 8B-Modell laufen lässt und Vibe Coding oder One-Shot-Ergebnisse erwartet, wird es schwierig.
    Wenn man ein Modell der 30B-Klasse betreiben kann, ist es bei passend abgegrenzten und gut definierten Aufgaben ziemlich gut. In diesem Bereich wirken Gemma4-31B und Qwen3.6-27B derzeit am besten.
    Wenn man schnellere Inferenz will, kann man auf ein MoE-Modell wechseln, aber bei den meisten Aufgaben fällt die Qualität spürbar ab. Kleine, eng umrissene Aufgaben gehen auch als One-Shot oder Vibe Coding, aber selbst dann ist Anleitung deutlich besser.
    Wenn man Frontier-Niveau will, braucht man mindestens 128 GB Speicher und viel Rechenleistung oder sehr viel Geduld. Den meisten fehlt entweder das Geld oder die Geduld. Bei lokaler Modellnutzung bedeutet Geduld nicht nur, auf Tokens zu warten, sondern auch den Aufwand, alles passend zum eigenen Workflow und zur eigenen Hardware einzurichten und stabil zum Laufen zu bringen.

    • argee: Ich nutze Gemma 4 26B A4B auf einem MacBook mit M4 Pro und 48 GB RAM zum Rust-Lernen und für verschiedene Fragen.
      Ich glaube nicht, dass es bei irgendetwas über sehr kleine Änderungen in einer IDE oder einem Harness hinaus gute One-Shots liefert. Aber wenn ein Mensch am Steuer sitzt, auf die Straße schaut und unter dem Tempolimit fährt, ist es als Copilot für Aufgaben mit kleinem bis mittlerem Kontext schnell und gut genug.
      Verglichen mit vor ein paar Jahren ist das erstaunlich, und ohne das würde ich KI fürs Programmieren vermutlich kaum nutzen. Ich mag das Gefühl nicht, dass alles sofort dumm wird oder blockiert, nur weil die Internetverbindung weg ist.
    • user43928: Ich habe ein kleines Modell, insbesondere GPT 5.4 Mini, gebeten, Änderungen von 10 bis 20 Codezeilen in eine andere Datei zu übertragen, und selbst beim zweiten Versuch hat es den Code verändert und Bugs eingebaut.
      Ich habe keine perfekte Zuverlässigkeit erwartet, aber ich dachte, wenn ich auf die Unterschiede hinweise, müsste es es zumindest beim zweiten Mal richtig machen. Stattdessen behauptete es selbstbewusst wieder, der Code sei jetzt identisch, und fügte einen anderen subtilen Bug hinzu.
      Ich weiß nicht, für welche Aufgaben solche Müllmodelle ausreichend sein sollen. Ein paar Minuten lang können sie so tun, als wären sie kompetent, aber am Ende stimmt das Ergebnis nicht. Höchstens für intelligentere Suche oder Autovervollständigung taugen sie meiner Meinung nach.

  • mgsram: Nach etwa einem Jahr mit lokalen LLMs bin ich jetzt bei einer Kombination aus Qwen3.6 27B dichtes GGUF, OpenCode und llmster (LM Studio) auf einem Mac Studio mit 512 GB RAM gelandet.
    Ich habe auch Qwen 3.6 35B-A3B ausprobiert, aber die Genauigkeit des dichten Modells ist eine Stufe höher, auf Kosten von Tokens pro Sekunde. Qwen3.6 27B läuft bei mir normalerweise mit etwa 25 bis 40 tok/s.
    Anfangs habe ich es für einfache Tools genutzt, aber seit den letzten 3 bis 4 Monaten setze ich es tatsächlich für produktionsreifes Coding in C/C++-Automotive-Software-Stacks und Python-Tools ein. Dass es langsamer ist, sorgt sogar eher dafür, dass ich in angemessenem Tempo arbeite.
    Bei Neuentwicklung oder Rewrite arbeite ich mit Sonnet zusammen an Design, Architektur, Reasoning und detaillierten Ausführungsplänen, zerlege das dann in Teile und gebe diese als präzise Prompts ein. Bei Arbeit an bestehendem Code ist Urteilsvermögen gefragt, und wenn ich die Grenzen lokaler Modelle spüre, gehe ich zurück zu Claude Code.
    Kürzlich habe ich mit Qwen 3.6 einen kompletten Rewrite eines auf C basierenden Power-Management-Service erstellt, unter Bezug auf bestehenden C++-Code, außerdem einen komplexen Excel-Spec-Parser und ein Tool, das CJK-Inhalte ins Englische übersetzt und in eine KG einspeist.

  • 3abiton: Da alle Qwen erwähnen, nutze ich ebenfalls Qwen 3.6 35B Q8(MTP) auf Strix Halo mit llama.cpp.
    Ich komme auf etwa 40 bis 50 t/s, und die Leistung ist wirklich gut. Ich habe es direkt mit forge-code in zsh verwendet, und bei langem Kontext über 150k fällt die Qualität ab und es beginnt Dinge zu vergessen.

  • wsintra2022: Wenn ich hier die Kommentare lese, kann ich oft nicht unterscheiden, ob es Bots im Sinne der AI-Anbieter sind, die einem lokale Lösungen ausreden wollen, oder echte Leute mit schlechten Erfahrungen mit lokalen AI-Modellen.
    Qwen 3.6 27B 8k quantisiert auf einem Mac Studio mit 64 GB ist kein universelles Superwesen auf Frontier-Niveau, sondern einfach gut. Es ist kostenlos, privat, und es ist magisch, wie es aus einem erfahrenen Engineer einen noch fauleren macht.
    Ich nutze llama.cpp und opencode, plane und lasse Codeänderungen ausführen und lege mich dann in die Hängematte, spüle ab oder mache etwas anderes. Ich prüfe später per tmux und ssh nach. Genau das ist der wirklich erstaunliche Teil.

    • epolanski: In der Software-"Engineering"-Branche ist die Messlatte sehr niedrig, weil es dort oft MIT-Leetcode-Ninjas gibt, die mit React+Tailwind speicherleckenden unbrauchbaren Slop schreiben.

  • garethsprice: Ich nutze OpenCode + OhMyOpenCode + Qwen 3.6 35B-A3B Q_4_KM auf einer Ada 4000 mit 20 GB VRAM, und die Generierung läuft bei etwa 55 tok/s.
    OpenCode hängt viel Kontext an, deshalb fühlt es sich langsamer an, als die Zahl vermuten lässt. Pi wird auch oft erwähnt, das schaue ich mir bald an.
    Ich lasse Opus einen Plan erstellen, dann folgt ihm ein lokaler Agent, und anschließend validiere ich wieder mit Opus. Es ist also nicht 100 % lokal, aber diese Modelle werden zunehmend Teil meines Produktions-Workflows.
    Im Moment lohnt es sich vielleicht noch nicht, wenn man nicht als Hobby gern Zeit und Geld hineinsteckt. Es ist nicht so gut wie Opus oder andere Frontier-Modelle, aber in Bereichen mit mehr Wiederholungsarbeit ist es "gut genug".
    Auch ohne Rolls-Royce kommt man mit einem gebrauchten Corolla zum Supermarkt. Dadurch werden neue Workflows möglich, bei denen Frontier-LLMs zu teuer wären. Ich habe über Nacht Fuzz-Tests wie ein Nutzer mit Chrome devtools MCP laufen lassen und per Multimodalität sogar Screenshots prüfen lassen; wenn man an die Kosten von Claude plus Screenshots denkt, ist das beeindruckend.
    Die Aussage "12 bis 18 Monate hinter Frontier" scheint zu stimmen. In 12 bis 18 Monaten könnte man wohl ein lokales Opus-Niveau-Modell für unter 5.000 Dollar betreiben, aber Frontier-Modelle werden dann ebenfalls weiter voraus sein.

  • arjie: Nicht lokal und auch kein interaktives Coding, aber ich betreibe DeepSeek V4 Flash mit zwei RTX Pro 6000 Blackwell.
    Die rohe Geschwindigkeit liegt bei 160 tok/s, aber es ist ein Reasoning-Modell. Ich nutze es für automatische Code-Erstellung und automatisierte Reviews anderer Systeme. Mit Pi lasse ich gelegentlich Code schreiben, und das ist sehr schnell, aber aus Gewohnheit nutze ich meist weiter CC und Codex.

    • akersten: Ich frage mich, wo du die RTX Pro 6000 Blackwell herbekommen hast.
      Alle Seiten, die ich gefunden habe, waren entweder ausverkauft, haben nur an Unternehmen verkauft oder wirkten dubios.
    • leptons: Ich würde gern wissen, ob du den Stromverbrauch dieses Setups gemessen hast. Mich interessiert, was das pro Monat kostet.

  • stymaar: Betreibt Qwen3.6-35B-A3B auf einem Strix Halo 128GB Bosgame M5
    Dafür ist eigentlich viel zu viel VRAM vorhanden, aber Qwen hat keine 122B-Version von Qwen3.6 veröffentlicht, die am besten zu meiner Hardware passen würde. Dafür sind die Stromkosten praktisch vernachlässigbar. Es ist ursprünglich ein Laptop-Chip, verbraucht im Idle also fast nichts und liegt selbst bei der Prompt-Verarbeitung nur etwas über 120W
    Qwen3.6 ist überraschend effektiv, sodass ich Claude nur gelegentlich nutze, vielleicht für etwa 10 % meines Gesamtbedarfs. Selbst mit dem günstigsten Plan bleibe ich unter dem Kontingent. Die Geschwindigkeit liegt bei etwa 800tps bei der Prompt-Verarbeitung und 50tps bei der Token-Generierung, ohne Speculative Decoding

    • manmal: Mich würde interessieren, ob du auch die 27B-Dense-Version ausprobiert hast. Für Coding ist sie deutlich besser

  • Kostic: Für private Nutzung verbinde ich VSCode mit llama.cpp und betreibe Qwen 3.6 27B oder Gemma 4 31B, was völlig ausreicht, um Cloud-Abos zu kündigen
    Qwen läuft auf der ersten GPU mit q4@176k Kontext und MTP bei etwa 70~50tok/s, was fürs Coding ziemlich gut ist. Gemma nutzt beide GPUs und verarbeitet mit q8@64k Kontext Dokument-Sentimentanalyse, Zusammenfassungen, Korrekturlesen und Übersetzungen mit 25tok/s
    Für Batch-Workflows ist es etwas langsam, aber brauchbar. Wenn llama.cpp MTP im Tensor-Split-Modus unterstützen würde, könnte es wohl noch mehr werden
    Auf der Arbeit nutze ich weiterhin Frontier-LLMs, weil ich die Kosten dort nicht selbst trage, und natürlich sind sie besser. Ich hoffe, dass es in etwa einem Jahr ein 30B-Modell auf dem Niveau von Sonnet 4.6/Opus 4.5 gibt
    Die Prompt-Verarbeitung startet bei 800t/s und fällt bis auf 400t/s ab. Mein Start-Prompt hat meist 16k~24k Token, daher dauert die Verarbeitung 60~90 Sekunden; nicht gut, aber akzeptabel

  • jodoherty: Nutzt Gemma 4 31B auf einer RTX Pro 6000 Blackwell mit Pi für sämtliches agentisches Coding
    Ich finde das nützlich, und dieses Side-Project ähnelt der Art, wie ich bei der Arbeit Projekte zuschneide und bearbeite: https://git.theodohertyfamily.com/wg-wrap.git/tree/README.md https://git.theodohertyfamily.com/wg-wrap.git/tree/CASE_STUD...
    Man muss sehr bewusst Architekturarbeit leisten und viel TDD anwenden. Schwierige Teile werden früh angegangen und mit einfachen, leicht nutzbaren Interfaces umhüllt, um technisches Risiko zu eliminieren
    Bei manchen Projekten ist es 2~3x schneller, als alles selbst zu schreiben, und bei langweiligen oder sehr breit angelegten Projekten spart es 5~10x Zeit, weil man Ideen schnell sammeln und ausprobieren kann
    Das Setup umfasst vLLM mit nvidia/Gemma-4-31B-IT-NVFP4 sowie llama.cpp mit unsloth/gemma-4-31B-it-qat-GGUF und MTP. Die GPU-Leistung ist auf 400W begrenzt. Die aktuelle llama.cpp-Konfiguration liefert je nach Akzeptanzrate des MTP-Drafts 60~150t/s, prefill liegt je nach Kontextlänge und -tiefe bei 1500~4000t/s

  • jborak: Betreibt Qwen3.6 27B MTP Q6_K in llama.cpp mit vier RTX 5070 und einem AMD Threadripper 1950X der ersten Generation und nutzt Pi erfolgreich als täglichen Driver
    Die Geschwindigkeit liegt bei etwa 50~60tok/s. Ich hänge auch andere Apps wie OpenWeb UI daran und habe kürzlich das LLM-Gateway Bifrost als standardmäßigen Einstiegspunkt für den Modellzugriff eingerichtet
    Ich habe auch Qwen3.6 35B A3B ausprobiert, aber fürs Coding passt 27B besser. Es ist als Dense-Modell langsamer, aber die Qualität wirkt deutlich besser. 35B A3B ist ohne MTP mit 130~140tok/s absurd schnell
    Um Qwen3.6 27B zu betreiben, braucht man nicht zwingend vier 5070er; drei, vielleicht sogar zwei könnten reichen. Wenn man 27B aber mit MTP beschleunigen will, braucht das Draft-Modell eigenen Kontext und damit mehr Speicher
    Man muss auch bedenken, dass der System-Prompt der Tools bei jeder Unterhaltung ins Modell geladen wird. Wenn ich Pi starte, reagiert es anfangs sehr schnell, aber bei Interaktionen über Hermes CLI bringen die einzelnen Prompts viele Skills, Tools usw. in den Kontext und behalten sie bis zum Ende des Gesprächs, wodurch alles deutlich langsamer wird
    Datenschutz ist schön, aber ich mag auch, dass es keine Kontingente gibt und ich mir keine Gedanken über den Verbrauch machen muss. Wenn die Zukunft aus „Loop Engineering“ besteht, verbrennt man mit Cloud-Modellen Token und Geld. Mein System liegt im Idle bei 200W und unter hoher Inferenzlast bei 350~450W, und Decoding ist nicht besonders effizient, sodass die GPUs öfter untätig sind, als man denken würde. Fortschritte wie Diffusion könnten das Decoding beschleunigen und die Auslastung inaktiver GPUs verbessern

    • zakisaad: Mich würde interessieren, warum du dich bei einer 4-Karten-Konfiguration für die 5070 entschieden hast
      Mein erster Eindruck wäre, dass sie stark auf Rechenleistung und zu wenig auf VRAM ausgelegt ist, also gut für Gamer, aber nicht besonders gut zum Ausführen von LLMs. Ich nutze in meinem Desktop ebenfalls eine 5070

  • cuttysnark: Mit lokalen Modellen habe ich einige Erfolge erzielt, indem ich mehrere Agenten in einem Workflow verkettet habe
    Jeder Agent nutzt je nach Rolle andere Prompts und ein anderes ollama-Modell. Ein Projektmanager- oder Schema-Agent (qwen3:14b) verwendet nicht dasselbe Modell wie ein Coding-Agent (qwen2.5-coder:7b)
    Zwischen den einzelnen Schritten gibt es einen Orchestrator und Playwright-Aufgaben, die versuchen, dem Agenten, der den vorherigen Codeblock erzeugt hat, Fehler sichtbar zu machen. Nur fehlerfreie Blöcke gehen in den nächsten Schritt über
    Die größte Verbesserung war, eine backend-for-agents-Servicedefinition einzuführen, sodass der Schema-Agent nur noch ein aufgabenbasiertes Manifest erstellt und es an den nächsten Agenten weitergibt. Kurz gesagt definiert man einen Workflow so, dass die Agenten nur sehr spezifische Aufgaben erledigen und dann an den nächsten Schritt übergeben. So verlieren sie nicht den Faden, und es entstehen Stellen, an denen ein Mensch in Abläufe mit 25 % oder 90 % Erfolg eingreifen kann

    • pianopatrick: Es wäre interessant, solche Workflow-Benchmarks und Wettbewerbe zu haben, damit man sehen kann, was gut funktioniert
      Etwa nach dem Muster: „Verwendet nur diese Consumer-GPU, nehmt beliebige Modelle und Workflows und schaut, wie gut ihr den xyz-Benchmark löst.“ Den Teilnehmenden gibt man maximal 1 Stunde und bewertet den Anteil beantworteter Aufgaben, die Genauigkeit und die Gesamtzeit — so etwas wie „The Local AI challenge“ wäre gut
    • sowbug: Mich würde interessieren, ob du schon ausprobiert hast, Agenten gegeneinander antreten zu lassen
      Zum Beispiel könnte man dieselbe Coding-Aufgabe zwei Modellen oder verschiedenen Seeds desselben Modells geben und dann einen Reviewer das bessere Ergebnis auswählen lassen. Es gibt die Ansicht, dass auch das menschliche Gehirn so funktioniert, dass Tausende von Mini-Kortexsäulen Situationen jeweils etwas anders betrachten und dann per Mehrheitsentscheid abstimmen

  • HappySweeney: Ich habe mit Optane und viel RAM über Nacht ein Modell nahe an einem Full-Size-Modell für das Schreiben von Funktionen bei etwa 0,7 t/s genutzt.
    Der aktuelle Test besteht darin, eine Scala-Funktion in eine Bit-Matrix-Transpose-Funktion umzuwandeln, die AVX512 verwendet. Cloud-Modelle schaffen das problemlos, aber Kimi 2.6 und GLM 5.1 scheitern daran katastrophal.

  • etoxin: Ersetzen konnte ich es bisher noch nicht. Für Projekte bei der Arbeit nutze ich openspec, und um ohne große Ausgaben lokale Hardware nachzuahmen, zahle ich für gehostete Versionen der aktuell populären lokalen Modelle.
    Die meisten kleineren lokalen Modelle beherrschen Tool Calling nicht richtig, aber die größeren Modelle bekommen das inzwischen ordentlich hin. Was auf der lokalen Seite noch nicht wirklich berücksichtigt wird, ist, dass produktive Engineers normalerweise mehrere CLI-Chats parallel zusammen mit git worktree laufen lassen. Ich habe normalerweise 3 Worktrees und CLI-Chats offen.

  • blurbleblurble: Ich glaube, die aktuelle Grenze liegt weniger beim Modell selbst als bei der Usability alternativer Harnesses, denen seltsamerweise Funktionen wie Queue-Management, Unterbrechung, Sub-Agents und Ziele fehlen.

    • coder543: Stimme ich völlig zu. Es nervt auch, dass OpenCode lokale LLMs nicht wirklich ordentlich unterstützen will.
      Man kann OpenCode zwar zum Laufen bringen, aber die Konfiguration ist sehr manuell und umständlich. Ich habe ein Skript gebaut, das llama-server-Konfigurationen automatisch in OpenCode-Konfigurationen umwandelt; das hilft, ist aber nicht ideal.
      Ich habe ernsthaft darüber nachgedacht, in meiner Freizeit noch einen weiteren Coding-Harness zu bauen. Ich habe ein paar Ideen, wie man das besser machen könnte.
    • horsawlarway: Pi ist okay
      Ich habe Claude, Cursor, den CLI-Agenten von Pi, selbst gebaute Custom-Harnesses und sogar gastown ausprobiert, und Pi reicht einfach aus. Es erledigt, was man braucht, die Standard-Tools sind okay, es integriert sich gut mit anderen Tools und verursacht weniger Aufwand.
      Wenn man Modelle um die 30B mit brauchbarer Geschwindigkeit laufen lassen kann, werden viele mit Pi ziemlich überrascht sein. Mit Erweiterungen wie https://pi.dev/packages/pi-mcp-adapter?name=mcp und https://pi.dev/packages/pi-web-access?name=search bekommt man außerdem Zugang zu Web-Tools, Perplexity-Suche, https://browsermcp.io/ zur Chrome-Steuerung und https://github.com/mozilla/firefox-devtools-mcp für Firefox.
      Es ist nicht so gut wie die bezuschussten Top-Modelle, aber kostenlos und trotzdem leistungsfähig. Persönlich nutze ich auch https://pi.dev/docs/latest/sdk mit viel Spaß; andere Anbieter verlangen für solchen API-Zugang Tausende Dollar pro Monat.
    • Insanity: Ich habe Gutes über pi.dev gehört, es aber noch nicht ausprobiert. Es könnte einige der erwähnten fehlenden Funktionen lösen.

  • _bobm: Wenn man von Claude-/GPT-Modellen spricht, muss man darüber nachdenken, was dieses „Modell“ tatsächlich ist.
    Man muss sich nur anschauen, wie GPT seine Denkabschnitte Stück für Stück sendet und Zusammenfassungen der Denkblöcke als Markdown-Header anhängen kann. Wenn man die API-Endpunkte und das Ausgabeverhalten beobachtet, sind sogenannte SOTA-Modelle nicht das, was sie zu sein scheinen, und infrastrukturell überhaupt nicht mit lokalen Modellen vergleichbar.
    Beim Betrieb in dieser Größenordnung gibt es eine enorme Orchestrierung, und deren Einschränkungen führen zu nicht offen ausgesprochenen Innovationen. Ich glaube nicht, dass das unmöglich aufzuholen ist, aber ein lokales Modell mit llama oder vLLM zu serven, ist nur Alphabet-A-, B-, C-Niveau.
    Was man tatsächlich braucht, ist meines Erachtens eine Reproduktion der oben angedeuteten Orchestrierung. Ein SOTA-„Modell“ ist kein einzelnes Modell, sondern eine tiefe Orchestrierung mehrerer Modelle, die zusammenarbeiten. Deshalb wird ein Einzelmodell nicht aufschließen, bevor es diese Orchestrierung in Training und Architektur repliziert.
    Ich glaube, dass ein einzelnes Modell innerhalb dieser Orchestrierungs-Konfigurationen, die normalen Verbrauchern angeboten werden, für sich genommen nicht viel besser ist als Qwen 3.6. Wenn man die Perspektive ändert, beginnt man den Maßstab der „Magie“ zu sehen.

    • XCSme: Ich verstehe nicht, warum du glaubst, dass SOTA-Modelle eine tiefe Orchestrierung mehrerer Modelle sind.
      Ich würde auch gern ein konkretes Beispiel dafür sehen, dass GPT Denkabschnitte zusammen mit Markdown-Header-Zusammenfassungen sendet.

  • cheekygeeky: Unser Softwareentwickler ist der klügste Mensch, den ich je getroffen habe, und nutzt OpenCode und Tmux zusammen mit Open-Source-Modellen.
    Fürs Coding bevorzugt er DeepSeek am meisten und nennt es „ziemlich gut“. Es läuft auf einem i9 mit 128 GB RAM und zwei 3090. https://www.msn.com/en-us/news/technology/china-s-open-deeps...

  • pianopatrick: Es wäre hilfreich, Benchmarks und Wettbewerbe für solche Workflows zu haben, damit man sehen kann, was gut funktioniert.
    So etwas wie: „Mit nur dieser Consumer-GPU, deinem Wunschmodell und deinem Workflow, wie gut kannst du den xyz-Benchmark lösen?“ Ich würde gern einen Wettbewerb wie „The Local AI Challenge“ sehen, bei dem die Teilnehmenden maximal 1 Stunde bekommen und nach Antwortquote, Korrektheit und Abschlusszeit bewertet werden.

  • bravetraveler: Ich nutze es fast komplett „grass-fed“, und auch die geringe LLM-Nutzung ist vollständig lokal.
    Auf einem 128-GB-Strix-System liefern weniger dichte Qwen- oder Gemma-Varianten 50–80 tok/s Ausgabe. Ich habe nicht vor, Anthropic/OpenAI usw. zu abonnieren, und selbst wenn dies das letzte lokale Modell wäre, bräuchte ich das nicht. Tool-Nutzung innerhalb des Modells fängt die Sorge um Aktualität auf.

  • GodelNumbering: Als jemand, der den ganzen Tag mit LLMs spricht, halte ich die Kombination aus Open-Source-Frontier-Modellen + gutem Harness bereits für ausreichend.
    Für eine vollständige lokale Bereitstellung braucht es wohl noch ein oder zwei Hardware-Generationen. Allerdings priorisieren Hardware-Unternehmen den Rechenzentrumsbereich derzeit so stark, dass dieser Zeitpunkt vielleicht nicht so bald kommt.

  • milchek: Ich habe es auf einem 36-GB-MacBook-Pro versucht, aber über sehr grundlegende Aufgaben hinaus war es kein großer Erfolg.
    Selbst mit kleineren Modellen war das Problem, dass der Kontext schnell erschöpft war und alles langsam lief. Für halbwegs ordentliche Leistung scheinen 128 GB Speicher nötig zu sein, was die Hardwarekosten stark erhöht.
    Am Ende ist es die Frage, ob man ein Frontier-Model-Abo nutzt oder das Geld in Hardware versenkt. Wenn Privatsphäre allerdings wichtig ist, gibt es außer Geld für hochwertige Hardware auszugeben kaum Alternativen.

  • acc_297: Ich frage mich, ob es helfen würde, ein mittelgroßes Modell mit RLHF bei jedem Prompt laufend fein auf die eigenen Nutzungsgewohnheiten abzustimmen.
    Ich weiß nicht, ob man ein Modell durch manuelles Finetuning verschlimmbessert oder verbessert. Wenn man gewissenhaft Feedback gibt, wäre es schön, generische Ticks wie übertriebenes Einschmeicheln, Geschwätzigkeit oder die nervige Angewohnheit, alles in Metaphern zu erklären, zu reduzieren, aber ich weiß nicht, ob das Feedback einer einzelnen Person dafür ausreicht.
    Ich habe auch gehört, dass interne Agenten, die mit internen Dokumenten feinabgestimmt wurden, merkwürdiges Verhalten zeigen und nicht unbedingt nützlicher sind als Standardmodelle. Es wäre gut, wenn man alle Antworten eines Agenten bearbeiten und ihn anhand der Unterschiede zwischen Original und Bearbeitung feinabstimmen könnte.
    Ich persönlich würde wohl viele Adjektive entfernen und auf Kernantworten verdichten, aber wenn man sich die Arbeiten von Alignment-Forschern wie Owain Evans ansieht, macht mir Sorgen, dass solche Anpassungen das Modell in schwer vorhersehbare Tendenzen schieben könnten.

    • htrp: Cursor macht so etwas. Anscheinend nutzen sie Fireworks als Anbieter: https://cursor.com/blog/real-time-rl-for-composer
    • rolisz: Ich würde so etwas Ähnliches gern mit dem OpenClaw-Agenten ausprobieren.
      Die Arbeit von Owain Evans war meines Wissens SFT. Auf Twitter meinte jemand, RL sei weniger anfällig für die von ihm gezeigten Phänomene, aber ich würde das gern selbst testen.

  • heisenbit: Es braucht Einrichtungsarbeit, aber dabei lerne ich eine Menge.
    Auf einem 48-GB-M4-MBP nutze ich meist qwen/qwen3.6-35b-a3b mlx, und es bleibt gerade noch genug Luft für Docker Dev-Container und grundlegende Aufgaben. Ich lasse es in LM Studio laufen und nutze es in VSCode.
    Einen großen Unterschied hat gemacht, den System-Prompt zu ändern, um die Tool-Integration zu verbessern. Davor hat es oft Code neu generiert, statt Änderungen anzuwenden, und damit mehr kaputtgemacht als geholfen.
    Um Lärm und Hitze zu vermeiden, nutze ich meist auch am Netzteil den Stromsparmodus. Bei maximaler Leistung ist es ungefähr doppelt so schnell, verbraucht aber mehr als doppelt so viel Strom.
    Möglich waren Dinge wie einfache Umstrukturierungen einer Seite, aber das Aufteilen eines Pinia-Stores ist gescheitert. GPT-5.4 erledigt diese Aufgabe problemlos. Ich denke, mit besserer Abstimmung der Tool-Nutzungsanweisungen und des unterstützenden Toolings ließe sich noch mehr herausholen.

  • nfrankel: Ich habe es versucht, und theoretisch funktioniert es: https://blog.frankel.ch/tokensparsamkeit-coding-assistants/#...
    Die Ergebnisse hängen vom Modell ab, und letztlich ist der Computer der begrenzende Faktor. Meine Hardware konnte es leider nicht stemmen.

  • K0balt: Mit qwen 3.6 27b dense bekomme ich ziemlich gute Ergebnisse.
    Je nach Aufgabe ist es ähnlich wie Claude Haiku 4.5, vielleicht manchmal sogar auf Sonnet-Niveau.

    • kadoban: Mich würde interessieren, mit welchen Tools du die Aufgaben ausführst.
    • kandros: Für Coding-Aufgaben würde ich eher den Metzger fragen als Haiku.

  • jderekw: Als tägliches Setup nutze ich AMD Lemonade.
    Ich habe mit Ollama angefangen, bin dann zu LMStudio gewechselt und habe mich inzwischen auf AMD Lemonade standardisiert, weil es beim Monitoring von cRAM, CPU, GPU und gRAM hilft. Dank der Multi-Model-Funktionen von Lemonade kann man damit leicht LLM-, Speech-to-Text-, NPU- und Bildgenerierungs-Stacks betreiben.
    Die Plattform läuft auch auf Nvidia-, Apple-, Intel- und AMD-Chipsätzen.

  • redox99: Modelle wie Qwen 35B, die man zu Hause betreiben kann, kommen Opus oder GPT 5.5 überhaupt nicht nahe.
    Die offenen Modelle in dieser Nähe liegen eher bei rund 1T Parametern, also kann man das zu Hause vergessen. Das ist wie mit einer alten Schrottkarre: Manche werden dich überzeugen wollen, dass sie für die Fahrt von A nach B völlig okay ist, aber das ist sie nicht.
    Außer wenn Privatsphäre absolut notwendig ist, es einfach Spaß macht oder man Spezialfälle wie ein Flugzeug hat, gibt es keinen rationalen Grund dafür. Wenn man sich nicht einmal die stark subventionierten 20 Dollar für Codex leisten will, ist selbst eine chinesische Modell-API diesen kleinen Modellen haushoch überlegen.

    • pbasista: Mich würde interessieren, auf welchen objektiven Fakten oder Benchmarks die Einschätzung beruht, dass „Modelle wie Qwen 35B, die man zu Hause betreiben kann, Opus oder GPT 5.5 überhaupt nicht nahekommen“.
    • xgulfie: Man braucht keinen Ferrari, um zur Arbeit zu fahren.

  • sj_tech: Auf einem Mac Mini mit 128 GB nutze ich Qwen 3.6 35B A3B mit der GitHub-Copilot-Extension für VSCode für agentisches Coding.
    Gemessen an der Modellgröße ist es okay, aber wenn das Problem zu groß wird, sehe ich, wie es in Schleifen gerät. Es ist gut, um Dinge erledigen zu lassen, die man selbst ohnehin kann, damit man Zeit spart.

  • julianlam: Auf einem Framework 13 mit 32 GB Speicher lasse ich Qwen 3.6 35B-A3B mit llama.cpp laufen und komme auf 15 tok/s.
    Es gibt Code und Text schneller aus, als ich lesen kann.

  • moezd: Noch nicht. Wenn man kein reines Apple-Setup oder keine ordentliche GPU hat, sind selbst mit viel RAM und vielen Threads nur etwa 30–50 tok/s drin, und das auch nur mit deaktiviertem Thinking.
    Ohne solche Optimierungen frisst das Modell bereitwillig MCP, Skills und Agent-Beschreibungen und man schaut gefühlt beim Trocknen von Farbe zu, bevor der erste Ausgabetoken erscheint.
    Beim lokalen Modell-Serving muss man jedes Token im Kontextfenster sparen, und das ist das genaue Gegenteil der Richtung, in die Claude/GPT/Copilot die Branche treiben.

    • amarshall: Thinking verändert die Ausgabegeschwindigkeit nicht. Die mediane Ausgabegeschwindigkeit von Anthropic-Modellen liegt ungefähr bei 40–60 t/s.

  • mitchell_h: Ich habe es versucht, aber das Kontextfenster war nicht groß genug.

    • coder543: Qwen3.6-27B unterstützt ein Kontextfenster von 1 Million Tokens.
      Natürlich braucht man Hardware, die ein solches Kontextfenster auch betreiben kann, und auf meinem DGX Spark benötigt das q4_k_xl-Modell mit vollständigem f16-KV-Cache etwa 100 GB Speicher.
    • lysace: Bei mir ähnlich. Meine RTX 4070 hat nur 12 GB, daher frage ich mich, ob 24/32 GB tatsächlich genug Verbesserung bringen, um wirklich nützlich zu sein.
    • deadbabe: Man muss einfach direkter prompten, statt es als offene Frage zu formulieren.

  • drnick1: Ich frage mich, was derzeit das beste Coding-Modell ist, das auf High-End-GPUs für Endverbraucher laufen kann.
    Falls man eine RTX 3090/4090 hat, würde mich auch interessieren, welchen Stack ihr empfehlen würdet. So eine Kombination wie Llama.cpp + OpenCode?

  • bijowo1676: Ich fand ein Setup interessant, bei dem man mit teuren Frontier-Modellen Markdown-Dokumente wie App-Spezifikationen, Produktanforderungen und Architektur schreibt und aktualisiert und dann günstigere oder lokale Modelle diese Spezifikationen umsetzen lässt.
    Markdown komprimiert Informationen besser als Hunderte von Source-Dateien und passt daher gut ins Kontextfenster, aber um die groben Kanten zu glätten, braucht es einen zweiten oder dritten Durchgang. Mich würde interessieren, ob das jemand so ausprobiert hat.

  • grmnygrmny2: Ich hatte ethische Vorbehalte gegen die Nutzung von Produkten von OpenAI oder Anthropic und war deshalb auch gegenüber der Einführung von LLMs selbst zurückhaltend.
    Lokale Modelle lösen für mich den Großteil dieser moralischen Vorbehalte, deshalb nutze ich sie seit etwa einem Monat für die Arbeit und für private Projekte. Meine Hardware sind Macs mit 32 GB sowie ein Gaming-PC mit einer 3080 mit 10 GB, daher ist bei verschiedenen Quantisierungen etwa Qwen3.6-35B-A3B das Limit, aber das reicht aus.
    Ich liege bei etwa 200–400 PP und 20–30 TG, und es hat etwas Zeit gebraucht zu lernen, wie man sie gut einsetzt. Bei manchen Aufgaben muss man sich darum kümmern oder die Richtung vorgeben, aber insgesamt ist es ziemlich nützlich.
    CC habe ich nie benutzt, daher kann ich nicht vergleichen, aber von Embedded C++ bis Vue taugt es als guter Assistent oder Pair Programmer. Es wäre schön, wenn ich 27B laufen lassen könnte, und gelegentlich gibt es Momente, in denen dieses Modell etwas fast zu verstehen scheint und es dann doch nicht schafft, aber das ist selten.
    Bei vielen Aufgaben spart es viel Zeit, und es war ziemlich gut darin, mit nur recht vagen Anweisungen Bugs tiefgehend zu untersuchen und zu beheben. Als Harness verwende ich einen Pi.