Bauen Sie Ihr eigenes KI-Rechenzentrum, Teil 1

Bei der Formulierung „das eigene Rechenzentrum aufbauen“ denken die meisten Menschen an Frankfurt. Doppelböden, Dieselgeneratoren, ein Budget im neunstelligen Bereich und ein dreijähriger Bauplan.

Dieses Bild ist der Grund, warum die meisten Unternehmen gar nicht erst in Betracht ziehen, KI auf eigener Hardware zu betreiben. Es ist allerdings auch falsch.

Für KI-Inferenz ist ein Rechenzentrum kein Gebäude. Es ist eine Kontrolleinheit: Hardware, die Ihnen gehört, in einem Raum, den Sie kontrollieren, und auf der Modelle laufen, die Sie ausgewählt haben. Das kann ein einzelnes, kompaktes Gerät auf einem Regal sein. Es kann ein einzelnes Rack in dem Serverraum sein, den Sie bereits haben. Nur die allerwenigsten Unternehmen benötigen jemals mehr.

Und so setzen Sie es tatsächlich um.

Schritt 1: Dimensionieren Sie die Arbeitslast, nicht die Ambition

Beginnen Sie nicht mit der Hardware. Beginnen Sie mit einer einzigen Frage: Was wird dieses System an einem ganz normalen Dienstag tun?

Konkrete Zahlen, die Sie erfassen sollten:

Wie viele Personen werden es nutzen und wie viele davon gleichzeitig? Ein Unternehmen mit 200 Mitarbeitern hat selten mehr als 15 bis 20 gleichzeitige KI-Nutzer. Welche Aufgaben? Dokumentenzusammenfassung, interner Chat, RAG über Ihre Dateifreigaben, Programmierunterstützung. Welche Modellgröße deckt diese Aufgaben ab? Für die meisten internen Unternehmensaufgaben reichen Modelle im Bereich von 8 bis 70 Milliarden Parametern völlig aus. Sie brauchen kein Spitzenmodell, um Verträge zusammenzufassen.

Einer unserer Kunden, ein Medienunternehmen, verarbeitet rund 14.000 API-Aufrufe pro Tag für 120 Benutzer. Das ist eine echte produktive Arbeitslast, und sie erfordert keine ganze Halle voller GPUs.

Schritt 2: Wählen Sie Ihre Hardware-Stufe

Es gibt drei realistische Einstiegspunkte.

Ein einzelnes Inferenz-Gerät. Geräte wie das ASUS Ascent GX10 sind kompakte Systeme im Desktop-Format, die genau dafür gebaut wurden. Sie betreiben anspruchsvolle Modelle, lassen sich an eine ganz normale Steckdose anschließen und stehen in einem verschlossenen Büro. Das ist der richtige Ausgangspunkt für Pilotprojekte und für Unternehmen mit weniger als ein paar hundert Mitarbeitern. Investition: im niedrigen fünfstelligen Bereich.

Eine GPU-Workstation oder ein einzelner Server. Eine oder zwei Rechenzentrums-GPUs in einem Tower oder 2U-Gehäuse. Mehr Speicher, mehr gleichzeitige Benutzer, passt immer noch in einen bestehenden Serverraum. Investition: im mittleren fünfstelligen Bereich.

Ein Rack. Mehrere GPU-Nodes, redundante Stromversorgung, ordentliche Netzwerkanbindung. Dies ist für Organisationen gedacht, die Tausende von Benutzern bedienen oder schwere Batch-Arbeitslasten haben. Die meisten Unternehmen, die dies lesen, werden das nie benötigen, und das ist auch völlig in Ordnung. Man kann hineinwachsen. Die Software ändert sich dabei nicht.

Der häufigste Fehler besteht darin, Kapazitäten der Stufe drei für Arbeitslasten der Stufe eins zu kaufen. Kaufen Sie für die Arbeitslast an einem Dienstag mit rund 30 Prozent Puffer. Späteres Skalieren bedeutet, einen Node hinzuzufügen, und nicht, wieder von vorne anzufangen: Das Gateway verteilt die Anfragen per Load-Balancing auf jeden erkannten Node, sodass eine zweite Maschine dem Pool beitritt und Datenverkehr übernimmt, ohne dass Änderungen an Ihren Anwendungen erforderlich sind. Mehr dazu in Schritt 5.

Schritt 3: Lösen Sie Stromversorgung, Kühlung und Platzierung pragmatisch

Hier klingt „eigenes Rechenzentrum“ einschüchternd, ist es aber meistens gar nicht.

Ein einzelnes Inferenz-Gerät verbraucht weniger Strom als eine Kaffeemaschine. Ein GPU-Server verbraucht 1 bis 3 kW, was ein Standard-Bürostromkreis und ein normal klimatisierter Raum problemlos bewältigen. Erst bei einer Rack-Größe müssen Sie mit der Gebäudeverwaltung über dedizierte Stromkreise und Kühlung sprechen.

Was Sie allerdings vom ersten Tag an benötigen: einen abschließbaren Raum, eine USV (unterbrechungsfreie Stromversorgung), damit ein Stromaussetzer keine Daten beschädigt, und eine klare Regelung, wer physischen Zugang hat. Physische Zugangskontrolle ist keine Bürokratie. Sie ist das Fundament für jeden Compliance-Nachweis, den Sie später erbringen müssen.

Schritt 4: Halten Sie das Netzwerk einfach und unspektakulär

Das stärkste Sicherheitsmerkmal von On-Premise-KI ist das, das Sie völlig umsonst bekommen: Der Datenverkehr verlässt niemals das Haus.

Platzieren Sie das Inferenzsystem in einem eigenen VLAN. Geben Sie einen einzigen Endpunkt für Ihr internes Netzwerk frei. Keine eingehenden Verbindungen aus dem Internet und im Idealfall auch keine ausgehenden. Modellgewichte werden einmalig über einen kontrollierten Update-Prozess eingespielt, nicht über eine Live-Verbindung zur Cloud eines Drittanbieters.

Wenn Ihre Firewall-Regeln für das KI-System auf einen einzigen Bildschirm passen, haben Sie alles richtig gemacht.

Schritt 5: Die Software-Ebene ist das eigentliche Produkt

Die Hardware ist der einfache Teil. Was eine GPU in einem Raum in eine Infrastruktur verwandelt, die Ihr Unternehmen auch nutzen kann, ist die Software darüber: Modellbereitstellung, Benutzerverwaltung, eine OpenAI-kompatible API, damit sich bestehende Tools ohne Code-Anpassungen verbinden lassen, Monitoring und Audit-Logs.

Das ist die Ebene, die wir entwickeln. Xinity läuft auf Ihrer Hardware, stellt offene Modelle über einen OpenAI-kompatiblen Endpunkt bereit und liefert Ihnen die operative Ebene drumherum. Der Kern ist Open Source unter Apache 2.0, sodass Sie jede Behauptung in diesem Beitrag durch Lesen des Codes überprüfen können.

Es ist auch die Ebene, die On-Premises skalierbar macht. Das Gateway von Xinity verteilt jede Anfrage per Load-Balancing auf Ihre Inferenz-Nodes, wählt das am wenigsten ausgelastete Gerät aus, versucht vorübergehende Fehler erneut, bevor der Benutzer überhaupt etwas davon merkt, und leitet wiederkehrende Konversationen an den Node zurück, der den Kontext bereits im Cache hat. Ob ein Gerät oder zehn – Ihre Anwendungen kommunizieren mit einem einzigen Endpunkt und das Gateway übernimmt die Verteilung. Unter dauerhafter Last ist dies wichtiger als die reine Anzahl der GPUs: Durch eine begrenzte Zulassung von Anfragen bleibt jeder Node in seinem effizienten Betriebsbereich, anstatt dass Lastspitzen das System zum Absturz bringen.

Die OpenAI-Kompatibilität ist wichtiger, als es klingt. Sie bedeutet, dass die Tools, die Ihre Teams bereits nutzen – von Office-Suites bis hin zu internen Apps –, durch einfaches Ändern einer Basis-URL auf Ihre eigene Hardware verweisen können. Die Migration ist eine reine Konfigurationsänderung, kein Riesenprojekt.

Schritt 6: Erledigen Sie die Compliance-Arbeit, solange es noch günstig ist

On-Premise macht Sie nicht automatisch compliant. Aber es macht Compliance nachweisbar.

Unter der DSGVO, dem EU AI Act und, sofern zutreffend, NIS2 und DORA sind die Fragen immer dieselben: Wo liegen die Daten, wer kann darauf zugreifen, was ist wann passiert. Wenn die Antwort lautet „in diesem Raum, diese Personen, hier sind die Protokolle“, fallen Audits kurz aus. Wenn die Antwort die Unterauftragsverarbeiter eines ausländischen Cloud-Anbieters einbezieht, werden Audits lang und Rechtsgutachten teuer.

DORA verdient für alle im Finanzdienstleistungssektor eine eigene Erwähnung. Es behandelt die Abhängigkeit von kritischen IKT-Drittanbietern als ein Risiko, das Sie registrieren, bewerten und beenden können müssen. Ein Inferenz-Stack auf eigener Hardware bedeutet einen Drittanbieter weniger im Register, ein Konzentrationsrisiko weniger, das Sie erklären müssen, und eine Exit-Strategie, die ganz einfach wahr ist, weil es nichts gibt, woraus man austreten müsste.

Dokumentieren Sie vom ersten Tag an drei Dinge: die physischen und netzwerkbasierten Zugriffsregeln, das Modell und den Update-Prozess sowie die Protokollierung. Das ist bereits der Großteil Ihrer Audit-Nachweise, der ganz nebenbei beim ordnungsgemäßen Betrieb des Systems abfällt. Architektur als Nachweis, nicht Papierkram als Versprechen.

Schritt 7: Rechnen Sie über 36 Monate, nicht über eine einzige Rechnung

Die Preisgestaltung für Cloud-KI basiert auf einer stillschweigenden Annahme: dass Sie klein bleiben. Die Preisgestaltung pro Token ist bei geringem Volumen günstig und bei produktivem Volumen extrem teuer.

Eigene Hardware kehrt dies um. Die Kosten fallen zu Beginn an und bleiben danach flach. Je mehr Sie sie nutzen, desto günstiger wird jede einzelne Anfrage. Einer unserer Kunden konnte seine Kosten pro Anfrage von 2,00 € auf 0,06 € senken, nachdem er die Inferenz ins eigene Haus verlagert hatte. Das ist eine Reduzierung um 97 Prozent, und sie resultierte nicht aus einem Rabatt. Sie resultierte aus der Auslastung.

Der Break-Even-Point hängt von Ihrer Arbeitslast ab, liegt aber für jedes Unternehmen mit regelmäßiger täglicher Nutzung in der Regel innerhalb der ersten ein bis zwei Jahre. Alles danach ist Marge, die Sie behalten, statt Miete, die Sie zahlen.

Um den Kompromiss klar zu benennen: Wenn Ihre Nutzung unregelmäßig oder experimentell ist, ist die Cloud das richtige Werkzeug. Kaufen Sie Hardware erst dann, wenn die Arbeitslast real ist. Nicht vorher.

Beginnen Sie mit einem Gerät, nicht mit einem Gesamtkonzept

Sie brauchen keinen Bauplan. Sie brauchen ein einziges Gerät, einen Pilot-Anwendungsfall und 30 Tage echte Nutzungsdaten.

Genau so funktioniert unser Pilotprojekt: ein ASUS Ascent GX10 mit der vollständigen Xinity-Software in Ihrem Gebäude, 30 Tage lang kostenlos, wobei Ihre Daten das Gebäude nie verlassen. Sie lassen Ihre tatsächliche Arbeitslast laufen und sehen selbst, ob die Rechnung für Ihr Unternehmen aufgeht.

Bewerben Sie sich unter xinity.ai/pilot.

Als Nächstes in dieser Serie: Teil 2, in dem Jonas den ersten Node vom nackten Blech bis zur Bereitstellung seines ersten Modells führt, inklusive Terminal-Session und allem, was dazugehört.