benchmark: Compose-Kartenwahl und Rerank-Bedingung in ADR-0006 ergänzt
ci / test (push) Successful in 26s
ci / test (push) Successful in 26s
- count: 1 in gpu-llamacpp greift die M4000 (geprüft), für die P2000 device_ids setzen - Empfehlung pve44/46/48 unter der Bedingung, dass Embedding + Rerank gemeinsam auf die P2000 passen - 8B-VRAM: 7,73 GiB gemessen, im Katalog auf 7,8 aufgerundet Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 5.5
parent
cdf0bb63e3
commit
d8797a9433
@@ -67,10 +67,11 @@ Weitere Befunde:
|
||||
- **CC 5.2 rechnet:** llama.cpp b6000 und whisper.cpp 1.9.5 laufen mit CUDA 12.4 auf der M4000, Flash-Attention eingeschlossen.
|
||||
- Die Token-Erzeugung (tg) ist auf beiden Karten etwa gleich schnell und liegt deutlich unter der Speicherbandbreite. Die Karte ist dabei voll ausgelastet (P2000 99 %), es liegt also nicht an der CPU der VM. b6000 ist über ein Jahr alt (aktuell `b11574`); vor einer Anhebung des Compose-Pins nachmessen.
|
||||
- Die P2000 hängt in pve48 nur mit PCIe 3.0 x4 an (M4000 x16). Das bremst nur das Laden.
|
||||
- **Kartenwahl in Compose:** `deploy/compose/gpu-llamacpp` reserviert `count: 1`. Docker gibt dann die erste Karte heraus, und das ist die M4000 (geprüft: `docker run --gpus 1 … nvidia-smi -L` → Quadro M4000). Für die P2000 in Task 6.1 `device_ids` (Index 1 oder UUID) statt `count` setzen.
|
||||
|
||||
### Empfehlung: M4000 wieder aufnehmen – **ja, aber nur gezielt**
|
||||
- **pve52 (nur eine M4000): ja**, für STT (whisper.cpp, 2,1 s je 10 s, schneller als die P2000). Ohne sie hat der Knoten keine GPU-Rolle, und die M4000 läuft dort für `nex-stt` ohnehin.
|
||||
- **pve44, pve46, pve48: vorerst nein** für die heutigen Rollen. Embedding, Rerank und Verifier laufen auf der P2000 gleich schnell oder schneller (Prefill +37 %) bei etwa halber Leistungsaufnahme. Die M4000 lohnt sich dort nur für Rollen, die mehr als 5 GB brauchen: `qwen3-8b-q4km` mit 16k Kontext (7,7 GiB), eine zweite STT-Instanz oder ein zweiter Verifier zur Lastverteilung.
|
||||
- **pve44, pve46, pve48: vorerst nein** für die heutigen Rollen. Embedding und Verifier laufen auf der P2000 gleich schnell oder schneller (Prefill +37 %) bei etwa halber Leistungsaufnahme. Bedingung: Embedding und Rerank passen mit `-ub 8192` gemeinsam auf die P2000 (Embedding allein 2,8 GiB, Rerank ungemessen). Passt das nicht, kommt Rerank auf die M4000 in derselben VM (dann „ja“ für pve44/46), oder `-ub` wird gesenkt. Die M4000 lohnt sich dort nur für Rollen, die mehr als 5 GB brauchen: `qwen3-8b-q4km` mit 16k Kontext (7,7 GiB), eine zweite STT-Instanz oder ein zweiter Verifier zur Lastverteilung.
|
||||
- Nur für llama.cpp und whisper.cpp; PyTorch, vLLM und TTS bleiben ausgeschlossen (Entscheidung 1 und 3 unverändert).
|
||||
- Eine gesperrte, aber eingebaute M4000 verbraucht im Leerlauf weiter etwa 13 W, solange der Treiber in der VM geladen ist. Bleibt sie dauerhaft ungenutzt, ausbauen.
|
||||
- Vorbehalt: Die Steckdosenmessung je Knoten (Leerlauf und Volllast) steht aus. Das Flag `disabled` im Inventar ist nicht geändert; die Freigabe für pve52 setzt der Nutzer nach dieser Messung.
|
||||
|
||||
Reference in New Issue
Block a user