AI-Profile-Router/docs/ATHENA_EFFICIENCY_REVIEW_20260920.md

Athena: abschließender Effizienz- und Quantisierungscheck

20.09.2026. Ergebnis: Die derzeitige Pure/MIX-Auswahl ist durch die vorhandenen Messungen gut begründet. Ein nachgewiesener, einfacher schnellerer Ersatz fehlt. Die Medium-Speicherkonfiguration bietet einen konkreten Ansatz für späteres Tuning; ein absolutes Leistungsoptimum ist nicht nachgewiesen.

Heute zusätzlich ausgeführt: lesender Modellinventar-, Konfigurations-, Hardware-, API-Health- und Speichercheck. Die Qwen-Referenz wurde wiederverwendet, nicht erneut benchmarked. Keine neue Quantisierung geladen und kein Dienst für diesen Abschlusscheck neu gestartet. Neue Belege stehen unter experiments/efficiency-review-20260920/.

Welche beiden Modelle laufen tatsächlich?

Es handelt sich um zwei Quantisierungen derselben Qwen3.8-27B-Familie:

Profil	Datei / Variante	Tatsächliche Tensorformate	Dateigröße
Fast	Qwen3.8-27B-IQ4-MIX.gguf	IQ4_XS, IQ3_S, IQ2_S, Q4_K, Q5_K sowie F32-Hilfstensoren	14,11 GB
Medium / Large / Ultra	qwen3.8-27b-IQ4_XS-pure.gguf	506 IQ4_XS-Tensoren und 360 F32-Tensoren	14,53 GB

Die GGUF-Header und Tensorbeschreibungen wurden direkt aus Athenas Dateien gelesen, ohne Gewichtsdaten auf GPUs zu laden. Keines der beiden ist natives NVFP4. „Pure“ heißt hier nicht unquantisiert/BF16. „MIX“ bedeutet gemischte Quantisierungsformate, nicht ein zweites Modell oder eine NVIDIA-Laufzeit. Die reine Anzahl der Tensoren ist kein Anteil der Parameter oder des Speichers.

Die Anbieter dokumentieren Pure und MIX getrennt. Entscheidend für diesen Bericht sind jedoch die tatsächlich installierten Dateien samt Prüfsummen in unserer eingefrorenen Referenz.

Daneben existieren das separate Uncensored-Profil und die heute getesteten ByteShape-/DFlash-Artefakte. Sie ersetzen keines der normalen Profile.

Die spezielle NVIDIA-Quantisierung

Gemeint ist NVFP4. Der aktuelle offizielle NVIDIA-Checkpoint mischt NVFP4 in MLP/LM-Head mit FP8 in Attention-Schichten. NVIDIA nennt Blackwell sowie vLLM/SGLang als unterstützten Einsatzpfad; das Beispiel wurde auf GB300 evaluiert. Die gemeldeten Qualitätswerte liegen nahe an BF16, zeigen aber auch Rückgänge. Das ist keine Qualitäts- oder Geschwindigkeitsgarantie für Athena.

Die am 20.09. geprüfte Revision 482ca0f3832238542f8f5295dde86b5f22711d80 enthält drei Safetensors-Dateien mit zusammen 21.921.697.280 Bytes = 20,42 GiB. Die 5080 bietet gemessen 15,92 GiB. Der vollständige gespeicherte Checkpoint ist also bereits ohne KV-Cache und Arbeitsbereiche größer als deren Speicher. Dateigröße ist nicht exakt Laufzeit-VRAM; selektives Laden oder Umwandlung wäre ein eigener Kandidat und wurde hier nicht geprüft. Ein unveränderter, vollständig GPU-residenter Einzelkarten-Test ist damit kein sinnvoller Schnelltest. Quelle der Größen: versionierte Dateiliste.

Die 5080 gehört zu Compute Capability 12.0. Die 3060 ist keine Blackwell-Karte; beide VRAM-Mengen lassen sich nicht einfach als ein gleichartiger nativer NVFP4-Beschleuniger behandeln. Das ist keine Behauptung, dass jeder andere Ausführungspfad unmöglich ist: vLLM dokumentiert auch einen W4A16/Marlin-Rückfall ohne native FP4-GEMM-Unterstützung, der bei rechenintensiven Aufgaben langsamer sein kann. Ein gemischter Athena-Pfad müsste separat integriert und gemessen werden. vLLM-ModelOpt-Dokumentation.

Bereits vorhandener historischer NVIDIA-Versuch

Das Register docs/TESTED_MODELS.md und die Originaldaten vom 22.08. enthalten bereits eine NVFP4-benannte Q4_K_M-GGUF-Datei: Qwen3.8-27B-NVFP4-Q4_K_M-mtp.gguf. Eingebettetes MTP lud nicht erfolgreich; separates MTP lief bei 72K und erreichte damals 42,3 tok/s (MTP2) beziehungsweise 35,9 tok/s (MTP3). Sie wurde ohne ausreichenden Gesamtvorteil verworfen.

Dieser historische GGUF-/llama.cpp-Versuch ist kein Benchmark des aktuellen nativen NVIDIA-Safetensors-Checkpoints. Andere Laufzeit, Prompts und Sampling; diese alten Zahlen nicht gegen heutige Messungen verrechnen. Der alte Versuch wird nicht vergessen oder unnötig wiederholt.

Was schon sinnvoll konfiguriert ist

• CUDA mit allen Modellschichten auf GPUs konfiguriert; Flash Attention aktiv.
• q 4_0-K/V reduziert den Speicherbedarf großer Kontexte.
• MTP ist eingerichtet; funktionierende Generation und Annahmestatistiken sind in den Referenzen und jüngsten Produktionslogs belegt.
• Fast legt das Hauptmodell vollständig auf die 5080. Große Kontexte nutzen die 3060 zusätzlich; Vision und TTS beanspruchen ebenfalls deren Speicher.
• Promptcache ist in Medium bereits eingeschaltet. Nicht als vermeintlich neuen Geschwindigkeitsgewinn nochmals „aktivieren“.
• Gespeicherte Pure-Referenz: bei kurzen Eingaben etwa 85,8 tok/s Deutsch, 122,1 tok/s Code und 2074,2 tok/s Prefill auf der 5080. Das sind spezifische Messfälle, keine garantierten Werte für jede Medium-Anfrage.

ByteShape spart Speicher und schafft mehr Einzelkarten-Kontext, war im kontrollierten Kurzvergleich aber langsamer und qualitativ nicht durchgehend gleichwertig. DFlash 2 funktioniert mit einem Slot und Draft auf 3060, zeigte aber keinen überzeugenden allgemeinen Vorteil. Beide Befunde sprechen gegen einen ungeprüften Wechsel des Standards.

Konkrete offene Effizienzpunkte

1. Medium startet ohne die zunächst versuchte Pipeline-Parallelisierung

Im aktuellen Startprotokoll steht:

failed to allocate CUDA0 buffer of size 1437729280
compute buffer allocation failed, retrying without pipeline parallelism

Danach lädt das Modell erfolgreich und wird gesund. Es ist ein abgefangener GPU-Rechenpufferfehler, kein Kernel-OOM oder Hostabsturz. Das zusätzliche Pufferbudget von etwa 1.338 GiB steht bei dieser Anordnung nicht zur Verfügung.

Die aktuelle Medium-Anordnung belegt im Leerlauf 15.714/16.303 MiB auf der 5080 und 10.920/12.288 MiB auf der 3060. Die 5080 ist somit bereits zu rund 96 % belegt. Maximal gefüllter VRAM bedeutet nicht automatisch maximalen Durchsatz: fehlende Arbeitsreserve kann einen effizienteren Ausführungspfad verhindern.

Sinnvollster späterer Vergleich: dasselbe Pure/MTP-Modell mit etwas mehr Reserve betreiben, etwa Microbatch 256 statt 512 und/oder leicht geändertem Layer-Split. Dabei tatsächlich prüfen, ob der Pipeline-Rückfall entfällt und ob Prefill, Einzelanfrage und zwei gleichzeitige Anfragen insgesamt profitieren. Nicht blind die Microbatch verkleinern: auch das kann Prefill verlangsamen. Eine Verbesserung ist hier noch nicht gemessen, deshalb heute keine Änderung.

2. Temperatur und Kartenverbindung mitmessen

Die gespeicherten Zwei-Sekunden-Samples der Pure/MIX-Referenz reichen bis 81 °C auf der 5080 und 62 °C auf der 3060. Der aktuelle Leerlauf ist kühler. Thermisches Drosseln wurde nicht mit Taktraten/Throttle-Countern nachgewiesen; die 81 °C sollten bei weiterem Tuning dennoch mit untersucht werden. Kein Übertakten, keine Treiber-/BIOS-Änderungen aus diesem Audit.

Die 3060 meldet eine aktuell ausgehandelte PCIe-Breite von x4, die 5080 x16. Die gemeldeten maximalen Link-Generationen sind 3 beziehungsweise 4. Aktuelles Gen 1 bei Leerlauf darf nicht als belegter dauerhafter Fehler interpretiert werden. Die reale Transferbegrenzung unter Last wurde heute nicht separat gemessen; die heterogene Verbindung bleibt ein Grund, die 5080 bevorzugt zu nutzen.

3. Lange Eingaben und Cache-Nutzung

Große Eingaben können die Wartezeit stärker bestimmen als Decode. Die gespeicherten Langkontextmessungen zeigen den erheblichen Zeitbedarf. Für den Alltag lohnt die Prüfung, ob Clients stabile gemeinsame Präfixe wiederverwenden und unnötig wiederholten Kontext vermeiden. Cache ist eingeschaltet; eine schlechte Cache- Trefferquote wurde hier nicht behauptet oder neu gemessen. Relevanten Kontext oder notwendiges Reasoning nicht pauschal kürzen, um schönere Zahlen zu erzielen.

Abschlussprüfung und Entscheidung

Alle geprüften Container gesund; Router health/readiness und Modell-health bestanden. Keine erfassten Kernel-Panic-, Xid-, OOM-Kill- oder GPU-fallen-off- Meldungen seit Tagesbeginn. Rund 43 GiB Host-RAM verfügbar; während der beiden Ein-Sekunden-Intervalle von vmstat kein Swap-in/out. Belegter Swap-Inhalt allein beweist kein aktuelles Pagingproblem. Das ist eine kurze Zustandsaufnahme, keine Dauerlastgarantie.

Für heute bleibt Pure/MIX mit MTP produktiv. NVFP4 ist grundsätzlich interessant, aber das aktuelle offizielle Modell ist für die 16-GB-Einzelkarte zu groß und für die gemischten GPUs kein einfacher Austausch. Priorität hat künftig ein gezielter Medium-Speicher-/Pipeline-Test, nicht noch eine breite Modellrunde. Alle bestehenden Messungen bleiben als Referenz erhalten. Kein neuer Benchmark, Download oder Umbau ist für später automatisch eingeplant.