LLM-Begriffe ohne Buzzwording

Rund um LLMs ist in erstaunlich kurzer Zeit ein eigener Wortschatz entstanden: Tokens, Parameters, Context Windows, Reasoning Models, Agents, RAG, MCP, Open Weights, Inference, Prompt Caching oder Mixture of Experts. Und irgendwo dazwischen verkauft ein Anbieter noch Credits.

Das Problem ist nicht, dass diese Begriffe bedeutungslos wären. Im Gegenteil: Viele beschreiben reale und wichtige technische Konzepte. Andere sind Produktbegriffe, Kategorien oder Abrechnungsmodelle. Wieder andere stammen aus Forschung und Engineering, werden inzwischen aber so breit verwendet, dass zwei Anbieter mit demselben Wort nicht zwingend exakt dasselbe meinen.

Dadurch entsteht schnell der Eindruck einer völlig neuen technischen Welt, obwohl sich vieles erstaunlich einfach erklären lässt. Bevor wir tiefer in Agentic Work einsteigen, sollten wir deshalb erst einmal das Buzzwording beseitigen – nicht um die Begriffe lächerlich zu machen, sondern damit wir später wissen, worüber wir eigentlich reden.

AI – Artificial Intelligence

Artificial Intelligence, auf Deutsch künstliche Intelligenz, ist zunächst ein sehr breiter Oberbegriff. Er umfasst Computersysteme, die Aufgaben bearbeiten, die wir mit Fähigkeiten wie Wahrnehmung, Sprachverarbeitung, Planung, Mustererkennung, Problemlösung oder Entscheidungsfindung verbinden.

Ein Schachprogramm kann damit genauso in den Bereich AI fallen wie ein Bilderkennungssystem oder ein Large Language Model. Das ist wichtig, weil heute häufig „AI“ gesagt wird, obwohl eigentlich ein LLM oder generative AI gemeint ist.

AI ist also nicht automatisch ein LLM. Ein LLM ist lediglich eine bestimmte Klasse von AI-Modellen.

Machine Learning

Machine Learning bezeichnet Verfahren, bei denen gewünschtes Verhalten nicht vollständig als explizite Regeln programmiert wird. Stattdessen wird ein Modell anhand von Daten so angepasst, dass es darin relevante Muster lernt.

Bei klassischer Software könnte ein stark vereinfachtes Bild so aussehen:

Eingabe
↓
von Menschen geschriebene Regeln
↓
Ausgabe

Beim Machine Learning entsteht ein Teil dieser Entscheidungslogik dagegen während des Trainings aus Daten. Das bedeutet nicht, dass ein Computer plötzlich selbst entscheidet, was und wie er lernen möchte. Menschen bestimmen weiterhin unter anderem Daten, Modellarchitektur, Trainingsverfahren, Optimierungsziele und Evaluation.

Deep Learning ist wiederum ein Teilbereich des Machine Learning, der mit neuronalen Netzen mit vielen Verarbeitungsschichten arbeitet. Moderne LLMs gehören in diese Kategorie.

Generative AI

Generative AI bezeichnet AI-Systeme, die neue Inhalte erzeugen können. Das können Texte, Bilder, Audio, Video, Programmcode oder Kombinationen daraus sein.

„Neu“ bedeutet dabei nicht zwangsläufig kreativ im menschlichen Sinn. Ein generatives Modell erzeugt einen Output auf Basis gelernter Strukturen und des aktuellen Inputs.

Ein Chatbot, der eine Antwort formuliert, ist generative AI. Ein Bildmodell, das aus einer Beschreibung ein Bild erzeugt, ebenfalls. Ein System, das lediglich klassifiziert, ob auf einem Foto eine Katze abgebildet ist, muss dagegen nicht generativ sein.

Model

Wenn wir in AI-Diskussionen von einem Modell sprechen, meinen wir vereinfacht gesagt ein gelerntes mathematisches System, das aus Eingaben Ausgaben erzeugen kann.

Während des Trainings werden sehr viele interne Zahlenwerte angepasst. Zusammen mit der Architektur bestimmen sie, wie das Modell auf spätere Eingaben reagiert.

Im Alltag wird der Begriff allerdings etwas unscharf verwendet. Wenn ein Anbieter einen Modellnamen nennt, kann damit mehr gemeint sein als nur eine bestimmte Architektur und ein Satz von Gewichten. Auch Post-Training, Tokenizer, Konfiguration oder spezielle Serving-Einstellungen können Teil dessen sein, was wir praktisch als „dieses Modell“ erleben.

Zwei Modelle mit ähnlich klingender Größe müssen deshalb weder technisch noch qualitativ direkt vergleichbar sein.

Foundation Model

Ein Foundation Model ist ein Modell, das auf breiten Datenbeständen trainiert wurde und anschließend als Grundlage für unterschiedliche Aufgaben dienen kann. Der Begriff wurde insbesondere durch das Stanford Center for Research on Foundation Models geprägt. [2]

Entscheidend ist weniger eine bestimmte Parameterzahl als die Rolle des Modells: Es bildet eine allgemeine Basis, die anschließend beispielsweise durch Prompting, Post-Training, Fine-Tuning oder zusätzliche Systeme für konkrete Anwendungen eingesetzt werden kann.

Viele moderne LLMs sind Foundation Models. Die Begriffe sind aber keine Synonyme, denn Foundation Models können auch andere Modalitäten als Sprache betreffen.

LLM – Large Language Model

Ein Large Language Model ist ein großes Sprachmodell. Die generativen LLMs, über die wir bei heutigen Chat- und Coding-Systemen meistens sprechen, verarbeiten Informationen als Tokens und erzeugen ihre Ausgabe typischerweise schrittweise.

Sehr vereinfacht:

bisheriger Context
↓
mögliche nächste Tokens bewerten
↓
nächstes Token bestimmen
↓
zum Context hinzufügen
↓
wiederholen

Eine der häufigsten Fehlvorstellungen ist deshalb, ein LLM sei eine gigantische Datenbank mit fertig gespeicherten Antworten. So funktioniert es nicht. Wenn ein Modell die Frage nach der Hauptstadt Frankreichs beantwortet, liest es normalerweise nicht den vollständigen Satz „Paris ist die Hauptstadt von Frankreich“ aus einer klassischen Tabelle aus, sondern erzeugt seine Antwort aus dem aktuellen Context und den während des Trainings gelernten Strukturen.

Dass Wissen und Zusammenhänge in den Modellparametern repräsentiert sein können, steht dazu nicht im Widerspruch. Ein LLM ist nur eben kein klassisches Nachschlagewerk.

Transformer

Transformer bezeichnet eine neuronale Netzwerkarchitektur, die 2017 mit dem Paper Attention Is All You Need vorgestellt wurde und die Entwicklung moderner Sprachmodelle maßgeblich geprägt hat. [1]

Ein wesentliches Element ist der sogenannte Attention-Mechanismus. Vereinfacht ermöglicht er dem Modell, beim Verarbeiten eines Tokens zu gewichten, welche anderen Teile der Eingabe für die aktuelle Berechnung besonders relevant sind.

Man muss die Mathematik dahinter nicht verstehen, um einen wichtigen Unterschied zu kennen:

LLM und Transformer sind keine Synonyme. Viele heutige LLMs basieren vollständig oder teilweise auf Transformer-Architekturen. Ein Transformer ist aber eine Architektur, während LLM eine Modellklasse beziehungsweise Anwendung dieser und verwandter Architekturen beschreibt.

Parameters

Parameter sind veränderbare Zahlenwerte eines Modells, die während des Trainings angepasst werden. Deshalb begegnen uns in Modellbeschreibungen Angaben wie 7B, 70B oder 600B. Das B steht dabei für das englische billion, also Milliarden.

Ein 70B-Modell besitzt damit ungefähr 70 Milliarden Parameter.

Aus dieser Zahl allein lässt sich allerdings erstaunlich wenig über die tatsächliche Qualität ableiten. Architektur, Trainingsdaten, Datenqualität, Trainingsverfahren, Post-Training und verfügbare Rechenleistung während der Inference beeinflussen die Fähigkeiten eines Modells ebenfalls.

Mehr Parameter bedeuten deshalb nicht automatisch ein besseres Modell.

Bei Mixture-of-Experts-Modellen wird diese einfache Parameterzahl noch schwieriger zu interpretieren. Dazu kommen wir weiter unten.

Weights

Weights, also Gewichte, sind gelernte Zahlenwerte innerhalb eines neuronalen Netzes. Sie beeinflussen, wie interne Signale miteinander verrechnet werden und werden während des Trainings angepasst.

Im alltäglichen LLM-Sprachgebrauch werden „Weights“ und „Parameters“ häufig beinahe synonym verwendet. Technisch ist die Unterscheidung etwas genauer: Gewichte sind Parameter, ein Modell kann aber zusätzlich andere Arten trainierbarer Parameter besitzen.

Wenn ein Anbieter ein Modell als Open Weights bezeichnet, meint er damit üblicherweise, dass die gelernten Modellgewichte verfügbar gemacht werden. Was daraus folgt – und was nicht –, behandeln wir später noch genauer.

Training

Training ist der Prozess, durch den ein Modell seine Parameter lernt beziehungsweise verändert.

Sehr vereinfacht verarbeitet das Modell große Mengen von Trainingsbeispielen, erzeugt Vorhersagen, bestimmt die Abweichung von einem Trainingsziel und passt seine Parameter anschließend schrittweise an. Dieser Vorgang wird sehr oft wiederholt.

Für den Rest dieses Artikels genügt zunächst eine einfache Trennung:

Training
Daten
↓
Optimierung
↓
veränderte Modellparameter


Inference
Input
↓
bereits trainiertes Modell
↓
Output

Training verändert das Modell. Inference verwendet das trainierte Modell.

Moderne Trainingspipelines sind deutlich komplexer als dieses Schema, aber für die begriffliche Trennung reicht es zunächst aus.

Pre-Training und Post-Training

Wenn heute über moderne LLMs gesprochen wird, begegnen einem häufig die Begriffe Pre-Training und Post-Training.

Beim Pre-Training entsteht zunächst ein allgemeines Basismodell. Es lernt aus sehr großen Datenmengen grundlegende Strukturen, Zusammenhänge und Fähigkeiten.

Danach können weitere Trainingsphasen folgen. Unter Post-Training werden unterschiedliche Verfahren zusammengefasst, mit denen ein Basismodell beispielsweise besser auf Instruktionen reagieren, bestimmte Aufgaben lösen oder gewünschte Verhaltensweisen zeigen soll. Dazu können Fine-Tuning und verschiedene Formen von Reinforcement Learning gehören.

Das ist deshalb relevant, weil zwei Modelle mit derselben grundlegenden Architektur und ähnlichem Pre-Training sich nach unterschiedlichem Post-Training praktisch deutlich anders verhalten können.

Fine-Tuning

Beim Fine-Tuning wird ein bereits trainiertes Modell durch weiteres Training gezielt angepasst. Das kann etwa geschehen, um es auf bestimmte Aufgaben, Fachgebiete, Ausgabeformate oder Verhaltensweisen zu spezialisieren.

Der entscheidende Begriff ist dabei Training: Beim Fine-Tuning werden Modellparameter verändert.

Das unterscheidet Fine-Tuning grundsätzlich von Prompting, RAG oder einem typischen Memory-System. Wenn ich einem Modell bei jeder Anfrage meine Architekturregeln mitsende, habe ich es nicht fine-getuned. Wenn ein Agent Informationen aus einer Projektdatenbank lädt, ebenfalls nicht.

Zusätzlicher Context ist noch kein Fine-Tuning.

Inference

Inference bezeichnet die Nutzung eines bereits trainierten Modells. Wir geben ihm einen Input und lassen daraus einen Output berechnen.

"Erkläre mir Dependency Injection."
↓
trainiertes Modell
↓
generierte Antwort

Während normaler Inference werden die Basisgewichte des Modells nicht automatisch verändert. Ein langer Chat trainiert das Basismodell deshalb nicht automatisch weiter, ebenso wenig ein einzelner Prompt oder ein klassisches RAG-System.

Auch ein Produkt, das sich Informationen über mich „merkt“, muss dafür keine Modellgewichte verändern.

Inference ist die Nutzung des Modells, nicht automatisch neues Training.

Diese Trennung wird später noch wichtig, wenn wir über Context, Memory, Retrieval und Agents sprechen.

Token

Ein Token ist eine Verarbeitungseinheit, mit der ein Sprachmodell arbeitet. Es ist weder automatisch ein Wort noch automatisch ein einzelnes Zeichen.

Ein häufiges Wort kann aus einem Token bestehen, während ein seltenes oder zusammengesetztes Wort in mehrere Tokens zerlegt wird. Satzzeichen und Wortbestandteile können ebenfalls eigene Tokens bilden.

Wie genau diese Zerlegung aussieht, hängt vom jeweiligen Tokenizer ab. Deshalb können verschiedene Modelle für denselben Text unterschiedliche Tokenzahlen erzeugen. Auch dieselbe Aussage in unterschiedlichen Sprachen kann sehr unterschiedlich viele Tokens benötigen. [3]

Tokens spielen unter anderem bei Context-Größe, maximaler Ausgabelänge, Rechenaufwand, API-Limits und häufig auch bei der Abrechnung eine Rolle.

Ein Token ist aber zunächst eine technische Einheit und keine Währung.

Tokenizer

Der Tokenizer übersetzt Text in die Token-Einheiten, mit denen ein Modell arbeitet.

Aus einem Satz entsteht intern also nicht einfach eine Liste deutscher oder englischer Wörter, sondern eine Sequenz von Token-IDs. Der Tokenizer besitzt dafür ein Vokabular und ein Verfahren, mit dem Text in passende Einheiten zerlegt wird.

Er bildet damit einen wichtigen Teil der Schnittstelle zwischen unserem Text und dem Modell.

Input Tokens

Input Tokens sind die Tokens, die in eine Modellanfrage hineingehen. Das ist häufig deutlich mehr als die sichtbare Nachricht des Nutzers.

Je nach Anwendung können zusätzlich Systeminstruktionen, bisheriger Chatverlauf, Tool-Beschreibungen, Dokumente, Suchergebnisse, Memory-Einträge oder Projektinformationen Teil des Inputs sein.

Deshalb kann eine sehr kurze Nutzerfrage einen überraschend großen tatsächlichen Input erzeugen.

Output Tokens

Output Tokens sind die Tokens, die während der Generierung entstehen. Bei einem normalen Chat entspricht ein großer Teil davon dem Text, den wir anschließend sehen.

Bei manchen Reasoning-Systemen können APIs daneben interne reasoning tokens erfassen. Diese müssen nicht vollständig als sichtbarer Antworttext erscheinen. Wie sie gezählt, sichtbar gemacht oder abgerechnet werden, hängt vom jeweiligen Anbieter und Modell ab. [3]

Eine kurze sichtbare Antwort bedeutet deshalb nicht zwingend, dass während der Inference nur sehr wenig gerechnet wurde.

Cached Tokens

Moderne LLM-Dienste können Teile wiederkehrender Inputs zwischenspeichern. Wenn bei vielen Anfragen beispielsweise derselbe große System Prompt oder dieselbe Tool-Beschreibung verwendet wird, können vorherige Berechnungen teilweise wiederverwendet werden.

Anbieter weisen solche wiederverwendeten Eingaben teilweise als cached tokens aus und behandeln sie technisch oder kommerziell anders. OpenAI führt Cached Tokens beispielsweise als Teil der Input-Tokens, während auch andere große Anbieter Formen von Prompt beziehungsweise Context Caching bereitstellen. [3]

Wichtig bleibt:

Cached Tokens bleiben Tokens.

Caching macht den Inhalt weder zu dauerhaftem Modellwissen noch vergrößert es automatisch das Context Window. Es kann jedoch Berechnungen vermeiden und dadurch Kosten oder Latenz reduzieren.

Prompt Caching

Prompt Caching bezeichnet die Wiederverwendung bereits verarbeiteter Teile eines Prompts über mehrere Anfragen hinweg.

Das ist besonders interessant, wenn viele Requests mit demselben langen Anfang beginnen – etwa mit umfangreichen Agent-Instruktionen, Tool-Schemata oder Dokumenten. Statt diese Bestandteile immer wieder vollständig neu zu verarbeiten, können geeignete Systeme bereits berechnete Zustände wiederverwenden.

Wie lange ein Cache lebt, welche Bestandteile cachefähig sind und wie die Nutzung abgerechnet wird, ist anbieterspezifisch.

Prompt Caching ist deshalb weder automatisch Memory noch zusätzliches Training.

KV Cache

Der KV Cache, ausgeschrieben Key-Value Cache, ist ein technischer Optimierungsmechanismus bei der Inference vieler Transformer-Modelle.

Während ein autoregressives Modell Token für Token generiert, speichert der KV Cache bestimmte bereits berechnete Zustände aus den Attention-Schichten. Dadurch müssen sie beim nächsten Token nicht vollständig neu berechnet werden. [16]

Für das Grundverständnis reicht die Abgrenzung: KV Cache ist ein Mechanismus innerhalb der Modell-Inference. Prompt Caching ist ein darüberliegendes Caching-Konzept eines Systems oder Anbieters. Beide können miteinander zusammenhängen, sind aber nicht dasselbe.

Prompt

Ein Prompt ist die Eingabe beziehungsweise Instruktion, mit der wir ein Modell beeinflussen.

Das kann eine einfache Frage sein:

Was ist ein Event Loop?

Ein Prompt kann aber genauso Anforderungen, Beispiele, Daten, Regeln und Constraints enthalten. Gerade im Software Engineering nähert sich ein guter Prompt bei komplexeren Aufgaben deshalb häufig einer Spezifikation an:

Das ist das Ziel. Das ist der Context. Diese Grenzen gelten. Dieses Ergebnis erwarte ich.

Prompting ist damit deutlich weniger mystisch, als der Begriff Prompt Engineering zeitweise vermuten ließ.

System Prompt

Viele LLM-Anwendungen besitzen zusätzliche Instruktionen, die den Rahmen für eine Interaktion festlegen. Häufig werden diese als System Prompt bezeichnet.

Darin kann beispielsweise stehen, welche Rolle ein System einnehmen soll, welche Werkzeuge verfügbar sind, welche Regeln gelten oder welches Ausgabeformat erwartet wird. Diese Instruktionen müssen für den Nutzer nicht vollständig sichtbar sein.

Ein System Prompt kann das Verhalten eines Modells stark beeinflussen. Er ist trotzdem kein mathematischer Beweis dafür, dass jede Regel unter allen Bedingungen perfekt eingehalten wird.

Context

Der Context umfasst vereinfacht die Informationen, die dem Modell für seine aktuelle Verarbeitung zur Verfügung stehen.

Dazu können die Nutzeranfrage, Systeminstruktionen, bisheriger Gesprächsverlauf, Dokumente, Tool-Ergebnisse, Memory-Inhalte oder Ergebnisse eines Retrieval-Systems gehören.

Context ist damit etwas anderes als Wissen, das während des Trainings in den Modellparametern entstanden ist. Wenn ich einem Modell eine neue API-Dokumentation in den Context gebe, kann es damit arbeiten, obwohl diese Dokumentation niemals Teil seines Trainings gewesen sein muss.

Nach der Anfrage sind die Basisgewichte dadurch trotzdem unverändert.

Context ist kein Training.

Context Window

Das Context Window beschreibt, wie viel Context ein Modell beziehungsweise ein konkreter Modell-Endpunkt innerhalb einer Verarbeitung unterstützen kann. Die Größe wird üblicherweise in Tokens angegeben.

Ein Context Window von 128k bedeutet deshalb nicht 128.000 Wörter, sondern ungefähr 128.000 Tokens. Wie Input und Output gegen dieses Limit gerechnet werden, hängt vom jeweiligen Modell und API-Design ab.

Ein großes Context Window ist praktisch wertvoll, bedeutet aber nicht automatisch, dass jede enthaltene Information gleich zuverlässig genutzt wird. Das bekannte Lost in the Middle-Paper zeigte bereits bei frühen Long-Context-Modellen deutliche Unterschiede abhängig davon, an welcher Position relevante Informationen lagen. [5] Spätere Arbeiten und neuere Modelle haben diese Fähigkeiten weiterentwickelt, die grundlegende Unterscheidung bleibt trotzdem sinnvoll:

In den Context passen und den Context zuverlässig nutzen sind zwei verschiedene Eigenschaften.

Context Engineering

Context Engineering bezeichnet die bewusste Gestaltung dessen, was einem Modell für eine Aufgabe zur Verfügung gestellt wird.

Dazu kann weit mehr gehören als der eigentliche Prompt: Systeminstruktionen, relevante Dateien, Tool-Beschreibungen, Beispiele, Memory, Retrieval-Ergebnisse, aktueller Zustand und Regeln darüber, welche Informationen wann geladen werden.

Damit verschiebt sich die Frage von:

Wie formuliere ich den perfekten Prompt?

zu:

Welche Informationen braucht das Modell für diese konkrete Entscheidung – und welche nicht?

Context Engineering ist deshalb kein neues Modellverfahren. Es ist vor allem Engineering rund um die Informationsversorgung des Modells.

Gerade bei Coding Agents wird dieser Begriff später noch wichtig.

Probabilistic

LLMs sind probabilistische Modelle. Das bedeutet nicht, dass sie einfach irgendetwas auswürfeln.

Für eine mögliche Fortsetzung berechnet ein Sprachmodell Werte, aus denen sich Wahrscheinlichkeiten für mögliche nächste Tokens ableiten lassen. Ein stark vereinfachtes Beispiel könnte so aussehen:

"Der Himmel ist ..."

blau      0,61
heute     0,08
klar      0,07
grün      0,01
...

Die Zahlen sind erfunden, das Prinzip nicht. Verschiedene mögliche Fortsetzungen werden unter den aktuellen Bedingungen unterschiedlich bewertet.

Wie aus dieser Verteilung anschließend tatsächlich ein Token ausgewählt wird, ist eine weitere Entscheidung.

Sampling

Sampling bezeichnet Verfahren, mit denen aus möglichen nächsten Tokens eine konkrete Auswahl entsteht.

Ein System kann immer das aktuell wahrscheinlichste Token wählen. Es kann aber auch aus mehreren plausiblen Kandidaten sampeln. Dafür existieren unterschiedliche Strategien und Parameter, etwa Temperature, Top-K oder Top-P. [4]

Damit wird auch verständlich, warum „probabilistisch“ nicht automatisch bedeutet, dass jede Anfrage völlig anders beantwortet werden muss. Ebenso wenig garantiert derselbe Prompt immer dieselbe Ausgabe.

Das Modell erzeugt eine Verteilung möglicher Fortsetzungen; die Decoding-Strategie beeinflusst, wie daraus die konkrete Sequenz entsteht.

Temperature

Temperature beeinflusst bei vielen Generierungsverfahren, wie stark sich die Auswahl auf besonders wahrscheinliche Tokens konzentriert.

Niedrigere Werte führen typischerweise zu einer stärker fokussierten Auswahl. Höhere Werte erlauben mehr Gewicht für alternative Kandidaten und damit häufig mehr Variation. [4]

Die verbreitete Kurzform

niedrige Temperature = korrekt, hohe Temperature = kreativ

ist deshalb zu simpel. Temperature verändert zunächst die Verteilung beziehungsweise Auswahl. Ob eine Antwort dadurch fachlich besser oder schlechter wird, hängt von Aufgabe, Modell und Decoding-Verfahren ab.

Auch temperature: 0 sollte nicht universell mit vollständiger Deterministik gleichgesetzt werden. APIs und Inference-Systeme können sich unterscheiden, und auch andere Teile der Verarbeitung können Variabilität erzeugen. Anthropic dokumentiert diese Einschränkung ausdrücklich.

Reasoning

Reasoning ist einer der Begriffe, bei denen technische Bedeutung und Marketing besonders leicht ineinanderlaufen.

In Forschung und Produkten bezeichnet der Begriff heute häufig Modelle oder Verfahren, die bei komplexeren Problemen zusätzliche Arbeit während der Inference investieren. Ein System kann beispielsweise mehr Zwischenschritte berechnen, mehrere Kandidaten erzeugen, Lösungswege prüfen oder zusätzliche Such- und Verifikationsschritte einsetzen.

In diesem Umfeld begegnen einem Begriffe wie test-time compute, inference-time compute, reasoning tokens oder thinking tokens. Diese Begriffe sind nicht vollständig synonym.

Test-Time beziehungsweise Inference-Time Compute bezeichnet allgemein zusätzliche Berechnung während der konkreten Aufgabe nach Abschluss des Trainings. Forschung zeigt, dass mehr Inference-Berechnung bei geeigneten Aufgaben die Lösungsqualität steigern kann, wobei der Effekt stark vom Verfahren und Problem abhängt. [6][7]

Reasoning Tokens oder Thinking Tokens sind dagegen häufig konkrete Implementierungs- beziehungsweise Produktbegriffe für interne Verarbeitungsschritte.

Der wichtigste Punkt ist deshalb weniger technisch als sprachlich:

Reasoning bedeutet nicht automatisch menschliches Denken, Bewusstsein oder Verständnis.

Der Begriff beschreibt Fähigkeiten beziehungsweise Verfahren eines AI-Systems und ist keine Aussage darüber, dass darin ein menschlicher Denkprozess stattfindet.

Hallucination

Von einer Hallucination sprechen wir bei LLMs typischerweise dann, wenn das Modell Inhalte erzeugt, die nicht mit den zugrunde liegenden Fakten, Quellen oder dem vorgegebenen Context übereinstimmen und dabei trotzdem plausibel formuliert wirken.

In Softwareentwicklung kann das eine Methode sein, die in einer Library überhaupt nicht existiert, eine erfundene API oder eine überzeugend klingende Quelle, die nie veröffentlicht wurde.

Nicht jeder Fehler ist deshalb automatisch eine Hallucination. Ein Modell kann eine Anforderung missverstehen, falsch rechnen, eine tatsächlich existierende aber veraltete API verwenden oder eine schlechte Architekturentscheidung treffen. Auch das kann falsch sein, beschreibt aber andere Fehlertypen.

Der Begriff selbst ist außerdem eine Metapher. Er sollte nicht so verstanden werden, als würde das Modell etwas im menschlichen Sinn „sehen“.

Noise

Noise ist im LLM-Umfeld kein sauber definierter wissenschaftlicher Fachbegriff. Entwickler verwenden ihn eher als praktische Sammelbezeichnung für Output, der zwar plausibel aussieht, für die eigentliche Aufgabe aber wenig Wert besitzt.

Das können unnötig lange Erklärungen, zusätzliche Abstraktionen, nicht angeforderte Änderungen oder fünf Absätze selbstbewusst formulierter Text sein, aus denen am Ende ein verwertbarer Satz übrig bleibt.

Bei Coding Agents kann Noise zusätzlich bedeuten, dass ein Agent neben einer kleinen gewünschten Änderung noch diverse „Verbesserungen“ durchführt und dadurch den Review-Aufwand vergrößert.

Der Begriff beschreibt damit eher das wahrgenommene Signal-Rausch-Verhältnis des Outputs als einen klar definierten Mechanismus des Modells.

Embedding

Ein Embedding ist eine numerische Repräsentation von Informationen. Text, Bilder oder andere Inhalte werden dabei als Vektoren aus Zahlen dargestellt.

Für diesen Artikel reicht der wichtigste praktische Effekt: Gute Embedding-Modelle können Inhalte so abbilden, dass semantisch ähnliche Informationen im entstehenden Vektorraum häufig näher beieinander liegen.

Dadurch kann eine Anwendung nach Bedeutung und Ähnlichkeit suchen, statt ausschließlich nach exakt denselben Wörtern.

Embeddings sind deshalb beispielsweise für semantische Suche und viele RAG-Systeme interessant. Sie sind aber keine kleine lesbare Kopie eines Dokuments, die lediglich in Zahlen umgeschrieben wurde.

RAG – Retrieval-Augmented Generation

Retrieval-Augmented Generation verbindet Informationssuche mit generativer Ausgabe.

Das Grundprinzip ist einfach:

Frage
↓
relevante Informationen suchen
↓
gefundene Informationen in den Context
↓
LLM
↓
Antwort

Das ursprüngliche RAG-Paper beschreibt die Verbindung von parametrischem Modellwissen mit extern abgerufenen Informationen. [8]

Retrieval kann heute sehr unterschiedlich umgesetzt werden: mit Embeddings und Vector Search, klassischer Volltextsuche, Datenbanken, APIs oder Kombinationen daraus.

Deshalb ist RAG nicht automatisch gleichbedeutend mit einer Vektordatenbank.

Noch wichtiger für unsere Begriffstrennung:

RAG trainiert das Modell normalerweise nicht neu. Die gefundenen Informationen werden zur Laufzeit bereitgestellt und gelangen typischerweise in den Context.

Tool Calling / Function Calling

Beim Tool Calling kann ein Modell strukturierte Ausgaben erzeugen, mit denen die umgebende Anwendung eine externe Funktion oder ein Werkzeug ansteuert.

Statt beispielsweise selbst eine Wetterinformation zu erfinden, könnte das Modell signalisieren:

Tool: getWeather
Argument:
  city: Berlin

Die eigentliche Operation findet anschließend außerhalb des Sprachmodells statt. Die Laufzeit beziehungsweise Anwendung führt die Funktion aus und gibt das Ergebnis zurück. Manche Plattformen stellen solche Tools direkt serverseitig bereit, das Prinzip bleibt aber dasselbe. [9]

Ein LLM besitzt also nicht allein deshalb Internetzugang, eine Shell oder Zugriff auf ein Dateisystem, weil es ein LLM ist. Diese Fähigkeiten entstehen durch das Gesamtsystem aus Modell, Tools und Berechtigungen.

Computer Use

Computer Use erweitert dieses Prinzip auf grafische Benutzeroberflächen.

Ein Modell beziehungsweise Agent kann beispielsweise Screenshots erhalten und anschließend Aktionen wie Klicks oder Tastatureingaben anfordern. Eine kontrollierende Laufzeitumgebung führt diese Aktionen aus.

Damit lassen sich auch Anwendungen bedienen, für die keine passende API existiert.

Computer Use erweitert allerdings nicht nur die Fähigkeiten eines Systems, sondern auch seine Risiken. Ein Agent, der tatsächlich klicken, schreiben oder Formulare absenden kann, benötigt andere Sicherheits- und Freigabemechanismen als ein Modell, das ausschließlich Text erzeugt.

Memory

Memory ist einer der unschärfsten Begriffe rund um LLM-Produkte.

Ein System kann Nutzerpräferenzen in einer Datenbank speichern. Ein Coding Agent kann Projektinformationen persistieren. Eine Chat-Anwendung kann frühere Gespräche durchsuchen und relevante Inhalte erneut in den Context laden. Ein Agent kann seinen Zustand zwischen zwei Arbeitsschritten sichern.

All diese Mechanismen werden je nach Produkt als Memory bezeichnet.

Gemeinsam ist ihnen häufig, dass Informationen zusätzlich zum eigentlichen Basismodell gespeichert und später wieder eingebracht werden.

Memory bedeutet deshalb nicht automatisch, dass die Modellgewichte verändert wurden.

Ein System kann sich sehr überzeugend an etwas „erinnern“, indem es die Information außerhalb des Modells speichert und beim nächsten Request erneut in den Context legt.

Agent

Für den Begriff Agent existiert keine einzige technische Definition, auf die sich Forschung, Anbieter und Entwickler vollständig geeinigt hätten.

Für unsere Zwecke reicht zunächst eine praktische Beschreibung:

Ein Agent kombiniert ein Modell mit einem Ziel, Context beziehungsweise Zustand, Werkzeugen und einem Ablauf, in dem mehrere Schritte ausgeführt und deren Ergebnisse erneut verarbeitet werden können.

Ein einfacher Agentic Loop könnte so aussehen:

Ziel
↓
Situation bewerten
↓
nächste Aktion auswählen
↓
Tool ausführen
↓
Ergebnis beobachten
↓
erneut bewerten
↓
...
↓
fertig

Eine nützliche Unterscheidung besteht darin, wie stark der Ablauf fest programmiert ist und wie viel Entscheidungsspielraum das Modell über den nächsten Schritt besitzt. Anthropic unterscheidet beispielsweise zwischen stärker vordefinierten Workflows und Agents, bei denen das Modell den Prozess dynamischer steuert. [12]

In realen Produkten ist diese Grenze allerdings fließend. Nicht alles, worauf „Agent“ steht, besitzt denselben Grad an Autonomie.

Coding Agent

Ein Coding Agent ist ein Agent, dessen Umgebung und Werkzeuge auf Softwareentwicklung ausgerichtet sind.

Er kann beispielsweise ein Repository durchsuchen, Dateien lesen und verändern, Compiler oder Linter starten, Tests ausführen, Git-Diffs untersuchen oder Shell-Befehle verwenden.

Dadurch unterscheidet er sich deutlich von einem Chat, der lediglich auf einen eingefügten Codeblock antwortet. Ein Coding Agent kann seine eigenen Änderungen erneut beobachten:

Code ändern
↓
Tests ausführen
↓
Fehler lesen
↓
Ursache untersuchen
↓
Code korrigieren
↓
erneut testen

Gerade dieser Feedback-Loop ist ein wesentlicher Bestandteil moderner Agentic-Coding-Workflows.

Ein Subagent ist in diesem Zusammenhang meist ein weiterer Agent, an den eine enger begrenzte Teilaufgabe delegiert wird. Auch dieser Begriff beschreibt keine einheitlich standardisierte Architektur.

Agent Harness

Der Begriff Agent Harness beschreibt die Laufzeit- und Kontrollschicht rund um das eigentliche Modell.

Dort können Context aufgebaut, Tool-Aufrufe gesteuert, Zustand gehalten, Berechtigungen geprüft, Freigaben eingeholt und mehrstufige Agent-Loops organisiert werden. Microsoft beschreibt einen Agent Harness aktuell entsprechend als Runtime-Scaffolding, das ein Sprachmodell mit den Komponenten ausstattet, die für länger laufende Agentenarbeit notwendig sind. [13]

Die Trennung ist hilfreich:

Modell
=
erzeugt Ausgaben und Entscheidungen

Harness
=
organisiert Context, Tools, State,
Berechtigungen und Ablauf

Agent
=
entsteht aus dem Zusammenspiel

Wenn zwei Coding-Produkte dasselbe Basismodell verwenden und trotzdem sehr unterschiedlich gut arbeiten, kann ein erheblicher Teil dieses Unterschieds im Harness liegen.

Agentic AI

Agentic AI ist ein Oberbegriff für AI-Systeme, die über eine einzelne Antwort hinaus stärker selbstständig auf ein Ziel hinarbeiten. Dazu können Planung, Tool-Nutzung, Beobachtung von Zwischenergebnissen, mehrere aufeinanderfolgende Aktionen und Anpassungen des weiteren Vorgehens gehören.

Auch Institutionen wie NIST verwenden den Begriff inzwischen für stärker autonome, zielgerichtete AI-Systeme. [11]

Trotzdem besitzt „agentic“ keine scharfe technische Grenze. Zwischen einem System, das aus drei fest vorgegebenen API-Aufrufen einen auswählt, und einem Coding Agent, der über längere Zeit ein Repository untersucht und Aufgaben delegiert, liegt ein großer Unterschied. Auf Produktseiten können trotzdem beide als agentic bezeichnet werden.

Agentic ist also weder eine neue Art von Modellarchitektur noch automatisch gleichbedeutend mit vollständiger Autonomie.

MCP – Model Context Protocol

Das Model Context Protocol, kurz MCP, standardisiert die Verbindung zwischen AI-Anwendungen und externen Fähigkeiten beziehungsweise Informationen.

Stand September 2026 ist 2026-07-28 die aktuelle MCP-Spezifikation. Diese Version hat unter anderem den Protokollkern stärker auf zustandslose Request/Response-Kommunikation ausgerichtet. [10]

Für das grundsätzliche Verständnis ist aber wichtiger, was MCP überhaupt tut. MCP-Server können standardisierte Fähigkeiten wie Tools, Resources und Prompts bereitstellen, die kompatible Hosts beziehungsweise Clients entdecken und verwenden können.

Vereinfacht:

AI-Anwendung
↓
MCP Client
↓
standardisiertes Protokoll
↓
MCP Server
↓
Tools / Resources / externe Systeme

Dadurch muss nicht jedes AI-Produkt für jedes Werkzeug und jede Datenquelle eine völlig eigene Integration definieren.

MCP ist dabei weder ein Modell noch ein Agent. Es ist auch nicht automatisch RAG oder Memory. Ein Agent kann MCP verwenden, um ein Tool aufzurufen, ein Retrieval-System kann darüber Daten beziehen und ein Memory-System könnte darüber angebunden sein.

MCP standardisiert die Verbindung. Es ist nicht der Agent, der sie benutzt.

Frontier Model

Frontier Model bezeichnet keine bestimmte Modellarchitektur.

Der Begriff wird typischerweise für hochleistungsfähige General-Purpose-Modelle nahe der jeweils aktuellen Leistungsgrenze verwendet. Auch die britische Definition von Frontier AI betont genau diesen relativen Charakter: Gemeint sind Systeme, deren Fähigkeiten den jeweils fortschrittlichsten Modellen entsprechen oder darüber liegen. [14]

Das Wort „jeweils“ ist entscheidend. Was 2023 zur Frontier gehörte, muss 2026 längst nicht mehr an der Leistungsgrenze liegen.

Frontier beschreibt deshalb eine Position im aktuellen Stand der Technik und keine konkrete technische Bauweise.

Multimodal

Ein multimodales Modell beziehungsweise System kann mehrere Arten von Informationen verarbeiten oder erzeugen.

Typische Modalitäten sind Text, Bilder, Audio und Video. Ein Modell kann beispielsweise Text und Bilder als Input akzeptieren, aber ausschließlich Text erzeugen. Ein anderes kann Sprache sowohl entgegennehmen als auch generieren.

„Multimodal“ bedeutet deshalb nicht automatisch, dass ein Modell jede denkbare Modalität gleichermaßen lesen und erzeugen kann. Die konkret unterstützten Ein- und Ausgaben müssen weiterhin betrachtet werden.

Ein VLM – Vision Language Model bezeichnet in diesem Umfeld insbesondere Modelle, die visuelle Informationen und Sprache gemeinsam verarbeiten.

Open Weights

Bei einem Open-Weights-Modell werden die trainierten Modellgewichte verfügbar gemacht. Dadurch können sie – sofern Lizenz, Software und Hardware dies erlauben – beispielsweise heruntergeladen und auf eigener Infrastruktur verwendet werden.

Das bedeutet allerdings nicht, dass alles rund um das Modell offen ist. Trainingsdaten können unbekannt sein, Trainingscode kann fehlen, die Lizenz kann Nutzungen einschränken und der vollständige Trainingsprozess muss nicht reproduzierbar sein.

Open Weights bedeutet zunächst, dass die Gewichte verfügbar sind – nicht, dass das gesamte Modellprojekt offen ist.

Open Source

Bei klassischer Software besitzt Open Source eine etablierte Bedeutung. Bei AI-Systemen ist die Übertragung komplizierter, weil neben Code auch Modellparameter, Trainingsverfahren und Informationen über Trainingsdaten relevant werden.

Die Open Source Initiative hat deshalb 2024 ihre Open Source AI Definition 1.0 veröffentlicht. Sie verlangt die Freiheiten, ein AI-System zu verwenden, zu untersuchen, zu verändern und weiterzugeben und definiert Anforderungen an Code, Parameter und Informationen über die Trainingsdaten. [15]

Diese Definition beendet nicht jede Debatte über den Begriff. Sie liefert aber einen wesentlich präziseren Maßstab als ein beliebiges „Open“ auf einer Produktseite.

Für technische Diskussionen bleibt deshalb eine einfache Unterscheidung hilfreich:

Open Weights ist nicht automatisch Open Source.

Local Model

Ein Local Model läuft im engeren Sinn direkt auf einem lokalen Gerät beziehungsweise Rechner – beispielsweise auf dem Entwickler-PC, Notebook oder einer Workstation.

Davon sollte man self-hosted unterscheiden. Ein self-hosted Modell kann ebenfalls unter eigener Kontrolle betrieben werden, aber beispielsweise auf einem internen GPU-Server oder in einem unternehmenseigenen Cluster laufen.

Im Alltag werden beide Begriffe manchmal vermischt. Für technische Diskussionen ist die Unterscheidung nützlich:

local
=
läuft auf dem lokalen Gerät


self-hosted
=
läuft auf Infrastruktur,
die ich oder meine Organisation kontrolliere

Beides sagt zunächst nichts über Qualität, Lizenz oder Offenheit des Modells aus. Ein Open-Weights-Modell kann lokal laufen, muss es aber nicht.

MoE – Mixture of Experts

Bei einem Mixture-of-Experts-Modell, kurz MoE, enthalten bestimmte Modellschichten mehrere Teilnetze, die als Experts bezeichnet werden. Ein Router entscheidet während der Verarbeitung, welche davon für einen konkreten Token verwendet werden.

Der Name „Expert“ sollte dabei nicht zu wörtlich genommen werden. Es muss nicht einen klar interpretierbaren „Java-Expert“, „Mathematik-Expert“ oder „Deutsch-Expert“ geben. Technisch handelt es sich zunächst um unterschiedliche Teilnetze, zwischen denen das Modell routet.

Ein bekanntes Beispiel ist Mixtral 8x7B, bei dem pro Token nur zwei von acht Experts ausgewählt werden. [17]

Vereinfacht:

Token
↓
Router
↓
┌────────┬────────┬────────┬────────┐
Expert A Expert B Expert C Expert D
   ✓               ✓
↓
ausgewählte Experts rechnen weiter

Dadurch kann ein Modell sehr viele Gesamtparameter besitzen, ohne bei jedem Token sämtliche Experts gleichzeitig zu verwenden.

Total Parameters

Total Parameters bezeichnet bei einem MoE-Modell die Gesamtzahl seiner Parameter. Dazu gehören auch Parameter aus Experts, die für einen konkreten Token gerade nicht ausgewählt werden.

Diese Zahl sagt deshalb etwas über die gesamte Modellgröße aus, aber nicht direkt darüber, wie viele Parameter bei jedem einzelnen Verarbeitungsschritt beteiligt sind.

Active Parameters

Active Parameters bezeichnet die Parameter, die für einen konkreten Verarbeitungspfad tatsächlich verwendet werden. Bei sparsamen MoE-Modellen kann diese Zahl erheblich kleiner sein als die Zahl der Total Parameters.

Wie ein Hersteller diese Angabe genau berechnet, sollte im Zweifel in Modellkarte oder Paper geprüft werden, denn neben den Experts existieren weitere gemeinsam verwendete Modellteile.

Der entscheidende Punkt bleibt:

sehr viele Total Parameters
≠
alle Parameter arbeiten bei jedem Token gleichzeitig

Bei einem MoE-Modell ist deshalb eine riesige Parameterzahl ohne zusätzliche Information wesentlich weniger aussagekräftig, als sie zunächst klingt.

Quantization

Quantization reduziert die numerische Präzision, mit der Modellwerte gespeichert beziehungsweise teilweise berechnet werden. Das Ziel besteht typischerweise darin, Speicherbedarf und Rechenaufwand zu reduzieren.

Modelle werden häufig bereits in Formaten wie FP16 oder BF16 betrieben. Stärkere Quantisierungsverfahren können Gewichte beispielsweise auf 8 Bit, 4 Bit oder noch kompaktere Darstellungen reduzieren. Je nach Verfahren lassen sich auch andere Teile der Inference quantisieren. [16]

Das ist besonders für lokale Modelle interessant, weil ein Modell in voller Präzision möglicherweise nicht in den verfügbaren GPU-Speicher passt, in quantisierter Form aber durchaus.

Dabei können Qualitätsverluste entstehen. Wie stark diese ausfallen, hängt vom Modell, Verfahren, der Bitbreite und der konkreten Aufgabe ab.

Die Vorstellung

4 Bit statt 16 Bit = nur noch ein Viertel der Intelligenz

ist deshalb falsch. Numerische Präzision und Modellfähigkeit skalieren nicht auf diese Weise.

Quantisierung ist vor allem ein Engineering-Trade-off zwischen Speicherbedarf, Rechenaufwand, Hardwareanforderungen und möglicher Qualitätsveränderung.

Credit

Und damit kommen wir zu einem Begriff, der mit der eigentlichen Funktionsweise eines LLMs erstaunlich wenig zu tun hat.

Ein Credit ist keine fundamentale technische Einheit eines Sprachmodells. Credits sind Produkt- beziehungsweise Abrechnungslogik eines Anbieters.

Ein Credit könnte einer bestimmten Menge Tokens entsprechen, einem Tool-Aufruf, einer Minute Rechenzeit, einem Modellaufruf oder einer beliebigen Kombination daraus. Was ein Credit tatsächlich bedeutet, muss deshalb beim jeweiligen Produkt nachgelesen werden.

Aus

Dieses Produkt enthält 10.000 Credits.

lässt sich ohne weitere Informationen kaum etwas über die tatsächliche LLM-Nutzung ableiten.

Begriff	Bedeutung
Token	technische Verarbeitungseinheit eines Modells
Credit	anbieterspezifische Nutzungs- oder Abrechnungseinheit

Tokens gehören zur Technik. Credits gehören zum Produkt- oder Geschäftsmodell.

Ein Anbieter kann Credits anhand von Tokens berechnen. Dadurch werden Credits aber nicht zu Tokens.

Vom Buzzword zum gemeinsamen Vokabular

Damit haben wir noch keine Machine-Learning-Ausbildung absolviert. Das war auch nicht das Ziel.

Wir können jetzt aber viele Begriffe, die auf Modellkarten, Produktseiten und in Entwicklerdiskussionen ständig auftauchen, sauberer voneinander trennen. Ein Modell wird trainiert und anschließend während der Inference verwendet. Es verarbeitet Tokens innerhalb eines Contexts. Der Tokenizer bestimmt, wie Text in diese Einheiten zerlegt wird. Sampling beeinflusst, wie aus möglichen Fortsetzungen eine konkrete Ausgabe entsteht. Reasoning kann zusätzliche Berechnung während der Inference umfassen, ohne deshalb menschliches Denken zu bedeuten.

RAG bringt externe Informationen in den Context, Memory kann Informationen außerhalb des Modells speichern und Tools geben einem AI-System Handlungsmöglichkeiten. Ein Harness organisiert Teile dieser Umgebung, während ein Agent sie über mehrere Schritte verwenden kann. MCP wiederum kann standardisieren, wie solche Systeme mit externen Fähigkeiten verbunden werden.

Und Credits? Die entscheiden möglicherweise nur darüber, wie lange uns der Anbieter dabei zuschauen lässt.

Damit ist die Begriffswelt hoffentlich etwas weniger mysteriös; wer einen Begriff später nachschlagen möchte, findet ihn im Glossar der Serie. Der nächste Schritt ist jedoch schwieriger: Wenn Anbieter behaupten, ein Coding Agent löse einen bestimmten Anteil realer Softwareaufgaben, woher kommt diese Zahl eigentlich?

Was ist ein Benchmark? Was misst SWE-bench? Was bedeuten Verified, Pro oder Pass@k? Und warum ist ein Benchmark-Ergebnis nicht einfach der Prozentsatz eines Softwareentwicklers, den ein Modell ersetzen kann?

Darum geht es im nächsten Artikel.

Quellen

[1] Ashish Vaswani, Noam Shazeer, Niki Parmar et al.: Attention Is All You Need. Advances in Neural Information Processing Systems 30, 2017. arXiv: 1706.03762.

[2] Rishi Bommasani, Drew A. Hudson, Ehsan Adeli et al.: On the Opportunities and Risks of Foundation Models. Stanford Center for Research on Foundation Models, 2021. arXiv: 2108.07258.

[3] OpenAI: Dokumentation zu Tokens, Usage, Reasoning Tokens und Prompt Caching. Stand 2026.

[4] Hugging Face Transformers: Generation / GenerationConfig. Technische Dokumentation, Stand 2026.

[5] Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, Percy Liang: Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics 12, 2024, S. 157–173. DOI: 10.1162/tacl_a_00638.

[6] Charlie Snell, Jaehoon Lee, Kelvin Xu, Aviral Kumar: Scaling LLM Test-Time Compute Optimally Can Be More Effective than Scaling Parameters for Reasoning. International Conference on Learning Representations, 2025.

[7] Mohsen Hariri et al.: Test-Time Scaling in Reasoning LLMs: Inference Regimes, Evaluation, and Reproducibility. Preprint, 2026. arXiv: 2608.04001.

[8] Patrick Lewis, Ethan Perez, Aleksandra Piktus et al.: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Advances in Neural Information Processing Systems 33, 2020. arXiv: 2005.11401.

[9] Anthropic: Tool use with Claude und How tool use works. Technische Dokumentation, Stand 2026.

[10] Model Context Protocol: Model Context Protocol Specification 2026-07-28 und begleitende Release Notes, 28. Juli 2026.

[11] National Institute of Standards and Technology: Agentic AI. NIST, 2026.

[12] Anthropic: Building Effective Agents. Technische Dokumentation.

[13] Microsoft: Agent Harness. Microsoft Agent Framework Documentation, Stand August 2026.

[14] UK Department for Science, Innovation and Technology: Frontier AI: capabilities and risks – discussion paper. Aktualisierte Fassung 2025.

[15] Open Source Initiative: The Open Source AI Definition – Version 1.0. 2024, stabile Version, Stand September 2026.

[16] Hugging Face Transformers: Dokumentation zu Quantization, Cache strategies und How caching works. Stand 2026.

[17] Albert Q. Jiang et al.: Mixtral of Experts. 2024. arXiv: 2401.04088.