Files
cluster-knaster/docs/adr/0006-legacy-gpus-llamacpp-tts-auf-ada.md
T
Robert RappandClaude Opus 5.5 e88e0ea46b sites: Inventar und Registry an echte Knoten (pve44–pve61) angepasst; ADR-0001/0002/0006 und PLAN §1.3/1.4/9 ergänzt
Inventar mit pve44–pve61 und den Ada-Rechnern gode-pc-05/06 (M4000 weiter
disabled). Registry-ops auf gpu-pve44/gpu-pve48/infra laut Placement, bei
den Ada-Slots entfallen pve_node und vmid (Worker-Registry v2, Task 6.4).
Tests: neuer test_site_knaster_matches_real_nodes, Konsistenztest auf
gpus-Liste umgestellt. ADR-Nachträge zu D1 (Variante B), D2 (eine GPU-VM
pro Knoten) und D3 (Ada bleibt Windows, vorgeschlagen).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-12 19:04:55 +02:00

2.9 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
  • 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

  1. 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.
  2. 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.
  3. 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-12: Ada-Rechner bleiben Windows (D3, vorgeschlagen, Bestätigung offen)

  • Die beiden RTX 4000 Ada (20 GB) stecken nicht in einem Proxmox-Knoten, sondern je eine in den Windows-Arbeitsplätzen GODE-PC-05 und GODE-PC-06 (64 GB RAM). Sie bleiben Windows, Mitarbeitende haben tagsüber Vorrang.
  • Vorschlag: LocalLLMWorker.ps1 mit llama-server (CUDA) meldet sich über die Worker-Registry v2. tier1-general (gode-pc-05) und tier1-flex (gode-pc-06) lösen auf einen Worker auf, der online ist, sonst auf Stufe 0 über den LiteLLM mit PSE.
  • In sites/knaster/registry.yaml behalten die Ada-Slots vorerst ihre Engine, nur pve_node und vmid entfallen. Die Umstellung folgt in Task 6.4.
  • Folgen: vLLM und PyTorch laufen unter Windows nicht nativ. tts-de-hq (Qwen3-TTS), Multi-LoRA und QLoRA auf gpu-flex warten auf eine spätere WSL2-Entscheidung (Phase 9). Bis dahin trägt tts-de (Piper) die Sprachausgabe allein.