Das Argument klingt überzeugend. Open-Source-Modelle sind wettbewerbsfähig, GPUs verfügbar und Inferenzserver wie vLLM, TGI und SGLang ausgereift. Warum bei OpenAI oder Anthropic einen fünf- bis zehnfachen Aufschlag bezahlen, wenn Sie eine vergleichbare Lösung selbst hosten können?
Die Realität ist komplexer. Bei bestimmten Größenordnungen ist Selbsthosting tatsächlich im Vorteil. Bei anderen übersteigt der betriebliche Aufwand die Einsparungen bei der Inferenz. Der Break-even hängt von Workload, Modellgröße, Latenzanforderungen und Fähigkeiten des Teams ab.
Dieser Artikel untersucht die Rechnung, die betrieblichen Realitäten und die Muster, die geeignete von ungeeigneten Teams unterscheiden. Wir gehen davon aus, dass Sie Selbsthosting ernsthaft erwägen und belastbare Zahlen wünschen.
Wann Selbsthosting sinnvoll ist
Einige Merkmale, die für Selbsthosting sprechen:
Größenordnung. Hohes Inferenzvolumen. Insbesondere monatliche API-Inferenzkosten von mehr als €5K–10K rechtfertigen meist eine Prüfung des Selbsthostings.
Vorhersehbarer Workload. Gleichmäßige, planbare Nutzung. Selbsthosting erfordert Kapazitätsplanung; stark schwankende Workloads verschwenden Kapazität bei Unterauslastung oder scheitern bei Überlastung.
Datenschutz- oder Compliance-Anforderungen. Daten, die nicht an Cloud-Anbieter übermittelt werden dürfen, etwa in regulierten Branchen, bei bestimmten Behördenaufträgen oder rein internen Daten.
Benutzerdefinierte Modelle. Fine-Tunes, benutzerdefinierte Architekturen oder spezialisierte Varianten, die verwaltete Anbieter nicht anbieten.
Latenzkontrolle. Für manche Anwendungen erfordert eine Time-to-First-Token unter 100 ms den Betrieb auf eigener Infrastruktur.
Kosten je Aufruf unterhalb des Break-even. Ihre konkrete Rechnung zeigt, dass Selbsthosting tatsächlich günstiger ist.
Wenn die meisten dieser Punkte zutreffen, ist Selbsthosting eine ernsthafte Überlegung wert.
Wann Selbsthosting nicht sinnvoll ist
Die andere Seite. Merkmale, die für verwaltete APIs sprechen:
Niedriges oder variables Volumen. Inferenzkosten unter €5K pro Monat. Die Einsparungen rechtfertigen den Betriebsaufwand nicht.
Stark schwankende Workloads. Nutzung, die zwischen Spitzen- und Ruhezeiten um den Faktor 10 variiert. Selbsthosting verschwendet in Lasttälern Kapazität.
Bedarf an Spitzenfähigkeiten. GPT-5.5, Claude Opus 4.8 und die neuesten Reasoning-Stufen sind geschlossen und nur über APIs verfügbar. Benötigt Ihr Workload tatsächlich diese Spitzenqualität, müssen Sie APIs nutzen.
Kleines Team. Selbst gehostete Inferenz erfordert Betriebsexpertise. Ohne dafür reservierte Kapazität treten Ausfälle auf.
Schnelle Iteration. Viele unterschiedliche Modelle, Konfigurationen und Anbieter ausprobieren. APIs erleichtern das; beim Selbsthosting erfordert jede Änderung eine Bereitstellung.
Mehrere Regionen oder globale Nutzer. Beim Selbsthosting müssen Sie jede Region selbst betreiben. Verwaltete APIs übernehmen das.
Für diese Fälle sind verwaltete APIs die richtige Antwort, auch bei erheblichen Kosten.
Die Kostenrechnung – mit Sorgfalt
Lassen Sie uns die tatsächlichen Zahlen für einen repräsentativen Fall durchgehen. Annahmen:
- Workload: 100 Millionen Eingabetoken und 30 Millionen Ausgabetoken pro Monat.
- Qualitätsziel: vergleichbar mit Claude Sonnet 5 oder dem aktuellen GPT-5.x-Tier.
- Verfügbares offenes Modell: Llama 3.3 70B (bei vielen Aufgaben liegt die Qualität nahe an geschlossenen Spitzenmodellen; beachten Sie, dass es kein „Llama 4 70B“ gibt – Llama 4 wird als Scout/Maverick-MoE-Modelle angeboten).
Option A: API eines geschlossenen Modells.
- Geschlossene Spitzenmodell-API (Listenpreis von Claude Sonnet 5, verifiziert am 2026-07-07): $3/M Eingabe × 100M = $300. $15/M Ausgabe × 30M = $450. Gesamt: ~$750 pro Monat.
Diese Ausgaben rechtfertigen kein Selbsthosting.
Lassen Sie uns die Workload um das 10-fache erhöhen:
- 1 Milliarde Eingabetokens, 300 Millionen Ausgabetokens.
- Geschlossene API: $7.500 pro Monat.
Nun wird Selbsthosting interessant.
Option B: API eines offenen Modells bei einem verwalteten Anbieter.
- Llama 3.3 70B auf Together AI: $0,88/M Eingabe und Ausgabe (Listenpreis, bestätigt 2026-07-07).
- 1B Eingabe × $0,88/M = $880. 300M Ausgabe × $0,88/M = $264. Gesamt: ~$1.144 pro Monat.
Eine Einsparung von ~85 % gegenüber dem geschlossenen Modell – erheblich.
Option C: Selbsthosting auf gemieteten GPUs.
- Ein quantisiertes 70B-Modell (INT8/FP8) passt auf eine einzelne H100 mit 80 GB; planen Sie für FP16-Gewichte oder zusätzliche Batch-Durchsatzreserve ~2 H100 ein – die folgende Dimensionierung geht zugunsten des Durchsatzes von 2 aus.
- Gemietete H100s: $2–3 pro Stunde.
- 2 H100s × $2,50/Stunde × 730 Stunden pro Monat = $3.650 pro Monat nur für Rechenkosten.
- Hinzu kommen Speicher, Netzwerk und Betriebsaufwand.
Bei diesem Workload ist ein offenes Modell beim verwalteten Anbieter in den reinen Kosten günstiger als Selbsthosting. Selbsthosting gewinnt nur, wenn Sie zusätzlich Kontrolle benötigen – etwa aus Datenschutzgründen oder für ein angepasstes Modell – oder Ihr Durchsatz erheblich höher liegt.
Option D: Selbsthosting auf eigenen oder langfristig reservierten GPUs.
- 2 H100s gekauft oder langfristig reserviert: $1–2 pro Stunde effektiv.
- 2 H100s × $1,50/Stunde × 730 Stunden = $2.190 pro Monat.
- Eine höhere Auslastung verteilt die Kosten: Verarbeiten diese GPUs mehrere Workloads, sinken die Kosten je Workload.
Damit sind wir gegenüber verwalteten Open-Source-Anbietern wettbewerbsfähig. Der betriebliche Zusatzaufwand bleibt jedoch real.
Die zentrale Erkenntnis: Bei dieser Größenordnung (~1,3B Token pro Monat) sind die Einsparungen durch Selbsthosting gegenüber verwalteten Open-Source-Anbietern gering. Gegenüber geschlossenen APIs sind sie drastisch, doch verwaltete Open-Source-Angebote realisieren den Großteil davon bereits.
Beim Zehnfachen dieses Workloads (~13B Token pro Monat) wird Selbsthosting deutlich günstiger. Bei einem Zehntel ist Hosting die richtige Wahl.
Die Betriebskosten
Zu den reinen Inferenzkosten kommen beim Selbsthosting die Betriebskosten.
Erste Einrichtung:
- Auswahl des richtigen Inferenzservers (vLLM, TGI, SGLang).
- Konfigurieren für Ihr Modell und Ihre Hardware.
- Einrichten der GPU-Infrastruktur (Cloud oder eigenes).
- Netzwerk, Sicherheit, Observability.
- Quantisierung und Optimierung.
Typisch sind 1–4 Entwicklungswochen für die erste Bereitstellung.
Laufende Betriebskosten:
- Überwachung (Latenz, Durchsatz, Fehler, GPU-Auslastung).
- Kapazitätsplanung.
- Upgrades (neue Modellversionen, Inferenzserver-Updates, Sicherheitspatches).
- Reaktion auf Vorfälle (GPU-Ausfälle, OOM-Abstürze, Softwarefehler).
- Skalierung (mehr GPUs bei steigender Last).
Typisch sind dauerhaft 0,25–1 Entwicklungs-FTE, abhängig von der Größenordnung.
Versteckte Kosten:
- GPU-Preisvolatilität.
- Cloud-Egress-Kosten bei Hybrid.
- Spezialisierte Expertise (CUDA, Quantisierung, Optimierung).
- Ersatz- und Ausfallkosten eigener Hardware.
Bei Vollkosten von €100K–200K je Entwickler und Jahr ist selbst ein Teilzeitanteil erheblich. Eine monatliche Inferenzersparnis von €5K wird durch €15K Entwicklungskosten pro Monat mehr als aufgezehrt.
Hier unterschätzen Teams die Kosten des Selbsthostings häufig. Isoliert betrachtet sieht die Inferenzrechnung gut aus; die Gesamtbetriebskosten liegen wesentlich höher.
Die Inferenzserver
Wenn Sie selbst hosten, stehen vor allem diese Optionen zur Wahl:
vLLM. Open Source. Wahrscheinlich die beliebteste Lösung zur Bereitstellung offener LLMs. PagedAttention, kontinuierliches Batching und breite Modellunterstützung. Die Standardwahl.
TGI (Text Generation Inference). Server von Hugging Face. Ausgereift, breite Modellunterstützung, gute Leistung. Zuletzt langsamere Funktionsentwicklung als bei vLLM.
SGLang. Neuer, mit sehr hoher Leistung. Stark bei strukturierter Generierung. Aktive Entwicklung.
LMDeploy. Vom InternLM-Team. Gute Quantisierungsunterstützung und hohe Geschwindigkeit.
llama.cpp / Ollama. Für kleinere Modelle und geringeren Durchsatz. CPU-freundlich und für manche Anwendungsfälle produktionsreif.
Hugging Face TGI Inference Endpoints. Verwaltetes Hosting auf dedizierten Instanzen. Abrechnung je Instanzstunde; HF übernimmt den Betrieb. Ein Mittelweg zwischen vollständigem Selbsthosting und verwalteter Inferenz.
Modal, RunPod, Replicate. Function as a Service für Inferenz. Geringere Bindung als vollständiges Selbsthosting, aber höhere Kosten als Eigenbetrieb.
Für die meisten Teams eignen sich vLLM oder SGLang für produktives Selbsthosting. Beide sind ausgereift, schnell und gut dokumentiert.
Hardwareauswahl
Die GPU-Frage:
NVIDIA H100. Aktueller Stand der Technik für Inferenz. Gemietet ~$2–3 pro Stunde. Bietet 80 GB VRAM und schnelle Inferenz. 70B-Modelle laufen quantisiert gut auf einer H100 oder unquantisiert auf zwei.
NVIDIA H200. Nachfolger von H100, mehr VRAM (141 GB). Für sehr große Modelle.
NVIDIA L40S. Leichter verfügbar, ~$1–2 pro Stunde. Gut für mittelgroße Modelle bis ~30B mit Quantisierung.
NVIDIA A100. Vorgängergeneration, weiterhin weit verbreitet. ~$1–2 pro Stunde. Ein Arbeitspferd vieler Produktiveinsätze.
AMD MI300X. Bei einigen Workloads mit der H100 wettbewerbsfähig. Zunehmend verfügbar, aber mit gewissen Reifeunterschieden im Software-Stack gegenüber NVIDIA.
Apple M-Serie. Bei sehr kleinen Modellen unter 8B funktionieren Mac Studio oder Mac Pro mit gemeinsamem Speicher. Ein Nischenfall.
Für die meisten Selbsthosting-Szenarien im Jahr 2026 gilt: H100 oder H200 für große Modelle, L40S oder A100 für mittelgroße.
Bezugsquellen zur Miete: AWS, GCP und Azure als große Anbieter sowie Lambda Labs, Runpod, Together und Vast.ai als Spezialanbieter. Die Preise variieren. Spot- oder unterbrechbare Instanzen können 50–70 % sparen, sofern Sie Unterbrechungen tolerieren.
Quantisierung
Die meisten produktiven Selbsthosting-Deployments verwenden quantisierte Modelle. Die Zielkonflikte:
FP16 (16 Bit). Standardpräzision. Volle Qualität. Höchster Speicherbedarf.
INT8 / FP8 (8 Bit). Halbierter Speicherbedarf, geringer Qualitätsverlust. Häufige Wahl im Produktiveinsatz.
INT4 (4 Bit). Ein Viertel des Speicherbedarfs, deutlicherer Qualitätsverlust, aber weiterhin nützlich. Eine aggressive Wahl.
AWQ, GPTQ, GGUF. Verschiedene Quantisierungsformate mit unterschiedlichen Kompromissen.
Für ein 70B-Modell:
- FP16: 140 GB VRAM.
- INT8: 70 GB VRAM.
- INT4: 35 GB VRAM.
Der H100 hat 80 GB VRAM. INT8 passt bequem; FP16 benötigt 2 GPUs.
Qualitätsauswirkungen:
- INT8: üblicherweise <1 % Verschlechterung in Benchmarks.
- INT4: 1–5 % Verschlechterung, abhängig von der Aufgabe.
Testen Sie mit Ihrem eigenen Workload, bevor Sie bereitstellen. Einige Aufgaben, insbesondere strukturierte Ausgabe und Code, reagieren empfindlicher auf Quantisierung als andere.
Durchsatz und Kapazitätsplanung
Eine zentrale Planungsfrage lautet: Wie viele Token pro Sekunde benötigen Sie?
Einzelner Anforderungsdurchsatz.
- 70B-Modell auf H100, INT8: ~50–80 Token pro Sekunde für einen einzelnen Nutzer.
Batch-Durchsatz.
- Mehrere parallele Anfragen: insgesamt 1000–3000 Token pro Sekunde über alle Anfragen hinweg (vLLM mit gutem Batching).
Latenzbetrachtung.
- Time-to-First-Token: typischerweise 100–500 ms.
- Pro-Token-Latenz: 10–30 ms.
Für Kapazitätsplanung:
- Schätzen Sie den Spitzenwert der parallelen Anfragen.
- Schätzen Sie die durchschnittliche Länge einer Anfrage.
- Berechnen Sie die benötigten Token pro Sekunde.
- Fügen Sie 50 % Puffer hinzu.
Ein Team, das 1 Mio. Token pro Stunde bei einer Spitze von 50 parallelen Nutzern verarbeitet, benötigt bei guter Auslastung typischerweise 2–4 H100.
Zuverlässigkeit und Fallback
Selbsthosting bedeutet, dass Sie die Zuverlässigkeit selbst verantworten.
Health Checks. Kontinuierliche Zustandsüberwachung. Fehlerhafte Instanzen neu starten.
Sanfte Degradation. Wenn die Kapazität gesättigt ist, bevorzugen Sie langsame Antworten gegenüber Fehlern.
Fallback auf APIs. Viele Teams verarbeiten den primären Datenverkehr selbst und weichen bei Überlastung auf verwaltete APIs aus. Das verbindet die Vorteile beider Ansätze, erhöht aber die Komplexität.
Reservehardware. GPUs fallen aus. Halten Sie Ersatzkapazität bereit.
Mehrere Regionen. Replizieren Sie für globale Nutzer oder verwenden Sie verwaltete APIs in entfernten Regionen.
Update-Strategie. Neue Modellversionen, Server-Upgrades. Blue-Green-Deployments, um Ausfallzeiten zu vermeiden.
Jeder dieser Punkte bedeutet Entwicklungs- und Betriebsarbeit, die verwaltete APIs für Sie übernehmen.
Durchgerechnetes Beispiel: Ein Team entscheidet sich für Selbsthosting
Ein reales Beispiel: Ein SaaS-Team mit KI-Funktionen zahlt für verwaltete APIs monatlich €18.000 an Inferenzkosten.
Die Rechnung:
- 80 % der Inferenz ist Klassifizierung und Extraktion (könnte auf einem kleineren Open-Modell laufen).
- 20 % entfallen auf komplexe Generierung, die ein geschlossenes Spitzenmodell erfordert.
Plan:
- Llama 3.3 70B für 80 % des Workloads selbst hosten.
- Claude-/GPT-APIs für die verbleibenden 20 % beibehalten.
- 3 H100s auf Lambda Labs reserviert: ~€4.500 pro Monat.
- Technische Einrichtung: 4 Wochen, einmalig €25.000.
- Laufender Betrieb: 0,25 Entwicklungs-FTE, ~€30.000/Jahr.
Ergebnis nach 6 Monaten:
- Die Inferenzkosten sanken von €18K auf €6K pro Monat (€4,5K Selbsthosting + €1,5K geschlossene API für schwierige Aufgaben).
- Nettoeinsparung gegenüber altem Modell: €12K pro Monat = €144K/Jahr.
- Abzüglich technischer Investition: einmalig €25K + €30K/Jahr ≈ €55K im ersten Jahr (€30K/Jahr danach).
- Nettofinanzieller Vorteil:
€89K im ersten Jahr (€114K/Jahr danach).
Versteckte Komplexitäten:
- Ein Ausfall durch einen Konfigurationsfehler bei einer Bereitstellung. Zwei Stunden eingeschränkter Betrieb.
- Mehrere Wochen fortlaufender Abstimmung zur Optimierung des Durchsatzes.
- Der für das Selbsthosting verantwortliche Entwickler hätte seine Zeit lieber für andere Aufgaben eingesetzt.
Ergebnis: finanziell positiv, betrieblich jedoch aufwendiger als erwartet. Das Team bleibt beim Selbsthosting; würde das Volumen um 50 % sinken, wechselte es zurück zu einer verwalteten Lösung.
So sieht eine wirklich erfolgreiche Selbsthosting-Entscheidung aus: keine Magie, sondern Entwicklungsarbeit mit messbarem ROI.
Durchgerechnetes Beispiel: Ein Team kehrt zu APIs zurück
Ein anderes Team, ähnlicher Ausgangspunkt.
Ursprüngliche Konfiguration: Selbst gehostetes Llama 3 70B auf gemieteten GPUs. Inferenzkosten: €3K Monatsmiete plus laufend ~€20K/Jahr für Entwicklung und Betrieb.
Die Änderung:
- Der Preis für offene Modelle bei einem verwalteten Anbieter sank innerhalb von 18 Monaten um 50 %.
- Ihr Team wuchs, aber sie stellten keine dedizierte MLOps-Expertise ein.
- Die selbst gehostete Konfiguration erforderte erheblichen Aufwand, um mit neuen Modellen Schritt zu halten.
Die Entscheidung:
- Selbsthosting beenden.
- Wechseln zu Together AI, die Open-Modelle hosten.
- Kosten: €2.500 pro Monat für ein verwaltetes offenes Modell. Kleine Einsparung, deutlich geringere Komplexität.
- Entwicklungskapazität freigeben.
Ergebnis:
- Moderate finanzielle Einsparung.
- Entwicklungszeit für Produktarbeit freigesetzt.
- Weniger betrieblicher Stress.
Ergebnis: Für dieses Team war es die richtige Entscheidung. Selbsthosting ist für manche Teams vorteilhaft, für andere nicht.
Wann die Entscheidung erneut überprüfen
Die Entscheidung gilt nicht für immer. Prüfen Sie sie regelmäßig:
Volumenänderungen. Deutlich gestiegen: Selbsthosting wird attraktiver. Deutlich gesunken: Es wird weniger attraktiv.
Preisänderungen. Geschlossene APIs werden günstiger oder teurer. Verwaltete offene Modelle und Hardware werden günstiger.
Modellverbesserungen. Neue Open-Source-Modelle, die der geschlossenen Qualität entsprechen. Neue geschlossene Modelle, die sich abheben.
Betriebskapazität. Die ML- und Betriebskompetenz des Teams ist gewachsen oder geschrumpft.
Änderungen bei Datenschutz oder Compliance. Neue Anforderungen, die Selbsthosting verlangen.
Eine quartalsweise Prüfung ist angemessen: keine ständige Neubewertung, aber auch keine Entscheidung für immer.
Häufige Fehler
Muster, die wir bei Entscheidungen über Selbsthosting beobachten:
Fehler 1: Kostenrechnung ohne Betriebskosten. „Selbsthosting spart €10K pro Monat“, ignoriert aber €15K monatliche Entwicklungs- und Betriebskosten. Negativer ROI.
Fehler 2: Zu frühes Selbsthosting. Technischer Aufwand für Selbsthosting bei einem kleinen Workload. Eine verfrühte Optimierung.
Fehler 3: Spitzenqualität mit kleinen offenen Modellen selbst hosten. „Wir können mit einem kleineren Modell Geld sparen“ – doch die Qualität sinkt und Nutzer beschweren sich. Es folgt der Rückgriff auf APIs.
Fehler 4: Kein Fallback. Die selbst gehostete Infrastruktur fällt aus, eine kontrollierte Degradation fehlt. Es entsteht ein Ausfall, den API-Nutzer nicht gehabt hätten.
Fehler 5: Zu geringe Investition in Optimierung. Ein 70B-Modell läuft auf einer einzelnen GPU mit 5 Token/s, obwohl eine korrekte Konfiguration 50 liefert. Der Großteil des Nutzens geht verloren.
Fehler 6: Qualitätsdrift ignorieren. Das selbst gehostete Modell ist gegenüber aktuellen geschlossenen Modellen zurückgefallen. Kunden bemerken es, das Team nicht.
Fehler 7: Entscheidung nicht erneut prüfen. Einmal Selbsthosting, immer Selbsthosting. Eine vor zwei Jahren richtige Entscheidung kann heute falsch sein.
Fehler 8: Spot- oder unterbrechbare Instanzen ohne kontrollierte Handhabung. 60 % Rechenkosten gespart, dafür Ausfälle im Abstand weniger Stunden, wenn Instanzen entzogen werden.
Eine Entscheidungscheckliste
Um die Entscheidung bewusst zu treffen:
- Betragen die API-Inferenzkosten mindestens €5–10K pro Monat?
- Ist der Workload stabil und vorhersehbar?
- Verfügt das Team über MLOps-/Inferenzexpertise oder kann es diese einstellen?
- Ist ein Open-Source-Modell mit ausreichender Qualität verfügbar?
- Sind die Latenzanforderungen mit Selbsthosting vereinbar?
- Haben Sie eine detaillierte Kostenrechnung einschließlich der Betriebskosten erstellt?
- Haben Sie einen Fallback-Plan?
- Erzwingen Compliance- oder Datenschutzanforderungen keinen bestimmten Weg?
- Werden Sie quartalsweise erneut überprüfen?
Wenn Sie die meisten Fragen mit Ja beantworten, ist Selbsthosting eine ernsthafte Überlegung wert.
Hybrid-Muster
Es ist nicht alles oder nichts. Viele Teams betreiben Hybrid:
Selbsthosting für den Großteil, APIs für schwierige Fälle. Klassifizierung und einfache Generierung laufen selbst gehostet, komplexes Reasoning über geschlossene APIs.
Selbsthosting für stabile Last, APIs für Spitzen. Die Grundlast läuft selbst gehostet, APIs fangen Spitzen ab.
Selbsthosting für sensible Daten, APIs für allgemeine Aufgaben. Sensible Daten werden selbst gehostet verarbeitet, allgemeine Anfragen über APIs.
Selbsthosting für Fine-Tunes, APIs für Standardmodelle. Angepasste Modelle selbst betreiben, Standardmodelle über APIs beziehen.
Ein hybrider Ansatz erhöht die Komplexität, verbindet aber häufig die Vorteile beider Seiten. Für Teams in großem Maßstab ist er oft die richtige Wahl.
Fazit
Selbst gehostete LLM-Inferenz ist 2026 tatsächlich praktikabel. Open-Source-Modelle sind wettbewerbsfähig, Inferenzserver ausgereift und Hardware verfügbar.
Der betriebliche Aufwand ist jedoch real und wird leicht unterschätzt. Der Break-even gegenüber verwalteten APIs liegt bei ungefähr €5–10K monatlichen Inferenzkosten; darunter lohnt sich die technische Investition nicht.
Teams, die Selbsthosting erfolgreich betreiben:
- haben ehrlich gerechnet und Betriebskosten einbezogen,
- verfügen über MLOps-Fähigkeiten oder können sie aufbauen,
- arbeiten in einer Größenordnung, die die Investition rechtfertigt,
- Haben stabile Workloads.
- benötigen keine ausschließlich über geschlossene Spitzenmodelle verfügbare Qualität,
- planen Zuverlässigkeit, Überwachung und Aktualisierungen ein.
Teams, die bei APIs bleiben sollten:
- haben ein niedriges Volumen,
- haben stark schwankende Workloads,
- benötigen schnelle Iteration,
- sind klein und verfügen über keine Betriebskapazität,
- benötigen exklusiv verfügbare Spitzenqualität.
Die richtige Antwort hängt von Ihrer Situation ab. Rechnen Sie sorgfältig und bewerten Sie Ihre Betriebskapazitäten ehrlich. Bleiben Sie standardmäßig bei APIs, sofern Selbsthosting nicht eindeutig gewinnt.
Wenn Selbsthosting gewinnt, dann deutlich – wirtschaftlich und architektonisch. Andernfalls ist es ein teurer Weg zu der Erkenntnis, dass verwaltete APIs die richtige Wahl gewesen wären.
