Zum Inhalt
Use cases/Lokal & selbst-gehostet

Welches Open-Weight-Modell sollten Sie selbst hosten?

Das Selbst-Hosten eines Sprachmodells ist die Option, die Teams zu früh abschreiben und zu spät übernehmen. Die übliche Begründung lautet, das Modell liege hinter der gehosteten Frontier — dabei ließe sich heute Qualität betreiben, die vor zwölf Monaten noch State-of-the-Art war, zu einem Bruchteil der laufenden Kosten. Die Adoption erfolgt dann doch, meist als Reaktion auf eine Compliance-Prüfung, die einen Deal-Breaker in den Nutzungsbedingungen eines Drittanbieters aufdeckt. Dieser Leitfaden wählt die fünf Open-Weight-Modelle aus, auf denen wir heute einen selbst-gehosteten Stack aufbauen würden — und nennt die Dimensionen, die entscheiden, welches Modell zu Ihrer Hardware passt.

Selbst-gehostetes GPU-Rack — Konzeptbild
Das richtige Open-Weight-Modell auf der richtigen Karte ist bei Skalierung günstiger als jede gehostete Alternative.

Warum selbst hosten eine zweite Chance verdient

Das Argument gegen Open-Weight-Modelle war früher simpel: Die gehostete Frontier liegt so weit vorne, dass alles andere eine Fehlinvestition ist. Dieses Argument verlor durch 2024 und 2025 jedes Quartal an Überzeugungskraft. Die stärksten offenen Modelle erreichen heute das Niveau, das vor einem Jahr als Flaggschiff der gehosteten Anbieter galt — ausreichend für fast jede Produktions-Workload, die kein kundenseitiger Chat ist. Die Lücke zur scharfen Kante besteht noch; die Lücke zu "gut genug" ist weg.

Der Grund für den lokalen Betrieb liegt selten in der Qualität. Es geht um Datenresidenz, laufende Kosten, Latenz in Regionen, die die großen Anbieter kaum bedienen, und die Sicherheit, ein Modell zu betreiben, das sich nicht unter einem verändert, wenn der Anbieter eine Generation abkündigt. Ein Team, das zehn Millionen interne Dokumente pro Monat klassifiziert, kann auf selbst-gehosteter Infrastruktur gegenüber Pay-per-Token sechsstellig im Jahr sparen. Ein Team mit regulierten Daten umgeht einen ganzen Beschaffungsprozess. Ein Team in einer Region mit hoher Latenz zu US-Rechenzentren bedient Nutzer eine Größenordnung schneller.

Die Kostenrechnung ist nicht so einfach wie "Modellgewichte sind gratis". Sie zahlen für GPUs — gekauft oder gemietet — und für die Engineering-Stunden, die den Betrieb erfordern. Die Gewinnschwelle hängt vom Tokenvolumen ab: Unter rund hundert Millionen Tokens pro Monat gewinnen gehostete APIs fast immer bei den Gesamtkosten; über einer Milliarde gewinnt Self-Hosting fast immer. Im mittleren Bereich entscheiden die workload-spezifischen Details.

Fünf Einschränkungen bestimmen die Wahl: wie viel VRAM das Modell bei einer akzeptablen Qualität benötigt, die Lizenzbedingungen für den eigenen Anwendungsfall, die Reife des umgebenden Ökosystems und die Latenz, die das Modell auf der eigenen Hardware tatsächlich liefert. Das richtige Modell ist das, das alle fünf erfüllt — nicht das mit dem besten Paper-Benchmark-Score.

Selbst-gehosteter Serving-Stack — Konzeptbild
Der Serving-Stack — vLLM, Ollama, llama.cpp — ist genauso entscheidend wie das Modell.

Die fünf Dimensionen, die entscheiden, welches Modell passt

Dies sind die Achsen, nach denen unsere Scorecard ein Open-Weight-Modell für produktives Self-Hosting bewertet. Die relative Gewichtung verschiebt sich mit dem Hardware-Budget, der Jurisdiction und der Toleranz gegenüber Ecosystem-Rauheiten — aber jeder ernsthafte Kandidat muss auf allen fünf eine Mindestanforderung erfüllen.

  1. 01 — Hardware-Fit

    Läuft es auf den Karten, die Sie tatsächlich haben?

    Ein Modell, das einen Multi-GPU-Knoten erfordert, ist eine andere Proposition als eines, das auf einer einzelnen Consumer-Karte läuft. Berechnen Sie stets den VRAM-Bedarf bei der geplanten Quantisierung und fügen Sie ausreichend Puffer für den KV-Cache bei der Ziel-Kontextlänge hinzu. Der günstigste Fehler ist zu viel Hardware zu kaufen; der teuerste ist zu wenig.

  2. 02 — Qualität bei Quantisierung

    Wie viel verliert es beim Quant-Niveau, das noch passt?

    Quantisierung tauscht Qualität gegen Speicher und Geschwindigkeit. Manche Modelle halten bei Vier-Bit-Quants gut stand; andere verschlechtern sich merklich unterhalb von acht Bit. Die veröffentlichten Full-Precision-Benchmarks sagen wenig — messen Sie auf dem Quant-Niveau, das Ihre Hardware tatsächlich erlaubt, und akzeptieren Sie, dass das die Rangliste umkehren kann.

  3. 03 — Lizenzbedingungen

    Dürfen Sie es so verwenden, wie Sie es vorhaben?

    Offene Gewichte bedeuten nicht zwingend offene Lizenzen. Manche erlauben breite kommerzielle Nutzung ohne Auflagen; andere enthalten Nutzungsschwellen, Attributionspflichten oder Vertriebsbeschränkungen. Lesen Sie die Lizenz vor dem Aufbau, nicht danach. Eine großzügige Lizenz mit etwas weniger Qualität schlägt meist eine restriktivere, die Ihre Rechtsabteilung letztlich ablehnen wird.

  4. 04 — Ökosystem-Unterstützung

    Ist der Serving-Stack roh oder ausgereift?

    Ein Modell mit erstklassiger Unterstützung in vLLM, Ollama und llama.cpp ist um Größenordnungen günstiger zu betreiben als eines, das lediglich ein Referenzskript und eine hoffnungsvolle README mitbringt. Die Tooling-Reife ist der versteckte Kostenfaktor, den die meisten Teams unterschätzen — er zeigt sich in den Engineer-Stunden, die Sie bei Incidents aufwenden.

  5. 05 — Latenz auf Ihrer Hardware

    Generiert es schnell genug für den Anwendungsfall?

    Ein selbst-gehostetes Modell, das auf der GPU, die Sie sich leisten können, zehn Tokens pro Sekunde produziert, ist ein Modell, das Sie nicht für Chat einsetzen können. Messen Sie Tokens-pro-Sekunde unter realistischer Gleichzeitigkeit auf genau der Karte, die Sie deployen wollen — Werte von jemand anderem H100 übertragen sich nicht auf Ihre L40S.

Tokonomix Top 5 Picks für selbst-gehostetes Deployment heute

Was folgt, ist die Auswahl, die wir nächste Woche tatsächlich auf Bare Metal deployen würden. Self-Hosting belohnt eine andere Auswahl als die Welt der gehosteten APIs — das richtige Hauptmodell ist meist das größte, das auf der GPU bei dem Quant-Niveau, das Sie tolerieren, noch Spielraum lässt. Ergänzen Sie es durch ein kleineres Modell hinter einem Router für Anfragen, die das große nicht benötigen, und die Wirtschaftlichkeit beginnt sich zu Ihren Gunsten zu verschieben.

#1 · Referenz Open-Weight

Meta-Llama-3_3-70B-Instruct

via OVH AI Endpoints (GRA)

Der De-facto-Ausgangspunkt jeder Open-Weight-Diskussion. Starke Instruktionsbefolgung, breite Sprachabdeckung und ein Community-Ökosystem (Ollama, vLLM, llama.cpp), das tiefer reicht als jede Alternative. Benötigt ernsthafte Hardware — zwei Consumer-GPUs oder eine Rechenzentrum-Karte — aber die Qualität in dieser Größe rechtfertigt den Aufwand.

Input / 1M Tokens
$0.6700
Output / 1M Tokens
$0.6700
Kontext
Vollständiges Benchmark-Profil →
#2 · Sweet Spot für eine einzelne GPU

Qwen3-32B

via OVH AI Endpoints (GRA)

Passt komfortabel auf eine einzelne High-End-Consumer-Karte bei vernünftiger Quantisierung, mit Qualität nahe dem größeren Llama für die meisten Workloads. Die richtige Wahl, wenn das Budget eine Karte bedeutet, keinen Cluster, und Englisch nicht die einzige Sprache ist, die das Modell gut beherrschen muss.

Input / 1M Tokens
$0.0800
Output / 1M Tokens
$0.2300
Kontext
Vollständiges Benchmark-Profil →
#3 · Europäische Wahl

Mistral-Small-3.2-24B-Instruct-2506

via OVH AI Endpoints (GRA)

Permissiv lizenzierte Open Weights eines europäischen Anbieters, auf EU-resider Infrastruktur gehostet und auf Sprachen abgestimmt, die US-Modelle oft nur dünn abdecken. Eine naheliegende Wahl für Teams, deren Beschaffungsregeln EU-Herkunft bevorzugen oder deren Nutzer etwas anderes als die Top-drei-Sprachen sprechen. Lesen Sie stets die Lizenzangabe auf der Modellkarte, bevor Sie es kommerziell einsetzen.

Input / 1M Tokens
$0.0900
Output / 1M Tokens
$0.2800
Kontext
Vollständiges Benchmark-Profil →
#4 · Googles offener BeitragTier C

gpt-oss-120b

via OVH AI Endpoints (GRA)

Starkes General-Purpose-Instruct-Modell mit permissiver Lizenz und guter multimodaler Unterstützung in den Vision-Varianten. Kleiner als die Llama- und Qwen-Flaggschiffe, liefert aber weit mehr als seine Größe vermuten lässt; eine vernünftige Standardwahl, wenn Ökosystem-Reife mehr zählt als die absolute Leaderboard-Spitze.

Input / 1M Tokens
$0.0800
Output / 1M Tokens
$0.4000
Kontext
Vollständiges Benchmark-Profil →

Gehostete Preisreferenz (wenn Sie nicht selbst hosten)

Self-Hosting ist eine Option; die andere ist der Kauf von Inference bei einem Anbieter, der dieselben Open-Weight-Modelle für Sie betreibt. Das Diagramm zeigt den aktuellen gehosteten Preis pro Million Output-Tokens für die Picks, die einen veröffentlichen — nützlich als Plausibilitätsprüfung für Ihre eigenen selbst-gehosteten Unit Economics.

Preis pro 1M Output-Tokens, USD, wie von einem Inference-Anbieter veröffentlicht, der das Modell hostet. Modelle ohne veröffentlichten Hosted-Preis sind ausgelassen. Quelle: Live-Anbieterpreise, erfasst von Tokonomix.
GPU-Auslastungs-Dashboard — Konzeptbild
Die Kennzahl, auf die es ankommt: Tokens-pro-Sekunde pro Dollar, gemessen auf Ihrer Hardware.

Feldleitfaden: welches Modell für welche Hardware

Die folgende Zuordnung ist das, was wir für die Beratung eines Teams bei der ersten selbst-gehosteten Modellwahl verwenden würden. Behandeln Sie es als Startpunkt, nicht als Urteil — Tokens-pro-Sekunde auf der eigenen GPU zu messen schlägt jede allgemeine Empfehlung.

Pattern A

Einzelne Consumer-GPU (24-32 GB VRAM)

Workstation oder Entwickler-Laptop mit einer starken Karte. Mistral Small 3.2 oder Qwen3-32B bei Vier-Bit-Quant bieten die beste Qualität pro Karte in diesem Bereich. Serving über Ollama für Benutzerfreundlichkeit oder vLLM für höheren Durchsatz.

Pattern B

Rechenzentrum-Inference-Knoten

Eine L40S, A100 oder H100 dediziert für Inference. Llama 3.3 70B ist der sichere Standard; wechseln Sie zu gpt-oss-120b, wenn die Qualitätslücke zählt und die Hardware es trägt. vLLM mit Paged Attention für das Serving.

Pattern C

Nur-CPU oder Edge-Gerät

Eingebettetes Gerät, Datenschutzmodus auf dem Laptop oder ein Server ohne GPU. Beschränken Sie sich auf kleine Modelle — Gemma 3 4B oder Mistral 7B — betrieben über llama.cpp. Stellen Sie realistische Erwartungen: Die Qualität wird ein gehostetes Tier-A-Modell nicht erreichen.

Pattern D

Verwaltete Open-Weight-Inference

Sie wollen die Lizenz und Herkunft offener Modelle, ohne selbst GPUs zu betreiben. Anbieter wie OVH AI Endpoints servieren Llama, Mistral, Qwen und Gemma auf EU-resider Infrastruktur mit Per-Token-Preisen — ein Mittelweg zwischen vollständigem Self-Hosting und gehosteter Frontier.

Selbst-gehostetes Ops-Setup — Konzeptbild
Der operative Aufwand ist real — kalkulieren Sie Engineer-Zeit ein, nicht nur GPU-Zeit.

Testen Sie auf Ihrer eigenen Hardware, bevor Sie sich festlegen

Leihen Sie sich die GPU aus, auf der Sie deployen wollen. Laden Sie zwei Kandidaten bei dem Quant-Niveau, das Sie tatsächlich ausliefern wollen — nicht die Full-Precision-Version auf einer geliehenen H100 — und schicken Sie dieselben hundert Prompts bei realistischer Gleichzeitigkeit durch beide. Sie werden an einem Nachmittag mehr darüber erfahren, welches Modell zu Ihnen passt, als Ihnen jede Benchmark-Seite in einem Quartal sagen kann.

Lesen Sie dann, was herauskommt. Hat es die Quantisierung verkraftet? Hat der Durchsatz unter gleichzeitiger Last gehalten? Hat die Lizenz die erste Prüfung durch Ihre Rechtsabteilung überstanden? Behandelt Ihr gewählter Serving-Stack es als First-Class-Citizen oder als Nachgedanken? Das Modell, das auf Ihrer Hardware gewinnt, ist das, das in Produktion geht — auch wenn kein Leaderboard es an die Spitze setzt.

Live-Test-Tool öffnen →

Verwandte Use Cases