Ein Leitfaden für CIOs und CTOs, die sich gegen die Cloud und für den Betrieb im eigenen RZ entschieden haben. Sie lernen, Ihren Bedarf aus Nutzerzahlen und Anwendungsfällen abzuleiten, ihn gegen eine Referenz-Kapazität (≈ 1 Mrd. Tokens pro Tag auf 2× H200) zu spiegeln und eine Server- und GPU-Konfiguration für die nächsten 24 Monate zu bestimmen — inklusive Vorlage für Ihre Ausschreibung.

Einleitung

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

Dieser Artikel richtet sich an Sie, wenn Sie an diesem Punkt stehen. Die Debatte Cloud gegen on-prem führt der Artikel nicht — die haben Sie geführt. Stattdessen bekommen Sie eine Methodik, mit der Sie nach dem Lesen vier Dinge können:

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

2. Diesen Bedarf gegen eine Referenz-Kapazität spiegeln.

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

4. Ein Briefing für Ihren Lieferanten formulieren.

Was Sie hier nicht finden: Eurobeträge. Hardwarepreise für KI-Komponenten ändern sich monatlich, GPU-Verfügbarkeit schwankt, neue Modellgenerationen verschieben Referenzpunkte. Jede Preisangabe ist in drei Monaten veraltet. Was sich nicht ändert, ist die Logik dahinter. Die bekommen Sie hier.

Auf einen Blick

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

• Ein Mitarbeiter mit aktiver KI-Nutzung erzeugt 30.000 bis 200.000 Tokens pro Tag, abhängig vom Anwendungsfall.

• Eine Referenz-Maschine mit 2× NVIDIA H200, betrieben mit GPT-OSS-120B in Q4-Quantisierung unter vLLM, erzeugt bei voller Auslastung rund eine Milliarde Tokens innerhalb von 24 Stunden.

• Auf einer GPU läuft selten nur das Sprachmodell. Embedding, Spracherkennung, OCR und perspektivisch Bildverarbeitung und Large Table Models brauchen 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 heute mit Faktor 3 bis 5 über dem ermittelten Tagesbedarf. Mit Blick auf agentische Workloads eher Faktor 10 bis 20.

• Wie Karten miteinander verbunden sind (NVLink, PCIe), entscheidet bei großen Modellen über die nutzbare Leistung — nicht allein der VRAM in Summe.

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

Bei einem Web-Server denken Sie in CPU-Kernen, RAM und IOPS. Die Logik ist seit zwanzig Jahren etabliert. Bei einem KI-Server gelten andere Regeln, und das ist der häufigste Stolperstein in Beschaffungsprojekten.

Die Größe, auf die es ankommt, ist nicht, wie viele Anfragen die CPU pro Sekunde annimmt. Es ist, wie viele Tokens pro Sekunde die GPU verarbeitet. Ein Token ist die kleinste Verarbeitungseinheit eines Sprachmodells — ein Wortbestandteil. "Krankenhaus" sind etwa drei Tokens, ein deutscher Satz 20 bis 30. Jede Frage, jede Antwort, jeder analysierte Dokumentenabschnitt wird in Tokens umgerechnet 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 ins Blaue.

CPU, System-RAM und Storage sind beim KI-Server nicht unwichtig, aber Beiwerk. Die GPU mit ihrem schnellen Spezialspeicher (VRAM) entscheidet über Erfolg oder Misserfolg Ihrer KI-Plattform.

Stütze 1: Ihr Bedarf in Tokens

Die erste Aufgabe besteht darin, Ihren Bedarf in dieser Einheit auszudrücken. Mit ein paar Erfahrungswerten geht das gut.

Wie viel ist ein Token in Ihrem Alltag?

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

Rechenbeispiel

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

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

2. Davon 20 % Intensivnutzer: 60 Personen × 150.000 Tokens = 9 Mio. Tokens/Tag.

3. Davon 80 % Gelegenheitsnutzer: 240 Personen × 30.000 Tokens = 7,2 Mio. Tokens/Tag.

4. Summe: rund 16,2 Mio. Tokens pro Tag.

Diese Zahlen sind Annahmen, keine Vorhersagen. Rechnen Sie mit Ihren Werten — Mitarbeiterzahl, Adoptionsquote, Nutzungsintensität.

💡 Faustregel: Pro 100 aktive Mitarbeitende rechnen Sie mit 5 bis 10 Millionen Tokens pro Tag bei klassischer Nutzung (Chat plus Dokumentenanalyse). Bei reiner Chat-Nutzung am unteren Rand, bei intensiver Dokumentenarbeit am oberen.

Wenn noch keine Erfahrungswerte vorliegen

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

Stütze 2: Von Tokens zur Hardware

Sobald die Bedarfsschätzung steht, lässt sich die Frage nach der Hardware beantworten. Dafür dient eine Referenzgröße — eine Maschine mit bekannter Kapazität, gegen die Sie spiegeln.

Die Referenz-Maschine

📊 Referenz: Eine Maschine mit 2× NVIDIA H200, betrieben mit dem Open-Weight-Modell GPT-OSS-120B in Q4-Quantisierung unter dem Inference-Stack vLLM, erzeugt bei voller Auslastung rund eine Milliarde Tokens innerhalb von 24 Stunden.

Drei Gründe für diese Wahl: Die Konfiguration ist eine Enterprise-Variante und derzeit lieferbar. GPT-OSS-120B ist ein produktiv eingesetztes Open-Weight-Modell. vLLM ist ein produktionsreifer Inference-Stack mit dokumentierten Durchsatzwerten.

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

Kontextlänge — was bedeutet das in Seiten?

Die Kontextlänge eines Modells beschreibt, wie viele Tokens Eingabe und Ausgabe zusammen das Modell verarbeitet. Diese Zahl klingt abstrakt — ein Vergleich mit DIN-A4-Seiten deutschen Fließtexts macht sie greifbar.

Eine DIN-A4-Seite mit deutschem Fließtext (Times New Roman 11pt, 1,15-zeilig, 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.

Hinweis zur Praxis: Der maximale Kontext eines Modells (etwa 128k) ist nicht der Wert, mit dem in der Realität gearbeitet wird. Die meisten Anfragen liegen weit darunter. Planen Sie mit dem Kontext, der für 95 % Ihrer Anwendungsfälle reicht — und behalten Sie die längeren als Ausnahme im Hinterkopf.

Eine GPU trägt selten nur das LLM

Hier kommt ein Punkt ins Spiel, der in vielen Sizing-Diskussionen fehlt: Eine produktive KI-Plattform besteht nicht aus einem einzigen Modell. Mehrere Modelle laufen parallel auf derselben Hardware:

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

Eine 2× H200-Maschine mit 282 GB VRAM trägt das 120B-Modell in Q4 (60 GB), Whisper (8 GB), ein Vision-Modell für OCR (~16 GB) und genug KV-Cache-Reserve für viele parallele Nutzer. Eine Konfiguration mit weniger VRAM zwingt zu Kompromissen — 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 haben dann 144 GB für ein großes Modell?" Die ehrliche Antwort lautet: technisch oft nicht, und wenn doch, dann mit deutlichen Leistungsverlusten.

Der Grund liegt in der Verbindung zwischen den Karten. Bei großen Modellen, die auf mehrere GPUs aufgeteilt werden (Tensor Parallelism), kommunizieren die Karten ständig untereinander. Diese Kommunikation braucht eine schnelle Verbindung — sonst wird der Datenbus zum Engpass und der Durchsatz bricht ein.

Es gibt zwei Verbindungsarten:

1. NVLink / NVSwitch: Eine direkte Hochgeschwindigkeitsverbindung zwischen GPUs, mit 600 bis 1.800 GB/s je nach Generation. Das ist die Voraussetzung für effizientes Tensor Parallelism bei großen Modellen.

2. PCIe: Der Standard-Bus im Server, mit 64 GB/s pro Karte (PCIe 5.0 x16). Für kleine Modelle ausreichend, für große Modelle ein Bremsklotz.

Nicht jede GPU unterstützt NVLink. Eine Übersicht der gängigen Karten:

Konsequenz für die Beschaffung: Wenn Sie ein Modell der 70B- oder 120B-Klasse betreiben wollen, ist die Wahl der GPU keine reine VRAM-Frage, sondern eine Bus-Frage. Eine Konfiguration mit 4× L40S klingt nach 192 GB Gesamtspeicher, taugt für große Modelle aber nur eingeschränkt. Eine Konfiguration mit 2× H200 in SXM-Bauform mit 282 GB und NVSwitch ist die deutlich bessere Wahl — auch wenn die Einzelkarte teurer ist.

Eine weitere Regel: Tensor Parallelism muss die Attention-Heads des Modells gleichmäßig teilen. GPT-OSS-120B mit 64 Heads läuft mit 1, 2, 4 oder 8 GPUs — nicht mit 3 oder 6. Das beeinflusst die sinnvolle Anzahl der Karten pro Server.

Was Sie dem Anbieter mitteilen

Mit den bisherigen Informationen formulieren Sie ein Briefing an Ihren Lieferanten, das auf wenige Zeilen passt:

Wir planen eine On-Premise-KI-Plattform für rund [X] aktive Nutzer in den nächsten 24 Monaten. Erwarteter Tagesbedarf: rund [Y] Mio. Tokens. Wir wollen ein Modell der [Z]B-Klasse betreiben, parallel dazu Whisper für Diktat und ein OCR-Modell.

Bitte schlagen Sie eine Konfiguration vor mit:

• GPU-Klasse H200 (SXM) oder gleichwertig mit NVLink/NVSwitch

• Gesamt-VRAM mindestens [N] GB

• Erweiterungsreserve für mindestens zwei weitere GPUs ohne Architekturbruch

• 5 Jahre Support, 4h-Reaktionszeit vor Ort

• DSGVO-konformer Betrieb, keine externe Telemetrie

Bitte nennen Sie zusätzlich Strom- und Kühlungsbedarf für unsere RZ-Planung.

Mehr braucht es für die erste Anfrage nicht. Den Rest übernimmt der Anbieter in seinem Angebot.

Eine Orientierung, in welcher Größenordnung Sie denken, gibt die folgende Tabelle:

Eine getestete Modell-Hardware-Matrix mit konkreten Quantisierungen, Kontextlängen und Nutzerzahlen pflegt basebox unter docs.basebox.ai/on-premise/llm-recommendations. Diese Liste wird laufend aktualisiert.

Der Kalculator für die Detailfrage

Für die Frage "Passt mein gewähltes Modell mit meiner Kontextlänge und Nutzerzahl in meine GPU-Konfiguration?" gibt es ein kostenloses Werkzeug: den VRAM-Calculator auf apxml.com.

💡 Mini-Glossar: Was die Begriffe im VRAM-Calculator bedeuten

Bevor Sie den Calculator nutzen, lohnt sich ein Blick auf die Eingabefelder. Sie müssen kein ML-Ingenieur sein, brauchen aber ein Verständnis der Einstellungen.

• Model / Modell: Das Sprachmodell, das Sie betreiben wollen. Die Parameterzahl (z.B. "70B" = 70 Milliarden Parameter) treibt den VRAM-Bedarf am stärksten.

• Inference Quantization / Quantisierung der Modellgewichte: Wie präzise das Modell seine internen Werte speichert. FP16 = volle Präzision, höchster VRAM-Verbrauch, beste Qualität. INT8 = halber VRAM, leichte Qualitätseinbußen. Q4 / INT4 = ein Viertel, spürbare Einbußen je nach Anwendungsfall. Für viele produktive Workloads ist Q4 ein Kompromiss zwischen Speicherbedarf und Qualität.

• KV-Cache Quantization: Während das Modell antwortet, speichert es Zwischenergebnisse (den Key-Value-Cache). Dieser Cache wächst proportional zur Kontextlänge. Bei langen Dokumenten wird der KV-Cache größer als das Modell selbst. FP16 = präzise, Q8/Q4 = sparsamer.

• Sequence Length / Kontextlänge: Wie viele Tokens das Modell gleichzeitig verarbeitet — Eingabe plus Ausgabe. Ein Arztbrief oder eine Aktennotiz braucht 4.000 bis 8.000 Tokens, eine längere RAG-Anfrage 16.000+. Mehr Kontext bedeutet mehr KV-Cache und damit mehr VRAM.

• Batch Size / Stapelgröße: Wie viele Anfragen die GPU gleichzeitig verarbeitet. Höhere Batch Size steigert Durchsatz und VRAM-Bedarf.

• Concurrent Users / Gleichzeitige Nutzer: Wie viele Personen zur gleichen Zeit Anfragen stellen. Das ist nicht die Gesamtzahl Ihrer Mitarbeitenden, sondern die Spitzenlast. Faustregel: 15–25 % Ihrer aktiven Nutzer sind in der Mittagsspitze gleichzeitig aktiv.

• Attention Structure / Positional Embeddings (MLA, RoPE, …): Technische Eigenschaften des Modells, die der Calculator automatisch aus dem gewählten Modell übernimmt. Hier nichts einstellen.

Zur Interpretation der Ergebnisse: Der Calculator rechnet mit der vollen Kontextlänge — als ob jeder Nutzer in jeder Anfrage das maximale Fenster ausnutzt. In der Praxis ist das selten der Fall. Chat-Anfragen liegen meist weit unter 4.000 Tokens, viele Dokumentenanalysen unter 10.000. Der reale VRAM-Bedarf liegt deshalb typischerweise unter dem berechneten Worst-Case-Wert. Nutzen Sie den Calculator als Obergrenze, nicht als Mittelwert.

Drei Werte, die Sie in der Praxis verändern: Modell, Quantisierung, Kontextlänge × gleichzeitige Nutzer. Alles andere bleibt auf den Voreinstellungen.

Den Calculator finden Sie unter apxml.com/tools/vram-calculator.

Der Trade-off bei der Quantisierung

Die Quantisierung von FP16 auf Q4 reduziert den VRAM-Bedarf um etwa 75 % und kostet Antwortqualität. Wie viel genau, hängt vom Modell und vom Anwendungsfall ab. Für klassische Aufgaben (Zusammenfassungen, Fragen zu Dokumenten, Auskunftsfunktionen) funktioniert Q4 in der Praxis. Für spezialisierte Fachsprache, medizinische Codierung oder komplexe juristische Analysen lohnt der Test mit höherer Präzision (Q8 oder FP16). Den Unterschied messen Sie nicht in der Theorie, sondern im laufenden Betrieb mit Ihren Daten.

Stütze 3: Skalierungsreserve für 24 Monate

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

1. Adoption wächst. Erfahrungswert aus laufenden Einführungen: 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 Grund ist nicht Hype, sondern Sichtbarkeit: Mitarbeitende sehen, wie Kolleg:innen mit KI schneller arbeiten, und ziehen mit.

2. Anwendungsfälle werden anspruchsvoller. Was als Chat beginnt, wird zu RAG über die gesamte Wissensbasis. Was als Zusammenfassung eines Dokuments beginnt, wird zu vergleichender Analyse über 20 Dokumente. Längere Kontexte, größere Modelle, mehr parallele Anfragen — der Token-Bedarf pro Nutzer wächst schneller als die Nutzerzahl.

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

4. Agentische Workloads. Sie betreiben heute Chat und Dokumentenanalyse. Innerhalb der Abschreibungsdauer Ihrer Hardware kommen agentische Workloads dazu — Anwendungen, in denen das LLM nicht eine Antwort generiert, sondern mehrere Schritte plant, Werkzeuge aufruft und Ergebnisse weiterverarbeitet.

Was dabei passiert: Jeder Agenten-Schritt ist ein eigener LLM-Aufruf, und in jedem Schritt wird der gesamte bisherige Kontext mitgegeben. Der Token-Verbrauch wächst nicht linear mit der Anzahl der Schritte, sondern überproportional — weil der Kontext bei jedem Schritt länger wird.

Belegte Größenordnungen aus laufenden Einführungen agentischer Systeme:

Derselbe Mitarbeiter, der heute 30.000 Tokens pro Tag verbraucht, kommt mit agentischer Unterstützung auf 300.000 bis 3.000.000 Tokens. 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 Planung, ein schnelles für Routine-Schritte. Beide brauchen gleichzeitig VRAM.

💡 Faustregel: Planen Sie heute mit Faktor 3 bis 5 über dem ermittelten Tagesbedarf für klassische Nutzung. Wer agentische Workloads innerhalb der Abschreibungsdauer einplant, rechnet mit Faktor 10 bis 20 — oder wählt eine Architektur, die schnelle Erweiterung erlaubt.

Modulare Architektur als Skalierungspfad

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

1. LLM-Server mit den GPU-Ressourcen für Sprach- und Multimodal-Modelle.

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

3. Management-Server mit Benutzerverwaltung, Auditlog, Monitoring, API-Gateway.

Diese Trennung erlaubt es, die GPU-Komponente unabhängig vom Rest zu skalieren. Wenn der Token-Bedarf wächst, kommt GPU-Kapazität hinzu. Wenn die Wissensbasis wächst, kommt RAG-Kapazität hinzu. Ein monolithischer Aufbau zwingt bei jeder Erweiterung dazu, das Gesamtsystem anzufassen.

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

GPUs in Servern fallen selten aus, aber sie fallen aus. Bei klassischen Web-Servern ist die Antwort auf Ausfallszenarien etabliert: redundante Netzteile, RAID, Cluster. Bei KI-Servern ist die Antwort komplexer, weil GPUs hohe Kosten haben und sich nicht trivial spiegeln lassen.

Drei Redundanz-Stufen, die in der Praxis vorkommen:

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

2. Modell-Redundanz auf mehreren GPUs. Wenn zwei oder mehr GPUs im Server laufen und das Modell auf jeder einzeln Platz findet, läuft der Inference-Stack bei Ausfall einer GPU mit reduzierter Kapazität weiter. Voraussetzung: Das Modell passt auf eine einzelne GPU, oder die Plattform unterstützt automatisches Failover.

3. Server-Redundanz mit zweitem Knoten. Ein zweiter, baugleicher Server übernimmt bei Ausfall des ersten. Das ist die Lösung mit echter Hochverfügbarkeit — und die mit höchsten Kosten.

Für den ersten Produktivbetrieb reicht Komponenten-Redundanz plus ein dokumentierter Wiederherstellungsplan (Ersatzteil-SLA, dokumentierte Wiederinbetriebnahme). Für geschäftskritische Anwendungen — etwa medizinische Diktatsysteme im 24/7-Betrieb — plant man ab Stufe 2, idealerweise mit einem zweiten Knoten.

Klären Sie bei der Ausschreibung: Welche Ausfallzeit ist tolerierbar? Welche Reaktionszeit garantiert der Lieferant? Steht ein Cold-Spare oder Hot-Spare zur Verfügung?

Ausbau und Zukunftsfähigkeit

Selbst wenn Sie heute mit 200 aktiven Nutzern starten — die Frage "Was passiert, wenn wir in zwei Jahren 2.000 oder 10.000 erreichen?" gehört in die Beschaffungsentscheidung. KI-Adoption verläuft selten linear: nach dem Pilot folgt ein steiler Anstieg, wenn weitere Fachbereiche dazukommen.

Drei Ausbaustufen, die bei der Hardware-Auswahl mitzudenken sind:

Stufe 1: Mehr GPUs in denselben Server. Server-Plattformen unterscheiden sich erheblich darin, wie viele GPUs sie aufnehmen. Typische Konfigurationen bieten 2, 4 oder 8 GPU-Slots. Worauf zu achten ist:

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

• Freie Slots: Wenn der Server heute mit 2 von 4 möglichen GPUs ausgeliefert wird, ist die Erweiterung ein Steckvorgang. Sind alle Slots belegt, kommt ein neuer Server.

• Stromreserve im Netzteil: Jede zusätzliche GPU braucht 350 bis 700 Watt. Das Netzteil muss die Erweiterung tragen.

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

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 (Load Balancing zwischen Knoten). Voraussetzung im RZ: Rack-Platz, Stromzuführung, Netzwerk-Anbindung. Bei guter Auslegung passt der zweite Server ohne Umbau ins selbe Rack.

Stufe 3: Multi-Node-Cluster. Bei vielen Tausend Nutzern werden mehrere Server zu einem Cluster verbunden — meist mit InfiniBand für GPU-zu-GPU-Kommunikation über Knotengrenzen hinweg. Das ist eine Architekturentscheidung, die sich nicht nachträglich kostenlos nachholen lässt: InfiniBand-Switches und -Kabel gehören in die Planung, das Netzwerk in die Auslegung.

Fragen, die Sie heute stellen

1. Wie viele GPU-Slots hat der angebotene Server insgesamt — und wie viele sind belegt?

2. Welche PCIe-Generation und wie viele Lanes pro GPU?

3. Welche Netzteilreserve bleibt für zusätzliche GPUs?

4. Welche Kühlungsreserve bleibt bei voller GPU-Bestückung?

5. Ist der Server InfiniBand-vorbereitet (NICs, Slots, Verkabelung)?

6. Wie sieht der Erweiterungspfad zu einem zweiten Knoten aus?

Diese Fragen kosten nichts in der Ausschreibung. Sie ersparen später teure Architekturbrüche.

Hilfe für Ihre Ausschreibung

Damit Sie nicht bei Null anfangen, finden Sie hier eine strukturierte Vorlage zur Anpassung an Ihre Situation. Sie ersetzt keine Rechtsberatung und ist kein vollständiges Lastenheft, liefert aber einen Startpunkt für vergleichbare Angebote.

1. Pflichtanforderungen

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

• NVLink/NVSwitch bei Modellen ab 70B Parametern.

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

• ECC-Speicher für GPU und System-RAM.

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

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

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

• Strom- und Kühlungsanforderungen kompatibel zur bestehenden RZ-Infrastruktur (kW pro Rack, Zuluft, Abluft, ggf. Wasserkühlung).

• DSGVO-konformer Betrieb, keine Telemetrie an externe Hersteller-Cloud.

2. Erweiterungsreserven

• Anzahl freier GPU-Slots im angebotenen Server.

• PCIe-Generation und Lane-Zuordnung pro Slot.

• Stromreserve im Netzteil für zusätzliche GPUs.

• Kühlungsreserve bei voller GPU-Bestückung.

• InfiniBand-Vorbereitung für späteren Multi-Node-Ausbau.

3. Bewertungskriterien mit Gewichtungsvorschlag

Die Gewichtung passen Sie an Ihre Prioritäten an, nicht abschreiben.

4. Lieferumfang

• Hardware vollständig montiert und vorkonfiguriert.

• Inbetriebnahme vor Ort durch den Lieferanten.

• Dokumentation auf Deutsch.

• Schulung der internen Administratoren (Vorschlag: 2 Tage).

• Übergabe-Workshop mit Performance-Nachweis.

5. Service-Level

• Reaktionszeit bei Ausfall (z.B. 4h vor Ort werktags).

• Ersatzteilverfügbarkeit über die gesamte Garantielaufzeit.

• Definierter Eskalationsweg (Name, Telefonnummer, Stellvertretung).

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

6. Abnahmekriterien

• Messbare Performance-Werte 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 die Erweiterungsoptionen technisch funktionieren.

Diese Vorlage ist neutral formuliert. Sie verlangt Leistung, nicht Marken. Das schützt vor Lock-in und führt zu vergleichbaren Angeboten.

Zusammenfassung

Drei Stützen tragen die Hardware-Entscheidung:

1. Bedarf in Tokens ausdrücken. Aus Mitarbeiterzahl, Adoptionsquote und Anwendungsfällen ergibt sich der tägliche Token-Bedarf. Pro 100 aktive Nutzer rund 5 bis 10 Mio. Tokens pro Tag.

2. Bedarf gegen Referenz spiegeln. Eine Maschine mit 2× H200 und GPT-OSS-120B in Q4 unter vLLM erzeugt rund eine Milliarde Tokens pro 24 Stunden. Daraus leiten Sie ab, welche GPU-Klasse, welcher VRAM und welche Anzahl GPUs in Ihrer Konfiguration stehen — damit neben dem LLM auch Embedding, Whisper, OCR und kommende Modelle Platz haben. Bei großen Modellen entscheidet die Verbindung zwischen den Karten (NVLink statt PCIe) mit über die nutzbare Leistung.

3. Skalierungsreserve einplanen. Faktor 3 bis 5 über dem heutigen Bedarf für klassische Nutzung, Faktor 10 bis 20 mit Blick auf agentische Workloads. Modulare Architektur, freie GPU-Slots, Stromreserve, klare Erweiterungspfade.

Mit dieser Methodik beantworten Sie Ihre Sizing-Frage. Der VRAM-Calculator auf apxml.com hilft bei der Detailprüfung. Die getestete Modell-Hardware-Matrix auf docs.basebox.ai/on-premise/llm-recommendations liefert konkrete Konfigurationen mit gemessenen Werten.

basebox ist eine On-Premise-KI-Plattform für Organisationen mit kritischen Daten — Patientendaten, Bürgerdaten, Sozialdaten, Geheimdaten. Für ein Gespräch über konkrete Konfigurationen in Ihrer Situation erreichen Sie uns über die üblichen Wege.

Quellen und weiterführende Werkzeuge

• VRAM-Calculator: apxml.com/tools/vram-calculator

• Getestete Modell-Hardware-Matrix: docs.basebox.ai/on-premise/llm-recommendations