TL;DR Die beste Alternative zu Together AI hängt davon ab, was Sie ändern möchten. Wählen Sie Fireworks AI, wenn Sie weiterhin gemanagte Open-Model-Inferenz möchten, aber unterschiedliche Serving-Tiers benötigen. Wählen Sie GroqCloud, wenn niedrige Latenz bei den unterstützten Modellen Priorität hat. Wählen Sie OpenRouter, wenn breite Modell- und Provider-Entdeckung am wichtigsten ist.
Wählen Sie Cloudflare AI Gateway, wenn Sie Gateway-Kontrollen wie Logging, Caching, Rate Limiting und Fallback rund um bestehende Provider wünschen. Wählen Sie LiteLLM, wenn Sie die Routing-Schicht selbst hosten möchten. Wählen Sie CometAPI, wenn Sie eine gemanagte, OpenAI-kompatible API über einen breiten Text- und multimodalen Modellkatalog hinweg benötigen.
Es gibt keinen universellen Gewinner. Together AI bleibt eine starke Option für serverlosen und dedizierten Zugriff auf Open-Modelle. Ein Ersatz ist nur gerechtfertigt, wenn eine andere Plattform besser zu Ihren benötigten Modellen, Ihrem Latenzziel, Ihren Routing-Kontrollen, Ihrer Datenarchitektur, Ihrem Abrechnungsmodell oder Ihrer operativen Verantwortung passt.
Zentrale Aussagen
- Alternativen zu Together AI fallen in drei Kategorien: gemanagte Inferenz-Provider, gemanagte Multi-Provider-Gateways und selbstgehostete Gateways.
- Fireworks AI und GroqCloud sind die engsten Alternativen, wenn das Hauptkriterium gehostete Inferenz für ausgewählte Open-Modelle ist.
- OpenRouter, Cloudflare AI Gateway und CometAPI sind die besseren Vergleiche, wenn der Bedarf der Zugang über mehrere Provider oder Modellfamilien über eine Steuerungsebene ist.
- LiteLLM passt am besten, wenn ein Team Provider-Flexibilität möchte, aber Deployment, Zugangsdaten, Routing-Policy und Observability selbst besitzen muss.
- Vergleichen Sie die Kosten pro erfolgreicher Aufgabe, nicht nur den Tokenpreis. Retries, fehlerhafte Ausgaben, Gateway-Gebühren, Ingenieursaufwand und Qualitätsunterschiede können das Ergebnis verändern.
- OpenAI-kompatible Endpunkte reduzieren den Migrationsaufwand, garantieren jedoch keine identische Unterstützung für Tools, strukturierte Ausgaben, Streaming-Events, Reasoning-Felder oder providerspezifische Funktionen.
Warum nach einer Together AI-Alternative suchen?
Together AI bietet serverlosen Zugriff auf Open-Modelle mit nutzungsbasierter Abrechnung sowie separate Bereitstellungsoptionen für Teams, die reservierte Kapazität benötigen. Der offizielle Katalog umfasst Chat, Bild, Vision, Video, Audio, Embeddings, Reranking und Moderation. Für viele Open-Model-Workloads ist das eine praktische Kombination.
Teams evaluieren Alternativen in der Regel, weil sich ihre Anforderungen geändert haben, nicht weil Together AI grundsätzlich ungeeignet wäre. Häufige Auslöser sind der Bedarf an proprietären Frontier-Modellen neben Open-Modellen, ein breiterer Providerkatalog, die Priorisierung eines bestimmten Latenzprofils, Konsolidierung der Abrechnung, Hinzufügen von Gateway-basiertem Routing und Observability oder die Verlagerung der Control Plane in die eigene Umgebung.
Die erste Frage sollte daher lauten: Welche Einschränkung wollen wir beseitigen? Die Antwort bestimmt, welche Kategorie von Alternativen auf die Shortlist gehört.
Together AI-Alternativen auf einen Blick
| Plattform | Typ | Modellumfang | Routing und Kontrolle | Abrechnungsmodell | Am besten geeignet |
|---|---|---|---|---|---|
| Together AI | Gemanagte Inferenz | Offene Modelle über Text und andere Modalitäten hinweg | Serverlose oder dedizierte Bereitstellung; Anwendung besitzt das Cross-Provider-Routing | Serverlose nutzungsbasierte Abrechnung; dedizierte Kapazität separat abgerechnet | Teams mit Fokus auf Open-Model-Inferenz, Fine-Tuning oder dedizierte Deployments |
| Fireworks AI | Gemanagte Inferenz | Ausgewählte offene Text-, Vision- und Embedding-Modelle | Standard-, Priority- und Fast-Serving-Pfade; Modell- und Deployment-Optionen variieren | Pro-Token serverlose Preise; Batch und andere Deployments separat bepreist | Open-Model-Workloads mit Bedarf an Serving-Tiers oder Prompt-Caching-Ökonomie |
| GroqCloud | Gemanagte Inferenz | Kuratierte gehostete Modelle und Systeme | OpenAI-kompatible API; schlankerer Katalog als breite Aggregatoren | Modellspezifische Tokenpreise und planspezifische Limits | Latenzkritische Workloads, die in den aktiven Modellkatalog von GroqCloud passen |
| OpenRouter | Gemanagter Aggregator | 400+ Modelle über 70+ Provider auf Pay-as-you-go | Auto-Routing, Providerwahl, Policy-Routing, Budgets und Aktivitätsprotokolle | Modellspezifische Nutzungspreise plus dokumentierte Plattform- bzw. Guthabenkauf-Gebühren | Breite Modellentdeckung und Multi-Provider-Routing über eine API |
| Cloudflare AI Gateway | Gemanagtes Gateway | Workers AI und unterstützte Drittanbieter | Logging, Caching, Rate Limiting, Retries, Fallbacks, Metadaten und Ausgabensteuerung | Kern-Gateway-Features in allen Plänen; optionale einheitliche Abrechnung mit dokumentierter Gebühr | Teams, die Cloudflare bereits nutzen oder eine Policy- und Observability-Schicht um Provider benötigen |
| LiteLLM | Selbstgehostetes Gateway/SDK | 100+ LLM-Integrationen je nach konfigurierten Providern | Retries, Fallbacks, Load Balancing, virtuelle Keys, Budgets und Observability-Callbacks | Open-Source-Software plus Upstream-Inferenz- und Infrastrukturkosten | Plattformteams, die maximale Kontrolle benötigen und das Gateway selbst betreiben können |
| CometAPI | Gemanagte einheitliche API | Vom Anbieter gelisteter Katalog mit 500+ Text- und multimodalen Modellen | Eine OpenAI-kompatible Zugriffsschicht; erforderliches Routing und Funktionsverhalten je Modell prüfen | Pay-as-you-go; Preise variieren je Modellroute | Teams, die breiten Modellzugang und konsolidierte Integration ohne selbstgehostetes Gateway wünschen |
Die Tabelle vergleicht die Produktarchitektur, ohne eine universelle Performance-Reihenfolge zu behaupten. Modellverfügbarkeit, Preise, Limits und Gateway-Funktionen ändern sich häufig, daher sollten Produktionsentscheidungen anhand der verlinkten Dokumentation und einer workloadspezifischen Evaluation überprüft werden.
1. Fireworks AI: Am besten für gemanagtes Open-Model-Serving mit Optionen
Fireworks AI Serverless ist die engste Alternative für Teams, die gehosteten Zugriff auf Open-Modelle ohne eigene GPUs wollen. Fireworks dokumentiert Standard-, Priority- und Fast-Serving-Pfade. Standard ist die Standardoption mit Bezahlung pro Token, Priority erhöht die Verkehrspriorität in Spitzenzeiten gegen Aufpreis und Fast-Varianten zielen, wo verfügbar, auf latenzsensitive Anwendungsfälle.
Die offizielle Preisseite trennt Kosten für Eingabef-, gecachte Eingabe- und Ausgabetoken und veröffentlicht modellspezifische Preise. Batch-Inferenz wird für unterstützte Workloads unterhalb von Echtzeit-Serverless bepreist. Das macht Fireworks relevant, wenn Serving-Ökonomie, Prompt-Caching oder explizite Traffic-Tiers wichtiger sind als der Zugang zu proprietären Modellfamilien.
Wählen Sie Fireworks AI, wenn: Sie gemanagte Open-Model-Inferenz möchten, Standard- und höher priorisierte Serving-Pfade vergleichen wollen oder erwarten, dass Prompt-Caching und Batch-Verarbeitung die Kosten wesentlich beeinflussen.
Zu beachten: Die Modellverfügbarkeit unterscheidet sich je Serving-Pfad, und eine Migration zu Fireworks schafft nicht automatisch Cross-Provider-Redundanz. Prüfen Sie genau das benötigte Modell, die Rate-Limit-Stufe, Region und Funktionsunterstützung.
2. GroqCloud: Am besten für latenzsensitive Workloads mit kuratiertem Katalog
GroqCloud veröffentlicht die aktiven Modell-IDs, Token-Geschwindigkeiten, Preise, Kontextfenster und Rate Limits des Entwicklerplans für die gehosteten Modelle. Die API verwendet einen OpenAI-kompatiblen Pfad, was den Migrationsaufwand für einfache Chat-Completion-Workloads reduzieren kann.
Der entscheidende Trade-off ist der Umfang. GroqCloud ist kein breiter Marktplatz für jedes große proprietäre und offene Modell. Es ist am nützlichsten, wenn eines der aktiven Produktionsmodelle Ihre Qualitätsanforderungen erfüllt und Latenz die primäre Einschränkung ist. Ein kleinerer kuratierter Katalog kann die Evaluation vereinfachen, bietet aber weniger Freiheit, zwischen unterschiedlichen Modellfamilien zu wechseln.
Wählen Sie GroqCloud, wenn: die Antwortgeschwindigkeit zentral für das Produkterlebnis ist und Ihre bevorzugten Modelle im aktuellen GroqCloud-Katalog enthalten sind.
Zu beachten: Testen Sie Rate Limits im Test- und Produktionsmodus separat und bestätigen Sie Toolaufrufe, strukturierte Ausgaben, Streaming und Fehlerverhalten mit Vertragstests, statt vollständige OpenAI-Parität anzunehmen.
3. OpenRouter: Am besten für breite Modell- und Provider-Entdeckung
OpenRouter ist eine gemanagte Aggregationsschicht und keine dedizierte Open-Model-Inferenzplattform. Der Pay-as-you-go-Plan listet derzeit Zugriff auf mehr als 400 Modelle über mehr als 70 Provider sowie Auto-Routing, bevorzugte Providerwahl, Budgets, Ausgabensteuerung, Aktivitätsprotokolle und Policy-basiertes Routing.
Diese Breite ist nützlich für Modellentdeckung und Anwendungen, die mehrere Upstream-Routen hinter einer Schnittstelle benötigen. OpenRouter veröffentlicht außerdem Metadaten zu Modellen, die nach Preis, Kontextlänge, Durchsatz, Latenz und unterstützten Parametern filterbar sind. Die Abrechnungsdokumentation sollte sorgfältig gelesen werden: Die Plattform listet 5,5 % Gebühr für Pay-as-you-go sowie separate Bedingungen für Bring-Your-Own-Key-Nutzung.
Wählen Sie OpenRouter, wenn: Katalogbreite, providerseitiges Routing und schneller Modellvergleich wichtiger sind als die Nähe zu einem einzelnen Inferenz-Stack.
Zu beachten: Dasselbe Modell kann von verschiedenen Providern mit unterschiedlicher Latenz, Datenrichtlinien und Verfügbarkeit bereitgestellt werden. Pinnen Sie Provider oder definieren Sie Routing-Policies, wenn Reproduzierbarkeit wichtig ist.
4. Cloudflare AI Gateway: Am besten für Gateway-Kontrollen um bestehende Provider
Cloudflare AI Gateway ist am besten als Observability- und Kontrollschicht zu verstehen. Dokumentierte Funktionen umfassen Analytics, Logging, Caching, Rate Limiting, Request-Retries, Modell-Fallbacks und benutzerdefinierte Metadaten. Teams können Anfragen mit eigenen Provider-Keys routen oder Cloudflares Unified Billing für unterstützte Drittanbieter nutzen.
Das ist etwas anderes, als Together AI durch einen anderen Inferenzhost zu ersetzen. Cloudflare kann vor mehreren Providern sitzen und Policies übergreifend durchsetzen. Die Fallback-Funktion kann nach einem Fehler oder konfiguriertem Timeout von einem Provider oder Modell zu einem anderen wechseln, während Response-Header anzeigen, welcher Schritt erfolgreich war.
Wählen Sie Cloudflare AI Gateway, wenn: Sie bereits Provider-Beziehungen haben und zentrale Sichtbarkeit, Caching, Sicherheitskontrollen, Budgets oder Fallback auf Gateway-Ebene benötigen.
Zu beachten: Providerspezifische Funktionen können weiterhin providerspezifische Request-Formate erfordern, und Unified Billing hat eigene Limits und Gebühren. Prüfen Sie, ob BYOK oder Unified Billing besser zu Ihren Verträgen und Rate Limits passt.
5. LiteLLM: Am besten für selbstgehostete Kontrolle
LiteLLM kann als Python-SDK oder als zentraler Proxy eingesetzt werden. Die Dokumentation beschreibt eine konsistente OpenAI-ähnliche Schnittstelle über mehr als 100 LLM-Integrationen hinweg, mit Retries, Fallbacks, Load Balancing, Ausgabenverfolgung, Budgets, virtuellen Keys und Observability-Integrationen.
LiteLLM ist attraktiv, wenn die Organisation kontrollieren muss, wo das Gateway läuft, wie Keys gespeichert werden und wie die Routing-Policy implementiert ist. Es kann auch direkte Providerverträge beibehalten, da der Traffic weiterhin die von Ihnen konfigurierten Provider-Credentials verwendet.
Wählen Sie LiteLLM, wenn: Sie ein Plattformteam haben, eine selbstgehostete Control Plane benötigen oder Cloud-APIs mit privaten oder lokalen Modell-Deployments kombinieren möchten.
Zu beachten: Die Kosten für Open-Source-Software sind nicht die Gesamtkosten. Ihr Team besitzt Deployment, Skalierung, Sicherheitspatches, Konfigurationsänderungen, Telemetrie, Incident Response und Updates zur Providerkompatibilität.
6. CometAPI: Am besten für breiten gemanagten Zugang über Text- und multimodale Modelle
CometAPI ist eine gemanagte einheitliche API. Die aktuelle Website listet mehr als 500 Modelle über Text, Bild, Video, Audio und andere Modalitäten und bietet eine OpenAI-kompatible Basis-URL. Entwickler können den aktuellen Modellkatalog prüfen, bevor sie eine Route auswählen.
Im Vergleich zum Open-Model-Inferenzfokus von Together AI ist CometAPI relevant, wenn ein Produkt sowohl offene als auch proprietäre Modellfamilien oder mehrere Modalitäten unter einem Konto und einer Integrationsschicht benötigt. Beispielsweise kann die aktuelle DeepSeek V4 Pro-Route über dieselbe OpenAI-kompatible Client-Form aufgerufen werden, die für andere unterstützte Textmodelle verwendet wird.
Wählen Sie CometAPI, wenn: Sie eine gemanagte Alternative mit breiter Modellvielfalt, einem API-Key und weniger clientseitigem Integrationsaufwand als bei mehreren Provider-SDKs möchten.
Zu beachten: Kataloggröße, Preis und Funktionsunterstützung sind anbieter- und routenspezifisch. Prüfen Sie Modell-IDs, Parameter, Streaming-Events, Usage-Felder, Datenverarbeitung und Fehlverhalten für die genauen Routen, die Sie planen.
So wählen Sie die richtige Together AI-Alternative
1. Entscheiden Sie, ob Sie einen Inferenz-Provider oder ein Gateway benötigen
Wenn die Hauptanforderung schnelleres oder anders bepreistes Hosting für Open-Modelle ist, vergleichen Sie Together AI mit Fireworks AI und GroqCloud. Wenn die Anforderung eine Schnittstelle über viele Provider ist, vergleichen Sie OpenRouter, Cloudflare AI Gateway, LiteLLM und CometAPI. Das Mischen dieser Kategorien ohne klare Architektur führt zu irreführenden Vergleichen.
2. Erstellen Sie die Shortlist anhand benötigter Modelle und Funktionen
Listen Sie die genauen Modellfamilien, Modalitäten, Endpunkte und Parameter der Anwendung auf. Beziehen Sie Toolaufrufe, strukturierte Ausgaben, Reasoning-Kontrollen, Embeddings, Reranking, Bildeingabe, Audio, Batch und Fine-Tuning ein, wo relevant. Entfernen Sie jeden Kandidaten, der eine erforderliche Fähigkeit nicht unterstützt.
3. Messen Sie die Kosten pro erfolgreicher Aufgabe
Der Tokenpreis ist nur eine Komponente. Messen Sie die gesamten Modellkosten, Gateway- oder Kreditgebühren, Retries, gecachte Tokens, fehlerhafte Antworten, Ingenieursaufwand und den Anteil der Ausgaben, die die Qualitätsprüfung der Anwendung bestehen. Eine günstige Route, die wiederholte Aufrufe erfordert, kann pro erledigter Aufgabe teurer sein.
4. Testen Sie Latenz und Zuverlässigkeit auf Ihrem Traffic
Führen Sie dieselben Prompts aus denselben Anwendungsregionen bei repräsentativer Parallelität aus. Protokollieren Sie Time to First Token, End-to-End-Latenz, Tail-Latenz, Erfolgsrate beim ersten Versuch, Timeout-Rate, 429-Rate und Wiederherstellungsverhalten. Vermeiden Sie universelle Geschwindigkeitsbehauptungen auf Basis eines Anbieter-Benchmarks oder eines einzelnen Modells.
5. Evaluieren Sie die Failure Domain
Ein zweites Modell auf demselben Gateway kann gegen einen modellspezifischen Ausfall schützen, aber nicht gegen einen Gateway-Ausfall. Ein zweiter Provider kann dennoch eine regionale oder Netzwerkabhängigkeit teilen. Dokumentieren Sie, welchen Ausfall jeder Fallback entfernt, und behalten Sie einen getesteten Bypass für kritischen Traffic, wenn das Gateway selbst nicht verfügbar ist.
6. Überprüfen Sie Datenverarbeitung und operative Verantwortung
Bestätigen Sie Request-Logging, Aufbewahrung, Löschkontrollen, Regionen, Subprozessoren, Key-Isolation und Compliance-Bedingungen. Für selbstgehostete Gateways zählen die Sicherheits- und On-Call-Belastung Ihres Teams. Für gemanagte Gateways berücksichtigen Sie den zusätzlichen Verarbeiter und die Abhängigkeit im Datenfluss.
Eine praktische Migrations-Checkliste
- Inventarisieren Sie die aktuelle Together AI-Last. Erfassen Sie Modell-IDs, Endpunkte, Parameter, durchschnittliche Ein- und Ausgabetokens, Parallelität, Latenz-Ziele, Rate-Limit-Verhalten und monatliche Ausgaben.
- Erstellen Sie einen providerneutralen Testsatz. Berücksichtigen Sie gewöhnliche Prompts, schwierige Prompts, Toolaufrufe, strukturierte Ausgaben, Streaming-Abbruch, langen Kontext und fehlerhafte Requests.
- Führen Sie Kompatibilitätstests durch. Vergleichen Sie Antwortschemata, Usage-Felder, Fehlerobjekte, Tool-Call-Argumente, Finish-Reasons und Streaming-Events.
- Benchmarken Sie produktionsähnlichen Traffic. Messen Sie Qualität, Latenz, Durchsatz, Retries und Kosten über wiederholte Läufe statt eines Demo-Requests.
- Testen Sie Fehler gezielt. Injizieren Sie Timeouts, 429er, 5xx-Fehler, ungültige Modelle, unvollständige Streams und Gateway-Unverfügbarkeit.
- Führen Sie einen Canary für die neue Route ein. Starten Sie mit unkritischem Traffic, gleichen Sie die Abrechnung mit Provider-Dashboards ab und halten Sie die vorherige Route während des Beobachtungsfensters verfügbar.
OpenAI-kompatibles Beispiel mit CometAPI
Das folgende Beispiel zeigt den begrenzten Migrationsvorteil, den ein OpenAI-kompatibler Endpunkt bieten kann: Client und Request-Form bleiben vertraut, während sich Base-URL und Modell-ID ändern. Es beweist keine Parität für jede providerspezifische Funktion, daher testen Sie die Parameter, die Ihre Anwendung nutzt.
import osfrom openai import OpenAIclient = OpenAI( base_url="https://api.cometapi.com/v1", api_key=os.environ["COMETAPI_KEY"], timeout=30.0,)response = client.chat.completions.create( model="deepseek-v4-pro", messages=[ {"role": "system", "content": "Gib knappes, gültiges JSON zurück."}, {"role": "user", "content": "Klassifiziere dieses Support-Ticket nach Dringlichkeit."}, ],)print(response.choices[0].message.content)
Vor dem Einsatz in Produktion bestätigen Sie die aktuelle Modellroute und das Request-Verhalten in der CometAPI-Dokumentation und testen Sie Abrechnung, Fehler, Streaming und strukturierte Ausgaben gegen Ihre Abnahmekriterien.
Häufig gestellte Fragen
Was ist die nächstliegende Alternative zu Together AI?
Fireworks AI ist der nächstliegende architektonische Vergleich für gemanagte Open-Model-Inferenz mit mehreren Serving-Optionen. GroqCloud ist ebenfalls relevant, wenn seine unterstützten Modelle zum Workload passen und niedrige Latenz die Hauptpriorität ist. Breite Aggregatoren und Gateways lösen ein anderes Problem.
Welche Together AI-Alternative hat die größte Modellauswahl?
OpenRouter dokumentiert mehr als 400 Modelle über mehr als 70 Provider auf dem Pay-as-you-go-Plan. CometAPI listet mehr als 500 Text- und multimodale Modelle. Da die Kataloge unterschiedliche Aufnahmeregeln verwenden und sich häufig ändern, vergleichen Sie die genauen Modelle und Modalitäten, die Sie benötigen, statt sich allein auf die Schlagzahl zu verlassen.
Sollte ich OpenRouter oder CometAPI wählen?
Wählen Sie anhand der benötigten Routen, der Preise für Ihren Modellmix, Provider-Kontrollen, Datenrichtlinien, Latenz und API-Verhalten. OpenRouter betont Provider-Entdeckung und -Routing. CometAPI betont breiten gemanagten Zugang über Text- und multimodale Modelle durch eine OpenAI-kompatible Integration. Testen Sie beide mit demselben Workload, bevor Sie Produktionstraffic umstellen.
Wann ist LiteLLM die bessere Wahl als eine gemanagte API?
LiteLLM passt besser, wenn die Organisation das Gateway hosten, direkte Provider-Credentials behalten, das Routing tiefgreifend anpassen oder private Modellendpunkte integrieren muss. Eine gemanagte API ist in der Regel einfacher, wenn das Team weniger Infrastrukturverantwortung möchte und eine externe Gateway-Abhängigkeit akzeptiert.
Kann ich migrieren, indem ich nur die Base-URL ändere?
Manchmal für einfache Chat-Completions, aber nicht zuverlässig für eine gesamte Produktionsanwendung. Modell-IDs, Tool-Schemata, strukturierte Ausgaben, Streaming-Events, Usage-Felder, Fehler, Embeddings, Batch-Jobs, Fine-Tuning und Reasoning-Kontrollen können sich unterscheiden. Behandeln Sie eine Base-URL-Änderung als Startpunkt der Migrationstests, nicht als deren Ende.
Ist die günstigste Together AI-Alternative die beste Option?
Nein. Die nützliche Metrik sind die Kosten pro erfolgreicher Aufgabe unter den Qualitäts-, Latenz- und Zuverlässigkeitsanforderungen der Anwendung. Berücksichtigen Sie Gateway-Gebühren, Retries, fehlerhafte Ausgaben, Ingenieursarbeit und operativen Overhead beim Vergleich der Gesamtkosten.
Fazit
Together AI bleibt eine glaubwürdige Wahl für gemanagte Open-Model-Inferenz. Die beste Alternative hängt von der tatsächlich benötigten Architektur ab. Fireworks AI bietet einen weiteren gemanagten Open-Model-Serving-Pfad. GroqCloud ist überzeugend für unterstützte latenzsensitive Workloads. OpenRouter bietet breite Modell- und Provider-Entdeckung. Cloudflare AI Gateway fügt Policy und Observability um den Providerzugang hinzu. LiteLLM bietet selbstgehostete Kontrolle. CometAPI liefert breiten gemanagten Zugang über Text- und multimodale Modelle.
Erstellen Sie die Shortlist aus den benötigten Fähigkeiten und testen Sie dann jeden Kandidaten mit denselben Prompts, derselben Parallelität, denselben Fehlerfällen und denselben Abnahmekriterien. Dieser Prozess führt zu einer belastbaren Entscheidung; ein generisches Providerranking nicht.
