Inferenz-Benchmarks

1. Aktueller Messstand vom 7. Oktober 2026

Die direkte Messung für 90 virtuelle Nutzer mit verteilten kurzen Anfragen besteht vollständig. Neue Messungen mit 64 und 90 gemeinsamen Starts sowie begrenzte lange Kontexte und Thinking bestehen ebenfalls. Der frühere Versuch mit vier fehlenden Antworten bleibt als eigener negativer Befund erhalten. Der Frontendlauf endet mit 117 erfolgreichen Chats als negatives Kapazitätsergebnis. Das vollständige vereinbarte 90er-Profil ist nicht bestanden.

Die 126 Restanfragen umfassen 90 gemeinsame Starts, 22 Fälle mit längeren Eingaben und 14 Thinking-Anfragen. Der ursprüngliche Direktlauf enthält sechs Aufwärmanfragen. Die getrennten Serien werden nicht nachträglich zu einem fehlerfreien ursprünglichen Lauf zusammengelegt.

2. Das tatsächlich gemessene Unterrichtsprofil

Die Hauptmessung verwendet synthetische Aufgaben im Modus Instant. Das Modell war bereits geladen. Die Eingabe umfasste etwa 2.000 Tokens, also Texteinheiten. Die Aufgabe verlangte kurze Antworten aus zwei Sätzen. Das Ausgabelimit von 512 Tokens ist eine Obergrenze, keine gemessene Antwortlänge.

Die Ergebnisse gelten für dieses Profil. Sie belegen keine dauerhaft 512 Tokens langen Antworten und keinen kalten Modellstart. 90 aktive Personen lesen, schreiben und stellen Folgefragen. Sie sind von 90 gleichzeitig offenen Modellanfragen zu unterscheiden.

3. Verteilte Anfragen von 90 Nutzern

Alle 180 Anfragen endeten vollständig und ohne technische Fehler. Die Wartezeit beginnt an der geplanten Ankunft und enthält eine mögliche Aufnahmeverzögerung. Denktext gilt nicht als sichtbarer Antwortbeginn.

Die Messung erfüllt für dieses Profil die vorgeschlagenen Ziele von höchstens fünf Sekunden bis zum sichtbaren Beginn und höchstens 60 Sekunden bis zum vollständigen Abschluss bei p95. Die fachliche Qualität der Antworten und die Benutzung über die Oberfläche werden damit nicht beurteilt.

4. Gemeinsame Starts, lange Eingaben und Thinking

Die Stufen bis 32 gemeinsamen Ankünften waren in jeweils drei Serien vollständig erfolgreich. Im ersten Versuch mit 64 Ankünften fehlten vier Abschlüsse. Eine getrennte neue 64er-Messung und die anschließende 90er-Messung endeten vollständig. Bei gemeinsamen Starts steigen die Wartezeiten, weil Anfragen gleichzeitig ankommen und auf freie Rechenplätze warten können.

Je Nutzerstufe liegen weniger als 100 erfolgreiche Beobachtungen vor. Deshalb werden Minimum, Median und Maximum angegeben. Für diese Stufen wird kein p95 veröffentlicht. Die Zeiten des ursprünglichen 64er-Versuchs beschreiben seine 60 erfolgreichen Antworten. Die vier fehlenden Antworten bleiben in der Bilanz erhalten.

Im neuen 90er-Versuch begann die sichtbare Antwort im Median nach 21,70 Sekunden und war nach 26,81 Sekunden vollständig. Der langsamste sichtbare Beginn lag bei 32,593 Sekunden, der langsamste Abschluss bei 34,948 Sekunden. Keine dieser 90 Antworten begann sichtbar innerhalb von fünf Sekunden. Ein Fünf-Sekunden-Ziel für einen solchen gemeinsamen Start ist deshalb nicht erfüllt. Die verteilten 180 Anfragen erfüllen ihr eigenes Wartezeitziel. Die gemeinsame Startmessung belegt kurze Antworten in diesem konkreten Versuch, keine beliebig große Dauerlast.

Begrenzte längere Eingaben und Thinking

Alle 22 Fälle mit längeren Eingaben und alle 14 Thinking-Anfragen wurden vollständig beantwortet. Die längeren Eingaben wurden mit geringer Parallelität geprüft. Die folgende Tabelle fasst jeweils die geplanten Einzel- und Parallelversuche zusammen.

Bei rund 8.000 Eingabetokens wurden höchstens vier, bei rund 16.000 höchstens zwei und bei rund 30.000 jeweils eine Anfrage gleichzeitig geprüft. Das belegt keine 32 gleichzeitig vollständig gefüllten Kontexte. Die Thinking-Antworten umfassten tatsächlich 149 bis 236 gemeldete Ausgabetokens. Auch für diese kleinen Stichproben wird kein p95 angegeben.

Bei den vier ursprünglichen Fehlanfragen kam keine sichtbare Antwort am Messclient an. Die erfolgreichen Nachmessungen erklären diese frühere Ursache nicht rückwirkend.

5. Frontendlauf: das vollständige Ziel ist nicht bestanden

Alle 90 Testkonten konnten sich anmelden, ihre Sitzung und Bereitschaft prüfen und sich wieder abmelden. Insgesamt wurden 121 Chatanfragen tatsächlich abgeschickt. Davon endeten 117 erfolgreich, vier nach dem Start ohne Erfolg. Weitere 68 vorgesehene Anfragen der 90er-Stufe wurden nicht gestartet. Diese 72 nicht vollständig erfolgreichen vorgesehenen Anfragen sind keine 72 tatsächlichen HTTP-Fehler.

Die folgenden Wartezeiten gelten ausschließlich für erfolgreich abgeschlossene Antworten. Die 108 erfolgreichen Antworten der 90er-Stufe bilden eine Teilmenge. Sie ersetzen keine vollständige Messung aller 180 vorgesehenen Anfragen.

Für die Grundprüfung mit neun Antworten wird kein p95 veröffentlicht. Das sichtbare p95 der 108 erfolgreichen Antworten liegt bei 7,70245 Sekunden und damit über dem vorgeschlagenen Fünf-Sekunden-Ziel. Ein vollständiges p95 für die 180 vorgesehenen Anfragen ist daraus nicht ableitbar.

Was die Abweisung für mehrere Klassen bedeutet

Der Lauf nahm 120 Chataufträge an und wies eine weitere Anfrage mit HTTP 429 ab. Der dokumentierte Produktstandard erlaubt schulweit 120 neue KI-Aufträge in zehn Minuten. Zwei Anfragen von 90 Personen ergeben 180 Aufträge in fünf Minuten. Dieses Unterrichtsprofil passt nicht zu der Standardregel. Eine erfolgreiche Anmeldung aller Personen ist deshalb keine Zusage, alle ihre Anfragen sofort anzunehmen.

Ein künftiger Unterrichtsplan muss die gewünschte Anfragemenge und Wartezeit mit der schulweiten Aufnahme abstimmen. Bei unveränderter Schutzregel müssen Anfragen über längere Zeit verteilt werden. Für mehr Aufträge und kurze Wartezeiten braucht es eine gesondert geprüfte Anpassung von Aufnahme und Queue. Beim Abschluss der Lastdiagnose wurde keine Schutzregel verändert und kein weiterer Modelllauf gestartet.

Leistungsanzeige und Grenzen

Bei allen 117 erfolgreichen Chats war die Leistungsanzeige verfügbar, jeweils mit zwei GPU-Messpunkten. Der Runtimeadapter erfasste 236 Verbindungen ohne Fehler. Das belegt die Funktion während dieses Lastlaufs. Zwei Punkte je Antwort ergeben keine vollständige Leistungskurve oder Bewertung des gesamten Stromverbrauchs. Energiewerte gleichzeitig laufender Chats werden nicht als Gesamt-Systemenergie addiert.

Eine Messung über die Anwendungsschnittstellen und Chatworker ersetzt keine vollständige Prüfung von 90 gleichzeitig geöffneten Browsern. Die verteilten direkten Anfragen, gemeinsame Starts, lange Eingaben und Thinking bleiben getrennte Profile.

Die gemeinsame Last mit 60 Quellen- und 20 Vorleseanfragen wurde nicht gestartet und bleibt ungeprüft. Frühere Vorbereitungsprobleme des Messaufbaus bleiben als eigene Befunde erhalten. Der geschützte Sitzungsprotokollabruf besteht bereits als getrennte Funktionsprobe, gehört aber nicht zu dieser Kapazitätsmessung.

6. Messgrenzen, Ressourcen und Datenschutz

Die frischen Nachkontrollen der direkten Messungen bestätigen erhaltene Betriebsbindungen und Modelleinstellungen sowie keine laufenden oder wartenden Inferenzanfragen. Die beobachteten OOM-Zähler blieben bei null. Die Modelleinstellungen wurden während dieser Messungen nicht verändert.

GPU-Speicher und GPU-Leistungsaufnahme wurden in den direkten Lastläufen nicht gemessen. Der Frontendlauf enthält die getrennt beschriebenen wenigen GPU-Leistungsstichproben. Die Modellgewichte wurden nicht erneut inhaltlich gehasht. Kaltstart, beliebig lange Antworten und große gleichzeitige Kontexte sind durch diese Ergebnisse nicht abgenommen. Die gemeinsame Chat-, Quellen- und Vorleselast bleibt ungeprüft.

Die Streams enthielten Denktext, obwohl die Tokenstatistik dafür jeweils null meldete. Daraus wird keine Rate für rein sichtbare Ausgabetokens abgeleitet. Die Juni-Kennzahl „erster Token“ kann Denktext einbeziehen und ist deshalb nicht präzise mit dem heutigen sichtbaren Antwortbeginn gleichzusetzen.

Die Messungen speichern technische Kennzahlen. Echte Schülerdaten, Chattexte, Zugangsschlüssel und vollständige Modellantworten gehören nicht in die veröffentlichten Ergebnisse. Die beiden Befunde zur Lastdiagnose und die Korrekturen an Messadapter und Erreichbarkeitsprüfung wurden am 7. Oktober 2026 durch Grok 4.7 unabhängig bestätigt. Diese Prüfung betrifft die Messwerkzeuge. Sie erteilt weder eine Kapazitätsfreigabe für 90 Personen noch eine allgemeine Sicherheitsfreigabe des Backends. Weitere formale Backend-Sicherheitsprüfungen bleiben offen.

7. Historische Referenz vom Juni 2026

Der vollständige Instant-Lauf mit gleichzeitigen Starts und der vollständige Instant-Lauf mit verteilten Starts bleiben erhalten. Der Thinking-Lauf wurde nur teilweise durchgeführt und ist keine vollständige Kapazitätsmessung.

Ergebnis: Gleichzeitige Nutzer

Der Gleichzeitigkeitstest vom 03.06.2026 schloss 723 von 723 Messanfragen erfolgreich ab. Die Fehlerquote lag in allen Stufen bei null Prozent. Gleichzeitig zeigt der Lauf eine deutliche Sättigungskurve: Ab etwa 24 bis 32 gleichzeitig gestarteten Anfragen wird die interne Warteschlange sichtbar.

Gleichzeitige Nutzer	Erfolgreich	Fehlerquote	p50 Latenz	p95 Latenz	p50 erster Token	p95 erster Token	Durchsatz
1	3/3	0 %	6,8 s	8,8 s	0,2 s	0,2 s	20,0/min
2	6/6	0 %	10,3 s	11,3 s	0,3 s	0,3 s	31,4/min
4	12/12	0 %	16,4 s	17,7 s	0,3 s	0,3 s	40,4/min
8	24/24	0 %	20,5 s	24,2 s	0,3 s	0,3 s	58,4/min
16	48/48	0 %	27,9 s	32,9 s	0,3 s	13,1 s	76,7/min
24	72/72	0 %	34,5 s	57,5 s	0,4 s	30,6 s	72,7/min
32	96/96	0 %	51,3 s	69,4 s	22,3 s	47,6 s	79,9/min
64	192/192	0 %	78,3 s	135,3 s	50,0 s	108,2 s	78,5/min
90	270/270	0 %	108,1 s	196,3 s	73,7 s	163,2 s	75,5/min

Der Durchsatz steigt zuerst an und erreicht dann ein Plateau im Bereich von etwa 75 bis 80 Antworten pro Minute. Zusätzliche Gleichzeitigkeit erhöht den Durchsatz danach nicht mehr wesentlich, sondern verlängert vor allem die Wartezeit.

So liest man das Diagramm: Die waagerechte Achse zeigt die Zahl gleichzeitig gestarteter Nutzerinnen und Nutzer, die senkrechte Achse die Sekunden bis zur fertigen Antwort. p50 beschreibt den typischen Fall, p90 und p95 die langsameren Fälle. Wichtig ist der Knick ab etwa 24 bis 32 gleichzeitigen Starts: Ab dort wächst vor allem die Wartezeit in der Queue.

So liest man das Diagramm: Die waagerechte Achse zeigt wieder die gleichzeitigen Starts, die senkrechte Achse die erfolgreich abgeschlossenen Antworten pro Minute. Eine steigende Linie bedeutet, dass zusätzliche Last noch in mehr abgeschlossene Antworten umgesetzt wird. Das Plateau bei etwa 75 bis 80 Antworten pro Minute zeigt die praktische Kapazitätsgrenze dieses Laufs.

So liest man das Diagramm: Jede Säule steht für eine Laststufe, die senkrechte Achse zeigt den Anteil fehlgeschlagener Anfragen. Null Prozent in allen Stufen bedeutet: Die Anfragen wurden technisch angenommen und abgeschlossen. Für das Nutzergefühl müssen trotzdem die Latenzgrafiken daneben gelesen werden.

Ergebnis: Zufallsverteilte Anfragen

Das Fünf-Minuten-Szenario vom 04.06.2026 schloss 350 von 350 Messanfragen erfolgreich ab. Aus Schulsicht ist dieses Szenario besonders wichtig, weil Unterrichtslast selten exakt gleichzeitig entsteht.

Virtuelle Nutzer in 5 Minuten	Erfolgreich	Fehlerquote	Max. Parallelität	p50 Latenz	p95 Latenz	p50 erster Token	p95 erster Token	Durchsatz
50	50/50	0 %	6	15,1 s	23,0 s	0,3 s	0,4 s	9,5/min
100	100/100	0 %	17	27,3 s	37,0 s	0,4 s	0,5 s	18,6/min
200	200/200	0 %	71	94,0 s	144,3 s	62,9 s	114,0 s	27,4/min

50 zufallsverteilte Anfragen in fünf Minuten sind in diesem Lauf unproblematisch. Auch 100 zufallsverteilte Anfragen sehen für reale schulische Nutzung gut aus: alle Anfragen waren erfolgreich, die p95-Gesamtlatenz lag bei 37 Sekunden und die Zeit bis zum ersten Token blieb niedrig.

200 zufallsverteilte Anfragen in fünf Minuten zeigen die Reserve und die Grenze zugleich: Ephraim bleibt stabil, aber die p50-Zeit bis zum ersten Token steigt auf 62,9 Sekunden. Der Benchmark-Runner selbst startete die Anfragen pünktlich. Die Verzögerung entsteht nach Annahme der Anfragen in der Inferenz-Abarbeitung.

So liest man das Diagramm: Die waagerechte Achse zeigt die fünf Minuten in Zeitfenstern, die senkrechte Achse die neu gestarteten Anfragen je Fenster. Einzelne Spitzen sind bei Zufallsverteilung normal. Entscheidend ist, wie dicht mehrere Spitzen aufeinander folgen, weil genau dann die Warteschlange schnell wächst.

So liest man das Diagramm: Die waagerechte Achse zeigt den Verlauf des Messzeitraums, die senkrechte Achse die typische Gesamtdauer abgeschlossener Antworten. Eine stabile Linie bedeutet, dass die Spark ungefähr so schnell abarbeitet, wie neue Arbeit hinzukommt. Eine steigende Linie zeigt, dass die Queue wächst und spätere Anfragen länger warten müssen.

So liest man das Diagramm: Die waagerechte Achse zeigt die Zeit, die senkrechte Achse die abgeschlossenen Antworten pro Minute. Die Kurve darf der Startgrafik nicht eins zu eins entsprechen: Starts erzeugen Arbeit, Durchsatz zeigt erledigte Arbeit. Wenn viele Starts auftreten, der Durchsatz aber nicht entsprechend steigt, wird die überschüssige Arbeit in der Queue gespeichert.