Einen LLM-Anbieter wählen: Rahmenbedingungen, Routing und umkehrbares Design
Fünf Rahmenbedingungen, die zwischen geschlossenen, Open-Weight- und selbst gehosteten Modellen entscheiden, dazu anbieterneutraler Code, Routing-Stufen, Kostenmodell und eine Sicherheits-Checkliste.
Teams fragen immer wieder, welches Modell das beste ist – als wäre die Wahl ein Geschmackstest. Diese Frage hat eine kurze Haltbarkeit. Die Anbieterpreise haben sich im ersten Halbjahr 2026 zweimal geändert, und jedes große Labor hat im selben Zeitraum neue Modellversionen veröffentlicht. Ein Unternehmen, das sich im Januar an einen einzigen Anbieter gebunden hat, hat diese Wette schon veralten sehen.
Eine bessere Frage hat drei Teile. Was verlangt dieser Workload? Welche Modellklasse erfüllt diese Anforderungen? Und wie günstig könnten wir in sechs Monaten wechseln? Wenn ein Anbieterwechsel ein Neuschreiben bedeutet, haben Sie keine Architekturentscheidung getroffen. Sie haben sich eine Abhängigkeit eingehandelt.
Im Folgenden geht es um die Rahmenbedingungen, die die Sache wirklich entscheiden, und um eine Code-Struktur, die die Wahl umkehrbar hält.
Fünf Rahmenbedingungen, die entscheiden
Gehen Sie diese durch, bevor Sie irgendeine Benchmark-Tabelle öffnen.
Wohin Ihre Daten dürfen. Geschlossene API-Modelle schicken Ihre Daten mit jeder Anfrage durch die Infrastruktur des Anbieters. In regulierten Branchen, bei Patientenakten oder Aufträgen der öffentlichen Hand kann allein diese Tatsache die Diskussion beenden. Self-Hosting oder ein Deployment in der passenden Region ist dann keine Kostenfrage mehr, sondern eine Compliance-Frage.
Kosten bei Produktionsvolumen. Demo-Traffic verschleiert die Spanne. Budget-Modelle liegen bei etwa $0.10 pro Million Eingabe-Tokens, Frontier-Modelle erreichen $25 bis $30 pro Million Ausgabe-Tokens. Bei rund einer Million Konversationen im Monat landen gehostete Modelle irgendwo zwischen $15.000 und $75.000 monatlich. Ein kleines feinabgestimmtes Modell auf eigener Hardware kann dieselbe Last für ein paar hundert Dollar stemmen – vorausgesetzt, die Aufgabe ist eng umrissen und wiederholt sich.
Tatsächliche Schwierigkeit der Aufgabe. Die meisten geschäftlichen Workloads bestehen aus Sortieren, Extrahieren, Zusammenfassen und Weiterleiten. Keine davon braucht Reasoning auf Frontier-Niveau, also heben Sie die teure Stufe für die schwierige Minderheit auf.
Latenztoleranz. Ein Mensch, der auf eine Chat-Antwort wartet, und ein nächtlicher Batch-Job haben nichts gemeinsam. Für Geschwindigkeit zu zahlen, die Sie nicht brauchen, ist die häufigste stille Mehrausgabe.
Bereitschaft zum Betrieb. Open-Weight-Modelle kosten beim Download nichts, aber ihr Betrieb bedeutet gemietete GPUs – von etwa $0.50 bis $5.00 pro Stunde, je größer die Modelle werden – und Ingenieure, die den Stack ausrollen, patchen und überwachen.
Schritt 1: Zuerst die Naht bauen
Definieren Sie die Abstraktion, bevor Sie sich für jemanden entscheiden. Der gesamte übrige Code sollte mit Ihrer Schnittstelle sprechen und nie mit einem Anbieter-SDK.
class ModelProvider(Protocol):
def complete(self, messages, *, max_tokens, tools=None) -> Completion: ...
class Router:
def __init__(self, providers: dict[str, ModelProvider]):
self.providers = providers
def complete(self, messages, *, tier="standard", **kw):
name = MODEL_FOR_TIER[tier] # config, not code
try:
return self.providers[name].complete(messages, **kw)
except (RateLimited, ProviderDown):
fallback = FALLBACK_FOR_TIER[tier] # different vendor entirely
return self.providers[fallback].complete(messages, **kw)
Das bringt zweierlei. Ein Anbieterwechsel wird zur Konfigurationsänderung statt zum Projekt. Und der Ausfall eines Anbieters legt Ihr Produkt nicht mehr lahm – etwas, das Teams unterschätzen, bis es passiert.
Halten Sie Eigenheiten der Anbieter in den jeweiligen Adaptern. Sobald Parameternamen eines Anbieters in die Geschäftslogik sickern, ist die Naht weg.
Schritt 2: Nach Aufgabe routen, nicht nach Liebling
Jede Anfrage an ein einziges Modell zu schicken, ist die teuerste Angewohnheit in produktiver KI. Teilen Sie die Arbeit in Stufen auf.
MODEL_FOR_TIER = {
"bulk": "small_local", # classification, extraction, tagging
"standard": "mid_hosted", # summaries, drafting, most chat
"hard": "frontier_hosted", # multi-step reasoning, ambiguous cases
"sensitive":"self_hosted", # data that cannot leave your estate
}
def choose_tier(task, payload):
if contains_regulated_data(payload):
return "sensitive" # compliance overrides cost
if task in {"classify", "extract", "tag", "route"}:
return "bulk"
if task == "reason" or payload.get("complexity") == "high":
return "hard"
return "standard"
Die Compliance-Prüfung steht bewusst an erster Stelle. Kosten und Qualität lassen sich gegeneinander abwägen. Wo Daten verarbeitet werden dürfen, nicht.
Schritt 3: Am eigenen Workload messen
Öffentliche Leaderboards zeigen, wie Modelle auf öffentlichen Leaderboards abschneiden. Mit der Frage, wie ein Modell mit Ihren Dokumenten, Ihrem Fachjargon und Ihren Sprachen zurechtkommt, hängen sie nur lose zusammen.
Veranstalten Sie Ihren eigenen Vergleich mit demselben Golden Set, das Sie vor Regressionen schützt.
def bake_off(candidates, cases):
results = {}
for name, provider in candidates.items():
passed, cost, latencies = 0, 0.0, []
for case in cases:
t0 = time.monotonic()
out = provider.complete(case["messages"], max_tokens=800)
latencies.append((time.monotonic() - t0) * 1000)
passed += grade(out.text, case["expected"])
cost += price(name, out.usage)
results[name] = {
"accuracy": passed / len(cases),
"cost_per_1k_calls": (cost / len(cases)) * 1000,
"p95_latency_ms": percentile(latencies, 95),
}
return results
Bewerten Sie drei Dinge gleichzeitig: Genauigkeit, Preis und Geschwindigkeit. Ein Modell, das zwei Punkte genauer ist, aber viermal so viel kostet, ist nicht eindeutig besser. Eines, das etwas günstiger, aber dreimal langsamer ist, fällt bei einem kundennahen Feature durch, egal was der Score sagt.
Bewerten Sie auch, wie zuverlässig Anweisungen befolgt und Tools aufgerufen werden. In den meisten Produktivsystemen zählt es mehr, die richtige Funktion mit gültigen Argumenten aufzurufen, als rohe Intelligenz.
Schritt 4: Kosten durchrechnen, bevor Sie sich festlegen
def monthly_estimate(name, calls_per_month, avg_in, avg_out, cache_hit_rate=0.0):
p = PRICING[name] # per million tokens
billable_in = avg_in * (1 - cache_hit_rate) + avg_in * cache_hit_rate * p["cache_ratio"]
return calls_per_month * (
(billable_in / 1_000_000) * p["input"]
+ (avg_out / 1_000_000) * p["output"]
)
# Always run it at 10x expected volume before signing anything.
Zwei Hebel verändern das Ergebnis stark und werden oft vergessen. Batch-Verarbeitung halbiert den Preis für nicht dringende Arbeit meist. Prompt-Caching kann die Kosten für wiederholte Eingaben um bis zu rund 90 Prozent senken – enorm, wenn jeder Aufruf denselben langen Kontext mitschleppt.
Drei Modellfamilien
Geschlossene API-Modelle bringen Sie am schnellsten in Produktion und führen an der Spitze, ganz ohne eigene Server. Im Gegenzug laufen Ihre Daten durch fremde Systeme, Ihre Rechnung wächst linear und ohne Ende, und deren Entscheidungen über Preise und Abkündigungen müssen Sie einfach hinnehmen.
Open-Weight-Modelle über einen Hosting-Anbieter kosten weniger, lassen sich leichter mitnehmen und werden schnell besser. Der mittlere Einführungspreis führender offener Modelle stieg von etwa $0.48 im Jahr 2024 auf $1.35 im Jahr 2026 – immer noch weit unter den geschlossenen Stufen. Ein Vorbehalt: Externe Hoster betreiben Modelle oft mit geringerer numerischer Präzision, um Geld zu sparen, was die Qualität etwas schmälern kann, und ihre Zuverlässigkeitszusagen unterscheiden sich von denen des ursprünglichen Labors.
Self-Hosting bietet volle Kontrolle über Ihre Daten und keine Gebühren pro Token. Sie bezahlen mit GPU-Kapazität und Entwicklerzeit und sind selbst für Patches, Skalierung und Verfügbarkeit verantwortlich. Gerechtfertigt ist das durch Souveränitätsvorgaben oder durch eng umrissene Aufgaben mit hohem Volumen, bei denen ein kleines angepasstes Modell ein allgemeines bei Preis und Genauigkeit schlägt.
Die meisten ausgereiften Systeme nutzen alle drei, und das ist keine Unentschlossenheit. Es ist das Design.
Sicherheitsaspekte
- Behandeln Sie Datenresidenz als Eingabe für das Design. Legen Sie fest, welche Datenarten wo verarbeitet werden dürfen, bevor Sie einen Anbieter suchen. Wer das spät nachrüstet, sieht Projekte im Compliance-Review scheitern.
- Lesen Sie die Bedingungen zur Datenverarbeitung genau: Aufbewahrungsfristen, ob Eingaben künftige Modelle trainieren, die Liste der Unterauftragsverarbeiter und welche Region Ihre Anfragen tatsächlich beantwortet. Enterprise-Verträge weichen meist von den Standardbedingungen ab, und die Standardbedingungen bekommen Sie, wenn niemand nachfragt.
- Ein Prompt ist ein ausgehender Datenfluss. Alles darin hat Ihren Bereich verlassen, also schwärzen Sie vor dem Senden und nicht danach.
- Self-Hosting verlagert das Risiko, statt es zu beseitigen. Nun müssen Sie die Gewichte schützen, jeder Inferenz-Endpunkt ist angreifbar, und Updates werden zu Ihrer Aufgabe. Ein interner Inferenz-Endpunkt ohne Authentifizierung ist ein häufiger und ernster Befund.
- Behandeln Sie API-Schlüssel wie Produktions-Zugangsdaten: einer pro Umgebung und Dienst, rotiert, eng begrenzt und mit Ausgabelimits gedeckelt. Ein geleakter Schlüssel bedeutet ein Datenrisiko plus eine Rechnung ohne Obergrenze.
- Pinnen Sie Modellversionen. Anbieter kündigen Modelle still ab und aktualisieren sie, und ein Modell, das sich unter Ihnen verändert, kann Verhalten brechen, das Sie vor Monaten geprüft haben. Fixieren Sie die Version und lassen Sie das Golden Set erneut laufen, bevor Sie eine Änderung übernehmen.
Checkliste
- Eine anbieterneutrale Schnittstelle, Anbieterdetails nur in den Adaptern
- Modellwahl in der Konfiguration, änderbar ohne Deployment
- Ein Fallback auf einen anderen Anbieter bei Ausfällen und Rate Limits
- Arbeit nach Stufen geroutet, die Compliance-Frage vor der Kostenfrage
- Ein Golden Set für jeden Kandidaten: Genauigkeit, Kosten und p95-Latenz
- Tool-Aufrufe und Befolgen von Anweisungen werden zusammen mit der Antwortqualität bewertet
- Kosten für das Zehnfache des erwarteten Volumens durchgerechnet
- Batching und Caching überall, wo der Workload es zulässt
- Datenresidenz pro Datenklasse festgelegt, bevor ein Anbieter gewählt wird
- Versionen gepinnt und vor Upgrades neu validiert
- Schlüssel pro Dienst begrenzt und mit Ausgabelimits
Zum Schluss
Wer sagt, ein bestimmtes Modell sei die Antwort, beschreibt diesen Monat, nicht Ihr System.
Starke Teams behandeln die Modellwahl als Routing-Entscheidung innerhalb einer stabilen Architektur. Günstige Arbeit geht an günstige Modelle, regulierte Daten bleiben dort, wo sie sein dürfen, bewertet wird mit eigenen Aufgaben statt mit fremden Leaderboards, und all das lässt sich an einem Nachmittag ändern.
Teams, die sich schwertun, haben einen Liebling gekrönt, ihn durch jede Schicht des Produkts gezogen und schreiben nun bei jeder Marktbewegung neu. Wenn sich die Preise binnen sechs Monaten zweimal neu sortieren, summiert sich das zu einer hohen Steuer.
Wählen Sie pro Workload, bauen Sie die Naht und rechnen Sie jedes Quartal neu.