Ein praktischer Leitfaden für Engineering-Teams, die bereit sind, die Kontrolle über ihre KI-Infrastruktur zu übernehmen.

Sie wissen bereits, warum. So geht's.

Wenn du das hier liest, hast du es wahrscheinlich schon gespürt: unvorhersehbare API-Rechnungen, Daten, die mit jedem Aufruf deine Infrastruktur verlassen, und das wachsende Gefühl, dass dein KI-Stack nach den Vorgaben von jemand anderem aufgebaut ist.

Dieser Leitfaden führt dich durch den Prozess — von der Überprüfung deiner aktuellen Cloud-KI-Nutzung bis hin zu deinem ersten Inferenzaufruf vor Ort mit Xinity.

Schritt 1: Prüfe deine aktuelle KI-Nutzung

Bevor du an irgendeiner Infrastruktur herumänderst, verstehe, was du tatsächlich verwendest.

Jeden API-Aufruf kartieren. Geh deine Codebasis durch und identifiziere jede Stelle, an der du OpenAI, Anthropic, Azure OpenAI oder einen anderen Cloud-KI-Anbieter aufrufst. Dokumentiere das Modell, den Endpunkt und das ungefähre Volumen.

Nach Kritikalität kategorisieren. Dein kundenorientierter Chatbot mit 10.000 Anfragen pro Tag ist eine andere Migration als dein interner Dokumentenzusammenfasser, der einmal pro Woche läuft. Ordne sie ein: produktionskritisch, interne Tools, experimentell.

Deine tatsächlichen Ausgaben berechnen. Zieh deine Rechnungen der letzten 6 Monate. Stell den Trend dar. Du kannst unseren ROI-Rechner verwenden, um zu sehen, wie diese Zahlen auf deiner eigenen Hardware aussehen.

Datenempfindlichkeit identifizieren. Welche Workloads verarbeiten Kundendaten? Mitarbeiterdaten? Alles unter Artikel 9 der DSGVO — Gesundheits-, biometrische oder politische Daten — ist ein unmittelbarer Kandidat für die Migration.

Schritt 2: Wähle deine Modell-Entsprechungen

Cloud-Anbieter sperren dich in ihre proprietären Modelle ein. Vor Ort hast du die Wahl. Hier ist, was wir einsetzen und empfehlen:

Ministral 3B Instruct — Mistrals kompaktes Modell mit 3 Milliarden Parametern, optimiert für den Edge-Einsatz. Bewältigt Chat, Instruktionsbefolgung, Klassifizierung, Extraktion und Routing-Aufgaben mit hoher Geschwindigkeit und minimalen Ressourcen. Passt in 8 GB VRAM. Ideal für Workloads mit hohem Durchsatz, für die du derzeit GPT-3.5 oder GPT-4o-mini verwenden würdest — die Aufgaben, die den Großteil der meisten API-Rechnungen ausmachen.

Qwen 3.5 35B — Alibabas Modell mit 35 Milliarden Parametern für komplexe Schlussfolgerungen, Analysen und Generierungsaufgaben. Das ist das Äquivalent zu GPT-4 — mehrstufiges Reasoning, nuanciertes Sprachverständnis, Long-Form-Content-Erstellung. Braucht mehr VRAM, liefert aber die Qualität, die deine Produktions-Workloads verlangen.

Qwen 3.6 35B FP8 — Die neueste Qwen-Generation mit 35 Milliarden Parametern in FP8-Quantisierung. Gleiche Leistungsklasse wie die 3.5, mit verbesserter Performance und Effizienz durch das FP8-Format — also schnellere Inferenz bei gleichem Qualitätsniveau.

Die entscheidende Erkenntnis: du brauchst nicht ein einziges Modell, das alles ersetzt. Leite schnelle, einfache Aufgaben an Ministral 3B weiter. Leite komplexes Reasoning an Qwen 35B weiter. Xinity übernimmt dieses Routing nativ über die OpenAI-kompatible API — deine Anwendung gibt einfach den Modellnamen in der Anfrage an, genau wie heute bei OpenAI.

Schritt 3: Hol dir deine Hardware

Wir empfehlen den ASUS Ascent GX10.

Das ist ein Desktop-KI-Supercomputer, angetrieben vom NVIDIA GB10 Grace Blackwell Superchip. Was ihn für diese Migration praktisch macht:

• 128GB vereinheitlichter Speicher — Modelle mit bis zu 200 Milliarden Parametern auf deinem Schreibtisch ausführen

• Bis zu 1 Petaflop KI-Leistung — Inferenz und Fine-Tuning auf Produktionsniveau

• 150 x 150 x 51mm — passt auf einen Schreibtisch, kein Serverraum erforderlich

• 240W-Netzteil — normale Steckdose, keine spezielle Infrastruktur

• Skalierbar — verbinde zwei Einheiten über NVIDIA ConnectX-7, um auf 2 Petaflops mit 256 GB Speicher zu verdoppeln

• Ubuntu Linux vorinstalliert — bereit für KI-Workloads, inklusive PyTorch, TensorFlow und Ollama

• 10G Ethernet + ConnectX-7 SmartNIC — schneller Datentransfer für Produktions-Workloads

Kein Rack-Platz. Keine Kühlräume. KI-Compute auf Enterprise-Niveau, einfach einstecken und loslegen.

Schritt 4: Installiere Xinity

Installiere die CLI und fahre den gesamten Stack hoch:

# Xinity-CLI installieren
curl -fsSL https://get.xinity.ai/install.sh | bash

# Alles einrichten (Postgres, Inferenz-Engine, Dashboard)

# Xinity-CLI installieren
curl -fsSL https://get.xinity.ai/install.sh | bash

# Alles einrichten (Postgres, Inferenz-Engine, Dashboard)

# Xinity-CLI installieren
curl -fsSL https://get.xinity.ai/install.sh | bash

# Alles einrichten (Postgres, Inferenz-Engine, Dashboard)

Wenn du auf einen Remote-Server statt auf die lokale Maschine deployen möchtest:

xinity up all --target-host

xinity up all --target-host

xinity up all --target-host

Erstelle dein Admin-Konto im Terminal:

Prüfe, ob alles gesund läuft:

Schritt 5: Dein erstes Modell bereitstellen

Stelle ein Modell direkt über die CLI bereit. Hier ist ein Schnellstart mit Phi-3 Mini:

xinity act deployment.create '{
  "name": "Phi-3 Mini",
  "publicSpecifier": "phi-3-mini",
  "modelSpecifier": "phi3:mini",
  "enabled": true
}'

xinity act deployment.create '{
  "name": "Phi-3 Mini",
  "publicSpecifier": "phi-3-mini",
  "modelSpecifier": "phi3:mini",
  "enabled": true
}'

xinity act deployment.create '{
  "name": "Phi-3 Mini",
  "publicSpecifier": "phi-3-mini",
  "modelSpecifier": "phi3:mini",
  "enabled": true
}'

Prüfe den Bereitstellungsstatus:

xinity act deployment.list '{"withStatus": true}'

xinity act deployment.list '{"withStatus": true}'

xinity act deployment.list '{"withStatus": true}'

Sobald dort "bereit" steht, hast du einen laufenden Inferenz-Endpunkt. Du kannst Modelle auch über das Xinity-Dashboard unter localhost:3100 bereitstellen und verwalten — der Model Hub bietet dir eine visuelle Oberfläche, um all deine Modelle bereitzustellen, zu testen, zu bearbeiten und zu überwachen.

Schritt 6: Deinen ersten Aufruf machen

Rufe deine lokale OpenAI-kompatible API auf:

curl http://localhost:3000/v1/chat/completions \
  -H "Authorization: Bearer sk_..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "phi-3-mini",
    "messages": [{"role": "user", "content": "Hallo aus dem On-Premises-Bereich."}]
  }'

curl http://localhost:3000/v1/chat/completions \
  -H "Authorization: Bearer sk_..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "phi-3-mini",
    "messages": [{"role": "user", "content": "Hallo aus dem On-Premises-Bereich."}]
  }'

curl http://localhost:3000/v1/chat/completions \
  -H "Authorization: Bearer sk_..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "phi-3-mini",
    "messages": [{"role": "user", "content": "Hallo aus dem On-Premises-Bereich."}]
  }'

Gleiches Endpunktformat, gleicher Request-Body, gleiche Antwortstruktur wie bei OpenAI.

Schritt 7: Passe deinen Anwendungscode an

In deiner Anwendung sind es zwei Zeilen Änderung:

Vorher (OpenAI):

from openai import OpenAI
client = OpenAI(api_key="sk-...")

from openai import OpenAI
client = OpenAI(api_key="sk-...")

from openai import OpenAI
client = OpenAI(api_key="sk-...")

Danach (Xinity):

from openai import OpenAI
client = OpenAI(
    base_url="http://your-xinity-instance:3000/v1",
    api_key="sk_your_xinity_key"
)

from openai import OpenAI
client = OpenAI(
    base_url="http://your-xinity-instance:3000/v1",
    api_key="sk_your_xinity_key"
)

from openai import OpenAI
client = OpenAI(
    base_url="http://your-xinity-instance:3000/v1",
    api_key="sk_your_xinity_key"
)

Gleicher SDK. Gleiche Methodenaufrufe. client.chat.completions.create() funktioniert identisch. Dein Anwendungscode ändert sich nicht — nur die Konfiguration.

Schritt 8: Migriere schrittweise

Nicht alles auf einmal umstellen.

Beginne mit deinem Workload mit dem geringsten Risiko. Interne Tools, Entwicklungsumgebungen, nicht kundenfacing Features. Richte sie auf Xinity aus.

Ausgaben vergleichen. Für deine ersten paar hundert Anfragen logge beide Antworten Seite an Seite. Die meisten Teams stellen fest, dass die Qualität für ihren konkreten Anwendungsfall gleichwertig ist.

Traffic schrittweise verschieben. Verlege Workloads einzeln, beginnend mit internen und weiter bis in die Produktion.

Die Wirtschaftlichkeit

Cloud-KI-Preise setzen auf sprunghafte, unvorhersehbare Workloads — also etwa 15-20 % GPU-Auslastung. Produktions-KI-Agenten laufen mit 80-90 % Auslastung. Bei dieser Auslastung liefert dedizierte On-Premises-Hardware rund 80 % Kosteneinsparung im Vergleich zu entsprechender Cloud-Kapazität.

Wir nennen das die Utilization Inversion: der Moment, in dem deine KI-Workloads vorhersehbar genug werden, dass Besitzen besser ist als Mieten.

Rechne die Zahlen für dein Setup durch: xinity.ai/roi-calculator

Was du nach der Migration bekommst

• Keine Kosten pro Token. Feste, planbare Infrastrukturkosten.

• Kein Datenabfluss. Jede Anfrage bleibt auf deiner Hardware, in deiner Jurisdiktion.

• Kein Vendor-Lock-in. Xinity ist Open Source unter Apache 2.0.

• Volle Compliance. DSGVO, EU AI Act — durch die Architektur gelöst, nicht durch Richtlinienversprechen.

• Gleiche Entwicklererfahrung. Deine Engineers verwenden weiterhin das OpenAI-SDK.

Bereit zu starten?

Das vollständige Migrations-Whitepaper mit Hardware-Dimensionierung und Modell-Benchmarks ist unter xinity.ai/whitepaper verfügbar.

Oder spring direkt ins Machen — Xinity ist Open Source:

curl -fsSL https://get.xinity.ai/install.sh | bash

curl -fsSL https://get.xinity.ai/install.sh | bash

curl -fsSL https://get.xinity.ai/install.sh | bash

Besitze deine KI. Besitze deine Daten. Kontrolliere deine Kosten.