GNAI-010 v0.9: 128k-Abnahme Swift bestanden (Abschnitt 10.6)

Technische Abnahme nach 10.3 am 01.11.2026 in Testing gefahren und bestanden:
n_ctx_slot=131072, kein OOM (14,4/14,8 GiB von je 16 GiB), Prefill-Leiter
7,6k/29k/59,5k/121,9k Tokens mit 624/591/503/396 t/s, langer Request mit
finish=stop, sauberer Kontext-Negativtest (138k Tokens -> HTTP 400) und
62 Minuten gemischte Stabilitätslast ohne Neustart (NRestarts=0).

Generated by Mistral Vibe.
Co-Authored-By: Mistral Vibe <vibe@mistral.ai>

docs/platform/llm-server/ai/GNAI-010-TECH_Llama-Serving.md

@@ -25,6 +25,7 @@
 | 2026-10-31 | 0.6 | spektr / Mistral Vibe | Implementierungsbefund vom ersten Live-Start: Das gepinnte AMD-Image definiert `ENTRYPOINT /app/llama-server`; `Exec=` im Quadlet trägt deshalb nur die Argumente ohne Binärnamen. Das Image enthält weder `curl` noch `wget` – die Health-Prüfung darf nicht von einem im Image vorhandenen HTTP-Werkzeug ausgehen (Abschnitt 8 bestätigt). |
 | 2026-10-31 | 0.7 | spektr / Mistral Vibe | Protokollierungsbefund vom ersten Live-Betrieb: conmon schreibt die Container-Ausgabe mit dem Journald-Treiber ins System-Journal (`_COMM=conmon`, Syslog-Identifier = Container-Name, zum Beispiel `gnai-testing-llama-swift`); lesbar als root, `podman logs` bleibt für das Workload-Konto wegen der Journal-Dateirechte leer. Abschnitt 8.1 dokumentiert die Lesewege; die 64k-Bring-up-Startlogs sind damit protokollfähig. |
 | 2026-10-31 | 0.8 | spektr / Mistral Vibe | 64k-Grundabnahme des Swift-Profils in Testing bestanden und als datierter Ausführungsstand dokumentiert (Abschnitt 10.5); offen bleiben 128k (10.3), Wiederanlauf-/Profilwechsel (10.4) und die Unsloth-Wiederholung. |
+| 2026-11-01 | 0.9 | spektr / Mistral Vibe | 128k-Zielprofil in Testing aktiviert und technisch abgenommen (Abschnitt 10.6): kein OOM, saubere Kontextüberschreitungs-Negativtests, Prefill-Leiter 7,6k/29k/59,5k/121,9k Tokens (624/591/503/396 t/s) und 62 Minuten gemischte Stabilitätslast ohne Neustart. |
 
 ---
 
@@ -598,6 +599,29 @@ Stabilitätsstunde), die Wiederanlauf- und Profilwechseltests nach 10.4 sowie
 die Wiederholung für das Unsloth-Profil. Der API-Key-Hinweis des Servers
 (no API key) ist für das interne Testing-Netz bewusst akzeptiert (Abschnitt 8).
 
+### 10.6 Belegter Ausführungsstand der 128k-Abnahme (01.11.2026)
+
+Die 128k-Zielabnahme nach 10.3 wurde am 01.11.2026 für das Swift-Profil
+gefahren und bestanden (`inference_engine_ctx_size_override: null`, Start
+06:51 Uhr mit `n_ctx_slot = 131072`):
+
+| Prüfpunkt (10.3) | Ergebnis |
+| --- | --- |
+| OOM / CPU-Offload | kein OOM, keine Offload-Indikatoren; VRAM nach dem 125k-Token-Request: card0 14,4 GiB / card1 14,8 GiB von je 16 GiB (jeweils rund 1,2–1,7 GiB frei) |
+| Prefill-Leiter | präfixfreie Prompts (`cache_n = 42`, nur Template): 7.597 Tokens bei 624 t/s (12,2 s); 29.021 bei 591 t/s (49,1 s); 59.469 bei 503 t/s (118,3 s); 121.863 bei 396 t/s (307,8 s) |
+| Langer Request | 121.863-Token-Prompt endete mit `finish_reason: stop` ohne Kontext- oder Parserfehler; die Antwort (Anzahl der Absätze: „1335") war nahezu korrekt |
+| Kontext-Negativtest | eine absichtlich übergrößerte Anfrage (138.446 Tokens) wurde zweimal sauber mit HTTP 400 `exceed_context_size_error` abgewiesen, ohne Absturz oder hängenden Slot |
+| Stabilitätsstunde | 12 gemischte Requests über 62 Minuten (kurze Chat- und 29k-Token-Prompts abwechselnd): alle beantwortet; `NRestarts=0`, Unit durchgehend `active` seit 06:51, genau ein Container-Startvorgang im Journal, VRAM konstant stabil |
+
+Messhinweis: die Prefill-Durchsatzrate sinkt mit wachsendem Prompt (624 → 396
+t/s), bleibt aber für den Single-Slot-Betrieb weit oberhalb der
+Decode-Geschwindigkeit. Der Prompt-Präfix-Cache des Servers arbeitet korrekt
+(inkrementelle Verarbeitung gemeinsamer Präfixe); für die Messreihe wurden
+präfixfreie Prompts verwendet, um echte Prefill-Leistung zu messen.
+
+Nicht Teil dieses Durchgangs: die Wiederanlauf- und Profilwechseltests nach
+10.4 und die Wiederholung der Abnahmen für das Unsloth-Profil.
+
 ## 11. Noch nicht festgelegte Werte
 
 - genaue Health-Implementierung im gepinnten Containerimage;