KI-Server für die Lehre: LLM-Zugang für Tausende Studierende, nach Spitzenlast ausgelegt

Was ein KI-Server für die Lehre leisten muss

Eine Universität oder Hochschule, die Tausenden Studierenden Zugang zu einem Sprachmodell gibt, legt den KI-Server nach der Zahl der Anfragen aus, die im Spitzenmoment laufen. Ein Server mit zwei NVIDIA RTX PRO 6000 Blackwell Server Edition reicht für eine Fakultät oder ein Pilotprojekt, vier Karten tragen einen universitätsweiten Chat-Dienst mit einem großen Modell, und acht Karten oder zwei Server mit je vier Karten tragen Prüfungszeiten und mehrere Modelle zugleich. Ein Gateway vor den Servern vergibt Schlüssel je Lehrveranstaltung und Limits je Studierendem, ein Chat-Frontend mit Single Sign-on gibt allen ein Konto.

Für das Rektorat oder die IT-Leitung hängt die Entscheidung an drei Zahlen: wie viele Studierende den Dienst in der Spitzenstunde nutzen, wie lang ihre Konversationen sind und welches Modell die Lehrenden wollen. Der Rest dieses Artikels macht aus diesen Zahlen eine Konfiguration. Ein Forschungslabor, das GPUs für eigene Jobs teilt, hat ein anderes Problem, das unser Leitfaden zum GPU-Server für Universität und Labor mit Slurm, MIG und Fair-Share löst.

Wie viele Studierende den Dienst gleichzeitig nutzen

Die Zahl der Eingeschriebenen sagt wenig. Die GPUs belastet die Zahl der Anfragen, an denen das Modell in einem Moment arbeitet, die laufenden Anfragen. Sie ergibt sich aus zwei Werten, die das Log des Gateways zeigt, sobald der Dienst läuft: wie viele Anfragen pro Sekunde eintreffen und wie lange jede Antwort dauert. Multipliziert ergeben sie die mittlere Zahl laufender Anfragen.

Ein Beispiel mit angenommenen Werten, nach unserer Rechnung: An einem Abend vor den Prüfungen sind 1.000 Studierende aktiv, jede und jeder sendet alle zwei Minuten einen Prompt, und jede Antwort läuft etwa 15 Sekunden. Das sind 1.000 ÷ 120 = 8,3 Anfragen pro Sekunde, mal 15 Sekunden, rund 125 laufende Anfragen. Derselbe Campus hat mittags im Semester vielleicht 300 aktive Studierende und 40 laufende Anfragen.

Die Lehre bringt eine Last, die Unternehmen selten kennen: die plötzliche Lastspitze. Eine Dozentin bittet 400 Studierende im Hörsaal, einen Prompt jetzt auszuprobieren, und 400 Anfragen kommen innerhalb einer Minute an. Ein Server mit Platz für 241 Konversationen beantwortet die ersten 241 sofort und reiht die übrigen ein, bis frühere Antworten fertig sind, im Beispiel nach rund 15 Sekunden; für eine Übung im Hörsaal ist das vertretbar, wenn das Frontend anzeigt, dass die Anfrage wartet. Ein Limit für Anfragen je Studierendem im Gateway verhindert, dass ein Skript oder eine ungeduldige Person die Lastspitze vervielfacht.

Unsere Beispielwerte, keine Messungen: ein Prompt alle zwei Minuten je aktivem Studierenden und 15 Sekunden je Antwort (8,3 Anfragen pro Sekunde × 15 s ≈ 125). Ersetzen Sie sie durch Ankunftsrate und Antwortzeit aus dem Log Ihres Gateways.

Welches Modell, und wie viele Konversationen jede Konfiguration hält

Lehrende wünschen meist ein leistungsfähiges allgemeines Modell für alle und manchmal ein kleineres, schnelleres für Programmierübungen oder Massenaufgaben. gpt-oss-120b und gpt-oss-20b von OpenAI sind Modelle mit offenen Gewichten, deren MXFP4-Checkpoints 60,8 GiB und 12,8 GiB belegen. Unsere Regel für Nutzer je Karte nimmt 0,9 × die 95,6 GiB, die der Treiber je RTX PRO 6000 Server Edition meldet, minus 3 GiB je Karte, minus die Gewichte, und teilt den Rest durch den KV-Cache je Konversation: 1,125 GiB je Konversation mit 32K bei gpt-oss-120b und 0,75 GiB bei gpt-oss-20b, jeweils in 16 Bit.

Unsere Schätzung nach der Regel für Nutzer je Karte: gleichzeitige Konversationen in voller Kontextlänge, KV-Cache in 16 Bit; Checkpoint von gpt-oss-120b 65,3 GB (60,8 GiB) und von gpt-oss-20b 13,76 GB (12,8 GiB) auf Hugging Face; Cache von gpt-oss-20b aus dessen config.json (12 Schichten mit voller Attention, 8 KV-Heads der Dimension 64).

Das sind Grenzen des Speichers. Studierende, die in kurzen Wechseln chatten, füllen 32K selten, die Spalte für 8K liegt also näher an einem Dienst für die Lehre; bei mehreren Hundert Konversationen je Karte erhält aber jede weniger Token pro Sekunde. Das eigene Limit der Serving-Engine für gleichzeitige Sequenzen muss passend gesetzt werden. Unser Leitfaden Wie viele Nutzer schafft eine RTX PRO 6000? erklärt die Regel und ihre Grenzen.

Veröffentlichter Durchsatz für acht RTX PRO 6000 Server Edition

Der Speicher sagt, wie viele Konversationen Platz haben; der Durchsatz sagt, wie schnell sie beantwortet werden. MLCommons veröffentlicht verifizierte Ergebnisse für Server mit acht RTX PRO 6000 Server Edition, darunter die beiden Modelle, die einem Dienst für die Lehre am nächsten kommen.

MLPerf® Inference: Datacenter v6.1, Closed Division, gpt-oss-120b und Llama 3.1 8B, Szenarien Server und Interactive, Token pro Sekunde, Einträge 6.1-0050 und 6.1-0082, jeweils mit acht RTX PRO 6000 Blackwell Server Edition, abgerufen von mlcommons.org am 24. Oktober 2026. Ergebnisse von der MLCommons Association verifiziert. The MLPerf name and logo are registered and unregistered trademarks of MLCommons Association in the United States and other countries. All rights reserved. Unauthorized use strictly prohibited. See www.mlcommons.org for more information.

Das Szenario Server schickt Anfragen in zufälligen Abständen und hält Latenzgrenzen ein, was einem Chat-Dienst nahekommt. Hat eine Antwort im Mittel 500 Token, sind 14.581,7 Token pro Sekunde nach unserer Rechnung rund 29 Antworten pro Sekunde oder rund 1.750 pro Minute; ein kleines Modell der Klasse Llama 3.1 8B beantwortet rund 99 pro Sekunde. Gegenüber den 8,3 Anfragen pro Sekunde aus dem Beispiel vor den Prüfungen hat ein Server mit acht Karten und gpt-oss-120b reichlich Reserve. Ein verifiziertes Ergebnis mit vier Karten für gpt-oss-120b zitieren wir hier nicht; nach unserer Schätzung trägt ein Server mit vier Karten, bei etwa der Hälfte der Rate mit acht Karten, das Beispiel noch, mit weniger Spielraum. Unser Überblick zu MLPerf Inference v6.1 für PCIe-GPU-Server nennt die übrigen Einträge.

Wir bauen diese Server mit zwei, vier oder acht Karten; schicken Sie uns die Zahl der Studierenden, die geplanten Modelle und eine Schätzung der Spitzenstunde, und unser Team antwortet mit einer Konfiguration und den Konversationen, die sie hält.

Gateway, Schlüssel und Quoten für Lehrveranstaltungen und Studierende

Ein Modellserver weiß nichts von Studierenden. vLLM prüft statische API-Schlüssel, hat aber keine Benutzerkonten; ein Gateway davor muss also wissen, welche Lehrveranstaltung und welcher Studierende eine Anfrage gesendet hat. Unser Leitfaden zum LLM-Gateway mit Schlüsseln, Token-Budgets und Abfrageprotokoll behandelt die Optionen; für die Lehre zeigt der Proxy von LiteLLM das Muster.

• Schlüssel je Lehrveranstaltung oder Fakultät. Jede Lehrveranstaltung oder Fakultät erhält ein Team mit eigenem Schlüssel, erlaubten Modellen und Limits, sodass ein Programmierkurs das kleinere Modell über die API aufruft, während das Chat-Frontend das große nutzt.
• Limits je Studierendem. Anfragen pro Minute (rpm_limit) und Token pro Minute (tpm_limit) je Schlüssel oder Team hindern Skripte und Schleifen daran, den Server zu belegen.
• Budgets je Zeitraum. Ein max_budget mit einer budget_duration wie 7d wird jede Woche zurückgesetzt; bei einem eigenen Modell zählt das Budget einen internen Satz je Token, kein Geld.
• Stapelverarbeitung nachrangig zum interaktiven Betrieb. Massenaufgaben wie Hilfe bei der Korrektur oder Dokumentenverarbeitung laufen unter Schlüsseln, deren Token-Limits dem Chat-Modell Raum für seine Spitze lassen.

Die Datenbank des Gateways zeigt dann Token je Fakultät und Lehrveranstaltung, die Grundlage für eine interne Kostenverrechnung, wie unser Leitfaden zu GPU-Kostenverrechnung und Quoten beschreibt.

Das Chat-Frontend für Tausende Konten

Die meisten Studierenden erreichen das Modell über den Browser. Open WebUI ist ein verbreitetes Frontend, und sein Skalierungsleitfaden ändert für große Installationen mehrere Voreinstellungen: PostgreSQL statt SQLite, Redis für Websockets und gemeinsamen Zustand, mehrere Replikate hinter einem Load Balancer mit je einem Worker und eine externe Vektordatenbank für hochgeladene Dokumente. Seine Kurzreferenz nennt diese Punkte als Pflicht für mehrere Instanzen und führt Installationen ab 1.000 Nutzern mit denselben Anforderungen auf.

Die Anmeldung sollte über OIDC vom Identity Provider der Universität kommen, damit Konten mit dem Ausscheiden enden und Claims zu Rolle oder Studiengang bestimmen, welche Modelle jemand sieht. Unser Leitfaden zu Open WebUI für 1.000 Nutzer und mehr beschreibt Replikate, Redis-Einstellungen, Speicher und die Reihenfolge bei Upgrades. Lehrveranstaltungen zu maschinellem Lernen brauchen zudem GPUs für Notebooks; MIG teilt jede RTX PRO 6000 Server Edition in bis zu vier Instanzen zu 24 GB, vier für die Lehre reservierte Karten ergeben also 16 isolierte Notebooks, wie unser Leitfaden zu den MIG-Profilen der RTX PRO 6000 zeigt. Karten im MIG-Modus stehen einer Tensor-Parallel-Kopie des Chat-Modells nicht zur Verfügung, denn laut NVIDIAs MIG-Leitfaden wird NCCL mit MIG nicht unterstützt; planen Sie die Notebook-Karten daher zusätzlich zu den Karten für den Chat-Dienst.

Drei Konfigurationen: zwei, vier oder acht Karten

Das sind die Referenz­konfigurationen auf unserer Seite zu KI-Servern; Arbeitsspeicher und Prozessorkerne folgen NVIDIAs Konfigurations­leitfaden für NVIDIA-Certified Systems: mindestens das Doppelte des GPU-Speichers als Arbeitsspeicher, mindestens sechs Kerne je GPU und zwei Sockel.

Unsere Seite zu KI-Servern und NVIDIAs Konfigurations­leitfaden für NVIDIA-Certified Systems (30. September 2026). Leistung an der Steckdose nach unserer Schätzung: Karten mit 600 W, zwei EPYC 9135 (zwei Karten), 9355 (vier) oder 9555 (acht), plus 15 Prozent für den Rest.

Einstieg mit zwei Karten. Hier beginnt eine Fakultät, oder eine ganze Universität betreibt ein Semester lang ein Pilotprojekt, bevor sie sich auf einen Dienst für den Campus festlegt. Das Kartenpaar hält gpt-oss-120b für rund 90 lange oder mehrere Hundert kurze Konversationen und passt an einen 230-V-Anschluss mit 16 A. Unsere Seite zum Server mit zwei RTX PRO 6000 Server Edition hat die Einzelheiten.

Dienst für den Campus mit vier Karten. Eine Kopie von gpt-oss-120b über vier Karten hält 241 Konversationen mit 32K, etwa das Doppelte des Beispiels vor den Prüfungen. Zwei Server mit je vier Karten statt eines Servers mit acht halten den Dienst bei Updates und Ausfällen am Laufen, was zählt, wenn eine Prüfungswoche daran hängt; unser Vergleich ein 8-GPU-Server oder zwei 4-GPU-Server wägt beides ab.

Acht Karten. Zwei Kopien von gpt-oss-120b oder ein großes Modell plus ein kleines für Programmierkurse, mit dem oben veröffentlichten Durchsatz. Unser Leitfaden, was acht RTX PRO 6000 Server Edition betreiben, behandelt größere Modelle.

Die H200 NVL passt zu einer Universität, die auf derselben Plattform auch Modelle trainiert; für einen Dienst mit vielen Studierenden bietet die RTX PRO 6000 Server Edition mehr Karten und Konversationen je Server.

Strom, Rack und Raum

Nach unserer Schätzung, mit Karten bei 600 W, zieht ein Server mit zwei Karten und zwei EPYC 9135 rund 1,8 kW an der Steckdose, einer mit vier Karten und zwei EPYC 9355 rund 3,4 kW und einer mit acht Karten und zwei EPYC 9555 rund 6,3 kW. Einen 230-V-Anschluss mit 16 A planen wir mit 80 Prozent ein, also 2,94 kW: Der Server mit zwei Karten passt daran, der mit vier braucht 32 A einphasig oder Drehstrom, der mit acht Drehstrom oder mehrere Anschlüsse. Dells Datenblatt nennt als Richtwert rund 8 kW je Knoten mit acht Karten, geplant wird der Anschluss daher nach dem Wert des Gehäuseherstellers. Ein Dienst für die Lehre ruht nachts und in den Ferien, ausgelegt wird der Anschluss aber für die Prüfungswoche. Unser Leitfaden zum Stromanschluss von GPU-Servern mit 16 A, 32 A und Drehstrom behandelt redundante Netzteile und Kabel.

Daten der Studierenden, Logs und Aufbewahrung

Prompts können Namen, Matrikelnummern und Studienarbeiten enthalten, das Abfrageprotokoll enthält also personenbezogene Daten. Artikel 5 Absatz 1 Buchstabe e der DSGVO verlangt, solche Daten nicht länger aufzubewahren, als es für ihren Zweck nötig ist. Was das Log speichert, wer es lesen darf und wie lange, entscheidet die oder der Datenschutz­beauftragte der Universität, bevor sich die ersten Studierenden anmelden; die Einstellungen des Gateways für Inhalt und Aufbewahrung des Logs folgen dann dieser Entscheidung. Dies ist eine allgemeine Information, keine rechtliche Bewertung.

Den Server für die Lehre bei uns bestellen

Diesen Server können Sie bei uns kaufen: Unser Team legt die Konfiguration auf Ihre Arbeitslast und Ihr Budget aus und antwortet innerhalb eines Werktages. Die Auslegung ist kostenlos. Wir montieren die Server, testen sie vor der Lieferung und liefern sie in die gesamte EU mit einem Vertrag und einer Rechnung, mit Herstellergarantie auf jede Komponente, und für die Montage stehen wir selbst ein. Auf Wunsch installieren wir Betriebssystem, NVIDIA-Treiber, CUDA und eine Container-Runtime und nehmen die Server vor Ort in Betrieb. Gateway, Chat-Frontend und Anmeldung gehören zu unserem Service Private AI/ML, umgesetzt von unserem Engineering-Partner Vixen.UNO. Stückzahlen und Lieferzeit werden mit dem Angebot schriftlich bestätigt, und Vorgaben einer Ausschreibung können Sie in der Anfrage nennen.

Für eine genaue Konfiguration brauchen wir die Zahl der Studierenden und Beschäftigten, eine Schätzung der Spitzenstunde, die von den Lehrenden gewünschten Modelle, die typische Länge der Konversationen, ob Lehrveranstaltungen Notebooks oder API-Zugang brauchen, sowie Rack und Stromanschluss. Beschreiben Sie diese Punkte im Formular unten, und wir antworten mit einer Konfiguration und einem schriftlichen Angebot.

FAQ