1cbc5df1ad
- llm.py: Text-Modell auf x-ai/grok-4.3 - telegram_bot.py: Fortschritts-Logik auf asyncio.wait_for + shield (15s Timeout) - monitor.py: Hermes-Healthchecks (CT151), Alert-Dedup, EXPECTED_STOPPED erweitert - core/loki_client.py: zentrale ERROR_EXCLUDE_RE fuer transiente cloudflared/QUIC-Flaps - Doku: JELLYFIN.md, infrastructure/STATE.md, hardware-ai-local-coding.md, sessions/ Bis 21.06. uncommittete Live-Edits, gesichert in backup/live-state-20260621. Ref #123.
228 lines
9.2 KiB
Markdown
228 lines
9.2 KiB
Markdown
# 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*
|
||
|
||
1. **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.
|
||
2. Aus Verkaufserlös + Cashflow PP: **MacBook Pro 16" M5 Max 128 GB**
|
||
in HK kaufen. US-Tastatur ist OK (extern Tastatur/Maus daheim).
|
||
3. 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):**
|
||
|
||
1. Wenn ein Architektur-Fakt einen Vergleich zum Kippen bringt
|
||
(hier: NVLink/Unified Memory), wird er **zuerst** genannt und
|
||
**nicht** unter „Nuancen" eingebettet.
|
||
2. Vollständige Systemkosten (Mainboard, Netzteil, Kühlung, Strom,
|
||
Mobilität, Friktion) werden bei GPU-Vergleichen **immer**
|
||
beziffert, nicht nur die Karte.
|
||
3. Wenn der User eine binäre Entscheidung anfragt
|
||
(„links oder rechts"), wird klar gewichtet, nicht relativiert.
|
||
4. 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.json` und 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:
|
||
|
||
```text
|
||
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.
|