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](https://huggingface.co/jpetrina/Qwen3.8-27B-IQ4_XS-pure-GGUF)
und [MIX](https://huggingface.co/vmarcelo/Qwen3.8-27B-MIX_GGUF) 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](https://huggingface.co/nvidia/Qwen3.8-27B-NVFP4)
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](https://huggingface.co/nvidia/Qwen3.8-27B-NVFP4/tree/482ca0f3832238542f8f5295dde86b5f22711d80).

Die [5080 gehört zu Compute Capability 12.0](https://developer.nvidia.com/cuda/gpus).
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](https://docs.vllm.ai/en/latest/features/quantization/modelopt/).

### 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](QWEN38_BYTESHAPE_AB_20260920.md) spart Speicher und schafft mehr
Einzelkarten-Kontext, war im kontrollierten Kurzvergleich aber langsamer und
qualitativ nicht durchgehend gleichwertig.
[DFlash 2](DFLASH2_ONE_SLOT_20260920.md) 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.