9.2 KiB
Hardware für lokales Vibe-Coding & lokale KI
Stand: 2026-04-26 Status: Plan beschlossen, Umsetzung läuft (Verkauf Alt-GPUs → MacBook Pro M5 Max 128 GB)
1 — Entscheidung in einem Satz
Eine einzige Maschine für lokales Vibe-Coding mit großen Modellen (Qwen 3.6 Coder, GLM, Devstral, Kimi-Coder etc.): MacBook Pro 16" M5 Max, 128 GB Unified Memory, 2 TB SSD, gekauft in Hongkong (deutlich günstiger als DE), eingerichtet vor Ort, ohne OVP nach Kambodscha mitgenommen.
Begründung kurz: Großer zusammenhängender Speicher, Apple-Silicon-Effizienz, hohe Bandbreite, MLX-Ökosystem, fertiges leises Gerät. Kein Bastel-Build, keine Kühl-/Strom-Gymnastik, keine VRAM-Fragmentierung.
2 — Warum NICHT NVIDIA-Multi-GPU
Harter Fakt zuerst
Bei aktuellen NVIDIA-Consumer-Karten (RTX 4090, RTX 5090) gibt es kein NVLink mehr. Das heißt:
- 2× RTX 5090 = 2× 32 GB getrennter VRAM, NICHT 64 GB Unified.
- Modelle, die nicht in 32 GB passen, müssen partitioniert werden (Tensor-Parallel, Pipeline-Parallel) — mit hohen Latenzen über PCIe, Treiber-Friktion und massivem Verlust bei Token-Generation und KV-Cache-Verwaltung.
- Für lokale Single-Model-Inferenz mit großem Kontext ist das ein Ausschlusskriterium, kein "weicher Nachteil".
Vollkostenrechnung 2× RTX 5090 (DE-Preise, realistisch 2026)
| Posten | Preis (€) |
|---|---|
| 2× RTX 5090 | 4.000 – 4.800 |
| Mainboard mit 2× PCIe 5.0 x16 | 500 – 800 |
| CPU + RAM (>128 GB DDR5 ECC) | 900 – 1.400 |
| 2 TB NVMe SSD | 150 – 250 |
| 1500 W Platinum Netzteil | 300 – 450 |
| Großes Gehäuse + Lüfter | 200 – 400 |
| Wasserkühlung (für 2× 5090) | 400 – 800 |
| Windows / Linux Setup-Zeit | pauschal viel |
| Summe Hardware | 6.450 – 8.900 |
Plus laufende Kosten:
- Strom unter Last realistisch 600–900 W sustained.
- Hitze, Lautstärke, Standortzwang (nicht im Schlafzimmer, nicht im Hotelzimmer, nicht in Phnom Penh ohne Klimaanlagen-Backup).
- Keine Mobilität.
Vergleich M5 Max Komplettpaket
| Posten | Preis (€) |
|---|---|
| MacBook Pro 16" M5 Max 128 GB / 2 TB (HK Listenpreis, EUR-äquivalent) | ~4.790 |
| Externer Ultrawide Monitor (später) | 400 – 900 |
| HDMI/Thunderbolt Adapter | 30 – 100 |
| Summe | 5.220 – 5.790 |
- Stromaufnahme unter Volllast ~120–150 W. Eine Größenordnung unter NVIDIA-Doppel-GPU.
- Leise, fertig, mobil (Handgepäck-Koffer mit Polsterung).
- 128 GB als ein Pool — passt für Modelle, die auf 2× 5090 nicht laufen können.
Konsequenz
Für den konkreten Use-Case (lokales Coding-Modell, ein Dev-Workplatz, auch unterwegs nutzbar) ist die NVIDIA-Multi-GPU-Variante teurer und schlechter geeignet. Der „mehr-Rohleistung"-Reflex ist ohne NVLink für große Einzelmodelle irrelevant.
3 — Roadmap
Phase 1 — jetzt
- Verkauf der Alt-GPUs (alle mit OVP):
- 4× RTX 3080 (Mining-Historie) → Test-Rig MSI B550 zum Durchtesten, dann Verkauf eBay-Kleinanzeigen.
- 1× RTX 3090 (kein Mining) → aktuell 700–1.100 € erzielbar.
- 8× AMD RX 6600 XT (8 GB) → Verkauf, ROCm auf Navi 23 für LLM irrelevant.
- Außerdem: MacBook Pro 14" M1 Pro 16 GB mit OVP, kratzerlos, wird kaum genutzt → Verkauf hilft Finanzierung.
- Aus Verkaufserlös + Cashflow PP: MacBook Pro 16" M5 Max 128 GB in HK kaufen. US-Tastatur ist OK (extern Tastatur/Maus daheim).
- Einreise nach Kambodscha ohne OVP, im gepolsterten Handgepäck. Customs-relevant: persönliches Elektronikgerät, getragen, nicht neu/originalverpackt.
Phase 2 — wenn M5 Ultra erscheint und ein Modell ihn ausreizt
- Wahrscheinliche Specs M5 Ultra: ~256 GB Unified Memory, ~1.000–1.200 GB/s Bandbreite. Releasezeitpunkt offen, kein Termin.
- Ohne passendes Modell (>128 GB sinnvoll) kein Kauf.
- Plan: M5 Max später ggf. in Zahlung geben oder per Thunderbolt als Co-Worker behalten.
- Realistisch: Heute existiert kein Coder-Modell, das 256 GB Unified Memory voll auslastet. Erst wenn Qwen / DeepSeek / GLM ein Coder-Modell jenseits aktueller MoE-Größen liefern, das Cursor 4.7-Niveau lokal erreicht, lohnt der Sprung.
Phase 3 — Jervais lokal
- Sobald M5 Max steht: Jervais (Assistent + Simultanübersetzung, STT/TTS) lokal auf MLX. Kein Cloud-Token-Verbrauch mehr für Routine-Coding und Übersetzung.
4 — Was M5 Max nicht kann
Damit die Doku ehrlich bleibt:
- CUDA-Only-Workloads (manche Vision-/Diffusion-Pipelines, einige Trainings-Scripts) laufen nicht oder schlecht. Inferenz ist meist per MLX/llama.cpp gelöst, Training größerer Modelle bleibt NVIDIA-Domäne.
- Kein Hot-Swap von Modellen mit kalten Karten — alles teilt sich den Unified Memory.
- Mobil ist nicht passiv-still unter Volllast: Lüfter dreht hörbar hoch, dauert aber nicht lange. 16"-Chassis kühlt sustained Loads spürbar besser als 14".
- Geschlossener Deckel: Reduziert Performance/Cooling, nicht Standard-Modus für lokale LLM-Sessions. Jervais-Zentrale "im Koffer mit zugeklapptem Deckel" funktioniert nur eingeschränkt.
5 — Lehre aus der Beratung am 2026-04-26 (selbstkritisch)
Während des Beratungsgesprächs zur Hardware-Entscheidung hat der Assistent die Frage „M5 Max vs. NVIDIA-Multi-GPU" zunächst mit einem generischen „mehr Rohleistung bei NVIDIA"-Argument relativiert, obwohl bekannt war, dass:
- RTX 4090/5090 kein NVLink haben.
- Daraus folgt kein gemeinsamer VRAM-Pool.
- Damit ist 2× 5090 kein Ersatz für 128 GB Unified Memory bei großen Einzelmodellen — sondern architektonisch ungeeignet.
Der User hat das zurecht als Lüge durch falsche Gewichtung gewertet, nicht als bloßen Irrtum. Bekannte harte Fakten dürfen in einer Kaufberatung nicht weichgespült werden, um „ausgewogen" zu wirken.
Konsequenz für künftige Beratung (Pflicht):
- Wenn ein Architektur-Fakt einen Vergleich zum Kippen bringt (hier: NVLink/Unified Memory), wird er zuerst genannt und nicht unter „Nuancen" eingebettet.
- Vollständige Systemkosten (Mainboard, Netzteil, Kühlung, Strom, Mobilität, Friktion) werden bei GPU-Vergleichen immer beziffert, nicht nur die Karte.
- Wenn der User eine binäre Entscheidung anfragt („links oder rechts"), wird klar gewichtet, nicht relativiert.
- Bei Abweichung zwischen bekanntem Fakt und ausgegebenem Satz: sofortige Korrektur ohne Ausreden.
Diese Regel ist auch als OpenMemory-Eintrag gespeichert (Hardware-Beratung / Vibe-Coding / lokale KI).
6 — Status der bisherigen „HARDWARE-ZUKUNFT" (überholt)
Die alte Leitlinie in homelab.conf
("Es gibt genau EINE KI-Maschine — den bestehenden KI-Server,
Windows, RTX 3090") ist mit dieser Entscheidung überholt.
Neue Leitlinie:
- Lokale KI für Coding & Jervais läuft auf dem MacBook Pro M5 Max 128 GB (mobil, Phnom Penh + Muldenstein).
- Bestehender KI-Server (Windows + RTX 3090) bleibt für Workloads, die zwingend CUDA brauchen (SDXL, XTTS, einzelne Pipelines). Keine Erweiterung mehr geplant.
- Alte GPUs (4× 3080, 8× 6600 XT) → Verkauf.
- Kein zweiter NVIDIA-Build, kein 2× 5090, kein Multi-GPU-Rig.
- M5 Ultra nur dann, wenn ein konkretes Modell das rechtfertigt.
homelab.conf und MASTER_INDEX.md werden parallel angepasst.
Entscheidungsnotiz: Qwen3.6 + BeeLlama fuer opencode-Tests
Stand: 2026-05-18
Qwen3.6 ueber BeeLlama ist fuer einfache, kontrollierte opencode-Tests ausreichend:
- Git-Repos klonen
- README,
package.jsonund Setup-Hinweise lesen - Projektstruktur erkunden
- Shell-/Git-Kommandos ausfuehren
- Tests finden und starten
- kleine, klar begrenzte Codeaenderungen vorbereiten
Wichtig: BeeLlama macht das Modell schneller und lokal praktikabler, aber nicht automatisch intelligenter. Fuer komplexe Coding-Agent-Aufgaben wie grosse Refactorings, viele Dateien gleichzeitig, schwierige Debug-Schleifen oder produktive Aenderungen bleibt ein spezialisiertes Coding-Modell zuverlaessiger.
Empfohlener erster Testauftrag:
Klon dieses Repo nach /tmp/opencode-test, lies README und package.json, aber aendere nichts. Sag danach, wie man es startet und welche Tests definiert sind.
Entscheidungsnotiz: zweite RTX 3090
Eine zweite RTX 3090 verbessert die Qualitaet desselben Modells nicht direkt. Dasselbe Modell mit derselben Quantisierung liefert grundsaetzlich dieselbe Antwortqualitaet.
Eine zweite GPU hilft indirekt durch:
- groessere Modelle, die vorher nicht in den VRAM passten
- bessere Quantisierung, z.B. Q5/Q6 statt Q4
- mehr Kontext/KV-Cache
- weniger CPU-Offload
- hoehere Tokenrate bei gutem Layer-/Tensor-Splitting
- mehr parallele Requests
Fuer opencode waere der echte Qualitaetsgewinn daher nicht die zweite GPU selbst, sondern dass dadurch eventuell ein besseres oder groesseres Coding-Modell lokal betrieben werden kann.