Switchyard vs LiteLLM vs Portkey: AI-Gateway-Vergleich 2026

Ein Coding Agent liefert wechselnde Ergebnisse, weil jede Anwendung eigene API-Adapter, Schlüsselverwaltung und Fallback-Regeln pflegt.

Die schnellste Entscheidung im AI-Gateway-Vergleich 2026 lautet: Für lokale Coding Agents und Stufenrouting sollte zuerst Switchyard geprüft werden, für breite Modell- und Anbieterkompatibilität LiteLLM, für eine verwaltete Kontrolloberfläche mit Governance und Observability Portkey.

Zu dieser Entscheidung passt der Artikel besonders für:

• Teams, die mehrere Modelle über eine einheitliche API in einer AI-Anwendung nutzen möchten.
• Plattformingenieure, die Modellschlüssel, Fallbacks, Budgets und Nutzungsprotokolle zentral verwalten müssen.
• Entwicklungsteams, die Claude Code oder vergleichbare Coding Agents mit unterschiedlichen Backends verbinden wollen.

Letzte Aktualisierung: 14.08.2026. Die Funktionsangaben wurden anhand der offiziellen Repositories und Dokumentationen von Switchyard, LiteLLM und Portkey geprüft.

Die drei Gateways zunächst nach ihrer eigentlichen Aufgabe einordnen

Ein AI Gateway ist nicht nur ein Proxy, der eine Chat-Anfrage von einer API zu einer anderen weiterleitet. Für eine belastbare Produktionsentscheidung müssen mindestens sechs Ebenen getrennt betrachtet werden:

1. Protokollkompatibilität: Unterstützt das Gateway OpenAI Chat Completions, OpenAI Responses und Anthropic Messages, oder wird nur ein einfacher Chat-Aufruf übersetzt?
2. Modell- und Backend-Abdeckung: Können verwaltete Anbieter, private Endpunkte, vLLM, Ollama oder andere lokale Inferenzsysteme angebunden werden?
3. Routing und Rückfalllogik: Wird nach Modellname, Anwendung, Gesprächsphase, Fehlerart oder Inhalt geroutet?
4. Zugriffs- und Kostensteuerung: Lassen sich virtuelle Schlüssel, Teams, Projekte, Budgets und Rate Limits voneinander trennen?
5. Betriebsbeobachtung: Werden Latenz, Tokenverbrauch, Fehlertyp, Routing-Entscheidung und sensible Inhalte angemessen behandelt?
6. Wartungsaufwand: Wie viel Arbeit entsteht bei Installation, Konfigurationsänderung, Upgrade, Rollback und Datenschutzprüfung?

Switchyard ist derzeit ausdrücklich als experimentelle Software mit Vorab-Reifegrad gekennzeichnet und laut Projektseite nicht für den Produktionseinsatz vorgesehen. Die Stärke liegt in einer eng umrissenen Routing-Schicht: Rust-basierter Proxy, Übersetzung zwischen mehreren LLM-Protokollen, Prometheus-Metriken und anpassbare Routing-Algorithmen. Offizielles Switchyard-Repository

LiteLLM ist breiter als SDK und Proxy-Plattform angelegt. Die offizielle Dokumentation beschreibt sowohl ein Python-SDK als auch einen zentralen Proxy mit Authentifizierung, virtuellen Schlüsseln, Kostenverfolgung, Budgets, Logging und Fallbacks. Offizielle LiteLLM-Dokumentation

Portkey verbindet ein Open-Source-Gateway mit einer kommerziellen beziehungsweise verwalteten Plattform. Die Dokumentation nennt unter anderem universelle APIs, bedingtes Routing, Fallbacks, Wiederholungen, Load Balancing, Caching, Budgetgrenzen, Guardrails und eigene Hosts. Die aktuelle Dokumentation weist außerdem auf eine Umbenennung beziehungsweise Integration in „PRISMA AIRS AI Gateway“ hin. Das sollte vor einer Einführung im Einkauf und in der Betriebsdokumentation geklärt werden. Offizielle Portkey-Gateway-Dokumentation

Erster Prüfpunkt: API-Kompatibilität statt einfacher Chat-Demo

Eine einfache Anfrage mit messages, model und stream beweist noch keine zuverlässige Kompatibilität. Coding Agents verwenden häufig Tool-Aufrufe, strukturierte Antworten, Streaming-Ereignisse, Systemanweisungen und anbieterspezifische Felder. Ein Gateway kann deshalb bei einer kurzen Chat-Demo funktionieren, aber beim ersten Tool-Resultat oder bei einem Streaming-Fehler ausfallen.

Switchyard nennt ausdrücklich die Übersetzung zwischen OpenAI Chat Completions, OpenAI Responses und Anthropic Messages. Die Architektur sieht vor, dass der Client sein natives Format beibehält, während Switchyard das ausgewählte Backend in dessen erwartetes Format anspricht. Das ist besonders relevant für Claude Code, wenn der Agent nicht direkt gegen ein Anthropic-Backend, sondern gegen einen OpenAI-kompatiblen Dienst, vLLM, NVIDIA NIM oder Ollama arbeiten soll. Die genannten Protokollpfade sind in der offiziellen Projektbeschreibung dokumentiert.

LiteLLM stellt nach eigener Dokumentation eine einheitliche OpenAI-kompatible Schnittstelle bereit und unterstützt neben Chat-Aufrufen auch Responses, Embeddings, Bilder, Audio und Batch-Endpunkte. Die Dokumentation nennt zudem Streaming, OpenAI-kompatible Fehlerbehandlung und Integrationen mit mehreren Beobachtungsdiensten. Diese Breite ist ein Vorteil, wenn eine Plattform nicht nur Coding Agents, sondern auch Embeddings, Sprachmodelle oder multimodale Anwendungen versorgen soll.

Portkey bietet ebenfalls eine universelle API sowie SDK- und REST-Zugänge. Die offizielle Funktionsübersicht nennt Streaming, Function Calling, multimodale Modelle, eigene Host-URLs und weitere Provider-Pfade. Für Teams mit mehreren Agent-Frameworks sind zusätzlich dokumentierte Integrationen mit unter anderem AutoGen, CrewAI, LangChain und LlamaIndex relevant. Portkey-Gateway auf GitHub

Welche Lösung ist für Claude Code am sinnvollsten?

Für Claude Code sollte Switchyard zuerst geprüft werden, wenn der Hauptbedarf darin besteht, die native Agent-Schnittstelle zu bewahren und Anfragen anhand von Gesprächssignalen, Tool-Ergebnissen oder Fehlern zwischen Modellstufen zu verteilen. LiteLLM ist die bessere erste Prüfung, wenn neben Claude Code viele Anbieter, private Endpunkte und unterschiedliche API-Pfade vereinheitlicht werden sollen. Portkey kommt infrage, wenn zusätzlich eine verwaltete Kontrolloberfläche, zentrale Richtlinien und eine gemeinsame Beobachtungsschicht benötigt werden.

Zweiter Prüfpunkt: Anbieter- und Backend-Abdeckung realistisch bewerten

Die Modellabdeckung darf nicht anhand einer Marketingliste beurteilt werden. Entscheidend ist, ob ein konkreter Backend-Typ mit den benötigten Parametern, Tool-Aufrufen, Streaming-Formaten und Fehlercodes unterstützt wird.

Entscheidungsdimension	Switchyard	LiteLLM	Portkey
Verwaltete Modellanbieter	Konfigurierte Ziele, projektseitige Pflege erforderlich	Breite Provider-Abstraktion über SDK und Proxy	Breite Provider-Anbindung über universelle API und Plattform
Private Endpunkte	Für OpenAI-kompatible und dokumentierte Backend-Ziele geeignet	Private und selbst gehostete Modelle über konfigurierte Endpunkte	Eigene Hosts und private Modellziele dokumentiert
Lokale Inferenz	vLLM, NVIDIA NIM, Ollama und OpenAI-kompatible Ziele werden im Projekt beschrieben	Ollama und weitere Backend-Typen dokumentiert	Lokale und eigene Hosts über Gateway-Konfiguration
Native Agent-Protokolle	OpenAI Chat, OpenAI Responses und Anthropic Messages	OpenAI-kompatible Vereinheitlichung sowie weitere SDK-Pfade	Universelle API, SDKs und Agent-Integrationen
Wartungsgrenze	Pre-Alpha; Änderungen vor Version 1.0 möglich	Größere Plattform mit vielen Integrationspunkten	Open-Source-Gateway und getrennte verwaltete beziehungsweise Enterprise-Funktionen

Die Tabelle zeigt einen wichtigen Unterschied: Switchyard ist kein vollständiger Ersatz für jede Governance- und Providerplattform. Es ist eher eine Routing- und Übersetzungsschicht, die sich in einen vorhandenen Agent- oder Proxy-Aufbau einfügen kann. Die Bibliotheksvariante entscheidet über das Ziel, führt aber laut Projektbeschreibung nicht automatisch selbst den Modellaufruf aus.

LiteLLM eignet sich stärker als zentrale Plattform für mehrere Teams, wenn dieselbe Schnittstelle für Cloudmodelle, interne Modelle und lokale Backends benötigt wird. Die dynamische Providerliste sollte immer aus der aktuellen Dokumentation geprüft werden; Community-Adapter dürfen nicht automatisch als langfristig gepflegte Kernfunktion bewertet werden.

Portkey ist interessant, wenn eine Organisation neben Modellverbindungen auch MCP-Server, Agent-Aufrufe, Guardrails und Zugriffsrichtlinien in einer gemeinsamen Schicht verwalten möchte. Die Enterprise- und Hosted-Funktionen müssen dabei getrennt von der frei verfügbaren Gateway-Komponente betrachtet werden.

Dritter Prüfpunkt: Routing, Rückfall und Zuverlässigkeit anhand von Fehlern testen

Wie lassen sich Modellrückfall und Routing in einem AI Gateway sinnvoll umsetzen?

Zuerst muss festgelegt werden, welcher Fehler überhaupt einen Rückfall auslösen darf. Ein Timeout, ein Rate Limit oder ein temporärer Providerfehler kann einen Wechsel rechtfertigen. Ein Kontextfensterfehler, ein ungültiger Tool-Aufruf oder eine inhaltlich schlechte Antwort lässt sich dagegen nicht immer durch einen bloßen Providerwechsel beheben.

Switchyard dokumentiert mehrere Routing-Strategien:

• Random Routing für feste Traffic-Aufteilungen und A/B-Vergleiche.
• LLM-Classifier-Routing, wenn der Anfrageinhalt zwischen Modellstufen entscheidet.
• Stage Router, wenn bereits vorhandene Signale aus Tool-Ergebnissen oder Fehlern die nächste Modellstufe bestimmen.
• Escalation Routing, bei dem eine Anfrage zunächst an ein schwächeres Modell geht und bei Bedarf auf ein stärkeres Modell eskaliert.
• Passthrough, wenn keine Routing-Entscheidung erforderlich ist.

Diese Strategien sind für Coding Agents besonders interessant, weil Agent-Aufgaben häufig in Phasen zerfallen: Planung, Dateisuche, Implementierung, Testauswertung und Fehlerbehebung. Ein Stage Router kann solche Signale nutzen, ohne für jede Anfrage einen zusätzlichen Klassifikator aufzurufen. Das bedeutet jedoch nicht automatisch, dass die Ergebnisse besser oder günstiger werden. Die Qualität muss mit realen Repository-Aufgaben geprüft werden.

LiteLLM bietet mit seinem Router Wiederholungs- und Fallback-Logik über mehrere Deployments. Damit ist es für klassische Provider-Ausfälle und Lastverteilung gut geeignet. Bei komplexen Inhalts- oder Phasenregeln muss die Plattform jedoch prüfen, ob die Entscheidung in LiteLLM, im Agenten oder in einer zusätzlichen Policy-Schicht liegen soll. LiteLLM-Router und Fallback-Dokumentation

Portkey dokumentiert Fallbacks, automatische Wiederholungen, Circuit Breaker, Load Balancing, Timeouts und bedingtes Routing. Die Bedingungen können beispielsweise auf Metadaten wie Nutzergruppe, Umgebung oder Region basieren. Das ist für Governance-Szenarien nützlich, darf aber nicht mit einer Qualitätsbewertung der Modellantwort verwechselt werden. Portkey: Conditional Routing

Hinweis: Ein Fallback, der bei jedem Fehler auf das teuerste Modell wechselt, verbessert möglicherweise die Verfügbarkeit, kann aber Budgetgrenzen, Antwortlatenz und Datenschutzanforderungen verschlechtern. Vor dem Produktionswechsel müssen Fehlerklassen, Abbruchbedingungen und maximale Versuchszahlen schriftlich festgelegt werden.

Vierter Prüfpunkt: Schlüssel, Budgets und Zugriffsrechte voneinander trennen

Die drei Lösungen unterscheiden sich weniger bei der Existenz eines API-Schlüssels als bei der organisatorischen Tiefe der Verwaltung.

Bei Switchyard liegt die Verantwortung stärker bei der bereitstellenden Umgebung. Die Konfiguration definiert Ziele und Routen; eine umfassende Team-, Projekt- oder Budgetverwaltung ist aus der Projektbeschreibung nicht als gleichwertiger Plattformumfang ersichtlich. Für einen lokalen Coding-Agent-Proxy kann das ausreichend sein. Für ein internes Gateway mit vielen Abteilungen müssen Schlüsselverwaltung, Secret Manager, Auditierung und Budgetkontrolle wahrscheinlich ergänzt werden.

LiteLLM beschreibt für den Proxy virtuelle Schlüssel, Authentifizierung und Autorisierung, Kostenverfolgung nach Projekt oder Nutzer, Budgets und Rate Limits. Damit kann ein Plattformteam den Anbieterzugang zentralisieren, ohne jedem Entwickler die echten Provider-Schlüssel zu geben. Die konkrete Verfügbarkeit einzelner Verwaltungsfunktionen muss nach der eingesetzten Edition und dem aktuellen Release geprüft werden.

Portkey nennt sichere Schlüsselverwaltung, virtuelle Schlüssel, rollenbasierte Zugriffssteuerung und Budget- beziehungsweise Tokenlimits. Die Enterprise-Funktionen, Hosted-Angebote und Open-Source-Gateway-Funktionen dürfen nicht in einer gemeinsamen Vergleichszeile zusammengefasst werden. Für eine DSGVO-Prüfung sind außerdem Datenresidenz, Protokollaufbewahrung, PII-Redaktion und die Frage entscheidend, ob Prompts beziehungsweise Tool-Parameter an einen verwalteten Dienst übertragen werden.

Fünfter Prüfpunkt: Logs müssen Routing-Gründe und Datenschutz sichtbar machen

Eine hübsche Übersicht über Token und Kosten reicht nicht. Für die Fehlersuche werden mindestens folgende Felder benötigt:

• angeforderte Modell-ID und tatsächlich gewähltes Ziel,
• Routing-Regel oder Routing-Grund,
• Provider- und HTTP-Fehler,
• Startzeit, Endzeit und Zeitüberschreitungen,
• Prompt- und Completion-Token, sofern die Daten zuverlässig verfügbar sind,
• Tool-Aufrufe und Streaming-Abbrüche,
• Fallback-Kette sowie endgültiger Antwortstatus,
• Redaktionsstatus sensibler Inhalte.

Switchyard nennt Prometheus-Metriken für Anfragen, Fehler, Latenz, Token und Routing-Overhead. Das ist eine gute technische Basis für eine bestehende Monitoringlandschaft, ersetzt aber keine vollständige Governance-Oberfläche.

LiteLLM bietet laut Dokumentation Logging- und Observability-Anbindungen sowie Kosten- und Latenzverfolgung. Für eine zentrale Plattform ist wichtig, dass nicht nur die Antwort, sondern auch die Zuordnung zu Projekt, Nutzer oder virtuellem Schlüssel nachvollziehbar bleibt.

Portkey positioniert Observability, Guardrails und Governance als zusammengehörige Plattformfunktionen. Die Dokumentation nennt Logs, Tracing, Schlüsselverwaltung, rollenbasierte Rechte und Datenschutzfunktionen. Vor dem Einsatz in einer produktiven Umgebung sollten Teams jedoch prüfen, welche Daten standardmäßig gespeichert werden, wie lange sie verfügbar bleiben und ob sensible Tool-Argumente maskiert werden.

Sechster Prüfpunkt: Self-Hosting nicht mit geringerem Gesamtaufwand verwechseln

Betriebsmodell	Vorteile	Typische Belastungen
Switchyard selbst betreiben	Kontrollierbare Routing-Schicht, lokale Konfiguration, Rust-Bibliothek für eigene Laufzeiten	Pre-Alpha-Reife, eigene Absicherung, eigenes Monitoring und manuelle Versionsprüfung
LiteLLM selbst betreiben	Zentrale Proxy-Funktion, breite Anbieteranbindung, virtuelle Schlüssel und Kostenverwaltung	Mehr Konfigurationsfläche, Secret-Management, Release- und Sicherheitsprüfung
Portkey-Gateway selbst betreiben	Lokaler Start möglich, Gateway-Konfigurationen und lokale Logs	Abgrenzung zwischen Open Source, Hosted und Enterprise; zusätzliche Plattformkomponenten für Governance
Verwaltete Gateway-Plattform	Weniger eigene Betriebsarbeit, zentrale Oberfläche und Richtlinien	Datenübertragung, Anbieterabhängigkeit, Vertrags- und Datenschutzprüfung

Switchyard kann laut offizieller Anleitung als Server installiert oder als Bibliothek in eine Rust-Anwendung eingebettet werden. Der Server wird mit einer TOML-Konfiguration gestartet und stellt einen Health-Endpunkt bereit. Das ist für isolierte Entwicklungsumgebungen attraktiv, verlangt aber eine eigene Strategie für Secrets, TLS, Netzwerkzugriff und Prozessüberwachung.

LiteLLM lässt sich als Proxy installieren und über Konfigurationsdateien oder Container betreiben. Die Plattform ist funktional umfangreicher, wodurch auch die Zahl der möglichen Fehlkonfigurationen steigt. Für jede neue Provideranbindung sollten Streaming, Tool Calls, strukturierte Ausgaben und Fehlerrückgaben separat getestet werden.

Portkey beschreibt einen lokalen Start über npx und stellt zusätzlich verschiedene Deploymentpfade für private Umgebungen bereit. Die lokale Ausführung eines Gateways bedeutet nicht automatisch, dass alle Hosted-Observability- oder Enterprise-Funktionen lokal verfügbar sind. Diese Grenze muss vor der Architekturentscheidung schriftlich bestätigt werden.

Die Auswahl für drei typische Teamtypen treffen

Persönlicher Coding Agent oder kleines Entwicklungsteam

Wenn primär Claude Code, Codex oder ein ähnlicher Agent mit unterschiedlichen Backends verbunden werden soll, ist Switchyard die naheliegende erste Evaluierung. Native OpenAI- und Anthropic-Formate, Stage Routing und die Möglichkeit, Routinglogik als Bibliothek einzubetten, passen zu diesem Szenario.

Die Einschränkung ist entscheidend: Wegen des dokumentierten Pre-Alpha-Status sollte Switchyard zunächst in einer isolierten Entwicklungsumgebung laufen. Ein produktiver Einsatz ohne eigene Regressionstests wäre nicht vertretbar.

LiteLLM ist für dieses Team sinnvoller, wenn bereits mehrere Provider verwendet werden oder später eine gemeinsame Schlüssel- und Kostenverwaltung entstehen soll. Portkey lohnt sich, wenn eine verwaltete Oberfläche wichtiger ist als maximale Kontrolle über die lokale Routing-Schicht.

Schnell wachsendes AI-Anwendungsprojekt

Für ein wachsendes Produkt sollte LiteLLM zuerst geprüft werden, wenn mehrere Anbieter, private Endpunkte, Kostenkontrolle und eine einheitliche API im Vordergrund stehen. Die Lösung deckt mehr Integrationsfälle ab und kann als zentrale Proxy-Schicht für mehrere Anwendungen dienen.

Portkey ist die bessere Kandidatenlösung, wenn neben dem Gateway auch Guardrails, Agent-Integrationen, Observability und Governance möglichst eng zusammenarbeiten sollen. Die Plattformkosten und die Datenverarbeitung müssen dabei in die Gesamtkostenrechnung aufgenommen werden; eine reine API-Kompatibilitätsprüfung genügt nicht.

Switchyard kann als spezialisierte Routing-Komponente interessant bleiben, sollte aber nicht ohne Weiteres als vollständiger Ersatz für Authentifizierung, Teamverwaltung und Compliance-Kontrollen eingeplant werden.

Unternehmensweite AI-Plattform

Für eine Unternehmensplattform sollte Portkey evaluiert werden, wenn zentrale Richtlinien, Rollen, Observability, Guardrails und verwaltete Betriebsabläufe im Vordergrund stehen. LiteLLM bleibt eine starke Alternative, wenn das Plattformteam Self-Hosting bevorzugt und die Governance-Funktionen selbst kontrollieren möchte.

Switchyard ist in diesem Szenario eher ein Baustein für eine eigene Plattformarchitektur. Das kann sinnvoll sein, wenn ein Team die Routingalgorithmen selbst entwickeln und die übrige Kontrollschicht bereits besitzt. Als alleinige Gateway-Lösung ist der aktuelle Reifegrad jedoch ein klares Ausschlusskriterium für viele produktive Unternehmensumgebungen.

Vor dem Produktionswechsel diese Abnahme durchführen

1. Reale Clients festlegen: Nicht nur curl, sondern den tatsächlichen Coding Agent, das SDK und die verwendeten Agent-Frameworks testen.
2. Reale Backends anschließen: Mindestens ein verwalteter Anbieter, ein privater Endpunkt und, falls vorgesehen, ein lokales Inferenzbackend.
3. Protokollfälle prüfen: Streaming, Tool Calls, strukturierte Ausgaben, lange Kontexte und anbieterspezifische Felder separat abnehmen.
4. Fehler injizieren: Rate Limit, Timeout, ungültige Antwort, Providerfehler und Kontextüberschreitung getrennt simulieren.
5. Routing protokollieren: Für jede Anfrage muss nachvollziehbar sein, warum ein Ziel ausgewählt oder ein Fallback ausgelöst wurde.
6. Datenschutz prüfen: Prompt-Inhalte, Tool-Parameter, Nutzerkennungen, Aufbewahrungsdauer und Redaktionsregeln dokumentieren.
7. Betrieb testen: Upgrade, Rollback, Secret-Rotation, Neustart, Health Checks und Wiederherstellung aus der Konfiguration durchführen.
8. Qualität vergleichen: Nicht nur Verfügbarkeit messen, sondern auch Tool-Erfolgsrate, Testresultate, Antwortqualität und Kosten je Aufgabenklasse.
9. Kleinen Traffic-Anteil freigeben: Erst nach erfolgreicher Abnahme darf ein begrenzter Produktionsanteil über das neue Gateway laufen.
10. Rückfallplan erhalten: Die bisherige Modellroute muss so lange aktiv bleiben, bis Fehlerbilder und Protokollabweichungen ausgeschlossen sind.

Für Teams, die diese Tests nicht auf dem eigenen Rechner durchführen möchten, kann eine isolierte Mac-Entwicklungsumgebung für reproduzierbare Agent-, Proxy- und Backend-Tests sinnvoll sein. Bei geografisch getrennten Teams kann zusätzlich ein Mac-Standort an der US-Ostküste geprüft werden, sofern Latenz und Datenschutzanforderungen dazu passen.

Klare Entscheidung für den AI-Gateway-Vergleich 2026

Switchyard sollte gewählt werden, wenn lokales Coding-Agent-Proxying, native Agent-Protokolle und signalbasiertes Stufenrouting die wichtigsten Kriterien sind und das Team den experimentellen Reifegrad akzeptiert.

LiteLLM sollte gewählt werden, wenn eine breite Anbieter- und Backend-Kompatibilität, zentrale virtuelle Schlüssel, Kostenverfolgung und klassische Fallback- beziehungsweise Load-Balancing-Szenarien im Mittelpunkt stehen.

Portkey sollte gewählt werden, wenn eine verwaltete Kontrolloberfläche, Observability, Guardrails, Agent-Integrationen und Governance-Workflows wichtiger sind als eine möglichst schlanke eigene Routing-Schicht. Bei Portkey muss die Trennung zwischen Open-Source-Gateway, Hosted-Dienst und Enterprise-Funktionen besonders sorgfältig dokumentiert werden.

Ein bisheriger Aufbau aus individuellen SDK-Adaptern, verstreuten Provider-Schlüsseln und selbst geschriebenen Wiederholungsregeln hat in der Praxis drei Nachteile: Routing-Entscheidungen sind schwer zu auditieren, Fallbacks werden häufig ohne Qualitätsprüfung ausgelöst, und sensible Nutzungsdaten liegen in mehreren Logs und Anwendungen. Für kurzfristige Evaluierungen kann ein gemieteter Mac von nuvcloud deshalb eine kontrolliertere Umgebung bieten, in der Gateway-Konfiguration, Agent-Client und Fehlerfälle getrennt getestet werden, ohne sofort eigene Hardware für jeden Entwickler bereitzustellen. Für dauerhaft hohe Last, physische Netzwerk- oder GPU-Anforderungen und langfristig stabile Produktionssysteme bleibt eine eigene Infrastruktur jedoch die ehrlichere Wahl.