Der Ansatz ist verlockend: Beschleuniger mieten oder kaufen, ein Open-Weight-Modell bereitstellen und damit variable API-Kosten ersetzen. Modelle sind jedoch nicht automatisch gleichwertig, GPUs bleiben nicht durchgehend voll ausgelastet und Sie übernehmen die Verantwortung für Sicherheit und Zuverlässigkeit des gesamten Serving-Stacks.
Dieser Artikel ist ein Leitfaden zur Kostenmodellierung und kein Benchmark. Prüfen Sie vor der Auswahl eines Servers die aktuelle vLLM-Dokumentation, die Sicherheitshinweise für vLLM, die Dokumentation zu SGLang und die Dokumentation zu Hugging Face TGI. Testen Sie die unterstützten Versionen auf der vorgesehenen Hardware.
Die Realität ist komplexer. Bei einer bestimmten Größenordnung kann sich Self-Hosting tatsächlich rechnen. In anderen Fällen übersteigen die Betriebskosten die Einsparungen bei der Inferenz deutlich. Der Break-even-Punkt hängt von der Arbeitslast, der Modellgröße, den Latenzanforderungen und den Fähigkeiten des Teams ab.
Dieser Artikel behandelt die Kostenrechnung, die betrieblichen Anforderungen und die Merkmale, anhand derer sich erkennen lässt, für welche Teams Self-Hosting sinnvoll ist und für welche nicht. Er richtet sich an Teams, die diese Option ernsthaft prüfen und konkrete Zahlen benötigen.
Wenn Self-Hosting sinnvoll ist
Einige Merkmale, die für ein selbst gehostetes Deployment sprechen:
Umfang und Auslastung. Eine dauerhaft hohe, vorhersehbare Nachfrage kann reservierte Kapazität amortisieren. Verwenden Sie die gemessene stündliche Lastverteilung; die monatlichen API-Ausgaben allein reichen für eine Break-even-Entscheidung nicht aus.
Vorhersehbare Arbeitslast. Die Nutzung ist gleichmäßig und planbar. Self-Hosting erfordert Kapazitätsplanung; stark schwankende Arbeitslasten verschwenden Kapazität bei Unterauslastung oder führen bei Überlastung zu Ausfällen.
Datenschutz- und Compliance-Anforderungen. Daten, die nicht an Cloud-Anbieter übermittelt werden dürfen (regulierte Branchen, bestimmte Regierungsverträge, ausschließlich interne Daten).
Eigene Modelle. Fine-Tunings, eigene Architekturen oder spezialisierte Varianten, die verwaltete Anbieter nicht bereitstellen.
Kontrolle über die Latenz. Ein Standort näher an den Nutzern und steuerbares Batching können die Latenz verbessern. Netzwerk, Warteschlangen, Modellgröße, Prompt-Länge und Last bleiben jedoch entscheidend. Messen Sie das relevante Perzentil.
Kosten pro Aufruf unter der Break-even-Schwelle. Die Rechnung zeigt, dass Self-Hosting tatsächlich günstiger ist.
Wenn die meisten dieser Punkte zutreffen, ist Self-Hosting eine ernsthafte Überlegung wert.
Wenn Self-Hosting nicht sinnvoll ist
Die andere Seite. Merkmale, die verwaltete APIs begünstigen:
Geringer oder schwankender Umfang. Leerlaufende Kapazität und die Auslegung auf Lastspitzen können vermeintliche Einsparungen beim Token-Preis aufzehren. Verwaltete Inferenz kann besser passen; rechnen Sie dennoch beide Varianten durch.
Sprunghafte Arbeitslasten. Große Unterschiede zwischen Spitzen- und Ruhezeiten können dazu führen, dass reservierte Kapazitäten ungenutzt bleiben oder teure Hochskalierungen für die Spitzenlast erforderlich sind.
Sie benötigen Funktionen eines geschlossenen Modells. Einige aktuelle Modelle, Modalitäten, Sicherheitssysteme oder gehostete Werkzeuge sind ausschließlich über einen Anbieterdienst verfügbar. Wenn die Evaluierung einer Arbeitslast eines dieser Elemente erfordert, berücksichtigen Sie den Anbieterpfad und seine vertraglichen Einschränkungen, statt ihn durch ein nicht evaluiertes Open-Weight-Modell zu ersetzen.
Kleines Team. Self-Hosting von Inferenz erfordert Betriebserfahrung. Ohne fest eingeplante Kapazität entstehen Betriebsprobleme.
Schnelle Iteration. APIs erleichtern das Ausprobieren verschiedener Modelle, Konfigurationen und Anbieter; bei Self-Hosting wird jede Änderung zu einem Deployment.
Mehrere Regionen / weltweite Nutzer. Self-Hosting kann regionale Kapazität sowie zusätzlichen Aufwand für Routing, Datenübertragung und Wiederherstellung erfordern. Verwaltete APIs können einen Teil der Infrastrukturverantwortung abnehmen. Verfügbarkeit in den jeweiligen Regionen, Datenresidenz, Failover und Netzwerklatenz müssen Sie dennoch prüfen.
In diesen Fällen können verwaltete APIs selbst bei höheren direkten Nutzungskosten die risikoärmere Option mit weniger Eigenverantwortung sein.
Die Kostenrechnung (sorgfältig)
Erstellen Sie drei aktuelle Szenarien mit gleichwertiger Qualität: eine API für ein geschlossenes Modell, verwaltetes Serving eines Open-Weight-Modells und Self-Hosting. Vergleichen Sie die Modelle erst, nachdem sie dieselbe Evaluierung für die konkrete Aufgabe bestanden haben.
Berechnen Sie für jedes Szenario Folgendes:
monthly total = metered inference or dedicated capacity + storage + network + observability + support + security/compliance + engineering + expected incident loss
Bei nutzungsabhängig abgerechneten APIs setzen sich die Inferenzkosten aus abgerechneten, nicht zwischengespeicherten Eingaben, Cache-Schreib- und -Lesevorgängen, Ausgabe- und Reasoning-Tokens, Werkzeugen, Batches und Wiederholungen zusammen. Bei selbst gehosteter oder verwalteter dedizierter Kapazität muss der Kostenpool für Beschleuniger die genutzte und ungenutzte Kapazität sowie Reserven für Lastspitzen, Rollouts, Ausfälle und Fallbacks umfassen. Setzen Sie nicht zusätzlich eine zweite Inferenzgebühr an, sofern der Vertrag dafür nicht einen separaten, sich gegenseitig ausschließenden Zähler vorsieht. Verteilen Sie die Kapazitätskosten anhand der gemessenen Anfragen pro Beschleunigerstunde bei der erforderlichen Latenz und Verfügbarkeit auf die Arbeitslasteinheiten, nicht anhand des Spitzendurchsatzes des Anbieters.
Führen Sie eine Sensitivitätsanalyse für Volumen, Verhältnis von Spitzen- zu Durchschnittslast, Modellqualität, Beschleunigerpreis, Auslastung, Personalaufwand und Migrationskosten durch. Der Break-even-Punkt liegt dort, wo die Nettokosten der qualitativ gleichwertigen Varianten innerhalb einer plausiblen Bandbreite von Annahmen gleich hoch sind.
Die Betriebskosten
Neben den reinen Inferenzkosten fallen beim Self-Hosting Betriebskosten an.
Ersteinrichtung:
- Die Auswahl des richtigen Inference-Servers (vLLM, TGI, SGLang).
- Konfiguration für Ihr Modell und Ihre Hardware.
- Einrichten der GPU-Infrastruktur (Cloud oder eigenständig betrieben).
- Netzwerktechnik, Sicherheit und Observability.
- Quantisierung und Optimierung.
Schätzen Sie den Aufwand für die erste Bereitstellung anhand eines klar abgegrenzten Projektstrukturplans, der Vorlaufzeiten für Hardware und Anbieter, der Sicherheitsprüfung, der Benchmark-Matrix, des Verfügbarkeitskonzepts und des beobachteten Arbeitstempos des Teams. Dieser Artikel nennt bewusst keine übertragbare Schätzung in Entwicklerwochen.
Laufender Betrieb:
- Überwachung (Latenz, Durchsatz, Fehler, GPU-Auslastung).
- Kapazitätsplanung.
- Updates (neue Modellversionen, Aktualisierungen des Inferenzservers, Sicherheitspatches).
- Vorfallbewältigung (GPU-Ausfälle, OOM-Crashes, Softwarefehler).
- Skalierung (mehr GPUs bei steigender Last).
Dokumentieren Sie, wer Plattformbetrieb, maschinelles Lernen, Sicherheit und Bereitschaftsdienst tatsächlich verantwortet. Die Annahme eines pauschalen Vollzeitäquivalents lässt sich nicht von einer Organisation auf eine andere übertragen.
Versteckte Kosten:
- Schwankungen bei den GPU-Preisen.
- Cloud-Egress-Kosten bei hybridem Betrieb.
- Fachspezifische Expertise (CUDA, Quantisierung, Optimierung).
- Ersatz- und Ausfallkosten für eigene Hardware.
Verwenden Sie die Vollkostenverrechnungssätze und Opportunitätskosten Ihrer Organisation. Einsparungen beim Token-Preis sind erst dann Nettoeinsparungen, wenn die betriebliche Verantwortung mitgerechnet ist.
Die Inferenzserver
Wenn Sie sich für Self-Hosting entscheiden, stehen Ihnen hauptsächlich folgende Optionen zur Verfügung:
vLLM. Eine Open-Source-Serving-Engine mit Continuous Batching und breiter, versionsabhängiger Modellunterstützung. Betrachten Sie die Sicherheitsrichtlinien als Pflichtlektüre.
TGI (Text Generation Inference). Das Serving-Projekt von Hugging Face. Überprüfen Sie den aktuellen Wartungsstatus und die Modellunterstützung, anstatt sich auf diesen Artikel-Snapshot zu verlassen.
SGLang. Ein Serving- und Programmierstack in aktiver Entwicklung. Führen Sie Benchmarks für die erforderlichen Modelle, den Pfad für strukturierte Ausgaben und die Betriebswerkzeuge durch.
LMDeploy. Ein weiterer Kandidat für das Serving mit modell-, quantifizierungs- und hardwareabhängiger Unterstützung; führen Sie Benchmarks unter denselben Akzeptanztests durch.
llama.cpp / Ollama. Kandidaten für lokale und einige serverbasierte Arbeitslasten. Unterstützte Hardware, Parallelität, Sicherheitsgrenzen, betriebliche Kontrollen und Eignung für den Produktivbetrieb müssen getestet werden; aus keinem der beiden Namen lassen sich ein niedrigerer Durchsatz oder Produktionsreife ableiten.
Verwaltete dedizierte Endpunkte. Hugging Face und andere Anbieter bieten verwaltete Endpunktprodukte an, deren Engines, Abrechnung, Isolation und Aufteilung der Betriebsverantwortung sich ändern können. Prüfen Sie den aktuellen Dienst, statt davon auszugehen, dass er TGI verwendet oder nach einem bestimmten Modell abrechnet.
Verwaltete GPU- oder Inferenzplattformen. Diese können einige Kapazitäts- und Serving-Aufgaben reduzieren, während Integration, Sicherheit, Evaluierung und Anbieterabhängigkeiten erhalten bleiben. Vergleichen Sie aktuelle Angebote und Verantwortlichkeiten; gehen Sie nicht von einem festen Preisverhältnis zum Eigenbetrieb aus.
Nehmen Sie nur Projekte in die engere Auswahl, die das konkrete Modell, den Beschleuniger, die Quantisierung, den API-Vertrag und die Sicherheitskontrollen unterstützen. Entscheiden Sie anhand eines reproduzierbaren Lasttests.
Hardwareauswahl
Die GPU-Frage:
Beschleunigergenerationen, Speicherkapazitäten und Mietpreise ändern sich schnell. Holen Sie aktuelle Angebote für die benötigte Region und Vertragslaufzeit ein.
Vergleichen Sie Speicherkapazität und Bandbreite, unterstützte Zahlenformate, Verbindungen zwischen Beschleunigern, Softwarekompatibilität, Kontingente, regionale Verfügbarkeit, Ausfallverhalten und Preis. Spot- oder unterbrechbare Kapazität gehört nur dann in das Modell, wenn Sie Unterbrechungen abfangen können und einen gemessenen Wiederherstellungspfad haben.
Quantisierung
Die Quantisierung ist eine Option für Kapazität und Leistung. Ihre Vor- und Nachteile hängen vom Modell, Format, Kernel, Hardwaretyp und Einsatzszenario ab:
Referenzpräzision der FP16/BF16-Klasse. Sie dient bei unterstützten Modellen und Hardware häufig als Vergleichsbasis, ist aber nicht automatisch das ursprüngliche Format des Modells oder das Format mit der höchsten Qualität.
INT8 / FP8 (8-Bit). Kann den Gewichtsspeicher reduzieren oder unterstützte Ausführungspfade verbessern; die Auswirkungen auf Qualität und Geschwindigkeit variieren.
INT4 (4-Bit). Kann den Gewichtsspeicher weiter reduzieren; messen Sie Qualität und Kernel-Leistung für das genaue Artefakt.
AWQ, GPTQ, GGUF. Verschiedene Quantisierungsformate mit unterschiedlichen Abwägungen.
Die reine Berechnung anhand der Parameterzahl liefert nur eine Untergrenze; zur Laufzeit werden außerdem Speicher für KV-Cache, Aktivierungen, Arbeitsbereiche, Fragmentierung und Replikate benötigt. Nutzen Sie den Profiler der Serving-Engine und einen Lasttest. Bewerten Sie die Ausgabequalität anhand der Produktivaufgabe, nicht nur mit einem allgemeinen Benchmark.
Durchsatz- und Kapazitätsplanung
Eine zentrale Frage der Planung: Wie viele Tokens pro Sekunde benötigen Sie?
Messen Sie über verschiedene Prompt- und Ausgabelängen sowie Parallelitätsstufen hinweg die Zeit bis zum ersten Token, die Latenz zwischen den Token, die Ende-zu-Ende-Latenz, den Durchsatz, die Warteschlangenzeit, die Fehlerrate und die Speicherreserve.
Für die Kapazitätsplanung:
- Schätzen Sie die Spitzenzahl gleichzeitiger Anfragen.
- Schätzen Sie die durchschnittliche Anforderungslänge ab.
- Berechnen Sie die insgesamt benötigten Tokens pro Sekunde.
- Fügen Sie eine Kapazitätsreserve hinzu, die sich aus Lastspitzen, Ausfällen und Rollout-Anforderungen ableitet.
Zuverlässigkeit und Fallback
Self-Hosting bedeutet, dass die Zuverlässigkeit in Ihrer Verantwortung liegt.
Zustandsprüfungen. Überwachen Sie den Systemzustand kontinuierlich und starten Sie fehlerhafte Instanzen neu.
Verhalten bei Überlastung. Verwenden Sie begrenzte Warteschlangen, Admission Control, Backpressure sowie eine getestete Strategie für kontrollierte Degradation oder die Ablehnung von Anfragen. Unbegrenzte Wartezeiten können eine Überlastung verschärfen und die Latenzziele verletzen.
Fallback zu APIs. Ein verwalteter Fallback kann einige Ausfälle oder Lastspitzen abfedern, jedoch nur dann, wenn Modellqualität, Datenrichtlinien, Verträge, Ratenbegrenzungen (Rate Limits), Zustand und Failover-Verhalten kompatibel sind und getestet wurden. Er erhöht die Komplexität und kann gleichzeitig ausfallen.
Ausfallkapazität. Dimensionieren Sie die Reservekapazität oder einen alternativen Pfad basierend auf dem Verfügbarkeitsziel und den getesteten Ausfallszenarien; jeder Beschleuniger kann ausfallen, aber dedizierte, im Leerlauf befindliche Hardware ist nicht das einzige Design.
Mehrere Regionen. Replizieren Sie für weltweite Nutzer oder verwenden Sie für weiter entfernte Regionen verwaltete APIs.
Aktualisierungsstrategie. Neue Modellversionen, Server-Upgrades. Blue-Green-Deployments zur Vermeidung von Ausfallzeiten.
Diese Aufgaben übernimmt bei verwalteten APIs der Anbieter.
Zwei Entscheidungsprotokolle, die Sie erstellen sollten
Erfinden Sie kein anonymisiertes Ergebnis. Erstellen Sie überprüfbare Entscheidungsprotokolle aus aktuellen Angeboten und Benchmark-Artefakten.
Protokoll für den Self-Hosting-Kandidaten:
- Modell-Artefakt, Revision, Lizenz, Quantisierung, Serving-Version, Beschleuniger, Region und Deployment-Topologie,
- Lastverteilung und Qualitätsbewertung im Vergleich zur aktuellen gehosteten Basislinie,
- Lasttest-Befehl, Datensatz, Latenz-/Durchsatzergebnisse, Sättigungspunkt und Wiederherstellungsverhalten,
- Kapitalkosten oder Mietkosten, Auslastung, Engineering-Aufwand, Sicherheitsmaßnahmen und erwartete Incident-Kosten,
- Break-even-Spanne mit Sensitivitätsanalyse und Ausstiegskriterium.
Protokoll für den verwalteten Kandidaten:
- Anbieter, Modell-/Revisionsverhalten, Region, Preisliste-Datum, Kontingente und Vertragsbedingungen,
- äquivalente Belege zu Qualität, Latenz, Rate-Limits, Ausfällen und Datengrenzen,
- Migrationsaufwand und Konzentrationsrisiko bei einem Anbieter,
- Umstände, die eine erneute Bewertung von Self-Hosting auslösen würden.
Wann die Entscheidung überprüft werden sollte
Die Entscheidung ist nicht endgültig. Überprüfen Sie regelmäßig:
Volumenänderungen. Bei einem deutlichen Anstieg wird Self-Hosting attraktiver, bei einem deutlichen Rückgang weniger attraktiv.
Preisänderungen. APIs für geschlossene Modelle, verwaltete Open-Weight-Angebote und Hardware werden günstiger oder teurer.
Modellverbesserungen. Neue Open-Weight- oder quellverfügbare Kandidaten, die das Arbeitslastziel erfüllen, oder neue geschlossene Modelle, die den Qualitätsvergleich verändern. Prüfen Sie Lizenzen und tatsächliche Verfügbarkeit.
Operative Kapazität. Das Team hat seine Fähigkeiten im Bereich Machine Learning und Operations erweitert oder reduziert.
Änderungen bei Datenschutz oder Compliance. Neue Anforderungen, die Self-Hosting vorschreiben.
Legen Sie einen Überprüfungszyklus fest, der auf Volatilität in Bezug auf Vertrag, Preis, Modell, Arbeitslast, Sicherheit und Kapazität basiert, und fügen Sie ereignisgesteuerte Auslöser hinzu. Eine vierteljährliche Überprüfung ist ein Beispiel, keine universelle Vorgabe.
Häufige Fehler
Typische Muster bei Entscheidungen zum Self-Hosting:
Fehler 1: Kostenrechnung ohne Betriebskosten. Einsparungen bei Tokens oder Beschleunigern werden ausgewiesen, während Engineering-, On-Call-, Sicherheits- und Incident-Kosten nicht berücksichtigt werden.
Fehler 2: Zu frühes Self-Hosting. Bei geringer Arbeitslast wird Entwicklungskapazität für Self-Hosting aufgewendet. Das ist vorzeitige Optimierung.
Fehler 3: Vergleich nicht äquivalenter Qualität. Es wird ein kostengünstigeres Modell ausgewählt, ohne nachzuweisen, dass es die Qualitäts-, Sicherheits- und Latenzanforderungen der Arbeitslast erfüllt.
Fehler 4: Kein Ausfallplan. Die selbst gehostete Infrastruktur fällt aus, doch es gibt keinen getesteten Pfad für Degradation, Warteschlange, Ablehnung oder Fallback. Auch verwaltete APIs können ausfallen; vergleichen Sie beide Architekturen anhand desselben Verfügbarkeitsziels.
Fehler 5: Die Annahme, dass die erste Serving-Konfiguration effizient ist. Es wird kein reproduzierbarer Sweep über unterstützte Quantisierung, Batching, Parallelität, Prompt-Längen und Servereinstellungen durchgeführt, sodass das Kapazitätsmodell auf einer nicht verifizierten Konfiguration beruht.
Fehler 6: Qualitätsdrift ignorieren. Das selbst gehostete Modell liefert inzwischen schlechtere Ergebnisse als das aktuelle geschlossene Modell. Kunden bemerken es, das Team jedoch nicht.
Fehler 7: Die Entscheidung nicht erneut prüfen. Nach der Einführung von Self-Hosting wird die Entscheidung nie wieder bewertet. Sie kann vor zwei Jahren richtig und heute falsch gewesen sein.
Fehler 8: Spot-/Preemptible-Instanzen ohne geordnete Behandlung. Ermäßigte Kapazität wird modelliert, ohne Unterbrechungshäufigkeit, Wiederherstellungszeit, doppelte Arbeit oder Fallback-Kosten zu berücksichtigen.
Eine Checkliste für Entscheidungen
Um die Entscheidung bewusst zu treffen:
- Wurden qualitätsäquivalente gehostete und selbst gehostete Kandidaten bewertet?
- Ist die Auslastung stabil und vorhersehbar?
- Verfügt das Team über MLOps-/Inferenz-Expertise oder kann es sie einstellen?
- Existiert ein entsprechend lizenziertes Open-Weight- oder Source-Available-Modell, das die Qualitäts- und Sicherheitsziele der Arbeitslast erfüllt?
- Sind die Latenzanforderungen mit Self-Hosting kompatibel?
- Haben Sie die detaillierten Kostenkalkulationen einschließlich der Betriebskosten durchgeführt?
- Haben Sie einen Fallback-Plan?
- Schreiben Compliance- oder Datenschutzanforderungen keinen bestimmten Weg zwingend vor?
- Gibt es einen dokumentierten Überprüfungszyklus und ereignisgesteuerte Auslöser für wesentliche Änderungen am Modell, Preis, Vertrag, Arbeitsaufkommen, der Sicherheit oder der Kapazität?
Reduzieren Sie dies nicht auf eine einfache Checkbox-Prüfung. Sicherheit, Modellqualität oder die operative Verantwortung können ein Veto ausüben, selbst wenn alle finanziellen Eingaben günstig erscheinen.
Hybride Muster
Es ist keine Entweder-oder-Frage. Zu den potenziellen hybriden Mustern gehören:
Self-Hosting für die Hauptlast, APIs für schwierige Fälle. Klassifizierung und einfache Generierung laufen in der eigenen Umgebung, komplexe Schlussfolgerungen über APIs für geschlossene Modelle.
Self-Hosting für die Grundlast, APIs für Spitzen. Die eigene Umgebung bewältigt die Grundlast, APIs fangen Lastspitzen ab.
Self-Hosting für sensible Daten, APIs für allgemeine Anfragen. Sensible Daten werden in der eigenen Umgebung verarbeitet, allgemeine Anfragen über APIs.
Self-Hosting für Fine-Tunings, APIs für Basismodelle. Eigene Modelle betreiben Sie selbst; Standardmodelle beziehen Sie über APIs.
Hybrid-Architekturen erhöhen die Komplexität in den Bereichen Routing, Datenrichtlinien, Evaluierung, Observability, Verträge und Fehlerbehandlung. Setzen Sie sie nur ein, wenn Tests nachweisen, dass die Aufteilung ein explizites Ziel verbessert.
Entscheiden Sie auf Grundlage aktueller Nachweise
Self-Hosting ist eine tragfähige Architektur, wenn ein unterstütztes Modell das Qualitätsziel der Arbeitslast erfüllt und die Organisation den Serving-Lebenszyklus selbst verantworten kann.
Der Break-even-Punkt ist keine allgemeingültige monatliche Ausgabenschwelle. Er verändert sich mit Modellqualität, Nachfrageverlauf, Auslastung, Preisen und Verfügbarkeit von Beschleunigern und Anbietern, Anforderungen an die Datenabgrenzung sowie Personalkosten.
Nachweise für eine Entscheidung zugunsten einer selbst gehosteten Lösung sollten Folgendes zeigen:
- Die Berechnungen wurden sorgfältig durchgeführt, einschließlich der Betriebskosten.
- MLOps-Kapazität ist vorhanden oder aufbaubar.
- Der Betrieb erfolgt in ausreichendem Maßstab, um die Investition zu rechtfertigen.
- Die Arbeitslasten sind stabil.
- Es werden keine Funktionen benötigt, die es ausschließlich bei Frontier-Modellen gibt.
- Zuverlässigkeit, Überwachung und Updates sind eingeplant.
Für einen verwalteten Dienst können folgende Anhaltspunkte sprechen:
- Geringerer Umfang.
- Unregelmäßige Arbeitslasten.
- Schnelle Iteration ist erforderlich.
- Kleine Teams ohne Operations-Kapazität.
- Es werden Funktionen benötigt, die nur geschlossene Spitzenmodelle bieten.
Die richtige Antwort hängt von der konkreten Arbeitslast ab. Vergleichen Sie Qualität, Lastverhalten, Ausfälle, Sicherheit und Kosten und bewerten Sie die betriebliche Kapazität. Bevorzugen Sie die Option mit der geringsten Eigenverantwortung, die alle zwingenden Anforderungen erfüllt. Das kann ein verwalteter Dienst, Self-Hosting oder eine Hybridlösung sein.
Wenn Sie Self-Hosting wählen, dokumentieren Sie den gemessenen Nutzen, die Annahmen, die verantwortliche Person, die Ausstiegskriterien und den nächsten Überprüfungsauslöser. Gehen Sie bei verwalteter Inferenz ebenso vor; keiner der beiden Wege ist ohne aktuelle Nachweise richtig.
