Shared vs. Dedicated LLM Serving
LLM Serving wird in zwei Servicemodellen angeboten. Shared LLM Serving Service ist das Standardprodukt — Multi-Tenant, Pay-as-you-go, bestellbar über den T-Cloud Marketplace und das API-Key Self-Service-Portal. Dedicated LLM Serving reserviert GPU-Hardware exklusiv für Ihren Vertrag, der Durchsatz wird ausschließlich durch die Hardware selbst begrenzt.
Beide Modelle nutzen dieselbe OpenAI-kompatible API und denselben Katalog an Open-Source-Modellen. Der Unterschied liegt in der Kapazitätsverteilung und im Abrechnungsmodell.
Auf einen Blick
Abschnitt betitelt „Auf einen Blick“| Shared LLM Serving Service | Dedicated LLM Serving | |
|---|---|---|
| Tenancy | Multi-Tenant — Kapazität wird über alle Kunden gepoolt | Single-Tenant — Hardware ist Ihrem Vertrag exklusiv zugewiesen |
| Preismodell | Pay-as-you-go, Abrechnung pro Token | Fester Monatspreis pro GPU-Äquivalent |
| Rate-Limits | Tarifabhängige RPM- und TPM-Obergrenzen — Best-Effort, nicht Teil des SLA | Keine — limitiert nur durch Ihre reservierte Hardware |
| Modelle | Voller Katalog laut Tarife & Preise | Jedes Modell, das auf die reservierte Hardware passt (inkl. privater Fine-Tuning-Modelle) |
| Performance (Latenz, Durchsatz) | Best-Effort, variiert mit Plattformlast; nicht Teil des SLA | Vorhersagbar auf der reservierten Hardware; Performance-SLAs verhandelbar |
| Verfügbarkeits-SLA | 99,9% API-Verfügbarkeit im Standardprodukt (Betriebszeit); deckt nur Erreichbarkeit ab | Individuelle Verfügbarkeits- und Performance-SLAs verhandelbar |
| Bestellung | Self-Service über den T-Cloud Marketplace und das API-Key Self-Service-Portal | Angebotsanfrage beim AIFS-Team |
| Geeignet für | Stetigen Produktionsverkehr, Exploration, Prototyping | Strikte Latenz-SLAs, bursty Workloads, hohen Dauerdurchsatz, private Modelle |
Wie sich Rate-Limits unterscheiden
Abschnitt betitelt „Wie sich Rate-Limits unterscheiden“Im Shared LLM Serving Service wird jedes Modell mit einem RPM- (Anfragen pro Minute) und einem TPM-Wert (Token pro Minute) je Tarif veröffentlicht — siehe Rate-Limits für die vollständige Tabelle.
Diese veröffentlichten Werte sind Best-Effort-/Best-Case-Obergrenzen — der maximale Verbrauch, den Sie erreichen dürfen, nicht ein Wert, den die Telekom zusichert. Sie sind nicht Teil des SLA.
- Closed-Source-Modelle (GPT, Claude, Gemini) — die Telekom leitet Anfragen an den Upstream-Anbieter weiter. Die veröffentlichten RPM/TPM sind die vertraglichen Drosselungs-Obergrenzen; das tatsächliche Rate-Limit setzt der Upstream-Anbieter durch, und der erreichte Durchsatz hängt von dessen Kapazität ab.
- Open-Source-Modelle auf T-Cloud (Llama, Mistral, Qwen, GPT-OSS, …) — laufen auf gemeinsam genutzter GPU-Infrastruktur bei T-Systems. Die veröffentlichten RPM/TPM sind ebenfalls Obergrenzen, aber der effektive Durchsatz kann bei Lastspitzen deutlich darunter liegen, wenn viele Tenants dasselbe Modell parallel nutzen. Auch End-to-End-Latenz und Time-to-First-Token variieren mit der Plattformlast.
Das SLA des Shared LLM Serving Service sichert ausschließlich 99,9% API-Verfügbarkeit zu. Es deckt RPM, TPM, Durchsatz, Latenz oder Time-to-First-Token nicht ab.
In Dedicated LLM Serving gibt es keine Pro-Minute-Obergrenzen. Sie verbrauchen so viele Token, wie Ihre reservierte Hardware physisch erzeugen kann. Durchsatz, Latenz und Time-to-First-Token werden deterministisch — sie hängen von Ihrem Modell, der Batch-Größe und der Prompt-Länge ab, nicht vom Verhalten anderer Kunden — und lassen sich mit vertraglichen Performance-SLAs verknüpfen.
Shared oder Dedicated LLM Serving wählen
Abschnitt betitelt „Shared oder Dedicated LLM Serving wählen“Shared LLM Serving Service passt, wenn:
Abschnitt betitelt „Shared LLM Serving Service passt, wenn:“- Ihr Traffic stetig und vorhersehbar ist und komfortabel unter den RPM/TPM-Obergrenzen Ihres Tarifs bleibt
- Sie gelegentliche Latenzschwankungen zu Stoßzeiten tolerieren können (Latenz ist nicht Teil des Shared-SLA)
- Sie keine vertragliche Latenz- oder Time-to-First-Token-Zusage gegenüber Ihren Endnutzern haben
- Sie prototypisieren, evaluieren oder im frühen Produktionsbetrieb sind und Pay-as-you-go bevorzugen
- Sie Self-Service-Bestellung über den T-Cloud Marketplace oder das API-Key Self-Service-Portal wollen
Das Shared-Modell deckt die große Mehrheit der Produktions-Workloads ab. Viele Kunden bleiben dauerhaft darauf.
Dedicated LLM Serving passt, wenn:
Abschnitt betitelt „Dedicated LLM Serving passt, wenn:“- Ihr Workload bursty ist — kurze Phasen sehr hoher Token-Last, die die Best-Effort-Obergrenzen des Shared Service überschreiten würden
- Sie vertragliche Latenz- oder Durchsatz-SLAs brauchen — Time-to-First-Token oder End-to-End-Latenz, die der Shared Service nicht zusichern kann (und strukturell auch nicht im SLA hat)
- Sie dauerhaft hohen Durchsatz brauchen, jenseits der Best-Effort-Obergrenzen des Agentic-Tarifs
- Sie ein privates, fine-tuned oder kundenspezifisches Modell hosten wollen, das nicht im Shared-Katalog steht
- Ihre Compliance Single-Tenant-Infrastruktur verlangt
- Sie planbare Monatskosten statt nutzungsbasierter Abrechnung bevorzugen
Dedicated LLM Serving tauscht eine feste Monatsgebühr gegen eine harte Zusage auf Hardware-Durchsatz. Vollständige Beschreibung und Bestellweg: Dedicated LLM Serving.
Hybrid-Deployments
Abschnitt betitelt „Hybrid-Deployments“Viele Enterprise-Kunden fahren einen Hybrid-Aufbau:
- Eine Dedicated-LLM-Serving-Instanz für den Hot Path — den latenzkritischen, durchsatzstarken Workload (z. B. einen kundenseitigen Chatbot)
- Den Shared LLM Serving Service für alles andere — interne Tools, Batch-Jobs, Evaluierungen, weniger kritische Funktionen
Beide nutzen dieselbe API und dasselbe SDK. Routing zwischen ihnen ist eine Konfigurations- und keine Architekturfrage.
Für ein individuelles Angebot über Shared, Dedicated LLM Serving oder eine Kombination wenden Sie sich an das AIFS-Team unter ai@t-systems.com.