Migration von API zu eigenem KI-Modell: wann und wie

Ein SaaS-Unternehmen mit 40.000 aktiven Nutzern erhält eine Rechnung für das LLM-API, die 30.000 PLN pro Monat übersteigt. Die Rechtsabteilung weist darauf hin, dass die von einem externen API verarbeiteten Daten einem Audit nach RODO unterzogen werden müssen. Der CTO fragt: Wäre es nicht günstiger, ein eigenes Modell zu betreiben? Diese Frage hören wir 2026 jede Woche. Die Antwort ist nicht einfach – aber berechenbar.

Im Folgenden beschreibe ich, wie eine solche Migration aus Sicht der Entscheidung, Architektur und Risiken aussieht. Ohne Versprechungen wie „Nach der Migration sparen Sie X%“. Mit konkreten Schwellenwerten, typischen Fallstricken und dem, was tatsächlich neu gestaltet werden muss.

Die Migration zu einem eigenen Modell ist ein Infrastrukturprojekt, keine Optimierung. Vor der Entscheidung sollten vier Fragen gestellt werden:

Sind die Token-Kosten der dominierende Ausgabenposten? Externe APIs berechnen jede Anfrage. Bei hohem Volumen sind das Zehntausende Złoty pro Monat. Wenn generative KI jedoch nur ein marginaler Bestandteil des Produkts ist (z. B. einige hundert Anfragen pro Tag), übersteigen die Betriebskosten eines eigenen Modells leicht die Einsparungen bei den Token-Kosten.

Dürfen die Daten die Infrastruktur nicht verlassen? Gesundheits-, Finanz-, Rechts- und Personaldaten – all diese Kategorien, die nach RODO oder Berufsgeheimnis besonderen Schutz erfordern, sprechen für Self-Hosting, selbst bei geringem Volumen. Hier ist die Entscheidung rechtlich, nicht nur wirtschaftlich.

Reicht ein allgemeines Modell aus, oder ist eine Spezialisierung erforderlich? Ein eigenes Modell, das direkt aus einem Repository (z. B. Mistral, Llama, Qwen) deployed wird, ist immer noch ein allgemeines Modell. Wenn die Aufgabe domänenspezifisches Wissen erfordert, reicht die Migration allein nicht aus – es wird Fine-Tuning oder eine RAG-Architektur auf Ihrer Wissensdatenbank benötigt.

Verfügen Sie über die Kompetenzen, um die Infrastruktur zu betreiben? Ein eigenes Modell bedeutet Server, Monitoring, Sicherheitsupdates und Reaktion auf Ausfälle. Ein API-first-Ansatz entlastet Ihr Team von diesen Kosten. Wenn Sie keine Erfahrung mit GPU-Infrastruktur haben, ist die Migration ohne externe Unterstützung ein operatives Risiko.

Ein eigenes Modell bedeutet nicht, ein Modell von Grund auf neu zu erstellen. Das Training eines LLM von Grund auf kostet Hunderttausende bis Millionen Dollar an Rechenleistung – außerhalb der Reichweite der meisten Unternehmen. „Eigenes Modell“ bedeutet in der Praxis einen von drei Ansätzen:

Deploy open-weight aus Hugging Face / Repository. Sie laden die Modellgewichte (Mistral, Llama 3, Qwen 2.5, Gemma) herunter und führen sie auf Ihrer eigenen GPU über Ollama, vLLM oder llama.cpp aus. Das Modell ist öffentlich verfügbar, aber die Inferenz findet auf Ihrer Infrastruktur statt. Keine Daten verlassen das Unternehmen.

Fine-Tuning auf Ihren Daten. Sie nehmen ein open-weight-Modell und passen es an Ihren Datensatz an (QLoRA, LoRA). Ergebnis: ein Modell, das Ihren Stil, Ihre Terminologie und Ihr Antwortformat kennt. Wann dies sinnvoll ist und wann stattdessen RAG ausreicht, beschreiben wir im Artikel wann Fine-Tuning sinnvoll ist.

Destillation von einem großen zu einem kleinen Modell. Sie generieren synthetische Trainingsdaten mit einem großen Modell (API) und trainieren ein kleineres Modell auf diesen Daten. Ergebnis: ein kompaktes, spezialisiertes Modell, das kostengünstig zu betreiben ist. Erfordert sorgfältiges Design des Datensatzes und Qualitätsvalidierung.

In jedem Fall ist es kein „URL-Austausch“, sondern eine Architekturänderung. Router, Guardrails, Prompt-Formate, Fehlerbehandlung, Monitoring – alles muss an die neue Modellcharakteristik angepasst werden.

Externe APIs und lokale Modelle sind nicht derselbe Interface mit einer anderen Adresse. Die Unterschiede sind fundamental:

Determinismus und Versionierung. Ein API kann das Modellverhalten ohne Vorankündigung ändern (Backend-Update). Ein lokales Modell hat festgelegte Gewichte – das Verhalten ist stabil, bis Sie selbst die Version ändern. Für Produktionssysteme ist das ein entscheidender Unterschied: Kunden bemerken es, wenn der Assistent plötzlich anders antwortet.

Latenz und Throughput. Externe APIs haben Netzwerklatenz und teilen die Bandbreite zwischen Kunden. Ein lokales Modell hat eine Inferenz-Latenz, die von der GPU abhängt, und ist Ihrem Traffic dediziert. Bei geringem Traffic ist das API schneller. Bei hohem, konzentriertem Traffic gewinnt das eigene Modell in Sachen Latenz.

Context Window und Speicher. Große Modelle in APIs bieten Kontextfenster bis zu 128K–200K Token. Open-weight-Modelle haben unterschiedliche Limits (meist 8K–128K, abhängig von der Version). Wenn Ihr System auf sehr lange Kontexte angewiesen ist, überprüfen Sie die Limits des jeweiligen Modells vor der Migration.

Antwortformat und Structured Output. Externe APIs bieten oft native Schema-Erzwingung für JSON. Bei lokalen Modellen müssen Sie dies auf der Anwendungsseite implementieren: Parser mit Reparatur, Schema-Validierung, erneute Versuche bei Strukturfehlern.

Kosten für Token vs. Rechenleistung. APIs berechnen pro Token. Ein eigenes Modell berechnet Strom und Hardware-Abschreibung. Letzteres hat feste Kosten unabhängig von der Anzahl der Anfragen – bei geringem Traffic ist es teurer, bei hohem günstiger.

Die Erfahrung aus Dutzenden Migrationen zeigt, dass immer dieselben Elemente überarbeitet werden müssen.

Modell-Router. Externe APIs nutzen in der Regel ein Modell. Nach der Migration zu Self-Hosting haben Sie eine Flotte von Modellen unterschiedlicher Größe und Kosten. Ein LLM-Router klassifiziert Anfragen nach Komplexität und leitet einfache Fragen an ein kleines Modell (schnell und günstig) und komplexe an ein großes weiter. Ohne Router verlieren Sie die Wirtschaftlichkeit Ihrer eigenen Infrastruktur.

Guardrails und Filterung. Externe APIs haben integrierte Inhaltsmoderation. Lokale Modelle nicht. Guardrails müssen Sie selbst implementieren: Eingabefilterung (Injection, Prompt-Angriffe, sensible Daten), Ausgabefilterung (PII in Antworten, thematischer Rahmen), Eskalationsfallen für Human-Handoff. Ohne diese Schicht ist ein lokales Modell weniger sicher als ein API.

PII und Maskierung. Paradox: Ein eigenes Modell verarbeitet Daten lokal, sodass das Risiko eines Datentransfers nach außen gleich null ist. Das entbindet jedoch nicht von der Pflicht, personenbezogene Daten vor dem Modell zu maskieren – gemäß dem Grundsatz der Datenminimierung aus der RODO. Daten sollten mit maskierten Identifikatoren an das Modell gesendet und erst in der Antwort demaskiert werden.

Observability und Monitoring. Externe APIs loggen Anfragen und Metriken auf ihrer Seite – oft für Sie unsichtbar. Ein eigenes Modell erfordert einen eigenen Observability-Stack: Anfragelogs (ohne PII), Leistungsmetriken, Alerts bei Qualitätsdrift. Mehr dazu, was und wie gemessen werden sollte, im Artikel über Monitoring der KI-Agenten-Qualität.

Fallback und Degradation. APIs haben Redundanz auf Anbieterseite. Eigene Infrastruktur erfordert die Planung eines Fallbacks: Was passiert, wenn die GPU nicht verfügbar ist? Der Service sollte gracefully degradieren – auf ein kleineres Modell umschalten oder dem Nutzer die Nichtverfügbarkeit kommunizieren, statt zu schweigen.

Praktischer Zeitplan für ein Unternehmen, das von einem externen API zu Self-Hosting migriert:

Schritt 1: Audit der aktuellen Nutzung (Woche 1). Sammeln Sie Logs vom API: Verteilung der Prompt-Längen, Verteilung der Antwortlängen, Aufgabentypen (Klassifikation, Generierung, Extraktion, Zusammenfassung), Fehlerverteilung. Dies dient als Input für die Modellauswahl. Nutzen Sie den ROI-Rechner für eine erste Wirtschaftlichkeitsanalyse.

Schritt 2: Auswahl und Benchmark des Modells (Woche 1–2). Wählen Sie 2–3 open-weight-Kandidatenmodelle mit einer Größe, die zu Ihren Aufgaben passt. Führen Sie einen Benchmark mit 50–100 realen Produktionsanfragen durch. Messen Sie: Antwortqualität, Latenz, Prozentsatz korrekter Structured Outputs. Konfigurieren Sie nicht basierend auf allgemeinen Benchmarks – messen Sie mit Ihren eigenen Daten.

Schritt 3: Vorbereitung der Infrastruktur (Woche 2–3). Server mit GPU, Konfiguration von Ollama oder vLLM, Netzwerk, Backup. Die detaillierte Hardwareauswahl beschreiben wir im Artikel über lokale LLM und GPU-Hardware. In dieser Phase implementieren Sie auch Router, Guardrails und die Observability-Schicht.

Schritt 4: Paralleler Pilot – Shadow Mode (Woche 3–4). Leiten Sie den Traffic für mindestens eine Woche parallel zum API und zu Ihrem eigenen Modell. Vergleichen Sie die Antworten. Unterbrechen Sie das API nicht – es dient als Fallback. Der Shadow Mode deckt Qualitätsunterschiede auf, die der Benchmark übersieht.

Schritt 5: Schrittweise Traffic-Umstellung (Woche 4–6). 10% des Traffics auf das eigene Modell, Monitoring, 25%, Monitoring, 50%, Monitoring, 100%. Halten Sie an jedem Punkt für 48 Stunden inne und überprüfen Sie die Metriken: Error Rate, Latenz, Qualitätsbewertungen (falls Sie ein Feedback-Loop haben).

Schritt 6: API-Abschaltung (nach Woche 6+). Erst wenn Shadow Mode und Ramp-up die Stabilität bestätigen. Behalten Sie den API-Zugang als Notfall-Fallback für weitere 30 Tage.

Die Migration zu Self-Hosting hat versteckte Kosten, die nicht im Vergleich „Token-Kosten vs. Server-Kosten“ sichtbar sind:

Personalkosten. GPU-Infrastruktur erfordert Wartung. Updates, Monitoring, Incidents, Modellrotation nach Versionsdeprecation. In der Regel 0,2–0,5 Vollzeitäquivalente eines Ingenieurs. Bei kleinen Teams ist das der dominierende Kostenfaktor.

Startkosten. Hardware (GPU-Server) ist eine einmalige Ausgabe oder Leasing. Die Abschreibung über 3–4 Jahre bei Kosten von 15.000–60.000 PLN (abhängig von der GPU) muss in die Rechnung einfließen. Berechnen Sie dies vor der Entscheidung mit dem Inference-Rechner.

Qualitätsdrift bei Modellaktualisierungen. Der Wechsel auf eine neue Modellversion kann das Systemverhalten ändern. Jedes Update erfordert einen neuen Benchmark und Regressionstests. Externe APIs verbergen dieses Problem – manchmal lösen sie es scheinbar, manchmal übertragen sie es leise auf Ihr System.

Risiko des AI Act. KI-Systeme, die als hochriskant eingestuft werden, erfordern technische Dokumentation, Systemregistrierung und Einhaltung von Transparenzanforderungen. Self-Hosting entbindet nicht von diesen Pflichten – es erhöht sogar den Umfang Ihrer Verantwortung als Deployer. Bevor Sie in hochriskanten Systemen auf ein eigenes Modell umsteigen, konsultieren Sie die DPIA und technische Dokumentation mit einem Anwalt.

Die Migration von API zu eigenem Modell ist eine Entscheidung, die Sie mit Zahlen, nicht mit Intuition begründen. Der Einstiegspunkt wird im Artikel wo-mit-ki-einführung-beginnen beschrieben – dort erklären wir, wie man die Frage vor der Tool-Auswahl richtig stellt.

Beschreiben Sie Ihren aktuellen Stack (Modell, Volumen, Aufgabentyp), und das Modell zeigt Ihnen die Migrationsschwellen und einen Architektur-Skelett für Self-Hosted mit Router und Guardrails – als Ausgangspunkt, nicht als fertiges Projekt (Playground: PII maskiert, keine Retention):

Die Wirtschaftlichkeitsschwelle hängt vom gewählten Modell und der Kontextlänge ab. Orientierung: Bei kurzen Prompts und Antworten (Klasse 200–500 Token) liegt die Schwelle bei 50.000–80.000 Anfragen pro Monat. Bei langen Kontexten (RAG, Dokumentenzusammenfassung) sinkt die Schwelle auf 20.000–40.000 Anfragen, da die Token-Kosten nichtlinear steigen. Berechnen Sie dies konkret mit dem ROI-Rechner vor der Entscheidung.

Self-Hosting eliminiert den Datentransfer zu externen Anbietern, was die Compliance vereinfacht – Sie müssen keinen DPA mit dem API-Anbieter abschließen oder sich um Data-Residency sorgen. Aber RODO gilt weiterhin: Grundsatz der Datenminimierung, Maskierung von PII vor dem Modell, Logs ohne personenbezogene Daten, Recht auf Löschung von Konversationshistorien. Ein eigenes Modell ist nicht automatisch RODO-konform – es erfordert dieselben Mechanismen, nur unter einer anderen Adresse.

2026 erreichen führende open-weight-Modelle (Llama 3.3 70B, Qwen 2.5 72B, Mistral Large) eine vergleichbare Qualität wie GPT-4-Class bei den meisten Geschäftsaufgaben: Klassifikation, Extraktion, Zusammenfassung, Generierung strukturierter Texte. Ein Unterschied zeigt sich bei Aufgaben, die komplexes mehrstufiges Reasoning und Wissen über sehr aktuelle Ereignisse erfordern. Für die meisten Unternehmenssysteme ist der Unterschied akzeptabel oder irrelevant. Überprüfen Sie dies mit einem Benchmark auf Ihren eigenen Daten.

Prompts, die für ein bestimmtes API-Modell geschrieben wurden, sind nicht eins zu eins portierbar. Open-weight-Modelle haben unterschiedliche Chat-Templates und reagieren anders auf Systemanweisungen. Meist reichen ein paar Iterationen: Anpassung des Formats (Rollen system/user/assistant), Entfernung von Anweisungen, die das Modell ignoriert, Hinzufügen von Beispielen (Few-Shot) an Stellen, wo das API-Modell sie nicht benötigte. Hilfreich ist auch Structured Output mit Schema-Validierung statt der Abhängigkeit vom Standard-Antwortformat.

Ja, und oft ist das die einfachste Migration. In einer RAG-Architektur ist das Modell nur der Antwortgenerator basierend auf abgerufenen Fragmenten – die Ergebnisqualität hängt mehr von der Qualität des Index und der Embeddings ab als von der Modellgröße. Ein kleineres, lokales Modell (7B–13B) meistert diese Aufgabe gut, und Embeddings – wie BGE-M3 – funktionieren ohnehin ausschließlich lokal. Die Token-Kosten für RAG sind hoch (langer Kontext mit Fragmenten), daher ist die Wirtschaftlichkeitsschwelle für Self-Hosting hier niedriger als für kontextlose Generierung.