feat: GPU-Split, Phase-Timer, llama.cpp-Update-Fixes
GPU-Setup: - Coder → GPU 1 (device=1), Judge → GPU 2 (device=2), kein --tensor-split - --chat-template-kwargs deprecated → --reasoning on (neue llama.cpp-API) - Smoke-Test-Timeout 180s → 300s (neue fitting-Phase beim Start) Fortschrittsanzeige: - Phase-Timer [MM:SS] in Statuszeile während LLM-Inference (sendAndWait) - currentActivity in Fix-Phase zeigt konkreten Blocker statt generischem Text Dokumentation: - README: GPU-Tabelle, VRAM-Abschätzung, --reasoning on, Timer-Beispiele - BEDIENUNGSANLEITUNG: Ladezeit, Fortschrittsanzeige mit Timer-Beispielen Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
parent
42d29354ad
commit
3f7ffe60c2
5 changed files with 122 additions and 72 deletions
121
README.md
121
README.md
|
|
@ -36,10 +36,10 @@ den Endpunkten wenn du ein `/judge`-, `/fix`- oder `/coder`-Kommando aufrufst.
|
|||
|
||||
## Modelle
|
||||
|
||||
| Rolle | Modell | Port | Container | Alias |
|
||||
|--------|---------------------------------------------------|------|------------------|----------------|
|
||||
| Coder | Qwen3.6-27B-Uncensored-HauhauCS-Aggressive-IQ4_XS | 8001 | qwen36-27b-coder | qwen3.5-coder |
|
||||
| Judge | Qwen3.6-27B-Uncensored-HauhauCS-Aggressive-IQ4_XS | 8002 | qwen36-27b-judge | qwen3.5-judge |
|
||||
| Rolle | Modell | Port | Container | Alias | GPU |
|
||||
|--------|---------------------------------------------------|------|------------------|----------------|----------|
|
||||
| Coder | Qwen3.6-27B-Uncensored-HauhauCS-Aggressive-IQ4_XS | 8001 | qwen36-27b-coder | qwen3.5-coder | device=1 |
|
||||
| Judge | Qwen3.6-27B-Uncensored-HauhauCS-Aggressive-IQ4_XS | 8002 | qwen36-27b-judge | qwen3.5-judge | device=2 |
|
||||
|
||||
Beide Container verwenden dasselbe GGUF-Datei, aber mit unterschiedlichen
|
||||
Serverparametern (Kontext, Temperatur, Parallelität).
|
||||
|
|
@ -58,7 +58,8 @@ Serverparametern (Kontext, Temperatur, Parallelität).
|
|||
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
|
||||
sudo systemctl restart docker
|
||||
```
|
||||
- Mindestens eine NVIDIA-GPU (empfohlen: zwei GPUs mit je ≥ 16 GB VRAM)
|
||||
- NVIDIA-GPUs: empfohlen 2 × RTX 3090 (je 24 GB VRAM) für Coder und Judge parallel.
|
||||
Bei 3 GPUs: GPU 0 für Display reservieren, GPU 1 → Coder, GPU 2 → Judge.
|
||||
- GGUF-Modell vorhanden unter:
|
||||
`$HF_HOME/models/qwen3/Qwen3.6-27B-Uncensored-HauhauCS-Aggressive-IQ4_XS.gguf`
|
||||
- Standard-Pfad: `HF_HOME=/home/dschlueter/nvme2n1p7_home/huggingface`
|
||||
|
|
@ -110,7 +111,9 @@ Nach späteren Änderungen an `pi-coder-judge-extension.ts` oder `models.json`:
|
|||
```
|
||||
|
||||
`start-servers.sh` startet beide Container gleichzeitig und wartet bis beide
|
||||
HTTP-ready sind. Logs werden getrennt gesammelt und nur bei Fehler ausgegeben.
|
||||
HTTP-ready sind (max. 5 Minuten — die neue llama.cpp-Version prüft beim Start, ob
|
||||
Modell + KV-Cache in den VRAM passen, was zusätzliche Zeit kostet). Logs werden
|
||||
getrennt gesammelt und nur bei Fehler ausgegeben.
|
||||
|
||||
Wenn Server bereits laufen und du `start-servers.sh` (oder ein Einzelskript)
|
||||
aufrufst, werden die laufenden Container zuerst per `docker rm -f` gestoppt
|
||||
|
|
@ -125,19 +128,20 @@ und dann neu gestartet — ein laufender Inference-Request wird dabei abgebroche
|
|||
| Parameter | Wert | Bedeutung |
|
||||
|---|---|---|
|
||||
| `--jinja` | — | Verwendet das im GGUF eingebettete Jinja-Chat-Template (Qwen-Format). Notwendig für korrekte `<\|im_start\|>`-Tokens. |
|
||||
| `--reasoning on` | — | Aktiviert das interne Thinking-Budget des Modells (Qwen3-spezifisch). Ersetzt das frühere `--chat-template-kwargs '{"enable_thinking":true}'`. |
|
||||
| `--no-context-shift` | — | Kontextfenster wird **nicht** verschoben wenn es voll ist — stattdessen Fehler. Verhindert stille Datenverluste. |
|
||||
| `--repeat-penalty 1.05` | — | Leichte Penalty für Wiederholungen. Wert > 1.0 unterdrückt Loops. |
|
||||
| `--top-k 40` | — | Nur die 40 wahrscheinlichsten nächsten Tokens werden berücksichtigt. |
|
||||
| `--top-k 20` | — | Nur die 20 wahrscheinlichsten nächsten Tokens werden berücksichtigt. |
|
||||
| `--min-p 0.01` | — | Tokens mit Wahrscheinlichkeit < 1 % des wahrscheinlichsten Tokens werden ausgeschlossen. |
|
||||
| `-ngl 999` | — | Alle Layer auf die GPU laden (999 = „alle"). Bei zu wenig VRAM reduzieren. |
|
||||
| `-fa on` | — | Flash Attention — schnellere Attention-Berechnung, weniger VRAM für den Attention-Pass. |
|
||||
| `--kv-unified` | — | Einheitlicher KV-Cache über alle Schichten. Effizienter bei langen Kontexten. |
|
||||
| `--cache-type-k q4_0` | — | KV-Cache Keys in 4-Bit quantisiert. Spart ~75 % VRAM gegenüber fp16 — nötig für 256K Kontext auf 2× 24 GB. |
|
||||
| `--cache-type-k q4_0` | — | KV-Cache Keys in 4-Bit quantisiert. Spart ~75 % VRAM gegenüber fp16 — nötig für 256K Kontext auf einer 24-GB-GPU. |
|
||||
| `--cache-type-v q4_0` | — | KV-Cache Values ebenfalls 4-Bit quantisiert. |
|
||||
| `--cont-batching` | — | Continuous Batching: neue Anfragen werden in laufende Batches eingefügt — höherer Durchsatz bei mehreren parallelen Anfragen. |
|
||||
| `--main-gpu 0` | — | GPU-Index (0 = erste der übergebenen GPUs) für Nicht-Tensor-Operationen. |
|
||||
| `--tensor-split 0.5,0.5` | — | Modell-Gewichte 50/50 auf zwei GPUs aufteilen. |
|
||||
| `--gpus '"device=1,2"'` | — | Docker-Argument: GPU 1 und GPU 2 dem Container übergeben. |
|
||||
| `--main-gpu 0` | — | GPU-Index (0 = erste des Containers) für Nicht-Tensor-Operationen. |
|
||||
| `--gpus '"device=1"'` (Coder) | — | Docker: nur GPU 1 dem Coder-Container zuweisen. |
|
||||
| `--gpus '"device=2"'` (Judge) | — | Docker: nur GPU 2 dem Judge-Container zuweisen. |
|
||||
|
||||
### Coder-Server (Port 8001) — optimiert für Coding-Aufgaben
|
||||
|
||||
|
|
@ -165,58 +169,60 @@ und dann neu gestartet — ein laufender Inference-Request wird dabei abgebroche
|
|||
|
||||
---
|
||||
|
||||
## Anpassung für eine einzelne GPU
|
||||
## GPU-Konfiguration und VRAM
|
||||
|
||||
Mit einer GPU läuft das Modell vollständig auf dieser GPU statt verteilt.
|
||||
Anpassungen in `start-coder.sh` und `start-judge.sh`:
|
||||
### Aktuelles Setup (1 GPU pro Server)
|
||||
|
||||
```bash
|
||||
# Vorher (2 GPUs, device 1 und 2):
|
||||
--gpus '"device=1,2"' \
|
||||
--main-gpu 0 \
|
||||
--tensor-split 0.5,0.5 \
|
||||
Jeder Server bekommt eine dedizierte GPU — dadurch kein VRAM-Konflikt:
|
||||
|
||||
# Nachher (1 GPU, z.B. device 0):
|
||||
--gpus '"device=0"' \
|
||||
--main-gpu 0 \
|
||||
# --tensor-split ← diese Zeile komplett entfernen
|
||||
```
|
||||
GPU 0 NVIDIA T600 → Display / Monitor (nicht für KI genutzt)
|
||||
GPU 1 RTX 3090 (24 GB) → qwen36-27b-coder (Port 8001)
|
||||
GPU 2 RTX 3090 (24 GB) → qwen36-27b-judge (Port 8002)
|
||||
```
|
||||
|
||||
### VRAM-Abschätzung für das 27B IQ4_XS-Modell
|
||||
Die Skripte verwenden `--gpus '"device=1"'` (Coder) bzw. `'"device=2"'` (Judge).
|
||||
Innerhalb des Containers ist dies stets `CUDA:0`, daher `--main-gpu 0` ohne `--tensor-split`.
|
||||
|
||||
### VRAM-Abschätzung für das 27B IQ4_XS-Modell (eine GPU)
|
||||
|
||||
| Komponente | Größe (ca.) |
|
||||
|---|---|
|
||||
| Modell-Gewichte (IQ4_XS, 27B) | ~14,5 GB |
|
||||
| KV-Cache bei 128K Kontext (q8_0) | ~14 GB |
|
||||
| KV-Cache bei 64K Kontext (q8_0) | ~7 GB |
|
||||
| KV-Cache bei 32K Kontext (q8_0) | ~3,5 GB |
|
||||
| Modell-Gewichte (IQ4_XS, 27B) | ~14 GB |
|
||||
| KV-Cache bei 262 144 Tokens (q4_0) | ~8–10 GB |
|
||||
| KV-Cache bei 131 072 Tokens (q4_0) | ~4–5 GB |
|
||||
| KV-Cache bei 65 536 Tokens (q4_0) | ~2–3 GB |
|
||||
| **Summe (262k Kontext)** | **~22–24 GB** |
|
||||
|
||||
Bei einer **24-GB-GPU** ist nur ein Server gleichzeitig sinnvoll betreibbar:
|
||||
- Modell-Gewichte: ~14,5 GB
|
||||
- KV-Cache bei 32K Kontext: ~3,5 GB
|
||||
- Summe: ~18 GB → passt mit Puffer
|
||||
|
||||
**Empfehlung für eine 24-GB-GPU:**
|
||||
Bei einer **24-GB-GPU** ist 262k Kontext knapp kalkuliert. Wichtig: keine anderen Prozesse
|
||||
dürfen nennenswert VRAM belegen (z. B. TTS-Dienste, Ollama). Prüfen mit:
|
||||
```bash
|
||||
# Coder — Kontext reduzieren
|
||||
-c 32768 # statt 131072
|
||||
-n 8192 # statt 16384
|
||||
nvidia-smi --query-gpu=index,memory.used,memory.free --format=csv
|
||||
```
|
||||
|
||||
# Judge — Kontext reduzieren
|
||||
-c 32768 # statt 131072
|
||||
Falls der VRAM nicht reicht: Kontext in den Startskripten auf `131072` oder `65536` reduzieren.
|
||||
|
||||
### Anpassung für andere GPU-Konfigurationen
|
||||
|
||||
```bash
|
||||
# 2 GPUs (beide für KI, keine Display-GPU):
|
||||
--gpus '"device=0"' # Coder
|
||||
--gpus '"device=1"' # Judge
|
||||
|
||||
# 1 GPU (beide Server auf gleicher GPU — nicht empfohlen, VRAM-Konflikt):
|
||||
--gpus '"device=0"' # beide Server
|
||||
--tensor-split 0.5,0.5 # Modell hälftig aufteilen
|
||||
-c 65536 # Kontext stark reduzieren
|
||||
|
||||
# 2 GPUs für einen Server (wenn sehr großer Kontext nötig):
|
||||
--gpus '"device=0,1"' \
|
||||
--tensor-split 0.5,0.5 \
|
||||
--main-gpu 0 \
|
||||
-c 262144
|
||||
```
|
||||
|
||||
Bei einer **16-GB-GPU** ist die Modellgröße allein schon grenzwertig.
|
||||
Entweder ein kleineres Modell verwenden oder die Quantisierung weiter erhöhen (IQ3_XS, Q4_K_M).
|
||||
|
||||
### Beide Server auf einer GPU betreiben
|
||||
|
||||
Technisch möglich, aber beide Server laden das Modell gleichzeitig → doppelter VRAM-Bedarf.
|
||||
Auf einer 24-GB-GPU daher **nicht empfohlen**. Alternativen:
|
||||
|
||||
- Nur einen Server gleichzeitig starten (manuell umschalten)
|
||||
- Kleinere Quantisierung wählen (IQ3_XS: ~11 GB)
|
||||
- `ollama` als Alternative — lädt Modelle bei Bedarf und entlädt sie wieder
|
||||
Entweder ein kleineres Modell verwenden oder die Quantisierung erhöhen (IQ3_XS, Q4_K_M).
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -243,7 +249,7 @@ KV-Cache ≈ `context_size × 28 × 128 × 32 × 2 × 1 Byte ≈ context_size ×
|
|||
| 32 768 | ~1,9 GB | 1 × 16-GB-GPU |
|
||||
| 65 536 | ~3,7 GB | 1 × 24-GB-GPU |
|
||||
| 131 072 | ~7,5 GB | 2 × 16-GB-GPU |
|
||||
| 262 144 | ~15 GB | 2 × 24-GB-GPU — **aktuell gesetzt** |
|
||||
| 262 144 | ~8–10 GB | 1 × 24-GB-GPU (q4_0) — **aktuell gesetzt** |
|
||||
|
||||
### KV-Cache-Quantisierung
|
||||
|
||||
|
|
@ -306,16 +312,19 @@ Ausführliche Beschreibung aller Kommandos mit Beispielen: siehe **BEDIENUNGSANL
|
|||
|
||||
## Live-Aktivitätsstatus
|
||||
|
||||
Während der Ausführung zeigt pi_coder in der Statuszeile, was gerade passiert:
|
||||
Während der Ausführung zeigt pi_coder in der Statuszeile, was gerade passiert —
|
||||
inklusive eines laufenden `[MM:SS]`-Timers während jeder LLM-Inference-Phase:
|
||||
|
||||
| Situation | Anzeige |
|
||||
|---|---|
|
||||
| Coder implementiert | `Coder implementiert…` |
|
||||
| Coder implementiert | `◉ Coder implementiert: Login-Flow mit JWT [01:23]` |
|
||||
| edit-Tool aktiv | `Editiere src/main.py…` |
|
||||
| git commit | `Git-Commit…` |
|
||||
| Judge reviewt (Runde 2/2) | `Judge reviewt (Runde 2/2)…` |
|
||||
| Tests laufen | `Tests laufen…` |
|
||||
| Fix-Phase | `Coder fixt Blocker…` |
|
||||
| Judge (Quick-Check, Runde 1) | `◉○ Runde 1/2: Quick-Check [00:47]` |
|
||||
| Judge (voller Review, Runde 2) | `●◉ Runde 2/2: Judge — TASK.md + letzter Commit + Tests [02:15]` |
|
||||
| Tests laufen | `●○ Runde 1/2: Tests laufen (pytest, max. 120s)…` |
|
||||
| Fix-Phase | `●◉ Runde 2/2: Coder fixt — fehlendes Null-Check [01:05]` |
|
||||
| ShipIt | `●●◉ ShipIt — finale Freigabe [00:33]` |
|
||||
| Interactive-Pause (--interactive) | `⏸ PASS – warte auf /continue…` |
|
||||
|
||||
So ist jederzeit erkennbar, in welcher Phase sich der automatische Loop befindet.
|
||||
Der Timer beweist, dass die LLM tatsächlich arbeitet. Steht er still, hängt der Prozess.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue