Wie skaliert eine On-Premises-Infrastruktur?

Es ist die erste Frage, die sich jeder CTO stellt, wenn das Thema On-Premise-KI aufkommt, und sie wird meist mit einer hochgezogenen Augenbraue gestellt. Die Cloud soll eigentlich das sein, was Kapazität zum Problem anderer Leute macht. Eigene Hardware klingt nach dem Gegenteil: starr, langsam, eine Rückkehr in die Ära der Serverräume.

Die Skepsis ist berechtigt. Es ist jedoch auch bemerkenswert, dass die Cloud am oberen Ende des GPU-Marktes die Kapazität ebenfalls nicht wirklich zum Problem anderer Leute macht. Beschleuniger der aktuellen Generation sind an Quoten, Wartelisten, regionale Verfügbarkeitsgrenzen und Reservierungsverpflichtungen gebunden. Die Cloud hat die Kapazitätsfrage nicht von Ihrer Roadmap verbannt. Sie hat sie lediglich in eine Beschaffungsverhandlung verwandelt, die Sie mit einem Vertriebsmitarbeiter statt über eine Bestellung führen.

Der tatsächliche Vergleich lautet also nicht elastisch versus starr. Es geht darum, für welche Art von Wachstum Sie planen wollen. Eine eigene KI-Infrastruktur skaliert anders als die Cloud, nicht schlechter, und speziell bei Inference-Workloads spricht der Unterschied oft zu Ihren Gunsten. So sieht Skalierung tatsächlich aus, wenn die Hardware Ihnen gehört.

Beginnen Sie damit, was Skalierung für Inference bedeutet

Training-Runs sind unregelmäßig und weisen Spitzen auf. Inference ist es nicht. Ein interner KI-Assistent, eine Pipeline zur Dokumentenverarbeitung oder ein Codierungs-Agent erzeugen eine bemerkenswert flache Lastkurve: hoch während der Arbeitszeit, Woche für Woche vorhersehbar und stetig wachsend, je weiter die Nutzung voranschreitet.

Die On-Demand-Preise für die Cloud sind für das gegenteilige Muster ausgelegt, und es lohnt sich, genau zu verstehen, warum sie so viel kosten. Der Aufschlag bei einem On-Demand-Tarif ist keine Gebühr für die Hardware. Es ist der Preis für eine Option: das Recht, Kapazitäten jederzeit und ohne Verpflichtung hinzuzufügen oder zu reduzieren. Diese Option hat einen realen Wert, wenn Ihre Last unregelmäßig ist. Wenn Ihre Lastkurve jedoch flach ist, bezahlen Sie diese Option jede Stunde, ohne sie jemals zu nutzen.

Das ist der Tausch, den wir als „Utilization Inversion“ bezeichnen. Keine neue Entdeckung in der Cloud-Ökonomie, sondern ein Name für die spezifische Form, die sie bei der KI-Inferenz annimmt: Die Workloads, die den größten Nutzen für das Unternehmen bringen, sind genau diejenigen, die am wenigsten von dem profitieren, wofür die Cloud-Preise berechnet werden. Dauerhaft aktive Agenten, die mit einer konstant hohen Auslastung laufen, sind genau der Fall, in dem das Mieten von Elastizität, die man nie nutzt, die teuerste Art ist, Rechenleistung zu kaufen.

Wie viel günstiger das ist, hängt ganz von Ihren Zahlen ab. Deshalb möchten wir lieber, dass Sie diese selbst durchrechnen, anstatt einen pauschalen Prozentsatz von einem Anbieter zu übernehmen. Unser ROI-Rechner fragt nach Ihrer GPU-Klasse, Ihrem Lastprofil sowie Ihren Abschreibungsannahmen und zeigt Ihnen den Crossover-Punkt für Ihren konkreten Fall.

Er formuliert auch die Frage der Skalierung neu. Sie fragen nicht: „Wie kann ich die Kapazität für eine Stunde verzehnfachen?“, sondern: „Wie kann ich die Kapazität im Gleichschritt mit der stetig steigenden Nachfrage ausbauen?“ Das ist ein wesentlich einfacheres technisches Problem, und genau darin ist eine eigene Infrastruktur stark.

Skalierung nach oben: Einmal vorbereiten, mit einem Befehl beitreten

In Xinity wird die Control Plane – also das Gateway, das Dashboard, die Datenbank und der Cache – nur einmal bereitgestellt. Die Rechenkapazität ist eine separate, unabhängige Schicht. Ein neuer GPU-Server benötigt zuerst seinen Treiber-Stack und eine Inference-Engine, vLLM und/oder Ollama, je nachdem, welche Modelle Sie bereitstellen möchten. Dies geschieht in der Regel im Zuge der Bereitstellung des Servers. Sobald die Maschine vorbereitet ist, reicht ein einziger Befehl, um sie dem Pool hinzuzufügen:

xinity up daemon

xinity up daemon

xinity up daemon

Der Daemon verbindet sich mit der gemeinsam genutzten PostgreSQL-Instanz, registriert sich selbst, erkennt seine Beschleuniger und beginnt mit dem Empfang von Modell-Deployments. Die Erkennung umfasst NVIDIA über nvidia-smi, AMD über sysfs mit einem rocm-smi-Fallback und Intel über xpu-smi. Unified-Memory-Systeme wie DGX Spark werden erkannt, wenn GPUs null VRAM melden, wobei 90 Prozent des System-RAMs als nutzbare Kapazität behandelt werden, und reine CPU-Inference funktioniert, wenn überhaupt keine GPU vorhanden ist. Der Workflow ist identisch, unabhängig davon, ob Ihre Control Plane auf Bare Metal, Docker oder NixOS läuft.

Es gibt zwei Dinge, die wir hier lieber klar ansprechen, anstatt Sie sie selbst herausfinden zu lassen.

Die Engine ist Apache 2.0 und läuft ohne das Dashboard. Die Knotenauswahl ist eine Dashboard-Funktion, weshalb die Multi-Node-Orchestrierung eine kostenpflichtige Dashboard-Lizenzstufe erfordert. Die kostenlose Version deckt eine Organisation und einen Inference-Knoten ab, was ausreicht, um die Plattform zu testen oder eine Single-Node-Produktionsumgebung zu betreiben.

Und der einzelne Befehl ist nur der Registrierungsschritt, nicht die ganze Geschichte. Die Integration eines Servers in den Stack bedeutet die Installation unserer Software zusammen mit einer Inference-Engine, vLLM und/oder Ollama, mit einem geringen Konfigurationsaufwand, normalerweise bevor der Daemon überhaupt gestartet wird. Den Server zu bestellen, einzubauen, zu verkabeln und die Stromversorgung sowie Kühlung zu überprüfen, ist nach wie vor Arbeit mit entsprechender Vorlaufzeit. Es bedeutet jedoch, dass die Kapazitätsplanung zu einer Beschaffungsplanung und nicht zu einem technischen Projekt wird. Die Compute-Seite fragt jeden GPU-Knoten alle zwölf Sekunden ab, und Prometheus erfasst neue Knoten automatisch über einen Service-Discovery-Endpunkt. Die Trendlinie, die Ihnen sagt, wann Sie bestellen müssen, liegt also bereits vor Ihnen. Wenn die Auslastung sich Ihrer Obergrenze nähert, bestellen Sie einen Server, bereiten ihn vor und führen einen Befehl aus. Es ist keine Umstrukturierung der Architektur, keine Migration und keine Änderung an den Anwendungen erforderlich, da das Gateway den Datenverkehr über alle vorhandenen Knoten leitet.

Intelligent skalieren: Platzierung ist eine Richtlinie, kein Ratespiel

Eine Flotte von GPU-Servern ist nur so gut wie die Logik, die entscheidet, wo die Modelle ausgeführt werden. Der Deployment-Synchronisationsdienst unterstützt vier Strategien zur Knotenauswahl, und die Auswahl einer Strategie ist eine einzeilige Konfiguration:

Balanced (ausgewogen), die Standardeinstellung, platziert jedes Modell auf dem Knoten mit dem am meisten absolut freien VRAM. Dadurch wird die Last natürlich verteilt und Sie erhalten als Nebeneffekt eine hohe Verfügbarkeit.

Bin-pack bewirkt das Gegenteil: Es konsolidiert die Workloads so eng wie möglich, sodass einige Knoten im Leerlauf bleiben und heruntergefahren werden können. Dies ist die richtige Strategie für Teams, die Server über Nacht ausschalten oder Ersatzknoten für Wartungsarbeiten bereithalten möchten.

Proportional zielt auf die niedrigste prozentuale Auslastung ab. Das ist wichtig, wenn Ihre Flotte heterogen ist – also ältere und neuere GPUs gemischt werden – und der absolut freie Speicher den Scheduler in die Irre führen würde.

First-fit wählt den ersten Knoten aus, der den Anforderungen des Modells entspricht. Deterministisch und unspektakulär – genau das, was manche Compliance-Umgebungen verlangen: Derselbe Input führt immer zur selben Platzierung.

Keine dieser Strategien ist für sich genommen neu. Sie gehören zum Standardrepertoire von Schedulern. Der Punkt ist, dass die Platzierung auf einer eigenen Infrastruktur eine von Ihnen festgelegte Richtlinie ist und keine undurchsichtige Entscheidung, die ein Cloud-Scheduler in Ihrem Namen trifft.

Skalieren unter Last: Wo das Gateway seine Stärken ausspielt

Mehr Server helfen nur dann, wenn der Datenverkehr sie auch intelligent erreicht. Das Gateway bietet drei Load-Balancing-Strategien: Least-Connections (Standardeinstellung), die den Knoten mit den wenigsten aktiven Anfragen auswählt (nachverfolgt in Redis) und auf Zufallsauswahl zurückgreift, falls Redis nicht verfügbar ist; Round-Robin, das einen atomaren Redis-Zähler pro Modell verwendet; und Uniform Random.

Darüber hinaus implementieren Least-Connections und Random eine Prefix-Cache-Affinität. Konversations-Präfixe werden gehasht und Knoten mit einer Gültigkeitsdauer (TTL) von fünf Minuten zugewiesen, sodass wiederholte Konversationen an den Knoten zurückgeleitet werden, der bereits den relevanten KV-Cache enthält. Bei Least-Connections ist diese Affinität bewusst konditional: Sie wird nur dann berücksichtigt, wenn der vorgeschlagene Knoten maximal zwei Verbindungen mehr aufweist als der am wenigsten ausgelastete Knoten. Die Cache-Lokalität gewinnt also niemals auf Kosten einer Überlastung eines Knotens.