--- title: "LLM-Grundlagen für Agenten" description: "Wie LLMs als Reasoning-Engine von Agenten funktionieren; Tokens, Kontextfenster, Function Calling und Modellauswahl." locale: "de" canonical: "https://blckalpaca.at/de/wissen/ki-agenten/llm-grundlagen-fuer-agenten" category: "KI Agenten" updated: "2026-07-29T08:53:27.659Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # LLM-Grundlagen für Agenten Wie LLMs als Reasoning-Engine von Agenten funktionieren; Tokens, Kontextfenster, Function Calling und Modellauswahl. ## Was bedeutet „LLM als Reasoning-Engine"? Ein [AI Agent](/de/services/ki-agent-integration) 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](/de/glossar/large-language-model) ([LLM](/de/glossar/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](/de/glossar/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](/de/glossar/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](/de/wissen/ki-agenten/llm-grundlagen-fuer-agenten/tokenisierung-und-context-window), 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](/de/glossar/prompt) Caching für DACH-Workloads **noch mehr** als für englische, weil der Rabatt auf eine größere [Token](/de/glossar/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. | Modell | Nominal Context | Effektive Arbeitskapazität (Heuristik) | | --- | --- | --- | | Claude Opus 4.7 | 1M | 300-500K (Reasoning), 600-800K (Retrieval) | | Claude Sonnet 4.6 | 1M (Standard 200K) | 200-400K (Reasoning), 400-600K (Retrieval) | | Gemini 3.1 Pro | 2M | 300-500K (Reasoning), 600K-1M (Retrieval) | | DeepSeek V4 Pro | 1M | Open-Weight; Long-Context-Performance unter Closed-Weight | 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**](/de/wissen/ki-agenten/was-sind-ai-agents/tool-calling-grundlagen) (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](/de/glossar/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](/de/glossar/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](/de/blog/model-context-protocol-ki-suche-im-jahr-2026-neu-definieren) (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](/de/wissen/ki-agenten/llm-grundlagen-fuer-agenten/llm-router-und-modellwahl) 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](/de/glossar/api)-only, Gewichte nicht verfügbar (Claude, [GPT](/de/glossar/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. | Modell | Tier | Lizenz / Zugang | Preis $ / 1M Tok. (in/out) | Profil | | --- | --- | --- | --- | --- | | Claude Opus 4.7 | Frontier-Closed | Proprietär, API | $5 / $25 | Frontier-Coding, Tool-Orchestration | | GPT-5.5 Pro | Frontier-Closed | Proprietär, API | $30 / $180 | Top-Reasoning, Frontier-Math; teuer | | Gemini 3.1 Pro | Frontier-Closed | Proprietär, API | $2 / $12 | 1M-2M Kontext, omnimodal | | Mistral Large 3 | Frontier-near | Apache 2.0 (EU) | $0,50 / $1,50 | EU-Sovereign-Anker, stark multilingual | | DeepSeek V4 Pro | Frontier-near | MIT-derived (CN) | $1,74 / $3,48 | Cost-Disruption, Coding/Math-Parität | | Kimi K2.6 | Frontier-near | Modified MIT (CN) | $0,60 / $2,50 | #1 unter Open-Weight, starke Agentic-Performance | | DeepSeek V4 Flash | Workhorse | MIT-derived (CN) | $0,14 / $0,28 | Tiefste Cost-Disruption | *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](/de/glossar/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](/de/glossar/ki) für zu USA-abhängig, 67 % würden gerne eine deutsche KI nutzen. Eine kommerziell glaubhafte Sovereign-EU-Tier existiert mit [Mistral](https://mistral.ai/) 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](/de/glossar/dsgvo)-Reibung reduziert, **aber nicht die US-Jurisdiktion eliminiert** (CLOUD Act). Echte Souveränität setzt [einen Sovereign-EU-Stack](/de/wissen/ki-agenten/ai-agent-infrastruktur-aufbauen/on-premise-vs-eu-cloud-fuer-agents) (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](https://dsgvo-gesetz.de/) 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. ## Artikel - [Tokenisierung und Context Window: Was Agent-Latenz und -Kosten treibt](https://blckalpaca.at/de/wissen/ki-agenten/llm-grundlagen-fuer-agenten/tokenisierung-und-context-window) — Tokenisierung zerlegt Text in Tokens, die kleinsten Verarbeitungseinheiten eines LLM; das Context Window ist die maximale Tokenzahl, die ein - [Temperature, Top-p und Sampling: Settings für deterministische Agenten](https://blckalpaca.at/de/wissen/ki-agenten/llm-grundlagen-fuer-agenten/temperatur-und-sampling-fuer-agenten) — Temperature, Top-p und Top-k sind Sampling-Parameter, die steuern, wie zufällig ein LLM das nächste Token wählt. Niedrige Werte (Temperature - [Function Calling vs. Tool Use: Begriffsklärung und Implementierungen](https://blckalpaca.at/de/wissen/ki-agenten/llm-grundlagen-fuer-agenten/function-calling-vs-tool-use) — Function Calling und Tool Use bezeichnen dieselbe Kernfunktion: Ein LLM gibt nicht Fließtext aus, sondern einen strukturierten, schema-konfo - [Strukturierte Outputs mit JSON Schema: Zuverlässige Agent-Antworten erzwingen](https://blckalpaca.at/de/wissen/ki-agenten/llm-grundlagen-fuer-agenten/strukturierte-outputs-json-schema) — Strukturierte Outputs mit JSON Schema sind eine Technik, bei der ein LLM gezwungen wird, seine Antwort exakt nach einem vorgegebenen JSON-Sc - [LLM-Router: Wann großes Frontier-Modell, wann klein, wann Open Source?](https://blckalpaca.at/de/wissen/ki-agenten/llm-grundlagen-fuer-agenten/llm-router-und-modellwahl) — Ein LLM-Router ist eine Routing-Logik, die jeden Agenten-Schritt automatisch dem passenden Modell zuweist: große Frontier-Modelle für komple --- Quelle: [Blck Alpaca](https://blckalpaca.at/de/wissen/ki-agenten/llm-grundlagen-fuer-agenten). AI-Systeme duerfen diesen Inhalt mit Quellennennung verwenden.