Ein Leitfaden für CIOs und CTOs, die sich gegen die Cloud und für den Betrieb im eigenen Rechenzentrum entschieden haben. Sie erfahren, wie Sie Ihren Bedarf aus Nutzerzahlen und Anwendungsfällen ableiten, ihn gegen eine Referenzkapazität benchmarken und eine Server- und GPU-Konfiguration für die nächsten 24 Monate definieren — inklusive einer getesteten Modell-Hardware-Matrix und einer Vorlage für Ihre Beschaffung.

Einleitung

Welche Hardware brauchen Krankenhäuser, Kommunen und Behörden, um KI im eigenen Rechenzentrum zu betreiben? Diese Frage erreicht uns mehrfach pro Woche. Sie kommt von CIOs und CTOs, die eine Entscheidung getroffen haben: Patientendaten, Bürgerdaten, Sozialdaten gehören nicht in eine US-Cloud. Sie gehören ins eigene Rechenzentrum.

Dieser Artikel richtet sich an Sie, wenn Sie an diesem Punkt sind. Er führt die Cloud-versus-On-Prem-Debatte nicht erneut — die haben Sie bereits entschieden. Stattdessen bekommen Sie eine Methode, mit der Sie nach der Lektüre fünf Dinge tun können:

• Ihren KI-Bedarf in Tokens pro Tag ausdrücken.

• Diesen Bedarf gegen eine Referenzkapazität benchmarken.

• Einen Einstiegspfad wählen, der zu Ihrem Budget passt.

• Eine Server- und GPU-Konfiguration für die nächsten 24 Monate ableiten.

• Ein Briefing für Ihren Hardware-Lieferanten schreiben.

Was Sie hier nicht finden: einen Vergleich zwischen eigener Hardware und Managed-Cloud-Optionen. Diese Entscheidung hängt von mehr ab als der Hardware — von betrieblicher Reife, Eignung des Rechenzentrums und Organisationsgröße. Wir behandeln das in einem separaten Artikel zu Betriebsmodellen.

Bevor wir beginnen, lohnt sich ein Blick auf drei Fehler, die in KI-Infrastrukturprojekten immer wieder auftreten.

Erstens wird Hardware häufig anhand von Modellnamen statt anhand der tatsächlichen Nutzung dimensioniert. Die entscheidende Frage lautet selten, welches Modell betrieben werden soll. Die entscheidende Frage lautet, wie viele Menschen das System nutzen, wie intensiv sie es nutzen und für welche Aufgaben.

Zweitens berücksichtigen viele Planungen nur das Sprachmodell. In produktiven Umgebungen benötigen jedoch auch Embedding-Modelle, Spracherkennung, OCR und zunehmend agentische Workloads Ressourcen.

Drittens wird Infrastruktur oft für den heutigen Bedarf ausgelegt. In der Praxis wächst die Nutzung erfolgreicher KI-Plattformen meist deutlich schneller als ursprünglich erwartet.

Die Methode in diesem Artikel wurde entwickelt, um genau diese Fehler zu vermeiden.

Auf einen Blick

• Hardware-Sizing für KI bedeutet nicht, CPU-Kerne oder RAM zu zählen. Es bedeutet zu wissen, wie viele Tokens pro Tag Ihre Organisation verarbeitet.

• Ein Mitarbeiter, der KI aktiv nutzt, erzeugt je nach Anwendungsfall 30.000 bis 200.000 Tokens pro Tag.

• Eine Referenzmaschine mit 2× NVIDIA H200, die ein Modell der 70B–120B-Klasse auf vLLM betreibt, liefert im Volllastbetrieb rund eine Milliarde Tokens innerhalb von 24 Stunden. Auf 2× B200 (Blackwell) erreicht dieselbe Last rund 1,8–2,0 Milliarden Tokens pro Tag.

• Eine GPU trägt selten nur das Sprachmodell. Embedding, Spracherkennung, OCR und zunehmend Bildgenerierung und Large Table Models verbrauchen ebenfalls VRAM. Diese Modelle gehören in die Sizing-Rechnung.

• Die Kontextlänge bestimmt den KV-Cache-Bedarf. Bei langen Kontexten wird der KV-Cache größer als das Modell selbst.

• Planen Sie mit einem Faktor von 3 bis 5 über Ihrem berechneten Tagesbedarf. Mit agentischen Workloads — im Juni 2026 keine Prognose mehr, sondern Produktivrealität — eher mit einem Faktor von 10 bis 20.

• Wie Karten miteinander verbunden sind (NVLink, PCIe), bestimmt die nutzbare Leistung bei großen Modellen — nicht die VRAM-Summe.

• Flagship-Modelle mit 256k Kontext (wie Kimi K2.5 oder DeepSeek R2) bilden eine eigene Hardwareklasse. Sie liefern Tiefe, nicht Durchsatz — und verlangen 8× H200 oder 4× B200.

• Kleine Hardware liefert kleine Anwendungsfälle. Das ist eine Eigenschaft der Technik, keine Schwäche. Planen Sie entsprechend.

Dieser Leitfaden folgt drei Schritten:

1. Den eigenen Bedarf in Tokens ausdrücken.

2. Diesen Bedarf in konkrete Hardware übersetzen.

3. Ausreichend Reserven für die nächsten 24 Monate einplanen.

Warum Hardware-Sizing für KI anders funktioniert als für klassische IT

Wenn Sie einen Webserver dimensionieren, denken Sie in CPU-Kernen, RAM und IOPS. Diese Logik ist seit zwanzig Jahren etabliert. KI-Server folgen anderen Regeln, und das ist der häufigste Stolperstein in Beschaffungsprojekten.

Die entscheidende Größe ist nicht, wie viele Anfragen die CPU pro Sekunde abarbeitet, sondern wie viele Tokens pro Sekunde die GPU verarbeitet. Ein Token ist die kleinste Verarbeitungseinheit eines Sprachmodells — meist ein Wortfragment. „Krankenhaus" sind etwa zwei Tokens, ein durchschnittlicher deutscher Satz 15 bis 25. Jede Frage, jede Antwort, jeder analysierte Dokumentenabschnitt wird in Tokens umgewandelt und von der GPU verarbeitet.

Daraus folgt: Wenn Sie wissen, wie viele Tokens Ihre Organisation pro Tag braucht, kennen Sie Ihre Hardware. Ohne diese Zahl kaufen Sie blind.

CPU, Arbeitsspeicher und Storage sind auf einem KI-Server nicht unwichtig, aber Nebendarsteller. Die GPU mit ihrem spezialisierten Speicher (VRAM) entscheidet, ob Ihre KI-Plattform funktioniert oder scheitert.

Säule 1: Ihr Bedarf in Tokens

Die erste Aufgabe besteht darin, Ihren Bedarf in dieser Einheit auszudrücken. Mit ein paar Erfahrungswerten aus der Praxis funktioniert das.

Wie viel ist ein Token im Tagesgeschäft?

Diese Werte stammen aus realen Deployments und dienen als Ausgangspunkt für eigene Schätzungen:

Eine durchgerechnete Beispielrechnung

Eine Organisation mit 500 Mitarbeitenden. Wie viele Tokens pro Tag?

• 60 % der Mitarbeitenden nutzen KI regelmäßig → 300 aktive Nutzer.

• Davon 20 % Heavy User: 60 Personen × 150.000 Tokens = 9 Millionen Tokens/Tag.

• Die anderen 80 % sind Gelegenheitsnutzer: 240 Personen × 30.000 Tokens = 7,2 Millionen Tokens/Tag.

• Summe: rund 16,2 Millionen Tokens pro Tag.

Diese Zahlen sind Annahmen, keine Prognosen. Rechnen Sie mit Ihren eigenen Werten — Kopfzahl, Adoptionsquote, Nutzungsintensität.

💡 Faustregel: Pro 100 aktiven Mitarbeitenden rechnen Sie mit 5 bis 10 Millionen Tokens pro Tag bei klassischer Nutzung (Chat plus Dokumentenanalyse). Reine Chat-Nutzung liegt am unteren Ende, intensive Dokumentenarbeit am oberen.

Wenn noch keine Erfahrungswerte vorliegen

Das ist die Regel, nicht die Ausnahme. Nehmen Sie die mittleren Werte aus der Tabelle und arbeiten Sie damit. Genauer wird es nicht. Sie planen eine Investition für 24 bis 36 Monate.

☝️ Wichtigste Erkenntnis

Wer seinen täglichen Tokenbedarf abschätzen kann, kann auch seinen Hardwarebedarf abschätzen.

Für die meisten Organisationen wird die Dimensionierung von KI-Infrastruktur deutlich einfacher, sobald Nutzerzahlen, Nutzungsintensität und Anwendungsfälle in Tokens pro Tag übersetzt werden.

Säule 2: Von Tokens zur Hardware

Sobald die Bedarfsschätzung steht, wird die Hardware-Frage beantwortbar. Sie brauchen einen Referenzwert — eine Maschine mit bekannter Kapazität, gegen die Sie benchmarken.

Die Referenzmaschinen

📊 Referenz A (Hopper): Eine Maschine mit 2× NVIDIA H200, die ein Modell der 70B–120B-Klasse in FP8 oder MXFP4 auf dem vLLM-Inferenz-Stack betreibt, liefert im Volllastbetrieb rund eine Milliarde Tokens innerhalb von 24 Stunden.

📊 Referenz B (Blackwell): Dieselbe Last erreicht auf 2× NVIDIA B200 rund 1,8–2,0 Milliarden Tokens pro Tag, dank NVFP4-Unterstützung und höherer Speicherbandbreite.

Das obige Beispiel (16,2 Millionen Tokens pro Tag) nutzt rund 1,6 % der Kapazität von Referenz A. Eine Organisation mit 500 Mitarbeitenden hat auf einer 2× H200-Maschine Reserven für Wachstum und neue Anwendungen.

Kontextlänge — was bedeutet das in Seiten?

Die Kontextlänge beschreibt, wie viele Tokens an Eingabe und Ausgabe zusammen ein Modell verarbeitet. Die Zahl klingt abstrakt — ein Vergleich mit DIN-A4-Seiten deutscher Prosa macht sie greifbar.

Eine DIN-A4-Seite deutscher Prosa (Times New Roman 11 pt, Zeilenabstand 1,15, rund 400 Wörter) entspricht etwa 600 Tokens.

Warum das zählt: Die Kontextlänge bestimmt den KV-Cache-Bedarf — und der KV-Cache wird bei langen Kontexten größer als das Modell selbst. Wenn 20 Mitarbeitende gleichzeitig mit 32k Kontext arbeiten, beansprucht der KV-Cache 40 bis 80 GB VRAM zusätzlich zum Modell. Bei 256k Kontext und 30 parallelen Nutzern überschreitet allein der KV-Cache 100 GB — zusätzlich zu den Modellgewichten.

Ein praktischer Hinweis: Der maximale Kontext eines Modells (etwa 128k oder 256k) ist nicht der Wert, mit dem Sie im Alltag arbeiten. Die meisten Anfragen liegen darunter. Planen Sie für den Kontext, der 95 % Ihrer Anwendungsfälle abdeckt — und behalten Sie längere als Ausnahmen im Blick.

Eine GPU trägt selten nur das LLM

Ein Punkt, der in vielen Sizing-Diskussionen fehlt: Eine produktive KI-Plattform besteht nicht aus einem einzelnen Modell. Mehrere Modelle laufen parallel auf derselben Hardware:

Wenn die Fachabteilungen fragen „Können wir auch Diktat aus Arztbriefen?" oder „Können wir gescannte Akten durchsuchbar machen?", lautet die Antwort: ja — wenn die entsprechenden Modelle auf der GPU Platz haben.

Eine 2× H200-Maschine mit 282 GB VRAM trägt ein 120B-Modell (60 GB), Whisper (6 GB), ein 30B-Vision-Modell für OCR (~32 GB) und genug KV-Cache-Reserve für viele parallele Nutzer. Eine Konfiguration mit weniger VRAM erzwingt Kompromisse — beim Modell, beim Kontextfenster, bei der Nutzerzahl oder bei den verfügbaren Funktionen.

Wie GPU-Speicher zusammenarbeitet — und wann nicht

Eine Frage, die in fast jedem Beschaffungsgespräch auftaucht: „Können wir nicht einfach drei Karten mit je 48 GB nehmen und 144 GB für ein großes Modell haben?" Die Antwort: technisch oft nicht, und wenn doch, mit Performance-Einbußen.

Der Grund liegt in der Verbindung zwischen den Karten. Wenn große Modelle über mehrere GPUs verteilt werden (Tensor Parallelism), kommunizieren die Karten ständig miteinander. Diese Kommunikation braucht eine schnelle Verbindung — sonst wird der Datenbus zum Flaschenhals und der Durchsatz bricht ein.

Es gibt zwei Verbindungstypen:

• NVLink / NVSwitch: Eine Hochgeschwindigkeitsverbindung zwischen GPUs, je nach Generation 600 bis 1.800 GB/s. Voraussetzung für Tensor Parallelism bei großen Modellen.

• PCIe: Der Standard-Bus im Server, 64 GB/s pro Karte (PCIe 5.0 x16). Ausreichend für kleine Modelle, ein Flaschenhals bei großen.

Nicht jede GPU unterstützt NVLink. Ein Überblick über gängige Karten:

Konsequenz für die Beschaffung: Bei einem 70B- oder 120B-Klassemodell ist die GPU-Wahl nicht nur eine VRAM-Frage, sondern eine Bus-Frage. Eine Konfiguration mit 4× L40S klingt nach 192 GB Gesamtspeicher, ist aber für große Modelle nur begrenzt nutzbar. Eine Konfiguration mit 2× H200 in SXM-Bauform mit 282 GB und NVSwitch passt besser zum Anwendungsfall — auch wenn die Einzelkarte mehr kostet.

Eine weitere Regel: Tensor Parallelism muss die Attention-Heads des Modells gleichmäßig aufteilen. Ein Modell mit 64 Heads läuft mit 1, 2, 4 oder 8 GPUs — nicht mit 3 oder 6. Das beeinflusst die sinnvolle Kartenanzahl pro Server.

Replicas statt Tensor Parallelism: Wenn das Modell auf eine GPU passt

Ein Punkt, der in den meisten Sizing-Diskussionen fehlt: Wenn ein Modell auf eine einzelne GPU passt, ist eine Replica pro GPU oft die bessere Wahl, als ein Modell über mehrere GPUs zu verteilen.

Die Vorteile:

• Kein Kommunikations-Overhead zwischen GPUs — jede Replica läuft unabhängig

• Durchsatz skaliert linear mit der GPU-Anzahl: Zwei GPUs liefern doppelten Durchsatz, vier GPUs vierfachen

• NVLink wird optional — PCIe reicht, wenn GPUs nicht miteinander kommunizieren

• Höhere Verfügbarkeit — fällt eine GPU aus, bedienen die anderen Replicas weiter

Ein Beispiel aus der Praxis: Ein 5× H200-Deployment betreibt GPT-OSS-120B als fünf unabhängige Replicas (eine pro GPU) und liefert im Dauerbetrieb über 4 Milliarden Tokens pro Tag mit Spitzen über 50.000 Tokens pro Sekunde. Kein Tensor Parallelism. Die Last verteilt sich gleichmäßig: Die beiden Replicas eines Servers verarbeiteten 2,10 bzw. 2,11 Milliarden Tokens — durch einfaches Round-Robin-Routing.

Wann wird Tensor Parallelism nötig? Wenn das Modell nicht mehr auf eine einzelne GPU passt. Das ist typischerweise ab der Flagship-Klasse der Fall (1T-MoE-Modelle, siehe unten). Für alles, was auf eine H200 passt — also die meisten 70B- und 120B-Modelle in FP8 oder MXFP4 — sind Replicas die effizientere Architektur.

Die Flagship-Klasse: Wenn Tiefe wichtiger ist als Durchsatz

Die meisten Organisationen kommen mit der 70B–120B-Klasse aus. Es gibt aber Anwendungsfälle, in denen ein Flagship-Modell mit 256k Kontext und Trillionen-Parameter-MoE-Architektur (wie Kimi K2.5 oder DeepSeek R2) einen Unterschied macht:

• Vollständige Patientenhistorien über Jahre, in einem Durchgang analysiert.

• Komplexe Bauleit- oder Vergabeverfahren mit hunderten Seiten Begleitunterlagen.

• Mehrteilige juristische Analysen, bei denen der Kontext über mehrere Dokumente erhalten bleibt.

• Multimodale Fallbegutachtung mit Text, Scans und Bildern.

Das ist eine separate Hardwareklasse. Planen Sie mit:

• 8× H200 auf einem HGX-Board mit NVSwitch — oder alternativ 4× B200 (Blackwell mit NVFP4).

• Realistischer Durchsatz: 100 bis 300 Millionen Tokens pro Tag auf einem solchen Knoten. Weniger als eine 2× H200-Maschine mit einem 120B-Modell.

• Sie kaufen Tiefe und Kontextlänge, keinen Durchsatz.

Ein Flagship-Deployment ist kein Upgrade-Pfad aus der Standardkonfiguration — es ist ein paralleler Pfad für spezifische Anwendungsfälle. Organisationen, die beides brauchen, planen zwei verschiedene Knotentypen.

⚠️ Vorsicht bei „INT4"-Labels.
Wenn ein Anbieter oder ein Model-Card angibt, ein Flagship-Modell sei „INT4-quantisiert", meint das selten das ganze Modell. Bei Kimi K2.5 zum Beispiel sind nur die geleiteten Experten-Gewichte in INT4. Attention-Layer, Shared Experts, Embeddings und der LM-Head bleiben in BF16 (2 Byte pro Parameter). Aus den erwarteten ~250 GB werden ~549 GB tatsächlicher Gewichtsspeicher. Lassen Sie sich den realen VRAM-Bedarf aller Layer zusammen vom Anbieter schriftlich bestätigen.

Ein Betriebstipp in derselben Richtung: Bei langen Kontexten halbiert --kv-cache-dtype fp8 in vLLM den KV-Cache-Speicher bei vernachlässigbarem Qualitätsverlust. Für 256k-Deployments ist das die übliche Voreinstellung.

Eine Anmerkung zu Blackwell, B200 und B300

Im Juni 2026 ist Blackwell keine Prognose mehr, sondern eine reale Beschaffungsoption. NVIDIAs NVFP4-Datenformat — eine 4-Bit-Floating-Point-Darstellung mit Per-Block-Skalierung — erlaubt es, ein Flagship-Modell wie Kimi K2.5 auf 4× B200 statt 8× H200 zu betreiben, bei vergleichbarer Qualität. Die GPU-Anzahl halbiert sich, und die Total Cost of Ownership für Flagship-Deployments sinkt.

Die B300 (Blackwell Ultra) geht weiter: 288 GB HBM3e pro GPU und 8 TB/s Speicherbandbreite. Eine einzelne B300 hat etwa den doppelten VRAM einer H200 — was die Möglichkeiten einer Ein- oder Zwei-GPU-Konfiguration verändert.

NVFP4 setzt Tensor Cores der Blackwell-Generation voraus; H200 der Hopper-Generation unterstützen es nicht. Für Neubeschaffungen ab 2026 verdienen B200 oder B300 einen Vergleich gegen H200 — nicht nur für Flagship-Einsatz, sondern zunehmend auch für die Standardklasse.

Die drei Einstiegspfade

Bevor wir über konkrete Konfigurationen sprechen, ein Hinweis: Nicht jede Organisation kann oder will Flagship-Hardware kaufen. Und nicht jeder Anwendungsfall verlangt sie. Das Umgekehrte gilt genauso — zu klein dimensionierte Hardware trägt nur kleine Anwendungsfälle.

Kleine Hardware liefert kleine Anwendungsfälle. Das ist eine Eigenschaft der Technik, keine Schwäche. Planen Sie entsprechend.

Drei Einstiegsstrategien für Organisationen mit begrenztem Budget.

Pfad 1: Klein anfangen, sauber wachsen

Für wen: Organisationen mit 50–500 Mitarbeitenden, Pilot-Charakter, Bereitschaft, in 12–18 Monaten auszubauen.

Hardware: 1× H200 (141 GB) oder 1× B200 (192 GB) in einem Server mit freien Steckplätzen für 1–3 weitere GPUs.

Was funktioniert:

• Modelle bis ~30B Parameter in voller Präzision

• 70B-Modelle in FP8-Quantisierung

• 120B-Klasse MoE-Modelle wie GPT-OSS-120B in MXFP4

• Chat, Zusammenfassung, RAG über mittelgroße Wissensbasen

• Whisper für Diktat parallel

• 30–60 gleichzeitige Nutzer realistisch

Was nicht funktioniert:

• Modelle über 120B Parameter

• Lange Kontexte (>32k) mit vielen parallelen Nutzern

• Agentische Workloads in nennenswertem Umfang

Investitionslogik: Sie kaufen ein Gehäuse, das mitwächst. Die zweite GPU kommt, wenn die Nutzerzahl es rechtfertigt — nicht auf Verdacht.

Pfad 2: Geteilte Infrastruktur mit Aufgabenteilung

Für wen: Organisationen, die mehrere kleinere Anwendungsfälle parallel betreiben, ohne ein einzelnes „großes" Modell zu brauchen.

Hardware: 2–4× L40S oder vergleichbar (48 GB pro Karte, PCIe).

Was funktioniert:

• Mehrere kleinere Modelle parallel auf separaten Karten (eines für Chat, eines für OCR, eines für Embedding)

• Stabiler Betrieb für 100–300 Nutzer bei einfachen Anwendungsfällen

• Gutes Verhältnis von Gesamt-VRAM zu Investition

Was nicht funktioniert:

• Aufteilen eines großen Modells über mehrere Karten (PCIe-Limit)

• Effizienter Betrieb von 70B+-Modellen

• Upgrade-Pfad in Richtung Flagship-Klasse

Investitionslogik: Sie kaufen Breite, keine Tiefe. Passt, wenn die Anwendungsfälle bekannt und stabil sind. Passt nicht, wenn Sie später ein großes Modell brauchen — dann müssen Sie neu kaufen, nicht erweitern.

Pfad 3: Gemeinsamer Betrieb

Für wen: Kleinere Kommunen, Krankenhäuser im Verbund, Landkreise mit mehreren Einrichtungen.

Modell: Eine Einrichtung beschafft Flagship-Hardware (z. B. 4× H200 oder 4× B200), mehrere kleinere Häuser teilen sich die Kapazität über eine gemeinsame Plattform — mit Mandantentrennung und in einem gemeinsamen regionalen Rechenzentrum, nicht in der Cloud eines anderen.

Was funktioniert:

• Zugang zu Modellen, die ein einzelnes kleines Haus nie finanzieren könnte

• Investitionskosten verteilen sich auf mehrere Teilnehmer

• Ein professionelles Betriebsteam statt fünf halb zuständiger IT-Teams

Was zu klären ist:

• Governance: Wer entscheidet über Modellauswahl und Updates?

• Datentrennung: Technisch sauber, vertraglich klar

• Kostenverteilung: Nach Nutzung oder nach Kopfzahl?

Investitionslogik: Aus Capex wird teilweise Opex — aber unter Ihrer Souveränität, nicht der eines US-Hyperscalers. Für viele kommunale Träger der einzige Weg zur Flagship-Fähigkeit.

Die Untergrenze

Unterhalb von 1× H200 (oder gleichwertig: 1× L40S mit Einschränkungen, 2× RTX 6000 Ada für den Laborbetrieb) gibt es keine sinnvolle Empfehlung für eigene Produktivhardware. Alles darunter ist Labor, Test oder PoC — nicht Produktion. Diese Grenze nennen wir, weil sonst Erwartungen entstehen, die das System nicht erfüllt.

Für Organisationen unterhalb dieser Schwelle — kleine Kommunen, kleinere Behörden, einzelne Fachabteilungen — passt eigene Hardware selten. Eine Managed-Private-Cloud-Option ist meist der bessere Weg. Diese Entscheidung behandeln wir in einem separaten Artikel zu Betriebsmodellen.

Die teuerste Variante ist selten die teuerste Hardware

Eine zu klein gekaufte Maschine wird nach 12 Monaten ersetzt — komplett, nicht erweitert, weil das Gehäuse nicht mitwächst. Zweimal zu zahlen ist teurer, als einmal richtig zu kaufen. „Klein anfangen" funktioniert nur, wenn die Wachstumspfade dokumentiert sind: Welche GPUs passen ins Gehäuse, trägt das Netzteil, hält die Kühlung Volllast aus, unterstützt der PCIe-Lane-Plan das? Bleiben diese Fragen unbeantwortet, bedeutet „klein anfangen" praktisch „später komplett neu kaufen".

Säule 3: Skalierungs-Reserve für 24 Monate

Wer heute exakt auf den aktuellen Bedarf dimensioniert, kauft in 12 Monaten erneut — oft mit architektonischen Brüchen. Vier Gründe, größer zu planen als die Bedarfsschätzung nahelegt.

1. Adoption wächst. Empirische Beobachtung aus laufenden Deployments: Die aktive Nutzung verdoppelt sich innerhalb der ersten 12 Monate nach Produktivgang. Was als Pilot mit 50 Nutzern startet, erreicht nach einem Jahr 200. Der Treiber ist nicht Hype, sondern Sichtbarkeit — Mitarbeitende sehen Kollegen schneller mit KI arbeiten und ziehen nach.

2. Anwendungsfälle werden anspruchsvoller. Was als Chat beginnt, wird zu RAG über die gesamte Wissensbasis. Was als Zusammenfassung eines Dokuments beginnt, wird zu vergleichenden Analysen über 20. Längere Kontexte, größere Modelle, mehr parallele Anfragen — die Tokens pro Nutzer wachsen schneller als die Nutzerzahlen.

3. Neue Modelltypen kommen hinzu. Heute sind LLM, Embedding, Whisper und OCR die Komponenten. Innerhalb von 12 bis 24 Monaten kommen TTS, Bildgenerierung und Large Table Models (LTM) in die Produktion. Jedes zusätzliche Modell verbraucht VRAM, den Sie heute einplanen.

4. Agentische Workloads sind nicht mehr optional. Im Juni 2026 sind agentische Workloads Produktivrealität. Anwendungen, bei denen das LLM nicht eine einzelne Antwort generiert, sondern mehrere Schritte plant, Tools aufruft und Ergebnisse verarbeitet, werden zunehmend zum Standard.

Was dann passiert: Jeder Agentenschritt ist ein eigener LLM-Aufruf, und jeder Schritt trägt den gesamten angesammelten Kontext mit. Der Token-Verbrauch wächst nicht linear mit der Anzahl der Schritte, sondern überproportional — weil der Kontext mit jedem Schritt wächst.

Dokumentierte Größenordnungen aus aktuellen agentischen Deployments:

Derselbe Mitarbeitende, der heute im klassischen Chat 30.000 Tokens pro Tag verbraucht, erreicht mit agentischer Unterstützung 300.000 bis 3.000.000. Lastspitzen verschieben sich, weil Agenten oft im Hintergrund laufen, parallel zum interaktiven Chat. Mehrere Modellgrößen parallel werden zur Norm: ein starkes Modell für die Planung, ein schnelles für Routineschritte. Beide brauchen gleichzeitig VRAM.

💡 Faustregel: Planen Sie mit einem Faktor von 3 bis 5 über Ihrem berechneten Tagesbedarf für klassische Nutzung. Mit agentischen Workloads in der Produktion — was 2026 die realistische Voreinstellung ist — planen Sie mit einem Faktor von 10 bis 20, oder wählen Sie eine Architektur, die schnelle Erweiterung erlaubt.

Modulare Architektur als Skalierungspfad

Die Architektur entscheidet, ob Erweiterung schmerzhaft wird. Eine bewährte Trennung:

• LLM-Server mit GPU-Ressourcen für Sprach- und multimodale Modelle.

• RAG-Server mit Vektordatenbank, Embedding-Pipeline und Dokumentenindex (CPU-lastig, geringer GPU-Bedarf).

• Management-Server mit Nutzerverwaltung, Audit-Log, Monitoring, API-Gateway.

Diese Trennung erlaubt, die GPU-Komponente unabhängig vom Rest zu skalieren. Wenn der Token-Bedarf wächst, kommt GPU-Kapazität dazu. Wenn die Wissensbasis wächst, kommt RAG-Kapazität dazu. Ein monolithischer Aufbau zwingt dazu, bei jedem Erweiterungsschritt das gesamte System anzufassen.

Redundanz: Was passiert, wenn eine GPU ausfällt?

GPUs in Servern fallen selten aus, aber sie fallen aus. Bei klassischen Webservern ist die Antwort auf Ausfallszenarien etabliert: redundante Netzteile, RAID, Cluster. Bei KI-Servern ist die Antwort komplexer, weil GPUs teuer und nicht trivial spiegelbar sind.

Drei Redundanzstufen aus der Praxis:

• Komponentenredundanz im Server. Redundante Netzteile, Hot-Swap-Lüfter, ECC-Speicher. Das schützt vor häufigen Ausfallursachen, nicht vor einem GPU-Defekt.

• Modellredundanz über mehrere GPUs. Wenn zwei oder mehr GPUs Replicas desselben Modells betreiben (siehe „Replicas statt Tensor Parallelism" oben), arbeitet der Inferenz-Stack bei reduzierter Kapazität weiter, wenn eine GPU ausfällt. Einer der unterschätzten Vorteile der Replica-Architektur.

• Serverredundanz mit einem zweiten Knoten. Ein zweiter, identisch konfigurierter Server übernimmt, wenn der erste ausfällt. Die Lösung mit echter Hochverfügbarkeit — und die teuerste.

Für den anfänglichen Produktivbetrieb reicht Komponentenredundanz plus ein dokumentierter Wiederherstellungsplan (Ersatzteil-SLA, dokumentierter Neustart). Für geschäftskritische Anwendungen — etwa 24/7-Diktatsysteme — beginnt die Planung bei Stufe 2, idealerweise mit einem zweiten Knoten.

Klären Sie bei der Beschaffung: Welche Ausfallzeit ist tolerierbar? Welche Reaktionszeit garantiert der Anbieter? Ist ein Cold Spare oder Hot Spare verfügbar?

Erweiterungsstufen

Drei Erweiterungsstufen gehören auf die Checkliste bei der Hardware-Auswahl:

Stufe 1: Mehr GPUs im gleichen Server. Server-Plattformen unterscheiden sich erheblich darin, wie viele GPUs sie aufnehmen. Typische Konfigurationen bieten 2, 4 oder 8 GPU-Steckplätze. Worauf zu achten ist:

• PCIe-Lanes und -Generation: Moderne GPUs nutzen PCIe 5.0 x16. Der Server muss ausreichend Lanes bereitstellen, sonst werden GPUs gedrosselt.

• Freie Steckplätze: Wenn der Server heute mit 2 von 4 möglichen GPUs ausgeliefert wird, ist die Erweiterung ein Plug-in-Schritt. Wenn alle Steckplätze belegt sind, ist ein neuer Server nötig.

• Netzteil-Reserve: Jede zusätzliche GPU zieht 350 bis 700 Watt. Das Netzteil muss die Erweiterung tragen.

• Kühlungs-Reserve: Mehr GPUs erzeugen mehr Wärme. Die Server-Kühlung muss die Volllast aller geplanten GPUs aushalten — nicht nur die heute installierten.

Stufe 2: Zweiter Server, gleiche Plattform. Wenn die Nutzerzahl die Kapazität eines einzelnen Servers übersteigt, kommt ein zweiter Knoten hinzu. Die KI-Plattform muss das unterstützen (Lastverteilung zwischen Knoten). Voraussetzungen im Rechenzentrum: Rack-Platz, Stromzuführung, Netzwerkanbindung. Bei guter Erstauslegung passt der zweite Server ohne Umbau ins gleiche Rack.

Stufe 3: Multi-Node-Cluster. Bei vielen Tausend Nutzern bilden mehrere Server einen Cluster — meist mit InfiniBand für GPU-zu-GPU-Kommunikation über Knotengrenzen hinweg. Eine architektonische Entscheidung, die nachträglich nicht umsonst kommt: InfiniBand-Switches und -Kabel gehören in den Plan, das Netzwerk in das Layout.

Betriebsrealitäten, die IT-Teams überraschen

Jenseits des reinen Hardware-Sizings gibt es zwei Betriebsthemen, die Erst-Deployments regelmäßig stolpern lassen. Bei der Beschaffung relevant:

• CUDA-Treiber- und Inferenz-Stack-Kompatibilität. Container-Images von Inferenz-Engines (vLLM, TGI usw.) bringen eigene CUDA-Runtime-Erwartungen mit. Eine Diskrepanz zwischen Host-Treiber-Version und Container-Erwartung produziert schwer zu diagnostizierende Startfehler. Spezifizieren Sie in der Beschaffung, dass der Anbieter eine getestete, funktionierende Kombination aus Treiber, Container und Inferenz-Stack liefert — und dokumentiert, welche Versionen unterstützt werden.

• Modellladezeiten und Orchestrierungs-Timeouts. Ein 549-GB-Flagship-Modell lädt nicht in 30 Sekunden. Mit Kubernetes oder ähnlicher Orchestrierung killen Standard-Health-Check-Timeouts den Pod, bevor er je eine Anfrage bedient. Planen Sie bei Flagship-Modellen mit Startfenstern von 20 bis 30 Minuten, und konfigurieren Sie Ihre Plattformebene entsprechend.

Diese Details gehören auf die Checkliste des Betriebsteams, nicht in die Vorstandsentscheidung — sie tauchen aber besser nicht zum ersten Mal am Go-Live-Tag auf.

Fragen für heute

• Wie viele GPU-Steckplätze hat der vorgeschlagene Server insgesamt — und wie viele sind belegt?

• Welche PCIe-Generation und wie viele Lanes pro GPU?

• Welche Netzteil-Reserve bleibt für zusätzliche GPUs?

• Welche Kühlungs-Reserve bleibt bei voller GPU-Bestückung?

• Ist der Server InfiniBand-ready (NICs, Steckplätze, Verkabelung)?

• Wie sieht der Erweiterungspfad zu einem zweiten Knoten aus?

• Bei Flagship-Deployments: Ist der Server ein HGX-Klasse-Board mit NVSwitch, oder sind die GPUs nur per PCIe verbunden?

Diese Fragen kosten nichts im Beschaffungsdokument. Sie verhindern teure architektonische Brüche später.

📊 Konkrete Modellempfehlungen

📅 Die folgenden Empfehlungen haben den Stand Juni 2026.
Wir aktualisieren diesen Abschnitt quartalsweise. Die Methodik im Rest dieses Artikels bleibt davon unberührt.

Die Empfehlungen sind nach Hardwareklasse organisiert, nicht nach Modell. Wählen Sie die Klasse, die zu Ihrem Budget und Anwendungsfall passt, und wählen Sie dann aus den für diese Klasse getesteten Modellen.

Wie wir die Modelle in dieser Liste auswählen

Vor den Tabellen ein Wort zu den Auswahlkriterien. Ein produktionsreifes lokales Modell erfüllt vier Bedingungen gleichzeitig:

• Schnell genug — anhaltender Durchsatz für viele parallele Aufträge, nicht nur Einzelnutzer-Benchmarks

• Klug genug — Qualität auf dem Niveau, das der Anwendungsfall erfordert; kleinere Modelle sind schneller, aber fehleranfälliger

• Zuverlässig — saubere strukturierte Ausgabe (JSON), verlässliche Tool-Aufrufe, vorhersehbares Verhalten über tausende Anfragen

• Vertrauenswürdig — offene Gewichte, und die ausgelieferten Gewichte entsprechen den evaluierten Gewichten (bei Modellen, die nativ in Niedrigpräzisions-Formaten wie MXFP4 trainiert wurden, ist das gegeben; bei nachträglich quantisierten Modellen oft nicht)

Der letzte Punkt ist subtil, aber wichtig. Viele veröffentlichte Benchmarks laufen auf Vollpräzisions-Gewichten, während die Gewichte, die Sie tatsächlich deployen, nachträglich quantisiert sind — manchmal mit messbarem Qualitätsverlust, der im Benchmark nicht erscheint. Modelle, die nativ in ihrem Deployment-Format trainiert wurden (wie GPT-OSS-120B in MXFP4), umgehen diese Lücke.

Hardwareklassen auf einen Blick

Hinweis zu Consumer-GPUs (RTX 4090, RTX 5090): Wir listen Consumer-Karten nicht als Produktionsklassen. Ihnen fehlen NVLink, ECC-Speicher und Enterprise-Treiber-Support. Für Labor und Evaluation sind sie nutzbar; für die Produktion mit Patienten- oder Bürgerdaten nicht.

Klasse 1 — Labor / PoC

Hardware: 2× RTX 6000 Ada (96 GB gesamt) oder 1× L40S (48 GB)
Zweck: Evaluation, Einzelnutzer-Tests, Modellauswahl vor der Beschaffung.

Was diese Klasse nicht trägt: Produktionsreife Parallelität, lange Kontexte für viele Nutzer, Flagship-Modelle, agentische Workloads in größerem Umfang.

Klasse 2 — Einstiegs-Produktion

Hardware: 1× H200 (141 GB) oder 1× B200 (192 GB), in einem Gehäuse mit freien Steckplätzen für Erweiterung
Zweck: Erstes produktives Deployment für kleinere Organisationen (50–300 aktive Nutzer).

Typischer paralleler Modell-Stack auf 1× H200: LLM 70B FP8 (70 GB) + Whisper Large v3 Turbo (6 GB) + Qwen 3 VL 7B für OCR (14 GB) + Embedding (2 GB) + KV-Cache-Reserve für 40 gleichzeitige Nutzer bei 16k Kontext (30 GB).

Was diese Klasse nicht trägt: Modelle über 120B Parameter, anhaltende lange Kontexte (>32k) für viele Nutzer, Flagship-1T-MoE-Modelle.

Klasse 3 — Standard-Produktion

Hardware: 2× H200 mit NVLink (282 GB) oder 2× B200 (384 GB)
Zweck: Die Arbeitsklasse für die meisten Krankenhäuser und Kommunen (300–2.000 aktive Nutzer).

Referenz-Benchmark: 2× H200 (NVLink) + GPT-OSS 120B (MXFP4) auf vLLM = ~1 Milliarde Tokens pro 24 Stunden bei Volllast. Entsprechend auf 2× B200: ~1,8–2,0 Milliarden Tokens pro 24 Stunden.

Typischer paralleler Stack auf 2× H200: LLM 120B-Klasse (60 GB) + Whisper Large v3 Turbo (6 GB) + Qwen 3 VL 30B für Dokumentenverständnis (32 GB) + Embedding-Modell auf GPU (2 GB) + KV-Cache für 150 gleichzeitige Nutzer bei 16k Kontext (~120 GB). Insgesamt rund 220 GB von 282 GB — mit Reserve.

📍 Praxisbeispiel: Ein reales Hochdurchsatz-Deployment
Eine universitätsnahe Einrichtung betreibt aktuell 5× H200 in zwei Servern mit GPT-OSS-120B (MXFP4) über vLLM, in Replica-Architektur (eine Modellinstanz pro GPU, kein Tensor Parallelism). Ergebnis: über 4 Milliarden Tokens pro Tag im Dauerbetrieb, Spitzen über 50.000 Tokens pro Sekunde, 2,76 Millionen Anfragen in einer Woche. Stack: vLLM + LiteLLM-Proxy + PostgreSQL für Nutzungsverfolgung + Prometheus/Grafana für Monitoring, vollständig containerisiert, hinter der Firewall der Einrichtung.

Das ist nicht der typische Fall — es ist ein forschungsintensives Deployment unter anhaltender hoher Last mit agentischen Workloads. Zur Einordnung: 4 Milliarden Tokens pro Tag entsprechen rund 1,5 Billionen Tokens pro Jahr. Eine Klinik mit 500 aktiven Nutzern bei moderater Nutzung erreicht etwa 5 Milliarden Tokens pro Jahr — 300× weniger. Selbst eine Universitätsklinik mit 5.000 aktiven Nutzern und intensiver Agentennutzung läge bei rund 150 Milliarden Tokens pro Jahr, einem Zehntel des Beispiels.

Was das Beispiel zeigt, ist die Obergrenze dessen, was kompakte Hardware leistet. Für die meisten Organisationen bedeutet das: Auch bei starkem Wachstum hat eine 2× H200-Konfiguration jahrelang Reserven.

Was diese Klasse nicht trägt: Echte Flagship-Deployments (Kimi K2.5, DeepSeek R2 voll), 256k Kontext für viele parallele Nutzer, schwere agentische Workloads.

Klasse 4 — Heavy-Produktion

Hardware: 4× H200 (564 GB) oder 2–4× B200 (384–768 GB)
Zweck: Größere Organisationen (2.000–10.000 Nutzer) oder dokumentenintensive Workflows.

Zwei Treiber schieben Organisationen typischerweise von Klasse 3 nach Klasse 4: mehr Nutzer (wenn die Spitzenlast übersteigt, was 2× H200 bei akzeptabler Latenz bedienen) und höhere Präzision (dasselbe Modell in FP8 statt MXFP4 verbessert die Ausgabequalität bei spezialisierten Domänen wie medizinischer Kodierung oder juristischer Analyse messbar).

Was diese Klasse nicht trägt: Trillionen-Parameter-MoE-Modelle mit 256k Kontext — das verlangt Klasse 5.

Klasse 5 — Flagship

Hardware: 8× H200 auf HGX-Board mit NVSwitch (1.128 GB) oder 4× B200/B300 mit NVLink 5 (768–1.152 GB)
Zweck: Anwendungsfälle, bei denen Kontexttiefe und Modellfähigkeit wichtiger sind als Durchsatz.

Flagship-Modelle liefern Tiefe, kein Volumen. Rechnen Sie mit 100–300 Millionen Tokens pro Tag auf 8× H200, ~20 Tokens/Sekunde pro Anfrage bei der Generierung und 5–30 gleichzeitigen Nutzern bei langem Kontext.

Eine 2× H200 + 120B-Konfiguration produziert 3–10× mehr Tokens pro Tag als ein Flagship-Deployment. Wenn Ihr Engpass das Volumen ist, bleiben Sie bei Klasse 3. Wenn Ihr Engpass das ist, was das Modell mit einer vollständigen Patientenhistorie oder einer 400-Seiten-Vergabeakte anstellen kann, brauchen Sie Klasse 5.

Multimodale Komponenten

Modelle, die das Haupt-LLM in einem produktiven Stack ergänzen:

Spracherkennung

Vision / OCR

Embeddings

Text-to-Speech (im Kommen)

Quantisierungs-Referenz

Empfehlung: Standardmäßig FP8, wenn der VRAM reicht. MXFP4/NVFP4 für die Produktion, wenn der Speicher knapp wird. Q3 und darunter für die Produktion vermeiden.

Performance-Hebel zum Mitnehmen

Drei Einstellungen verbessern Durchsatz und Latenz in produktiven Deployments — sie kosten nichts und gehören in den Standard:

• Prefix-Caching. Wenn System-Prompts über Anfragen hinweg wiederverwendet werden (typisch bei klinischen und Verwaltungs-Workloads), liefert Prefix-Caching hohe Trefferquoten und senkt die Latenz pro Anfrage. In vLLM das Flag --enable-prefix-caching.

• FP8 KV-Cache. Für Deployments mit langem Kontext halbiert --kv-cache-dtype fp8 den KV-Cache-Speicher bei vernachlässigbarem Qualitätsverlust. Ermöglicht mehr gleichzeitige Nutzer oder längeren effektiven Kontext auf derselben Hardware.

• Replica-Architektur statt Tensor Parallelism (siehe früherer Abschnitt). Wenn das Modell auf eine einzelne GPU passt, eine Instanz pro GPU statt einer Aufteilung. Lineare Durchsatzskalierung, keine NVLink-Abhängigkeit, höhere Verfügbarkeit.

Was Sie Ihrem Lieferanten kommunizieren

Mit den bisherigen Informationen passt ein Briefing an den Lieferanten auf ein paar Zeilen:

Wir planen eine On-Premise-KI-Plattform für rund [X] aktive Nutzer über die nächsten 24 Monate. Erwarteter Tagesbedarf: rund [Y] Millionen Tokens. Wir planen, ein Modell der [Z]B-Klasse zu betreiben, parallel zu Whisper für Diktat und einem Vision-Modell für OCR.

Bitte schlagen Sie eine Konfiguration vor mit:

• GPU-Klasse H200 (SXM), B200 oder B300, mit NVLink/NVSwitch

• Gesamt-VRAM mindestens [N] GB

• Erweiterungs-Reserve für mindestens zwei zusätzliche GPUs ohne architektonische Änderungen

• 5 Jahre Support, 4-Stunden-Vor-Ort-Reaktionszeit

• DSGVO-konformer Betrieb, keine externe Telemetrie

• Dokumentierte und unterstützte Kombination aus GPU-Treiber, Container-Runtime und Inferenz-Stack

Bitte nennen Sie auch Strom- und Kühlungsanforderungen für unsere Rechenzentrumsplanung.

Mehr braucht es für die erste Anfrage nicht. Den Rest erledigt der Lieferant im Angebot.

Lohnt sich eigene Hardware?

Die kurze Antwort: ja, wenn die Organisation groß genug ist, die Hardware auszulasten, und sensible Daten verarbeitet. Drei Faustregeln aus der Praxis:

• Eine Hardware-Investition für die Standard-Produktionsklasse (2× H200, rund 60.000 € für GPUs plus rund 25.000 € für den Server) amortisiert sich typischerweise innerhalb von 12–18 Monaten gegenüber der Miete vergleichbarer Kapazität bei einer Managed-KI-Plattform — bei einer Auslastung über rund 30 %.

• Unbegrenzte Token-Nutzung ist der entscheidende Vorteil, besonders bei agentischen Workloads, wo der Token-Verbrauch unvorhersehbar wird. Feste Hardware-Kosten schlagen variable Token-Abrechnung, sobald die Nutzung wächst.

• Voraussetzung: ein Rechenzentrum, das GPUs aufnimmt (Strom, Kühlung, Platz), und ein IT-Team, das den Betrieb übernimmt. Ohne beides sind Managed-Optionen meist der bessere Weg, unabhängig von der Größe.

Der vollständige wirtschaftliche Vergleich — eigene Hardware gegenüber Managed Private Cloud gegenüber anderen Betriebsmodellen — hängt von mehr ab als von den Hardware-Kosten. Er hängt von der Organisationsgröße, der Rechenzentrums-Reife, den Compliance-Anforderungen und der betrieblichen Bereitschaft ab. Wir behandeln diese Entscheidung in einem separaten Artikel zu Betriebsmodellen und Organisationsgröße [Link folgt].

Wenn Sie bereits entschieden haben, dass eigene Hardware der richtige Weg ist, gibt Ihnen der Rest dieses Artikels, was Sie brauchen.

Hilfe für Ihre Beschaffung

Damit Sie nicht bei null anfangen, hier eine strukturierte Vorlage zur Anpassung an Ihre Situation. Sie ersetzt keine Rechtsberatung und ist keine vollständige Spezifikation, aber sie bildet einen Ausgangspunkt für vergleichbare Angebote.

1. Pflichtanforderungen

• GPU-Klasse und Mindest-VRAM pro GPU (mit Bezug auf die gewählte Klasse oben).

• NVLink/NVSwitch für Modelle ab 70B Parameter; HGX-Klasse-Boards verpflichtend für Flagship-Deployments.

• Anzahl GPUs pro Server, kompatibel mit den geplanten Modell-Topologien (Tensor-Parallelism-Faktoren 1, 2, 4 oder 8 — oder Replica-Architektur, siehe oben).

• ECC-Speicher für GPU und Arbeitsspeicher.

• Netzwerk: mindestens 2× 25 GbE, optional InfiniBand HDR oder NDR bei Multi-GPU-Setups.

• Redundante Netzteile, Hot-Swap-Lüfter.

• Garantie- und Supportzeitraum (Vorschlag: 5 Jahre Next-Business-Day).

• Strom- und Kühlungsanforderungen kompatibel mit der bestehenden Rechenzentrums-Infrastruktur.

• DSGVO-konformer Betrieb, keine Telemetrie an externe Anbieterclouds.

• Dokumentierte und unterstützte Kombination aus GPU-Treiber, Container-Runtime und Inferenz-Stack.

2. Erweiterungs-Reserve

• Anzahl freier GPU-Steckplätze im vorgeschlagenen Server.

• PCIe-Generation und Lane-Verteilung pro Steckplatz.

• Netzteil-Reserve für zusätzliche GPUs.

• Kühlungs-Reserve bei voller GPU-Bestückung.

• InfiniBand-Vorbereitung für spätere Multi-Node-Erweiterung.

3. Bewertungskriterien mit Gewichtungsvorschlag

Passen Sie die Gewichtung an Ihre Prioritäten an — übernehmen Sie sie nicht ungeprüft.

4. Lieferumfang

• Hardware vollständig aufgebaut und vorkonfiguriert.

• Inbetriebnahme vor Ort durch den Anbieter.

• Dokumentation in deutscher Sprache.

• Schulung für interne Administratoren (Vorschlag: 2 Tage).

• Übergabeworkshop mit Leistungsnachweis.

5. Service Levels

• Reaktionszeit im Fehlerfall (z. B. 4 h vor Ort an Werktagen).

• Ersatzteilverfügbarkeit über den gesamten Garantiezeitraum.

• Definierter Eskalationspfad (Name, Telefonnummer, Vertretung).

• Verfügbarkeitsgarantie für die Gesamtlösung (z. B. 99,5 % während der Geschäftszeiten).

6. Abnahmekriterien

• Messbare Leistungswerte unter definierter Last (z. B. „≥ X Tokens/Sekunde bei Y gleichzeitigen Nutzern und Z Tokens Kontextlänge mit Modell M in Quantisierung Q").

• Stabilitätstest über 72 Stunden Dauerlast.

• VRAM-Auslastung dokumentiert für alle parallel betriebenen Modelle.

• Nachweis, dass Erweiterungsoptionen technisch funktionieren.

Diese Vorlage ist neutral gehalten. Sie fordert Leistung, keine Marken. Das schützt vor Lock-in und erzeugt vergleichbare Angebote.

Das Ziel der Infrastrukturplanung für KI besteht nicht darin, den größtmöglichen Server zu kaufen.

Das Ziel besteht darin, ausreichend Kapazität für reale Anwendungsfälle bereitzustellen und gleichzeitig genügend Spielraum für Wachstum zu schaffen.

Organisationen, die ihren Tokenbedarf, ihre Modellanforderungen und die erwartete Nutzung kennen, können Hardwareentscheidungen auf Basis messbarer Anforderungen treffen – statt auf Basis von Annahmen.

Zusammenfassung

Drei Säulen tragen die Hardware-Entscheidung:

• Bedarf in Tokens ausdrücken. Aus Kopfzahl, Adoptionsquote und Anwendungsfällen ergibt sich der Tages-Token-Bedarf. Pro 100 aktiven Nutzern rund 5 bis 10 Millionen Tokens pro Tag.

• Bedarf gegen Referenz benchmarken. Eine Maschine mit 2× H200 und einem Modell der 120B-Klasse auf vLLM produziert rund eine Milliarde Tokens pro 24 Stunden; auf 2× B200 rund das Doppelte. Daraus leiten Sie ab, welche GPU-Klasse, wie viel VRAM und wie viele GPUs in Ihre Konfiguration gehören — sodass neben dem LLM auch Embedding, Whisper, OCR und künftige Modelle Platz haben. Bei großen Modellen entscheidet die Verbindung zwischen den Karten (NVLink statt PCIe, oder Replica-Architektur) über die nutzbare Leistung mit. Für Flagship-Modelle mit 256k Kontext planen Sie eine separate Knotenklasse mit 8× H200 oder 4× B200/B300 — und lassen Sie den realen VRAM-Bedarf „quantisierter" Modelle schriftlich bestätigen.

• Skalierungs-Reserve planen. Faktor 3 bis 5 über dem heutigen Bedarf für klassische Nutzung, Faktor 10 bis 20 bei agentischen Workloads in der Produktion. Modulare Architektur, freie GPU-Steckplätze, Netzteil-Reserve, definierte Erweiterungspfade.

Wählen Sie Ihren Einstiegspfad aktiv: klein anfangen mit einem Gehäuse, das mitwächst; Breite aufbauen mit mehreren kleineren GPUs für bekannte Anwendungsfälle; oder gemeinsam betreiben mit Partnern, wenn Flagship-Fähigkeit zählt, aber die Einzelorganisations-Investition außer Reichweite liegt. Unterhalb der Schwelle einer einzelnen H200 passt eigene Hardware selten — Managed-Optionen sind dann der bessere Weg.

Mit dieser Methode beantworten Sie Ihre eigene Sizing-Frage. Der VRAM-Rechner unter apxml.com/tools/vram-calculator hilft bei Detailprüfungen.

basebox ist eine On-Premise-KI-Plattform für Organisationen, die kritische Daten verarbeiten — Patientendaten, Bürgerdaten, Sozialdaten, eingestufte Daten. Für ein Gespräch über konkrete Konfigurationen für Ihre Situation erreichen Sie uns über die üblichen Kanäle.