LLMs vergleichen, ohne sich im Lärm zu verlieren
Wenn jemand fragt, was LLMs sind und wie sie funktionieren, lautet die schnelle Antwort meist „Sprachmodelle, die das nächste Wort vorhersagen“. Das ist richtig, aber unzureichend, um zu entscheiden, welches man verwenden soll. Der praktische Unterschied zwischen einem Modell und einem anderen liegt nicht in dieser Definition, sondern darin, wie sie den Kontext verwalten, wie viel sie pro Million Tokens kosten, wie gut sie lange Anweisungen befolgen und wie weit ihr Aufmerksamkeitsfenster reicht, bevor sie vergessen, was am Anfang der Unterhaltung gesagt wurde.
Dieser Artikel wiederholt nicht die Erklärung aus dem Lehrbuch. Er konzentriert sich auf das, was sich beim Vergleich der meistgenutzten Familien ändert — GPT, Claude, Gemini, Llama und Mistral — und auf die Kriterien, die im professionellen Einsatz wirklich den Unterschied machen: Schlussfolgern mit umfangreichen Dokumenten, Codegenerierung, Betriebskosten und Kontrolle über die Daten.
Wie ein LLM intern funktioniert (gerade genug zum Vergleichen)
Ein LLM ist ein neuronales Netz, das mit einer Transformer-Architektur trainiert wurde. Es verarbeitet Text, indem es ihn in Tokens (Wortfragmente) zerlegt und Wahrscheinlichkeiten für das nächste Token berechnet. Dieser Mechanismus erzeugt, wiederholt angewandt, kohärente Antworten. Für einen Vergleich ist relevant, dass es zwei klar getrennte Phasen gibt:
- Vortraining: Das Modell nimmt Muster aus enormen Textkorpora auf. Hier werden sein allgemeines Wissen und seine grundlegende Schlussfolgerungsfähigkeit definiert.
- Ausrichtung (Fine-Tuning und RLHF): Es wird angepasst, um Anweisungen zu befolgen, schädliche Anfragen abzulehnen und einen bestimmten Ton anzunehmen. Hier werden sein „Charakter“ und seine Folgsamkeit definiert.
Zwei Modelle gleicher Größe können sich je nach Gestaltung dieser zweiten Phase radikal unterschiedlich verhalten. Deshalb führt der Vergleich von „Parametern“ ohne Blick auf die Ausrichtung zu falschen Schlüssen.
Der Kontext ist nicht nur eine Zahl
Die technischen Datenblätter geben Kontextfenster von 128.000, 200.000 oder sogar einer Million Tokens an. In der Praxis nimmt die Qualität der Wiederauffindung innerhalb dieses Fensters ab. Ein Muster, das sich beim Testen von Modellen mit langen Verträgen wiederholt: Informationen in der Mitte des Dokuments werden schlechter wiedergefunden als die am Anfang oder Ende. Es ist der bekannte „Lost in the Middle“-Effekt, der in Branchenstudien zur Bewertung langen Kontexts dokumentiert ist.
Praktische Konsequenz: Wenn du einen 300-seitigen Bericht analysieren willst, reicht es nicht, dass das Modell das Dokument akzeptiert. Es empfiehlt sich, es zu zerlegen, zu indexieren und semantische Wiederauffindung (RAG) durchzuführen, statt darauf zu vertrauen, dass das Modell alles mit derselben Aufmerksamkeit liest.
Vergleich der meistgenutzten Familien
GPT (OpenAI)
Es ist die Referenz wegen seines Ökosystems: ausgereifte API, Tools, Funktionen und eine enorme Community. Es zeichnet sich bei der Codegenerierung und beim Befolgen strukturierter Anweisungen aus (JSON-Ausgaben, Funktionsaufrufe). Seine historische Schwäche war die Weitschweifigkeit und eine gewisse Neigung, dem Nutzer zu gefallen, selbst wenn die Prämisse falsch ist. Für Aufgaben der Datenextraktion mit strengem Format ist es meist die vorhersehbarste Option.
Claude (Anthropic)
Es hat sich stark im Verfassen langer Texte und in der Analyse umfangreicher Dokumente positioniert. Es erzeugt meist Texte mit weniger Füllwörtern und akzeptiert nuancierte Korrekturen besser. Bei Aufgaben der redaktionellen Überarbeitung oder der Zusammenfassung von Verträgen ziehen es viele Teams wegen seines Tons vor. Reale Einschränkung: In manchen sehr spezifischen Code-Workflows bleibt es unter GPT, und seine Integration mit externen Tools kam später.
Gemini (Google)
Sein Vorteil ist die Integration in das Google-Ökosystem: Suche, Workspace, Android. Das große Kontextfenster und der Zugang zu aktuellen Informationen über die Suche machen es nützlich für Aufgaben, die aktuelle Daten erfordern. Die Nuance: Die Variabilität zwischen Versionen (Flash, Pro, Ultra) ist hoch, und die Wahl des falschen Modells für eine Aufgabe kann die Kosten in die Höhe treiben, ohne das Ergebnis zu verbessern.
Llama (Meta)
Es ist die offene Referenzfamilie. Es ermöglicht die lokale Ausführung oder auf eigenen Servern, was Datenschutzanforderungen erfüllt, die Cloud-Modelle nicht abdecken. Gegenstück: Es erfordert Infrastruktur (GPU), Wartung und technisches Know-how. Für ein KMU ohne ML-Team wird die Lizenzersparnis durch die Betriebskosten aufgezehrt.
Mistral
Effiziente Modelle, gut im Verhältnis Qualität/Größe, mit offenen und kommerziellen Optionen. Sie eignen sich gut, wenn ein leichtgewichtiges Modell für Klassifizierung, Extraktion oder Kundenservice mit niedriger Latenz benötigt wird. Es ist nicht die beste Option für komplexes mehrstufiges Schlussfolgern.
Schnelle Entscheidungstabelle
| Bedarf | Vernünftige Option | Warum |
|---|---|---|
| Code generieren und mit APIs automatisieren | GPT | Ökosystem und zuverlässige strukturierte Ausgaben |
| Lange Dokumente analysieren und verfassen | Claude | Sorgfältiger Ton und gute Verwaltung umfangreichen Kontexts |
| Aktuelle Daten und Google-Integration | Gemini | Integrierte Suche und Anbindung an Workspace |
| Datenschutz und lokale Ausführung | Llama | Offenes Modell, volle Kontrolle über die Daten |
| Niedrige Latenz und überschaubare Kosten | Mistral | Effiziente kleine Modelle |
Ein realer Fall, der die Entscheidung verändert
Ein Rechtsteam versuchte, einen 180-seitigen Rahmenvertrag in ein Modell mit einem Fenster von 200.000 Tokens hochzuladen. Die Überraschung: Das Modell zitierte die Klauseln am Anfang und am Ende korrekt, ließ aber eine Vertragsstrafenklausel auf etwa Seite 90 aus. Es war kein Kapazitätsfehler, sondern ein Fehler der verteilten Aufmerksamkeit. Die Lösung bestand nicht darin, das Modell zu wechseln, sondern darin, nach Abschnitten zu zerlegen, mit Embeddings zu indexieren und nach konkreten Klauseln zu fragen. Dies ist die Art von Einschränkung, die in Benchmark-Vergleichen nicht auftaucht und die man erst entdeckt, wenn man das Modell mit echten Dokumenten nutzt.
Was kein LLM gut macht (noch nicht)
Es ist angebracht, es klar zu sagen: Kein aktuelles Modell garantiert Wahrhaftigkeit. Sie können Referenzen, Zahlen oder Zitate mit völliger Sicherheit erfinden. Sie haben auch kein Bewusstsein für ihre Grenzen: Wenn man sie nach einem Datum fragt, das sie nicht kennen, neigen sie dazu, die Lücke zu füllen. Und sie schlussfolgern nicht streng symbolisch: Für Finanzberechnungen oder formale Logik bleibt eine Tabellenkalkulation oder eine Regel-Engine zuverlässiger.
Außerdem können die Kosten pro Token niedrig erscheinen, bis man skaliert. Ein Workflow, der täglich Tausende von Dokumenten verarbeitet, kann eine bescheidene Monatsrechnung in eine beträchtliche Summe verwandeln, wenn das größte Modell für Aufgaben verwendet wird, die ein kleines Modell genauso lösen würde.
Wie man wählt, ohne sich zu irren
- Definiere die Aufgabe: klassifizieren, verfassen, extrahieren, schlussfolgern. Jede hat ein Modell, das sich auszeichnet.
- Messe mit deinen Daten: Öffentliche Benchmarks geben Orientierung, ersetzen aber keinen Test mit hundert echten Beispielen aus deiner Domäne.
- Berechne die Gesamtkosten: nicht nur den Preis pro Token, sondern auch Latenz, Wiederholungen und menschliche Überwachung.
- Prüfe den Datenschutz: Wenn die Daten deine Infrastruktur nicht verlassen dürfen, reduziert sich die Entscheidung auf offene Modelle.
- Bereite den Austausch vor: Die Verwendung einer Abstraktionsschicht (wie Bibliotheken vom Typ LangChain oder einheitliche Clients) verhindert, an einen Anbieter gebunden zu sein.
Der nützliche Vergleich ist nicht „welches ist das beste Modell“, sondern „welches ist das beste für diese Aufgabe, mit diesem Budget und diesen Einschränkungen“. Diese Frage ändert sich alle paar Monate, und deshalb empfiehlt es sich, den Workflow so aufzubauen, dass man die Engine wechseln kann, ohne alles neu zu machen.