Heute Morgen ist mir ein kleiner Fehler aufgefallen: In meinem Buchungs-Formular wird das Datum falsch angezeigt. Normalerweise tippe ich dann einen Satz in Claude Code, „schau dir die Datei an und finde den Fehler", und ein paar Sekunden später habe ich die Antwort. Was ich dabei selten bedenke: Dieser Satz reist über fremde Server in einem Rechenzentrum. Die ehrliche Frage hinter diesem Artikel: Wie viel davon könnte auf meiner eigenen Hardware laufen, in den eigenen vier Wänden? Und was würde es kosten, in Geld, Speicher und Zeit?
Die Antwort gibt es hier mit Zahlen statt Bauchgefühl. Und gleich vorweg, ehrlich: Überraschend viel läuft lokal richtig gut. Die schwersten Läufe, die großen Multi-Agenten-Reviews, stoßen im Juni 2026 an klare Grenzen. Wo genau, kannst du gleich selbst durchrechnen, am selben Datum-Bug, mit dem wir hier anfangen.
Bleiben wir kurz beim Datum-Bug. Damit das Modell ihn findet, schicke ich ihm meinen echten Buchungs-Code, und in dem stecken Kundendaten, Tabellenstrukturen, halbe Geschäftslogik. Genau hier liegt der erste von drei Gründen.
Datenschutz und Souveränität. Bei einem lokalen Modell verlässt kein einziges Token meinen Rechner. Kein Kundencode, keine Bewerbungsunterlage, kein Vertragsentwurf wandert über fremde Server. Für alles Vertrauliche ist das nicht ein nettes Extra, sondern das Argument.
Kontrolle und Unabhängigkeit. Das Modell ändert sich nicht über Nacht unter dir weg, es wird nicht abgekündigt, es gibt keine Tageslimits, und im Zweifel läuft es auch ohne Internet. Du besitzt das Werkzeug, statt es zu mieten.
Kosten pro Aufruf. Nach dem Kauf der Hardware kostet jede Anfrage nichts mehr: keine Abrechnung pro Token, nur etwas Strom. Ob sich das gegen die Cloud rechnet, ist eine überraschend zwiespältige Frage. Die lösen wir mit echten Zahlen ganz am Ende.
Und das ehrliche Gegenargument: reine Leistung. Die besten Cloud-Modelle sind den besten lokalen Modellen im Juni 2026 noch ein gutes Stück voraus, besonders bei langen, kniffligen Aufgaben mit vielen Schritten. „Lokal" heißt nicht „dasselbe, nur umsonst". Es heißt: vieles davon, auf eigenen Bedingungen. Genau diese Grenze macht dieser Artikel nachrechenbar.
Bevor wir zum Wie kommen, spiel ruhig jetzt schon damit. Dieser Rechner vergleicht zwei Maschinen nebeneinander an meinen echten Läufen: Was passt überhaupt in den Speicher, wie schnell antwortet die Maschine, wie nah kommt die Qualität an die Cloud. Stell zwei Geräte ein, wähl einen Lauf, schau, was sich ändert. Was Lesen, Schreiben und Speicher dabei bedeuten, erklärt der Artikel gleich darunter Schritt für Schritt. Die Engine ist rein deterministisch (kein Modell im Hintergrund), alle Zahlen sind Schätzungen, die Formeln stehen aufklappbar dabei.
| A | B |
|---|
Speicher = Gewichte (einmal) + Agenten × KV-Cache. Schreibtempo ≈ 0,85 × Bandbreite ÷ (aktive Gewichte + Overhead). Lesetempo ∝ Rechenleistung ÷ aktive Modellgröße (bei MoE zählen die aktiven Experten, nicht die Gesamtgröße). Durchsatz = Schreibtempo × gebündelte Agenten (begrenzt durch die Rechenleistung) × Kopplungsfaktor. Gesamtzeit = Einlesen aller Agenten (in Bündeln) + Schreiben aller Agenten. Qualität = Modell-Können − Quant-Abschlag + Effort-Bonus, gegen die Cloud-Lücke gewichtet mit der Schwierigkeit des Laufs. Vereinfachungen: die Bündel-Größe ist pro Maschine pauschal angesetzt (real hängt sie auch am Modell), und der Mehr-Geräte-Bonus ist eher optimistisch, mehrere Geräte helfen vor allem, große Modelle reinzubekommen, weniger beim Tempo. Keine gemessenen Benchmarks, eine ehrliche Einordnung.
Ich tippe meinem lokalen Modell also denselben Satz, „schau dir die Datei an und finde den Fehler", und drücke Enter. Was in den nächsten Sekunden in meinem Rechner passiert, ist eigentlich die ganze Geschichte dieses Themas. Sie hat fünf Stationen, und fast jede Tempo- oder Speicherfrage später hängt an genau einer davon.
1. Bevor ich überhaupt tippe, muss das Modell schon da sein. Monate vorher hat ein Hersteller es im Rechenzentrum trainiert: Es hat sich wochenlang durch riesige Textmengen gearbeitet und dabei seine Milliarden Parameter justiert. Das passiert einmal. Übrig bleibt eine mehrere Gigabyte große Datei, die Modellgewichte, die ich mir einmal heruntergeladen habe. Ein Detail, das gleich wichtig wird: Was nach dem Trainings-Stichtag passierte, weiß es nicht (Wissens-Cutoff). Meine Code-Datei von heute Morgen sieht es nur, weil ich sie ihm mitgebe, per Websuche oder aus eigenen Dokumenten (RAG).
2. Mein Satz ist für den Rechner kein Satz. Er wird in Tokens zerlegt, grob ein Wortteil pro Stück. Und es zählt nicht nur meine Frage: Ich hänge ja die Code-Datei mit an, und die wird genauso zu Tokens: Aus vierzehn Wörtern Frage werden mit Datei schnell ein paar tausend Token. Alles zusammen ist die Eingabe.
3. Jetzt das Wichtigste, und es sind zwei getrennte Schritte. Zuerst liest das Modell alles ein, was ich ihm hingelegt habe (Prefill). Erst danach fängt es an zu tippen, Wort für Wort (Decode). Und hier kommt der Satz, an dem später jede Tempo-Frage hängt: Lesen und Schreiben werden von zwei völlig verschiedenen Dingen ausgebremst. Eselsbrücke: Lesen ist Überfliegen, viel Stoff auf einmal, das braucht Rechen-Muskeln. Schreiben ist Wort für Wort, da zählt, wie schnell der Speicher nachliefert (Speicherbandbreite). Letzteres ist lokal fast immer der Flaschenhals, denn für jedes einzelne Wort der Antwort muss das gesamte Modell einmal komplett durch den Speicher gelesen werden. Schnellerer Speicher heißt direkt mehr Wörter pro Sekunde. Diese zwei Muskeln (Rechnen fürs Lesen, Speicher-Tempo fürs Schreiben) sind bei verschiedenen Maschinen verschieden stark; im Rechner ganz oben zeigen wir sie als zwei kippende Balken. Und wo steckt das Denken? Es ist kein dritter Schritt, sondern der Anfang des Schreibens: Hat das Modell gelesen, denkt es zuerst still vor sich hin und tippt erst danach die eigentliche Antwort: Beides ist Decode, beides zählt voll mit. Wie lange es vorab denkt, steuert die Effort-Einstellung: mehr Effort heißt mehr Vordenken (bessere Antworten bei harten Aufgaben, aber mehr Zeit und mehr Speicher). Bei unserem simplen Datum-Bug wäre viel Effort nur Wartezeit.
4. Mit einer Antwort ist es nicht getan. Mein Werkzeug gibt sich mit „liegt vermutlich an Zeile 40" nicht zufrieden: Es öffnet die Datei, liest die Stelle, prüft seine eigene Vermutung, schaut in eine zweite Datei nach, wo das Datum herkommt. Aus der einen Frage ist ein Agent geworden: Er fragt das Modell nicht einmal, sondern dutzende Male hintereinander, und schleppt bei jedem Schritt den ganzen bisherigen Verlauf mit. Der Kontext wächst: Das Prefill wird länger (das nächste Wort kommt später), und der Notizzettel, den das Modell beim Schreiben anlegt (KV-Cache), wächst mit und frisst zusätzlichen Speicher. Ein Agent wird im Verlauf also eher langsamer, nicht schneller.
5. Und jetzt der letzte Sprung. Bei einem echten Code-Review jage ich nicht einen Agenten über mein Projekt, sondern fünf gleichzeitig: einen für die Datenbank, einen fürs Frontend, einen für die Sicherheit. Hier sitzt der Denkfehler, den fast jeder macht: Jeder Agent hat sein eigenes Kontextfenster, aber die Modellgewichte liegen nur EINMAL im Speicher. Fünf Agenten laden nicht fünfmal das Modell. Was sich summiert, ist allein der KV-Cache pro Agent. Lokal ist damit der Speicher die geteilte Ressource, in der Cloud sind es die Kosten. Gute Agenten-Architektur gibt deshalb jedem Agenten ein frisches, kleines Fenster und reicht nur Zusammenfassungen weiter, statt alles in ein Riesenfenster zu stopfen.
Das ist das ganze Bild im Kopf. Wer es einmal hat, kann jede Hardware-Frage selbst einordnen. Und unseren Datum-Bug treffen wir am Ende wieder, wenn wir ausrechnen, was so ein Lauf wirklich kostet. Die Einzelbegriffe stehen ausführlich im Glossar, und im ganzen Text kannst du über jedes unterstrichene Wort fahren, um die Kurzfassung zu sehen.
Erste konkrete Frage an unserem Bug: Welches Modell findet ihn überhaupt? Es gibt nicht „das beste lokale Modell", es gibt das beste für deinen Zweck und für deine Hardware. Drei Fragen entscheiden fast alles: Programmieren, Bilder verstehen, kniffliges Nachdenken.
Programmieren, unser Fall. Für den Einstieg auf einer einzelnen Grafikkarte oder einem Mac mit 32 GB: Devstral Small 2 (24 Mrd. Parameter, freie Apache-2.0-Lizenz, rund 68 % auf dem Coding-Test SWE-bench Verified). Den Datum-Bug (eine Datei, klarer Auftrag) findet das problemlos. Wer mehr Speicher hat (Mac ab 64 GB), nimmt Qwen3.6-35B-A3B: ein Experten-Mix mit 35 Mrd. Parametern gesamt, aber nur rund 3 Mrd. aktiv pro Token, schnell und mit ~73 % eines der stärksten offenen Coding-Modelle. (Zwei Stolperfallen: Mistrals Devstral ist die Coding-Linie, Magistral die Reasoning-Linie; und das ältere Qwen3.5-35B-A3B ist nicht dasselbe Modell.)
Bilder & Screenshots. Hänge ich statt der Code-Datei einen Screenshot vom kaputten Formular an, braucht das Modell „Augen". Lokal stark: Qwen2.5-VL-72B (bzw. der Nachfolger Qwen3-VL) und InternVL3-78B. Die Speicher-Realität: In voller Genauigkeit brauchen die 144–160 GB; auf einen 128-GB-Rechner passen sie nur quantisiert, und das am Limit. Kleinere Seh-Modelle gibt es, aber sie lesen dichte Oberflächen wie einen Backend-Screenshot merklich ungenauer. Das wird in Teil 5 zur eigentlichen Qualitätsfrage, nicht nur zum Tempo.
Kniffliges Nachdenken. Magistral Small (24B, zeigt seine Gedankenkette offen) oder GLM-4.7-Flash (ein Experten-Mix mit 30 Mrd. gesamt, nur 3 Mrd. aktiv): kompakt und trotzdem ordentlich im mehrschrittigen Schließen.
Die ganz Großen, als Ausblick, nicht als Alltag. Modelle wie Kimi K2.6 (offene Gewichte, 1 Billion Parameter gesamt, ~32 Mrd. aktiv) oder DeepSeek V4 spielen ganz oben mit. Aber ehrlich: Die volle DeepSeek-V4-Variante läuft faktisch nur über die Cloud oder einen GPU-Cluster; nur die kleinere V4-Flash (284 Mrd. / 13 Mrd. aktiv) läuft auf einer High-End-Workstation. „Lokal" ist hier ein dehnbarer Begriff, das gehört dazugesagt, sonst klingt es größer, als es ist.
dense vs. Experten-Mix: warum „35B" nicht gleich „35B" ist. Ein dichtes Modell rechnet bei jedem Wort mit allen Parametern. Ein Experten-Mix besteht aus vielen Experten, von denen pro Wort nur ein paar aktiv sind. Folge: Qwen3.6 muss zwar mit 35 Mrd. Parametern komplett in den Speicher (wie ein großes Modell), rechnet aber pro Wort nur mit ~3 Mrd. (schnell wie ein kleines). Genau das macht MoE-Modelle zum lokalen Liebling: viel Können bei gutem Tempo, wenn der Speicher reicht.
Das 10-Millionen-Kontextfenster (mit Sternchen). Manche Modelle werben mit gigantischen Kontextfenstern, Llama 4 Scout etwa mit zehn Millionen Tokens. Technisch stimmt das. Praktisch nutzen kannst du es auf normaler Hardware aber nicht: Den KV-Cache für so ein Fenster komplett zu füllen, bräuchte nicht hundert Gigabyte extra, sondern Terabyte. Große Kontext-Zahlen sind ein Speicher-Versprechen, kein Gratis-Feature.
Die Bit-Frage: wie klein darfst du gehen? Ein Modell wird über Quantisierung verkleinert: je weniger Bits pro Zahl, desto kleiner und schneller. Von genau nach kompakt: FP16 (volle Genauigkeit) → FP8 → INT8 → 6-Bit → INT4. Für Privatrechner ist Q4 bis Q5 der gängige beste Kompromiss: Das Format Q4_K_M und die GPU-Variante AWQ liegen nur grob 1–3 % über dem Qualitätsmaß (Perplexität) der vollen Version, bei rund 70–75 % weniger Größe.
Wie nah an Claude Code? (ehrlich) Auf demselben Coding-Test steht es Mitte 2026 grob so: das beste Consumer-lokale Modell bei ~73 %, ein Spitzen-Cloud-Modell wie Claude Fable 5 bei 95 %. Das sind rund 22 Prozentpunkte, eine echte Lücke, die bei langen, mehrschrittigen Aufgaben mit vielen Dateien spürbar zubeißt. (Wirft man Kimi K2.6 auf einen Multi-GPU-Server, schrumpft sie auf etwa 15 Punkte, aber das ist kein Schreibtisch-Setup mehr.) Wichtig zum Einordnen: SWE-bench misst genau die schweren, vielschrittigen Fälle, dort reißt lokal ab. Eine einzelne klare Datei wie unseren Datum-Bug lösen beide Klassen zuverlässig. Was das für deine konkreten Läufe heißt, rechnen wir in Teil 5 nach.
Die rund 22 Prozentpunkte, die das beste lokale Modell auf dem Coding-Test hinter einem Spitzen-Cloud-Modell wie Fable 5 liegt, lassen sich lokal verkleinern, ohne ein größeres Modell zu kaufen, indem du nicht einem Modell vertraust, sondern einen Rat befragst. Dieselbe Frage geht an zwei, drei verschiedene lokale Modelle (etwa Devstral, Qwen3.6 und GLM), und ihre Antworten werden gegeneinander geprüft. Sind sie sich einig, ist das ein starkes Signal; widersprechen sie sich, ist genau das die heikle Stelle, die ein Mensch oder ein vierter „Schiedsrichter"-Lauf anschaut.
Warum das trägt: Verschiedene Modelle machen verschiedene Fehler. Wo eines selbstbewusst danebenliegt, fällt ein zweites mit anderer Trainingsbasis oft nicht auf denselben Trick herein. Drei mittelgroße Modelle, die sich gegenseitig korrigieren, holen einen Teil dessen zurück, was ein einzelnes großes Cloud-Modell von Haus aus kann, ohne dass ein einziges Token den Rechner verlässt.
Der ehrliche Preis: Ein Rat kostet mehr Speicher oder mehr Zeit (die Modelle laufen neben- oder nacheinander), und die wirklich langen, vielschrittigen Aufgaben rettet auch er nicht ganz. Die Auswertung bleibt simpel und regelbasiert, die Mehrheit zählt; kein zusätzliches Modell entscheidet heimlich mit. Für unseren Datum-Bug ist das Overkill. Für die Frage „ist dieser Code wirklich sicher?" verdient der Rat sich seinen Speicher.
Devstral findet unseren Bug. Aber wie schnell tippt die Maschine die Antwort, und passt überhaupt das Modell rein, das ich brauche? Das entscheidet die Hardware, über drei Größen: Speicherbandbreite (Tempo beim Antworten), Speichermenge (wie groß darf das Modell sein) und Preis. Für einen anspruchsvollen Einzelnutzer gibt es Mitte 2026 drei realistische Maschinen.
Mac Studio M3 Ultra: die Bandbreiten- und Speicher-Maschine. Mit Abstand die höchste Speicherbandbreite (819 GB/s) und bis zu 256 GB vereinheitlichter Speicher, dazu das ausgereifteste Software-Ökosystem (Apples MLX). Preis: ab ~3.999 $ für die 96-GB-Basis. Haken, und der ist 2026 gravierend: Wegen der Speicher-Knappheit hat Apple erst die 512-GB-Option (Anfang 2026), dann auch die 256-GB-Konfiguration (Mai 2026) ganz aus dem Store genommen. Neu bei Apple bekommst du den M3 Ultra derzeit nur noch mit 96 GB. Die 256-GB-Variante (zuletzt ~5.999 $ / ~6.849 €) gibt es nur noch gebraucht: auf eBay mit dickem Knappheits-Aufschlag, in Deutschland real eher 9.000–11.000 €.
Nvidia DGX Spark: der kompakte KI-Desktop. GB10-Chip, 128 GB vereinheitlicht, real rund 220–260 GB/s (die 273 GB/s auf dem Datenblatt erreicht er im Alltag nicht ganz): also langsamer im Antworten als der Mac, dafür dank dicker Rechenleistung stark beim Prefill (Einlesen) und zu mehreren Geräten koppelbar. Preis: ~4.699 $. Haken: Große Modelle (70B) schreibt er nur zäh.
Framework Desktop (AMD „Strix Halo"): der Preis-Leistungs-Sieger. Ryzen-AI-Max-Chip, 128 GB, real rund 215 GB/s, ab ~1.999 $, also rund halb so teuer wie die DGX Spark. Leise, läuft 7B- bis 70B-Modelle gut (Backend über ROCm/Vulkan). Haken: Das Software-Ökosystem ist etwas dünner als bei Apple und Nvidia.
Mehrere Geräte verbinden, und die „ein großes vs. zwei kleine"-Frage. Man kann Maschinen koppeln, um ihren Speicher zu bündeln. Der Haken ist physikalisch: Die Verbindung zwischen den Geräten ist viel langsamer als der Speicher innerhalb eines Geräts. Fürs Tempo einer einzelnen Antwort bringt das darum fast nichts: In einem realen Test stieg ein großes Modell von 19,5 auf 26,2 Tokens/Sekunde beim Sprung von einem auf zwei Geräte (und auf 31,9 bei vier), nicht aufs Doppelte oder Vierfache. Für eine einzelne Anfrage gewinnt also ein großes System bei Tempo, Kosten und Einfachheit. Ob das beim Gesamt-Durchsatz vieler gleichzeitiger Agenten anders aussieht, ist eine ganz andere Frage. Die heben wir uns für Teil 5 auf.
Strom, Wärme, Lärm. Unter echter KI-Last ziehen beide Maschinen mehr, als man denkt: der Mac Studio rund 160–180 Watt, die DGX Spark rund 170–200 Watt (System, nicht nur der Chip). In Deutschland sind das grob 100–250 Euro Stromkosten im Jahr, gegen eine Cloud-Rechnung praktisch Rauschen. Alle drei Maschinen sind leise genug für den Schreibtisch.
Lohnt sich der Kauf überhaupt? Die Rechnung ist im Prinzip einfach: einmalig rund 2.000–6.000 $ Hardware plus 100–250 Euro Strom im Jahr gegen eine laufende Cloud-Rechnung. Aber welche Cloud-Zahl ist überhaupt der faire Vergleich: das Abo, das du zahlst, oder der API-Gegenwert dessen, was du tatsächlich verbrauchst? Genau da wird es interessant. Die ehrliche Rechnung mit echten Zahlen steht in Teil 5.
Ausblick (Gerüchteküche, bewusst als Gerücht markiert). Erwartet, aber nicht bestätigt: ein M5 Ultra Mac Studio im Herbst 2026 (Leaks nennen über 1.000 GB/s; ob er bei 256 GB bleibt oder wieder bis 512 GB geht, ist umstritten) und eine kleinere Consumer-Variante des Spark-Chips. Alles Gerüchteküche, kein Grund, deshalb mit dem Einstieg zu warten, wenn du es jetzt brauchst. (Den M5 Ultra kannst du im Rechner oben übrigens als spekulativen Schalter ausprobieren.)
Modell ausgewählt, Hardware steht. Aber zwei Fragen sind noch offen, und sie werden gern verwechselt: Wer startet das Modell eigentlich, und wer übernimmt die Rolle, die bei mir bisher Claude Code spielt, also die Datei zu öffnen, sich selbst zu prüfen und den Datum-Bug autonom zu jagen?
Wer das Modell laufen lässt: die Inferenz-Maschine. Das ist die Software, die die Modellgewichte in den Speicher lädt und ausführt. Ollama ist die einfachste (ein Befehl, und es läuft). llama.cpp ist schlank und läuft sogar auf der reinen CPU. LM Studio legt eine Oberfläche zum Klicken darüber. Auf einem Mac ist MLX (Apples eigenes Framework) bei kleineren Modellen das schnellste. Und vLLM ist die Maschine für Durchsatz auf einem Server.
Der Satz, auf den später alles ankommt: Es gibt zwei Tempo-Fragen, nicht eine. Die erste ist die Latenz: wie schnell kommt eine Antwort. Da gewinnt die Maschine mit der höchsten Speicherbandbreite, also der Mac. Die zweite ist der Durchsatz: wie viele Tokens pro Sekunde schafft das System insgesamt, wenn viele Agenten gleichzeitig laufen. Und hier passiert etwas Erstaunliches: Bündelt man viele Anfragen (Continuous Batching), werden die Modellgewichte einmal aus dem Speicher gelesen und auf alle Agenten gleichzeitig angewandt. Für diesen Teil der Arbeit verschwindet der Bandbreiten-Flaschenhals, jetzt zählt die rohe Rechenleistung, und da hat eine Maschine wie die DGX Spark viel Wumms. (Ganz fair muss man sagen: Das gilt für die Gewichte, nicht für den KV-Cache jedes Agenten, der muss weiter pro Agent gelesen werden und bremst bei langen Kontexten. Aber der Effekt ist real und groß.) Genau dieses Bündeln ist es, was vLLM (Continuous Batching plus PagedAttention) am vollständigsten herausholt, llama.cpp kann es ansatzweise, Ollama am wenigsten. Die Software verändert hier also die Zahlen, nicht nur den Komfort.
Wer den Agenten steuert: der ehrliche Knackpunkt. Claude Code selbst läuft nicht auf beliebigen lokalen Modellen. Was an seine Stelle tritt: Cline (in VS Code), Aider (im Terminal), OpenHands oder das anbieter-unabhängige OpenCode. Die öffnen Dateien, rufen das lokale Modell in der Schleife auf und prüfen Ergebnisse. Den Datum-Bug bekommt Cline mit Devstral lokal sauber hin. Der eigentliche Stolperstein kommt erst, wenn viele solche Agenten zuverlässig zusammenarbeiten müssen. Genau das kannst du im Rechner ganz oben durchspielen.
Jetzt zahlt der Datum-Bug sich aus: Der Rechner steht ganz oben, hier liest du, was er zeigt, und ziehst das ehrliche Fazit.
Spiel dich oben durch; hier die Reise in Worten. Bei der Einzelfrage (unser Datum-Bug) tippt der Mac die Antwort drei- bis viermal schneller als die Spark. Lokal fühlt sich das fast wie die Cloud an. Auch die Agenten-Schleife bleibt klar Mac-Terrain. Beim Recherche-Lauf mit vier parallelen Agenten wird es enger: Beim Einlesen der vielen Quellen ist die Spark plötzlich vorn. Und beim Code-Review mit sechzehn Agenten passieren zwei Dinge auf einmal. Erstens entscheidet nicht mehr das Tempo, sondern der Speicher: Auf 96 GB platzen die sechzehn KV-Caches, auf 256 GB passt es. Zweitens kippt hier die Durchsatz-Frage: Werden alle sechzehn Agenten gebündelt, holt die rechenstarke Spark beim Gesamt-Durchsatz auf und zieht am Mac vorbei, während der Mac bei der einzelnen Antwort schneller bleibt. Zwei verschiedene Sieger, je nachdem, was du misst.
Dann der UX-Review mit hundert und mehr Screenshots: Hier zeigt sich die andere Stärke der Spark. Der Mac kaut minutenlang an der Bild-Wand, während die Spark sie deutlich schneller einliest (in einem gemessenen Text-Vergleich rund 3,8-mal so schnell, bei Bildern in derselben Größenordnung); in der Vergleichstabelle dreht sich beim Lesetempo das Bild deutlich um. Der Haken: Das Seh-Modell mit so vielen Screenshots sprengt den 128-GB-Speicher einer einzelnen Spark. Erst eine 256-GB-Maschine oder zwei gekoppelte Sparks fangen das auf. Und schließlich die ehrliche Spitze: Tempo gewonnen heißt nicht fertig. Das kleinere Seh-Modell liest dichte Oberflächen ungenauer, und der eigentliche Stolperstein bleibt, viele Agenten überhaupt zuverlässig zu orchestrieren. Schnell ist nicht gleich gut ist nicht gleich erledigt.
Die Geld-Frage, ehrlich. Mein Verbrauch entspricht zu API-Preisen rund 8.000 $ im Monat, bezahlen tue ich 200 $ über ein Flat-Abo, also etwa das Vierzigfache seines Preises an Rechenleistung. Was heißt das für lokale Hardware? Ein Mac Studio mit 256 GB kostete zuletzt rund 6.000 $ Listenpreis, nur bekommt man ihn neu kaum noch (Apple hat die Variante 2026 wegen der Speicher-Knappheit gestrichen, gebraucht zahlst du eher 10.000 €). Selbst gegen die 200 $, die ich real zahle, rechnet sich das erst nach vielen Jahren, und die Spitzen-Cloud-Qualität erreicht die Kiste trotzdem nicht. Gegen den 8.000-$-API-Gegenwert wäre sie in gut einem Monat bezahlt. Beide Zahlen stimmen; welche gilt, hängt daran, ob du sonst Flat oder pro Token zahlen würdest. Fast alle zahlen Flat, darum ist der ehrliche Grund für lokal Datenschutz und Kontrolle, nicht das Geld. Es sei denn, dein Verbrauch sähe aus wie meiner und es gäbe die Flatrate nicht.
Und die Maschinen-Frage. Willst du auf eine Antwort schnell warten, kauf Bandbreite (Mac). Willst du zwanzig Agenten parallel durchjagen, kauf Rechenleistung (Spark). Zwei verschiedene Käufe, und fast jeder Vergleichstest misst nur den ersten. Über beidem die dritte Frage, die kein Tempo-Balken beantwortet: gut genug? Bei einer klaren Datei ja, bei einem dichten Vision-Review noch nicht ganz. Der pragmatischste Ausweg ist heute oft gar keine Hardware-Frage: viele kleine Läufe statt einem Riesen-Bündel, genau das, was mein auto-wave-Workflow tut, der jede Welle als frischen, kleinen Lauf startet, statt alles in ein Riesenfenster zu stopfen.