LLM-Hochverfügbarkeit on-premise: zwei GPU-Knoten, Failover und Wartungsfenster
Eurokommerz, Wien, seit 2006: Private AI/ML · IT Managed Services · Enterprise Training · KI-Hardware & Software
- Ein On-Premise-LLM-Dienst übersteht den Ausfall eines Knotens, wenn jeder GPU-Knoten jedes Modell des Dienstes allein betreibt und die ganze Spitze trägt und ein Load Balancer oder Gateway Anfragen nur an Replikate schickt, die ihren Health Check bestehen
- Die Auslegung ist N+1 in der Spitze: Für die 80 Anfragen in Bearbeitung unseres Beispiels mit 2.000 Mitarbeitern und gpt-oss-120b bei 32K brauchen zwei Knoten je 5 RTX PRO 6000 oder 2 H200 NVL, drei Knoten je 3 RTX PRO 6000 oder 1 H200 NVL
- vLLM 0.31.0 beantwortet /health mit 200, solange seine Engine läuft, und mit 503, sobald die Engine ausgefallen ist; NIM for LLMs trennt /v1/health/live von /v1/health/ready, das nur dann 200 liefert, wenn das Modell geladen ist
- Ein Failover verliert die Anfragen in Bearbeitung auf dem ausgefallenen Knoten und dessen Prefix-Cache; NGINX wiederholt standardmäßig keinen POST, der schon an den Upstream gesendet wurde, und kann eine Antwort nicht fortsetzen, sobald ein Teil davon beim Client angekommen ist
- Auf GPU-Knoten ohne freie Karte bleibt das standardmäßige Rolling Update eines Deployments mit zwei Replikaten stehen, weil ein Surge von 25 Prozent auf einen zusätzlichen Pod aufgerundet wird; setzen Sie maxSurge auf 0, aktualisieren Sie Treiber Knoten für Knoten und betreiben Sie etcd mit drei Mitgliedern
Geliefert von Eurokommerz: KI-Server, auf Bestellung gebaut Konfiguration anfragen →
Wie ein On-Premise-LLM verfügbar bleibt, wenn ein Knoten ausfällt
LLM-Hochverfügbarkeit on-premise bedeutet, dass der Dienst weiterläuft, wenn ein GPU-Server ausfällt. Das gelingt, wenn jeder Knoten jedes Modell des Dienstes allein betreiben und dabei noch die ganze Spitze tragen kann und ein Load Balancer oder Gateway Anfragen nur an Replikate schickt, die einen Health Check bestehen. Bei zwei redundanten Knoten heißt das N+1-Auslegung, bei der jeder der beiden Server allein die Spitzenzahl der Anfragen in Bearbeitung hält. Treiber und Modelle werden dann in einem Wartungsfenster Knoten für Knoten aktualisiert. Ein Failover kostet trotzdem die Anfragen, die auf dem ausgefallenen Knoten laufen.
Die Rechnung zur Auslegung stammt aus unserem Leitfaden zu privaten ChatGPT-Servern nach Unternehmensgröße, die Schichten der Plattform aus unserem Leitfaden zu einer privaten LLM-Plattform auf Kubernetes.
Zwei GPU-Knoten für N+1 in der Spitze auslegen
Jeder Knoten muss jedes Modell des Dienstes halten: Ein RAG-Assistent braucht auf dem verbleibenden Knoten auch sein Embedding-Modell, seinen Reranker und den Vektorindex. In unserem Leitfaden zur Unternehmensgröße lässt gpt-oss-120b bei deklarierten 32K Kontext mit einem 16-Bit-KV-Cache Platz für rund 19 Gespräche auf einer RTX PRO 6000 und rund 55 auf einer H200 NVL, und sein Beispiel mit 2.000 Mitarbeitern ergibt eine Spitze von 80 Anfragen in Bearbeitung.
| AUFBAU | KARTEN, SPITZE 80 | EIN KNOTEN FÄLLT AUS | WÄHREND DER WARTUNG | ETCD-MITGLIEDER |
|---|---|---|---|---|
| Ein Knoten | 5 × RTX PRO 6000 oder 2 × H200 NVL | Dienst ausgefallen | Dienst für die Dauer des Fensters ausgefallen | 1, toleriert keinen Ausfall |
| Zwei Knoten | 5 × RTX PRO 6000 oder 2 × H200 NVL je Knoten, insgesamt 10 oder 4 | 95 oder 110 Sitzungen gehalten | der andere Knoten hält die Spitze, ohne Failover-Reserve | 2, tolerieren weiterhin keinen Ausfall: einen dritten Control-Plane-Knoten ergänzen |
| Drei Knoten | 3 × RTX PRO 6000 oder 1 × H200 NVL je Knoten, insgesamt 9 oder 3 | 114 oder 110 Sitzungen gehalten | 114 oder 110 gehalten; ein zweiter Ausfall lässt 57 oder 55 | 3, tolerieren einen Ausfall |
Sitzungen sind Gespräche mit gpt-oss-120b bei 32K mit einem 16-Bit-KV-Cache, 19 je RTX PRO 6000 und 55 je H200 NVL, unsere Schätzungen aus dem Leitfaden zur Unternehmensgröße; die Spitze von 80 beruht auf dessen Beispielwerten. Ausfalltoleranz von etcd aus der FAQ zu etcd v3.6.
Bei zwei Knoten sind die GPUs eines Knotens in der stärksten Stunde Failover-Reserve. Bei drei Knoten hält jeder die halbe Spitze, wofür 9 statt 10 RTX PRO 6000 oder 3 statt 4 H200 NVL reichen. Während der Wartung eines Knotens laufen beide Aufbauten ohne Failover-Reserve; legen Sie das Fenster also außerhalb der Spitze.
KI-Server bauen wir auf Bestellung mit 2 bis 8 GPUs je Knoten, ausgelegt nach Modellgröße und gleichzeitigen Nutzern, und liefern beide Knoten unter einem EU-Vertrag und auf einer Rechnung. Schicken Sie uns über das Formular unten Ihre Modelle und die Spitzenzahl der Anfragen in Bearbeitung.
Health Checks und Load Balancing vor vLLM
Die Dokumentation von vLLM zum Online-Serving führt /health und /metrics unter seinen Endpunkten auf. In vLLM 0.31.0, erschienen am 5. Oktober 2026, liefert /health den Status 200, wenn die Engine ihren Health Check besteht, und 503, sobald die Engine ausgefallen ist. Standardmäßig überlebt der API-Server seine Engine nicht: Die Variable VLLM_ von vLLM, standardmäßig ausgeschaltet, hält den Server auch nach einem Fehler der zugrunde liegenden AsyncLLMEngine am Leben. Richten Sie den Load Balancer auf /health statt auf den TCP-Port aus und lassen Sie eine Liveness-Probe oder den Service-Manager den Prozess neu starten. NVIDIA NIM for LLMs teilt die Prüfung in zwei: /v1/health/live liefert 200, wenn der Container läuft, und /v1/health/ready liefert 200, wenn das Modell geladen und Inferenz verfügbar ist.
Ein Health Check zeigt, ob die Engine läuft, nicht, ob sie mit der Last mithält; Warteschlange, KV-Cache und Latenz kommen aus den Metriken in unserem Leitfaden zum Monitoring des LLM-Servings.
Ohne Kubernetes verteilt ein Reverse Proxy auf einem separaten Host die Anfragen. Das Open-Source-NGINX prüft passiv: Standardmäßig markiert ein fehlgeschlagener Versuch (max_fails) innerhalb von 10 Sekunden (fail_timeout) einen Server für 10 Sekunden als nicht verfügbar. Verbindungsfehler, Timeouts und ungültige Header zählen als fehlgeschlagene Versuche, ein HTTP 503 aber nur, wenn proxy_next_upstream den Wert http_503 aufführt. Aktive Prüfungen mit seiner Direktive health_check sind laut NGINX nur als Teil seines kommerziellen Abonnements verfügbar, und ihre Standard-URI ist /; setzen Sie sie also auf /health. Chat-Anfragen sind POST-Anfragen, die NGINX nicht an den nächsten Server weitergibt, sobald sie an einen Upstream-Server gesendet wurden, es sei denn, die Option non_idempotent ist gesetzt. Seine Dokumentation ergänzt, dass sich eine Anfrage nur dann an den nächsten Server weitergeben lässt, wenn noch nichts an einen Client gesendet wurde. Sein proxy_read_timeout von 60 s gilt zwischen zwei Lesevorgängen; eine nicht gestreamte Antwort, die länger als eine Minute braucht, endet deshalb in einem Timeout, sofern Sie den Wert nicht erhöhen.
Der Proxy ist selbst ein Single Point of Failure; keepalived, in Version 2.4.3 vom Juli 2026, betreibt zwei Proxys auf einer virtuellen IP-Adresse mit VRRP.
Was ein Failover verliert: Anfragen in Bearbeitung und gecachte Präfixe
Fällt ein Knoten aus, gehen die Anfragen verloren, die auf ihm laufen, und eine gestreamte Antwort bricht mit einem Fehler ab. Das Gespräch bleibt erhalten, denn eine Anfrage an die OpenAI-kompatible Chat-API trägt die Nachrichten des Gesprächs mit, und das Chat-Frontend speichert sie in seiner eigenen Datenbank. Der Nutzer lässt die Antwort neu erzeugen, und die nächste Anfrage geht an den verbleibenden Knoten.
Dieser Knoten startet ohne die Präfixe, die der ausgefallene Knoten im Cache hatte. Das automatische Prefix-Caching von vLLM speichert den KV-Cache bestehender Anfragen, damit eine neue Anfrage mit demselben Präfix ihn wiederverwenden kann, und zwar im GPU-Speicher eines Servers. Nach einem Failover wird jedes verschobene Gespräch ab seinem ersten Token neu verarbeitet; die Zeit bis zum ersten Token steigt also, bis sich der Cache wieder gefüllt hat, und zwar in dem Moment, in dem der verbleibende Knoten die ganze Last übernimmt.
Das Chat-Frontend und seine Datenbank, das Gateway und die Vektordatenbank brauchen ebenfalls jeweils eine zweite Instanz. Halten Sie die Modellgewichte auf lokalem NVMe in jedem Knoten, mit gepinnter Revision und einem Prüfsummen-Manifest, damit ein ausgefallener Fileserver kein Replikat am Start hindern kann. Was jede dieser Komponenten hält und wie Sie sie wiederherstellen, steht in unserem Leitfaden zum Backup eines KI-Servers.
Ausfälle und Änderungen: was passiert und wie das Design antwortet
| EREIGNIS | WAS PASSIERT | ANTWORT IM DESIGN |
|---|---|---|
| Ganzer Knoten ausgefallen | Anfragen in Bearbeitung auf ihm enden mit einem Fehler; der Balancer nimmt ihn heraus, sobald seine Prüfung fehlschlägt | jeder Knoten trägt die Spitze allein; getrennte Stromzuführungen und Switch-Ports |
| GPU vom Bus gefallen, Xid 79 | die vLLM-Engine auf dieser Karte fällt aus | der Health Check nimmt das Replikat heraus; NVIDIAs Triage-Leitfaden weist an, den Knoten zu leeren |
| Engine ausgefallen | /health antwortet mit 503, und standardmäßig beendet sich dann der API-Server | Health Checks und Liveness-Probes auf /health, nicht auf den Port |
| Neustart nach Absturz | das Replikat bedient erst wieder Anfragen, wenn seine Gewichte geladen sind | eine Startup-Probe, die die Ladezeit abdeckt; Gewichte auf lokalem NVMe |
| Load-Balancer-Host verloren | keiner der beiden gesunden Knoten erhält Verkehr | zwei Proxys, die sich per VRRP eine virtuelle IP-Adresse teilen |
| Update von Treiber oder vLLM | das Replikat des Knotens hält für das Update an | ein Knoten nach dem anderen, in einem Fenster, nach Prüfung der Kapazität des anderen Knotens |
| 2 etcd-Mitglieder, eines weg | etcd hat keine Mehrheit, und der Cluster kann keine Änderungen speichern | drei Control-Plane-Mitglieder, die kleine Server ohne GPUs sein können |
Quellcode von vLLM 0.31.0 (/health, Umgebungsvariablen); NVIDIAs Xid-Katalog und Triage-Leitfaden, wie in unserem DCGM-Leitfaden zusammengefasst; Kubernetes-Dokumentation v1.37; FAQ zu etcd v3.6; Projektseite von keepalived.
Alarmieren Sie je Knoten, denn ein Pool mit einem ausgefallenen Knoten antwortet bis zur nächsten Spitze normal. Vergleichen Sie die Spitze der laufenden plus wartenden Anfragen, summiert über beide Knoten, mit dem, was ein Knoten allein hält: Nähert sich die Summe diesem Wert, ist die Failover-Reserve aufgebraucht. Unser Leitfaden zum GPU-Server-Monitoring mit DCGM führt die XIDs auf, nach denen ein Knoten zu leeren ist.
Kubernetes: zwei Replikate, Probes und Rolling Updates ohne freie GPU
Geben Sie auf Kubernetes dem Deployment des Modells zwei Replikate und eine verpflichtende (required) Pod-Anti-Affinität mit dem Topologieschlüssel kubernetes.io/hostname, die im Beispiel der Kubernetes-Dokumentation den Scheduler anweist, nicht mehrere Replikate auf einem Knoten zu platzieren. Das Kubernetes-Beispiel in der aktuellen Dokumentation von vLLM prüft /health an Port 8000 für Liveness und Readiness, jeweils mit einer Anfangsverzögerung von 60 Sekunden. Ein Pod, dessen Readiness-Probe fehlschlägt, erhält von keinem Service Verkehr, und eine fehlschlagende Liveness-Probe lässt das kubelet den Container neu starten. Die Seite von vLLM warnt vor einem failureThreshold, der für die Zeit zum Starten des Servers zu niedrig ist; ergänzen Sie eine Startup-Probe, deren failureThreshold × periodSeconds das langsamste Laden eines Modells abdeckt, dessen Dauer Sie gemessen haben.
Rolling Updates brauchen Sorgfalt auf Knoten, deren GPUs alle belegt sind. Ein Deployment setzt maxSurge und maxUnavailable standardmäßig auf 25 Prozent, wobei maxSurge aufgerundet und maxUnavailable abgerundet wird; bei zwei Replikaten legt Kubernetes also zuerst einen zusätzlichen Pod an und entfernt keinen. Dieser Pod braucht eine unbelegte GPU und, mit der Anti-Affinität oben, einen dritten Knoten; ohne beides bleibt er Pending. Die alten Replikate bedienen weiter, während der Rollout stehen bleibt. Mit maxSurge auf 0 und maxUnavailable auf 1 wird jeweils ein Pod auf der GPU ersetzt, die er freigibt. Im Deployment-Modus Standard nennt KServe 0.20.0, Stand Oktober 2026 das aktuelle Release, die Einstellung mit maxSurge auf 0 seinen Modus ResourceAware; sein Modus Availability, mit maxUnavailable auf 0, braucht die freie GPU.
NVIDIAs Helm-Chart für NIM for LLMs legt standardmäßig ein StatefulSet an. Kubernetes aktualisiert es Pod für Pod, löscht jeden alten Pod, bevor sein Ersatz startet, und wartet, bis dieser „Running and Ready“ ist; eine freie GPU ist also nicht nötig. Für den Deployment-Modus des Charts schlägt seine Dokumentation Recreate vor, wenn der Cluster keinen zusätzlichen GPU-Pod erübrigen kann, aber Recreate stoppt alle Pods, bevor neue starten, was einen Dienst mit zwei Replikaten ausfallen lässt; bleiben Sie also beim StatefulSet aus der Voreinstellung.
Bei einem Drain oder einem Update sendet das kubelet SIGTERM und nach terminationGracePeriodSeconds, standardmäßig 30 Sekunden, SIGKILL. In vLLM 0.31.0 steht --shutdown-timeout standardmäßig auf 0, was sein Hilfetext mit „0 = abort, >0 = wait“ erklärt. Mehr sagt die Dokumentation zu Anfragen in Bearbeitung nicht; setzen Sie den Wert also so, dass er eine lange Antwort abdeckt, setzen Sie die Grace Period darüber und testen Sie einen Drain unter Last. Ein PodDisruptionBudget mit minAvailable 1 lässt kubectl drain jeweils nur ein Replikat räumen, begrenzt aber nicht das Rolling Update eines Deployments, und unfreiwillige Störungen lassen sich laut Kubernetes nicht durch PDBs verhindern. Zwei GPU-Knoten allein ergeben keinen hochverfügbaren Cluster: Die FAQ von etcd gibt einem Cluster mit zwei Mitgliedern eine Ausfalltoleranz von 0 und empfiehlt eine ungerade Zahl von Mitgliedern; betreiben Sie also drei Control-Plane-Mitglieder.
Treiber- und Modell-Updates Knoten für Knoten
Der NVIDIA GPU Operator, mit 26.7.1 Stand Oktober 2026 das neueste Release in seinen Release Notes, aktualisiert containerisierte Treiber über einen Upgrade-Controller, der standardmäßig aktiviert ist. Ohne gesetzte Upgrade-Policy aktualisiert er jeweils einen Knoten, sperrt ihn (cordon), löscht die Pods, die GPUs belegen, bevor er den Treiber neu lädt, und lässt das Leeren (Drain) ausgeschaltet; die Dokumentation schreibt dazu „By default, drain is disabled“. Auf dem Host installierte Treiber liegen außerhalb seines Bereichs, und unser Leitfaden zu NVIDIA-Treiberzweigen und CUDA-Versionen behandelt, welcher Zweig zu wählen ist. Von Hand ist die Reihenfolge dieselbe.
- Prüfen Sie im Monitoring, dass der andere Knoten allein die Spitze der letzten Arbeitstage gehalten hat.
- Nehmen Sie den Knoten aus dem Load Balancer und warten Sie, bis
vllm:num_requests_running0 erreicht; auf Kubernetes sperren (cordon) und leeren (drain) Sie ihn. - Aktualisieren Sie den Treiber, die Images oder vLLM, starten Sie neu, wo der Treiber es verlangt, und bestätigen Sie in nvidia-smi und DCGM, dass jede GPU wieder da ist.
- Lassen Sie Ihren festen Evaluationssatz direkt gegen den Knoten laufen, bevor er wieder Verkehr erhält.
- Nehmen Sie den Knoten wieder in den Pool auf, beobachten Sie ihn durch die nächste Spitzenstunde und wiederholen Sie den Ablauf dann auf dem zweiten Knoten.
Eine neue Modellversion folgt derselben Reihenfolge; behalten Sie die vorherigen Gewichte auf der lokalen Platte jedes Knotens, damit ein Rollback keinen Download braucht.
Unsere Leistung Private AI/ML, mit Engineering von unserem Engineering-Partner Vixen.UNO, baut eine Kubernetes-basierte Plattform mit KServe und stellt Modelle mit vLLM bereit, mit laufendem Support unter SLA. Beschreiben Sie Ihr Setup und Ihre Wartungsfenster im Formular unten.
Was wir liefern
Wir liefern beide GPU-Knoten als nach Auftrag gebaute KI-Server mit 2 bis 8 GPUs je Knoten, mit Karten RTX PRO 6000 Server Edition oder H200 NVL für das Sprachmodell und der L4 oder L40S für Embedding- und Reranking-Modelle. Sie werden vor dem Versand unter Last getestet, mit Herstellergarantie auf jede Komponente, unter einem EU-Vertrag und auf einer Rechnung. Wir prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot erstellen, und Konfiguration und Angebot folgen innerhalb eines Werktages. Die Plattform darüber, mit einem Query-Log und einem für den Betrieb geschulten Team, ist unsere Leistung Private AI/ML, mit Engineering von unserem Engineering-Partner Vixen.UNO.
FAQ
Wie erreicht man LLM-Hochverfügbarkeit on-premise?
Unterstützt vLLM Hochverfügbarkeit?
Wie viele GPU-Server braucht ein LLM-Failover?
Was passiert mit laufenden Chats, wenn ein LLM-Server ausfällt?
Wie aktualisiere ich ein LLM ohne Ausfallzeit?
Kann ein Kubernetes-Cluster mit zwei Knoten hochverfügbar sein?
Schicken Sie uns die Modelle, die Sie bereitstellen, die Spitzenzahl der Anfragen in Bearbeitung, wie lange der Dienst nicht verfügbar sein darf und ob er auf Kubernetes läuft. Wir antworten innerhalb eines Werktages mit einer Konfiguration und einem Angebot für beide Knoten. Das erste Gespräch zur Plattform ist kostenlos.
Mit einem Experten sprechenWir antworten innerhalb eines Werktages