Die Abhängigkeit von einem einzigen API-Anbieter ist ein stilles Risiko: Die Kosten steigen mit dem Traffic, Daten verlassen das Unternehmen, und ein Anbieterwechsel bedeutet, Integrationen neu zu schreiben.
Was macht Souveränität aus#
- LLM-Serving lokal (vLLM, Ollama) — vorhersehbare Latenz und Kosten.
- Embedding-Server (BGE-M3) als Grundlage für semantische Suche.
- RAG auf Unternehmenswissen — Antworten aus Deinen Dokumenten, mit Zitaten.
- Router / Gateway, der den Eingang vereinheitlicht und die Kosten kontrolliert.
Design für Exit, nicht für Lock-in#
Grundprinzip: Das System muss den Anbieterwechsel ermöglichen — niemals umgekehrt. Der Router erlaubt es, lokale Modelle (für sensible Pfade) mit Cloud-Modellen (wo Leistung benötigt wird) zu mischen, ohne Code neu zu schreiben.
Und was ist mit DSGVO?#
Compliance wird von Anfang an mitgedacht (Compliance-by-Design): In der On-Prem-Variante verlässt die Generierungsschicht das Unternehmen nicht, und wenn der Router ausgewählte, sichere Pfade in die Cloud leitet, maskieren wir PII vor jedem Export nach außen. Sicherheit und DSGVO sind wichtiger als ein einzelnes Feature.
Du brauchst nicht sofort einen GPU-Cluster — wir wählen die Variante basierend auf realer Auslastung und Budget. Entscheidend sind vorhersehbare Kosten, nicht maximale Hardware.
Wie viel Hardware Du wirklich brauchst#
Die Hardware-Variante hängt vor allem von Modellgröße und Quantisierung ab — also davon, wie viel VRAM nötig ist, um das Modell vollständig in den Speicher der Karte zu laden. In der Praxis sieht der ungefähre Bedarf so aus:
- Ein 7B-Modell in Q4-Quantisierung — etwa 4–5 GB VRAM. Passt auf eine einzelne Consumer-Karte.
- Ein 13B-Modell — etwa 8–10 GB VRAM. Eine einzelne 24-GB-Karte reicht, mit Reserve für den Kontext.
- Ein 70B-Modell — mindestens 40–48 GB VRAM, also zwei per NVLink verbundene 24-GB-Karten oder eine professionelle Karte mit 48 GB+.
Deshalb bedeutet Souveränität nicht sofort einen Cluster. Ein realistischer Pilot startet meist mit einem kleinen Q4-Modell — zunächst auf der CPU für einen Prototyp, und erst wenn Volumen und Latenzanforderungen es rechtfertigen, wechselt er auf GPU. Die vollständige Übersicht über Karten, Durchsatz und Hardware-Kosten beschreiben wir im Leitfaden zu lokalen LLMs und der Wahl der GPU.
Wann sich Self-Hosting gegenüber einem API lohnt#
Das ist eine finanzielle Entscheidung, nicht nur eine technische. Bei stetigem, hohem Anfragevolumen amortisieren sich die einmaligen Hardware-Kosten (CAPEX), und Du zahlst danach hauptsächlich für Strom — dann ist die eigene Infrastruktur günstiger als eine Rechnung pro Token. Bei geringem oder unregelmäßigem Traffic gewinnt meist die Cloud: Du bindest kein Kapital in Hardware, die Du nicht auslastest. Die vollständige Berechnung der Wirtschaftlichkeitsschwelle — mit konkreten Spannen und einem Break-even-Szenario — findest Du im Vergleich von lokalen LLM-Kosten und API-Kosten.
Was Souveränität im Gegenzug verlangt#
Souveränität bringt nicht nur Vorteile — sie bedeutet auch betriebliche Verpflichtungen, die Du ehrlich in die Entscheidung einrechnen musst:
- Wartung und Rufbereitschaft — eigene Infrastruktur braucht Monitoring und Incident-Reaktion (On-Call), nicht nur ein einmaliges Deployment.
- Modell- und Treiber-Updates — neue Modellversionen, Serving-Bibliotheken und GPU-Treiber müssen aktualisiert und getestet werden.
- Hardware-Redundanz — ein einzelner Server ist ein einzelner Ausfallpunkt; Hochverfügbarkeit bedeutet Ersatz-Hardware oder Failover.
- Skalierung bei Spitzen — die Cloud skaliert elastisch mit dem Traffic; lokal bewältigst Du Spitzen innerhalb der Grenzen Deiner vorhandenen Hardware (hier hilft eine Hybridlösung mit Router).
- Zugang zu den neuesten Modellen — die neuesten Modelle sind im API mitunter früher verfügbar als lokal.
Deshalb wählen wir die Variante nach realer Auslastung, halten Pfade mit hohem Volumen lokal und ergänzen die Cloud dort, wo Elastizität nötig ist. Die vollständige Betriebsrechnung (Monitoring, Updates, Aufsicht) schlüsseln wir im Leitfaden zu den Wartungskosten eines AI-Agenten auf.
Self-hosted vs. Cloud-API#
| Self-hosted | API in der Cloud | |
|---|---|---|
| Kosten | Vorhersehbar (CAPEX + Strom) | Variabel, steigt mit Traffic |
| Datenschutz | Daten bleiben bei Dir | Daten verlassen das Unternehmen |
| Kontrolle | Vollständig (Modell, Version, Feinabstimmung) | Eingeschränkt auf API |
| Abhängigkeit vom Anbieter | Keine (Wechsel möglich) | Lock-in bei Preis und Funktionen |
| Einstiegshürde | Höher (Hardware, Implementierung) | Niedrig (API-Schlüssel) |
| Wartung und Skalierung | Auf Deiner Seite (On-Call, Updates, Redundanz) | Auf Anbieterseite (elastische Skalierung) |
Verwandte Wege#
Für die tiefere Umsetzung lies den Leitfaden zu self-hosted LLM und DSGVO, den Vergleich von lokalen LLM-Kosten und API-Kosten sowie die Produktseite zu BGE-M3 für semantische Suche. Deine eigene Wirtschaftlichkeitsschwelle berechnest Du im Rechner für Inferenzkosten.
FAQ#
Was ist souveräne AI-Infrastruktur?#
Das sind Modelle auf Deiner Hardware, mit Eigentum an Code und Daten — Self-Hosting statt Abhängigkeit von einem Anbieter. Wir gestalten es so, dass Du den Anbieter wechseln kannst, niemals umgekehrt.
Brauche ich eigene Server oder GPU?#
Nicht zwingend. Wir wählen die Variante basierend auf realer Auslastung und Budget — von kleinen Modellen bis zum Cluster. Entscheidend sind vorhersehbare Kosten, nicht maximale Hardware.
Wie wirkt sich souveräne Infrastruktur auf die Kosten aus?#
Vorhersehbare Kosten statt Überraschungsrechnung: Statt pro Token in der Cloud zu zahlen, kontrollierst Du Leistung und Kosten auf eigener Hardware.