MCP Gateway vs. LLM Gateway: Verwechsle sie nicht
Die kurze Antwort: Ein LLM Gateway sitzt zwischen deiner Anwendung und den Modell-Anbietern und routet und regelt Modell-API-Aufrufe. Ein MCP Gateway sitzt zwischen deinem Agenten und seinen Tools und routet und regelt Tool-Aufrufe. Beide heißen im Marketing "AI Gateway", mehrere Anbieter verkaufen beides in einem Produkt, und Käufer evaluieren regelmäßig das eine, wenn sie das andere brauchen. Zehn Minuten hier sparen dieses Meeting.
Was ein LLM Gateway tut
Ein LLM Gateway ist ein Proxy für Modell-Verkehr. Deine Apps rufen eine API auf, und das Gateway leitet an OpenAI, Anthropic, Gemini oder eigene gehostete Modelle dahinter weiter. Der Wert ist Bündelung und Kontrolle auf der Modell-Seite:
- Eine API-Oberfläche für viele Anbieter, Modellwechsel heißt nicht Apps umschreiben
- Routing und Failover (diese Arbeitslast an jenes Modell, Ausweichen bei Ausfall)
- Kosten-Kontrolle: Budgets pro Team, Rate Limits, Nutzungs-Analytik pro Key
- Caching wiederholter Prompts, Logging der Requests
Etablierte Beispiele sind LiteLLMs Proxy und die LLM-Seiten von Kongs AI Gateway und agentgateway. Die Arbeitseinheit ist ein Modell-Request: Prompt rein, Completion raus.
Was ein MCP Gateway tut
Ein [MCP Gateway](/de/blog/what-is-an-mcp-gateway) ist ein Proxy für Tool-Verkehr. Dein Agent verbindet sich mit einem MCP-Endpunkt, und dahinter bündelt das Gateway viele MCP-Server: verschmolzener Tool-Katalog mit Namespaces, vermittelte Zugangsdaten pro Upstream, Widerruf pro Verbindung, ein Audit-Trail dessen, was der Agent getan hat. Die Arbeitseinheit ist ein Tool-Aufruf: Der Agent ruft crm__search_contacts auf, das Gateway routet ihn mit dem richtigen Token zum Server des CRM, das Ergebnis kommt zurück.
Andere Schicht, andere Risiken, andere Käufer-Fragen. Ein LLM Gateway beantwortet "welche Modelle rufen wir auf und was kostet es?". Ein MCP Gateway beantwortet "welche Systeme dürfen unsere Agenten anfassen, mit wessen Zugangsdaten, und was haben sie getan?".
Die Tabelle zum Auseinanderhalten
| LLM Gateway | MCP Gateway | |
|---|---|---|
| Sitzt zwischen | Deinen Apps und Modell-APIs | Deinen Agenten und ihren Tools |
| Regelt | Modell-Requests (Prompts, Completions) | Tool-Aufrufe (Aktionen auf echten Systemen) |
| Typische Features | Routing, Failover, Caching, Ausgaben-Limits | Federation, Credential-Vault, Widerruf, Audit |
| Kosten-Hebel | Modellwahl, Caching, Budgets | Tool-Schema-Last, und (selten) Memory |
| Verhinderter Schaden | Anbieter-Ausfall, entlaufene Modell-Ausgaben | Credential-Wildwuchs, unbelegbare Agenten-Aktionen |
| Beispiele | LiteLLM-Proxy, Kong AI Gateway (LLM-Seite) | Docker MCP Gateway, IBM ContextForge, Tulimoa |
Warum die Verwirrung existiert
Drei Gründe, alle im Markt 2026 beobachtbar.
Anbieter machen beides unter einem Namen. Kong regelt "LLM-, MCP- und Agent-zu-Agent-Verkehr mit demselben Kong AI Gateway". LiteLLM hat MCP-Governance in seinen LLM-Proxy eingebaut. agentgateway wirbt mit "einem Hochleistungs-Gateway für Service-, LLM- und MCP-Verkehr". Echte Produkte, bewusst konvergiert, und der Sammelbegriff "AI Gateway" bügelt den Unterschied platt.
Namen führen in die Irre. Glama, bekannt für sein MCP-Server-Verzeichnis, verkauft ein "Gateway", das ein OpenAI-kompatibles LLM Gateway ist (Modell-Zugang, Kosten-Analytik, Prompt-Caching), kein MCP Gateway. Am Produkt ist nichts falsch; falsch ist nur die Annahme, das Wort meine die Tool-Schicht.
Beide versprechen Kosten-Kontrolle. LLM Gateways senken Ausgaben über Routing und Caching. MCP Gateways senken sie über die Tool-Schema-Seite (bei uns heißt das [die Context Tax](/de/blog/the-context-tax)) und, in unserem Fall, über Memory. Dasselbe Wort "billiger", verschiedene Mechanismen, auf einer Folie leicht zu vermengen.
Welches brauchst du?
Antworte mit dem Schmerz, nicht mit dem Kategorienamen.
- Modell-Rechnungen sind undurchsichtig, du jonglierst Anbieter, du willst Failover: LLM Gateway.
- Agenten erreichen echte Tools, Zugangsdaten vermehren sich, niemand kann sagen, was der Agent getan hat: MCP Gateway. Wann dieser Moment kommt, steht im [ehrlichen Entscheidungs-Guide](/de/blog/do-you-need-an-mcp-gateway).
- Beide Schmerzen, eine Plattform-Präferenz: Die konvergierten Produkte oben sind glaubwürdig; bewerte jede Hälfte für sich, statt anzunehmen, dass Exzellenz überträgt.
Eine Unterscheidung noch, wo wir dabei sind: Ein MCP Gateway ist auch nicht dasselbe wie ein einzelner MCP-Server, entwirrt in [MCP Gateway vs. MCP-Server](/de/blog/mcp-gateway-vs-mcp-server).
Der Vollständigkeit halber und mit benannter Voreingenommenheit: [Tulimoa](/de/gateway) ist ein MCP Gateway, nur Tool-Schicht, mit angeschlossener Memory-Schicht, in früher Beta. Wenn du Modell-Routing brauchst, sind wir ehrlich gesagt nicht dein Produkt.
Häufige Fragen
Ist ein AI Gateway dasselbe wie ein MCP Gateway?
"AI Gateway" ist der Marketing-Sammelbegriff und meint meist die LLM-Seite, manchmal beides. Wenn ein Anbieter AI Gateway sagt, frag, welchen Verkehr es regelt: Modell-Requests, Tool-Aufrufe oder beides. Die Antwort sortiert das Produkt in einem Satz.
Kann ein Produkt zugleich LLM Gateway und MCP Gateway sein?
Ja, mehrere sind es (Kong, LiteLLM, agentgateway). Die Schichten sind benachbart, nicht identisch: Bewerte die Modell-Routing-Hälfte und die Tool-Governance-Hälfte getrennt, denn gut in einem heißt nichts fürs andere.
Routet ein MCP Gateway meine Modell-API-Aufrufe?
Nein. Der Modell-Verkehr deines Agenten läuft weiter, wo er vorher lief. Das MCP Gateway sieht nur die Tool-Aufrufe des Agenten, und genau deshalb handelt sein Audit-Trail von Aktionen, nicht von Prompts.