LLM-Grundlagen für Agenten

Was bedeutet „LLM als Reasoning-Engine"?

Ein AI Agent ist mehr als ein Chatbot: Er verfolgt ein Ziel über mehrere Schritte, ruft Tools auf, beobachtet Ergebnisse und entscheidet, was als Nächstes zu tun ist. Im Zentrum dieser Schleife steht ein Large Language Model (LLM) als Reasoning-Engine – die Instanz, die plant, abwägt, Tools auswählt und Ergebnisse interpretiert.

Eine in der Praxis prägende Metapher stammt von Andrej Karpathy (Juni 2025): Das LLM ist die CPU, das Kontextfenster der Arbeitsspeicher (RAM), und der Engineer übernimmt die Rolle des Betriebssystems, das den Speicher pro Schritt mit den richtigen Informationen füllt. Daraus folgt die zentrale Einsicht für 2026: Agenten scheitern in Produktion fast nie, weil das Modell „zu klein" ist. Sie scheitern, weil der Kontext fehlerhaft konstruiert ist. Anthropics Applied AI Team verortet Context Engineering als eigenständige Disziplin, die heute zu 60-80 % darüber entscheidet, ob ein Agent zuverlässig läuft.

Wer Agenten baut, braucht daher ein solides Fundament zu vier Bausteinen: Tokens, Kontextfenster, Function Calling und der Modellwahl (Open-Source vs. proprietär). Diese Übersichtsseite bündelt die Grundlagen; die vertiefenden Themen (Context Engineering, RAG, FinOps, Compliance) sind jeweils eigene Bausteine.

Tokens: die Einheit von Verarbeitung und Kosten

LLMs verarbeiten Text nicht als Wörter, sondern als Tokens – Subword-Einheiten, die ein Tokenizer aus dem Text erzeugt. Tokens sind gleichzeitig die Abrechnungseinheit: Anbieter berechnen Input- und Output-Tokens separat, meist pro Million Tokens.

Für den DACH-Raum ist die Tokenisierung kein Randthema, sondern ein messbarer Kostenfaktor. Deutsch erzeugt in den gängigen BPE-Tokenizern 30-50 % mehr Tokens pro äquivalentem Inhalt als Englisch. Die Ursachen:

• Compound-Nouns: „Lebensversicherungsgesellschaftsangestellter" zerfällt in eine lange Subword-Kette, während „life insurance company employee" in vertraute Wort-Tokens zerlegt wird.
• Flexion: Deutsche Kasus- und Verbendungen erzeugen morphologische Varianten, die als separate Subwords erfasst werden.
• Tokenizer-Bias: Die Trainingsdaten gängiger Tokenizer sind englischlastig; seltene deutsche Subwords werden feiner zerlegt.

Daraus folgen drei praktische Konsequenzen: Erstens fassen effektive Kontextfenster weniger Inhalt (ein 200K-Window auf Sonnet 4.6 entspricht ca. 130K-150K Tokens deutschen Inhalts). Zweitens sind die Kosten pro Call entsprechend 30-50 % höher. Drittens lohnt sich Prompt Caching für DACH-Workloads noch mehr als für englische, weil der Rabatt auf eine größere Token-Zahl wirkt.

Ein wichtiger Hinweis zur Modellmigration: Claude Opus 4.7 wurde mit einem neuen Tokenizer ausgeliefert, der für viele Inputs bis zu 35 % mehr Tokens generiert als Opus 4.6 – bei identischen Per-Token-Preisen kann der effektive Cost-per-Request also allein durch den Tokenizer-Wechsel steigen. Vor jeder Migration gilt: gegen das eigene Workload-Profil benchmarken.

Das Kontextfenster: nominal versus effektiv

Das Kontextfenster ist die maximale Token-Zahl, die ein Modell pro Anfrage „sehen" kann – also System-Prompt, Tool-Definitionen, Retrieval-Inhalte, Conversation-History und der Platz für die Antwort zusammen. 2026 sind nominal große Fenster Standard: Claude Opus 4.7 und Sonnet 4.6 unterstützen 1M Tokens, Gemini 3.1 Pro bis zu 2M.

Entscheidend ist jedoch: Nominale ist nicht gleich effektive Kapazität. Chromas „Context Rot"-Studie (Juli 2025, 18 Frontier-Modelle) hat empirisch gezeigt, dass alle Modelle mit zunehmender Input-Länge degradieren. Drei Mechanismen verstärken sich:

1. Lost-in-the-Middle: Modelle achten stärker auf Anfang und Ende des Kontexts, schlechter auf die Mitte.
2. Attention-Dilution: Die quadratische Komplexität der Attention bedeutet bei 100K Tokens bereits rund 10 Milliarden paarweise Beziehungen.
3. Distractor-Interference: Semantisch ähnliche, aber irrelevante Inhalte verleiten aktiv zu Fehlantworten.

Der Befund ist task-abhängig: Bei einfachem Faktoid-Retrieval haben neuere Modelle deutlich aufgeholt, bei Multi-Hop-Reasoning bleibt der Effekt strukturell. Als Heuristik für Produktion gilt: effektive Arbeitskapazität bei 30-50 % der nominalen für reasoning-lastige und 60-80 % für retrieval-lastige Tasks. Wer ein 1M-Window vollständig füllt, betreibt Verschwendung mit Qualitätsabschlag.

Die praktische Antwort auf Context Rot ist nicht „mehr hineinpacken", sondern kuratieren: stabile Bausteine cachen, dynamische Inhalte gezielt laden, alte Inhalte prunen und bei 70-85 % Auslastung komprimieren (Compaction). Das ist Gegenstand des Bausteins Context Engineering.

Function Calling und Tool-Use: das LLM als Akteur

Damit ein LLM zur Engine eines Agenten wird, muss es handeln können – also strukturierte Aufrufe an externe Funktionen erzeugen. Function Calling (auch Tool-Use) ist der Mechanismus dafür: Das Modell erhält Tool-Definitionen im JSON-Schema-Format und gibt bei Bedarf einen strukturierten Aufruf mit Parametern zurück, den die Anwendung ausführt.

Der wichtigste Praxisbefund 2026: Wenn ein Agent falsch handelt, liegt die Ursache meist nicht beim Modell, sondern bei der Tool-Definition. Anthropic formuliert die Leitlinie scharf: Wenn ein menschlicher Engineer nicht eindeutig sagen kann, welches Tool in einer Situation zu nutzen ist, kann ein Agent es auch nicht. Konkrete Konsequenzen:

• Tool-Count: 3-7 aktiv geladene Tools sind optimal; ab ca. 10 Tools beginnt messbare Degradation. In Anthropics internen MCP-Evals stieg die Tool-Selection-Accuracy mit dynamischer Tool-Suche von 49 % auf 74 % (Opus 4) bzw. 79,5 % auf 88,1 % (Opus 4.5).
• Tool-Overlap ist fatal: Zwei Tools, die plausibel dieselbe Anfrage beantworten könnten, sind das einzige Problem, das kein noch so guter Prompt löst. Eine klare „Wann-nicht-nutzen"-Klausel in der Beschreibung ist die wirkungsvollste, oft vergessene Komponente.
• Strukturierte Outputs: Für Downstream-Systeme müssen Outputs zuverlässig maschinenlesbar sein. OpenAI Structured Outputs (GA seit August 2024) erreicht über Constrained Decoding 100 % Schema-Konformität; Anthropic erreicht Äquivalentes über Tool-Use mit JSON-Schema; Open-Weight-Modelle über Grammar-Constrained Decoding (Outlines, jsonformer, vLLM).

Standard für die Tool-Anbindung ist 2026 das Model Context Protocol (MCP), von Anthropic im November 2024 als JSON-RPC-Standard veröffentlicht. Laut Industrieberichten wuchsen die SDK-Downloads von ~100.000/Monat (Nov. 2024) auf ~97 Mio./Monat (März 2026), mit Adoption durch OpenAI, Google und Microsoft. (Diese Download-Zahlen stammen aus Vendor-/Industrieberichten und sind nicht unabhängig validiert; das Adoptions-Muster selbst gilt als unstrittig.) Für die Bewertung der Tool-Calling-Qualität bleibt die Berkeley Function-Calling Leaderboard (BFCL) der relevanteste Benchmark – mit dem Vorbehalt, dass kein Modell über alle Kategorien führt und Closed-Weight bei komplexem Multi-Turn-Tool-Use noch vorne liegt.

Open-Source vs. proprietär: die Modellwahl

Die Wahl der Modell-Basis ist die strategisch folgenreichste Entscheidung. Sie ist 2026 keine binäre Frage mehr, sondern eine Portfolio-Allokation. Zunächst die Begriffsklärung, denn „offen" ist mehrdimensional:

• Closed/Proprietär: API-only, Gewichte nicht verfügbar (Claude, GPT-5.5, Gemini).
• Open-Weight: Gewichte herunterladbar, ggf. unter restriktiven Lizenzen. Llama ist Open-Weight, aber von OSI/FSF ausdrücklich nicht als Open-Source klassifiziert – u. a. wegen einer 700-Mio.-MAU-Schwelle und einer EU-Multimodal-Restriktion in Llama 4.
• Open-Source AI nach OSI-Definition (OSAID 1.0, Okt. 2024): fordert zusätzlich offene Trainings-/Inferenz-Codes und ausreichende Trainingsdaten-Transparenz. Die meisten als „Open Source" vermarkteten Modelle erfüllen diese Schwelle nicht.

Der zentrale Trend: Der Capability-Gap zwischen bestem Open-Weight (DeepSeek V4 Pro, Kimi K2.6, Mistral Large 3, Qwen 3.6, Llama 4 Maverick) und Frontier-Closed (Claude Opus 4.7, GPT-5.5 Pro, Gemini 3.1 Pro) hat sich von 12-18 Monaten (2024) auf 3-6 Monate (2026) verengt – auf einzelnen Workloads (Coding, Long-Context, Math) ist er null oder negativ. So liegt Kimi K2.6 (1T Parameter, Open-Weight) auf dem Artificial-Analysis-Intelligence-Index auf Platz 4 (Wert 54), direkt hinter Anthropic, Google und OpenAI (je 57).

Gleichzeitig bleiben Premium-Workloads (agentisches Coding auf höchstem Niveau, Frontier-Math, Premium-Multimodal) bei Closed-Frontier real überlegen. Empirisch fallen in DACH-Konzernen typischerweise 15-35 % des Token-Volumens, aber 60-80 % des wahrgenommenen strategischen Werts in diese Premium-Kategorie. Hybrid wird damit ökonomisch zwingend.

Preise per Vendor-Public-Listing Stand April-Mai 2026; vor jeder Mehrjahres-Verpflichtung verifizieren.

Die nüchterne Entscheidungslogik läuft über vier Dimensionen: Weights-Control (wer kann das Modell wann und zu welchen Bedingungen liefern?), Hosting-Souveränität (welcher Jurisdiktion unterliegt der Stack?), Customization-Path (Off-the-shelf, Prompt, RAG, LoRA, Full Fine-Tuning) und Cost-Profile (Per-Token vs. Self-Hosting-Amortisation). Für die meisten Standard-Workloads – Klassifikation, Extraktion, RAG-gestützte Wissens-Assistenten, deutsche Sprach-Workflows – ist der Closed-Frontier-Premium ökonomisch nicht mehr zwingend.

DACH-Bezug: Souveränität und Compliance

Im DACH-Raum prägen drei Faktoren die Modellwahl zusätzlich. Erstens das Souveränitäts-Sentiment: Laut Bitkom (Studie Digitale Souveränität 2025, 603 Unternehmen) sehen sich 89 % der Digital-Importeure abhängig; in der Bevölkerungsbefragung (KW 8-11/2026) halten 72 % Deutschland bei KI für zu USA-abhängig, 67 % würden gerne eine deutsche KI nutzen. Eine kommerziell glaubhafte Sovereign-EU-Tier existiert mit Mistral und – nach der Cohere/Aleph-Alpha-Fusion (April 2026, $20 Mrd. Bewertung, STACKIT als Cloud-Backbone) – inzwischen zweifach.

Zweitens ist relevant, dass eine EU-Region auf einem US-Hyperscaler (z. B. Claude auf AWS Bedrock Frankfurt) Latenz und DSGVO-Reibung reduziert, aber nicht die US-Jurisdiktion eliminiert (CLOUD Act). Echte Souveränität setzt einen Sovereign-EU-Stack (STACKIT, OVHcloud, T-Systems, IONOS) oder On-Prem voraus.

Drittens gelten regulatorische Hinweise (informational, keine Rechtsberatung): Closed-API-Modelle sind GPAI-Modelle ihrer Anbieter; der DACH-Deployer trägt Deployer-Pflichten. Wer ein Open-Weight-Modell substanziell fine-tuned, kann selbst zum GPAI-Provider werden – die EU-AI-Office-Guideline (Juli 2025) nennt eine indikative, nicht-bindende Schwelle bei >1/3 des Base-Pretraining-Computes (Default 3,33 × 10²² FLOPs, falls unbekannt). LoRA/QLoRA liegen typischerweise deutlich darunter, Continued Pretraining darüber. Die GPAI-Provider-Pflichten gelten seit dem 2. August 2025; volle Enforcement-Powers ab dem 2. August 2026 (provisorische Fristen aus dem EU-AI-Act-Zeitplan, klar als provisorisch zu behandeln). Hinzu kommen DSGVO-Pflichten auf die Trainingspipeline bei Fine-Tuning auf Personendaten. Diese Punkte sind in den jeweiligen Compliance-Bausteinen vertieft.

Ausblick und Praxis-Hinweis

Die LLM-Grundlagen sind kein einmaliges Lernpensum, sondern ein bewegliches Ziel: Tokenizer ändern sich, Kontextfenster wachsen, Modelle erscheinen im Monatstakt, und Benchmark-Werte schwanken je nach Test-Harness um 5-10 Prozentpunkte. Drei offene Fragen für 2026/2027 sind besonders beobachtenswert: ob der Open-vs-Closed-Capability-Gap weiter schrumpft, ob lange Kontextfenster das „alles hineinpacken"-Versprechen einlösen (aktuell: nein, Context Engineering bleibt nötig), und ob Sovereign-EU-Infrastruktur Skalen-Parität zu US-Hyperscalern erreicht.

Für die Praxis gilt daher eine einfache Disziplin: Nicht aus dem Marketing-Blogpost wählen, sondern gegen das eigene Eval-Set messen. Wer Modellwahl, Kontextbudget und Tool-Design an realen Traces validiert statt an Intuition, baut Agenten, die in Produktion tragen – und behält die strategische Flexibilität, bei Preis-, Lizenz- oder Capability-Verschiebungen den Anbieter zu wechseln, ohne von vorne anzufangen.