KI selbst hosten: Was es braucht und wann es sich lohnt

Was heisst "KI selbst hosten"?

KI selbst hosten bedeutet, das Modell auf einer Infrastruktur zu betreiben, die Sie kontrollieren, statt Ihre Prompts an eine fremde API wie jene von OpenAI oder Anthropic zu senden. Selbst hostbar sind sogenannte Open-Weight-Modelle: Ihre trainierten Parameter stehen zum Download bereit (Llama, Mistral, Qwen, Gemma, DeepSeek und das Schweizer Apertus). Sie laden die Gewichte herunter und stellen sie selbst bereit.

Selbst hosten ist ein Spektrum, keine einzelne Entscheidung:

• Lokales Gerät: ein Laptop oder eine Workstation mit Ollama oder LM Studio - ideal für Prototyping und Einzelnutzer-Aufgaben.
• On-Premises-Server: eine GPU-Maschine im eigenen Büro oder Rechenzentrum - die Daten verlassen das Haus nie.
• Private/dedizierte Cloud: gemietete, aber isolierte GPU-Instanzen (z. B. ein dediziertes VPC) - Sie kontrollieren die Umgebung, ohne Hardware zu besitzen.

Was es an Hardware braucht

Der Flaschenhals ist der VRAM, der Videospeicher der GPU. Er muss das Modell samt Kontext aufnehmen. Grössere Modelle und längerer Kontext brauchen mehr VRAM. Quantisierung - das Komprimieren der Gewichte auf 4 oder 8 Bit - senkt den Bedarf drastisch bei nur moderatem Qualitätsverlust. Als grobe Faustregeln:

• Klein (3-8 Mrd. Parameter), 4-Bit: ~4-8 GB VRAM - läuft auf einer Consumer-GPU oder einem modernen Apple-Silicon-Mac; gut für Chat, Zusammenfassung, RAG.
• Mittel (12-34 Mrd.), 4-Bit: ~10-24 GB VRAM - eine High-End-Consumer-GPU (z. B. 24 GB) oder eine Workstation-Karte.
• Gross (70 Mrd.), 4-Bit: ~40+ GB VRAM - professionelle GPUs oder Multi-GPU; deutlich näher an Spitzenqualität.
• Frontier-Open (100 Mrd.+/MoE): mehrere Rechenzentrums-GPUs - meist nur in der Private Cloud sinnvoll.

Software und Skills

Neben der GPU gilt: Parallelität vervielfacht alles - zehn gleichzeitige Nutzer brauchen weit mehr als einer. Rechnen Sie CPU, RAM, schnellen Speicher, Strom und Kühlung ein. NVIDIA (CUDA) dominiert; Apple Silicon mit Unified Memory ist für lokale Einzelnutzung exzellent; AMD holt auf, hat aber ein kleineres Ökosystem.

Die Tools sind gereift. Für den Einstieg bündeln Ollama und LM Studio alles in ein nahezu Ein-Klick-Erlebnis. Für den Produktivbetrieb bieten vLLM und Hugging Face TGI Batching, höheren Durchsatz und eine OpenAI-kompatible API, sodass sich Ihre Anwendungen kaum ändern. llama.cpp bildet die Basis vieler Tools und läuft auch auf bescheidener Hardware effizient.

Der schwierigere Teil ist der Betrieb, nicht die Installation. Jemand muss:

• Linux, GPU-Treiber und CUDA-Versionen verwalten
• das Modell zuverlässig bereitstellen, Latenz und Verfügbarkeit überwachen und Skalierung handhaben
• Sicherheit patchen, Zugriffe kontrollieren und einen Audit-Trail führen
• Modelle bewerten und tauschen, sobald bessere erscheinen (das offene Ökosystem bewegt sich schnell)
• die eigentliche Wertschöpfungsschicht bauen: RAG, Prompts, Guardrails, Integration

Kosten: Self-Hosting vs. API

Realistisch braucht ein KMU mindestens eine fähige Engineering-Person oder einen externen Partner; den laufenden Aufwand zu unterschätzen ist der häufigste Grund, warum Self-Hosting-Projekte enttäuschen. Die Ökonomie hängt an Volumen und Auslastung. Eine API rechnet pro Token ab: keine Vorabkosten, sofort skalierbar, Sie zahlen nur die tatsächliche Nutzung. Self-Hosting verlagert die Kosten nach vorn: Sie kaufen oder mieten GPUs und zahlen Strom, Kühlung und - der grösste versteckte Posten - Engineering-Zeit, ob die GPU nun ausgelastet ist oder leerläuft.

Der Break-even spricht für Self-Hosting, wenn die Auslastung hoch und konstant ist - ein stark ausgelasteter Dauerbetrieb amortisiert die Fixkosten. Bei niedrigem oder schwankendem Volumen macht eine leerlaufende GPU die API günstiger. Modellieren Sie das ehrlich, inklusive Personalzeit, bevor Sie Hardware kaufen. Kurzvergleich:

• Anfangskosten: API keine; Self-Hosting hoch (Hardware) oder moderat (Miete)
• Grenzkosten pro Anfrage: API pro Token; Self-Hosting nahezu null im Betrieb
• Skalierung: API elastisch; Self-Hosting durch Ihre Hardware begrenzt
• Leerlaufkosten: API null; Self-Hosting Sie zahlen unabhängig von der Nutzung
• Betriebsaufwand: API minimal; Self-Hosting erheblich

Vorteile und Nachteile auf einen Blick

• Vorteil - Datensouveränität: Prompts und Dokumente verlassen Ihre Kontrolle nie; entscheidend bei sensiblen Daten.
• Vorteil - Planbare Kosten im grossen Massstab: kein Pro-Token-Konto, sobald die Hardware abbezahlt ist.
• Vorteil - Unabhängigkeit: kein Vendor-Lock-in, keine überraschenden Preis- oder Richtlinienänderungen, funktioniert offline/air-gapped.
• Vorteil - Kontrolle: exakte Modellversion wählen, anpassen und feinjustieren (Fine-Tuning), Latenz steuern.
• Nachteil - Kapital und Betrieb: Hardwareausgaben plus kontinuierliches Engineering.
• Nachteil - Qualitätslücke: Die besten offenen Modelle liegen bei harten Reasoning-Aufgaben hinter den führenden proprietären - der Abstand schrumpft jedoch.
• Nachteil - Skalierungsreibung und volle Verantwortung: Nachfragespitzen sind schwer abzufedern; Sicherheit, Verfügbarkeit und Compliance liegen ganz bei Ihnen, inklusive des ständigen Nachziehens neuer Modelle.

Wann lohnt es sich für ein KMU?

Self-Hosting ergibt am meisten Sinn, wenn mindestens einer dieser Punkte zutrifft:

Meist lohnt es sich nicht, wenn das Volumen niedrig oder unvorhersehbar ist, wenn Sie das stärkstmögliche Reasoning brauchen oder wenn Betriebskapazität fehlt - dann dient eine konforme API oder eine Private-Cloud-Bereitstellung (z. B. eine Schweizer/EU-Region eines Anbieters oder ein isoliertes VPC) oft besser. Viele KMU landen bei einem hybriden Ansatz: kleine, hochvolumige, sensible Aufgaben selbst hosten, die schwierigsten per API lösen.

Zwei Schweizer Hinweise. Erstens macht Self-Hosting Sie nicht per se konform - das revDSG, die EDÖB-Leitlinien und der extraterritoriale EU AI Act gelten für Ihre KI-Nutzung unabhängig davon, wo sie läuft; Self-Hosting beseitigt vor allem das Problem grenzüberschreitender Datentransfers. Zweitens gibt es mit Apertus nun ein vollständig offenes grosses Sprachmodell von ETH Zürich, EPFL und CSCS - eine beachtenswerte Option, wenn Transparenz und Schweizer Herkunft zählen.

• Sie verarbeiten sensible oder regulierte Daten (Gesundheit, Recht, Finanzen, HR), bei denen Daten im Haus die revDSG/nDSG-Konformität und das Kundenvertrauen erleichtern.
• Das Volumen ist hoch und konstant genug, um Hardware zu amortisieren.
• Sie brauchen Offline-Betrieb, garantierte Latenz oder air-gapped Umgebungen.
• Sie verfügen bereits über solide IT-/Engineering-Fähigkeiten oder einen verlässlichen Partner.

Ein pragmatischer Fahrplan

• Mit einem lokalen Pilot starten: Ollama mit einem kleinen offenen Modell auf einer Workstation betreiben und eine Woche an echten Aufgaben testen.
• Ehrlich messen: Qualität für Ihren Use Case, erwartetes Monatsvolumen und nötige Latenz.
• Gesamtkosten vergleichen: Hardware plus Personalzeit gegen eine gleichwertige API-Rechnung.
• Die Stufe wählen: lokal, on-prem, Private Cloud - oder hybrid.
• In die Wertschöpfungsschicht investieren (RAG, Integration, Guardrails) - sie zählt mehr als das reine Modell.