WISSEN > KI ARCHITEKTUR > LLM GRUNDLAGEN
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
Was ist ein Large Language Model (LLM) und wie funktioniert es?
Wie Sprachmodelle arbeiten und warum das Betriebsmodell zur Architekturfrage wird
Das sollten Sie mitnehmen:
- Ein LLM ist nicht die gesamte KI-Anwendung.
Es bildet die Modell- und Generierungsschicht; Storage, RAG, APIs und MCP sind eigene Bestandteile.
- LLMs verarbeiten Tokens, keine Wörter.
Tokenizer zerlegen Eingaben in Einheiten, die das neuronale Netz als numerische Repräsentationen weiterverarbeitet.
- Attention ist die technische Grundlage moderner Modelle.
Sie erlaubt es, bei der Repräsentation eines Tokens andere Positionen der Sequenz einzubeziehen.
- Training und RAG lösen verschiedene Aufgaben.
Training verändert Modellparameter, RAG stellt dem fertigen Modell zur Laufzeit Kontext bereit.
- Das Bereitstellungsmodell gehört zur Modellfamilie, nicht zum Anbieter.
Nahezu alle Anbieter führen beides parallel; Lizenz und Betriebsverantwortung sind pro Modell zu prüfen.
Was ist ein Large Language Model (LLM) und wie funktioniert es?
Inhaltsverzeichnis
- Ein Modell erzeugt jede Antwort Wort für Wort neu
- Ein LLM berechnet Wahrscheinlichkeiten für Token-Sequenzen
- Attention löst das Problem der Bezüge innerhalb einer Sequenz
- Das Kontextfenster ist nicht das Wissen des Modells
- Training verändert das Modell, RAG verändert es nicht
- Mixture of Experts bedeutet nicht größeres Modell, sondern selektive Aktivierung
- Das Bereitstellungsmodell ist eine Eigenschaft der Modellfamilie, nicht des Anbieters
- Eigenbetrieb verschiebt Verantwortung, er reduziert sie nicht
- Benchmarks beantworten die Betriebsfrage nicht
- Das LLM verarbeitet Kontext, die Infrastruktur bestimmt ihn
- Fazit
- Quellen
Large Language Models bilden die Modell- und Generierungsschicht vieler heutiger KI-Anwendungen. Sie analysieren Eingaben, verarbeiten den bereitgestellten Kontext und erzeugen daraus Text, Programmcode oder strukturierte Ausgaben.
Dabei wird das LLM häufig mit der gesamten KI-Anwendung gleichgesetzt, und technisch ist diese Gleichsetzung falsch: Ein LLM ist zunächst ein trainiertes Modell. Unternehmensdaten, Retrieval-Augmented Generation (RAG), Vektordatenbanken, Storage, APIs oder das Model ContextProtocol (MCP) sind davon getrennte Komponenten, die mit einem LLM zu einer Anwendung verbunden werden können.
Für Unternehmen ist diese Unterscheidung wesentlich, denn die Entscheidung für ein bestimmtes Modell beantwortet noch nicht die Fragen, wo Unternehmensdaten liegen, wie sie gefunden werden, welche Benutzer darauf zugreifen dürfen oder wie eine KI aktuelle Informationen und externe Systeme einbindet. Wir trennen im Folgenden deshalb konsequent zwischen dem Modell selbst und der Infrastruktur, die es mit Daten und Funktionen versorgt.
Ein Modell erzeugt jede Antwort Wort für Wort neu
Bevor Formeln und Fachbegriffe ins Spiel kommen, lohnt sich ein Blick darauf, was beim Beantworten einer Frage tatsächlich abläuft. Eine fertige Antwort erweckt den Eindruck, sie sei als Ganzes entstanden. Tatsächlich entsteht sie in vielen kleinen Schritten, und dieser Ablauf erklärt fast alle Eigenschaften, die später technisch beschrieben werden.
Das Modell bekommt einen Text und bestimmt, wie dieser Text plausibel weitergeht. Das Ergebnis hängt es an, betrachtet den nun etwas längeren Text und bestimmt erneut die Fortsetzung. Diesen Schritt wiederholt es, bis die Antwort fertig ist. Eine Frage ist für das Modell dabei nichts anderes als ein Textanfang; die Fortsetzung sieht aus wie eine Antwort, weil das Modell aus sehr großen Textmengen gelernt hat, wie Antworten auf Fragen üblicherweise aussehen. Nichts an diesem Ablauf ähnelt einer Datenbankabfrage.
Der Vergleich mit der Wortvorhersage auf dem Smartphone liegt nahe und trifft das Prinzip. Er unterschätzt allerdings, wie weit es trägt. Die Tastatur betrachtet die letzten Wörter, ein großes Sprachmodell betrachtet den gesamten bisherigen Zusammenhang und hat gelernt, welche Bestandteile eines Textes aufeinander Bezug nehmen. Aus diesem Unterschied entsteht der Sprung von brauchbaren Wortvorschlägen zu zusammenhängender Argumentation, funktionierendem Programmcode und strukturierten Ausgaben.
Was vom Training bleibt, sind Muster, keine Texte
Beim Training hat das Modell keine Textsammlung abgelegt, in der es später nachschlagen könnte. Was zurückbleibt, sind Zahlenwerte, die beschreiben, welche sprachlichen Muster in welchen Zusammenhängen aufgetreten sind. Man kann sich das wie einen Menschen vorstellen, der außergewöhnlich viel gelesen hat, sich an kein einzelnes Buch mehr erinnert, aber ein sehr genaues Gefühl dafür entwickelt hat, wie über ein Thema geschrieben wird.
Weil diese Zahlenwerte nur Muster abbilden, folgt daraus die zweite Eigenschaft: Das Modell erzeugt auch dann eine flüssige Antwort, wenn es die Sache nicht kennt. Eine erfundene Quelle oder eine nicht existierende Konfigurationsoption fügt sich sprachlich ebenso glatt ein wie eine zutreffende Angabe, denn ein Prüfschritt, der zwischen beidem unterscheidet, ist im Verfahren nicht vorgesehen. Sicheres Auftreten ist deshalb kein Hinweis auf Richtigkeit.
Von der Anschauung zur Technik
Die folgenden Kapitel lösen dieses Bild schrittweise auf und benennen dabei keine anderen Vorgänge, sondern dieselben genauer. Was hier „Text" heißt, zerlegt das Modell in Tokens. Was als Gefühl für Zusammenhänge beschrieben wurde, leistet der Attention-Mechanismus. Die Zahlenwerte aus dem Training sind die Modellparameter, und die plausibelste Fortsetzung ist präzise gefasst eine Wahrscheinlichkeitsverteilung über mögliche nächste Tokens.
Welche Folgen dieser Ablauf für die Dateninfrastruktur um das Modell herum hat — warum ein Modell die Bestände eines Unternehmens nicht kennt und welche Architektur daraus entsteht — behandeln wir an anderer Stelle. Hier geht es um das Modell selbst.
[QV: KI-Infrastruktur-Architektur — warum aus der Arbeitsweise des Modells eine Daten- und Integrationsarchitektur folgt]
Ein LLM berechnet Wahrscheinlichkeiten für Token-Sequenzen
Ein Large Language Model ist ein statistisches, neuronales Modell für die Verarbeitung und Generierung von Sequenzen. Bei autoregressiven Sprachmodellen besteht die grundlegende Aufgabe darin, auf Basis einer bereits vorhandenen Tokenfolge eine Wahrscheinlichkeitsverteilung für das nächste Token zu berechnen. Vereinfacht lässt sich dies schreiben als P(xₜ | x₁, x₂, …, xₜ₋₁).
Das Modell bestimmt also die Wahrscheinlichkeit eines Tokens xₜ unter der Bedingung der vorhergehenden Tokens. Bei der Textgenerierung wiederholt sich dieser Vorgang: Ein Token wird erzeugt, der bisherigen Sequenz hinzugefügt und anschließend das nächste Token berechnet. Aus diesem vergleichsweise einfachen Grundprinzip entstehen bei großen, entsprechend trainierten Modellen komplexe Fähigkeiten zur Verarbeitung und Erzeugung von Sprache, Code und – bei multimodalen Modellen – weiteren Datentypen.
KI, Machine Learning, generative KI und LLM bezeichnen nicht dasselbe
Die vier Begriffe werden im Sprachgebrauch häufig synonym verwendet, lassen sich aber hierarchisch einordnen. ISO/IEC 22989 stellt für diese Ebenen eine herstellerneutrale Terminologie bereit.
Künstliche Intelligenz ist der weit gefasste Oberbegriff für Computersysteme und Verfahren, die Aufgaben bearbeiten, die mit intelligentem Verhalten verbunden werden. Machine Learning bezeichnet innerhalb dieses Feldes Verfahren, bei denen Modelle anhand von Daten optimiert werden, statt das gewünschte Verhalten ausschließlich über explizit programmierte Regeln festzulegen. Generative KI wiederum bezeichnet Modelle und Systeme, die neue Inhalte erzeugen können, etwa Text, Bilder, Audio, Video oder Programmcode. Large Language Models schließlich sind eine Klasse großer Modelle mit Schwerpunkt auf der Verarbeitung und Generierung von Sprache; moderne Modelle können darüber hinaus multimodal ausgelegt sein. Ein LLM ist damit weder mit „KI" insgesamt noch mit einer vollständigen generativen KI-Anwendung gleichzusetzen.
Zwischen Eingabe und Antwort liegen mehrere Verarbeitungsstufen
Eine Benutzereingabe durchläuft bis zur erzeugten Antwort eine feste Kette von Schritten. Der Text wird zunächst tokenisiert, die Tokens werden in Embeddings überführt, diese durchlaufen die Transformer-Blöcke, am Ende entstehen Wahrscheinlichkeiten für die möglichen nächsten Tokens, aus denen eines ausgewählt wird. Anschließend beginnt der Vorgang für das folgende Token erneut. Diese Kette erklärt gleichzeitig mehrere zentrale Begriffe moderner LLM-Architekturen und zeigt, aus welchen Komponenten ein Modell besteht.
[BILD 1: Verarbeitungskette von der Texteingabe bis zum ausgewählten Token, mit Rückführung der Ausgabe in die Eingabe]
Der Tokenizer gehört zum Modell, nicht zum neuronalen Netz
Ein LLM verarbeitet einen Text nicht unmittelbar als Wörter oder Sätze. Ein Tokenizer zerlegt die Eingabe zunächst in Tokens und übersetzt sie in eine Sequenz numerischer Token-IDs. Ein Token kann je nach Tokenizer einem vollständigen Wort, einem Wortbestandteil, einem Satzzeichen oder einer anderen Zeichenfolge entsprechen.
Der Tokenizer gehört zum konkreten Modell, nicht zum neuronalen Netz selbst. Er wird gemeinsam mit dem Modell ausgeliefert und ist an dessen Vokabular gebunden. Deshalb entspricht eine bestimmte Anzahl Wörter nicht einer festen Anzahl Tokens, und dieselbe Eingabe ergibt bei unterschiedlichen Modellen unterschiedliche Tokenzahlen. Für Kosten und Kontextfenster ist das unmittelbar relevant, denn viele kommerzielle LLM-Dienste messen Ein- und Ausgabe anhand der verarbeiteten Tokenmenge.
Embeddings im Modell und Embeddings im RAG-System sind nicht dasselbe
Die Token-IDs allein besitzen noch keine für das neuronale Netz geeignete Repräsentation. Eine Embedding-Schicht ordnet Tokens deshalb Vektoren zu; das Modell verarbeitet damit numerische Repräsentationen in einem mehrdimensionalen Vektorraum. Zusätzlich benötigt der Transformer Informationen über die Position der Tokens innerhalb der Sequenz, deren konkrete Umsetzung sich zwischen Architekturen unterscheidet.
Wichtig ist an dieser Stelle die Abgrenzung zu RAG-Systemen, weil auch dort von Embeddings gesprochen wird. Die Funktion ist jedoch nicht identisch. Innerhalb eines LLM sind Token-Embeddings Bestandteil der Modellberechnung, während in einem RAG-System ein eigenes Embedding-Modell zum Einsatz kommt, das nicht mit dem antwortenden Sprachmodell identisch ist und Dokumentabschnitte sowie Suchanfragen als Vektoren für semantisches Retrieval abbildet.
[QV: KI-Infrastruktur-Architektur — Embeddings und Vektorsuche auf der Retrieval-Seite]
Die Parameterzahl allein sagt wenig über die Modellqualität
Den Hauptteil des neuronalen Netzes bilden wiederholte Transformer-Blöcke. Sie enthalten Attention-Mechanismen und Feed-Forward-Komponenten sowie weitere Elemente wie Normalisierung und Residual-Verbindungen, wobei die genaue Ausgestaltung zwischen Modellarchitekturen variiert.
Die beim Training gelernten Gewichte dieses Netzes werden als Parameter bezeichnet. Wenn von einem Modell mit mehreren Milliarden Parametern gesprochen wird, beschreibt dies die Anzahl dieser trainierten numerischen Werte. Als alleiniges Qualitätsmaß taugt die Zahl allerdings nicht, denn Architektur, Trainingsdaten, Trainingsverfahren, Datenqualität und Post-Training beeinflussen das resultierende Verhalten ebenso.
Inferenz bezeichnet die Ausführung, nicht nur die Generierungsschleife
Am Ende der Berechnung erzeugt das Modell Werte für die möglichen nächsten Tokens des Vokabulars. Nach der Umwandlung in eine Wahrscheinlichkeitsverteilung lässt sich daraus das nächste Token bestimmen.
Als Inferenz wird allgemein die Ausführung des trainierten Modells auf einer Eingabe bezeichnet, also der Durchlauf des Netzes ohne Anpassung der Parameter. Bei generativen Sprachmodellen besteht die Inferenz aus der wiederholten Ausführung dieses Durchlaufs, weil jedes erzeugte Token Teil der Eingabe für den nächsten Schritt wird. Genau diese Wiederholung erklärt, warum der Ressourcenbedarf generativer Modelle mit der Länge der Ausgabe steigt.
Attention löst das Problem der Bezüge innerhalb einer Sequenz
Die Grundlage der heute verbreiteten LLM-Architekturen ist der Transformer, vorgestellt 2017 in „Attention Is All You Need". Der entscheidende Ansatz bestand darin, Sequenzverarbeitung auf Attention-Mechanismen aufzubauen, ohne dafür die zuvor verbreitete rekurrente Verarbeitung zu benötigen.
Der Grund dafür lässt sich an einem Satz zeigen: „Der Server konnte die Datei nicht lesen, weil er keine Berechtigung hatte." Für die Interpretation von „er" sind andere Bestandteile des Satzes relevant; ein Token steht nicht isoliert. Self-Attention ermöglicht es dem Modell, für die Berechnung der Repräsentation eines Tokens Informationen anderer relevanter Positionen der Sequenz einzubeziehen.
Query, Key und Value bestimmen die Gewichtung
Technisch werden aus den Eingaberepräsentationen drei Vektoren gebildet: Query, Key und Value. Die ursprüngliche Transformer-Arbeit definiert Scaled Dot-Product Attention als Attention(Q,K,V) = softmax(QKᵀ / √dₖ)V. Die Query-Key-Beziehungen bestimmen dabei die Gewichtung, mit der die zugehörigen Value-Repräsentationen in das Ergebnis einfließen.
Bei Multi-Head Attention werden mehrere solcher Berechnungen parallel mit unterschiedlichen gelernten Projektionen durchgeführt. Dadurch kann das Modell verschiedene Beziehungen innerhalb einer Sequenz gleichzeitig repräsentieren.
[BILD 2: Self-Attention über eine Beispielsequenz, Gewichtung der Bezüge zwischen Tokens]
Das Kontextfenster ist nicht das Wissen des Modells
Das Context Window bestimmt, wie viele Tokens ein Modell innerhalb einer Verarbeitung berücksichtigen kann. Zum Kontext gehören je nach Anwendung Systemanweisungen, Benutzeranfragen und vorherige Teile einer Unterhaltung, dazu Dokumentauszüge aus einem RAG-System, Tool-Ergebnisse und weitere zur Laufzeit bereitgestellte Informationen.
Das Kontextfenster ist damit nicht mit dem Wissen des Modells gleichzusetzen. Ein Modell kann Informationen aus seinen trainierten Parametern verwenden und gleichzeitig zusätzliche Informationen im aktuellen Kontext verarbeiten. Die verfügbaren Kontextgrößen sind modellabhängig und ändern sich mit neuen Modellgenerationen, weshalb konkrete Grenzwerte immer anhand der Dokumentation des eingesetzten Modells zu prüfen sind.
Die Begrenzung des Kontextfensters ist zugleich der Ausgangspunkt für einen erheblichen Teil der Infrastruktur um das Modell herum, denn wenn nicht alles übergeben werden kann, muss ausgewählt werden.
[QV: KI-Infrastruktur-Architektur — warum aus der Begrenzung des Kontextfensters Chunking, Retrieval und Kontextzusammenstellung folgen]
Training verändert das Modell, RAG verändert es nicht
Die Entwicklung eines modernen LLMs kann mehrere Trainings- und Post-Training-Phasen umfassen. Für Unternehmensarchitekturen ist dabei vor allem eine Abgrenzung wichtig: Pre-Training und Fine-Tuning verändern die Modellparameter, Retrieval-Augmented Generation verändert sie nicht.
Pre-Training erzeugt das Basismodell
Beim Pre-Training verarbeitet das Modell sehr große Datenmengen und optimiert seine Parameter anhand eines Trainingsziels. Bei autoregressiven Sprachmodellen besteht ein wesentliches Trainingsziel darin, das nächste Token einer Sequenz vorherzusagen. Während dieses Vorgangs werden die Parameter des neuronalen Netzes iterativ angepasst; das Ergebnis ist zunächst ein Base Model.
Ein vortrainiertes Modell ist damit allerdings noch kein guter Dialogassistent. Durch Supervised Fine-Tuning lässt es sich anhand geeigneter Beispiele darauf optimieren, bestimmte Aufgaben oder Anweisungen besser zu bearbeiten. Fine-Tuning verändert dabei – anders als die bloße Bereitstellung zusätzlichen Kontexts – die Modellparameter.
Alignment ist mehr als RLHF
Zusätzliche Post-Training-Verfahren können das Verhalten des Modells stärker an gewünschte Eigenschaften oder menschliche Präferenzen anpassen. Ein historisch wichtiges Beispiel ist Reinforcement Learning from Human Feedback. Das 2022 veröffentlichte InstructGPT-Verfahren verlief in drei Schritten: Zunächst wurde das Modell anhand menschlicher Demonstrationen per Supervised Fine-Tuning angepasst. Anschließend bewerteten Menschen jeweils mehrere Modellantworten im Vergleich zueinander, und aus diesen Vergleichsdaten wurde ein separates Reward Model trainiert. Im dritten Schritt wurde das Sprachmodell mit Reinforcement Learning gegen dieses Reward Model weiter optimiert.
Der Zwischenschritt über das Reward Model ist der Grund, warum das Verfahren als Reinforcement Learning bezeichnet wird: Nicht die menschlichen Bewertungen selbst, sondern ein aus ihnen gelerntes Bewertungsmodell liefert das Optimierungssignal. RLHF ist jedoch nicht mit Alignment insgesamt gleichzusetzen, denn moderne Modellanbieter können unterschiedliche Post-Training- und Preference-Optimization-Verfahren verwenden.
RAG trainiert keine Unternehmensdaten in das Modell hinein
Bei Retrieval-Augmented Generation wird zunächst außerhalb des LLMs nach relevanten Informationen gesucht, und die gefundenen Inhalte werden in den Kontext der Modellanfrage aufgenommen. Während beim Training Trainingsdaten über einen Optimierungsvorgang zu veränderten Modellparametern führen, gehen bei RAG die gefundenen Inhalte in den Kontext eines unveränderten Modells ein. RAG ist deshalb kein Verfahren, mit dem Unternehmensdaten in ein LLM „hineintrainiert" werden.
Für die Betrachtung des Modells endet die Unterscheidung hier: Pre-Training und Fine-Tuning verändern das Artefakt, das betrieben wird, RAG verändert es nicht. Welche der drei Möglichkeiten sich eignet, um Unternehmenswissen tatsächlich verfügbar zu machen, und welche Anforderungen an Aktualität, Nachvollziehbarkeit und Berechtigungen daraus folgen, ist dagegen eine Architekturfrage.
[QV: KI-Infrastruktur-Architektur — Training, Feintuning und Kontext im Vergleich und warum im Unternehmensalltag der dritte Weg trägt]
Mixture of Experts bedeutet nicht größeres Modell, sondern selektive Aktivierung
Der Begriff Transformer beschreibt eine Architekturklasse, nicht ein einzelnes Modell. Für generative LLMs ist insbesondere die autoregressive, decoderbasierte Transformer-Architektur bedeutsam, daneben haben sich Varianten entwickelt, die das Grundprinzip verändern oder erweitern. Eine für die Infrastrukturplanung wichtige Unterscheidung betrifft Dense Models und Mixture-of-Experts-Modelle.
Dense Transformer durchlaufen alle Komponenten für jedes Token
Bei einem klassischen Dense Model werden die entsprechenden Modellkomponenten für jedes Token durchlaufen. Zu dieser Entwicklungslinie gehören zahlreiche GPT- und Llama-Generationen; Meta beschreibt etwa Llama 3 als autoregressives Sprachmodell auf Basis einer optimierten Transformer-Architektur.
Bei MoE weichen Gesamt- und aktivierte Parameter voneinander ab
Bei Mixture-of-Experts-Modellen enthalten bestimmte Modellbereiche mehrere spezialisierte Parametersätze, die sogenannten Experts. Ein Router entscheidet, welche Experts für ein Token aktiviert werden, wodurch Gesamtparameterzahl und die Zahl der pro Token tatsächlich aktivierten Parameter voneinander abweichen können.
Ein anschauliches dokumentiertes Beispiel ist Mistral AI Mixtral 8x7B. Dort besteht jede Schicht aus acht Feedforward-Blöcken, und für jedes Token wählt in jeder Schicht ein Router-Netzwerk zwei dieser acht Experts aus, wobei sich die Auswahl von Token zu Token unterscheiden kann. Das Ergebnis ist eine deutliche Differenz zwischen verfügbaren und genutzten Parametern: Jedes Token hat Zugriff auf 47 Milliarden Parameter, aktiviert bei der Inferenz jedoch nur 13 Milliarden davon.
Auch Meta verwendet inzwischen MoE-Architekturen. Llama 4 Scout und Maverick sind nach Herstellerangaben die ersten Llama-Modelle mit Mixture-of-Experts-Architektur; sie wurden am 5. April 2025 veröffentlicht. Maverick arbeitet mit 17 Milliarden aktiven von rund 400 Milliarden Gesamtparametern bei 128 Experts, Scout mit denselben 17 Milliarden aktiven Parametern bei rund 109 Milliarden Gesamtparametern und 16 Experts.
MoE bedeutet daher nicht einfach „größeres Modell", denn die wesentliche architektonische Eigenschaft besteht in der selektiven Aktivierung von Teilen des Modells. Für die Infrastrukturplanung ist die Unterscheidung unmittelbar relevant, weil der Speicherbedarf der Gesamtparameterzahl folgt, die Rechenlast pro Token dagegen der Zahl der aktivierten Parameter.
[BILD 3: Dense-Transformer gegenüber MoE-Schicht mit Router und selektiv aktivierten Experts]
Das Bereitstellungsmodell ist eine Eigenschaft der Modellfamilie, nicht des Anbieters
Anbieter unterscheiden sich nicht nur durch die Leistungsfähigkeit einzelner Modelle, sondern vor allem dadurch, wie ihre Modelle bereitgestellt und lizenziert werden. Eine verbreitete Vereinfachung ordnet dabei jedem Anbieter genau ein Bereitstellungsmodell zu: hier die Anbieter, die ausschließlich verwaltete Dienste betreiben, dort diejenigen, die Modellgewichte veröffentlichen. Diese Zuordnung trägt nicht mehr.
Die Trennlinie verläuft durch die Portfolios
OpenAI ist dafür das deutlichste Beispiel. Die GPT-Modelle werden weiterhin als verwaltete Modelle über APIs bereitgestellt. Daneben hat OpenAI im August 2025 mit gpt-oss-120b und gpt-oss-20b zwei Open-Weight-Modelle unter der Apache-2.0-Lizenz veröffentlicht, die ausdrücklich nicht über die OpenAI-API ausgeliefert werden, sondern auf selbst kontrollierter Infrastruktur oder bei Hosting-Anbietern laufen sollen.
Google verfolgt eine vergleichbare Zweiteilung. Die Gemini-Modellfamilie wird über die KI- und Cloud-Plattformen des Unternehmens angeboten, parallel dazu existiert mit Gemma eine Familie mit herunterladbaren Gewichten. Bemerkenswert ist hier die Lizenzentwicklung: Gemma 1 bis 3 standen unter den unternehmenseigenen Gemma Terms of Use, einer quellenoffenen, aber mit Nutzungseinschränkungen versehenen Lizenz. Gemma 4 erschien am 2. April 2026 unter Apache 2.0 und damit unter einer Standardlizenz ohne herstellerspezifische Zusatzbedingungen.
Meta veröffentlicht mit Llama Modellfamilien, bei denen für verschiedene Generationen Modellgewichte verfügbar sind. Die Llama Community License ist allerdings keine OSI-anerkannte Open-Source-Lizenz, sondern enthält Nutzungsbedingungen, die ab einer Schwelle von 700 Millionen monatlich aktiven Nutzern eine gesonderte Vereinbarung mit Meta erfordern. Für die meisten Unternehmen ist diese Schwelle praktisch irrelevant, für die juristische Prüfung ist sie es nicht.
Mistral AI kombiniert API-Angebote mit Modellen, deren Gewichte für weite Teile des Portfolios unter Apache 2.0 verfügbar sind. Mixtral bleibt zugleich das wichtigste dokumentierte Beispiel für den Einsatz einer Sparse-MoE-Architektur.
Alibaba stellt mit Qwen eine der am breitesten eingesetzten Open-Weight-Familien überhaupt bereit, in dichten wie in Mixture-of-Experts-Varianten und über Text hinaus auch multimodal. Weite Teile der Familie stehen unter Apache 2.0. Sie zeigt allerdings ebenso, dass sich Lizenzfragen nicht auf Anbieterebene beantworten lassen: Die Gewichte der Flaggschiff-Modellklasse erschienen im August 2026 unter einer eigenen, herstellerspezifischen Lizenz statt unter Apache 2.0.
DeepSeek veröffentlicht seine Modelle unter der MIT-Lizenz und damit unter der permissivsten der hier genannten Varianten. Die V4-Familie besteht aus zwei Mixture-of-Experts-Modellen: DeepSeek-V4-Pro mit 1,6 Billionen Gesamtparametern und 49 Milliarden aktivierten Parametern sowie DeepSeek-V4-Flash mit 284 Milliarden Gesamt- und 13 Milliarden aktivierten Parametern, beide mit einem Kontextfenster von einer MillionTokens. Die Familie erschien im April 2026 zunächst als Preview und ging im Sommer 2026 in reguläre Checkpoints über.
Von den hier betrachteten Anbietern bleibt damit allein Anthropic bei der ursprünglichen Zuordnung: Claude wird ausschließlich serviceorientiert bereitgestellt, Modellgewichte werden nicht veröffentlicht.
Verfügbare Gewichte und gehosteter Dienst sind zwei verschiedene Fragen
Gerade bei den Anbietern aus China zeigt sich, warum diese Unterscheidung mehr als eine begriffliche Feinheit ist. Die Berliner Beauftragte für Datenschutz und Informationsfreiheit hat die DeepSeek-App am 27. Juni 2025 nach Artikel 16 Digital Services Act gegenüber Apple und Google als rechtswidrigen Inhalt gemeldet. Grundlage war die Übermittlung personenbezogener Nutzerdaten nach China, für die mangels Angemessenheitsbeschluss der EU die Voraussetzungen nach Artikel 46 Absatz 1 DSGVO nicht als erfüllt angesehen wurden. Die Behörde hatte das Unternehmen zuvor im Mai 2025 erfolglos zur Abhilfe aufgefordert; ob und wie die beiden Plattformbetreiber abschließend entschieden haben, ist öffentlich nicht dokumentiert.
Diese Bewertung betrifft den gehosteten Dienst, nicht die veröffentlichten Modellgewichte. Wer dieselben Gewichte von einer Modellplattform lädt und auf eigener oder europäischer Infrastruktur betreibt, überträgt dabei keine Nutzerdaten an den Modellanbieter; der beanstandete Datenpfad existiert in dieser Konstellation nicht. Umgekehrt gilt dieselbe Trennung für westliche Anbieter, denn die Verfügbarkeit von Gewichten sagt nichts darüber aus, wie der parallel angebotene gehostete Dienst desselben Herstellers Daten verarbeitet.
Für Unternehmen sollte deshalb nicht nur die Frage gestellt werden, welches Modell leistungsfähiger ist. Mindestens ebenso wichtig ist, ob ein bestimmtes Modell in der geplanten Infrastruktur betrieben werden kann und darf, unter welcher Lizenz seine Gewichte stehen, und ob die Nutzung über den Dienst des Anbieters oder über eine selbst kontrollierte Bereitstellung erfolgen soll. Wir beantworten diese drei Fragen in Projekten für jede Modellfamilie getrennt und angesichts der Geschwindigkeit, mit der sich Lizenzen und Bereitstellungsformen ändern, für jede Modellgeneration erneut.
Eigenbetrieb verschiebt Verantwortung, er reduziert sie nicht
Aus der Bereitstellungsfrage entstehen architektonisch zwei grundlegend unterschiedliche Betriebsmodelle.
Beim verwalteten Dienst wird die Schnittstelle Teil des Datenpfades
Die Anwendung sendet ihre Anfrage über eine Schnittstelle an den Modellanbieter beziehungsweise dessen Plattform und erhält von dort die Antwort zurück. Der Betreiber der Anwendung muss die eigentliche Modellinfrastruktur damit nicht selbst bereitstellen, was den eigenen Aufwand für GPU-Infrastruktur, Modellbereitstellung und Skalierung reduziert.
Gleichzeitig wird die externe Schnittstelle Bestandteil des Daten- und Kontrollpfades. Daraus ergeben sich Fragen zu Datenübertragung, vertraglicher Datenverarbeitung, unterstützten Regionen, Servicegrenzen, Preisen, Rate Limits, Modellversionen und Verfügbarkeit. Diese Eigenschaften müssen für den konkreten Dienst geprüft werden und lassen sich nicht aus dem Begriff „Cloud-LLM" allein ableiten.
Beim Eigenbetrieb wird das Modell zur produktiven Infrastruktur
Bei verfügbaren Modellgewichten kann ein Unternehmen ein Modell auf eigener oder kontrollierter Infrastruktur betreiben. Die Anwendung spricht dann einen eigenen Inference Server an, der das Modell auf eigener Compute-Infrastruktur ausführt.
Damit übernimmt das Unternehmen allerdings zusätzliche Aufgaben. Dazu gehören die Bereitstellung geeigneter Compute-Ressourcen einschließlich Accelerator-Kapazität, das Modell-Deployment und die Auswahl der Inference-Software, dazu Skalierung, Monitoring, Updates, Kapazitätsplanung, Hochverfügbarkeit sowie Security und Lifecycle Management. Das Modell muss dann wie andere produktive Infrastruktur behandelt werden.
„On-Premises" bedeutet deshalb nicht automatisch „einfacher" oder „günstiger". Es verschiebt Verantwortlichkeiten vom Serviceprovider zum Betreiber.
[QUERVERWEIS: High-Performance Data Access – Anforderungen an Datenpfad und Durchsatz beim Eigenbetrieb von Inferenz-Infrastruktur]
Benchmarks beantworten die Betriebsfrage nicht
Die Modellentscheidung sollte nicht isoliert anhand von Benchmarks erfolgen. Mehrere Kriterien wirken unabhängig voneinander auf das Ergebnis und sind getrennt zu bewerten.
Datenhoheit endet nicht am Modell
Entscheidend ist, welche Daten den eigenen kontrollierten Bereich verlassen und unter welchen technischen und vertraglichen Bedingungen sie verarbeitet werden. Ein selbst betriebenes Modell kann Datenverarbeitung innerhalb einer kontrollierten Infrastruktur ermöglichen. Das beantwortet allerdings noch nicht automatisch Fragen nach Berechtigungen, Logging, Isolation oder Schutz der angebundenen Datenquellen.
[QUERVERWEIS: Data Intelligence und Governance – Klassifizierung, Berechtigungen und Nachvollziehbarkeit auf der Datenebene]
Welche Variante günstiger ist, entscheidet der Workload
Cloud-APIs und Eigenbetrieb besitzen unterschiedliche Kostenstrukturen. Bei einem API-Modell entstehen typischerweise nutzungsabhängige Kosten, beim Eigenbetrieb müssen dagegen Compute-Infrastruktur, Energie, Betrieb, Auslastung und Personal berücksichtigt werden. Welche Variante wirtschaftlicher ist, lässt sich daher nur anhand eines konkreten Workloads bestimmen.
Latenz entsteht an unterschiedlichen Stellen
Die wahrgenommene Antwortzeit setzt sich aus mehreren Komponenten zusammen. Bei einem externen Dienst kommen Netzwerkpfad und Serviceverarbeitung hinzu. Beim lokalen Modell entfällt dieser externe Pfad, dafür hängt die Inferenzgeschwindigkeit unmittelbar von eigener Hardware, Modellgröße, Quantisierung, Parallelisierung, Batch-Verhalten und Inference-Software ab.
Skalierung wird beim Eigenbetrieb zur Planungsaufgabe
Ein verwalteter Dienst abstrahiert einen großen Teil der darunterliegenden Modellinfrastruktur. Beim Eigenbetrieb muss Kapazität dagegen selbst geplant und bereitgestellt werden, und Lastspitzen können zusätzliche Accelerator-Ressourcen sowie geeignete Scheduling- und Serving-Mechanismen erfordern.
Aus der Parameterzahl folgt keine Hardwarekonfiguration
Der Ressourcenbedarf eines selbst betriebenen LLMs hängt von Modellarchitektur, Parameterzahl, numerischer Präzision beziehungsweise Quantisierung, Kontextlänge, gewünschtem Durchsatz und Parallelität ab. Bei Mixture-of-Experts-Modellen kommt hinzu, dass Speicherbedarf und Rechenlast unterschiedlichen Größen folgen: Die Gewichte aller Experts müssen vorgehalten werden, aktiviert wird pro Token jedoch nur ein Teil davon. Aus der Parameterzahl allein lässt sich deshalb keine vollständige Hardwarekonfiguration ableiten.
Modelle sind nicht ohne Weiteres austauschbar
Eine standardisierte Anwendungsschicht kann einen Modellwechsel erleichtern. Vollständig austauschbar sind Modelle jedoch nicht automatisch, denn Tokenizer, Kontextgrenzen, APIs, Tool Calling, multimodale Fähigkeiten, Ausgabeformate und modellspezifisches Verhalten können sich unterscheiden.
Das LLM verarbeitet Kontext, die Infrastruktur bestimmt ihn
Aus allem Bisherigen folgt eine Architekturgrenze, die sich in einem Satz fassen lässt: Das LLM verarbeitet Informationen, aber die umgebende Infrastruktur entscheidet, welche Informationen und Funktionen ihm überhaupt zur Verfügung stehen. Storage, Retrieval, Vektorindex, APIs und das Model Context Protocol liegen sämtlich außerhalb des Modells. Keine dieser Komponenten erweitert die trainierten Parameter; sie bestimmen ausschließlich, was im Kontextfenster ankommt und welche Aktionen die Anwendung auslösen darf.
Diese Grenze hat eine Folge, die sich durch die Modellwahl nicht auflösen lässt. Wenn benötigte Informationen nicht auffindbar sind, Berechtigungen nicht korrekt berücksichtigt werden, Daten veraltet sind oder relevante Systeme nicht angebunden wurden, kann die Modellschicht diese Defizite nicht beheben, und ein leistungsfähigeres Modell ändert daran nichts. Modellwahl und Dateninfrastruktur sind zwei getrennte Architekturentscheidungen.
Dieser Artikel behandelt bewusst die erste. Wie die Schichten unterhalb des Modells aufgebaut werden, welche Komponente welche Aufgabe übernimmt und welche davon zwingend erforderlich ist, entwickeln wir im Architekturbeitrag der Serie.
[QV: KI-Infrastruktur-Architektur — Zusammenspiel von Unternehmensdaten, Retrieval, Modell und Integrationsschicht]
[QV: AI-ready Data ist keine Storage-Eigenschaft — warum Datenqualität und Auffindbarkeit nicht aus der Speicherschicht folgen]
Fazit
Ein Large Language Model ist im Kern ein trainiertes neuronales Modell, das Token-Sequenzen verarbeitet und bei autoregressiver Generierung Wahrscheinlichkeiten für folgende Tokens berechnet. Tokenizer, Embeddings, Transformer-Blöcke, Attention, Modellparameter und Output-Schicht bilden die technische Grundlage der Verarbeitung. Pre-Training erzeugt das grundlegende Modell, Fine-Tuning und Alignment können sein Verhalten anschließend gezielt verändern.
Aus der Architektur folgen zugleich die Größen, die eine Infrastrukturplanung braucht. Bei Mixture-of-Experts-Modellen weichen Gesamtparameterzahl und pro Token aktivierte Parameter voneinander ab, weshalb Speicherbedarf und Rechenlast unterschiedlichen Größen folgen. Kontextlänge, Quantisierung, Durchsatz und Parallelität wirken unabhängig davon. Aus einer Parameterzahl allein lässt sich deshalb weder eine Hardwarekonfiguration noch eine Aussage über die Modellqualität ableiten.
Ob ein Modell als externer Dienst oder auf kontrollierter eigener Infrastruktur betrieben wird, ist ebenfalls keine reine Modellfrage. Es ist eine Entscheidung über Datenhoheit, Compute-Infrastruktur, Kostenmodell, Skalierung, Latenz und Betriebsverantwortung. Weil nahezu alle großen Anbieter inzwischen beide Wege parallel anbieten, lässt sie sich nicht durch die Wahl des Anbieters vorentscheiden, sondern ist für jede Modellfamilie und jede Generation erneut zu treffen.
Damit ist die Modellschicht beschrieben, nicht die KI-Infrastruktur. Welche Daten eine Anwendung benötigt, wo sie liegen und wie sie kontrolliert zum Modell gelangen, ist die zweite Hälfte der Aufgabe und Gegenstand des Architekturbeitrags dieser Serie.
Quellen
Vaswani, Ashish et al.: Attention Is All You Need. Advances in Neural Information Processing Systems 30, 2017. arXiv:1706.03762. Abschnitt 3.2.1 (Scaled Dot-Product Attention), Abschnitt 3.2.2 (Multi-Head Attention).
Ouyang, Long et al.: Training Language Models to Follow Instructions with Human Feedback. 2022. arXiv:2203.02155. Abschnitt 3 (Methods: SFT, Reward Modeling, Reinforcement Learning).
Jiang, Albert Q. et al. (Mistral AI): Mixtral of Experts. arXiv:2401.04088, eingereicht 8. Januar 2024. Abschnitt 2 (Architectural Details), Figure 1.
Meta AI: The Llama 4 Herd: The Beginning of a New Era of Natively Multimodal AI Innovation. Ankündigung vom 5. April 2025. https://ai.meta.com/blog/llama-4-multimodal-intelligence/ – Abruf 2. September 2026.
Meta AI: Llama 3 Model Card. Architekturbeschreibung als autoregressives Sprachmodell auf Basis einer optimierten Transformer-Architektur. Abruf 2. September 2026.
Meta AI: Llama 4 Community License Agreement. Nutzungsbedingungen einschließlich der Schwelle von 700 Millionen monatlich aktiven Nutzern. Abruf 2. September 2026.
OpenAI: Introducing gpt-oss. Veröffentlichung von gpt-oss-120b und gpt-oss-20b unter Apache 2.0, August 2025. https://openai.com/index/introducing-gpt-oss/ – Abruf 2. September 2026.
OpenAI: OpenAI Open-Weight Models (gpt-oss). Help-Center-Dokumentation zu Lizenz, Bereitstellung und Abgrenzung zur OpenAI-API. Abruf 2. September 2026.
Google AI for Developers: Gemma Terms of Use. Lizenzbedingungen für Gemma 1 bis 3 mit Verweis auf die separate Gemma-4-Lizenz. https://ai.google.dev/gemma/terms – Abruf 2. September 2026.
Google DeepMind: Gemma 4. Modellfamilie, veröffentlicht am 2. April 2026 unter Apache 2.0. Abruf 2. September 2026.
DeepSeek-AI: DeepSeek-V4-Pro Model Card. Hugging Face, MIT-Lizenz. Parameterzahlen für V4-Pro und V4-Flash, Kontextfenster. Abruf 2. September 2026.
Qwen Team, Alibaba Group: Qwen3.8 Model Cards und Repository. Lizenzangaben für dichte und MoE-Varianten. Abruf 2. September 2026.
Berliner Beauftragte für Datenschutz und Informationsfreiheit: Berliner Datenschutzbeauftragte meldet KI-App DeepSeek in Deutschland bei Apple und Google als rechtswidrigen Inhalt. Pressemitteilung vom 27. Juni 2025. https://www.datenschutz-berlin.de/pressemitteilung/berliner-datenschutzbeauftragte-meldet-ki-app-deepseek-in-deutschland-bei-apple-und-google-als-rechtswidrigen-inhalt/ – Abruf 2. September 2026.
ISO/IEC 22989: Information technology – Artificial intelligence – Artificial intelligence concepts and terminology. Herstellerneutrale Begriffsdefinitionen für KI, Machine Learning und verwandte Konzepte.
Google: Gemini API – Tokens, Context Window and Models. Technische Dokumentation. Abruf 2. September 2026.
OpenAI: OpenAI API – Models. Modelldokumentation. Abruf 2. September 2026.
Welche Entscheidung steht bei Ihnen an?
Sie möchten eine bestehende Infrastruktur bewerten, eine neue Architektur planen oder eine konkrete technische Fragestellung klären? Sprechen Sie mit uns über Ihre Anforderungen.
Spezialist für moderne Dateninfrastruktur
