Wenn Sie zum ersten Mal mit einem Large Language Model arbeiten, passiert etwas Merkwürdiges: Sie stellen eine Frage, bekommen eine Antwort, und irgendwo dazwischen läuft ein Prozess ab, der sich erstaunlich anders anfühlt als alles, was Sie bisher programmiert haben. Keine if-Bedingungen, keine expliziten Regeln, keine Datenbankabfrage mit vorhersehbarem Ergebnis. Stattdessen: Sie werfen Text hinein, und Text kommt heraus. Was dazwischen passiert, wirkt zunächst wie Magie.
Ist es aber nicht. Es ist Mathematik. Sehr viel Mathematik.
Ein Large Language Model ist, technisch gesehen, eine trainierte Funktionsapproximation. Eine gigantische, hochdimensionale Funktion, die gelernt hat, Muster in Texten zu erkennen und zu reproduzieren. Wenn wir verstehen wollen, wie wir diese Funktion in produktionsnahen Systemen einsetzen, müssen wir verstehen, was ein “Modell” in diesem Kontext eigentlich ist. Nicht als abstrakte Idee, sondern als konkrete technische Einheit, die wir auswählen, deployen, betreiben müssen.
Denn das ist das Erste, was viele überrascht: Es gibt nicht “das” Large Language Model. Es gibt Tausende. Und die Entscheidung, welches Sie verwenden, ist keine Nebensache. Sie bestimmt, was Ihre Anwendung kann, was sie kostet, wo sie läuft, wem sie gehört.
Beispiel: Sie wollen einen Spam-Filter bauen. Der traditionelle Ansatz wäre, Regeln zu definieren – wenn die E-Mail mehr als drei Ausrufezeichen enthält, wenn sie von einer verdächtigen Domain kommt, wenn bestimmte Schlüsselwörter auftauchen. Sie codieren Ihr Wissen darüber, was Spam ausmacht, direkt in den Programmcode.
Ein Modell dreht diesen Ansatz um. Sie geben dem System Tausende Beispiele von Spam und Nicht-Spam. Das System lernt selbst, welche Muster relevant sind. Es baut eine interne Repräsentation auf – eine mathematische Struktur, die diese Muster kodiert. Diese Struktur nennen wir das Modell.
Bei neuronalen Netzen, und damit auch bei Large Language Models, besteht diese Struktur aus Millionen oder Milliarden von Parametern. Jeder Parameter ist im Grunde nur eine Zahl, ein Gewicht in einer gigantischen Matrix. Aber zusammen bilden diese Zahlen ein System, das erstaunlich komplexe Aufgaben lösen kann.
Wenn Sie ein trainiertes Large Language Model herunterladen – sagen wir, Llama 3.1 mit 8 Milliarden Parametern – dann laden Sie im Wesentlichen eine riesige Datei herunter, die diese Gewichte enthält. Keine Logik, keine Regeln, keine Datenbank mit Fakten. Nur Zahlen. Aber diese Zahlen wurden so optimiert, dass sie eine bestimmte Aufgabe extrem gut lösen können: die Vorhersage des nächsten Tokens in einer Sequenz.
Das klingt simpel. Ist es aber nicht. Denn um die Aufgabe “nächstes Token vorhersagen” gut zu lösen, muss das Modell implizit eine Menge anderer Dinge gelernt haben: Syntax, Semantik, Weltwissen, Argumentation, manchmal sogar ein bisschen Logik. All das steckt kodiert in diesen Parametern.
Fast alle modernen Large Language Models basieren auf der Transformer-Architektur. Das ist wichtig zu verstehen, nicht weil Sie die mathematischen Details kennen müssen, sondern weil diese Architektur bestimmte Eigenschaften mit sich bringt, die Ihre Arbeit beeinflussen.
Transformer verarbeiten Text nicht linear, Wort für Wort, wie es frühere Architekturen taten. Stattdessen betrachten sie den gesamten Kontext gleichzeitig, durch einen Mechanismus namens Attention. Jedes Token kann potenziell mit jedem anderen Token in Beziehung gesetzt werden. Das macht Transformer mächtig – aber auch hungrig nach Rechenleistung und Speicher.
Die Parameterzahl eines Modells ist eine grobe Metrik für seine Komplexität. Ein Modell mit 7 Milliarden Parametern ist nicht unbedingt “besser” als eines mit 3 Milliarden – aber es hat mehr Kapazität, komplexere Muster zu kodieren. Gleichzeitig braucht es mehr Speicher, mehr Rechenzeit, mehr Energie. In der Praxis ist die Parameterzahl ein Trade-off: Zwischen Leistungsfähigkeit und Ressourcenverbrauch, zwischen Genauigkeit und Geschwindigkeit.
Was bedeutet das konkret? Die folgende Tabelle zeigt die praktischen Implikationen verschiedener Modellgrößen:
| Parameterzahl | Speicherbedarf (16-bit) | Hardware-Anforderung | Typischer Einsatz |
|---|---|---|---|
| 3B | ~6 GB | Consumer-GPU, Laptop | Prototyping, einfache Aufgaben |
| 7B | ~14 GB | Einzelne moderne GPU | Standard-Anwendungen, lokale Deployments |
| 13B | ~26 GB | High-End GPU oder 2x Consumer-GPU | Komplexere Aufgaben, bessere Qualität |
| 70B | ~140 GB | Mehrere High-End GPUs (A100/H100) | Anspruchsvolle Anwendungen, Produktionsumgebungen |
| 175B+ | ~350 GB+ | GPU-Cluster | State-of-the-Art, meist nur über API verfügbar |
Ein 7-Milliarden-Parameter-Modell passt auf eine einzelne moderne GPU und läuft auf einem gut ausgestatteten Laptop. Für viele Anwendungen reicht das völlig. Ein 70-Milliarden-Parameter-Modell hingegen braucht mehrere High-End-GPUs – was es für die meisten Teams unpraktikabel macht, es selbst zu hosten.
Nicht alle Modelle sind gleich gebaut. Es gibt einen fundamentalen Unterschied zwischen General-Purpose-Modellen und spezialisierten Varianten – und dieser Unterschied bestimmt oft, welches Modell Sie für Ihre Anwendung wählen sollten.
General-Purpose-Modelle wie GPT-4, Claude oder Llama sind darauf trainiert, möglichst viele verschiedene Aufgaben zu beherrschen. Sie können Gedichte schreiben, Code debuggen, Verträge zusammenfassen, Fragen zu historischen Ereignissen beantworten, mathematische Probleme lösen. Diese Vielseitigkeit ist ihre Stärke. Aber sie ist auch eine Schwäche: Sie sind Meister von vielem, aber Experten in nichts.
Spezialisierte Modelle hingegen fokussieren sich auf einen bestimmten Bereich. Ein Code-Modell wie Codex oder StarCoder wurde primär auf Code trainiert und dann für Code-bezogene Aufgaben optimiert. Ein medizinisches Modell wie Med-PaLM wurde mit medizinischen Texten, Fallstudien, Forschungspapieren gefüttert. Diese Modelle sind in ihrer Domäne oft deutlich besser als generalistische Alternativen – aber außerhalb ihrer Domäne möglicherweise deutlich schlechter.
Die Frage ist: Was brauchen Sie?
Wenn Sie ein System bauen, das vielfältige Aufgaben erledigen muss – Kundenanfragen beantworten, die mal technisch, mal geschäftlich, mal allgemein sind – dann ist ein generalistisches Modell vermutlich die richtige Wahl. Wenn Sie hingegen ein System bauen, das ausschließlich Röntgenbilder interpretiert oder SQL-Abfragen optimiert, dann lohnt sich der Blick auf spezialisierte Modelle.
Aber hier wird es kompliziert: Spezialisierte Modelle sind oft nicht öffentlich verfügbar. Oder sie sind nur über kostenpflichtige APIs zugänglich. Oder ihre Lizenz erlaubt keine kommerzielle Nutzung. Das führt zu einer pragmatischen Realität: Die meisten Entwickler arbeiten mit generalistischen Modellen und optimieren sie dann für ihre spezifische Aufgabe – durch geschicktes Prompting, durch Finetuning, durch Retrieval-Augmented Generation.
Um zu verstehen, was ein Modell kann und was nicht, hilft es zu wissen, wie es entstanden ist. Denn die Art des Trainings prägt das Verhalten fundamental.
Am Anfang steht das Pretraining. Das ist die Phase, in der ein Modell von Grund auf lernt, was Sprache ist. Man nimmt ein uninitialisiertes neuronales Netz – im Grunde ein System mit zufälligen Gewichten – und trainiert es auf riesigen Mengen an Text. Wikipedia, Bücher, Webseiten, Code-Repositories, wissenschaftliche Papers. Alles, was digital verfügbar ist.
Die Aufgabe ist simpel: Gegeben die ersten N Tokens eines Textes, sage das nächste Token vorher. Falsch geraten? Dann passen wir die Gewichte an, so dass die richtige Antwort beim nächsten Mal wahrscheinlicher wird. Das wiederholt man Billionen Male, über Wochen oder Monate auf riesigen GPU-Clustern.
Das kostet. GPT-4 soll laut Schätzungen zwischen 50 und 100 Millionen Dollar an Rechenressourcen gekostet haben. Llama 3, eines der größeren Open-Source-Modelle, wurde auf 15 Billionen Tokens trainiert. Selbst kleinere Modelle brauchen Millionen von Dollar und Monate an Training.
Das Ergebnis ist ein sogenanntes Base Model. Es kennt Sprache, es kennt Muster, es hat implizites Weltwissen aufgebaut. Aber es ist noch nicht benutzbar. Nicht wirklich.
Ein Base Model zu benutzen, fühlt sich seltsam an. Sie geben ihm einen Satz, und es vervollständigt ihn – aber nicht unbedingt so, wie Sie es wollen. Sie schreiben “Erkläre mir Quantenphysik”, und das Modell könnte antworten, indem es den Satz einfach fortführt: “Erkläre mir Quantenphysik, sagte der Student zu seinem Professor. Der Professor lächelte und begann…”
Das ist nicht hilfreich. Sie wollen keine Fortsetzung Ihrer Eingabe, Sie wollen eine Antwort auf Ihre Anfrage.
Hier kommt Instruction Tuning ins Spiel. Man nimmt das Base Model und trainiert es weiter – diesmal auf Beispielen von Instruktionen und den gewünschten Antworten darauf. “Fasse diesen Text zusammen” gefolgt von einer guten Zusammenfassung. “Schreibe eine Python-Funktion, die…” gefolgt von gut geschriebenem Code. “Erkläre das Konzept von…” gefolgt von einer klaren, pädagogischen Erklärung.
Das Modell lernt, dass es nicht mehr nur Text vervollständigen soll. Es soll auf Anfragen reagieren, als wäre es ein hilfreiches System.
Reinforcement Learning from Human Feedback – RLHF – ist der Schritt, der aus einem instruction-tuned Modell etwas macht, das sich richtig anfühlt. Hier kommt menschliches Feedback ins Spiel.
Das Modell generiert mehrere mögliche Antworten auf eine Frage. Menschen bewerten diese Antworten: Welche ist hilfreicher? Welche ist sachlich korrekter? Welche ist höflicher? Welche vermeidet schädliche Inhalte? Aus diesen Bewertungen lernt das Modell, welche Art von Antworten Menschen bevorzugen.
Das ist nicht perfekt. Die menschlichen Bewerter können selbst Vorurteile haben. Sie können inkonsistent sein. Sie können sich irren. Und das Modell lernt nicht nur “gute Antworten”, es lernt auch “Antworten, die menschliche Bewerter für gut halten” – was nicht immer dasselbe ist.
Aber RLHF ist der Grund, warum ChatGPT sich so anders anfühlt als ein rohes Base Model. Warum es höflich ist, auch wenn Sie unhöflich sind. Warum es sagt “Ich weiß nicht”, statt zu halluzinieren (manchmal). Warum es hilfreiche Strukturierungen bietet, Beispiele gibt, sich an Ihren Ton anpasst.
Das alles ist nicht intrinsisch im Modell. Es wurde trainiert. Optimiert. Angepasst an menschliche Präferenzen.
Wenn Sie verstehen, wie ein Modell trainiert wurde, verstehen Sie auch seine Grenzen und Stärken.
Ein Base Model ist roh, aber mächtig. Wenn Sie es finetunen wollen, ist das Ihr Ausgangspunkt. Aber es wird sich seltsam verhalten, wenn Sie es direkt benutzen.
Ein instruction-tuned Modell ist brauchbar. Es kann Aufgaben ausführen, wenn Sie sie klar formulieren. Aber es wird nicht unbedingt höflich sein, nicht immer hilfreich strukturiert, manchmal direkt und schroff.
Ein RLHF-optimiertes Modell fühlt sich an wie ein Assistent. Es ist das, was die meisten öffentlichen APIs bieten: GPT-4, Claude, Gemini. Diese Modelle sind darauf trainiert, sich “gut” zu verhalten – nach den Standards der Menschen, die sie bewertet haben.
Aber “gut verhalten” heißt nicht “korrekt”. Ein RLHF-Modell wird lieber eine plausibel klingende Antwort geben als zuzugeben, dass es nicht genug Kontext hat. Es wird lieber höflich bleiben, auch wenn Direktheit angebracht wäre. Es hat gelernt, menschliche Präferenzen zu erfüllen, nicht Wahrheit zu maximieren.
Das ist keine Kritik. Es ist eine Realität, die Sie verstehen müssen, wenn Sie diese Systeme einsetzen.
Bauen Sie ein System für Kundeninteraktion? Dann brauchen Sie ein Modell, das natürlich klingt, höflich ist, Kontext versteht, mit mehrdeutigen Anfragen umgehen kann. RLHF-trainierte Modelle sind hier Gold wert. Gleichzeitig müssen Sie sicherstellen, dass das Modell keine halluzinierten Informationen gibt – also brauchen Sie wahrscheinlich ein Retrieval-System, das dem Modell verifizierte Informationen liefert.
Bauen Sie ein System, das sensible Daten verarbeitet – medizinische Akten, Verträge, Finanzinformationen? Dann ist On-Premise wahrscheinlich Pflicht. Kein Kunde will, dass seine Gesundheitsdaten über OpenAI’s API gehen. Hier müssen Sie lokale Modelle einsetzen, selbst wenn sie schlechter sind als die Cloud-Alternativen.
Wie vergleicht man Modelle objektiv? Die Antwort sind Benchmarks – standardisierte Tests, die verschiedene Fähigkeiten messen. Die folgende Tabelle zeigt die wichtigsten Benchmarks und was sie testen:
| Benchmark | Was wird getestet | Warum es relevant ist |
|---|---|---|
| MMLU | Wissen und Verständnis über 57 Themengebiete (Mathematik, Geschichte, Medizin, etc.) | Misst breites Weltwissen und Anwendungsfähigkeit |
| GSM8k | Mathematisches Reasoning anhand von Grundschul-Matheaufgaben | Gute Metrik für logisches Denken und mehrstufige Berechnungen |
| HumanEval | Code-Generierung (Funktion schreiben, Tests bestehen) | Direkte Messung der Programmier-Fähigkeiten |
| MBPP | Code-Generierung mit Python-Aufgaben | Alternative Code-Metrik mit anderen Schwerpunkten |
| HellaSwag | Commonsense-Reasoning (plausible Satzfortsetzungen) | Testet intuitives Weltwissen und Alltagsverständnis |
Diese Benchmarks sind hilfreich, aber nicht perfekt. Ein Modell kann in allen Benchmarks gut abschneiden und trotzdem in Ihrer spezifischen Anwendung schlecht sein. Benchmarks messen generelle Fähigkeiten, aber nicht, wie gut ein Modell in Ihrem Kontext, mit Ihren Daten, für Ihre Aufgabe funktioniert.
Die einzige wirklich verlässliche Metrik ist: Ausprobieren. Mit echten Daten, echten Aufgaben, echten Nutzern.
Es ist wichtig zu verstehen, dass hinter jedem Modell Interessen stehen. Modelle sind keine neutralen Werkzeuge, sie sind Produkte von Unternehmen oder Communities mit spezifischen Zielen.
Google trainiert Gemini, um seine Suchmaschine zu verteidigen und seine Cloud-Services zu verkaufen. OpenAI trainiert GPT, um führend in kommerzieller KI zu bleiben. Meta gibt Llama als Open Source frei, nicht aus Altruismus, sondern um zum De-facto-Standard zu werden und andere abhängig von seiner Infrastruktur zu machen. Anthropic positioniert Claude als sicherere, ethischere Alternative – was auch eine Marktdifferenzierung ist.
“Open Source” klingt gut. Klingt nach Freiheit, nach Community, nach Transparenz. Aber bei LLMs ist die Realität komplizierter.
Wenn Meta Llama als “open source” freigibt, bedeutet das: Sie bekommen die Modellgewichte. Sie können das Modell herunterladen und laufen lassen. Aber Sie bekommen nicht die Trainingsdaten. Sie bekommen nicht den kompletten Trainingscode. Sie können das Modell nicht von Grund auf reproduzieren. Und die Lizenz hat Einschränkungen – wenn Ihre Anwendung mehr als 700 Millionen Nutzer hat, müssen Sie eine spezielle Lizenz anfragen.
Das ist nicht “open source” im klassischen Sinne, wie Sie es von Linux oder Python kennen. Es ist “open weights” – die Gewichte sind zugänglich, aber der Prozess dahinter ist proprietär.
Echte Open-Source-Modelle, bei denen auch Daten und Trainingsscripts verfügbar sind, sind selten und meist kleiner. Und selbst wenn sie existieren: Die Trainingsdaten nachzubauen ist oft praktisch unmöglich. Common Crawl enthält Petabytes an Webseiten – das zu verarbeiten erfordert Infrastruktur, die den meisten nicht zur Verfügung steht.
Trotzdem hat “open weights” enormen Wert. Sie können das Modell selbst hosten. Sie können es finetunen. Sie können die Community-Innovation nutzen – Tausende von Entwicklern bauen Varianten, Adapter, Optimierungen. LoRA (Low-Rank Adaptation) erlaubt es, ein großes Modell mit relativ wenig Daten und Rechenaufwand an spezifische Aufgaben anzupassen. Das entstehende Ökosystem ist mächtig.
Bei closed-source Modellen wie GPT-4 haben Sie diese Möglichkeiten nicht. Sie können das Modell nicht modifizieren, nicht auf Ihrer Hardware laufen lassen, nicht für Ihre Aufgabe finetunen. Dafür sind diese Modelle oft leistungsfähiger – weil OpenAI oder Anthropic mehr Ressourcen in Training und Optimierung stecken können, als die meisten Open-Source-Projekte aufbringen können.
Theoretisch könnten Sie jedes Modell für Ihre spezifische Aufgabe finetunen. Praktisch ist das oft eingeschränkt.
Bei closed-source Modellen bieten manche Anbieter Finetuning als Service an – Sie geben Ihre Daten, sie trainieren eine angepasste Version, Sie zahlen pro Beispiel und pro Token. Das funktioniert, aber Sie haben immer noch keine Kontrolle über das Modell. Und es ist teuer.
Bei open-weights Modellen können Sie theoretisch selbst finetunen. Aber volles Finetuning eines 70-Milliarden-Parameter-Modells braucht mehrere A100-GPUs über Tage. Das ist für die meisten nicht praktikabel.
Hier kommen Techniken wie LoRA ins Spiel. Statt alle Parameter neu zu trainieren, trainieren Sie nur eine kleine Anpassungsschicht. Das braucht viel weniger Ressourcen – Sie können ein 7-Milliarden-Parameter-Modell mit LoRA auf einer einzelnen Consumer-GPU in Stunden anpassen. Die Community baut Tausende solcher LoRA-Adapter für verschiedene Aufgaben, und Sie können sie kombinieren, mischen, anpassen.
Das ist die Stärke des Open-Weights-Ökosystems: Nicht, dass Sie von Grund auf trainieren können, sondern dass Sie auf einer riesigen Basis von Community-Arbeit aufbauen können.
Am Ende läuft es auf eine Entscheidung hinaus, die von Ihren Constraints abhängt.
Haben Sie strenge Datenschutzanforderungen? On-Premise, open-weights Modelle.
Brauchen Sie die absolut beste Performance? Closed-source Cloud-Modelle wie GPT-4 oder Claude.
Haben Sie eine spezialisierte Aufgabe mit vielen Beispieldaten? Finetuning oder LoRA-Adapter auf einem open-weights Modell.
Bauen Sie einen Prototyp und wollen schnell iterieren? Cloud-API, weil Sie sich nicht um Infrastruktur kümmern müssen.
Bauen Sie ein Produkt, das in fünf Jahren noch laufen soll? Open-weights, weil Sie nicht von einem Anbieter abhängig sind, der sein Geschäftsmodell ändern oder sein Modell einstellen könnte.
Es gibt keine universell richtige Antwort. Es gibt nur die Antwort, die für Ihren konkreten Use Case funktioniert.
Aber diese Entscheidung zu treffen, setzt voraus, dass Sie verstehen, was ein Modell ist. Nicht als abstrakte Idee, nicht als “künstliche Intelligenz” im Marketing-Sprech, sondern als konkrete technische Einheit mit spezifischen Eigenschaften, Stärken, Schwächen, Abhängigkeiten.