Präzise KI-Kapazitätsplanung: SLA-basierte Dimensionierung mit der Engsets Formel

Wenn Ihr CFO fragt “Wie viele KI-Server brauchen wir?”, zucken die meisten Anbieter mit den Schultern und sagen “Das hängt davon ab …” Uns ist das nicht ausreichend. Wir haben darum ein Verfahren entwickelt, das Ihnen eine mathematisch präzise Antwort gibt.

Dieses Whitepaper erklärt die Warteschlangentheorie hinter unserem LLM Hardware Cost Calculator und warum dies für Unternehmen wichtig ist, die On-Premise-KI-Bereitstellungen planen.

Executive Summary

Die meisten KI-Kapazitätsplanungen basieren heute auf Schätzungen: “Wir haben 50 Benutzer, also vielleicht 2 Server?” Dieser Ansatz führt entweder zu Unterdimensionierung (frustrierte Benutzer, langsame Antworten) oder Überdimensionierung (verschwendetes Budget, ungenutzte Hardware).

Wir lösen dies mit Engsets Formel—Mathematik aus dem Jahr 1915, die über ein Jahrhundert lang zuverlässige private Telefonnetze gewährleistet hat. Indem wir KI-Inferenz-Anfragen wie Telefonanrufe an eine Unternehmenszentrale behandeln, können wir genau berechnen, wie viele “Leitungen” (Hardwarekapazität) Sie benötigen, um ein bestimmtes Servicelevel zu garantieren.

Warum Engset? Im Gegensatz zu den bekannteren Erlang-Formeln (entwickelt für öffentliche Netze mit unbegrenzten Anrufern) wurde Engset speziell für endliche Populationen entwickelt—genau wie Ihr Unternehmen mit einer bekannten Anzahl von Mitarbeitern. Die Verwendung von Erlang B für die Unternehmens-Kapazitätsplanung führt zu systematischer Überdimensionierung; Engset gibt Ihnen die mathematisch korrekte Antwort.

Wesentliche Vorteile:

Mathematische Garantien statt fundierter Schätzungen
SLA-basierte Dimensionierung: “95% der Benutzer erhalten 40 Tokens/Sekunde” wird zu einer lösbaren Gleichung
Kostenoptimierung: Weder zu viel noch zu wenig Hardware (Engset vermeidet Erlang Bs Überdimensionierung)
Vorhersagbare Leistung: Wissen Sie genau, was Sie Stakeholdern versprechen können
Jahrhundertbewährt: Die gleiche Mathematik, die Unternehmens-Telefonsysteme weltweit dimensioniert

Teil 1: Das Problem mit traditioneller Dimensionierung

Bestehende Ansätze und ihre Limitationen

Während es mehrere Online-Vorschläge zur Hardware-Dimensionierung für KMU-große LLM-Systeme gibt, basieren sie meist auf groben Heuristiken statt auf rigorosen mathematischen Modellen. Aktuelle Berechnungsmethoden fallen in drei Kategorien:

VRAM-zentrierte Dimensionierungsleitfäden

Mehrere Anbieter konzentrieren sich auf “passt dieses Modell und dieser Kontext in den GPU-Speicher” mit nur informellen Gleichzeitigkeit-Daumenregeln:

Lenovos LLM-Dimensionierungsleitfaden gibt Formeln zur Schätzung des GPU-Speichers basierend auf Modellgröße, Sequenzlänge, Attention-Heads, Präzision und Batch-Größe, behandelt dann “Anzahl gleichzeitiger Benutzer” im Wesentlichen als Batch-Größe. Er bietet kein probabilistisches Gleichzeitigkeits- oder SLA-Modell; stattdessen schlägt er vor, Kundenanforderungen zu sammeln und Stresstests durchzuführen.
Baseboxs Hardware-Dimensionierungsleitfaden gibt explizite Gleichzeitigkeits-Heuristiken für KMUs (z. B. für “intensive Nutzung” 50 Gesamtbenutzer → 15–25 gleichzeitige Benutzer, 100 Gesamtbenutzer → 30–50 gleichzeitige Benutzer), löst dann eine einzelne GPU-Empfehlung zurück. Dies ist im Wesentlichen eine Daumenregel für Spitzengleichzeitigkeit, keine warteschlangenbasierte Dimensionierung.
Puget Systems VRAM-Dimensionierungsleitfaden wählt GPU-Anzahlen, indem er Modell+Kontext+Batch VRAM-Nutzung prüft und dann “zur Sicherheit” eine zusätzliche GPU hinzufügt, wenn mehr Benutzer oder Tokens auftauchen, wieder ohne formales SLA-Wahrscheinlichkeitsmodell.

Die Einschränkung: Diese Leitfäden beantworten “welche GPU-Spezifikation brauche ich für mein Modell und Batch?”, aber sie beantworten nicht “für 50 Bürobenutzer, welche Hardware garantiert X Tokens/Sekunde bei P95?”

Cloud-Quota / TPM-basierte Planung

Andere Leitfäden gehen von SaaS-APIs aus und dimensionieren um Provider-Quoten (TPM/RPM), nicht um On-Premise-Hardwarekapazität:

Azure OpenAI / Databricks Kapazitätsleitfäden erklären Tokens-pro-Minute (TPM) und Requests-pro-Minute (RPM) Quoten, führen dann durch die Schätzung von TPM aus Benutzeranzahl, Anfragen pro Benutzer, interne Agent-Aufrufe pro Anfrage und durchschnittlichen Prompt/Antwort-Token-Längen. Sie fügen einen Puffer hinzu (z. B. 20%) und wählen eine Anmeldestufe, die ausreichend TPM bietet.
Palantirs LLM-Kapazitätsverwaltung beschreibt die Reservierung von TPM und RPM für interaktive Abfragen vs. Batch-Jobs und erzwingt eine feste Aufteilung (z. B. 20% Kapazität für interaktiv reserviert), behandelt Kapazität aber als harte Quote und verwendet keine Engset/Erlang-ähnlichen Modelle.

Die Einschränkung: Diese Ansätze sind konzeptionell nah (Tokens/Zeit als Einheit, interaktiv vs. Batch), aber sie dimensionieren gegen eine Quotentabelle, nicht gegen eine geschlossene Blockierungswahrscheinlichkeit für eine endliche Benutzerbasis.

KMU-orientierte “Local LLM” Rechner

Einige Tools zielen explizit auf “KMU-große” oder “Local LLM” Bereitstellungen ab, sind aber hauptsächlich heuristisch:

Generische VRAM-Rechner wie “Can You Run This LLM?” lassen Sie ein Modell und einen Kontext auswählen und sagen Ihnen, wie viel VRAM Sie benötigen, modellieren aber keine Benutzerpopulationen oder SLAs.
Local-LLM-Hardware-Leitfäden (Introl, OpenMetal, etc.) ordnen Beispielorganisationen (10, 50, 100 Benutzer) ein oder zwei GPU-SKUs basierend auf angenommener Modellgröße und breiten “leicht/mittel/schwer” Nutzungskategorien zu, ohne ein probabilistisches Gleichzeitigkeits- oder Blockierungsmodell.

Die Einschränkung: Diese Tools bieten grobe Zuordnungen, aber es fehlt ihnen die mathematische Rigorosität, um spezifische SLA-Perzentile zu garantieren.

Was unseren Ansatz auszeichnet

Unser LLM Hardware Cost Calculator ist eines der sehr wenigen öffentlichen Tools, das die Hardware-Dimensionierung für KMUs explizit als ein SLA-basiertes, wahrscheinlichkeitsgetriebenes Kapazitätsplanungsproblem mit endlichen Benutzern formuliert, statt nur VRAM und Spitzengleichzeitigkeit zu raten.

Kurz gesagt: Während es mehrere Online-Vorschläge zur Hardware-Dimensionierung für KMU-große LLM-Systeme gibt, verwenden sie meist VRAM-plus-Heuristiken oder TPM-Quoten-Arithmetik. Die Engset-basierte endliche-Population SLA-Dimensionierung in diesem Whitepaper ist wirklich rigoroser und vergleichsweise einzigartig—sie bietet mathematische Garantien statt fundierter Schätzungen.

Die Konsequenzen

Für Unternehmen hat es echte Kosten, wenn dies falsch gemacht wird:

Unterdimensioniert: Benutzer warten 30+ Sekunden auf Antworten → Produktivitätsverlust, Frustration, Shadow IT (Benutzer wechseln zu Cloud-APIs, was den Zweck von On-Premise zunichtemacht)
Überdimensioniert: €50.000+ in ungenutzten GPUs → verschwendetes Kapital, schwerer zu rechtfertigende zukünftige KI-Investitionen

Teil 2: Eine Lösung aus der Telekommunikation

Die Ursprünge: 1915–1918

Tore Olaus Engset, ein norwegischer Ingenieur, entwickelte sein Finite-Source-Loss-Modell in einem Manuskript von 1915 und veröffentlichte es 1918, um frühe automatische Telefonvermittlungsstellen zu dimensionieren. Seine Arbeit geht tatsächlich den bekannteren Erlang-Formeln voraus oder läuft parallel zu ihnen—beide wurden zu grundlegenden Säulen der Warteschlangen- und Fernmeldeverkehrstheorie.

Engsets Problem war identisch mit unserem: Wie viele Telefonleitungen benötigt eine private Vermittlungsstelle (Nebenstellenanlage), damit Anrufer selten ein Besetztzeichen hören?

Wie KI-Anfragen sind Telefonanrufe:

Sporadisch: Benutzer rufen nicht kontinuierlich an
Variable Dauer: Einige Anrufe sind kurz, andere lang
Aus einer endlichen Population: Ihr Unternehmen hat eine feste Anzahl von Mitarbeitern

Engsets Durchbruch war die Modellierung endlicher Populationen, bei denen Kapazität explizit pro Quelle zugewiesen wird. Im Gegensatz zu öffentlichen Netzen (wo Nachfrage von überall kommen kann) bedient eine private Vermittlungsstelle eine bekannte Gruppe von Teilnehmern, jeder mit einem definierten Serviceanspruch. Dies ermöglichte präzises “Servicegrad”-Engineering: Bei N Benutzern und Ziel-Blockierungswahrscheinlichkeit die genaue Anzahl benötigter Leitungen berechnen.

Die Analogie

Telefonvermittlungsstelle	KI-Inferenz-System
Telefonleitungen	GPU-Rechenkapazität
Anrufer	Benutzer, die KI-Anfragen stellen
Anrufdauer	Anfrageverarbeitungszeit
Besetztzeichen	Anfrage wartet/überschreitet Zeitlimit
Blockierungswahrscheinlichkeit	Wahrscheinlichkeit, dass Benutzer keinen sofortigen Service erhält
Nebenstellenanlage (Nebenstelle)	On-Premise-KI-Bereitstellung

Die zentrale Erkenntnis: Ihr KI-System ist eine “private Vermittlungsstelle” mit einer bekannten, endlichen Anzahl potenzieller Benutzer—genau das, wofür Engsets Formel vor über einem Jahrhundert entwickelt wurde.

Teil 3: Warum Engset, nicht Erlang B?

Dies ist vielleicht die wichtigste technische Entscheidung in unserem Modell. Lassen Sie uns das erklären.

Die Erlang-Familie

Die meisten Ingenieure kennen Erlang B (für Blockierungswahrscheinlichkeit) und Erlang C (für Warteschlangen). Diese Formeln, entwickelt vom dänischen Mathematiker A.K. Erlang um 1917, nehmen eine unendliche Population potenzieller Anrufer an—angemessen für öffentliche Telefonnetze, wo die Anzahl möglicher Anrufer im Wesentlichen unbegrenzt ist.

Der kritische Unterschied

Modell	Populationsannahme	Am besten für
Erlang B	Unendliche Quellen	Öffentliche Netze, Cloud-APIs, großskalige Dienste
Engset	Endliche Quellen	Private Vermittlungsstellen, Unternehmenssysteme, bekannte Benutzeranzahlen

Warum ist das wichtig? Der entscheidende Unterschied liegt in der Nachfragemodellierung, nicht in physischen Beschränkungen.

Engset modelliert die Wahrscheinlichkeitsverteilung gleichzeitiger Nachfrage aus einer bekannten Population. Bei N Benutzern mit bekannten Nutzungsmustern sagt es voraus: “Wie hoch ist die Wahrscheinlichkeit, dass X Benutzer gleichzeitig Kapazität benötigen?”

Dies ermöglicht Bereitstellung basierend auf Wahrscheinlichkeiten:

Bei $P_{95}$: Dimensionieren, sodass gleichzeitige Nachfrage nur 5% der Zeit die Kapazität überschreitet
Bei $P_{99}$: Dimensionieren, sodass gleichzeitige Nachfrage nur 1% der Zeit die Kapazität überschreitet

Erlang B, das unendliche Quellen annimmt, überschätzt die Spitzennachfrage für kleine Populationen—was zu Überdimensionierung führt. Engset gibt die statistisch korrekte Antwort für Unternehmens-Bereitstellungen.

Die Kosten der Verwendung des falschen Modells

Wenn das Verhältnis von Benutzern zu Kanälen klein ist (typisch für Unternehmens-Bereitstellungen), überschätzt Erlang B systematisch die Blockierungswahrscheinlichkeit:

Szenario: 20 Benutzer, 5 Kanäle, moderate Last

Modell	Blockierungswahrscheinlichkeit
Erlang B Vorhersage	~12% Blockierung
Engset Vorhersage	~6% Blockierung
Realität	Näher an Engset

Die Verwendung von Erlang B für die Unternehmens-Kapazitätsplanung führt zu Überdimensionierung: Sie kaufen Hardware, die Sie nicht benötigen, weil das Modell einen Worst-Case annimmt, der mit einer endlichen Benutzerbasis tatsächlich nicht eintreten kann.

Konvergenz bei großer Skala

Für sehr große Benutzerpopulationen konvergieren Engset und Erlang B zum gleichen Ergebnis—weshalb Erlang B in der öffentlichen Telekommunikationsplanung dominant wurde. Aber für Unternehmens-KI-Bereitstellungen mit 5, 50 oder sogar 500 bekannten Benutzern ist der Unterschied erheblich und Engset ist die mathematisch korrekte Wahl.

Keine historische Kuriosität

Engsets Formel ist über ein Jahrhundert alt, aber immer noch das richtige Werkzeug für [Finite-Source-Systeme](https://repositum.tuwien.at/bitstream/20.500.12708/13123/2/Dombacher Christian - 2010 - Queueing models for call centres.pdf). Sie wurde nicht so sehr “überholt” als vielmehr in die moderne Warteschlangentheorie eingebettet. Zeitgenössische Fernmeldeverkehrs-Lehrbücher präsentieren Engset neben Erlang als die Standard-Finite-Source-Loss-Formel. Aktuelle Forschung entwickelt weiterhin effiziente numerische Methoden zur Berechnung von Engset-Wahrscheinlichkeiten und erweitert das Modell auf moderne Netzwerkkontexte.

In der praktischen Ingenieursarbeit erscheinen Engset-ähnliche Modelle immer noch in:

Unternehmens-Telefonie (Nebenstellenanlagen)
[Call-Center-Kapazitätsplanung](https://repositum.tuwien.at/bitstream/20.500.12708/13123/2/Dombacher Christian - 2010 - Queueing models for call centres.pdf)
Unternehmens-IT-Systeme mit bekannten Benutzeranzahlen
On-Premise-KI-Bereitstellungen ← das sind wir

Optionale Verbesserung: QoS Traffic Shaping

Das Engset-Modell dimensioniert Kapazität so, dass Nachfrage selten das Angebot überschreitet. Für die meisten Bereitstellungen ist dies ausreichend—Benutzer erleben natürlicherweise gute Leistung, weil das System nicht überlastet ist.

Für hochausgelastete oder mission-kritische Bereitstellungen bietet jedoch eine QoS-Schicht (Quality of Service) zusätzliche Garantien:

Szenario	Ohne QoS	Mit QoS
Niedrige Last	Alle Benutzer erhalten exzellente Geschwindigkeit	Gleich
Spitzenlast	First-Come-First-Served (einige Benutzer erhalten möglicherweise weniger)	Faire Verteilung an alle Benutzer
Überlastung	Verschlechterung für alle	Sanfte Drosselung, garantierte Mindestwerte

Wann QoS in Betracht ziehen:

Hohe SLA-Perzentile ($P_{99}$, $P_{100}$), bei denen Fairness während Spitzen kritisch ist
Multi-Tenant-Bereitstellungen, bei denen Isolation zwischen Benutzergruppen wichtig ist
Regulierte Branchen, die überprüfbare Servicegarantien erfordern

Für die meisten Unternehmens-Bereitstellungen bietet die korrekte Dimensionierung über Engset die primäre Garantie. QoS ist eine architektonische Verbesserung, keine Voraussetzung.

Teil 4: Das mathematische Modell

Definition des Systems

Wir modellieren eine On-Premise-LLM-Bereitstellung als M/M/c/c/N Loss-System:

$N$ Benutzer (endliche Population: Ihre Mitarbeiter)
$c$ Kanäle (Servicekapazität bei garantierter Rate)
Keine Warteschlange (wenn besetzt, wird Anfrage “blockiert”—Benutzer erlebt Verzögerung)

Ein Kanal repräsentiert die Kapazität, einen Benutzer mit der garantierten Rate zu bedienen:

$$\text{Kanäle} = \left\lfloor \frac{\text{Gesamtsystemkapazität}}{\text{garantierte_Rate_pro_Benutzer}} \right\rfloor$$

Zum Beispiel: Ein System mit 120 Tokens/Sekunde Gesamtkapazität, das 40 Tokens/Sekunde pro Benutzer garantiert, hat 3 Kanäle (kann 3 Benutzer gleichzeitig mit voller Geschwindigkeit bedienen).

Verkehrsintensität (Erlang)

Erlang ist die Standardeinheit für Telekommunikationsverkehr. Sie repräsentiert die durchschnittliche Anzahl gleichzeitiger “Anrufe” (Anfragen) in Bearbeitung:

$$\text{Verkehr (Erlang)} = \frac{\text{gesamt_angeforderte_Tokens_pro_Sekunde}}{\text{garantierte_Tokens_pro_Benutzer}}$$

Wenn Ihre 50 Benutzer gemeinsam eine durchschnittliche Nachfrage von 100 Tokens/Sekunde generieren und Sie 40 Tokens/Sekunde pro Benutzer garantieren:

$$\text{Verkehr} = \frac{100}{40} = 2,5 \text{ Erlang}$$

Das bedeutet, dass durchschnittlich 2,5 “Kanäle” zu jedem Zeitpunkt in Nutzung sind.

Die Engset-Formel

Für $N$ Benutzer, $m$ Kanäle und Verkehrsintensität $a$ pro Benutzer ist die Blockierungswahrscheinlichkeit:

$$P_b = \frac{P(m)}{\sum_{i=0}^{m} P(i)}$$

Wobei Zustandswahrscheinlichkeiten folgen:

$$\frac{P(i)}{P(i-1)} = \frac{N - i + 1}{i} \cdot \beta \quad \text{wobei} \quad \beta = \frac{a}{1 - a}$$

Machen Sie sich keine Sorgen, wenn dies komplex aussieht. Die zentrale Erkenntnis: Bei Ihrer Benutzeranzahl, ihren Nutzungsmustern und Ihrer Hardwarekapazität können wir die genaue Wahrscheinlichkeit berechnen, dass ein Benutzer verschlechterten Service erlebt.

SLA-Compliance

Ein SLA wie “P95: 40 Tokens/Sekunde Minimum” bedeutet:

95% der Zeit erhält jeder Benutzer mindestens 40 Tokens pro Sekunde.

Hier dient Tokens pro Sekunde (TPS) als zentrale Durchsatzmetrik für LLM-Inferenz. Die Beziehung zwischen Durchsatz, Latenz und benutzerwahrgenommener Leistung ist in der LLM-Serving-Literatur gut etabliert.

Mathematisch:

$$(1 - P_b) \geq 95%$$

Was bedeutet:

$$P_b \leq 5%$$

Unser Solver findet die minimale Hardware, die diese Garantie erreicht. Dieser probabilistische SLA-basierte Ansatz steht im Kontrast zu dynamischen Batching-Optimierungen und bietet geschlossene Garantien statt Laufzeit-Scheduling-Entscheidungen.

Teil 5: SLA-Stufen erklärt

Verschiedene Geschäftskontexte erfordern unterschiedliche Zuverlässigkeitsniveaus:

SLA-Stufe	Blockierung erlaubt	Typischer Anwendungsfall	Hardwareauswirkung
P90	10%	Interne Tools, nicht-kritische Apps	Kosteneffizienteste
P95	5%	Professionelle Büroumgebungen	Standardwahl
P99	1%	Geschäftskritische Systeme	Höhere Redundanz erforderlich
P100	0%	Mission-kritisch, regulierte Branchen	Maximale Kapazität

Interpretation in der Praxis

P90: “9 von 10 Anfragen erhalten volle Geschwindigkeit.” Akzeptabel für Entwicklertools, internen Chat.
P95: “19 von 20 Anfragen erhalten volle Geschwindigkeit.” Gut für allgemeine Büroproduktivität.
P99: “99 von 100 Anfragen erhalten volle Geschwindigkeit.” Erforderlich für kundenorientierte, finanzielle, medizinische Anwendungen.
P100: “Jede einzelne Anfrage erhält volle Geschwindigkeit.” Für Systeme, bei denen jede Verzögerung inakzeptabel ist.

Die Kostenkurve ist nichtlinear. Der Übergang von $P_{95}$ zu $P_{99}$ könnte $2\times$ die Hardware erfordern. Der Übergang von $P_{99}$ zu $P_{100}$ könnte $3\times$ mehr erfordern. Wählen Sie weise.

Teil 6: Die serielle Durchsatzbeschränkung

Eine kritische Einschränkung

Es gibt eine Beschränkung, die reine Warteschlangentheorie nicht erfasst: Kein einzelner Benutzer kann mehr Tokens pro Sekunde erhalten, als eine Hardwareeinheit produzieren kann.

Selbst mit 10 GPUs, die 1.200 Tokens/Sekunde Gesamtkapazität bereitstellen, wenn jede GPU bei 120 Tokens/Sekunde maximiert, kann kein einzelner Benutzer jemals mehr als 120 Tokens/Sekunde erhalten.

Warum dies wichtig ist

Szenario	Gesamtkapazität	Pro-Einheit-Geschwindigkeit	Benutzererfahrung
4× AMD (30 TPS jeweils)	120 TPS	30 TPS	Jeder Benutzer erhält max. 30 TPS
1× NVIDIA (120 TPS)	120 TPS	120 TPS	Jeder Benutzer erhält max. 120 TPS

Gleiche Gesamtkapazität, sehr unterschiedliche Benutzererfahrung. Für interaktive Anwendungsfälle (Chat, Code-Vervollständigung) ist die Pro-Einheit-Geschwindigkeit genauso wichtig wie die Gesamtkapazität.

SLA-Unmöglichkeit

Wenn Ihr SLA 40 Tokens/Sekunde Minimum erfordert, aber Ihre Hardware nur 30 Tokens/Sekunde pro Einheit produziert, ist das SLA unmöglich zu erfüllen—unabhängig davon, wie viele Einheiten Sie bereitstellen.

$$\text{Wenn } v_{\text{Einheit}} < v_{\text{garantiert}} \Rightarrow \text{SLA unmöglich}$$

Unser Rechner erkennt dies und warnt Sie, entweder:

Die garantierte Rate zu senken
Schnellere Hardware zu wählen

Teil 7: Praktische Anwendung

Der Solver-Algorithmus

Unser Rechner implementiert diese Logik:

$$ \begin{aligned} &\textbf{Für } u = 1 \text{ bis } u_{\max}: \ &\quad 1.; C = u \times v_{\text{Einheit}} \ &\quad 2.; m = \left\lfloor C / v_{\text{garantiert}} \right\rfloor \ &\quad 3.; P_b = \text{Engset}(N, m, a) \ &\quad 4.; \textbf{Wenn } (1 - P_b) \geq \text{SLA}{\text{Ziel}}: \textbf{ Return } u \ &\textbf{Return } u{\max} \text{ (SLA bei dieser Skala unmöglich)} \end{aligned} $$

Beispiel: Software-Startup

Szenario:

3 Büroangestellte (5.000 Tokens/Stunde jeweils)
6 Entwickler (50.000 Tokens/Stunde jeweils)
SLA: P95 bei 40 Tokens/Sekunde
Hardware: AMD Ryzen AI Max+ 395 (30 TPS pro Einheit)

Berechnung:

$$ \begin{aligned} N &= 9 \text{ Benutzer} \ \text{Nachfrage} &= 315{.}000 \text{ Tokens/Stunde} = 87,5 \text{ TPS} \ \text{Verkehr} &= \frac{87,5}{40} = 2,19 \text{ Erlang} \end{aligned} $$

Für 3 AMD-Einheiten ($C = 90$ TPS, $m = 2$ Kanäle bei 40 TPS):

$$P_b \approx 8% \quad \Rightarrow \quad \text{Erfolgsrate} = 92% < 95% ;; ❌$$

Für 4 AMD-Einheiten ($C = 120$ TPS, $m = 3$ Kanäle bei 40 TPS):

$$P_b \approx 2% \quad \Rightarrow \quad \text{Erfolgsrate} = 98% \geq 95% ;; ✅$$

Ergebnis: 4 AMD-Einheiten erforderlich

Beispiel: Arztpraxis

Szenario:

8 Büroangestellte (8.000 Tokens/Stunde jeweils)
SLA: P99 bei 30 Tokens/Sekunde (höhere Zuverlässigkeit für medizinische Anwendungen)
Hardware: NVIDIA RTX Pro 6000 (120 TPS pro Einheit)

Berechnung:

$$ \begin{aligned} N &= 8 \text{ Benutzer} \ \text{Nachfrage} &= 64{.}000 \text{ Tokens/Stunde} = 17,8 \text{ TPS} \ \text{Verkehr} &= \frac{17,8}{30} = 0,59 \text{ Erlang} \end{aligned} $$

Für 1 NVIDIA-Einheit ($C = 120$ TPS, $m = 4$ Kanäle bei 30 TPS):

$$P_b \approx 0,1% \quad \Rightarrow \quad \text{Erfolgsrate} = 99,9% \geq 99% ;; ✅$$

Ergebnis: 1 NVIDIA-Einheit erforderlich

Teil 8: Auslastung vs. Kapazität

Das Paradox der niedrigen Auslastung

Eine häufige Frage: “Wenn ich nur 4 Einheiten für mein SLA benötige, warum ist die durchschnittliche Auslastung nur 15%?”

Antwort: SLAs betreffen Worst-Case-Garantien, nicht durchschnittliche Leistung.

Metrik	Optimiert für	Ergebnis
Durchschnittliche Auslastung	Kosteneffizienz	Benutzer warten während Spitzen
SLA-Compliance	Benutzererfahrung	Kapazität verfügbar, wenn benötigt

Denken Sie daran wie an Feuerlöscher: Sie stehen 99,9% der Zeit ungenutzt herum, aber Sie würden sie niemals entfernen, um die “Auslastung zu verbessern”.

Wann niedrige Auslastung erwartet wird

Hohe SLA-Perzentile ($P_{99}$, $P_{100}$): Muss seltene Spitzenereignisse bewältigen
Burstige Nutzungsmuster: Entwickler können während Coding-Sprints $50\times$ die durchschnittliche Last generieren
Kleine Benutzerpopulationen: Statistische Glättung erfordert mehr Spielraum

Teil 9: Visualisierung und Überwachung

SLA-Compliance-Diagramm

Zeigt Spielraum (Prozentsatz über/unter SLA) über alle Perzentilebenen:

Positiver Spielraum: System übertrifft Anforderungen (grüne Zone)
Null Spielraum: System erfüllt SLA genau (Schwelle)
Negativer Spielraum: System erfüllt SLA nicht (rote Zone)

TPS pro Benutzer Diagramm

Zeigt die maximale Tokens/Sekunde, die jeder Benutzer bei jedem Perzentil erhalten kann:

Über “Erforderlich”-Linie: SLA wird erfüllt
Unter “Erforderlich”-Linie: SLA wird nicht erfüllt
Begrenzt auf Einheitsgeschwindigkeit: Serielle Durchsatzbeschränkung sichtbar

Diese Diagramme helfen zu visualisieren, nicht nur ob Sie Ihr SLA erfüllen, sondern wie viel Spielraum Sie haben.

Häufig gestellte Fragen

Warum Engset statt Erlang B oder Erlang C verwenden?

Dies ist die zentrale technische Entscheidung, die in Teil 3 oben erklärt wird. Kurz gesagt:

Erlang B/C nehmen unendliche Quellen an → entwickelt für öffentliche Netze, wo Nachfrage von überall kommen kann
Engset nimmt endliche Quellen an → entwickelt für Unternehmenssysteme, bei denen Sie Kapazität pro bekanntem Benutzer bereitstellen

Für Unternehmens-KI-Bereitstellungen (5–500 Benutzer) überschätzt Erlang B die erforderliche Kapazität um 50–100%, was zu teurer Überdimensionierung führt. Engset modelliert eine Bereitstellungsstrategie, bei der jeder Benutzer einen definierten Serviceanspruch hat, durchgesetzt durch QoS-Mechanismen.

Beide Formeln wurden um 1915–1918 entwickelt und bleiben grundlegend in der Fernmeldeverkehrstechnik. Für große Populationen (Tausende von Benutzern) konvergieren sie. Für Unternehmensskala ist Engset mathematisch korrekt.

Können Benutzer mehrere parallele Anfragen stellen?

Ja—Benutzer können mehrere Tabs haben, parallele API-Aufrufe machen usw. Das Engset-Modell nimmt keine physischen Beschränkungen an; es modelliert die statistische Wahrscheinlichkeit gleichzeitiger Nachfrage aus einer bekannten Population. Bei gegebenen Nutzungsmustern (Tokens/Stunde pro Benutzertyp) sagt es voraus, wie oft die Gesamtnachfrage verschiedene Niveaus erreicht. Wir dimensionieren Hardware so, dass Nachfrage Kapazität nur mit der akzeptablen Rate überschreitet (z. B. 5% für P95).

Benötige ich QoS-Software, damit dies funktioniert?

Nein. Engset dimensioniert Kapazität basierend auf Nachfragewahrscheinlichkeit. Wenn korrekt dimensioniert, ist das System bei Ihrem Ziel-Perzentil nicht überlastet—Benutzer erleben natürlicherweise gute Leistung. QoS ist eine optionale Verbesserung für mission-kritische Bereitstellungen, bei denen faire Verteilung während seltener Spitzenereignisse wesentlich ist, oder für Multi-Tenant-Isolation.

Was ist, wenn meine Benutzer sehr unterschiedliche Nutzungsmuster haben?

Das Modell aggregiert Verkehr von allen Benutzertypen. Eine Mischung aus leichten Benutzern (Büroangestellte) und schweren Benutzern (Entwickler) wird durch Summierung ihrer erwarteten Last behandelt. Die Engset-Berechnung verwendet Gesamtbenutzer und Gesamtverkehr, was eine konservative Schätzung liefert.

Kann ich dies für Cloud-API-Kapazitätsplanung verwenden?

Die Mathematik gilt, aber Cloud-APIs haben typischerweise Preise pro Anfrage, nicht feste Kapazität. Der Wert dieses Modells liegt bei festen Kapazitätssystemen (On-Premise, reservierte Instanzen), bei denen Sie für Hardware bezahlen, unabhängig von der Auslastung.

Was ist mit Anfragewarteschlangen statt Blockierung?

Unser Modell nimmt “Loss”-Systeme an (keine Warteschlange). Für Systeme mit Warteschlangen gelten andere Formeln (Erlang-C). Für interaktive KI-Anwendungsfälle schlägt Warteschlangen jedoch oft den Zweck—Benutzer wollen sofortige Antworten, nicht “Ihre Anfrage ist #47 in der Warteschlange.”

Wie wirkt sich Modellquantisierung darauf aus?

Quantisierung ändert die Tokens/Sekunde pro Einheit (Modellgeschwindigkeit), was in die Kanalberechnung einfließt. Mehr Quantisierung = schnellere Inferenz = mehr Kanäle pro Einheit = möglicherweise weniger Einheiten für dasselbe SLA erforderlich.

Ist das Engset-Modell zu konservativ oder zu aggressiv?

Für gemischte Benutzerpopulationen ist es leicht konservativ (empfiehlt marginal mehr Kapazität als streng notwendig). Dies ist angemessen für Produktions-Kapazitätsplanung, bei der Unterdimensionierung kostspieliger ist als Überdimensionierung.

Technischer Anhang: Implementierungsdetails

Blockierungswahrscheinlichkeitsberechnung

function calculateBlockingProbability(users, trafficErlangs, channels) {
    if (channels <= 0) return 1.0;
    if (users <= channels) return 0.0;  // Mehr Kanäle als Benutzer
    if (users === 0) return 0.0;

    const a = trafficErlangs / users;  // Pro-Quelle Verkehrsintensität
    if (a <= 0) return 0.0;
    if (a >= 1) return 1.0;  // Überlastet

    const beta = a / (1 - a);

    // Zustandswahrscheinlichkeiten iterativ berechnen
    let probabilities = [1.0];
    for (let i = 1; i <= channels; i++) {
        const ratio = ((users - i + 1) / i) * beta;
        probabilities.push(probabilities[i - 1] * ratio);
    }

    const sum = probabilities.reduce((a, b) => a + b, 0);
    return probabilities[channels] / sum;
}

Binäre Suche für maximale TPS pro Benutzer

Um den maximal erreichbaren Durchsatz bei einem gegebenen Perzentil zu finden:

function findMaxTpsPerUser(capacity, targetBlockingProb, users, totalTPS) {
    let low = 0.1;
    let high = capacity;

    for (let i = 0; i < 50; i++) {
        const mid = (low + high) / 2;
        const traffic = totalTPS / mid;  // Verkehr relativ zur getesteten Rate
        const channels = capacity / mid;
        const pb = interpolatedBlockingProbability(users, traffic, channels);

        if (pb <= targetBlockingProb) {
            low = mid;  // Kann diese Rate erreichen
        } else {
            high = mid;  // Rate zu hoch
        }
    }

    return low;
}

Referenzen

Klassische Fernmeldeverkehrstheorie

Domańska, J., et al. “Stationary Queueing Models with Aspects of Customer Impatience.” Telecommunications Review, 2010. Online verfügbar
Engset, T. O. (1918). “Finite-source loss model for automatic telephone exchanges.” Nachgedruckt und diskutiert in modernen Warteschlangen-Übersichten. Historische Referenz
Virtamo, J. “Finite source population: the M/M/s/s/n system (Engset’s system).” Vorlesungsnotizen, Aalto University. Online verfügbar
“What is the Engset calculation?” Teletraffic engineering, Wikiversity. Online verfügbar
Cisco Systems. “Traffic Analysis – Engset formula for finite sources.” Cisco VoIP Traffic Analysis guide. Online verfügbar
“Traffic Engineering Techniques in Telecommunications.” Tutorial PDF (behandelt Erlang B/C und Engset, mit Trunk-Dimensionierungsbeispielen). Online verfügbar
“Traffic Engineering Tutorial.” Online verfügbar
ITAM. “An Introduction to Erlang B and Erlang C.” Vorlesungsnotizen. Online verfügbar
Columbia University. “Erlang B and C Formulas.” Vorlesungsnotizen. Online verfügbar

Moderne Finite-Source-Anwendungen

Dombacher, C. “Queueing Models for Call Centres.” Dissertation, TU Wien, 2010. [Online verfügbar](https://repositum.tuwien.at/bitstream/20.500.12708/13123/2/Dombacher Christian - 2010 - Queueing models for call centres.pdf)
Domańska, J., et al. “Stationary Queueing Models with Aspects of Customer Impatience.” Diskutiert Engset-Erweiterungen. Online verfügbar
Modellierung von Wireless Local Loop mit endlichen Teilnehmern, zeigt dass Engset-ähnliche Loss-Modelle noch verwendet werden. ACM Digital Library. Online verfügbar
“Finite-source queueing models in wireless communications.” Online verfügbar

LLM-Inferenz-Metriken und Performance

BentoML. “Key metrics for LLM inference.” Behandelt TPS, TTFT, Latenz pro Token. Online verfügbar
Databricks. “LLM Inference Performance Engineering: Best Practices.” Diskutiert die Beziehung zwischen TTFT, Pro-Token-Latenz, Gesamtantwortlatenz und Auswirkungen von Batch-Größe und Tensor-Parallelität. Online verfügbar
AIMultiple. “LLM Latency Benchmark by Use Cases.” Empirische Latenz-Benchmarks über Modelle und Anwendungsfälle. Online verfügbar

SLA-basiertes LLM-Serving

Pang, B., et al. “Optimizing LLM Inference Throughput via Memory-aware Dynamic Batching under SLA Constraints.” arXiv:2503.05248, 2025. Online verfügbar
“Scaling Up Throughput-oriented LLM Inference.” arXiv:2509.13201, 2025. Diskutiert durchsatzorientierte LLM-Inferenz mit entspannter Latenz/SLAs. Online verfügbar

Bestehende Hardware-Dimensionierungsmethoden

Lenovo. “LLM Sizing Guide.” Bietet Formeln zur Schätzung von GPU-Speicheranforderungen aus Modellparametern, fehlt aber probabilistische Gleichzeitigkeits- oder SLA-Modelle. Online verfügbar
Basebox. “Hardware Sizing for On-Premise AI: The VRAM Calculation Guide.” Verwendet Daumenregel-Spitzengleichzeitigkeit-Heuristiken für KMU-Bereitstellungen ohne warteschlangenbasierte Dimensionierung. Online verfügbar
Puget Systems. “Sizing VRAM to Generative AI and LLM Workloads.” Wählt GPU-Anzahlen basierend auf VRAM-Anforderungen mit informellen Sicherheitsmargen, ohne formale SLA-Wahrscheinlichkeitsmodelle. Online verfügbar
Microsoft Azure / Databricks. “Provisioned Throughput Tokens.” Kapazitätsplanungsleitfäden für Cloud-APIs mit TPM/RPM-Quoten und Puffer-basierter Dimensionierung, nicht probabilistische Modelle für endliche Benutzerpopulationen. Online verfügbar
Palantir. “LLM Capacity Management.” Beschreibt TPM/RPM-Reservierungsstrategien für interaktive vs. Batch-Workloads, behandelt Kapazität aber als harte Quoten ohne Engset/Erlang-ähnliche Modelle. Online verfügbar
“Can You Run This LLM?” VRAM-Rechner. Generisches Tool zur Schätzung von VRAM-Anforderungen, modelliert aber keine Benutzerpopulationen oder SLAs. Online verfügbar
Introl. “Local LLM Hardware Pricing Guide 2025.” Ordnet Beispielorganisationen GPU-SKUs basierend auf Nutzungskategorien zu, ohne probabilistische Gleichzeitigkeitsmodelle. Online verfügbar
OpenMetal. “AI Model Performance: Tokens per Second.” Hardware-Leitfäden, die Benutzeranzahlen GPU-Empfehlungen zuordnen, ohne probabilistische Blockierungsmodelle. Online verfügbar

Probieren Sie es selbst aus

Erleben Sie SLA-basierte Kapazitätsplanung mit unserem interaktiven Rechner:

→ LLM Hardware Cost Calculator

Der Rechner implementiert alles, was in diesem Whitepaper beschrieben wird:

Echtzeit-Engset-Berechnungen
Hardwarevergleiche unter identischen SLAs
Visuelle SLA-Compliance-Diagramme
Branchenvoreinstellungen für gängige Szenarien