Was ist ein LLM? Große Sprachmodelle für Entwickler erklärt

Was ist ein LLM? Große Sprachmodelle für Entwickler erklärt

LLMs sind überall — in Coding-Assistenten, Chatbots und seit Kurzem auch in IDEs und CI-Pipelines. Aber was passiert eigentlich unter der Haube? Dieser Artikel erklärt große Sprachmodelle aus der Perspektive eines Entwicklers: Wie Tokens funktionieren, warum Context Windows wichtig sind und weshalb ein LLM dir manchmal eine Bibliothek empfiehlt, die gar nicht existiert.

DarkWolfCave.de

Was ist ein Large Language Model?

Ein Large Language Model — kurz LLM — ist im Kern ein statistisches Modell. Es wurde mit riesigen Mengen Text trainiert und hat dabei gelernt, das wahrscheinlichste nächste Token vorherzusagen. Nicht mehr, nicht weniger.

Das klingt simpel, aber genau hier liegt ein verbreitetes Missverständnis: Ein LLM ist keine Datenbank, die Antworten nachschlägt. Es ist auch nicht „intelligent” im menschlichen Sinne. Es hat Muster in Textdaten erkannt — statistische Zusammenhänge zwischen Wörtern, Sätzen und Konzepten — und nutzt diese Muster, um Text zu erzeugen.

Die technische Grundlage dafür ist die Transformer-Architektur, die Google 2017 in dem Paper „Attention Is All You Need” vorgestellt hat. Die zentrale Idee: Statt Text Wort für Wort zu verarbeiten (wie es ältere Modelle taten), betrachtet ein Transformer den gesamten Eingabetext gleichzeitig. Über einen Mechanismus namens „Self-Attention” lernt das Modell, welche Teile des Textes für die Vorhersage des nächsten Tokens relevant sind.

Vor Transformern gab es RNNs (Recurrent Neural Networks) und LSTMs, die Text sequenziell verarbeiteten. Die konnten mit langen Texten schlecht umgehen — bei Satz 50 war Satz 1 praktisch vergessen. Transformer haben dieses Problem gelöst und damit den Weg für die heutigen Modelle geebnet.

ℹ️ Hinweis: Wenn jemand sagt, ein LLM „versteht” Code oder Sprache — dann ist das eine Vereinfachung. Das Modell hat statistische Muster gelernt, die den Eindruck von Verständnis erzeugen. Ob da echtes Verständnis dahintersteckt, ist eine offene Debatte in der KI-Forschung.

Tokens — die Grundeinheit von LLMs

LLMs arbeiten nicht mit Wörtern, sondern mit Tokens. Ein Token ist ein Textstück — manchmal ein ganzes Wort, manchmal nur ein Wortteil oder ein einzelnes Zeichen. Die Zerlegung in Tokens (Tokenisierung) passiert vor der eigentlichen Verarbeitung.

Ein Beispiel: Der englische Satz „The cat sat on the mat” wird in 6 Tokens zerlegt — jedes Wort ist ein Token. Beim deutschen Satz „Die Katze saß auf der Matte” sieht es ähnlich aus.

Aber bei zusammengesetzten deutschen Wörtern wird es interessant:

• the → 1 Token
• Straßenbahnhaltestelle → 5-7 Tokens (je nach Modell)
• Datenschutzgrundverordnung → 4-6 Tokens

Das liegt daran, dass die meisten LLMs primär auf englischen Texten trainiert wurden. Englische Wörter sind im Vokabular des Tokenizers häufiger vertreten und werden effizienter kodiert. Deutsche Komposita werden in ihre Bestandteile zerlegt — und das kostet mehr Tokens.

Warum ist das relevant? Aus zwei Gründen:

1. Kosten: API-Anbieter rechnen pro Token ab. Deutscher Text ist tendenziell teurer als englischer, weil mehr Tokens nötig sind.
2. Context Window: Jedes Modell hat ein begrenztes Token-Budget. Wenn dein deutscher Prompt mehr Tokens verbraucht, bleibt weniger Platz für die Antwort.

Als grobe Faustregel: 1.000 Tokens entsprechen etwa 750 englischen Wörtern. Bei deutschem Text sind es eher 500-600 Wörter für die gleiche Token-Anzahl.

Context Window — das Kurzzeitgedächtnis

Das Context Window ist die maximale Menge an Tokens, die ein LLM gleichzeitig verarbeiten kann. Alles, was im Context Window steht — dein Prompt, der bisherige Chatverlauf, System-Instruktionen — wird vom Modell „gesehen”. Was nicht drin ist, existiert für das Modell nicht.

Stand März 2026 bieten die großen Modelle alle 1 Million Tokens:

• Claude Opus 4.6 — 1M Tokens
• GPT-5.4 — 1M Tokens
• Gemini 3.1 Pro — 1M Tokens

Das klingt nach viel — und ist es auch. 1 Million Tokens entsprechen grob 10 bis 15 durchschnittlichen Softwareprojekten. Theoretisch könntest du eine komplette Codebase in den Kontext laden.

Aber: Größer heißt nicht automatisch besser. In der Praxis nimmt die Antwortqualität bei den meisten Modellen jenseits von ca. 256.000 Tokens merklich ab. Das Modell „sieht” zwar alles, aber die Aufmerksamkeit verteilt sich. Informationen in der Mitte eines langen Kontexts gehen leichter unter als solche am Anfang oder Ende — das ist als „Lost in the Middle”-Problem bekannt.

Für Coding-Tasks bedeutet das: Schick nicht blindlings die gesamte Codebase ins Context Window. Wähle gezielt die Dateien aus, die für deine aktuelle Aufgabe relevant sind. Ein fokussierter Kontext mit 50.000 Tokens liefert meistens bessere Ergebnisse als ein überlaufener mit 500.000.

💡 Tipp: Tools wie TypingMind oder Claude Code managen den Kontext für dich. Sie entscheiden, welche Dateien und Informationen ins Context Window geladen werden — und das macht einen spürbaren Unterschied bei der Qualität der Ergebnisse.

Warum LLMs halluzinieren

Wenn du regelmäßig mit LLMs arbeitest, ist dir das schon passiert: Du fragst nach einer Python-Bibliothek für einen bestimmten Zweck, und das Modell empfiehlt awesome-lib mit Version 3.2 — die es gar nicht gibt. Oder es generiert einen API-Call mit Parametern, die in der echten Dokumentation nirgends auftauchen.

Das ist kein Bug. Das ist ein direktes Ergebnis davon, wie LLMs funktionieren.

Ein LLM erzeugt Text auf Basis von Wahrscheinlichkeiten. Wenn du nach einer Bibliothek für Task X fragst, sucht das Modell nicht in einer Datenbank. Es generiert eine Antwort, die statistisch plausibel ist — basierend auf Mustern in den Trainingsdaten. Wenn es für Task X keine eindeutige Bibliothek gesehen hat, erzeugt es trotzdem eine Antwort. Eine, die sich richtig anhört. Die einen plausiblen Namen hat. Die eine vernünftige API-Struktur aufweist. Nur dass sie frei erfunden ist.

Das Problem betrifft nicht nur Bibliotheksnamen. In einer Studie von CodeRabbit (Dezember 2025) wurde KI-generierter Code systematisch analysiert. Die Ergebnisse:

• 1,7x mehr Fehler insgesamt im Vergleich zu manuell geschriebenem Code
• 2,74x mehr Sicherheitslücken — fehlende Input-Validierung, unsichere Defaults, mangelhafte Error-Handling

Das sind keine Ausreißer. Das ist das erwartbare Verhalten eines Systems, das auf Musterabgleich basiert und keine Vorstellung von „korrekt” oder „sicher” hat.

ℹ️ Hinweis: Halluzinationen lassen sich reduzieren, aber nicht eliminieren. Retrieval Augmented Generation (RAG) — also das Einbinden externer Datenquellen — hilft. Aber auch RAG-Systeme können halluzinieren, wenn die abgerufenen Dokumente nicht eindeutig genug sind.

In meiner Arbeit bedeutet das konkret: Ich übernehme keinen generierten Code ungeprüft. Jeder Import wird verifiziert, jeder API-Call gegen die Doku gegengeprüft. Das kostet Zeit, spart aber die Stunden, die man sonst mit der Fehlersuche bei einem Phantom-Bug verbringt.

Die wichtigsten Modelle im Überblick

Stand März 2026 gibt es vier relevante Modell-Familien für Entwickler. Keine davon ist „die beste” — es kommt auf den Anwendungsfall an.

Modell	Anbieter	Stärken	Context Window
Claude Opus 4.6	Anthropic	Lange Code-Kontexte, präzise Instruktionsbefolgung, starkes Reasoning	1M Tokens
Claude Sonnet 4.6	Anthropic	Gutes Preis-Leistungs-Verhältnis, schnell, guter Code-Output	1M Tokens
GPT-5.4	OpenAI	Breites Allgemeinwissen, multimodal, gute Tool-Integration	1M Tokens
GPT-4.1	OpenAI	Schnelle Code-Generierung, niedrigere Kosten	1M Tokens
Gemini 3.1 Pro	Google	Gut bei großen Dokumenten, multimodal mit nativem Bildverständnis	1M Tokens
Llama 4	Meta	Open Source, lokal betreibbar, keine API-Kosten, Daten bleiben privat	1M-10M Tokens

Ein paar persönliche Einschätzungen aus meiner täglichen Arbeit:

Claude Opus 4.6 nutze ich für komplexe Refactoring-Aufgaben und wenn ich mit großen Codebases arbeite. Die Instruktionsbefolgung ist bei Anthropic nach wie vor am zuverlässigsten — wenn ich sage „ändere nur Datei X”, dann bleibt das Modell auch bei Datei X.

GPT-4.1 setze ich ein, wenn ich schnell Boilerplate-Code brauche oder kleinere Aufgaben erledigen will, bei denen die Kosten im Vordergrund stehen.

Llama 4 ist die Option, wenn Daten das Haus nicht verlassen dürfen. Lokal auf eigener Hardware, keine API-Calls, keine Datenweitergabe. Für Teams mit strengen Compliance-Anforderungen ist das oft die einzige Wahl. Die Maverick-Variante bietet 1M Tokens Kontext, Scout sogar bis zu 10M.

Wie gesagt: Es gibt hier kein „das eine Modell”. Ich wechsle je nach Aufgabe zwischen mehreren. Das Experiment mit Gemini für die Favoritenportal-Entwicklung hat mir gezeigt, dass jedes Modell seine eigenen Stärken und Grenzen hat.

LLMs als Werkzeug für Entwickler

Die Frage ist nicht, ob du LLMs in deinem Entwickler-Alltag nutzt — das tust du wahrscheinlich schon. Die Frage ist, wie du sie nutzt.

Die gängigsten Anwendungsfälle in der Praxis:

• Code-Generierung: Boilerplate, Tests, Datenbank-Migrationen. Alles, wo die Struktur klar ist und das Modell sie schneller ausfüllt als du tippen kannst. Tools wie Cursor oder GitHub Copilot integrieren LLMs direkt in die IDE.
• Debugging: Fehlermeldung reinkopieren, Kontext dazu geben, mögliche Ursachen auflisten lassen. Oft findet das Modell den Fehler schneller als eine manuelle Suche.
• Refactoring: „Extrahiere diese Logik in eine eigene Funktion” oder „Konvertiere diese Klasse zu TypeScript”. Hier glänzen LLMs besonders.
• Code verstehen: Legacy-Code erklären lassen. Ich nutze das regelmäßig, wenn ich in fremde Projekte einsteige.

Andrej Karpathy hat im Februar 2025 den Begriff Vibe Coding geprägt — also das Programmieren, bei dem man der KI eine vage Beschreibung gibt und sie den Code generieren lässt. Das funktioniert für Prototypen und kleine Projekte. Für Produktionscode ist das keine gute Idee, wie die CodeRabbit-Studie zeigt. Welche konkreten Fehler dabei passieren und wie du sie vermeidest, habe ich in 5 typische Fehler beim Vibe Coding zusammengefasst.

Mein Ansatz: Ich bin der Fahrer, nicht der Beifahrer. Das LLM ist ein Werkzeug, kein Autopilot. Ich gebe die Richtung vor, prüfe das Ergebnis und übernehme die Verantwortung für den Code, der am Ende in der Codebase landet.

💡 Tipp: Wenn du mit KI-generiertem Code arbeitest, gewöhne dir an, ihn mit den gleichen Standards zu reviewen wie Code von Kollegen. KI-generierte Inhalte verdienen die gleiche Sorgfalt — egal ob es Text oder Code ist.

Wie du jetzt weitermachen kannst

LLMs sind ein Werkzeug, das du als Entwickler verstehen solltest — nicht nur nutzen. Wer weiß, wie Tokens funktionieren, warum Context Windows begrenzt sind und woher Halluzinationen kommen, trifft bessere Entscheidungen bei der Tool-Auswahl und im täglichen Umgang mit KI-Assistenten.

Wenn du LLMs als Entwickler von Grund auf verstehen willst — mit Quizzes, Praxisbeispielen und einem strukturierten Lernpfad — schau dir meinen kostenlosen Kurs KI & LLM Grundlagen für Entwickler auf der Wolf Academy an.