Files
AI-Profile-Router/docs/MEDIUM_MICROBATCH_20260920.md
T

74 lines
3.8 KiB
Markdown

# Medium: Microbatch 512 gegen 256 — Kurztest
Nachtrag: [256 mit gesenkter Startreserve erfolgreich getestet](MEDIUM_MICROBATCH_RESERVE448_20260920.md). Der folgende Bericht dokumentiert den vorherigen Schutzabbruch.
20.09.2026. **256 lädt ohne den bisherigen Pufferfehler, hat aber zu wenig
Reserve für die festgelegte Testfreigabe. Deshalb keine produktive Umstellung
und noch kein Geschwindigkeitsvergleich für 256.**
Die echten Medium-Startargumente wurden vor dem Versuch aus Docker übernommen.
Zwischen beiden Testarmen unterschied sich nachweislich nur `--ubatch-size`.
Modell Pure, Kontext 160.000, zwei Slots mit gemeinsamem KV-Pool, Split 85:15,
Vision auf 3060, MTP3, Flash Attention, q4_0-K/V, Batch 2048 und sechs Threads
blieben gleich. Das Testendpoint war isoliert; TTS blieb auf 3060 resident.
## Ergebnis
| Prüfung | Microbatch 512 | Microbatch 256 |
|---|---|---|
| Modell geladen | ja | ja |
| Meldung: Rückfall ohne Pipeline-Parallelisierung | ja | nicht aufgetreten |
| 5080 belegt nach Laden | 15.704 MiB | 15.842 MiB |
| 5080 frei nach Laden | 599 MiB | **461 MiB** |
| 3060 belegt nach Laden, inklusive TTS | 10.918 MiB | 10.642 MiB |
| Mindestreserve von 512 MiB erfüllt | ja | **nein** |
| Inferenzaufgaben durchgeführt | ja | **nein, Schutzabbruch vorher** |
Bei 512 reproduziert sich der bekannte abgefangene Rechenpufferfehler mit
anschließendem Rückfall. Bei 256 fehlt diese Meldung; das Modell lädt erfolgreich.
Die höhere Belegung der 5080 trotz kleinerer Microbatch ist mit einem anderen
Rechenpuffer-/Pipeline-Pfad vereinbar. **Die Abwesenheit der Fehlermeldung allein
beweist jedoch weder aktive Pipeline-Auslastung noch einen Geschwindigkeitsgewinn.**
Der Abbruch bei 256 war eine Entscheidung des Testtreibers aufgrund der
festgelegten Reserve, kein CUDA-OOM und kein Modellabsturz. Die Grenze wurde
nicht abgesenkt, um doch noch eine Inferenz zu erzwingen. Auch die Reserve ist
keine Garantie, dass jede Langkontext-/Vision-Anfrage passt.
## Kleiner Kontrolllauf mit 512
| Aufgabe | Messwert |
|---|---:|
| Deutsche Ausgabe, 768 Tokens | 57,2 tok/s |
| Code-Ausgabe, 768 Tokens | 74,9 tok/s |
| Prefill, 24.674 Eingabetokens | 1.782,0 tok/s |
| Ausgabe nach dieser Eingabe, 512 Tokens | 54,8 tok/s |
| Drei eingebaute Fakten wiedergefunden | 3/3 |
Ein Lauf pro Aufgabe; kein umfassender Qualitätstest, kein Vollkontexttest und
kein Test zweier gleichzeitiger Anfragen. Die Vision-Komponente war geladen,
Bilder wurden nicht verarbeitet. TTFT wurde nicht separat gestreamt gemessen.
Die Anfragen verwenden das gespeicherte Text-/Sampling-Protokoll mit deaktiviertem
Promptcache; die Serverkonfiguration einschließlich RAM-Cache blieb unverändert.
Die 512er-Kontrolle ist ein kleiner neuer Vergleichspunkt für das konkrete
Medium-Profil und ersetzt oder verändert die bisherige Qwen-Referenz nicht.
## Entscheidung und möglicher nächster Schritt
**512 bleibt vorerst bestehen.** Ein alleiniger Wechsel auf 256 ist auf Basis
dieses Tests nicht freigegeben. Für einen weiteren Versuch müsste zuerst mehr
Reserve auf der 5080 geschaffen werden, etwa durch eine kleine Verschiebung
weiterer Qwen-Schichten auf die 3060. Dann müsste 256 tatsächlich gemessen werden;
auch dieser mögliche Schritt ist keine Zusage für einen Geschwindigkeitsgewinn.
Kein weiterer Test wurde automatisch gestartet oder eingeplant.
Das ursprüngliche Medium mit Microbatch 512 wurde wiederhergestellt. Medium,
Router, Controller, Gateway und TTS gesund; Router readiness und minimale
Modellantwort geprüft. Keine Xid-, Kernel-Panic-, OOM-Kill- oder
GPU-fallen-off-Meldungen im geprüften Kerneljournal seit Testbeginn. Kein
Host-Neustart und keine Treiber-/Kernel-/Netzwerkänderung.
Rohdaten, genaue Argumente, GPU-Samples, Logs und Wiederherstellungsnachweis:
`experiments/medium-microbatch-20260920/` im Repository und
`/data/benchmarks/medium-microbatch-20260920/` auf Athena.