Die Wahl eines Sprachmodells ist heute keine Glaubensfrage. Sie ist eine Ingenieursentscheidung, die Kosten, Latenz, Datenschutz und Ausgabequalität beeinflusst. Und um gut zu entscheiden, lohnt es sich zu verstehen, was unter dieser Blackbox steckt, die wir LLM nennen. Diese Vergleichsanalyse handelt nicht davon, „welches das beste ist», sondern davon, warum sich jede Modellfamilie je nach Aufgabe unterschiedlich verhält und worauf du achten solltest, bevor du eines in deinen Workflow integrierst.
Die gemeinsame Architektur: Alle basieren auf demselben Trick
Die aktuellen Modelle (GPT, Claude, Gemini, Llama, Mistral) sind direkte Nachfahren des Transformers, der im Paper Attention Is All You Need (2017) vorgestellt wurde. Die zentrale Idee: Text parallel zu verarbeiten, mittels Attention-Mechanismen, die gewichten, welche Wörter des Kontexts für die Vorhersage des nächsten wichtiger sind. Das Training erfolgt mit Gradientenabstieg über Milliarden von Tokens, und die Ausgabe ist eine Wahrscheinlichkeitsverteilung über das nächste Token.
Dieses Detail ist wichtig: Das Modell „weiß» nichts im strengen Sinne. Es berechnet Wahrscheinlichkeiten. Deshalb kann es sicher klingen, während es ein bibliografisches Zitat erfindet. Der Unterschied zwischen den Modellen liegt nicht im Konzept, sondern darin, wie sie nach dem Pretraining abgestimmt werden (RLHF, DPO, Constitutional AI) und in der Menge und Qualität der Daten, die sie sehen.
Vergleich der vier am häufigsten verwendeten Familien
GPT (OpenAI): Das breiteste Ökosystem
Die GPT-4o-Familie und ihre Mini-Varianten bieten native Multimodalität (Text, Bild, Audio) und eine sehr gut dokumentierte API. Ihre Stärke ist die Integration: Plugins, Assistenten, ausgereiftes Function Calling. Ihre praktische Schwäche ist die Undurchsichtigkeit beim Training und die Abhängigkeit von einem einzigen Anbieter. Für schnelle Prototypen und Drittanbieter-Tools ist es der Weg mit der geringsten Reibung.
Claude (Anthropic): Langer Kontext und nuancierte Antworten
Claude zeichnet sich durch umfangreiche Kontextfenster (Hunderttausende Tokens in seinen neueren Versionen) und durch ein konservatives Verhalten bei mehrdeutigen Anweisungen aus: Es neigt dazu, um Klärung zu bitten, statt zu improvisieren. Bei der Analyse langer Dokumente oder der Code-Überprüfung ist diese Vorsicht willkommen. Bei reiner kreativer Generierung wirkt es manchmal weniger risikofreudig als gewünscht.
Gemini (Google): Integration in das Ökosystem und Multimodalität
Die Versionen Flash und Pro sind darauf ausgelegt, mit Google-Diensten (Workspace, Vertex AI, Suche) zusammenzuarbeiten. Ihr langer Kontext und ihre multimodale Fähigkeit sind wettbewerbsfähig. Die Kehrseite: Dokumentation und Quotenlimits ändern sich häufig, und die Unterschiede zwischen Flash- und Pro-Versionen beeinflussen die Qualität des Schlussfolgerns stark.
Llama und Mistral: Offene Gewichte und volle Kontrolle
Hier ist die Logik eine andere. Die Gewichte sind verfügbar (mit Lizenzen, die man lesen sollte, denn nicht alle sind gleich permissiv). Du kannst sie lokal oder in deiner Cloud ausführen, sie mit Fine-Tuning anpassen und das Verhalten auditieren. Der Preis ist die Infrastruktur: Ein Modell mit 70B Parametern in FP16 benötigt etwa 140 GB VRAM nur für die Gewichte, plus Speicher für den Kontext. Die Quantisierung auf 4 Bit reduziert diese Zahl auf einen handhabbaren Bereich bei High-End-GPUs, führt aber zu messbarer Verschlechterung bei Schlussfolgerungsaufgaben.
Was du wirklich vergleichen solltest, bevor du wählst
- Reales versus effektives Kontextfenster: Dass ein Modell 200.000 Tokens ankündigt, bedeutet nicht, dass es über diesen gesamten Bereich die Kohärenz aufrechterhält. Die beeinträchtigte Attention an mittleren Positionen (das Phänomen lost in the middle) ist in Branchenstudien dokumentiert. Teste mit deinem eigenen langen Dokument, bevor du dich verlässt.
- Latenz und Kosten pro Token: Ein großes Modell kann mehrere Sekunden brauchen, um eine vollständige Antwort zu generieren. Für interaktiven Chat gewinnen kleine, angepasste Modelle oft bei der wahrgenommenen Geschwindigkeit.
- Verhalten bei Ablehnung: Alle haben Filter. Der Unterschied liegt darin, wie viele falsche Positive sie erzeugen. Ein Modell, das eine legitime medizinische Anfrage aus übermäßiger Vorsicht ablehnt, ist ein operatives Problem.
- Determinismus und Temperatur: Bei Temperatur 0 ist die Ausgabe bei den meisten APIs zwischen Aufrufen nicht vollständig reproduzierbar. Wenn du identische Ergebnisse benötigst, musst du die Ausgabe cachen oder validieren.
Ein konkreter Fall: Der Fehler, den Kontext nach der Ankündigung zu bemessen
Vor einigen Monaten, bei der Arbeit an der Extraktion von Klauseln aus Mietverträgen, stellten wir fest, dass ein Modell mit einem Fenster von 128.000 Tokens begann, Klauseln in der Mitte des Dokuments auszulassen, wenn dieses 60 Seiten überschritt. Die Lösung war nicht, das Modell zu wechseln, sondern das Dokument in Abschnitte zu unterteilen und Teilzusammenfassungen zu verketten. Es ist ein Muster, das sich wiederholt: Das angekündigte Limit ist nicht das nützliche Limit. Wer LLMs in der Produktion integriert, lernt schnell, dass die Kontext-Engineering (was du hineingibst und in welcher Reihenfolge) mehr wiegt als die Wahl der Modellmarke.
Ein weiterer häufiger Fehler: anzunehmen, dass ein Modell mit besseren allgemeinen Benchmarks in deiner Domäne besser sein wird. Bewertungen wie MMLU oder HumanEval messen breite Fähigkeiten, nicht deinen Anwendungsfall. Der einzige gültige Test ist ein eigener Evaluationsdatensatz mit realen Beispielen aus deinem Geschäft und definierten Akzeptanzkriterien.
Einschränkungen, die noch kein Modell löst
LLMs haben kein persistentes Gedächtnis zwischen Sitzungen, es sei denn, du baust es (RAG, Vektordatenbanken, Verlauf). Sie überprüfen keine Fakten selbst: Wenn du sie nach einer Zahl fragst, werden sie diese mit derselben Sicherheit generieren wie eine korrekte. Sie schlussfolgern nicht zuverlässig symbolisch bei Problemen der formalen Logik mit vielen Variablen. Und sie sind allein nicht geeignet für medizinische, rechtliche oder finanzielle Entscheidungen ohne menschliche Aufsicht: Die offizielle Dokumentation der Anbieter selbst warnt davor.
Ebenso wenig sollte man sie als Orakel der Aktualität nutzen. Ihr Wissen hat ein Stichdatum, und obwohl einige eine Websuche integrieren, fügt diese Integration Latenz und eine zusätzliche Fehlerebene hinzu (welche Quelle sie wählen, wie sie sie zitieren).
Wie man in der Praxis entscheidet
Für Klassifizierungs- und Extraktionsaufgaben mit hohem Volumen ist ein kleines Modell mit Fine-Tuning oft günstiger und vorhersehbarer als ein großes. Für komplexes Schlussfolgern und lange Dokumente sparen Modelle mit erweitertem Kontext Architektur. Für sensible Daten, die deine Infrastruktur nicht verlassen dürfen, sind offene Gewichte der einzige realistische Weg, unter Inkaufnahme der Wartungskosten. Und für Prototypen spart dir die API mit der besten Dokumentation und Community Tage.
Keine Wahl ist endgültig: Die Modelle ändern sich alle paar Monate, und was heute Referenz ist, ist morgen veraltet. Gestalte deine Integration mit einer Abstraktionsschicht über dem Anbieter und einem eigenen Evaluationsdatensatz. Das ermöglicht dir, das Modell zu wechseln, ohne das Produkt neu zu schreiben, was die rentabelste Entscheidung langfristig ist.
Und eine abschließende Warnung zur Transparenz: Es gibt kein Modell, das korrekte Antworten garantiert. Die Qualität hängt vom Kontext ab, den du ihm gibst, davon, wie du die Anweisung formulierst, und von der Validierung, die du danach einbaust. Jedes Versprechen unfehlbarer Ergebnisse sollte man mit Distanz betrachten.