rorapp/cluster-knaster

Fork 0

Files

T

rorappandClaude Opus 5.5 c81e372c49

ci / test (push) Successful in 25s

Details

sites: Inventar und Zielbild an echte Knoten (pve44–pve61) angepasst; ADR-0001/0002/0006 ergänzt

Aufbauplan Task 0.4:
- inventory.yaml: pve44/46/48/52/61 und GODE-PC-05/06 (Ada, Windows, cpu_roles: false)
- proxmox.yaml: eine GPU-VM pro Knoten mit allen Karten (D2), local-lvm/tank (D1 B),
  192.168.100.0/24 ohne VLAN, Gast-IPs .220–.239 (ANNAHME bis Task 0.2)
- registry.yaml/prometheus.yml: ops-Labels auf gpu-pve44/46/48, Ada ohne pve_node/vmid
- tofu: dynamische hostpci, Speicher je Gast; Ansible: pve_gpu_hosts/pve_kiosk,
  Replikation auf mehrere Ziele
- Placement: cpu_roles=false schließt Arbeitsplätze/Kiosk von CPU-Rollen aus
- PLAN §1.3/§1.4/§9 und ADR-Nachträge (D1 entschieden, D2/D3 Bestätigung offen)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-10-13 01:39:49 +02:00

3.0 KiB

Raw Blame History

ADR-0006: Alte GPUs nur für llama.cpp, M4000 vorerst außer Betrieb, TTS auf Ada und CPU

Status: angenommen, ergänzt am 2026-10-13 (Nachtrag D3, Bestätigung offen)
Datum: 2026-10-12

Kontext

PyTorch unterstützt Maxwell und Pascal seit 2.8 nur noch in den cu126-Builds. PyTorch 2.14 ist die letzte Version mit CUDA-12.x-Wheels (Ankündigung vom 04.09.2026), danach geht es nur noch über einen eigenen Build.
Pascal hat weder bf16 noch schnelles FP16, und FlashAttention fehlt. Qwen3-TTS 1.7B erreicht auf einer Tesla P40 nur RTF ~7,3 (Referenz-Implementierung, gemessen von tinycomputers.io). P2000 und M4000 sind schwächer.
llama.cpp unterstützt Maxwell und Pascal mit CUDA 12 weiterhin. FlashAttention läuft dort auch auf Maxwell.
Für die M4000 gibt es keine direkten Messungen. Geschätzt liegt sie bei 7B Q4 auf 12–25 Token/s, bei 120 W pro Karte. Die P2000 decken Embedding, Rerank und Verifier bereits ab.

Entscheidung

Engine-Grenzen im Katalog (catalog/models.yaml → engines): pytorch ab Compute Capability 7.5, vllm ab 7.0, llamacpp ab 5.0. Das Placement setzt PyTorch-Workloads damit nie auf Maxwell/Pascal.
M4000 vorerst außer Betrieb (disabled: true im Inventar). Wieder aufgenommen werden sie nur nach llama-bench plus Strommessung am Deployment-Tag, und dann nur für llama.cpp-Rollen.
TTS:
- tts-de: Piper auf der CPU im Infra-LXC. Schnell, robust, ohne GPU, zugleich Fallback.
- tts-de-hq: Qwen3-TTS 1.7B (Apache 2.0, Deutsch, Stimmenklonen) in bf16 auf gpu-flex, im Wechsel mit Training und tier1-flex. Wenn TTS aktiv ist, sinkt der vLLM-Anteil am VRAM auf ~55 %.
- Kein TTS auf P2000 oder M4000.

Folgen

Bei gpu-flex muss sich der Lifecycle die Karte mit TTS teilen. Während des Trainings gehen sowohl tier1-flex als auch tts-de-hq auf unavailable, und LiteLLM fällt auf tts-de zurück.
Die tatsächlichen RTF-Werte misst knaster bench tts beim Deployment. Sie ersetzen die Schätzungen im Katalog.

Nachtrag 2026-10-13: Ada-Rechner bleiben Windows (Aufbauplan D3, Bestätigung offen)

Die beiden RTX 4000 Ada stecken in GODE-PC-05 und GODE-PC-06 (je eine Karte, 64 GB RAM). Das sind Windows-Arbeitsplätze, tagsüber haben Mitarbeitende Vorrang. Sie laufen schon heute als LLM-Worker (LocalLLMWorker.ps1, llama-server mit CUDA).

Die Slots tier1-general und tier1-flex lösen künftig über die Worker-Registry v2 auf einen Worker auf, der gerade online ist. Ist keiner online, geht die Anfrage an tier0 über den PSE-LiteLLM (Aufbauplan Task 6.4). Bis dahin behalten sie in der Registry ihre Engine.
vLLM, Multi-LoRA, QLoRA und Qwen3-TTS (tts-de-hq) laufen unter Windows nicht nativ. Sie kommen erst mit einer späteren Entscheidung über WSL2 bzw. nächtliches vLLM (Phase 9). Bis dahin ist tts-de (Piper, CPU) der einzige aktive TTS-Slot.
Im Inventar stehen die Rechner mit cpu_roles: false. Das Placement verplant dort nur die GPU und nie Infra- oder CPU-Fallback-Rollen.

3.0 KiB Raw Blame History Unescape Escape