Lokales Qwen ist kein schlechteres Opus, sondern ein anderes Werkzeug
(blog.alexellis.io)- Lokales Qwen 3.6 27B liefert praktischen Nutzen bei Aufgaben, die sich schwer in die Cloud hochladen lassen, etwa Kundendaten und interne Telemetrie, ersetzt aber keine Cloud-SOTA-Modelle
- Die Stärke lokaler Modelle liegt nicht im Punktevergleich mit den besten Modellen, sondern in Fixkosten, Datenschutz und der Reduzierung von Vendor-Risiken; besonders deutlich wird das bei hoher Nutzung und internen SaaS-Funktionen
- Auf SWE-Bench Verified erreicht Qwen 3.6 27B 77,2 Punkte, Claude Opus 4.8 liegt bei 88,6 %; die Behauptung, „lokal liegt nur 12 % hinter SOTA“, ignoriert die Möglichkeit des Benchmark-Tunings und Unterschiede zu realen Domänen wie Go
- Die für etwa 12.000 US-Dollar angeschaffte RTX 6000 Pro Blackwell 96GB hat ihre Kosten allein durch einen Fall von Revenue Recovery wieder eingespielt, bei dem unterberichtete Kundenlizenzen gefunden wurden
- Die größte Einschränkung ist das Loop-Problem mit wiederholten Ausgaben und Halluzinationen bei langen Aufgaben; lokales Qwen eignet sich daher eher für Kundensupport, eng abgegrenzte Wartung sowie das Lesen und Erklären von Codebasen als für langfristiges unbeaufsichtigtes Coding
Hintergrund zur AI-Nutzung und zum Geschäftskontext
- Das Team betreibt, ausgehend von OpenFaaS, mit SlicerVM, Actuated, Inlets und weiteren Produkten ein Portfolio rund um Low-Level-Infrastruktur und Linux-Primitiven
- Es basiert auf Containern, Firecracker microVM, Netzwerkprotokollen, Tunneln, CLI und Kubernetes, wird überwiegend in Go geschrieben und enthält teilweise React-UIs
- AI-Tools werden schon seit den Zeiten der automatischen VS Code-Tab-Vervollständigung genutzt; heute entsteht der Großteil des Codes mit Claude oder Codex, manuelles Coding findet kaum noch statt
- Um Arbeitsabläufe mit langen Sessions in tmux zu steuern, wurde Superterm.dev entwickelt; es dient dem Management von Sessions und Notizen sowie dem visuellen Feedback von Coding-Agenten
Wendepunkt bei Frontier-Intelligenz
- Zwischen November 2025 und Januar 2026 kam es zu einem Wendepunkt; viele Entwickler auf X bewerteten Claude Opus so, dass es ihre gesamte Arbeit übernehmen kann
- Die Kosten für Top-Coding-Pläne haben sich für Einzelpersonen bei rund 200 USD pro Monat eingependelt; solange übermäßige unbeaufsichtigte Arbeit vermieden wird, reicht das innerhalb der Limits von 5 Stunden und pro Woche aus
Warum lokale Modelle interessant sind
- 2026 ist eine Zeit, in der praktisch jeder mit nur einem Abo eine Idee über Nacht kopieren kann; auch SlicerVM und Superterm wurden bereits geklont
- In einem Markt, in dem sich die Softwarekosten gegen null bewegen, kann „kostenlos und gut genug“ entscheidend werden
- Führende Modelle werden auf 0,5–2T Parameter geschätzt, also in einer völlig anderen Größenordnung als selbst High-End-lokale Hardware
-
Benchmaxxing
- Benchmarks sind öffentlich und lassen sich daher auf hohe Scores hin tunen, was sie als absolute Kennzahl fragwürdig macht
- SWE-Bench Verified basiert auf Python-Issues, bei denen der meiste Code Single-Threaded und synchron ist; verteilte Go-Systeme arbeiten dagegen mit channels, context und struct über große Ausführungsbereiche hinweg
- Aus reinen Benchmark-Scores lässt sich daher kaum ableiten, dass „lokal nur 12 % hinter SOTA liegt“; in realer Arbeit entscheiden Sprach- und Systemeigenschaften oft maßgeblich über Erfolg oder Misserfolg
-
Kosten (Cost)
- Die Aussage „Lokale Modelle sind kein Kostenproblem“ trifft nicht auf alle Nutzer zu
- Ein persönlicher Coding-Plan für 200 Dollar im Monat liefert hohe Nutzung und Intelligenz auf SOTA-Niveau, scheint aber strukturell subventioniert zu sein
- GitHub Copilot bot früher für 39 Dollar im Monat 1.500 Anfragen und wechselte später zu tokenbasierter Abrechnung, was starke Gegenreaktionen auslöste
- Bei Abrechnung über API-Tokens kann der Break-even schnell erreicht sein
- Uber begrenzt AI-Ausgaben auf 1.500 Dollar pro Monat und Entwickler pro Tool
- Beim Uber-Median-Gehalt von 330.000 Dollar entspräche es rund 12 % des Jahresgehalts, wenn ein Entwickler zwei Tools jeweils bis zum Limit nutzt
- Bei hoher Nutzung, Loops, Agenten-Analysen und eingebetteten SaaS-Funktionen liefern Open-Weight- und lokale Modelle erheblichen Wert
-
Souveränität und Privatsphäre (Sovereignty and privacy)
- Aufgrund von Kundendaten und Vertragsbedingungen gibt es Fälle, in denen Daten nicht in einen Cloud-Plan hochgeladen werden können
- ChatGPT Pro und Claude Max lassen sich auf eine Aufbewahrungsfrist von 30 Tagen einstellen, doch selbst dieses Niveau könnte Kundenverträge aus Sicht des Autors verletzen
- Dass Anthropics Fable-5-Modell für Nutzer außerhalb der USA über Nacht entfernt wurde, wirkt als Vendor-Risiko
- Lokale Modelle sind eine Antwort auf die Frage: „Was, wenn ein Frontier-Lab X tut?“
Die Analogie zum Klingenschmieden — das Wesen lokaler Modelle
- Wie bei der Wärmebehandlung von Stahl, bei der man bei einem einzigen Fehltritt von vorn beginnen muss, gilt auch für lokale Modelle: Wenn sie zu heiß laufen, schießen sie über das Ziel hinaus und landen in Loops
- Die einzige Lösung ist, den Harness zu beenden und mit geleertem Context auf ein anderes Ergebnis zu hoffen
- So wie man das Schmieden einer Klinge nicht unbeaufsichtigt laufen lässt, wird Qwen 3.6 27B nicht mit Aufgaben mit langem Horizont betraut
-
Wonach ich gesucht habe (What I was looking for)
- Das Ziel waren Privatsphäre, Fixkosten und Absicherung gegen Vendor-Risiken
- Enttäuschung entstand, wenn lokale Modelle wie Claude oder Codex behandelt wurden
- Claude arbeitet mit kurzen Anweisungen wie „do it and test it end to end“ in einem effizienten Loop aus PR-Erstellung, automatischem Code-Review und Iteration innerhalb von 5–15 Minuten
Erkenntnisse mit der 3090
- 2023 begann alles mit einer einzelnen 3090; für Modell-Load und ausreichend Context war eine zweite Karte nötig
- Qwen 3.5 war der erste Zeitpunkt, an dem man einen Agenten wirklich produktiv arbeiten sah
- Auf die Anweisung „Untersuche die Maschine aus allen Blickwinkeln und schreibe einen Forensik-Bericht“ las das Modell jede Datei einzeln, füllte damit den Context und halluzinierte Dateinamen und Tool-Calls (
~/faas-netes→~/faaned)- Wurde der Aufgabenbereich auf „schau dich kurz um“ verengt, erzeugte es mit etwa 40–50 tok/s einen klaren Bericht
- Ein 27B-Modell passt nicht in voller Präzision auf eine einzelne 3090; Stellschrauben sind daher Gewichtsquantisierung, Context-Länge und KV-Cache-Kompression
- Als gängige Auffassung gilt, dass es beim Keys-Teil des KV-Caches mit Q4_0 Probleme gibt; selbst aggressiv wurde nur keys Q8_0 / values Q4_0 genutzt
- Auch bei Experimenten mit vLLM + NVLink + tensor parallelism war die Generierung 3 Token pro Sekunde langsamer als mit llama.cpp; dazu kamen Loops und mehrminütige Ladezeiten der Gewichte
- vLLM eignet sich für groß angelegtes paralleles Serving, doch im Prosumer-Umfeld sind Startzeit, Einfachheit und Single-User-Latenz wichtiger
Große Ausgabe — Einführung der RTX 6000 Pro
- Um Support-Tickets schneller zu lösen, wurde eine RTX 6000 Pro Blackwell (96GB VRAM) für etwa 12.000 USD gekauft
- Später stieg der Preis auf etwa 15.400 USD, wodurch eine zweite Karte schwer zu rechtfertigen war
- Wegen PCI-Lanes, Bandbreite, Kartenabstand und PSU-Last lässt sie sich nicht einfach in eine Consumer-Maschine nachrüsten
- Es war eine kalkulierte Wette mit Ergebnis, ersetzt aber kein Claude-Abo
Einfacher Kundensupport ohne Datenabfluss
- Es wurde das leicht nutzbare CLI-Tool „diag“ gebaut, das einen vollständigen Snapshot einer OpenFaaS-Kubernetes-Installation aufnimmt
- Der empfangene Dump wird in einer von Slicer erzeugten airgapped lokalen Modellumgebung in einer ephemeral VM analysiert
-
Revenue Recovery
- Durch Einspeisen einer Telemetrie-Datenbank in das lokale Modell wurde bei einem Kunden eine über 12 Monate laufende Unterberichterstattung von Lizenzen mit dem 4- bis 5-Fachen an Außenständen entdeckt; allein diese Rückgewinnung deckte die Kosten der Karte
- Telemetrie und diag-Dumps werden unabhängig von Aufbewahrungsrichtlinien in keinen Cloud-Plan eingespeist
- ChatGPT Pro und Claude Max erlauben zwar eine 30-Tage-Aufbewahrungseinstellung, doch auch das könnte Kundenverträge verletzen
- Frühe Modelle scheiterten an Arithmetik (27,3K wurde zu 273.000) und stuften häufige Ausführung bei geringer Funktionszahl fälschlich als Churn-Risiko ein
- Insgesamt funktioniert es besser, das Modell auf Analyse statt Interpretation zu fokussieren
Aktuelles Setup
- Auf dem RTX-6000-Rig laufen die neueste Qwopus-Generation und das Basis-Qwen 3.6 27B parallel; das Setup ändert sich mit neuen Finetunes und Point-Releases
- Qwopus ist ein auf Qwen aufbauendes Finetuning, das mit Chain-of-Thought-Tracking die Inferenz- und Coding-Leistung verbessern soll
- Bis vor Kurzem lief das Setup mit vollständig deaktiviertem thinking; das erneute Aktivieren fiel zeitlich mit mehr Loops zusammen
- Es wird über zwei unabhängige llama.cpp-Instanzen serviert, um die volle Context-Länge zu erhalten;
--parallel 2halbiert den Context - Beim Speculative Decoding (MTP) liegt die Akzeptanzrate bei rund 93 %, die Geschwindigkeit stieg von stabilen 67 tok/s auf 130–200 tok/s und fühlt sich damit schneller als die Cloud an
- Wichtig ist, die Tuning-Hinweise der Model Card zu befolgen; Qwopus läuft optimal mit deaktiviertem thinking und sehr hoher Temperatur von 0,85–1,0
Wiederholte Ausgaben und die Grenzen langer Aufgaben
- Das größte Problem von Qwen ist die Tendenz, bei Aufgaben mit großem Umfang in Loops zu geraten
- Auf die Frage nach einem zusätzlichen Befehl für
faas-climachte es zunächst vernünftige Vorschläge, wiederholte dann aber dieselbe Befehlsliste und verbrauchte dabei etwa 30 Minuten lang 600W Leistung - Auch beim Hinzufügen von
--jsonzu allenget- undlist-Befehlen wirkten die ersten ein bis zwei Änderungen noch plausibel und wurden sogar getestet, danach eskalierte das Problem - Als es für die
--json-Ausgabe einen Python-Reverse-Proxy bauen sollte, um insecure-TLS-Warnungen beihttp://-Remote-Endpunkten zu vermeiden, war die erste Version noch brauchbar, hatte aber falsche Einrückungen; beim Nachbessern beschädigte das Modell die Datei und blieb dann wiederholt stecken - Auch Teammitglied Han erlebte ähnliche Loops, insbesondere wenn Modell oder Agent an der Leistungsgrenze verharrten, ohne um Hilfe zu bitten
- Deshalb ist lokales Qwen außerhalb von Kundensupport und Telemetrie-/diag-Analysen für Verlängerungen nur schwer vertrauenswürdig
Zugriff messen und verteilen
- Anfangs wurde ein einzelner inlets-Tunnel genutzt; wenn zwei Agenten an dieselbe llama.cpp-Instanz gingen, invalidierten ihre gecachten Prefixes einander, wodurch der gesamte Prompt neu verarbeitet werden musste
- Mit mehreren Nutzern verlässt das Ganze schnell den Prototypenstatus; es entstehen Managementfragen dazu, wer welche Instanz wie lange mit welchem Modell nutzt, was Strom kostet und wie mit Churn umzugehen ist
- Statt
opencode.jsonmanuell zu bearbeiten und zu verteilen, wurde mit „Toilgate“ ein Provider für opencode geschrieben, über dessen Model Picker sich von der Basis bis zu experimentellen Qwopus-Varianten wählen lässt- Toilgate ist zu 100 % vibe-coded, eine Open-Source-Veröffentlichung wäre aufwendig
- Der Stromverbrauch wird mit zwei Shelly Plus Plug 2 an der Steckdose gemessen; die RTX 6000 Pro zieht bei Inferenz 600W und bleibt leise, zwei 3090 zusammen etwa 750W und sind sehr laut
-
Der falsche Vergleich (The wrong comparison)
- Die Ein- und Ausgabekosten pro Million Token mit den API-Preisen von GPT-5.5 zu vergleichen, ist angesichts der aktuellen Fähigkeiten der falsche Vergleich
- „Lokale AI“ läuft am Ende auf ein Betriebsproblem hinaus, das Identität, Access Control, Metering, Quotas, Model Routing und Stromüberwachung benötigt
Nutzungsmuster, die tatsächlich geholfen haben
- Es ist wichtig, das lokale Modell und den Harness auf spezialisierte Aufgaben zuzuschneiden
- Kundensupport
- Wartung mit klar definiertem Umfang
- End-to-End-Tests
- Wenn in
AGENTS.mddetaillierte Anweisungen ergänzt wurden, konnte das lokale Modell neue CLI-Funktionen schneller und effizienter hinzufügen und selbst testen- Dieser Effekt zeigte sich bei alexellis/arkade
- Auch wenn das lokale Modell beim direkten Schreiben von Code Grenzen hat, ist es stark darin, Codebasen schnell zu lesen und zu erklären
- Auch Agent Skills waren hilfreich; es gab etwa einen Fall, in dem ein lokaler Agent Slicer auf einem neuen Mini-PC von Grund auf eingerichtet hat
- Es sollte allgemeiner werden, dieselbe Aufgabe sowohl lokal als auch mit einem Cloud-Modell auszuführen
- Wie beim Vergleich derselben Aufgabe sind die Ergebnisse manchmal enttäuschend und manchmal überraschend gut
- Lange, unbeaufsichtigte Agentenarbeit mit großem Horizont sollte vermieden werden; selbst Hardware für fast 15.000 Dollar löst dieses Problem nicht
Aktuelles Fazit und Grenzen bei der Modellauswahl
- Lokales Qwen ist weniger „nahe an Opus-Niveau“ als vielmehr ein anderes Werkzeug, das in bestimmten Aufgaben und Workflows Wert liefert
- Qwen 3.5 gilt als das erste Modell, das brauchbare Ergebnisse lieferte; zu 3.7 gibt es Gerüchte, erwartet werden aber eher inkrementelle Verbesserungen als eine Revolution
- 70B-Modelle gelten größtenteils als alt und generationell zurückliegend
- Qwen 35-A3B ist beliebt, weil es auf einem MacBook schnell wirkt, doch da bei der Generierung nur 3B Parameter aktiv sind, wird hier Qualität gegenüber Geschwindigkeit bevorzugt
- Größere Modelle wie GLM 5.2, Kimi 2.7, Minimax M3 oder Deepseek V4 Flash sind auf mancher lokaler Hardware prinzipiell möglich, liegen aber meist außerhalb des Rahmens, weil selbst quantisierte Varianten oft 4–6 RTX 6000 Pro zum Laden brauchen
- Das heutige dichte 27B-Modell reicht nicht aus, um den ganzen Tag Go-Code zu schreiben; seine begrenzten Kenntnisse und seine begrenzte Aufmerksamkeit werden im Code-Review schnell sichtbar
- Qwen folgt Anweisungen zur Knappheit nicht besonders gut und schreibt in automatischem Code-Review unnötig ausführlich oder halluziniert Concurrency-Probleme und race conditions, wodurch Experimente schnell abgebrochen werden
- Das günstigere und schnellere Grok Coder Fast 1 funktionierte einige Monate lang gut, bis es deprecated wurde
- Verwandte Beispiele sind im code review bot und bei OpenFaaS's painless customer support and architecture review dokumentiert
1 Kommentare
Hacker-News-Kommentare
Wenn man diese Modelle lange genug benutzt, merkt man, dass es nicht einfach nur darum geht, dass „X schlauer als Y“ ist oder „Y billiger als Z“. Es sind unterschiedliche Werkzeuge, und auch die Prompting-Ansätze unterscheiden sich, fast wie beim Spielen eines Instruments
Bei Claude muss man manchmal absichtlich weniger explizit oder indirekter formulieren, um der Umsetzung mehr Farbe zu geben oder kreative Ergebnisse hervorzulocken. Und so seltsam es klingt: Wenn man freundlich zu Claude ist, wird man dafür belohnt, und wenn man grob ist, hat man eher Nachteile. Claude übernimmt den Ton stärker, daher ist es besser, nicht in eine negative Schleife zu geraten
Bei GPT muss man präzise sein und Mehrdeutigkeiten reduzieren. GPT versucht Unklarheiten oft mit einer Minimax-Logik à la „Ich mache X, aber nicht Y“ aufzulösen; wenn man den Umfang nicht klar eingrenzt, neigt es dazu, alle Grenzfälle abdecken zu wollen und übermäßig zu entwerfen
Qwen muss man eine Form geben, die es dann ausfüllen kann. Qwen mag XML, JSON und Listen und funktioniert gut, wenn man viele Beispiele früherer Aufgaben zeigt. Das ist überhaupt nicht wissenschaftlich, nur mein Eindruck, also können die Ergebnisse abweichen
Aber oberflächlich sehen sie alle ähnlich aus, und um herauszufinden, was wo ein bisschen besser ist, muss man selbst umfangreiche, zeitaufwendige und womöglich teure Tests durchführen
Ich empfehle das allen: Man braucht keine speziellen Daten außer denen, die man ohnehin schon benutzt, und die Ergebnisse sind ziemlich schockierend. Es gibt weit mehr Zufälligkeit oder Instabilität, als man denkt, und was man für bessere Prompt-Techniken oder für besonders gute oder schlechte Ergebnisse hält, kann einfach Zufall sein oder an Verhaltensunterschieden zwischen Modellversionen und -größen liegen. Kleine Unterschiede in der Eingabe können die Ergebnisse stark verzerren. In der Firma nennen wir manches davon magische Wörter: Schon das Erwähnen bestimmter Fachbegriffe oder Referenzen bzw. Techniken verbessert die Ergebnisse deutlich
Dahinter steckt eine Technik. In einer Agenten-Schleife wird das Modell in eine Selbstevaluationsstruktur gebracht, in der es schwerer ist zu tricksen oder Abkürzungen zu nehmen, und wenn das zu den gelernten Strukturen oder dem Bereich passt, funktioniert es sehr gut. Aber den Sweet Spot zu finden ist schwierig. Ein Tipp: Wenn man Opus 4.8 bittet, ein PyTorch-Modell in ONNX oder ein quantisiertes Modell umzuwandeln oder es auf anderer Hardware laufen zu lassen, ist es darin so gut, als hätte man eine Spezialfähigkeit eingeschaltet. Dagegen schaffe ich es absolut nicht, es ohne Tricks eine EBNF-Formalisierung für allgemeine Sprachen oder Formate korrekt schreiben und testen zu lassen
Das Schlimmste ist, dass sich dieses Wissen viel zu häufig ändert, sodass es kaum Nutzen hat, tief einzusteigen, wenn man nicht selbst die Modelle trainiert. Ich wünschte, die Stabilität der Ausgaben würde im Training stärker betont, damit das Verhalten berechenbarer wird. Das ist wohl schwer hinzubekommen, ohne Overfitting oder den Explore-Exploit-Loop zu ruinieren, aber wenn sich Batch-Jobs damit stabiler ausführen ließen, würde ich viel mehr Geld für LLMs ausgeben
Bei derselben Anfrage an Claude Sonnet 4.6 kam ein Ergebnis heraus, als wäre das Spiel von Anfang an in JS geschrieben worden. Außerdem machte es daraus aus irgendeinem Grund eine einzelne HTML-Datei, entfernte alle Assets, erzeugte Grafik und Musik dynamisch und baute sogar einen besseren neuen Hintergrund ein
Ich hatte nur darum gebeten, das Spiel zu portieren, also war ich überrascht. Mir gefiel die Entscheidung eigentlich ziemlich gut, aber ich weiß nicht, wie man dieses Verhalten ein- oder ausschaltet. Manchmal braucht man Kreativität, und manchmal will man, dass einfach genau das getan wird, was man gesagt hat
Bei diesem Artikel und all dem Lob dafür habe ich das Gefühl von des Kaisers neuen Kleidern. Schon dieser Satz ergibt keinen Sinn
“These products use very low level Linux primitives like containers, Kubernetes, Firecracker microVMs, and networked protocols.”
Von den Dingen, die man als „Low-Level-Linux-Primitiven“ bezeichnen könnte, lässt sich höchstens bei Netzwerkprotokollen irgendwie argumentieren. Und es wirkt eindeutig wie ein KI-generierter Text. Wenn man dem Inhalt vertrauen könnte, wäre das egal, aber das kann man nicht
Der Text ist nicht KI-generiert; den Code generiere ich mit KI, aber den Text schreibe ich selbst. Mich würde interessieren, welcher Teil unverständlich ist. Dieser Text beschreibt unsere eigenen Erfahrungen und unseren Weg, und bei konkreten Behauptungen kann ich gern Belege liefern
Ich bin nach wie vor überzeugt, dass die Stärke von KI letztlich nicht darin liegt, ein weiterer Cloud-Service zu sein, für den man endlos zahlen muss und der mit der Zeit nur schlechter wird, weil er die Gier von Unternehmensaktionären bedienen soll, sondern dann zum Tragen kommt, wenn sie lokal, sicher und privat eingesetzt wird.
Ich würde ChatGPT oder Anthropic zwar niemals meine Gesundheitsdaten an ihre Systeme binden lassen, aber ich glaube weiterhin an die Fähigkeit von KI, Datenmuster zu erkennen, die ich übersehen würde. Deshalb braucht es dringend ein rein lokales Ökosystem, in dem Daten Dingen wie Qwen oder Gemma sicher und privat zur Verarbeitung offengelegt werden können.
Für Smart Home und persönliche Assistenten gilt das genauso. Der unternehmerische Ansatz, bei dem Firma A auf bei Firma B gespeicherte Daten zugreift, Firmen D und E sie verarbeiten und sie dann an Werbekunden und Datenbroker verkauft werden, ohne dass ich sie jemals auf meiner lokalen Hardware extrahieren oder einsehen kann, ist für solche privaten Anwendungsfälle nicht nachhaltig. Meine Daten sollten zu meinen Bedingungen besessen, kontrolliert und offengelegt werden und zuerst dazu dienen, mein Leben zu verbessern, statt die Gewinn-und-Verlust-Rechnung anderer zu verbessern. Ich will, dass Technologie mir wieder Zeit zurückgibt und Ergebnisse verbessert, und nachdem ich oft genug von Big Tech enttäuscht wurde, lehne ich die Annahme entschieden ab, dass im AI-as-a-Service-Geschäftsmodell irgendetwas Edles oder Gemeinwohlorientiertes steckt.
Die Fähigkeiten sind bereits da, und ich denke, die Leute, die lokale Tools bauen, welche das Potenzial lokaler Modelle unterstützen und freilegen, sind auf dem richtigen Weg. Es ist schön zu sehen, was sie bauen.
Wenn man Modelle wie Qwen oder DeepSeek verwendet, kann man zwischen unabhängigen Anbietern wechseln, statt an ein einzelnes Unternehmen gebunden zu sein, und dabei möglicherweise bessere Datenschutzgarantien erhalten. So lassen sich Modelle auch auf Geräten nutzen, die sie nicht selbst ausführen können, solange eine Internetverbindung besteht.
Die Stärke von KI liegt in Open-Source-Modellen. Man sollte Modelle nutzen, die Vendor Lock-in vermeiden und sowohl lokale Nutzung als auch Hosting durch unabhängige Anbieter erlauben.
Guter Beitrag. Ich glaube nur, dass er das Verbesserungspotenzial unterschätzt.
Die Autoren räumen selbst ein, dass ein Vergleich lokaler Modelle von vor einem Jahr mit heute wenig Sinn ergibt. Tatsächlich sehen viele Menschen erst im vergangenen November mit Opus 4.5, also vor 8 Monaten, den Zeitpunkt, an dem Agentic Coding auch bei Frontier-Hosting-Modellen breit praktikabel wurde.
Warum sollte man also ausgerechnet jetzt das Bild davon festschreiben, was lokale Modelle gut können und was nicht? In einem Jahr wird das bei praktisch allem vermutlich anders aussehen. Es mag naiver Optimismus sein zu glauben, dass auf Consumer- und Profi-Hardware sogar Aufgaben über lange Kontexte hinweg möglich werden, aber bisher gewinnen die naiven Optimisten.
Es ist ähnlich wie beim Kauf eines Autos. Man fährt dieses Auto und gewöhnt sich an seine Eigenschaften, statt darüber nachzudenken, wie sich dieses oder ein ähnliches Auto künftig verbessern wird. Es ist mein Werkzeug, und ich möchte das Maximum daraus herausholen.
Natürlich sind die technischen Kosten für einen Wechsel des lokalen Modells sehr gering, aber es kostet dennoch erheblich Zeit, aus einem Modell die Maximalleistung herauszuholen, und dieser Aufwand funktioniert bei einer neuen Version womöglich nicht mehr.
Interessanter Beitrag. Ich persönlich hätte mir gewünscht, dass der Autor zwei Dinge besser macht.
Erstens hätte er statt llama.cpp vLLM verwenden sollen. Auf NVIDIA-Hardware ist der Unterschied bei Lasten mehrerer Nutzer und beim Caching mit vLLM enorm. An den Stellen, an denen sich darüber beschwert wurde, dass mehrere Nutzer das Modell verwenden oder der Cache verschwindet, dachte ich nur: „Ja, natürlich.“
Zweitens hätte sich das Budget für die einzelne Karte bei SPARK deutlich besser einsetzen lassen. Man könnte ein 2-x-GX10-Cluster nutzen; die Gesamtkosten liegen selbst heute noch unter der Hälfte dessen, was der Autor bezahlt hat, und darauf laufen vLLM und Deepseek v4 Flash. Im Vergleich zu Qwen ist der Unterschied gewaltig. Ich habe noch nie gesehen, dass es in Schleifen hängen bleibt, und von allem, was ich bisher getestet habe, ist es am ehesten Sonnet-ähnlich. antirez scheint dem zuzustimmen, denn offenbar hat er deshalb den ds4-Fork erstellt.
Wie es auf 2 GX10 eingerichtet wurde, steht hier: https://forums.developer.nvidia.com/t/deepseek-v4-flash-offi...
Die Leistung liegt beim Prefill bei 2K Token/s, was sehr nützlich ist, wenn man große Mengen Quellcode in riesige Kontextfenster lädt, und beim Coden im pi.dev-Harness bei etwa 50–60 Token/s Generierung. Für das Geld, das der Autor ausgegeben hat, hätte man 4 GX10 kaufen können, und vLLM skaliert bei Tensor-Parallelisierung nahezu linear, sodass sich beide Werte hätten verdoppeln lassen.
Vielleicht probiere ich später noch mehr damit aus, aber ich habe nicht unendlich viel Zeit zum Herumspielen und wollte einfach meinen bisherigen Weg und mein Urteil teilen.
Für gleichzeitiges Batch-Serving ist vLLM die richtige Wahl, und barrkel hat unten genau recht. Aber für unsere Art der Nutzung ist llama.cpp weiterhin besser.
Der Spark-/GX10-Weg ist wirklich eine ganz andere Wette, und danke fürs Teilen der Zahlen. Vor ein paar Monaten war die allgemeine Stimmung noch, dass GX10 nur etwas für Fine-Tuning sei und die Leistungswerte ernsthaft schlecht wären.
Und die Karte wurde überhaupt nicht gekauft, um ein Claude-Max-Abo zu ersetzen. Bei den Aufgaben, für die sie tatsächlich gekauft wurde, liefert sie 140–200 Token/s, und darauf kommt es an.
Der Beitrag war lang, aber ich weiß immer noch nicht, worauf der Autor eigentlich hinauswill. Abgesehen von dem, was sich aus dem Titel erschließen lässt.
Ich habe nur mitgenommen, dass der Autor ziemlich cool ist, weil er sowohl physische Dinge als auch Software baut, und dass andere Leute ihm dafür sogar Geld geben. Ob das mit dem Thema zu tun hat, das der Titel andeutet, weiß ich nicht.
Dieser Beitrag fasst lokale Modelle gut zusammen. Anders als die Übertreibung, sie seien manchmal fantastische Werkzeuge für lokale Coding- und Agenten-Arbeit, sind sie in der Realität ziemlich eingeschränkt, schwach bei langen oder komplexen Aufgaben und neigen dazu, in Schleifen zu geraten oder Aufgaben zu vergessen
Was im Beitrag fehlt: Auch die Kosten sind recht hoch. Nicht nur die Hardware kostet, sondern auch der Strom. Eine 3090- oder 5090-Maschine verbraucht viel Energie, und weil Modelle auf solchen Maschinen ziemlich langsam sind, ist auch der Stromverbrauch pro Token höher
Die Stärke liegt in Kontrollierbarkeit, Datenschutz und Vorhersagbarkeit. Für wiederkehrende Aufgaben wie etwa das Sortieren von Foto- und Videobibliotheken ist das zum Beispiel gut, und je nach Strompreis kann es auch kostenseitig Vorteile geben
Tool Calling muss zu 99 % zuverlässig sein, und vor allem muss es sagen können: „Diese Aufgabe liegt außerhalb meiner Fähigkeiten“, und sie dann an ein leistungsstarkes Online-Modell irgendwo in einem riesigen Datacenter weiterreichen
Dann würde das Gerät alle einfachen Aufgaben lokal erledigen, dabei Daten sammeln und den Problemkontext verstehen, und nachdem das Einfache erledigt ist, kommt ein klügeres Modell dazu und löst das Problem
Dass für eine
/commit-Fähigkeit, die ein lokales Modell zu 100 % beherrscht, ein Online-Modell aufgerufen wird, fühlt sich wirklich dumm an. Das ist allerdings größtenteils ein Harness-Problem und zu großen Teilen lösbarEs funktioniert sehr gut, und auch bei Coding-Aufgaben ist es großartig, wenn man weiß, wie man es einsetzt, statt ihm gleich einen riesigen Plan komplett hinzuwerfen
Ich weiß nicht, wie das im Vergleich zu anderem dasteht, aber ich vermute, dass eine 5090 bei derselben Leistungsbegrenzung schneller und damit etwas günstiger wäre
Ich fand interessant, dass vLLM als langsamer als llama.cpp abgetan wurde
Meiner Erfahrung nach ist vLLM deutlich schneller als llama.cpp und vor allem bei Batch-Verarbeitung unter gleichzeitiger Last überlegen. Der Nachteil ist die drastisch geringere Flexibilität bei der Feinabstimmung. Es gibt nur sehr wenige Optionen, quantisierte Gewichte auszuführen, und weil der Rechengraph optimiert wird, dauert der Start viel länger. Wenn also ein einzelner Nutzer ein im Verhältnis zur Hardware etwas zu großes Modell testet, kann sich vLLM frustrierend anfühlen
„Abgetan“ ist ein starkes Wort, aber genauer gesagt dauerte das Laden auf einem 2x-3090-System mehr als 4 Minuten, und bei einer einzelnen Anfrage war es 3 Token/s langsamer
Das Schlimmste war, dass ich mir trotz des ganzen Aufwands für Setup und Tuning immer noch Schleifen eingefangen habe. Ich hatte gehofft, der oft gehörte Rat „Nimm einfach vLLM“ wäre eine Universallösung
Worauf man hier achten muss: Wir dürfen nicht anfangen, llama.cpp schlechtzureden, so wie manche es bei Ollama getan haben. llama.cpp ist ein sehr fähiges Werkzeug und für den Zweck, für den wir diese Karten tatsächlich nutzen wollen, besser geeignet
Wenn ein großes Team ein Claude-Abonnement ersetzen will, ist vLLM vielleicht die einzige Wahl, aber um etwas wie GLM 5.2 hochzufahren, müsste man wohl noch etwa fünf RTX 6000-Karten dazustellen
Zuerst heißt es, „das Modell läuft zu heiß, schießt über das Ziel hinaus und gerät in Schleifen“, und später dann, vLLM sei als neuestes Experiment eingerichtet worden, sei aber selbst mit NVLink und Tensor Parallelism bei der Generierung 3 Token/s langsamer als llama.cpp gewesen
In all meinen Tests hat es sich gelohnt, vLLM zu betreiben. Es war der einzelne Faktor, der am meisten gegen Schleifenprobleme, seltsam werdende Agenten, Verlust der Aufgabenfokussierung und praktisch unbrauchbar werdende lange Kontexte geholfen hat
Wenn man in vLLM FP8-Modelle und einen nicht quantisierten Cache verwendet, ist das Gesamterlebnis eine Stufe besser als mit jedem anderen Stack. Danach kann man aufhören, ständig an den Einstellungen herumzuschrauben, und sich darauf konzentrieren, das Modell für andere Dinge zu nutzen
Und ich frage mich auch, ob du das Gefühl hast, dass vLLM auf diese Weise erst ab einer gewissen Mindesthardware sinnvoll wird. Ich plane als Wochenendprojekt einen Home-Inference-Server aus alten Datacenter-Teilen und feile gedanklich noch ständig an der endgültigen Konfiguration
Allen, die ihre eigene AI-Hardware kaufen und bauen möchten, würde ich empfehlen, sich zuerst mit einem der verschiedenen Inference-Provider zu verbinden und eine Zeit lang selbst unterschiedliche Modelle auszuprobieren
Das kostet fast nichts, gibt aber eine ziemlich gute Vorschau darauf, was man mit eigener Hardware herausholen kann. Nur ein gut gemeinter Tipp