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 Frage hinter diesem Artikel: Wie viel davon könnte auf meiner eigenen Hardware laufen? Und was würde es kosten, in Geld, Speicher und Zeit?
Die Antwort gibt es hier mit Zahlen statt Bauchgefühl. Und gleich vorweg: Ü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 kein 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 knifflige Frage. Die lösen wir mit echten Zahlen ganz am Ende.
Und das 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.
Spiel ruhig jetzt schon damit. Der Rechner stellt zwei Maschinen nebeneinander an meinen echten Läufen: Was passt in den Speicher, wie schnell antwortet sie, 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 bedeuten, erklärt der Artikel gleich darunter. Alle Zahlen sind deterministische Schätzungen (kein Modell im Hintergrund), die Formeln stehen aufklappbar dabei. Der Rechner zeigt einzelne Läufe; das Gesamtbild eines ganzen Monats, alle Läufe zusammengezählt, steht live in meinem Token-Dashboard.
| 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. Bei den Selbstbau-Builds mit mehreren Grafikkarten zählt fürs Schreibtempo die Bandbreite einer Karte (die Modellschichten liegen verteilt, pro Token ist effektiv eine Karte aktiv), während sich der Speicher summiert und das Lesen/Prefill mit Abschlag über die Karten skaliert; Intels unreifere LLM-Software steckt bewusst als niedrigere Rechen- und Bündel-Werte drin. 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, erklärt fast jede spätere Tempo- und Speicherfrage. Das Wichtigste der Reihe nach.
Erst lädt das Modell, dann zerlegt es meine Frage. Das Modell ist eine mehrere Gigabyte große Datei (die Modellgewichte), die einmal in den Speicher geladen wird, das wird gleich wichtig. Meine Frage plus die angehängte Code-Datei werden dann in Tokens zerlegt: aus vierzehn Wörtern Frage werden mit Datei schnell ein paar tausend. Das alles zusammen ist die Eingabe.
Lesen und Schreiben sind zwei verschiedene Muskeln, und das entscheidet fast alles. Zuerst liest das Modell die ganze Eingabe ein (Prefill), erst danach tippt es Wort für Wort die Antwort (Decode). Lesen ist Überfliegen, viel Stoff auf einmal, das braucht Rechen-Muskeln. Schreiben geht Wort für Wort, und für jedes einzelne Wort muss das ganze Modell einmal durch den Speicher, da zählt das Speicher-Tempo (Speicherbandbreite), lokal fast immer der Flaschenhals. Diese zwei Muskeln sind bei verschiedenen Maschinen verschieden stark, im Rechner oben sind es die zwei kippenden Balken. (Das Denken ist kein dritter Schritt, sondern der Anfang des Schreibens; wie lange das Modell vordenkt, steuert die Effort-Einstellung, beim simplen Datum-Bug wäre viel davon nur Wartezeit.)
Aus einer Frage wird ein Agent. 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.
Beim echten Review laufen viele Agenten gleichzeitig. Für ein Code-Review jage ich nicht einen Agenten über mein Projekt, sondern fünf: Datenbank, Frontend, 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.
Mehr braucht es nicht, um jede Hardware-Frage in diesem Artikel selbst einzuordnen; den Datum-Bug rechnen wir am Ende durch. (Wo das Modell herkommt, was ein Wissens-Cutoff ist, wie es per Websuche oder eigenen Dokumenten an Neues kommt: steht im Glossar und in Teil 2. Über jedes unterstrichene Wort kannst du fahren und die Kurzfassung lesen.)
Erste konkrete Frage zu 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. Der solide Einstieg ist 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 es problemlos. Wer mehr Modell will, 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.
Und der Rest, in einem Satz. Fürs knifflige Nachdenken sind Magistral Small (24B) oder GLM-4.7-Flash kompakt und ordentlich; die Riesen wie Kimi K2.6 (1 Bio. Parameter) oder DeepSeek V4 spielen ganz oben mit, laufen aber faktisch nur über Cloud oder GPU-Cluster, „lokal" ist da ein dehnbarer Begriff.
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 darf es sein? Ein Modell wird über Quantisierung verkleinert: je weniger Bits pro Zahl, desto kleiner und schneller. Von voll 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? 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 bricht lokal ein. 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.
Diese rund 22 Prozentpunkte lassen sich lokal verkleinern, ohne ein größeres Modell zu kaufen: Du fragst nicht ein Modell, sondern einen Rat. Dieselbe Frage geht an zwei, drei verschiedene Modelle (etwa Devstral, Qwen3.6 und GLM), ihre Antworten werden gegeneinander geprüft. Verschiedene Modelle machen verschiedene Fehler: Wo eines selbstbewusst danebenliegt, fällt ein zweites mit anderer Trainingsbasis oft nicht auf denselben Trick herein. Der Preis ist mehr Speicher oder mehr Zeit. Für den Datum-Bug ist das Overkill, für „ist dieser Code wirklich sicher?" verdient er sich seinen Speicher. Wie man so einen Rat praktisch verdrahtet, steht in Teil 2.
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 fertige Maschinen, dazu als vierten Weg den Selbstbau mit mehreren Grafikkarten.
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 sie 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: in Deutschland je nach Hersteller ab ~3.569 € (Nvidias eigene Box ~5.100 €), die komplette Familie steht in der Tabelle unten. Haken: Große Modelle (70B) schreibt sie 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 mit 7B- bis 70B-Modellen gut (Backend über ROCm/Vulkan). Haken: Das Software-Ökosystem ist etwas dünner als bei Apple und Nvidia.
Es gibt einen vierten Weg, den die drei fertigen Boxen verschweigen: ein eigener Rechner, vollgesteckt mit mehreren Grafikkarten. Der Reiz ist der Speicher fürs Geld, VRAM satt ohne den Aufpreis einer fertigen Maschine. 2026 ringen hier zwei Karten um den Schreibtisch, und sie stehen für zwei gegensätzliche Philosophien.
Intel Arc Pro B70: das billige VRAM. 32 GB pro Karte für rund 1.200 €, 608 GB/s Bandbreite. Vier davon ergeben 128 GB für unter 5.000 € allein an Karten, konkurrenzlos günstig. Der Haken, und er ist der entscheidende: Intels Software-Ökosystem für KI (oneAPI, IPEX-LLM, SYCL) ist deutlich unreifer als Nvidias CUDA. In der Praxis heißt das langsameres Einlesen, weniger ausgereiftes Bündeln vieler Agenten und mehr Gefrickel beim Aufsetzen. Die Hardware ist gut, die Software bremst, und genau das ist der eigentliche Unterschied, nicht das Datenblatt.
Nvidia RTX 5090: die rohe Geschwindigkeit. Ebenfalls 32 GB pro Karte, aber mit 1.792 GB/s fast dreimal so viel Bandbreite wie die B70, dazu das ausgereifteste KI-Software-Ökosystem überhaupt. Dafür kostet sie in Deutschland ab rund 3.300 €, zieht 575 Watt pro Karte und bleibt bei 32 GB: für viel VRAM brauchst du viele teure Karten. Zwei sind brutal schnell, aber nur 64 GB, drei kosten mehr als ein gebrauchter 256-GB-Mac.
Und das, was im Preis gern vergessen wird: das Drumherum. Eine Grafikkarte ist noch keine Maschine. Für drei oder vier davon brauchst du ein Mainboard mit genug PCIe-Lanes, eine CPU, RAM, vor allem ein sehr dickes Netzteil (vier B70 ziehen rund 920 W, zwei 5090 schon 1.150 W, drei über 1.700 W), dazu Gehäuse oder offenes Frame, Kühlung, eine SSD und Riser-Kabel. Realistisch kommen 1.800 bis 2.400 € obendrauf, je nachdem ob du auf Consumer-Teilen mit Bifurcation baust oder workstation-sauber (Threadripper, ECC-RAM). Erst das ergibt den ehrlichen Preis:
| BuildVRAM gesamt | GrafikkartenStück × ab-Preis | + Drumherum | Gesamt ca. | Kurz |
|---|---|---|---|---|
| 3× Arc Pro B7096 GB | ~3.600 €3 × ~1.200 € | ~1.800 € | ~5.400 € | günstigster Weg zu 96 GB, aber Intel-Software |
| 4× Arc Pro B70128 GB | ~4.800 €4 × ~1.200 € | ~2.200 € | ~7.000 € | viel VRAM fürs Geld, hält das 16-Agenten-Review |
| 2× RTX 509064 GB | ~6.600 €2 × ~3.300 € | ~2.000 € | ~8.600 € | brutal schnell, aber nur 64 GB |
| 3× RTX 509096 GB | ~9.900 €3 × ~3.300 € | ~2.400 € | ~12.300 € | schnellste 96 GB, aber Preis & Strom brutal |
Alle vier Builds stehen jetzt oben im Rechner, neben Mac und Spark. Was er bestätigt: Beim Tempo einer einzelnen Antwort spielen die Karten-Builds vorn mit, die 5090 zieht dank ihrer Bandbreite sogar am Mac vorbei. Zwei Realitäten holen sie zurück. Erstens ist pro Token effektiv nur eine Karte aktiv (die Modellschichten liegen über die Karten verteilt), die Bandbreite summiert sich also nicht. Zweitens kostet bei Intel die unreife Software genau das, was auf dem Papier gut aussieht. Und der schwerste Lauf bleibt eine Speicherfrage: Drei B70 (96 GB) und drei 5090 (96 GB) platzen beide am 16-Agenten-Review (er braucht rund 104 GB), erst vier B70 (128 GB) oder eine 256-GB-Box fangen ihn auf. Das ist am Ende der Grund, warum bei mir eine fertige Box stand statt eines Karten-Stapels: ein Netzteil, kein Treiber-Gefrickel, fester Preis, und der Strom bleibt Rauschen statt Heizung.
Die DGX Spark gibt es nicht nur von Nvidia. Acht Hersteller (plus der Vertriebspartner PNY) bauen exakt dieselbe Box: gleicher GB10-Chip, gleiche 128 GB, praktisch gleiches Antwort-Tempo. Unterschiede gibt es nur bei Speicher, Kühlung, Preis und Verfügbarkeit. Wenn du dich für diese Klasse entscheidest, lohnt der Blick auf die ganze Familie, hier komplett für Deutschland (nach Preis sortiert):
| Hersteller · ModellVerfügbarkeit DE | DE-Preis abinkl. MwSt. | ✅ Stärke | ❌ Schwäche |
|---|---|---|---|
| ASUS · Ascent GX10breit lieferbar | €3.569 (1 TB)€4.760 (4 TB) | günstigster echter Einstieg, sehr leise | 1-TB-Basis nur Gen4-SSD, im Burst wärmer (~87 °C) |
| Gigabyte · AI TOP ATOMbreit lieferbar | €3.930 (1 TB)€4.153 (4 TB Gen5) | sofort da, Klick-Oberfläche statt Terminal, Gen5-SSD | heißeste CPU im Feld (90 °C), Lautstärke ungetestet |
| Dell · Pro Max with GB10lieferbar | €4.730 (2 TB)~€7.086 (4 TB) | bester Enterprise-Support, leichtester SSD-Tausch | 4 TB extrem teuer, nur Gen4-SSD (2 TB QLC) |
| Lenovo · ThinkStation PGX4 TB lieferbar, 1 TB meist vergriffen | €4.800 (4 TB)1 TB nominell ~€3.337 | günstige 1-TB-Option, Enterprise-Support | kaum Eigenprofil außer Marke, in DE teurer als US |
| Acer · Veriton GN100lieferbar | €4.889nur 4 TB | kühlste Box (74,7 °C), schnellste SSD | versiegelt (kein Upgrade), nur 4 TB, über UVP |
| HP · ZGX Nano G1nbreit lieferbar | ~€4.900 (2 TB)~€5.298 (4 TB) | leisester/kühlster OEM, Security-Stack (FIPS, EAL4+) | teuer, viel Kunststoff, hoher Idle-Verbrauch |
| PNY · DGX Sparklieferbar | ~€4.999nur 4 TB | baugleich zur Nvidia-Box, etwas günstiger | nur 4 TB, kein Eigenprofil |
| MSI · EdgeXpert MS-C931in DE kaum lieferbar (Wochen–Monate) | ~€5.0804 TB | beste Dauerlast-Kühlung, 5 Jahre Garantie | in DE schwer zu bekommen, lauteste Lüfter |
| Nvidia · DGX Spark (Founders Edition)lieferbar | ~€5.100nur 4 TB (Gen5) | Referenz-Software/-Support, Gen5-SSD | teuerste 4-TB-Option, kein günstiger Einstieg |
Weil der Chip überall derselbe ist, ist das Antwort-Tempo praktisch gleich; die Tabelle vergleicht nur, was sich real unterscheidet. Wer ohnehin im Terminal arbeitet, kann Gigabytes Klick-Oberfläche ignorieren, sie senkt nur die Einstiegshürde, macht das Gerät aber nicht schneller. Und die heißen 90 °C der Gigabyte-CPU sind ein Dauerlast-Thema, nicht der Alltag: kurz und unkritisch bei normalen Anfragen, relevant erst bei langen Batch-Läufen, wo die kühleren Boxen (Acer, HP) seltener drosseln.
Diese Geräteklasse ist jung (Marktstart Oktober 2025); die Punkte unten stammen aus NVIDIA-/Hersteller-Foren, Reviews und Nutzerberichten. Das Wichtigste: Die meisten ernsten Probleme sind plattformweit (gleicher GB10-Chip, gleiches DGX OS), nicht markenabhängig. Vollständig behobene Punkte sind bewusst weggelassen.
| Problem | Schwere | Häufigkeit | Status |
|---|---|---|---|
| Hard-Power-Off unter Dauerlast (Volllast → Abschalten nach ~60 s, kein Log) | 🔴 | Mehrfach | offen |
| 100-W-/PD-Throttling (GPU klemmt bei ~100 W statt 240 W) | 🔴 | Verbreitet (Launch) | teilw. gefixt |
| Bricking / Boot-Loop nach Firmware-/Treiber-Update | 🔴 | Verbreitet | teilw. gefixt |
| Software unreif (SM121: vLLM/NIM/FP8; NVFP4 war kaputt) | 🟠 | Alle Nutzer dieser Frameworks | teilw. gefixt |
| ConnectX-7 „200 Gbps" real ~200 gesamt (PCIe-x4); Drossel-Bugs auf 13/25 Gbps | 🟠 | Alle (Bauart) / Mehrfach (Bug) | strukturell / überw. gefixt |
| M.2-2242-SSD selten (Tausch = Garantieverlust), RAM verlötet, nur USB-C, HDMI-Sleep, ARM-Inkompatibilität | 🟡 | Alle (Bauart) | strukturell |
| RMA: kein Advance-Replacement (erst einschicken, dann Ersatz) | 🟠 | Alle (Policy) | strukturell |
Strategie gegen die Hitze-Themen: Wer die Box dauerhaft unter Volllast fährt, kann sie zusätzlich kühlen, das ist in den Foren der gängige Workaround: Gerät frei und erhöht aufstellen (Luft von unten), einen externen Lüfter davorstellen, im Extremfall die Wärmeleitpaste erneuern oder den GPU-Takt leicht begrenzen (per nvidia-smi). Das nimmt Throttling-Events und thermisch bedingten Abschaltungen die Spitze, behebt aber die offenen Firmware-Bugs nicht.
| Marke | Problem | Schwere | Häufigkeit | Status |
|---|---|---|---|---|
| Acer | Versiegelt → jeder Defekt = Voll-RMA | 🔴 | Alle (Bauart) | strukturell |
| Acer | DE-Support schwach + patentbedingter Support-Ausfall Jan–März '26 | 🟠 | DE-Käufer (temporär) | teilw. entspannt |
| Gigabyte | ConnectX-7-Hotplug → dauerhaft 25 Gbps | 🟠 | Einzelfall/wenige | offen |
| Gigabyte | Heißeste CPU (90 °C im Prefill) | 🟡 | Alle Gigabyte (Bauart) | by design |
| Gigabyte | Brick-Risiko beim Firmware-Update (dünne Doku) | 🟠 | Einzelfälle | offen |
| ASUS | Throttling-Events im Stresstest (96 → 76 W) | 🟡 | Test-Befund (1 Gerät) | by design |
| ASUS | „Avoid ASUS GX10"-Support-Drama (4 tote ConnectX) | 🟠 | Einzelfall | offen |
| ASUS | 30-W-Safety-Mode (PD-Firmware) → RMA | 🔴 | Einzelfall | RMA, nicht heilbar |
| MSI | Lauteste Lüfter im Vergleich | 🟡 | Alle MSI (Bauart) | by design |
| MSI | In DE kaum lieferbar (Wochen–Monate) | 🟠 | Alle DE-Käufer | offen |
| Lenovo | Headless-Firmware-Update schlägt fehl (ohne Monitor) | 🟠 | Mehrfach (Testgeräte) | offen |
| Lenovo | 1-TB-Variante in DE oft nicht lieferbar | 🟡 | Verbreitet | wechselnd |
| Dell | Gen4-SSD (2 TB QLC) + wärmste Box im Prefill | 🟡 | Alle Dell (Bauart) | by design |
| NVIDIA/PNY | Keine Power-LED an der Founders Edition | 🟡 | Alle FE | by design |
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. Ein Selbstbau mit mehreren Grafikkarten spielt in einer anderen Liga: vier B70 ziehen rund 920 Watt, drei 5090 über 1.700 Watt. Da werden aus dem Rauschen schnell mehrere hundert Euro im Jahr, plus spürbare Abwärme und Lüfterlärm. Die drei fertigen Boxen 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 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 und Hardware stehen. Zwei Rollen fehlen noch, und sie werden gern verwechselt: Wer startet das Modell (die Inferenz-Maschine, von Ollama für den bequemen Einstieg bis vLLM für Durchsatz auf dem Server), und wer die Rolle übernimmt, die bei mir bisher Claude Code spielt, also Dateien öffnen, sich selbst prüfen, den Bug autonom jagen (das tun Werkzeuge wie Cline oder Aider, denn Claude Code selbst läuft nicht auf beliebigen lokalen Modellen). Wie diese Teile zusammenstecken, ist das ganze Thema von Teil 2. Hier zählt nur der eine Satz, an dem die Hardware-Frage hängt.
Es gibt zwei Tempo-Fragen, nicht eine. Die erste ist die Latenz: wie schnell kommt eine Antwort. Da gewinnt die höchste Speicherbandbreite, also der Mac. Die zweite ist der Durchsatz: wie viele Tokens pro Sekunde das System insgesamt schafft, wenn viele Agenten gleichzeitig laufen. Und hier passiert das Erstaunliche: Bündelt man die Anfragen (Continuous Batching), werden die Modellgewichte einmal gelesen und auf alle Agenten gleichzeitig angewandt: der Bandbreiten-Flaschenhals verschwindet, jetzt zählt die rohe Rechenleistung, und da hat die DGX Spark viel Wumms. (Nur der KV-Cache jedes Agenten muss weiter einzeln gelesen werden und bremst bei langen Kontexten.) Genau dieses Kippen, schnelle Einzelantwort gegen hohen Gesamt-Durchsatz, spielst du im Rechner ganz oben durch.
Jetzt zahlt der Datum-Bug sich aus: Der Rechner steht ganz oben, hier liest du, was er zeigt, und ziehst das Fazit.
Klick 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 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. Mein Verbrauch entspricht zu API-Preisen rund 8.600 $ im Monat (gemessen, live in meinem Token-Dashboard), 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 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. Genau das ist mein Fall: Mein Verbrauch sieht so aus, und ich erwarte nicht, dass das günstige Flat-Abo ewig hält. Fällt es weg, wird aus dem Gegenwert eine echte Rechnung, und dann will ich die Box schon stehen haben, statt sie erst zu bestellen.
Und die Maschinen-Frage. Willst du schnell eine Antwort, 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.
Und ich? Mein Alltag ist selten die eine schnelle Antwort, öfter der Schwarm: ein Code-Review wirft sechzehn Agenten gleichzeitig aufs Projekt, Welle um Welle. Genau der Lauf, bei dem oben im Rechner die rechenstarke Spark am Mac vorbeizieht. Also wurde es eine Spark, und zwar die günstigste echte Einstiegsbox aus der Tabelle oben: die ASUS Ascent GX10 (rund 3.569 €, leise, breit lieferbar). Mit offenen Augen, wohlgemerkt: Die jungen Firmware-Themen aus „Bekannte Probleme" gelten auch für sie, und die Spitzen-Cloud-Qualität holt sie nicht ein. Der Grund für den Kauf ist trotzdem nicht das Geld, gegen mein Flat-Abo spart sie nichts, sondern das, was kein Tempo-Balken zeigt: Daten, die den Schreibtisch nicht verlassen, und ein Werkzeug, das mir gehört statt es zu mieten, und das schon steht, wenn das günstige Flat-Abo eines Tages kippt.