4.0 KiB
Medium: Microbatch 512 gegen 256 — Kurztest
Historischer Teststand. Danach wurde Medium auf MTP2/Microbatch256 und Large auf MTP2 übernommen: aktueller Abschluss.
Nachtrag: 256 mit gesenkter Startreserve erfolgreich getestet. 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.