Prüfe, ob ein geplanter LLM-Batch innerhalb eines vorgegebenen Zeitfensters fertig werden kann. Der Rechner verteilt das Tokenvolumen auf parallele Worker, addiert festen Start- oder Abschluss-Overhead und vergleicht die geschätzte Dauer mit einem SLA-Zeitfenster. Zusätzlich wird die maximale Aufgabenmenge berechnet, die unter denselben Annahmen in das Fenster passt.
Das Hauptresultat ist die geschätzte End-to-End-Batchdauer. Der SLA-Puffer zeigt, ob das Zeitfenster rechnerisch eingehalten wird; die maximale Aufgabenmenge quantifiziert den Spielraum.
Die Berechnung setzt gleichmäßige Arbeitsteilung voraus. Datenbereitstellung, Queueing, stragglende Worker und Rate-Limits können die reale Laufzeit verlängern.
100.000 Aufgaben mit je 900 Tokens ergeben 90 Mio. Tokens. Acht Worker zu je 5.000 Tokens/s verarbeiten sie in 37,5 Minuten; mit 10 Minuten Overhead beträgt die Gesamtdauer 47,5 Minuten. Bei einem 240-Minuten-Fenster bleiben 192,5 Minuten Puffer.
Gib das vierstündige Zeitfenster als 240 Minuten ein und vergleiche die berechnete Gesamtdauer sowie den SLA-Puffer.
Upload, Jobinitialisierung, Queueing-nahe Startzeiten oder Ergebniszusammenführung verursachen oft Zeit, die nicht direkt mit dem Token-Durchsatz skaliert.
Unter idealer Skalierung sinkt die reine Verarbeitungszeit ungefähr umgekehrt proportional zur Workerzahl. In der Praxis können Limits und Koordinationskosten die Skalierung begrenzen.
Er zieht den festen Overhead vom Zeitfenster ab und multipliziert die verbleibende Zeit mit dem gesamten Worker-Durchsatz; anschließend wird durch Tokens je Aufgabe geteilt.
Dann bleibt keine Netto-Verarbeitungszeit. Der Rechner zeigt einen negativen Puffer und eine maximale Aufgabenmenge von null.
| Dimension | Verwendung |
|---|---|
| Primärer Wert | Kapazitäts- oder Kostenentscheidung |
| Sekundärwerte | Plausibilitätsprüfung und Skalierung |
| Annahmen | Mit Produktionsmesswerten regelmäßig aktualisieren |