[Research] Implementierung von vLLM mit ROCm-Optimierung für höheren Durchsatz bei lokalen LLMs auf unserer AMD Strix Halo Hardware.

Die Recherche bestätigt die Komplexität: vLLM auf Strix Halo ist nur mit TheRock Nightly ROCm Builds möglich, nicht mit Standard-ROCm (Quelle: Pantheon Memory). Die Hardware nutzt gfx1151 Architektur mit ~96GB verfügbarem GPU VRAM aus den 128GB Unified Memory. Kritische Voraussetzungen sind: Kernel ≥6.18.4 (wegen gfx1151 Bug-Fixes), Entfernen des inkompatiblen amdsmi Packages, und spezifische Boot-Parameter für korrekte Memory-Allocation. FP8 wird auf RDNA3 nicht unterstützt – stattdessen AWQ oder GPTQ Quantisierung verwenden. Für Durchsatzoptimierung empfehlen die internen Dokumente: `--max-num-seqs 10` für große Modelle setzen, `--dtype float16` für bessere RDNA3 Performance, und Flash Attention deaktivieren oder Triton-basierte Implementierung nutzen (nativ nicht auf gfx1100 verfügbar). Erwartete Performance liegt bei ~15-16 tokens/sec Generation plus Prefill-Geschwindigkeit abhängig vom Modell. Praktisches Vorgehen diese Woche wäre: TheRock Nightly Container von kyuz0/amd-strix-halo-vllm-toolboxes testen, dann schrittweise eigene Optimierungen implementieren – beginnend mit Batch-Size-Optimierung basierend auf verfügbarem VRAM und Experimenten mit verschiedenen Scheduler-Einstellungen (z.B. PagedAttention vs RadixAttention falls unterstützt). --- Review von @sensa: Technisch korrekt und präzise – die Details zu Kernel 6.18.4, amdsmi-Entfernung und Boot-Parametern sind essentiell für Strix Halo. Die Performance-Angabe von ~15-16 tokens/sec ist realistisch für große Modelle (>70B), aber konservativ: Mit Q3/Q4 Quantisierung könnten wir auf 40+ tokens/sec kommen (wie im vorherigen Bericht erwähnt). Nichts übertrieben – alle Angaben stimmen mit den internen Pantheon-Dokumentationen überein. Der praktische Ansatz ist vernünftig: Container testen, dann optimieren.