Der Markt für Sprachmodelle hat sich im letzten Jahr so rasant verändert, dass der alte Ansatz – ein einziges Frontier-Modell wählen und alles damit erledigen – nicht mehr funktioniert. Heute stehen Open-weight-Modelle mit millionenweiten Kontextfenstern, Cloud-APIs zu Preisen nahe null, lokale Deployments auf einem einzigen Server und milliardenschwere MoE-Architekturen zur Verfügung, die kleiner sind, als sie aussehen. Gleichzeitig gilt: Ein Modell ohne Rahmen auszuwählen ist Lotterie – nicht wegen der Modellqualität, sondern weil die meisten Entscheidungen ohne klare Aufgabenstellung getroffen werden.
Dieser Artikel liefert einen konkreten Entscheidungsrahmen. Vier Dimensionen – Aufgabe, Infrastruktur, Preis und Datenschutz – und für jede eine Reihe von Filtern, die die Kandidatenliste auf zwei oder drei Finalisten verkürzen. Konkrete Zahlen stammen aus verifizierten Quellen; wo Zahlen unklar sind, sagen wir das direkt.
Schritt 1 — Definieren Sie, was das Modell tut (und was nicht)
Vor der Modellauswahl muss klar sein, welcher Aufgabentyp gelöst werden soll. Sprachmodelle sind nicht in allen Bereichen gleich stark, und ein Modell, das bei Arithmetik gewinnt, kann bei langen Dokumenten verlieren.
Drei Grundkategorien von Aufgaben:
- Extraktion und Klassifikation: Datenextraktion aus Scans, Ticket-Labeling, Zusammenfassung. Kleinere Modelle reichen aus. Latenz und Throughput sind kritischer als rohe Intelligenz.
- Generierung und Reasoning: Berichte schreiben, Vertragsanalyse, Coding, Planung. Hier zählt Benchmark-Qualität – bevorzugen Sie Frontier-Modelle oder starke Open-weight-Modelle der Familien Llama, Qwen oder Mistral.
- Langer Kontext: Analyse umfangreicher Dokumentation, Unternehmensarchive, Zusammenfassung von Protokollen. Hier unterscheiden sich Modelle dramatisch – nicht alle bewältigen Retrieval inmitten von Megabytes gleich gut, selbst wenn das Kontextfenster nominell existiert.
Sobald Sie den Aufgabentyp kennen, wissen Sie, worauf Sie bei Benchmarks achten müssen: MMLU, HumanEval und GSM8K für allgemeines Reasoning und Code; IFEval für Instruction-Following; RULER oder Needle-in-a-haystack-Tests für langen Kontext. Lesen Sie Benchmarks jedoch sorgfältig – sie messen spezifische Bedingungen, nicht die Produktionsrealität. Mehr dazu im Artikel LLM-Benchmarks richtig lesen.
Schritt 2 — Open-weight vs. Cloud-API: das ist die eigentliche Entscheidungsachse
Nicht „welches Modell", sondern „wo läuft es". Diese Entscheidung bestimmt 80 % der übrigen Parameter.
Cloud-API (Anthropic, OpenAI, Google, Mistral, DeepSeek)
Vorteile: - Kein Infrastruktur-Overhead – Sie zahlen für Tokens, nicht für GPUs - Höchste Leistung in allen Kategorien (Frontier-Modelle führen Benchmarks an) - Kontextfenster ohne Beschränkung durch eigenes VRAM - SLA und Verfügbarkeit verantwortet der Provider
Einschränkungen: - Ihre Daten und Prompts verlassen Ihre Infrastruktur - Preise sind variabel; bei großen Volumen können Monatskosten fünfstellig werden - Regulierte Branchen (Gesundheitswesen, Recht, Finanzen) haben strenge Einschränkungen beim Data Egress
Orientierungspreise 2026: Frontier-Modelle (Claude Opus, GPT-5.x) liegen je nach Tier in der Größenordnung von $3–25 pro Million Eingabe-Tokens. DeepSeek und ähnliche Modelle chinesischer Familien über API sind typischerweise rund 10–30-mal günstiger als US-Frontier. Die Preise sind im letzten Jahr deutlich gefallen, sodass alte Kalkulationen nicht mehr gelten.
On-Prem / lokales Deployment (Open-weight-Modelle)
Vorteile: - Daten verlassen das Netzwerk nicht – der einzige Weg für GDPR-sensible oder geheime Betriebe - Vorhersehbare Kosten (Hardware + Energie) nach der Anfangsinvestition - Vollständige Kontrolle über Modell, Prompt-Logs und Versionen
Einschränkungen:
- Einmalige GPU-Investition und IT-Overhead
- Schlechtere Leistung als Frontier-Cloud-Modelle (der Abstand verringert sich, existiert aber)
- Sie benötigen eine Serving-Schicht – vLLM, SGLang oder Ollama (für produktives Serving scheidet Ollama aus, mehr dazu weiter unten)
Wenn Sie diese Entscheidung systematisch angehen, lesen Sie die detailliertere Analyse in Lokale LLM vs. Cloud. Für regulierte Branchen gelten weitere Bedingungen – On-Prem-Eliminierung von Data Egress reicht für Compliance ohne Audit-Logs und gesteuerte Zugriffe nicht aus, was On-Prem LLM für regulierte Branchen behandelt.
Schritt 3 — Modellgröße: größer ist nicht immer besser
Der Open-weight-Markt 2026 ist voll von MoE-Architekturen (Mixture of Experts). Was das in der Praxis bedeutet: Ein Modell mit dem Namen „400B Parameter" kann bei einer einzelnen Inference-Anfrage nur ~17 Milliarden aktivieren. Parameteranzahl und aktive Parameter sind zwei verschiedene Zahlen.
Praktische Konsequenzen für die Auswahl:
- MoE-Modelle (z. B. Llama 4 Maverick, Qwen 3.x MoE-Varianten, Mixtral, DeepSeek V3): Geringerer Compute bei der Inferenz, aber Sie müssen das gesamte Modell auf Disk und in VRAM laden. Große MoE-Modelle haben hunderte Milliarden Parameter, von denen bei jedem Token nur ein Bruchteil aktiv ist – VRAM benötigen sie jedoch für das gesamte Modell. Die naive Betrachtung der „aktivierten Parameter" unterschätzt daher die Hardware-Anforderungen.
- Dense-Modelle (Gemma 3, Phi-4, ältere Llama 3.x): Unkomplizierteres Deployment; Parameteranzahl ≈ Compute. Phi-4 oder kleinere Gemma-3-Modelle sind hervorragend für Edge-Deployments und eingebettete Anwendungsfälle.
Orientierungswerte für VRAM-Bedarf (ohne KV-Cache) bei gängigen Größen:
- 7–9B-Modell: Q4_K_M-Format ≈ 5–7 GB VRAM; FP16 ≈ 16–19 GB
- 13B-Modell: Q4_K_M ≈ 8 GB; FP16 ≈ 26 GB
- 70B-Modell: Q4_K_M ≈ 35–40 GB; FP16 ≈ 140–168 GB
Quantisierung (GGUF Q4_K_M, AWQ 4-bit) ist nicht automatisch schlecht – bei den meisten Benchmarks liegt sie innerhalb von 5–8 % gegenüber FP16-Qualität. Deutliche Degradierung tritt erst bei Q2 und darunter auf. Mehr über Techniken und ihre Unterschiede in LLM-Quantisierung (GGUF, AWQ, GPTQ).
Für die meisten B2B-Use-Cases gilt: Ein gut feinabgestimmtes 13B-Modell übertrifft ein generisches 70B-Modell in einer engen Domäne. Vor der Entscheidung über die Größe lohnt es sich zu prüfen, ob genügend Daten für Fine-tuning vorhanden sind – dazu RAG vs. Fine-tuning.
Schritt 4 — Latenz und Throughput: wer ist Ihr Nutzer?
Zwei grundlegend unterschiedliche Profile mit unterschiedlichen Anforderungen:
Interaktiver (nutzerorientierter) Chat oder Copilot: Latenz ist kritisch. Das erste Token sollte innerhalb von 1–2 Sekunden ankommen. Hier ist TTFT (Time to First Token) relevant. Ein kleineres Modell, das schnell antwortet, ist besser als ein großes, das wartet.
Batch-Verarbeitung: Throughput ist kritisch. Es kommt auf Tokens pro Sekunde über den gesamten Batch an. Hier lohnt sich ein größeres Modell auf Kosten höherer Latenz pro Request, weil Sie zehntausende Dokumente auf einmal verarbeiten.
Für die Serving-Infrastruktur: vLLM ist die Produktionswahl für die meisten NVIDIA-Deployments – PagedAttention reduziert die KV-Cache-Fragmentierung dramatisch (von typischerweise 60–80 % Verschwendung auf unter 4 %) und Continuous Batching steigert den Throughput 2–3-fach gegenüber statischem Batching. SGLang ist stärker bei prefix-heavy Workloads (RAG, Agents, Multi-Turn) – Benchmarks zeigen ~29 % höheren Throughput auf H100 und ~23 % schnelleres TTFT gegenüber vLLM.
Ollama eignet sich für einen einzelnen Entwickler am Desktop, nicht für produktive Multi-User-Deployments. Bei mehreren parallelen Nutzern ist der Durchsatz deutlich niedriger als bei vLLM.
Schritt 5 — Kosten: wo wirklich bezahlt wird
Der Cloud-LLM-API-Markt ist heute preislich deutlich günstiger als vor einem Jahr. Aber es gibt nach wie vor Fallen.
Kontextfenster ≠ günstigere Lösung. Ein 1M-Token-Kontext bedeutet nicht, dass Sie immer eine Million Tokens hineinschicken – Sie zahlen für jedes Token, das Sie senden. Der KV-Cache wächst linear mit der Sequenzlänge. Beispielsweise benötigt ein 70B-Modell bei 128K Kontext allein ~40 GB KV-Cache; für vier parallele Anfragen bei 128K sind das ~160 GB zusätzlich zum Modell selbst. Das Kontextfenster ist eine Kapazität, keine Konstante.
Prompt Caching ist ein wichtiges Instrument zur Kostensenkung bei wiederkehrenden System-Prompts. Orientierungswert: Bei einem guten Workload sparen Sie 50–70 % der Kosten für Eingabe-Tokens. Aber Cache-Write-Tokens sind auf einigen Plattformen 1,25–2-fach teurer als normale – die Einsparung tritt erst bei wiederholtem Lesen desselben Präfixes auf. Workloads mit einzigartigen langen Prompts profitieren nicht vom Caching. Mehr in Prompt Caching und Kosten.
Routing (Aufruf eines günstigen Modells für einfache Fragen, eines teuren nur für komplexe) kann bei gut kalibrierter Konfiguration 95 % der Qualität bei einem Bruchteil der Kosten erhalten. Forschung aus Berkeley zeigte, dass bei einem richtigen Router 75–90 % der Aufrufe auf das kleinere Modell entfallen. Das ist einfach zu implementieren, erfordert aber Baseline-Evals – ohne Messung weiß man nicht, wo die Grenze liegt.
Schritt 6 — Lizenzen und Nutzungsbedingungen
Das wird vernachlässigt, bis es zum Problem wird.
Open-weight-Modelle sind nicht automatisch für jeden Einsatz frei:
- Llama 4 (Meta): Meta-Custom-Lizenz. Einschränkungen bei Deployments mit mehr als 700 Millionen monatlich aktiven Nutzern. Für die meisten B2B-Unternehmensdeployments ist die Einschränkung nicht relevant, aber sie sollte gelesen werden.
- Qwen 3.x: Apache 2.0 – kommerzielle Nutzung, Modifikation und Distribution ohne Gebühren. Mistral: Kleinere Modelle (z. B. Mistral Small) sind Apache 2.0, größere (Mistral Large) haben eine eigene Mistral-Lizenz – beim konkreten Modell prüfen.
- DeepSeek V3: MIT-Lizenz – maximale Freiheit einschließlich Fine-tuning und Weiterverteilung.
- Gemma 3 (Google): Eigene Gemma-Lizenz – erlaubt kommerzielle Nutzung, ist aber keine OSI-genehmigte Open-Source-Lizenz. Bedingungen sorgfältig lesen.
- Phi-4 (Microsoft): MIT.
Bei Closed-weight-Cloud-APIs (Claude, GPT-5.x, Gemini) sind die Bedingungen durch SLA und Terms of Service geregelt – Achtung auf Data-Retention-Policy und Opt-out aus Trainingsdaten.
Regulierte Branchen sollten einen DPA (Data Processing Agreement) unterzeichnet haben, bevor der erste Produktionsaufruf erfolgt.
Schritt 7 — Kontextfenster: wann 1M hilft und wann nicht
Fast jedes Flaggschiff-Modell 2026 hat ein Kontextfenster von mindestens 128K Tokens. Llama 4 Scout kommt auf bis zu 10M. Claude (höhere Tiers), Gemini 2.5 und Llama 4 Maverick bieten 1M; DeepSeek V3 hat 128K.
Die Frage ist nicht „welches hat den größeren Kontext", sondern „brauche ich ihn?".
Forschungsergebnisse zeigen, dass Modelle mit wachsendem Kontext „Context Rot" aufweisen – die Retrieval-Genauigkeit sinkt, wenn relevanter Inhalt von großen Mengen irrelevanten Textes umgeben ist. Das gilt besonders bei Multi-Hop-Fragen, bei denen Informationen aus verschiedenen Stellen des Dokuments kombiniert werden müssen.
Praktische Faustregel: Wenn Ihr Use-Case lange Dokumente (Verträge, technische Handbücher, Archive) umfasst, die Abfragen aber gezielter Natur sind, ist RAG wirtschaftlicher und präziser als das direkte Einspeisen des gesamten Dokuments in den Kontext. Langer Kontext ist sinnvoll, wo Sie wirklich brauchen, dass das Modell das gesamte Dokument auf einmal liest – Generierung eines Abstracts aus einem 200-seitigen Bericht, Analyse einer Codebasis.
Praktischer Entscheidungsbaum
Dieses Vorgehen schränkt das Feld in der Praxis auf zwei bis drei Finalisten ein:
- 1.Dürfen Daten Ihr Netzwerk verlassen? → Nein: Open-weight + lokales Serving. Ja: weiter.
- 2.Sind Throughput oder Latenz kritisch und das Volumen hoch? → Ja: lokales Serving erwägen. Nein: Cloud-API.
- 3.Was ist die Aufgabe? → Einfache Extraktion/Klassifikation: kleines Modell (7–13B oder günstiges API). Komplexes Reasoning: Frontier oder starkes 70B+.
- 4.Haben Sie eine spezifische Domäne mit ausreichend Daten? → Fine-tuning eines kleineren Modells erwägen, bevor ein größeres gekauft wird.
- 5.Wie lautet die Lizenz? → Filtern nach Apache 2.0 / MIT für produktive kommerzielle Deployments ohne rechtlichen Overhead.
Häufige Fragen
Welches Open-weight-Modell ist derzeit das beste?
Es gibt nicht das eine richtige. Im Jahr 2026 führen bei verschiedenen Benchmarks Modelle wie Llama 4 Maverick, Qwen 3.x, DeepSeek und Mistral Large – abhängig von der Aufgabe. Für Code und Reasoning sind Modelle der Qwen-Familie stark, für langen Kontext sticht Llama 4 Scout heraus (10M-Kontextfenster). Testen Sie immer auf eigenen Daten, nicht nur auf öffentlichen Benchmarks.
Ist DeepSeek für den europäischen Einsatz zuverlässig?
DeepSeek bietet offene Gewichte mit MIT-Lizenz – das Modell kann heruntergeladen und lokal betrieben werden, ohne jeglichen Aufruf chinesischer Server. Aus GDPR-Sicht ist ein lokales DeepSeek-Deployment genauso „sauber" wie Llama oder Mistral. Die Cloud-API-Version über DeepSeek-Server ist eine andere Frage – hier gelten dieselben Data-Egress-Überlegungen wie bei US-Providern.
Was ist MoE und muss ich mich damit bei der Auswahl befassen?
MoE (Mixture of Experts) ist eine Architektur, bei der das Modell bei jedem Token nur einen Teil der Parameter aktiviert. Praktische Konsequenz: geringerer Compute bei der Inferenz, aber höherer gesamter VRAM-Footprint. Wenn Sie lokal deployen, müssen Sie das gesamte Modell in den Speicher laden, auch wenn bei jedem Token nur ein Bruchteil genutzt wird. Bei einer Cloud-API interessiert Sie dieses Detail nicht – Sie zahlen für aktive Parameter.
Lohnt sich Fine-tuning statt eines größeren Modells?
In vielen Fällen ja – aber nur wenn genügend qualitativ hochwertige Daten und eine klar definierte Domäne vorhanden sind. Ein gut feinabgestimmtes 13B-Modell kann ein generisches 70B-Modell bei einer engen industriellen Aufgabe übertreffen. Ohne ausreichend Daten (für SFT benötigen Sie grob tausende qualitativ hochwertige Beispiele) schadet Fine-tuning eher als es nützt. Über die Entscheidung zwischen RAG und Fine-tuning schreiben wir in RAG vs. Fine-tuning.
Wie stelle ich fest, ob ich richtig gewählt habe?
Die richtige Wahl wird durch Evaluierungen auf eigenen Daten und Use-Cases überprüft – nicht nur durch Benchmark-Vergleiche. Definieren Sie 50–100 Testfälle mit erwartetem Output, führen Sie diese auf den Kandidaten aus und vergleichen Sie. Diesen Prozess beschreiben wir ausführlich in Wie misst man die Qualität einer LLM-Anwendung.
*Bei MP Industrial Solutions begleiten wir Unternehmen strukturiert durch die Modellauswahl – von der Erfassung der Use-Cases über das Testen der Kandidaten bis zum produktiven Deployment auf eigener Infrastruktur. Wenn Sie vor dieser Entscheidung stehen und teure Sackgassen vermeiden möchten, sprechen wir gerne mit Ihnen.*