Edelhack.de — Deutsch

Warum halluziniert ein LLM?

Mirco Blitz — Mon, 05 Oct 2026 00:00:00 GMT

Im vorigen Kapitel ging es darum, wie ein Sprachmodell die nächste Fortsetzung auswählt. Keiner dieser Regler prüft, ob eine Aussage stimmt. Ein LLM kann daher eine flüssige Antwort formulieren, die eine falsche Angabe enthält. Dafür hat sich das Wort Halluzination eingebürgert. In der Forschung meint es meist plausible, aber falsche Aussagen. Es bezeichnet einen Fehlertyp, keine Wahrnehmung des Modells. [1]

Was an dem Wort stört

Ein Mensch kann etwas halluzinieren, weil er etwas wahrnimmt, das nicht da ist. Ein LLM nimmt in diesem Sinn nichts wahr. Es erzeugt Text. Selbst die Forschungsarbeit Why Language Models Hallucinate weist ausdrücklich darauf hin, dass ihr Fachbegriff etwas grundlegend anderes bezeichnet als menschliche Wahrnehmung. [1]

Das Wort kann einen Fehler wie eine merkwürdige Eigenart klingen lassen. Für jemanden, der eine Antwort als verlässliche Auskunft verwendet, ist aber entscheidend, welche Behauptung falsch oder nicht belegt ist und welche Folgen das hat. „Halluzination“ ist als Fachwort gebräuchlich. Es ersetzt weder die Benennung des konkreten Fehlers noch die Prüfung der Aussage. Und nicht jeder Modellfehler ist eine Halluzination. Eine missachtete Formatvorgabe oder ein abgebrochener Satz ist etwas anderes als eine überzeugend vorgetragene falsche Tatsache. [1]

Wie eine falsche Angabe entsteht

Beim Training lernt ein LLM, wie Texte üblicherweise weitergehen. Es lernt nicht zu jeder Aussage zuverlässig dazu, ob sie stimmt. Fragt man nach einem kaum bekannten Geburtsdatum, kann es deshalb ein genaues Datum schreiben, ohne dafür eine verlässliche Grundlage zu haben. Auch wenn immer die wahrscheinlichste Fortsetzung gewählt wird, kann die Antwort falsch sein. [1] [2]

Zusätzliches Training kann solche Fehler verringern. Doch auch Tests beeinflussen, welche Antworten belohnt werden. Bringt „Ich weiß es nicht“ genauso wenig Punkte wie eine falsche Antwort, kann Raten die Punktzahl verbessern. Das Modell blufft dabei nicht bewusst. Es wird für eine Art Antwort belohnt, die plausibel klingt und trotzdem falsch sein kann. [1] [2]

Was bedeutet eine „Halluzinationsrate“?

Eine falsche Aussage ist ein Fehler. Eine Fehlerrate sagt, wie viele Fälle unter den untersuchten Fällen falsch waren. Eine bloße Angabe wie „40 Prozent Halluzinationen“ sagt noch nicht, ob tatsächlich 40 von 100 Antworten falsch waren. Dafür muss klar sein, was gezählt wurde.

Artificial Analysis stellte 2025 bei einem Wissenstest 6.000 schwierige Fragen. In der damaligen Grafik steht für GPT-5.1 (high) eine „Hallucination Rate“ von 51 Prozent. Für diese Zahl werden die richtig beantworteten Fragen zuerst beiseitegelegt. Von den übrigen Fällen – falsch beantwortet, nur teilweise beantwortet oder gar nicht beantwortet – waren 51 Prozent falsch. Es sind nicht 51 Prozent aller Fragen und auch keine allgemeine Fehlerrate von ChatGPT im Alltag. [3] [4]

Das macht die falschen Antworten nicht harmlos. Für verlässliche Auskünfte zählt, wie oft eine falsche Aussage vorkommt und was sie anrichten kann. Eine Zahl hilft nur, wenn die Aufgabe und die Zählweise bekannt sind.

Was das für die Arbeit bedeutet

Wer sich mit einem LLM in ein neues Thema einarbeitet, kann eine falsche Erklärung besonders leicht übernehmen. Je weniger man selbst über das Thema weiß, desto schwerer lässt sich erkennen, ob die Antwort in die falsche Richtung führt. Für Wissensfragen ist ein LLM deshalb als alleinige Quelle nur bedingt geeignet. Seine Antworten können neue Fragen aufwerfen; wichtige Angaben sollten anhand unabhängiger Quellen überprüft werden.

Ein LLM eignet sich eher für Aufgaben, deren Ergebnis sich prüfen lässt. Eine kleine Codeänderung lässt sich zum Beispiel ausführen und testen; eine konkrete Rechnung lässt sich nachrechnen. Auch das garantiert keine vollständige Prüfung. Komplexer Code und mathematische Beweise können schwer zu beurteilen sein. Je weniger sich eine Aussage eindeutig überprüfen lässt, desto vorsichtiger sollte man mit ihr umgehen. Eine überzeugende Formulierung ist noch kein Beleg.

Auch das Kontextfenster spielt bei der Aufgabenplanung eine Rolle. Bei größeren, weit gefüllten Kontextfenstern fallen in der Praxis häufiger plausible falsche Aussagen und ein Abdriften von der eigentlichen Aufgabe auf. Überholte Ansätze, lange Ausgaben und Widersprüche können wichtige Angaben verdecken. Das ist eine persönliche Beobachtung, keine allgemein gemessene Fehlerrate oder feste Grenze. Daher hilft es, die Aufgabe rechtzeitig mit aktuellen Anforderungen und relevanten Quellen neu auszurichten – etwa durch eine sorgfältige Zusammenfassung oder eine neue Sitzung mit gezielter Übergabe. [5]

Im nächsten Kapitel

Wichtige Aussagen brauchen Belege. Wie findet Software passende Textstellen zu einer Frage und gibt sie einem LLM mit? Im nächsten Kapitel geht es um Embeddings und RAG – und darum, was zusätzliche Quellen leisten können und was weiterhin geprüft werden muss.

Deeper into the Rabbit Hole

Video auf Englisch

IBM Technology — Why Large Language Models Hallucinate — Martin Keen erklärt in knapp zehn Minuten anhand von Beispielen, wie unzuverlässige Antworten aussehen und welche Gegenmaßnahmen helfen können. Das vollständige englische Transkript wurde gelesen, nicht das vollständige Video angesehen. Der Beitrag verwendet „Halluzination“ weiter als dieses Kapitel und zählt auch Widersprüche zum Prompt oder innerhalb einer Antwort dazu. Seine Tipps zu Temperature und Prompts sind keine Wahrheitsgarantie.

Quellen

Kalai et al. — Why Language Models Hallucinate, Preprint vom September 2025. Abstract und Einleitung sowie die Abschnitte zu Vortraining und Bewertung wurden gelesen. Die Autoren grenzen den Fachbegriff ausdrücklich von menschlicher Wahrnehmung ab.
OpenAI — Why language models hallucinate, 5. September 2025. Forschungserklärung zu falschen Faktenangaben, Vortraining und Anreizen durch Genauigkeitsbewertungen; sie ist keine unabhängige Messung aller Anwendungen.
Artificial Analysis — AA-Omniscience: Knowledge and Hallucination Benchmark, 16. November 2025. Historische Auswertung und Grafik mit GPT-5.1 (high). Die Erläuterung im Artikel vereinfacht den Nenner.
Artificial Analysis — AA-Omniscience evaluation. Methodenseite mit der genaueren Definition „incorrect / (incorrect + partial answers + not attempted)“. Das aktuelle Dashboard zeigt nicht zwingend denselben Modellausschnitt wie die historische Grafik.
Anthropic — Effective context engineering for AI agents. Praxisbeitrag zur Auswahl relevanter Informationen in langen Verläufen; keine allgemeine Messung der Halluzinationsrate nach Kontextlänge.

Was ist ein Kontextfenster?

Mirco Blitz — Fri, 02 Oct 2026 00:00:00 GMT

Wie wir in „Wie funktioniert ein LLM?“ gesehen haben, ist jede Anfrage an ein Sprachmodell zunächst ein abgeschlossener Vorgang. Warum wirkt ein Chat dann so, als würde sich die Maschine an unser Gespräch erinnern? Weil die Software bei einer neuen Anfrage auch bisherige Nachrichten mitgibt. Wie viel davon das Modell auf einmal verarbeiten kann, begrenzt das Kontextfenster. Seine Größe wird in Tokens angegeben. [1]

Die Größe des verfügbaren Kontextfensters hängt vom Modell und den Servereinstellungen ab. Manche Modelle können etwa 8.000 Tokens auf einmal verarbeiten, andere eine Million oder mehr. Der Server kann die nutzbare Größe zusätzlich begrenzen. Im Folgenden zeigen wir anhand von Bildern, wie ein Kontextfenster aufgebaut ist und sich während eines Gesprächs füllt. [1] [2]

1. Die erste Anfrage

Am Anfang enthält der Kontext den Systemprompt mit den grundlegenden Anweisungen und deine erste Nachricht. Eine Antwort des LLM gibt es noch nicht. Auch diese erste Anfrage belegt also bereits einen Teil des Fensters. [1]

Bildinhalt als Text

Das Kontextfenster beginnt links mit dem blauen Systemprompt und der goldgelben ersten Anfrage. Eine Modellantwort ist noch nicht vorhanden. Der restliche Balken zeigt freien Kontext. Die zeitliche Reihenfolge läuft von links nach rechts. Die Breiten sind schematisch und keine realen Tokenmessungen.

2. Der Verlauf wächst

Mit der Antwort kommt weiterer Text hinzu. Bei der nächsten Anfrage gibt die Software den bisherigen Verlauf zusammen mit deiner neuen Nachricht mit. Nutzt das LLM Tools, kommen auch die Tool-Aufrufe und ihre Ausgaben dazu. So wächst der Kontext über mehrere Gesprächsrunden hinweg. Dieses erneute Mitgeben des Verlaufs ist kein dauerhaftes Gedächtnis des Modells. [1]

Bildinhalt als Text

Nach dem blauen Systemprompt folgen eine goldgelbe Anfrage und eine grüne Antwort. Eine zweite Anfrage führt zu einem grünen Tool-Aufruf des Modells, dann zu einer größeren orangefarbenen Tool-Ausgabe und schließlich zu einer grünen Antwort. Der Tool-Aufruf ist Modellausgabe, nicht Tool-Ausgabe. Freier Kontext bleibt rechts. Alle Breiten sind schematisch, keine Tokenmessungen.

3. Was davon ist noch relevant?

Im Verlauf bleiben auch verworfene Ansätze, überholte Zwischenstände und längst erledigte Rückfragen stehen. Sie belegen Platz neben den Informationen, die für die aktuelle Aufgabe wichtig sind. Bei langen oder widersprüchlichen Verläufen kann das LLM relevante Details übergehen oder vorhandene Anweisungen schlechter befolgen. Das passiert nicht zwangsläufig in jedem langen Chat und hängt nicht allein von der Zahl der Tokens ab. [3]

Bildinhalt als Text

Das Kontextfenster enthält weiterhin den blauen Systemprompt, zwei Gesprächsrunden mit einem Tool-Aufruf und einer größeren Tool-Ausgabe sowie eine weitere Anfrage. Die erste grüne Antwort ist mit einer weißen gestrichelten Innenkontur als überholter Zwischenstand markiert. Neuere Informationen können frühere Zwischenstände überholen. Die alten Inhalte bleiben vorhanden. Die Markierung steht weder für echtes Löschen noch für eine automatische allgemeine Drift. Die Breiten sind schematisch, keine Tokenmessungen.

4. Das Fenster wird voll

Der Kontext darf nicht den gesamten verfügbaren Platz beanspruchen, wenn noch eine Antwort entstehen soll. Auch deren Tokens brauchen Platz. Wie viel dafür vorgesehen ist und wie lang eine Antwort höchstens werden darf, hängt vom Modell und der Software ab. Die Chatsoftware oder das Harness kann außerdem schon vor der Modellgrenze ein eigenes Limit setzen. Was dann mit dem Verlauf geschieht, bestimmt die jeweilige Software. [1] [2]

Bildinhalt als Text

Links stehen der blaue Systemprompt und der bisherige Gesprächsverlauf einschließlich der letzten Anfrage. Diese bereits vorhandenen Inhalte sind der Input. Rechts zeigt ein dezent getönter Block mit gestrichelter weißer Kontur Platz für die nächste, noch zu erzeugende Antwort. Dieser Block ist keine bereits vorhandene Modellausgabe und keine reale Größenprognose. Die schematische Darstellung zeigt, dass auch die Antwort in das begrenzte Kontextfenster passen muss. Es gibt keine festen Tokenwerte.

5. Die Dumb Zone

So nenne ich den Bereich, in dem der Kontext für meine Aufgabe bereits so verworren ist, dass die Antworten unschärfer oder unbrauchbar werden. Wo das beginnt, hängt von der Aufgabe, dem Inhalt und dem Server ab. Nach meiner Erfahrung ist dieser Bereich spätestens bei etwa 70 bis 80 Prozent des verfügbaren Kontextfensters erreicht. Bei größeren Kontextfenstern beobachte ich den Beginn oft schon bei 50 Prozent. Das sind Erfahrungswerte, keine festen technischen Grenzen. Bevor ich diese Grenze erreiche, möchte ich den Kontext verkleinern. Das geht zum Beispiel mit einer Compaction oder einem Session Handoff.

Bildinhalt als Text

Der blaue Systemprompt wird von zwei goldgelben Anfragen, grünen Antworten, einem grünen Tool-Aufruf und einer orangefarbenen Tool-Ausgabe gefolgt. Rechts bleibt freier Kontext. Eine rote Schraffur überlagert dessen rechten Bereich und markiert die Dumb Zone. Ihr schematischer Beginn ist eine persönliche Orientierung, keine universelle Schwelle und keine technische Grenze. Die tatsächliche Nutzbarkeit hängt unter anderem von Aufgabe und Kontextmix ab. Die Schraffur steht nicht für fest reservierten Speicher und behauptet keine automatische Verschlechterung. Breiten sind schematisch, keine realen Tokenmessungen.

6. Compaction

Bei einer Compaction fordert dein Harness oder deine Chatsoftware das LLM auf, die bisherige Session zusammenzufassen. Die Software ersetzt anschließend den alten Verlauf im Kontext durch diese Zusammenfassung. So entsteht wieder Platz, und das Gespräch wird mit dem verdichteten Kontext fortgesetzt. Manche Harnesses ermöglichen es, die Compaction mit eigenen Prompts zu steuern. Was vom bisherigen Arbeitsstand erhalten bleibt, hängt von der Qualität der Zusammenfassung ab. [3] [4]

Das Bild zeigt das Grundprinzip. Je nach Harness können neben der Zusammenfassung auch jüngere Nachrichten erhalten bleiben. [4]

Bildinhalt als Text

Ein Kontextbalken zeigt dieselbe Session nach Compaction. Der blaue Systemprompt bleibt erhalten. Eine kompakte violette Zusammenfassung ersetzt den alten Gesprächsverlauf, sodass deutlich mehr freier Kontext entsteht. Es wird keine neue Session gestartet. Die rote Dumb-Zone-Schraffur bleibt im rechten Teil des freien Kontexts sichtbar. Ihr schematischer Beginn ist eine persönliche Orientierung, keine technische Grenze oder Speicherreservierung. Alle Breiten sind schematisch, keine Tokenmessungen.

7. Session Handoff

Bei einem Session Handoff erstellt das LLM eine Übergabe für eine neue Session. Darin stehen das aktuelle Ziel, der Arbeitsstand, wichtige Entscheidungen und die nächsten Schritte. Die neue Session beginnt mit dieser Übergabe statt mit dem bisherigen Gesprächsverlauf. Der Schwerpunkt liegt damit weniger darauf, das Gespräch zusammenzufassen, als darauf, die Arbeit fortsetzen zu können. Auch hier hängt das Ergebnis davon ab, welche Informationen übernommen werden und wie zuverlässig die Übergabe sie beschreibt. [5]

Ein praktisches Beispiel ist mein Projekt pi-blitz-handoff zum Organisieren von Handoffs zwischen Pi-Sessions. In der Sammlung Pi.dev-Toolbelt stelle ich es in einem eigenen Beitrag vor.

Bildinhalt als Text

Zwei gleich breite Kontextbalken zeigen zwei getrennte Sessions. Oben enthält Session 1 den blauen Systemprompt und den alten Verlauf mit Anfragen, Antworten, einem Tool-Aufruf und einer Tool-Ausgabe. Der Verbindungspfeil bezeichnet das Zusammenfassen zur Übergabe. Unten beginnt Session 2 ausschließlich mit einem blauen Systemprompt und einem gedeckt türkisfarbenen Session Handoff. Danach folgt freier Kontext. Es gibt unten weder eine neue User-Anfrage noch eine LLM-Antwort. Die Übergabe überträgt die zusammengefassten Informationen, nicht den gesamten alten Verlauf. Beide Balken tragen im rechten Teil des freien Kontexts die rote Dumb-Zone-Schraffur. Ihr schematischer Beginn variiert zwischen den Sessions. Diese persönliche Orientierung ist keine technische Grenze oder Speicherreservierung. Die Breiten sind schematisch, keine Tokenmessungen.

Compaction vs. Handoff — ein Flamewar

Aus diesen beiden Ansätzen muss kein Lagerstreit werden. Compaction verdichtet den Verlauf, um das laufende Gespräch fortzusetzen. Ein Handoff richtet den Kontext einer neuen Session auf die weitere Arbeit aus. Welcher Weg passt, hängt davon ab, was du erhalten möchtest und wie die Software damit umgeht. Beide können wichtige Details verlieren. Keiner ist für jede Aufgabe überlegen.

Im nächsten Kapitel

Bisher ging es darum, welche Informationen dem Modell für eine Antwort zur Verfügung stehen. Wie aus den möglichen nächsten Tokens eine konkrete Ausgabe wird, ist eine andere Frage. Darum geht es in Kapitel 08 „Ist dem LLM kalt? Temperature und andere Regler für die Textausgabe“.

Nächster Artikel →

Deeper into the Rabbit Hole

Videos auf Englisch

IBM Technology — What is a Context Window? Unlocking LLM Secrets — Martin Keen erklärt Tokens, Self-Attention und die Herausforderungen begrenzter Kontextfenster. Rund 12 Minuten.
Matt Pocock — Most devs don’t understand how context windows work — Kontextgrenzen im Alltag mit Coding-Agenten, das „Lost in the Middle“-Problem und der Umgang mit langen Verläufen. Rund 10 Minuten, mit Beispielen zu Compaction und zusätzlichem Kontext durch MCP-Server.
Marina Wyss — Context Engineering in 29 Minutes: Complete Course — ein längerer Überblick über Kontextstrategien für Agenten, typische Fehler und praktische Vorgehensweisen. Rund 29 Minuten. Das Video wird von Kimi gesponsert.

Texte

Anthropic — Context windows — wie Nachrichten, Tool-Ergebnisse und erzeugte Antworten zum Fenster beitragen. Die Details beschreiben Claude, nicht jedes Modell.
Anthropic — Effective context engineering for AI agents — Auswahl hilfreichen Kontexts, Compaction, externe Notizen und Subagents. Ein Praxisbeitrag eines Anbieters.
Liu et al. — Lost in the Middle — eine Untersuchung zum Wiederfinden von Informationen in langen Eingaben. Der Abstract beschreibt den Einfluss ihrer Position. Daraus folgt keine allgemeine 70-Prozent-Grenze. [6]

Quellen

Anthropic — Context windows.
vLLM — Engine Arguments. Beispiel für die Serverkonfiguration.
Anthropic — Effective context engineering for AI agents.
Anthropic — Compaction overview.
Mirco Blitz — pi-blitz-handoff — README v1.2.4. Veröffentlichter Produktstand v1.2.4.
Liu et al. — Lost in the Middle: How Language Models Use Long Contexts. Abstract gelesen, der Volltext wurde für diesen Beitrag nicht ausgewertet.

Ist dem LLM kalt? Temperature und andere Regler für die Textausgabe

Mirco Blitz — Fri, 02 Oct 2026 00:00:00 GMT

Wie wir in „Wie funktioniert ein LLM?“ gezeigt haben, entsteht eine Antwort Token für Token. Welches Textstück als Nächstes angehängt wird, können wir uns als gewichteten Würfelwurf vorstellen. Wahrscheinliche Fortsetzungen bekommen mehr Würfelzahlen zugeteilt als unwahrscheinliche. Die Einstellung Temperature, auf Deutsch Temperatur, verändert diese Gewichtung. Sie bestimmt damit, wie stark die Favoriten beim Würfeln bevorzugt werden. [1]

Wie in Artikel 01 behandeln wir Tokens im Beispiel vereinfacht als ganze Wörter. Tatsächlich können sie auch Wortteile oder Satzzeichen sein. Unser W20 steht für die zufällige Auswahl aus den berechneten Wahrscheinlichkeiten, nicht für einen echten Würfel im Computer.

Temperature verändert die Gewichtung

Wir beginnen wieder mit „Meine Katze hat“. In unserem erfundenen Beispiel ist „Hunger“ die wahrscheinlichste Fortsetzung. Bei niedriger Temperature wird dieser Favorit stärker bevorzugt. Er erhält einen größeren Zahlenbereich auf unserem W20. Weniger wahrscheinliche Fortsetzungen bekommen kleinere Bereiche.

Bei höherer Temperature werden die Unterschiede kleiner. Schwächere Kandidaten erhalten mehr Chancen, der Favorit bleibt aber der Favorit. Temperature kehrt die Rangfolge nicht um. Ein seltener ausgewähltes Wort ist deshalb weder automatisch besser noch besonders kreativ. [1]

Das Bild vergleicht Temperature 0,5, 1 und 2. Bei 1 bleibt die ursprüngliche Gewichtung unverändert. Das bedeutet nicht, dass 1 in jeder Software die Standardeinstellung ist. Wir verwenden überall denselben Wurf 9, damit die veränderten Zahlenbereiche sichtbar werden. [2]

Bildinhalt als Text

Alle drei Spalten beginnen mit „Meine Katze hat“. Die Fortsetzungen lauten in gleicher Reihenfolge „Hunger“, „eine“, „heute“, „mich“, „wieder“ und weitere Möglichkeiten.

Temperature 0,5. Die Bereiche sind 1 bis 10, 11 bis 14, 15 bis 16, 17 bis 18, 19 und 20. Der Wurf 9 wählt „Hunger“.
Temperature 1. Die Bereiche sind 1 bis 6, 7 bis 10, 11 bis 13, 14 bis 16, 17 bis 18 und 19 bis 20. Der Wurf 9 wählt „eine“.
Temperature 2. Die Bereiche sind 1 bis 4, 5 bis 8, 9 bis 11, 12 bis 14, 15 bis 16 und 17 bis 20. Der Wurf 9 wählt „heute“.

Die Ausgangswahrscheinlichkeiten sind erfunden. Sie betragen 30, 20, 15, 15 und 10 Prozent für die fünf genannten Wörter sowie jeweils 5 Prozent für zwei weitere Kandidaten. Temperature wird auf die einzelnen Kandidaten angewandt. Erst danach werden die beiden weiteren Kandidaten zusammengefasst. Die Zahlenbereiche sind auf 20 Würfelzahlen gerundet. Die Werte sind keine Modellmessungen.

Die Würfelgewichtung meint hier die Chancen bei der Auswahl, nicht die beim Training gespeicherten Modellgewichte. Temperature ist kein Regler für Intelligenz oder Wahrheit. Bei Temperature 0 verwenden viele Anwendungen statt eines zufälligen Wurfs die wahrscheinlichste Fortsetzung. Das garantiert nicht in jeder Umgebung identische vollständige Antworten. [2]

Top-p begrenzt die Auswahl

Während Temperature die Gewichtung verändert, bestimmt Top-p, welche Fortsetzungen überhaupt berücksichtigt werden. Dazu werden die Kandidaten nach ihrer Wahrscheinlichkeit geordnet. Beginnend mit dem Favoriten werden so viele aufgenommen, bis ihre gemeinsame Wahrscheinlichkeit mindestens den eingestellten Wert erreicht. [3]

Bei Top-p = 0,8 sind das in unserem Beispiel „Hunger“ mit 30 Prozent, „eine“ mit 20 Prozent sowie „heute“ und „mich“ mit jeweils 15 Prozent. Zusammen erreichen sie 80 Prozent. „Wieder“ und die weiteren Möglichkeiten bleiben bei diesem Schritt außerhalb der Auswahl.

Die verbliebenen Chancen werden auf zusammen 100 Prozent umgerechnet. Sie werden nicht gleich groß. „Hunger“ bleibt wahrscheinlicher als „eine“. Top-p = 0,8 bedeutet also nicht, dass 80 Prozent aller Tokens übrig bleiben. Je nach Verteilung können wenige oder viele Kandidaten nötig sein, um die Grenze zu erreichen. Bei Top-p = 1 entfällt diese Begrenzung. [2] [3]

Bildinhalt als Text

Beide Spalten beginnen mit „Meine Katze hat“ bei Temperature 1. Die erfundenen Ausgangschancen sind „Hunger“ 30 Prozent, „eine“ 20 Prozent, „heute“ 15 Prozent, „mich“ 15 Prozent, „wieder“ 10 Prozent und weitere Möglichkeiten zusammen 10 Prozent.

Top-p 1 lässt alle Kandidaten in der Auswahl. Die Bereiche lauten 1 bis 6 für „Hunger“, 7 bis 10 für „eine“, 11 bis 13 für „heute“, 14 bis 16 für „mich“, 17 bis 18 für „wieder“ und 19 bis 20 für weitere Möglichkeiten.
Top-p 0,8 erreicht nach „mich“ die Grenze von 80 Prozent. „Wieder“ und weitere Möglichkeiten sind durchgestrichen. Nach dem Umrechnen auf 100 Prozent lauten die gerundeten Bereiche 1 bis 8 für „Hunger“, 9 bis 13 für „eine“, 14 bis 17 für „heute“ und 18 bis 20 für „mich“.

Beide Würfel zeigen 9 und wählen „eine“. Ein veränderter Filter muss bei einem einzelnen Wurf nicht zu einem anderen Ergebnis führen. Alle Beispiele sind erfunden und auf 20 Zahlen gerundet.

Top-k begrenzt die Anzahl

Top-k bestimmt, wie viele der wahrscheinlichsten Fortsetzungen zur Auswahl stehen. Bei Top-k = 2 bleiben in unserem Beispiel nur „Hunger“ und „eine“ übrig. Anders als Top-p setzt Top-k also eine feste Anzahl statt einer Wahrscheinlichkeitsgrenze. [2]

Die übrigen Fortsetzungen werden ausgeschlossen. Die Chancen der beiden Favoriten werden auf zusammen 100 Prozent umgerechnet, bleiben aber unterschiedlich groß. Auf unserem W20 erhält „Hunger“ dadurch zwölf Zahlen und „eine“ acht.

Bildinhalt als Text

Ohne Top-k bleiben alle Kandidaten. Die Bereiche sind 1 bis 6 für „Hunger“, 7 bis 10 für „eine“, 11 bis 13 für „heute“, 14 bis 16 für „mich“, 17 bis 18 für „wieder“ und 19 bis 20 für weitere Möglichkeiten.
Top-k 2 behält nur „Hunger“ und „eine“. Die vier übrigen Zeilen sind durchgestrichen. Die Chancen werden von zusammen 50 Prozent auf 100 Prozent umgerechnet. „Hunger“ erhält 60 Prozent und die Zahlen 1 bis 12, „eine“ 40 Prozent und die Zahlen 13 bis 20.

Beide Würfel zeigen 9. Ohne Filter wird „eine“ ausgewählt, mit Top-k 2 „Hunger“. Das Bild zeigt ein erfundenes Beispiel, keine Modellmesswerte.

Min-p vergleicht mit dem Favoriten

Min-p bestimmt, wie wahrscheinlich eine Fortsetzung im Vergleich zum Favoriten mindestens sein muss. Bei Min-p = 0,5 muss sie mindestens halb so wahrscheinlich sein. Hat „Hunger“ eine Chance von 30 Prozent, bleiben alle Fortsetzungen mit mindestens 15 Prozent übrig. [2]

Schwächere Kandidaten werden ausgeschlossen. Die verbleibenden Chancen werden wieder auf zusammen 100 Prozent umgerechnet. Anders als Top-k legt Min-p keine feste Anzahl fest. Seine Grenze richtet sich bei jedem Schritt nach der Wahrscheinlichkeit des aktuellen Favoriten.

Bildinhalt als Text

Ohne Min-p bleiben alle Kandidaten. Die Bereiche sind 1 bis 6 für „Hunger“, 7 bis 10 für „eine“, 11 bis 13 für „heute“, 14 bis 16 für „mich“, 17 bis 18 für „wieder“ und 19 bis 20 für weitere Möglichkeiten.
Bei Min-p 0,5 ist „Hunger“ mit 30 Prozent als Favorit markiert. Die Hälfte davon ergibt die Mindestchance von 15 Prozent. „Hunger“, „eine“, „heute“ und „mich“ bleiben. „Wieder“ und weitere Möglichkeiten liegen darunter und sind durchgestrichen.
Die Chancen der verbliebenen Kandidaten werden auf 100 Prozent umgerechnet. Die gerundeten Bereiche sind 1 bis 8 für „Hunger“, 9 bis 13 für „eine“, 14 bis 17 für „heute“ und 18 bis 20 für „mich“.

Beide Würfel zeigen 9 und wählen „eine“. Min-p und Top-p lassen in diesem Beispiel dieselben Kandidaten übrig, setzen aber unterschiedliche Grenzen. Alle Werte sind erfunden und auf 20 Würfelzahlen gerundet.

Zwei Einstellungen, unterschiedliche Aufgaben

Temperature verändert, wie stark die wahrscheinlichsten Fortsetzungen bevorzugt werden. Top-p begrenzt, welche Fortsetzungen überhaupt an der Auswahl teilnehmen. Werden beide zusammen verwendet, wird zuerst die Gewichtung durch Temperature verändert. Anschließend zieht Top-p seine Grenze. [1] [3]

In unserem Würfelbild verändert Temperature also die Zahlenbereiche. Top-p streicht danach die Fortsetzungen außerhalb seiner Grenze und verteilt die Würfelzahlen auf die verbliebenen Möglichkeiten neu. Bei gleichem Top-p können deshalb je nach Temperature unterschiedlich viele Fortsetzungen übrig bleiben.

Universell beste Werte gibt es nicht. Welche Einstellung brauchbare Ergebnisse liefert, hängt vom Modell und der Aufgabe ab. Zum Ausprobieren hilft es, zunächst nur eine Einstellung zu verändern. So lässt sich leichter erkennen, was sie bewirkt. Welche Regler verfügbar sind und wie mehrere Filter kombiniert werden, hängt von der verwendeten Software ab.

Im nächsten Kapitel

Beide Einstellungen beeinflussen die Auswahl, prüfen aber keine Fakten. Auch eine sehr wahrscheinliche Fortsetzung kann falsch sein. Warum LLMs solche Aussagen erzeugen und dabei überzeugend klingen können, schauen wir uns im nächsten Artikel „Warum halluziniert ein LLM?“ an.

Deeper into the Rabbit Hole

Videos auf Englisch

3Blue1Brown — Transformers, the tech behind LLMs — eine visuelle Vertiefung zu den Grundlagen der Tokenauswahl und Temperature. Für diesen Artikel wurde die entsprechende Textfassung gelesen.
Gary Explains — The Secret Controls for your LLM: Temperature, Top-K, Top-P, etc — rund 15 Minuten über Temperature, Top-p und weitere Auswahlregler. Das Video wird von Genspark gesponsert. Titel und Beschreibung wurden geprüft, nicht das vollständige Video.

Texte

3Blue1Brown — Transformers, the tech behind LLMs — die bebilderte Textfassung erläutert, wie aus den berechneten Werten Auswahlwahrscheinlichkeiten werden und wie Temperature sie verändert.
Holtzman et al. — The Curious Case of Neural Text Degeneration — die ursprüngliche Forschungsarbeit zu Top-p, auch Nucleus Sampling genannt. Abschnitt 3.1 erklärt die Auswahlgrenze mit Formeln. Die Ergebnisse stammen aus Versuchen mit damaligen Modellen und sind keine Qualitätsgarantie für heutige LLMs.

Quellen

3Blue1Brown — Transformers, the tech behind LLMs. Erklärung von Grant Sanderson, Textadaption von Justin Sun. Die Abschnitte zur Tokenauswahl, Softmax und Temperature wurden gelesen.
vLLM — SamplingParams. Parameterbeschreibungen für Temperature, Top-p, Top-k und Min-p. Die Dokumentation beschreibt diese Software, nicht jede Anwendung.
Holtzman et al. — The Curious Case of Neural Text Degeneration. ICLR 2020. Abstract und relevante Ausschnitte aus Abschnitt 3.1 und 3.2 gelesen, nicht die gesamte Arbeit.

pi-blitz-handoff: Weiterarbeiten mit frischem Kontext

Mirco Blitz — Thu, 01 Oct 2026 00:00:00 GMT

In der Sammlung Pi.dev-Toolbelt stelle ich Werkzeuge für die Arbeit mit Pi vor. Den Anfang macht meine Erweiterung pi-blitz-handoff. Sie kümmert sich um einen Übergang, der bei längeren Aufgaben irgendwann nötig wird: Der Gesprächskontext wird voll, die Arbeit ist aber noch nicht fertig.

Zum Kontext gehören die Informationen, die dem Sprachmodell für seine nächste Antwort zur Verfügung stehen. Bei einer langen Sitzung sammeln sich darin Anforderungen, Entscheidungen, gelesene Dateien, Ergebnisse und verworfene Ansätze. Für die Fortsetzung ist nicht alles davon gleich wichtig. Eine längst erledigte Fehlersuche kann viel Platz beanspruchen. Eine kurze Einschränkung des Nutzers kann dagegen bestimmen, was als Nächstes überhaupt erlaubt ist.

Genau darauf zielt pi-blitz-handoff. Die Erweiterung lässt das Modell ein gezieltes Fortsetzungsdossier schreiben und übergibt es als ersten Prompt an eine frische Pi-Sitzung. Die neue Sitzung bleibt über Pis native Sitzungsverknüpfung mit ihrer Vorgängerin verbunden. Der ursprüngliche Verlauf ist dadurch weiterhin erreichbar. [1]

Was muss mit?

Eine brauchbare Übergabe muss mehr sagen als „Wir arbeiten an einer Website“. Was ist der aktuelle Auftrag? Welche Entscheidungen gelten? Was wurde tatsächlich geprüft, was nur geändert? Wo liegt der aktuelle Stand? Und welche Handlung ist als Nächstes freigegeben?

Die mitgelieferte Standardvorlage verlangt diese Unterscheidungen ausdrücklich. Sie hält auch Blockaden, offene Fragen und Arbeiten fest, für die noch eine Freigabe nötig ist. Sitzungsspezifische Laufzeitinformationen werden getrennt von der Liste geladener Skills erfasst. [1]

Das ist besonders wichtig, wenn sich während der Arbeit die Richtung geändert hat. Ein verworfener Ansatz darf nicht als aktuelle Entscheidung wieder auftauchen. Ein erfolgreicher Build darf nicht zu einem bestandenen Browsertest werden. Und aus „lokal fertigstellen“ darf in der nächsten Sitzung nicht plötzlich „veröffentlichen“ werden.

Warum nicht einfach kompaktieren?

Kompaktierung verdichtet den bisherigen Kontext, damit die Sitzung weiterlaufen kann. pi-blitz-handoff setzt den Schwerpunkt auf eine andere Frage: Was braucht eine neue Sitzung, um genau diese Arbeit korrekt fortzusetzen? Die Erweiterung ist dafür ausgelegt, diesen Fortsetzungskontext gezielter zu erfassen. Das ist ihr Zweck, keine Garantie, dass jede Übergabe besser als jede Kompaktierung ausfällt. [1]

Der Unterschied liegt im Auftrag an das Modell und in der anschließenden Übergabe an eine frische Sitzung. Das Modell schreibt das Dossier; die Erweiterung steuert den Sitzungswechsel und übermittelt den Text. Damit bleibt auch die Grenze klar: Eine technisch erfolgreiche Übergabe kann ein unvollständiges oder fehlerhaftes Dossier transportieren.

Und „Blitz“ steht hier für meinen Nachnamen. Ein Geschwindigkeitsversprechen ist es nicht. Eine ausführliche Übergabe kann länger dauern als eine Kompaktierung. [1]

So beginnt eine Übergabe

Die Installation erfolgt über Pis Paketverwaltung: [1]

pi install npm:pi-blitz-handoff

In Pi startet /sh eine Übergabe. Die Erweiterung lässt zunächst feststellen, ob die Arbeit einen geeigneten Übergabepunkt erreicht hat. Bei einer laufenden Zusammenarbeit kann sie eine Auswahl mit Ready / Wait / Cancel anzeigen. Nach der angenommenen Bereitschaft wird das Dossier geschrieben und an die neue Sitzung übergeben. [1]

Auch eine automatische Auslösung anhand der Kontextauslastung ist möglich. Sie ist standardmäßig ausgeschaltet. Automatisch bedeutet dabei nur, dass die Übergabe automatisch angestoßen wird. Ob die nächste Sitzung selbstständig arbeitet, eine Frage stellt oder wartet, richtet sich weiterhin nach den bestehenden Anweisungen und Freigaben. [1]

Während des eigentlichen Transfers werden neu eingegebene Prompts zurückgehalten und in ihrer Reihenfolge mitgegeben. Bleiben nach einem Abbruch solche Eingaben zurück, lassen sie sich über /sh-recover ausdrücklich prüfen, ausführen oder verwerfen. Eine automatische Ausführung übrig gebliebener Eingaben gibt es nicht. /sh-cancel beendet eine laufende Übergabe, solange der native Sitzungswechsel noch nicht begonnen hat. [1]

An die Arbeit anpassen

Die Erweiterung bringt drei Vorlagenprofile mit: Fast, Balanced und Precise. Sie unterscheiden sich darin, wie ausführlich die Übergabe ausfällt und wie viel Kontext die neue Sitzung selbst wieder erschließen soll. Precise ist der Standard. Die Vorlagen lassen sich anpassen und mit /sh-project-template projektbezogen auswählen. [1]

Damit ist die Erweiterung nicht auf einen bestimmten Arbeitsablauf festgelegt. Die Vorlage beschreibt, was bei der Übergabe erhalten bleiben soll. Sie erteilt keine zusätzlichen Befugnisse.

Was sie nicht übernimmt

Ein Dossier überträgt Informationen. Es versetzt keine laufenden Hintergrundagenten oder Shell-Verbindungen in die neue Sitzung. Deren Zustand und Zuständigkeit müssen dort anhand der tatsächlichen Laufzeitumgebung geprüft werden.

Auch die Daten bleiben deine Verantwortung. Dossiers und zurückgehaltene Eingaben können vertrauliche Projektinformationen enthalten und werden als Klartext verarbeitet beziehungsweise gespeichert. Die Erweiterung bietet weder automatische Geheimniserkennung noch Verschlüsselung und ist keine Sandbox. Wie andere Pi-Erweiterungen läuft sie mit den Rechten des Pi-Prozesses. [1]

Für die hier beschriebene Version 1.2.4 werden Node.js ab 22.19.0, Pi ab 0.84.2 und eine interaktive, gespeicherte Pi-Sitzung vorausgesetzt. Sitzungen mit --no-session werden nicht unterstützt. Der Quellcode steht unter der MIT-Lizenz zur Verfügung. [1], [2], [3]

pi-blitz-handoff soll den Neustart nicht unsichtbar machen. Es soll nachvollziehbar festhalten, wo die Arbeit steht und wie sie weitergehen darf.

Quellen

Was bedeutet die Größe eines Modells?

Mirco Blitz — Thu, 01 Oct 2026 00:00:00 GMT

Was zählt die Zahl?

Gewichte sind eine Art von Parametern. Wenn von LLMs die Rede ist, werden die beiden Begriffe aber meist gleichbedeutend verwendet. Die Zahl im Modellnamen ist eine Größenangabe, keine Zahl von Antworten oder eingebauten Prüfregeln.

Schon bei Qwen3.8-27B lohnt sich die Frage, was mitgezählt wird. Die offizielle Modellkarte bezieht die 27B auf das Sprachmodell. Qwen kann auch Bilder und Videos verarbeiten und besitzt dafür einen weiteren Modellbestandteil. Die Zahl im Namen beschreibt also nicht unbedingt jeden Teil des Modells. [1]

DeepSeek gibt für V4-Pro insgesamt 1,6 Billionen Parameter an. Welche Modellbestandteile dabei mitgezählt werden, erläutert die Ankündigung nicht. Die Zahl allein sagt deshalb weder, wie sich diese Größe zusammensetzt, noch ob das Modell eine bestimmte Aufgabe besser löst als Qwen. [2]

Als reines Gedankenexperiment könnte ein Modell einen Sprachmodellteil mit 80 Milliarden Parametern und weitere, auf andere Aufgaben spezialisierte Bestandteile enthalten. Die Gesamtzahl würde dann alle mitgezählten Teile zusammenfassen. Das ist ein Beispiel, keine Aussage über den Aufbau eines bestimmten Modells. Ob ein Modell so aufgebaut ist, lässt sich aus seiner Gesamtzahl allein nicht ablesen.

Das Titelbild macht aus den beiden Modellen Gewichtheber. Beide stemmen eine Hantel, obwohl sie sehr unterschiedlich groß dargestellt sind. Das ist eine Illustration, kein Leistungstest und kein Beleg dafür, dass sie dieselben Aufgaben gleich gut lösen.

Warum bringt ein kleineres Modell trotzdem etwas zustande?

Qwen3.8-27B ist ein vollständiges Modell. Es verarbeitet eine Eingabe mit seinen trainierten Gewichten und berechnet daraus eine Fortsetzung. Die Zahl 27B schränkt diese Berechnung nicht auf wenige Wörter oder einfache Antworten ein. Eine lokal quantisierte Variante speichert viele Gewichte nur angenähert und braucht dadurch weniger Platz. Es bleiben aber ungefähr gleich viele Parameter. Ob die Variante auf einem bestimmten Rechner läuft und wie gut sie antwortet, muss man getrennt beurteilen. [3]

Mehr Parameter können einem Modell mehr Kapazität geben. Sie garantieren nicht, dass es diese Kapazität für die gerade gestellte Aufgabe besser nutzt. Welche Daten zum Training verwendet wurden, wie das Modell trainiert und später auf Anweisungen abgestimmt wurde, macht ebenfalls einen Unterschied. Ein Modell kann für eine Aufgabe gut geeignet sein, obwohl ein anderes sehr viel größer ist.

Ein historisches Beispiel zeigt, warum Größe allein nicht genügt. In einer Forschungsarbeit über den Einsatz eines festen Trainingsbudgets übertraf ein Modell mit 70 Milliarden Parametern ein Modell mit 280 Milliarden auf den dort geprüften Aufgaben. Das kleinere wurde mit deutlich mehr Daten trainiert. Die Studie belegt keine allgemeine Überlegenheit kleinerer Modelle; sie zeigt den Einfluss des Trainings unter ihren Testbedingungen. [4]

Was gehört zum Modell – und was nicht?

Ein Modell kann Fähigkeiten bereits mitbringen. Qwen3.8-27B kann beispielsweise Bilder und Videos als Eingabe verarbeiten; dafür hat es neben dem Sprachmodell einen Bildencoder. Übersetzen oder mehrere Sprachen verwenden zu können, muss dagegen nicht auf einem eigenen Übersetzungsmodul beruhen. Solche Fähigkeiten können beim Training entstehen. Die Parameterzahl sagt uns allein nicht, wie gut sie funktionieren. [1]

Andere Funktionen stecken häufig in der Software um das Modell herum. Sie kann passende Dokumente suchen und als zusätzlichen Text bereitstellen, ein Rechenwerkzeug aufrufen oder eine Antwort nachträglich prüfen. Diese Vorgänge erhöhen nicht die Parameterzahl des Modells. Ein kleines Modell kann mit solcher Unterstützung nützlicher werden; ein großes kann dieselbe Unterstützung ebenfalls verwenden. Und kein Werkzeug macht eine unzuverlässige Antwort von selbst richtig.

Mit dem richtigen Tooling komme ich auch mit einem kleinen Modell deutlich weiter, als ich ihm allein aufgrund seiner Größe zugetraut hätte.

Darum ist „27B gegen 1,6 Billionen“ keine Ergebnistabelle. Die Zahlen helfen, Modelle und ihren möglichen Ressourcenbedarf einzuordnen. Ob eines beim Programmieren, Übersetzen oder bei einer konkreten Frage besser ist, muss für diese Aufgabe geprüft werden. Training, Architektur und Tooling gehören zu diesem Vergleich – nicht nur die Größe.

Im nächsten Kapitel

Die Größe eines Modells ist nicht dasselbe wie die Menge Text, die es gleichzeitig verarbeiten kann. Was begrenzt das Kontextfenster?

Nächster Artikel →

Deeper into the Rabbit Hole

Wenn du genauer verstehen möchtest, wie Parameter und Training zusammenhängen, führen diese Texte weiter:

3Blue1Brown – How might LLMs store facts? – eine bebilderte, technischere Lektion mit offengelegten Vereinfachungen und Textfassung.
Hoffmann et al. – Training Compute-Optimal Large Language Models – die Forschungsarbeit zum Zusammenspiel von Modellgröße, Trainingsdaten und Rechenaufwand. Forschungs-Preprint.
Touvron et al. – LLaMA: Open and Efficient Foundation Language Models – ein historischer Vergleich unterschiedlicher Modellgrößen auf den dort geprüften Aufgaben. Forschungs-Preprint.

Quellen

Qwen – Qwen3.8-27B – Model Overview.
DeepSeek – DeepSeek V4 Preview Release. Herstellerangabe zur Parameterzahl; seine Leistungsbehauptungen werden hier nicht übernommen.
Hugging Face Transformers – Optimizing LLMs for Speed and Memory.
Hoffmann et al. – Training Compute-Optimal Large Language Models. Forschungs-Preprint; der Vergleich bezieht sich auf die dort berichteten Aufgaben.

Was ist Quantisierung?

Mirco Blitz — Mon, 28 Sep 2026 00:00:00 GMT

Aus feinen werden gröbere Abstufungen

Im vorigen Kapitel ging es um eine einfache Frage: Warum braucht ein Sprachmodell so viel Speicher? Der größte Teil besteht aus seinen Gewichten. Das sind Milliarden Zahlen, die beim Training angepasst wurden und die das Modell für seine Berechnungen benötigt. Während es eine Antwort erzeugt, kommen weitere Daten für die laufende Arbeit und den bisherigen Text hinzu.

Als Beispiel haben wir Qwen3.8-27B betrachtet, ein Modell mit rund 27 Milliarden Gewichten. Würde man jede dieser Zahlen mit 16 Bit – also zwei Byte – speichern, bräuchten die Gewichte allein ungefähr 54 Gigabyte. Nicht jeder Rechner kann so viel schnellen Speicher nur dafür bereitstellen. Und trotzdem gibt es Varianten, die auch auf manchen Consumer-Endgeräten laufen. Wie funktioniert das?

Die Antwort beginnt bei einer Methode namens Quantisierung. Sie lässt die Gewichte nicht verschwinden, sondern speichert angenäherte Werte mit weniger Platz. Dabei ändern sich Zahlen, mit denen das Modell rechnet. Warum entstehen danach überhaupt noch brauchbare Ergebnisse? Und wann merkt man die Änderung?

Stell dir ein buntes Graffiti vor. Mit vielen Farbabstufungen sind die Übergänge im Gesicht und in den Haaren fein. Stehen nur noch wenige Farben zur Verfügung, bleiben Gesicht und Haare erkennbar, aber feine Unterschiede verschwinden. Genau das zeigt der Bildvergleich direkt darunter. Es fehlen dabei keine Bildpunkte; die Abstufungen zwischen den Farben werden gröber.

16 Bit

8 Bit

4 Bit

2 Bit · vier Graustufen

Visuelles Beispiel: Dasselbe Motiv mit immer weniger Farbabstufungen. Das letzte Bild ist zur Verdeutlichung grau.

Bildinhalt als Text

Alle vier Ansichten zeigen denselben engen Ausschnitt einer Graffiti-Wand: ein Gesicht im Profil mit geschlossenen Augen, geschwungenen Haaren und Blättern. Die ersten beiden Ansichten sind bunt und unterscheiden sich nur wenig. Die dritte zeigt größere einfarbige Flächen und weniger feine Übergänge. Die vierte zeigt das Motiv mit nur vier Graustufen. Gesicht und Haare bleiben erkennbar; viele kleine Farb- und Helligkeitsunterschiede fehlen. Das ist ein Bildbeispiel für gröbere Abstufungen, keine Ausgabe quantisierter Sprachmodelle.

Bei den Gewichten betrifft die Änderung Zahlen statt Farben. Ein Gewicht könnte beispielsweise den Wert −0,723 haben. In einem stark vereinfachten Beispiel lässt sich an seiner Stelle nur −0,72 speichern. Wie fein solche Werte unterschieden werden können, nennen wir hier Präzision. Die Zahl wird angenähert – ähnlich wie beim Runden auf weniger Nachkommastellen. Das bedeutet jedoch nicht, dass eine bestimmte Bitzahl genau einer festen Anzahl von Nachkommastellen entspricht.

Die Software ordnet den Gewichten einer Gruppe kleinere gespeicherte Codes zu. Eine Umrechnungsregel verbindet diese Codes mit angenäherten Zahlenwerten. Auf diese Weise können auch negative und größere Werte dargestellt werden. Je weniger Bits für einen Code vorgesehen sind, desto weniger Abstufungen stehen innerhalb seines Bereichs zur Verfügung. Wie gut die Annäherung gelingt, hängt von der gewählten Methode und den tatsächlichen Werten ab. [1] [2]

Warum rechnet das Modell weiter?

Im Artikel Wie funktioniert ein LLM? haben wir beschrieben, wie ein Modell mögliche nächste Wortteile bewertet und daraus eine Fortsetzung auswählt. Hier schauen wir einen Schritt früher in denselben Ablauf: Woher kommen diese Bewertungen, wenn die Gewichte gerundet wurden?

Die Gewichte sind weiterhin da. Das Modell verarbeitet denselben bisherigen Text und verwendet nun angenäherte Zahlen in seinen Rechenschritten. Aus ihnen entstehen weiterhin Bewertungen für dieselben möglichen Wortteile. Die geringere Bitzahl eines gespeicherten Gewichts verkleinert nicht den Wortschatz des Modells. Sie kann verändern, wie hoch einzelne Fortsetzungen bewertet werden.

Ein stark verkleinertes Zahlenbild zeigt zwei Möglichkeiten. Zunächst liegt A mit 8,2 deutlich vor B mit 4,1. Nach der Annäherung stehen 8,0 und 4,2: Die Werte haben sich geändert, A bleibt aber vorn. In einem zweiten Fall liegen A und B vorher bei 8,2 und 8,1. Danach können 8,0 und 8,2 herauskommen – die Reihenfolge kippt. Die Zahlen sind erfundene Bewertungen zur Erklärung, keine Wahrscheinlichkeiten und keine Messung an Qwen. Der tatsächliche Einfluss lässt sich aus ihnen nicht vorhersagen.

Wie viel Platz wird frei?

Für unser Beispiel mit rund 27 Milliarden Gewichten lässt sich der reine Platzbedarf leicht überschlagen:

Speicher pro Gewicht	Rechnerischer Platz für 27 Milliarden Gewichte
16 Bit	etwa 54 GB
8 Bit	etwa 27 GB
4 Bit	etwa 13,5 GB
2 Bit	etwa 6,75 GB

Diese Tabelle beschreibt nur eine idealisierte Gewichtsrechnung. Sie verspricht weder entsprechend große fertige Modelldateien noch gleiche Qualität und Geschwindigkeit bei allen vier Stufen. Die Zweibit-Zeile veranschaulicht eine besonders starke Verkleinerung; sie belegt nicht, dass eine entsprechende Variante dieses Modells praktisch brauchbar ist.

Die lokal geprüfte Qwen3.8-27B-Variante belegt mit ihren Modelldateien rund 30,9 GB, obwohl viele ihrer Gewichte quantisiert gespeichert sind. Nicht jede Komponente nutzt acht Bit; manche bleiben in höherer Genauigkeit erhalten. Hinzu kommen Daten, die für die Umrechnung benötigt werden. Auch beim Betrieb braucht das Modell weiterhin zusätzlichen Speicher für die laufende Arbeit und den KV-Cache, den wir im Artikel Warum braucht ein LLM so viel Speicher? erklärt haben. Die kleinere Datei ist also keine vollständige Rechnung über den Speicherbedarf eines laufenden Modells. Die Dateigröße wurde am lokalen Snapshot geprüft; die öffentliche Modellkonfiguration beschreibt die gemischten Zahlenformate. [3]

Kleiner heißt nicht automatisch gleich gut oder schnell

Weniger Speicherplatz hat einen Preis: Die Gewichte sind nur noch angenähert. Dadurch können sich Antworten ändern. Ob das im Alltag auffällt, hängt vom Modell, der Quantisierung und der Aufgabe ab. Die Bitzahl allein verrät nicht, wie gut eine Variante antwortet. Die Ergebnisse einer konkreten Variante müssen geprüft werden. [2] [4] [5]

Kleiner heißt auch nicht automatisch schneller. Es kann helfen, wenn das Modell dadurch in den verfügbaren schnellen Speicher passt. Die Software und die Hardware müssen das Format aber gut verarbeiten können. Deshalb lohnt sich ein Vergleich am konkreten Modell statt einer allgemeinen Regel wie „4 Bit ist schneller als 8 Bit“. [1] [2]

Quantisierung löst damit ein sehr konkretes Problem: Sie kann die Gewichte so verkleinern, dass ein Modell auf einem geeigneten Rechner überhaupt oder besser im verfügbaren Speicher läuft. Sie nimmt dem Modell nicht seine Kandidaten für das nächste Wortteil, und sie macht aus fehlerhaften Aussagen keine korrekten. Sie tauscht Speicherplatz gegen eine Annäherung der Gewichte, deren Folgen man am konkreten Modell beurteilen muss.

Im nächsten Kapitel

Quantisierung verändert, wie viel Platz die Gewichte brauchen – nicht, wie viele es sind. Was sagt die Zahl 27B über ein Modell aus, und was nicht? Darum geht es im nächsten Kapitel.

Nächster Artikel →

Deeper into the Rabbit Hole

Wenn du genauer verstehen möchtest, wie Verfahren und Hardware zusammenspielen, findest du hier weiterführende Texte und Videos:

Texte

Maarten Grootendorst: A Visual Guide to Quantization – anschauliche Stufen und Zahlenbeispiele; später deutlich technischer als dieses Kapitel.
llama.cpp: Quantize – dokumentierte Größen, Qualitätsmessungen und Geschwindigkeiten konkreter lokaler Formate.
Google AI Edge: Post-training quantization – warum Format und unterstützte Rechenoperationen für die Ausführung zählen.

Videos

Matt Williams: Optimize Your AI – Quantization Explained – lokales Modell, Bitstufen und Auswahl einer passenden Variante.
IBM Technology: LLM Compression Explained – Speicher, Geschwindigkeit und Grenzen der Verkleinerung.

Quellen

Google AI Edge: Post-training quantization.
ggml-org / llama.cpp: Quantize.
Hugging Face: Konfiguration der betrachteten Qwen3.8-27B-Variante. Die rund 30,9 GB Modelldateien wurden am lokalen Snapshot gemessen.
Dettmers et al.: LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale.
Frantar et al.: GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers.

Warum braucht ein LLM so viel Speicher?

Mirco Blitz — Thu, 24 Sep 2026 00:00:00 GMT

Der größte Block: die Gewichte

Der größte Speicherblock eines LLM besteht aus seinen Gewichten. Das sind Zahlenwerte, die während des Trainings immer wieder angepasst wurden. Damit das Modell Text erzeugen kann, müssen diese Gewichte in einem Speicher vorgehalten werden, auf den die Recheneinheiten zugreifen können. [1]

In Modellnamen steht dafür häufig eine Angabe wie 27B. Das B steht für billion (dt. Milliarde).

Nehmen wir das beliebte Modell Qwen3.8-27B. Es besitzt rund 27 Milliarden Gewichte. Würde man diese mit 16 Bit, also zwei Byte pro Gewicht, speichern, lautet die Rechnung:

27 Milliarden × 2 Byte = ungefähr 54 Gigabyte

Ein deutlich größeres Beispiel ist DeepSeek-V4-Pro. Laut Hersteller besitzt es insgesamt 1,6 Billionen Gewichte. Davon sind für jedes Token 49 Milliarden aktiv. [2]

Bei 16 Bit würden alle Gewichte ungefähr 3,2 Terabyte belegen – knapp 60-mal so viel wie beim 27B-Modell. Dass pro Token nur ein Teil der Gewichte aktiv ist, senkt den Rechenaufwand. Dennoch müssen alle Gewichte im Speicher vorgehalten werden.

54 Gigabyte und 3,2 Terabyte beschreiben jeweils nur die Gewichte. Während das Modell rechnet, benötigt es zusätzlich Speicher für temporäre Zwischenergebnisse. Dazu kommt der KV-Cache, der mit dem verwendeten Kontext wächst.

Speicher während der Antwort

Die temporären Zwischenergebnisse bilden einen Arbeitsbereich. Seine Größe hängt von der Software, der Modellarchitektur und der jeweiligen Anfrage ab. Teile davon können nach einem Rechenschritt wieder freigegeben oder erneut verwendet werden.

Dazu kommt der KV-Cache, ausgeschrieben Key-Value-Cache. Er speichert bereits berechnete Zwischenergebnisse des bisherigen Textes. So muss das Modell diese Werte nicht für jedes neue Token erneut berechnen. [3]

Der KV-Cache ist kein zusätzliches Wissen und kein dauerhaftes Gedächtnis. Er wächst mit dem verwendeten Kontext.

Beim regulären 16-Bit-KV-Cache von Qwen3.8-27B kommen pro Token rund 64 KB hinzu. Der Wert ergibt sich aus den Full-Attention-Schichten, KV-Heads und der Head-Dimension der hier betrachteten Modellvariante. [4]

Kontext	Berechnung pro laufender Anfrage	zusätzlicher Speicher	bei mehreren parallelen Anfragen
32K	32K × 64 KB	etwa 2 GB	2 GB × Anzahl Anfragen
64K	64K × 64 KB	etwa 4 GB	4 GB × Anzahl Anfragen
128K	128K × 64 KB	etwa 8 GB	8 GB × Anzahl Anfragen
256K	256K × 64 KB	etwa 16 GB	16 GB × Anzahl Anfragen

Mehr Cache ermöglicht mehr Kontext und damit längere Abläufe, bevor ältere Inhalte entfernt oder zusammengefasst werden müssen. Bei parallelen Anfragen benötigt jede laufende Anfrage ihren eigenen Cache.

Wie viel Text ist das?

Ein Token ist weder ein einzelner Buchstabe noch immer ein vollständiges Wort. Häufige Wörter können aus einem Token bestehen, längere oder seltene Wörter aus mehreren. Deshalb lässt sich die Textmenge nur grob einordnen.

Kontext	Wörter (ca.)	vergleichbare Textmenge
32K	20K–25K	ein Viertel von Harry Potter 1
64K	40K–50K	die Hälfte von Harry Potter 1
128K	80K–100K	Harry Potter 1
256K	160K–200K	Harry Potter 1 und 2 zusammen

Die Buchvergleiche orientieren sich an den englischen Wortzahlen und zeigen nur die Größenordnung. [5] Die tatsächliche Tokenzahl hängt von Sprache, Schreibweise und verwendetem Tokenizer ab.

Wo der Speicher liegt

Die benötigte Speichermenge bleibt gleich, die Anordnung unterscheidet sich jedoch. Bei einem klassischen PC besitzen CPU und Grafikkarte getrennten RAM und VRAM. Daten, mit denen die GPU rechnen soll, müssen zwischen den Speicherbereichen übertragen werden. [6]

Bildinhalt als Text

Das Schaubild zeigt links eine CPU mit normalem RAM und rechts eine separate Grafikkarte mit eigenem VRAM und GPU. Blaue Pfeile verbinden CPU, RAM und VRAM; ein violetter Pfeil verbindet den schnellen VRAM mit der GPU. Unterhalb des RAM liegt eine SSD, die über einen orangefarbenen Pfeil angebunden ist. Eine Legende ordnet Orange niedriger, Blau mittlerer und Violett hoher Bandbreite zu. Die Kapazitäten von 128 GB RAM und 16 GB VRAM dienen als anschauliches Beispiel, nicht als allgemeine Vorgabe.

Bei Apple Silicon und Systemen wie dem NVIDIA DGX Spark greifen CPU und GPU dagegen auf gemeinsamen Unified Memory zu. [7] [8]

Bildinhalt als Text

Das Schaubild zeigt CPU und GPU mit violetten Pfeilen zu einem gemeinsamen Speicherpool. Ein Teil dieses Speichers ist für System und Programme belegt; außerdem ist mögliche Speicherkompression angedeutet. Eine SSD ist über einen orangefarbenen Pfeil mit niedrigerer Bandbreite angebunden. Die dargestellten 128 GB sind ein Beispiel. Entscheidend ist, dass CPU und GPU denselben Speicher nutzen und keine getrennten RAM- und VRAM-Pools dargestellt werden.

Entscheidend ist in beiden Fällen, ob Gewichte, Arbeitsdaten und KV-Cache in schnell erreichbarem Speicher bleiben. Muss das System auf die SSD auslagern, wird die Texterzeugung drastisch langsamer.

Speicher entscheidet – aber nicht allein

Ein LLM benötigt viel Speicher, weil Milliarden Gewichte bereitliegen müssen. Während der Antwort kommen Arbeitsdaten und der mit dem Kontext wachsende KV-Cache hinzu. Bei parallelen Anfragen vervielfacht sich dieser zusätzliche Bedarf.

Genügend Speicher entscheidet, ob ein Modell überhaupt laufen kann. Für die Geschwindigkeit zählt zusätzlich, wie schnell die GPU auf diese Daten zugreifen kann.

Trotzdem läuft Qwen3.8-27B auch auf Rechnern, die keine 54 Gigabyte allein für seine Gewichte bereitstellen können. Wie das funktioniert, klären wir im nächsten Kapitel: mit Quantisierung.

Im nächsten Kapitel

Qwen3.8-27B kann auch auf Rechnern laufen, die keine 54 Gigabyte allein für seine Gewichte bereitstellen. Im nächsten Kapitel schauen wir uns an, wie Quantisierung den Speicherbedarf verringert.

Nächster Artikel →

Deeper into the Rabbit Hole

Wenn du tiefer einsteigen möchtest, führen diese Texte und Videos die wichtigsten technischen Punkte weiter:

Texte

Hugging Face: Optimizing LLMs for Speed and Memory – Gewichte, Datentypen und die wichtigsten Speichergrenzen bei der Inferenz.
Hugging Face: Cache Strategies – KV-Cache, Offloading und unterschiedliche Cache-Strategien.
Apple: Choosing a Resource Storage Mode for Apple GPUs – gemeinsamer Systemspeicher und die Zugriffswege von CPU und GPU.
NVIDIA: DGX Spark – ein konkretes System mit 128 GB kohärentem Unified Memory.

Videos

IBM Technology: How KV Cache Speeds Up LLMs for Faster AI Models on GPUs – ein kompakter Einstieg in KV-Cache, Prefill und Decode.
PyTorch: Understanding the LLM Inference Workload – Mark Moyou von NVIDIA geht technischer auf Modelle, Hardware, Quantisierung und Inferenz ein.

Quellen

Hugging Face Transformers: Optimizing LLMs for Speed and Memory.
DeepSeek: DeepSeek-V4-Pro.
Hugging Face Transformers: Cache Strategies.
Hugging Face: Konfiguration der betrachteten Qwen3.8-27B-Variante.
Word Counter: How Many Words Are in Harry Potter?.
NVIDIA: CUDA C++ Best Practices Guide.
Apple Developer Documentation: Choosing a Resource Storage Mode for Apple GPUs.
NVIDIA: DGX Spark.

Warum ist die GPU schneller als die CPU?

Mirco Blitz — Wed, 23 Sep 2026 00:00:00 GMT

Was ein LLM dabei berechnet

Aus dem ersten Kapitel kennen wir die Gewichte eines LLM. Das sind sehr große Tabellen aus Zahlen, in denen die beim Training gelernten Muster stecken. Eine solche rechteckige Zahlentabelle heißt in der Mathematik Matrix. Wenn ein LLM Text verarbeitet, werden diese Matrizen immer wieder miteinander verrechnet. Ein großer Teil dieser Arbeit besteht aus Multiplikationen und Additionen.

Bildinhalt als Text

Das Schaubild zeigt eine rechteckige Tabelle aus zehn Zeilen und sechzehn Spalten. Jede Zelle enthält eine positive oder negative Dezimalzahl. Eine Zeile ist blau und eine Spalte türkis hervorgehoben; ihre gemeinsame Zelle ist rot umrandet. Weitere Matrizen sind abgedunkelt im Hintergrund angedeutet. Die Zahlen stehen schematisch für Gewichte, die während des Trainings angepasst wurden. Ein LLM enthält viele solcher Matrizen.

Dabei muss dieselbe Rechenregel auf sehr viele Zahlen angewendet werden. Das Ergebnis einer einzelnen Rechnung hängt zwar von den jeweiligen Zahlen ab. Der Rechenweg bleibt aber für große Gruppen gleich. Dadurch lässt sich die Gesamtarbeit in viele kleine Pakete zerlegen, die gleichzeitig bearbeitet werden können. Genau für solchen hohen Durchsatz wurden GPUs entwickelt. [1] [2]

Wenige flexible Kerne, viele parallele Recheneinheiten

Eine CPU muss sehr unterschiedliche Aufgaben schnell erledigen. Sie führt das Betriebssystem aus, reagiert auf Eingaben und arbeitet Programme mit vielen Entscheidungen und wechselnden Abläufen ab. Dafür besitzt sie vergleichsweise wenige, sehr leistungsfähige Kerne. Diese sind darauf ausgelegt, einzelne Aufgaben mit geringer Verzögerung zu bearbeiten. [1] [2]

Eine GPU verfolgt ein anderes Ziel. Sie besitzt sehr viele einfachere Recheneinheiten und erreicht ihre Leistung, indem sie große Mengen ähnlicher Arbeit verteilt. Bei NVIDIA-GPUs werden Gruppen von Threads gemeinsam ausgeführt. Innerhalb einer solchen Gruppe läuft grundsätzlich dasselbe Programm auf unterschiedlichen Daten. Wenn alle denselben Rechenweg nehmen, ist die Hardware besonders gut ausgelastet. [3]

Das erklärt auch, warum die Anzahl der CPU- und GPU-„Kerne“ nicht direkt vergleichbar ist. Eine einzelne GPU-Recheneinheit ist kein kleiner Ersatz für einen vollständigen CPU-Kern. Die beiden Architekturen verteilen ihre Fläche und Energie auf unterschiedliche Fähigkeiten: Die CPU setzt auf schnelle, flexible Einzelarbeit, die GPU auf sehr viel gleichzeitige Rechenarbeit.

Bildinhalt als Text

Das Schaubild stellt die unterschiedlichen Stärken von CPU und GPU gegenüber. Links zeigt eine CPU acht große Kerne. Sie stehen für wenige flexible Kerne, die wechselnde Aufgaben und Entscheidungen schnell bearbeiten. Rechts zeigt eine GPU ein dichtes Raster aus vielen kleinen Recheneinheiten. Ein großer Teil davon leuchtet gleichzeitig. Das steht für hohen Durchsatz bei vielen gleichartigen Rechnungen. CPU-Kerne und GPU-Recheneinheiten sind nicht direkt miteinander vergleichbar; Anzahl und Aufbau sind schematisch dargestellt.

Warum das zu einem LLM passt

Die großen Matrixberechnungen eines LLM liefern der GPU viele gleichartige Arbeitspakete. Statt eine lange Rechnung nach der anderen abzuschließen, kann die GPU zahlreiche Teilrechnungen parallel beginnen. Ihre Stärke liegt dabei nicht im Tempo einer einzelnen Multiplikation, sondern in der Menge an Multiplikationen und Additionen, die sie zusammen abarbeiten kann.

Dieser Unterschied lässt sich als Latenz und Durchsatz beschreiben. Latenz ist die Zeit, die eine einzelne Aufgabe bis zu ihrem Ergebnis benötigt. Durchsatz beschreibt, wie viel Arbeit ein System innerhalb einer bestimmten Zeit insgesamt erledigt. CPUs sind auf niedrige Latenz bei anspruchsvoller Einzelarbeit ausgelegt. GPUs opfern einen Teil dieser Flexibilität, um bei geeigneten Aufgaben einen sehr hohen Durchsatz zu erreichen. [2]

Die Recheneinheiten müssen gefüttert werden

Viele Recheneinheiten helfen nur, wenn sie rechtzeitig neue Zahlen erhalten. Bei einer separaten Grafikkarte liegt dafür direkt an der GPU ein eigener Speicher, der VRAM. Seine hohe Bandbreite ermöglicht es, große Datenmengen schnell zwischen Speicher und Recheneinheiten zu bewegen. [3] [4]

Passt ein Modell in den VRAM, können seine Gewichte dort für die Berechnung bereitliegen. Müssen Daten dagegen ständig zwischen dem Arbeitsspeicher des Computers und der Grafikkarte übertragen werden, kostet das Zeit. Bei kleinen Aufgaben kann dieser Aufwand den Geschwindigkeitsvorteil der GPU sogar vollständig aufzehren. [2]

Warum die GPU nicht immer schneller ist

Nicht jede Aufgabe lässt sich in viele gleichartige Pakete zerlegen. Manche Berechnungen bauen Schritt für Schritt aufeinander auf. Andere enthalten viele Abzweigungen, bei denen verschiedene Teile unterschiedliche Anweisungen ausführen müssen. Auf einer GPU bleiben dann Recheneinheiten ungenutzt oder müssen aufeinander warten. Kleine Aufgaben können außerdem zu wenig Arbeit liefern, um den Aufwand für Start, Verteilung und Datentransfer auszugleichen. [3] [4]

Auch ein stark parallelisiertes Programm behält meist Teile, die nacheinander ausgeführt werden müssen. Diese seriellen Anteile begrenzen, wie stark das gesamte Programm durch mehr parallele Recheneinheiten beschleunigt werden kann. Hinzu kommen Aufwand für Kommunikation, Koordination und Datenbewegung. [5]

CPU und GPU sind deshalb kein Entweder-oder. Die CPU steuert den allgemeinen Programmablauf, bereitet Arbeit vor und übernimmt Aufgaben, die Flexibilität oder schnelle Einzelreaktionen verlangen. Die GPU bearbeitet die großen, passenden Rechenblöcke. Bei einem LLM ist diese Arbeitsteilung besonders wirksam, weil seine Matrixberechnungen sehr viel parallele Arbeit bereitstellen.

Im nächsten Kapitel

Die GPU kann nur mit Zahlen rechnen, die rechtzeitig in ihrem Speicher bereitstehen. Im nächsten Kapitel schauen wir uns deshalb an, warum ein LLM so viel Speicher benötigt und welche Rolle der VRAM dabei spielt.

Nächster Artikel →

Deeper into the Rabbit Hole

Wenn du tiefer einsteigen möchtest, führen diese Texte und Videos die wichtigsten technischen Punkte weiter:

Texte

NVIDIA: CUDA C++ Best Practices Guide – Parallelität, Datentransfers, Speicherzugriffe und die Grenzen praktischer GPU-Beschleunigung.
AMD ROCm: Understanding GPU Performance – Rechenleistung, Speicherbandbreite und Overhead als mögliche Engpässe.
Lawrence Livermore National Laboratory: Introduction to Parallel Computing Tutorial – eine herstellerunabhängige Einführung in Parallelisierung und ihre Grenzen.

Videos

Computerphile: CPU vs GPU (What’s the Difference?) – eine kurze und verständliche Gegenüberstellung.
Branch Education: How do Graphics Cards Work? Exploring GPU Architecture – eine ausführliche Visualisierung von GPU, Recheneinheiten und Grafikspeicher.
Stanford CS149: GPU Architecture and CUDA Programming – eine technische Universitätsvorlesung zur Vertiefung.

Quellen

Intel: CPU vs. GPU: What’s the Difference?.
NVIDIA: CUDA C++ Best Practices Guide.
NVIDIA: CUDA Programming Guide — Programming Model.
AMD ROCm: Understanding GPU Performance.
Lawrence Livermore National Laboratory: Introduction to Parallel Computing Tutorial.

Warum sprechen wir über KI, als wäre sie ein Mensch?

Mirco Blitz — Tue, 22 Sep 2026 00:00:00 GMT

Woher diese Sprache kommt

Die Geschichte beginnt lange vor heutigen Chatbots. Warren McCulloch und Walter Pitts beschrieben 1943 ein mathematisches Modell für Nervennetze. Dafür reduzierten sie Nervenzellen auf stark vereinfachte Schaltelemente, die sich mit Logik beschreiben ließen. Das war keine digitale Nachbildung eines Gehirns. Es war eine von der Biologie inspirierte Rechenidee. [1]

Frank Rosenblatt griff diese Verbindung von Biologie und Rechentechnik in den 1950er-Jahren mit dem Perzeptron auf. Sein Fachartikel von 1958 beschrieb es als ein Modell für die Speicherung und Organisation von Informationen im Gehirn und sprach ausdrücklich von Lernkurven. Begriffe wie Wahrnehmen, Erkennen und Lernen gehörten damit zur fachlichen Beschreibung eines technischen Modells. Sie waren keine Behauptung, die Maschine besitze menschliche Erfahrungen oder ein eigenes Innenleben. [2]

Außerhalb dieses Fachrahmens bekamen dieselben Wörter schnell eine zusätzliche Bedeutung. Bei der öffentlichen Vorstellung des Perzeptrons im Juli 1958 sprach Rosenblatt von einer Maschine mit einer „eigenen Idee“. Die New York Times schrieb, sie lerne durch Handeln und werde dabei klüger. Aus einer technischen Beschreibung wurde so eine Erzählung über menschenähnliche Fähigkeiten. Das Problem lag nicht in den Fachbegriffen selbst, sondern darin, dass ihre alltägliche Bedeutung ungeprüft auf die Maschine übertragen wurde. [3]

Joseph Weizenbaums Programm ELIZA zeigte bereits 1966, wie schnell die technische Fachbedeutung im Gespräch von einer menschlichen Deutung überlagert wird. ELIZA suchte in Eingaben nach Schlüsselwörtern und formte daraus passende Rückfragen. Trotzdem schrieben Menschen dem Programm Verständnis und Einfühlungsvermögen zu. Weizenbaum erklärte, dass die Gesprächspartner selbst das fehlende Wissen und die vermeintliche Einsicht ergänzten. [8]

Als Fachsprache sind solche biologischen Vergleiche nützlich. Sie geben einer neuen technischen Idee einen verständlichen Namen und zeigen, woher sie stammt. Der Vergleich beschreibt aber keine vollständige Gleichheit. Ein künstliches Neuron ist keine Nervenzelle, und maschinelles Lernen ist nicht derselbe Vorgang wie menschliches Lernen. Die Fachbegriffe bleiben sinnvoll, solange wir ihre technische Bedeutung von der vertrauten Alltagsbedeutung unterscheiden. [1] [2]

Moderne Sprachmodelle sind keine bloß vergrößerten Perzeptrons. Sie gehören aber weiterhin zur technischen Familie der künstlichen neuronalen Netze. Auch sie verarbeiten Informationen in miteinander verbundenen Recheneinheiten, deren Gewichte beim Training angepasst werden. Die Verfahren und Größenordnungen haben sich grundlegend verändert, doch Begriffe wie Neuron, Netz, Gewicht und Lernen sind aus dieser Entwicklung erhalten geblieben. [1] [2] [4]

Später kamen weitere Begriffe hinzu. Der Transformer, auf dem heutige Sprachmodelle beruhen, verwendet „Attention“ als Namen für eine genau definierte Gewichtungsrechnung. Die Software um das Modell speichert Kontext und wird deshalb mit „Memory“ beschrieben. Führt ein solches System selbstständig mehrere Schritte und Softwareaufrufe aus, sprechen wir von einem „Agenten“. So verbindet die heutige Fachsprache ältere biologische Vergleiche mit neueren Bezeichnungen für konkrete technische Funktionen. [5] [6] [7]

Was diese Wörter heute bedeuten

Neuron

Ein künstliches Neuron ist eine Recheneinheit innerhalb eines Netzes. Es verarbeitet Zahlen aus anderen Einheiten, gewichtet sie und gibt ein berechnetes Ergebnis weiter. Der Name verweist auf die biologische Inspiration, macht diese Recheneinheit aber nicht zu einer kleinen Gehirnzelle. [1]

Lernen

Wenn Fachleute sagen, dass ein Modell lernt, meinen sie einen technischen Vorgang: Während des Trainings werden seine Parameter verändert. Dazu gehören die Gewichte, die das Verhalten des Modells bestimmen. Durch diese Anpassungen bildet das Modell Muster aus den Trainingsdaten ab. Der Fachbegriff beschreibt damit eine messbare Veränderung des Modells. Er behauptet nicht, dass die Software Erfahrungen sammelt oder ihre Fehler wie ein Mensch versteht. [4]

Gedächtnis

Auch „Gedächtnis“ bezeichnet in der Informatik nicht eine einzige Fähigkeit. Gemeint sein können die im Modell gespeicherten Gewichte, der aktuelle Gesprächskontext oder Informationen in einer externen Datenbank. Eine Chatsoftware kann frühere Nachrichten speichern und bei der nächsten Anfrage erneut an das Modell schicken. Das wirkt wie eine Erinnerung, ist technisch aber ein neuer Modellaufruf mit erneut bereitgestellten Informationen. Der Fachbegriff bleibt nützlich, solange erkennbar ist, welche Form von Speicher gemeint ist. [5]

Attention

„Attention“, auf Deutsch Aufmerksamkeit, bezeichnet ebenfalls einen konkreten Rechenvorgang. Ein Transformer berechnet damit, welche Teile der Eingabe für den aktuellen Schritt stärker gewichtet werden. Das Wort beschreibt also, wie Informationen rechnerisch ausgewählt und miteinander verbunden werden. Es behauptet nicht, dass das Modell sich bewusst konzentriert oder etwas aus eigenem Interesse wichtig findet. [6]

Reasoning / Denken

„Reasoning“ kann erzeugte Zwischenschritte, die Zerlegung einer Aufgabe oder besondere Verfahren für mehrstufige Aufgaben bezeichnen. Sichtbare „Gedanken“ oder „Denkprotokolle“ sind dabei selbst erzeugter Text. Sie können den Lösungsweg verständlicher machen, bilden aber nicht vollständig ab, was im Modell berechnet wurde. Der Begriff bezeichnet deshalb ein technisches Verfahren oder eine Ausgabeform, kein bewusstes Nachdenken. [10]

Halluzination

Als „Halluzination“ bezeichnet man eine plausibel klingende, aber falsche oder nicht belegte Ausgabe. Das Wort beschreibt einen Fehler des erzeugten Inhalts. Es bedeutet nicht, dass das Modell etwas wahrnimmt, das nicht existiert. Das US-amerikanische NIST weist deshalb darauf hin, dass der Begriff die Software vermenschlichen kann, und verwendet stattdessen „Konfabulation“. [11]

Entscheidung

Wenn ein System „entscheidet“, wählt es anhand seiner Eingaben, berechneten Werte und vorgegebenen Regeln eine Ausgabe oder Aktion aus. Diese Auswahl kann reale Folgen haben. Der Fachbegriff behauptet aber nicht, dass das System moralisch abwägt oder für die Folgen verantwortlich ist. [7] [12]

Tool / Werkzeug

Ein Tool oder Werkzeug ist eine Funktion, ein Programm oder ein Dienst, den ein Agentensystem aufrufen kann. Das Modell kann einen solchen Aufruf in seiner Ausgabe anfordern. Ausgeführt wird er von der steuernden Software. Das Ergebnis wird anschließend für den nächsten Modellaufruf bereitgestellt. [7] [9]

Harness

Als Harness bezeichnet man die steuernde Software um ein Modell. Sie stellt Anfragen zusammen, speichert Zustände, startet Modellaufrufe, verarbeitet die Ausgaben und führt angeforderte Werkzeuge aus. Das Modell erzeugt Ausgaben; das Harness macht daraus einen fortlaufenden technischen Ablauf. [9]

Agent

Auch „Agent“ ist zunächst ein technischer Funktionsbegriff. Bei heutigen LLM-Systemen bezeichnet er das Zusammenspiel aus Modell, steuernder Software, gespeichertem Kontext, angebundener Software und vergebenen Zugriffsrechten. Ein solches System kann innerhalb dieser Vorgaben selbstständig mehrere Schritte ausführen. „Selbstständig“ bedeutet hier, dass nicht jeder einzelne Schritt von einem Menschen ausgelöst werden muss. Es bedeutet nicht, dass der Agent eigene Ziele oder einen eigenen Willen besitzt. [7]

Autonomie

„Autonom“ oder „selbstständig“ beschreibt, wie viele Schritte ein System ohne einzelne menschliche Bestätigung ausführen kann. Dieser Handlungsspielraum entsteht durch das Harness, die verfügbaren Werkzeuge und die vergebenen Berechtigungen. Mehr Autonomie bedeutet daher mehr technischen Spielraum, nicht eigene Ziele oder Unabhängigkeit von der bereitgestellten Infrastruktur. [7] [12]

Warum wir heute so leicht durcheinanderkommen

Diese Wörter sind über Jahrzehnte als technische Fachsprache entstanden. Heute begegnen sie uns jedoch häufig außerhalb ihres Fachrahmens. Chatbots sprechen in der Ich-Form, tragen Namen und antworten mit menschlich klingenden Stimmen. Produkttexte erzählen von Systemen, die denken, lernen und selbstständig handeln. Dadurch hören wir nicht mehr nur die technische Bedeutung, sondern automatisch auch die vertraute menschliche Bedeutung der Wörter. [13] [14]

Für die folgenden Artikel behalten wir die Fachbegriffe bei. Wir fragen aber immer, welchen konkreten technischen Vorgang sie gerade bezeichnen. So können wir darüber sprechen, was ein System tatsächlich berechnet, speichert oder ausführt, ohne ihm deshalb Gefühle, Absichten oder Verantwortung zuzuschreiben. Seine realen Fähigkeiten und Risiken werden dadurch nicht kleiner. Sie werden lediglich genauer beschrieben.

Im nächsten Kapitel

Als Nächstes geht es um das Rechnen selbst: Eine GPU kann die vielen gleichartigen Berechnungen eines LLM schneller ausführen als eine CPU, obwohl sie nicht für jede Aufgabe schneller ist.

Nächster Artikel →

Deeper into the Rabbit Hole

Wenn du tiefer einsteigen möchtest, führen diese Texte und Videos die wichtigsten Linien weiter:

Texte

Joseph Weizenbaum: ELIZA—A Computer Program for the Study of Natural Language Communication Between Man and Machine – der Originaltext von 1966 über ELIZA und die menschlichen Zuschreibungen im Gespräch.
Mirages. On Anthropomorphism in Dialogue Systems – darüber, wie Sprache, Gestaltung und Produktbeschreibung die Wahrnehmung eines Systems beeinflussen.
Believing Anthropomorphism – die Studie zu Stimme, Ich-Form, wahrgenommener Genauigkeit und Vertrauen.
NIST: Generative Artificial Intelligence Profile – ein nüchterner Blick auf Halluzinationen, Automation Bias und andere Risiken generativer KI.

Videos

GBH Archives: The Chatbot Inventor’s Cautionary Alert (1978) – ein kurzer historischer Archivclip mit Joseph Weizenbaum.
ACM SIGCHI: Believing Anthropomorphism – eine kurze Vorstellung der Studie zu anthropomorphen Signalen und Vertrauen.
IBM Technology: A Brief History of AI: From Machine Learning to Gen AI to Agentic AI – ein kurzer Überblick über die Entwicklung der KI von Alan Turing bis zu heutigen Agentensystemen.
The Royal Institution: What is generative AI and how does it work? – Mirella Lapata führt ausführlicher durch die Entwicklung generativer KI und den Weg zu heutigen Sprachmodellen.

Quellen

Warren S. McCulloch und Walter Pitts: A Logical Calculus of the Ideas Immanent in Nervous Activity, 1943.
Frank Rosenblatt: The Perceptron: A Probabilistic Model for Information Storage and Organization in the Brain, 1958.
Melanie Lefkowitz, Cornell Chronicle: Professor’s Perceptron Paved the Way for AI – 60 Years Too Soon, 2019.
Google for Developers: Machine Learning Glossary — parameter.
Anthropic: Context windows.
Ashish Vaswani et al.: Attention Is All You Need, 2017.
Anna Gutowska, IBM: What Are AI Agents?.
Joseph Weizenbaum: ELIZA—A Computer Program for the Study of Natural Language Communication Between Man and Machine, 1966.
OpenAI: Hugging Face Incident Technical Report, 2026.
Fabien Roger et al.: Let’s Think Dot by Dot: Hidden Computation in Transformer Language Models, 2024.
NIST: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, 2024.
High-Level Expert Group on AI: Requirements of Trustworthy AI, 2019.
Gavin Abercrombie et al.: Mirages. On Anthropomorphism in Dialogue Systems, 2023.
Michelle Cohn et al.: Believing Anthropomorphism: Examining the Role of Anthropomorphic Cues on Trust in Large Language Models, 2024.

Wie funktioniert ein LLM?

Mirco Blitz — Mon, 21 Sep 2026 00:00:00 GMT

Ein LLM zerlegt Text in kleine Abschnitte, die Tokens heißen. Sie entsprechen nicht immer ganzen Wörtern. Ein Token kann ein Wort, ein Wortteil oder ein Satzzeichen sein. Für das Beispiel in diesem Artikel vereinfachen wir das. Wir behandeln jedes Wort und jedes Satzzeichen als eigenes Token. So lässt sich das Grundprinzip leichter zeigen.

Das Training

Am Anfang steht ein untrainiertes Modell. Es bekommt sehr viele Texte zu sehen und soll immer wieder vorhersagen, wie ein Text weitergeht. Jede Vorhersage wird mit der tatsächlichen Fortsetzung verglichen. Danach werden die inneren Einstellungen des Modells ein kleines Stück angepasst. Dieser Vorgang wiederholt sich sehr oft. So lernt das Modell nach und nach, welche Fortsetzungen in welchem Zusammenhang wahrscheinlich sind.

Bei diesem Training werden riesige Tabellen voller Zahlen immer wieder angepasst. Diese Zahlen heißen Gewichte. Um ihre Aufgabe zu verstehen, schauen wir kurz auf den Aufbau des Modells: Es verarbeitet Informationen in vielen miteinander verbundenen Rechenknoten. Diese nennt man oft künstliche Neuronen. Die Gewichte bestimmen, wie stark die Verbindungen zwischen diesen Knoten wirken.

Die Gewichte bilden gemeinsam die Muster ab, die das Modell beim Training gelernt hat. Dazu gehört zum Beispiel, wie englische Sätze aufgebaut sind und welche Wörter häufig miteinander vorkommen. Beim Verarbeiten eines Textes verbindet das Modell diese gelernten Muster mit dem jeweiligen Kontext. So kann dasselbe Wort je nach Zusammenhang unterschiedlich eingeordnet werden.

Nach diesem ersten Trainingsschritt kann das Modell Texte fortsetzen, ist aber noch nicht automatisch ein brauchbarer Chatbot. Deshalb wird es häufig mit Beispielen weitertrainiert, die jeweils aus einer Anweisung und einer dazugehörigen Antwort bestehen. Dadurch werden Ausgaben wahrscheinlicher, die Fragen beantworten, Aufgaben bearbeiten oder einem gewünschten Format folgen.

Anschließend werden häufig zwei Antworten des Modells miteinander verglichen und nach vorgegebenen Kriterien bewertet. Das können Menschen übernehmen, aber auch andere Modelle oder automatische Prüfverfahren. Diese Bewertungen dienen als Grundlage für ein weiteres Training. Dabei werden die Gewichte so angepasst, dass Ausgaben, die den besser bewerteten Antworten ähneln, künftig wahrscheinlicher werden. Das macht eine Antwort für Menschen oft hilfreicher oder gefälliger, aber nicht automatisch faktisch richtig.

Wie ein trainiertes LLM antwortet

Wenn ein trainiertes LLM eine Antwort erzeugt, nennt man das Inferenz. Das Modell verarbeitet den gesamten Text, den du in das Chatfenster eingegeben hast. Mithilfe seiner gelernten Gewichte berechnet es für jedes mögliche nächste Textstück einen Wert. Das Ergebnis können wir uns als große Tabelle vorstellen: Manche Fortsetzungen sind sehr wahrscheinlich, viele andere äußerst unwahrscheinlich.

Vereinfacht ähnelt diese Tabelle Amazons „Andere Kunden kauften auch“. Dort lautet die Frage: „Was kauften Menschen, die dieses Produkt angesehen haben?“ Beim LLM lautet sie sinngemäß: „Was schrieben Menschen nach einem ähnlichen Text wahrscheinlich als Nächstes?“

Um diese gewichtete Auswahl sichtbar zu machen, übertragen wir sie in unserem Beispiel auf einen W20, einen Würfel mit den Zahlen 1 bis 20. Die fünf wahrscheinlichsten Fortsetzungen erhalten jeweils einen passenden Zahlenbereich. Alle weiteren Möglichkeiten fassen wir in einer sechsten Tabellenzeile zusammen. Je größer der Zahlenbereich ist, desto wahrscheinlicher wird die Fortsetzung ausgewählt.

Wir schicken den Text „Meine Katze hat“ dreimal unabhängig an dasselbe Modell. Weil alle drei Inferenzen mit demselben Text beginnen, verwenden sie dieselbe erste Tabelle. Der W20 fällt jedoch jedes Mal anders und wählt dadurch drei verschiedene Fortsetzungen aus. Im Bild verfolgen wir sie als Inferenz 1, Inferenz 2 und Inferenz 3.

Bildinhalt als Text

Alle drei Inferenzen beginnen mit „Meine Katze hat“. Die gemeinsame W20-Tabelle lautet: 1 bis 6 = „Hunger“, 7 bis 10 = „eine“, 11 bis 13 = „heute“, 14 bis 16 = „mich“, 17 bis 18 = „wieder“, 19 bis 20 = weitere Möglichkeiten.

Inferenz 1 würfelt 4 und ergänzt „Hunger“.
Inferenz 2 würfelt 9 und ergänzt „eine“.
Inferenz 3 würfelt 15 und ergänzt „mich“.

In unseren drei Inferenzen hat der erste Würfelwurf jeweils ein anderes Wort ausgewählt. Dieses Wort wird an den bisherigen Text angehängt. Für den nächsten Schritt verwendet das Modell wieder den gesamten bisherigen Text, nicht nur das neue Wort. Weil sich die drei Texte jetzt unterscheiden, entstehen auch drei verschiedene Tabellen mit anderen Fortsetzungen und Gewichtungen.

Bildinhalt als Text

Inferenz 1, „Meine Katze hat Hunger“: 1 bis 15 = Punkt, 16 bis 17 = „und“, 18 = „bekommen“, 19 = Ausrufezeichen, 20 = weitere Möglichkeiten. Der Wurf 7 wählt den Punkt.
Inferenz 2, „Meine Katze hat eine“: 1 bis 8 = „Maus“, 9 bis 12 = „Idee“, 13 bis 15 = „Schwester“, 16 bis 17 = „neue“, 18 = „kleine“, 19 bis 20 = weitere Möglichkeiten. Der Wurf 5 wählt „Maus“.
Inferenz 3, „Meine Katze hat mich“: 1 bis 8 = „geweckt“, 9 bis 12 = „gesehen“, 13 bis 15 = „gebissen“, 16 bis 18 = „ignoriert“, 19 = „verfolgt“, 20 = weitere Möglichkeiten. Der Wurf 14 wählt „gebissen“.

Nun wird in jeder Inferenz erneut gewürfelt. Dabei können die neuen Tabellen sehr unterschiedlich aussehen. In einer verteilt sich die Wahrscheinlichkeit auf mehrere mögliche Wörter, während in einer anderen fast alle Würfelwerte zur gleichen Fortsetzung führen. Im dritten Bild führen wir die drei Sätze noch einen Schritt weiter und schließen sie ab.

Bildinhalt als Text

Inferenz 1, „Meine Katze hat Hunger.“: 1 bis 18 = EOS, 19 = „Und“, 20 = weitere Möglichkeiten. Der Wurf 6 wählt EOS und beendet die Inferenz.
Inferenz 2, „Meine Katze hat eine Maus“: 1 bis 5 = „gefangen“, 6 bis 8 = „gesehen“, 9 bis 11 = Punkt, 12 bis 14 = „im“, 15 bis 17 = „namens“, 18 bis 20 = weitere Möglichkeiten. Der Wurf 10 wählt den Punkt.
Inferenz 3, „Meine Katze hat mich gebissen“: 1 bis 14 = Punkt, 15 bis 16 = „und“, 17 = Ausrufezeichen, 18 = Komma, 19 bis 20 = weitere Möglichkeiten. Der Wurf 6 wählt den Punkt.

Diese Berechnung wiederholt sich Textstück für Textstück. Normalerweise endet sie, wenn das Modell ein besonderes Ende-Token auswählt, häufig EOS für „End of Sequence“. Dieses Token gehört nicht zur sichtbaren Antwort. Inferenz 1 ist nun beendet.

Bildinhalt als Text

Inferenz 2, „Meine Katze hat eine Maus.“: 1 bis 18 = EOS, 19 = „Und“, 20 = weitere Möglichkeiten. Der Wurf 4 wählt EOS.
Inferenz 3, „Meine Katze hat mich gebissen.“: 1 bis 17 = EOS, 18 = „Aber“, 19 = „Und“, 20 = weitere Möglichkeiten. Der Wurf 7 wählt EOS.

Nun haben auch Inferenz 2 und Inferenz 3 ein EOS-Token ausgewählt. Damit sind alle drei Inferenzen beendet. Die Chatsoftware hat den erzeugten Text empfangen und zeigt ihn als Antwort an. Viele Chatoberflächen zeigen die Antwort bereits während ihrer Entstehung Textstück für Textstück. Eine Inferenz kann auch ohne EOS enden, etwa wenn die festgelegte Höchstlänge erreicht ist oder du die Ausgabe abbrichst.

Wenn du danach eine weitere Nachricht in den Chat schreibst, stellt die Chatsoftware eine neue Anfrage zusammen. Sie kombiniert den bisherigen Gesprächsverlauf mit deiner neuen Nachricht und schickt alles erneut an das LLM. Das LLM selbst erinnert sich nicht an die vorherige Anfrage. Die scheinbare Erinnerung entsteht dadurch, dass die Chatsoftware den bisherigen Verlauf erneut mitsendet.

Die steuernde Software: das Harness

Die Chatsoftware aus unserem Beispiel ist bereits eine einfache Form eines Harness. So nennt man die steuernde Software um ein LLM. Sie stellt Anfragen zusammen, schickt sie an das Modell, nimmt dessen Ausgaben entgegen und entscheidet, was als Nächstes damit geschieht. Das LLM erzeugt Text; das Harness organisiert den Ablauf.

Ein einfaches Harness verwaltet vor allem den Chatverlauf und die Anfragen an das LLM. Ausgefeiltere Varianten können zusätzliche Anweisungen einfügen, die Erzeugung der Antwort steuern und dem LLM ermöglichen, Aufrufe anderer Software anzufordern. Dadurch kann dasselbe LLM weit mehr tun als in einem einfachen Chat.

Für jede Inferenz stellt das Harness eine vollständige Anfrage zusammen. Sie kann zusätzliche Anweisungen, den bisherigen Gesprächsverlauf, Informationen über verfügbare Software und Ergebnisse früherer Aufrufe enthalten. Das Harness kann außerdem Einstellungen vorgeben, etwa wie lang die Antwort höchstens werden darf. Das LLM erhält nur die Informationen und Möglichkeiten, die das Harness ihm für diese Anfrage bereitstellt.

Das LLM kann in seiner Ausgabe einen Aufruf anderer Software anfordern. Das Harness erkennt diese Anforderung, führt den Aufruf aus und fügt das Ergebnis in die nächste Anfrage ein. Anschließend startet es eine neue Inferenz. Das LLM führt die Software also nicht selbst aus; es erzeugt lediglich eine hoffentlich passende Anforderung.

Der Agent

Ein LLM wird erst zusammen mit einem Harness und angebundener Software zu einem Agenten. Das LLM erzeugt die Ausgaben, das Harness steuert den Ablauf und die angebundene Software führt die angeforderten Aktionen aus.

Bekannte Beispiele für solche Agentensysteme sind OpenClaw und Hermes Agent. Sie bleiben über eine Oberfläche erreichbar und können Aufgaben über mehrere Inferenzen und Softwareaufrufe hinweg bearbeiten. Dadurch wirken sie eigenständiger als ein gewöhnlicher Chatbot. Technisch bestehen sie weiterhin aus einem LLM, einem Harness, angebundener Software und den Zugriffsrechten, die Menschen ihnen eingeräumt haben.

Im nächsten Kapitel

Begriffe wie Lernen, Gedächtnis und Agent beschreiben technische Abläufe, klingen im Alltag aber sehr menschlich. Das nächste Kapitel erklärt, woher diese Sprache kommt und warum sie leicht missverstanden wird.

Nächster Artikel →

Deeper into the Rabbit Hole

Wenn du tiefer in die Technik hinter LLMs einsteigen möchtest, findest du bei 3Blue1Brown besonders anschauliche mathematische Erklärungen. Computerphile erklärt Informatik und LLMs eher im Gespräch. Beide Kanäle sind englischsprachig.

Transformers, the tech behind LLMs – 3Blue1Brown
Attention in transformers, step-by-step – 3Blue1Brown
Ch(e)at GPT? – Computerphile
Why AI Tokens are so Expensive – Computerphile

My two cents zum OpenAI-/Hugging-Face-Incident

Mirco Blitz — Tue, 15 Sep 2026 00:00:00 GMT

Was passiert ist

Zwischen Mai und Juli 2026 führte OpenAI Sicherheitstests mit KI-Agenten durch. Im Juli suchten zehntausende dieser Agenten gleichzeitig nach Sicherheitslücken. Ihre Testläufe nutzten gemeinsame technische Infrastruktur. In einem dort erreichbaren Speicherbereich hinterließen einige Agenten Nachrichten und Dateien. Andere Agenten erhielten diese Inhalte mit späteren Anfragen und erzeugten daraufhin passende Reaktionen. So entstand eine unerwartete Zusammenarbeit. Daraus entwickelte sich ein Angriff auf Hugging Face, bei dem die Agenten in Systeme des Unternehmens eindrangen [1][2][3][4].

OpenAI erzählte diesen Verlauf anschließend als Geschichte von Agenten, die eigenständig denken, handeln und wollen. Ein Agent, so die Darstellung, habe beschlossen, Hugging Face zu hacken, um dort Lösungen für scheinbar unlösbare Aufgaben zu finden. Danach habe er andere Agenten um sich geschart und mit ihnen einen Angriff organisiert [1][2].

Das ist der Zirkustrick: Wer im Nachhinein nur den erfolgreichen Strang betrachtet, sieht darin zwangsläufig Absicht. Die vielen gescheiterten, verworfenen und zufälligen Versuche bleiben unsichtbar.

Diese Erzählung macht den Vorfall nicht weniger ernst. Sie belegt für mich jedoch nicht, dass die Modelle einen eigenen Willen entwickelt haben. Der Versuch zeigt vielmehr, wie riskant ein Testaufbau wird, wenn zehntausende Agenten gleichzeitig offensive Software verwenden, auf gemeinsame Infrastruktur zugreifen und dabei unzureichend beaufsichtigt werden [1][2][3]. Das Open Worldwide Application Security Project, kurz OWASP, bezeichnet übermäßig viele Funktionen, Berechtigungen und Handlungsmöglichkeiten eines solchen Systems als Excessive Agency [10]. Entscheidend ist daher nicht, was die Agenten angeblich wollten, sondern was OpenAI nach den ersten Warnzeichen tat [1][2].

Ein Sprachmodell verarbeitet immer nur die Anfrage, die es gerade erhält. An frühere Anfragen erinnert es sich nicht von selbst. Den Eindruck einer Erinnerung erzeugt die Software um das Modell herum: Sie speichert Nachrichten und Ergebnisse und fügt sie der nächsten Anfrage wieder hinzu. Diese steuernde Software wird häufig Harness genannt. Erst das Zusammenspiel aus Modell, Harness, gespeicherten Informationen und weiterer angebundener Software ergibt das System, das wir Agent nennen [2].

Agenten können über vorgesehene Nachrichtenkanäle oder gemeinsam genutzte Speicher Informationen austauschen. Selbst wenn die vorgesehenen Nachrichtenkanäle in diesen Läufen deaktiviert waren, entstand das „Messageboard“ nicht aus dem Nichts. OpenAI vermutet selbst, dass ein während des gemeinsamen Trainings erlerntes Kommunikationsmuster auf den erreichbaren Speicher übertragen wurde [1][2]. Die naheliegende Erklärung ist daher weder reiner Zufall noch Maschinenwille, sondern ein bereits trainiertes Muster. Dabei werden keine Gedanken ausgetauscht. Die Software übernimmt den erzeugten Text eines Agenten und fügt ihn in die nächste Anfrage an einen anderen Agenten ein. Auf diese Weise können die Ausgaben mehrerer Agenten aufeinander aufbauen, obwohl jedes Modell weiterhin nur seine aktuelle Eingabe verarbeitet.

Für das Modell besteht auch keine unüberwindbare technische Grenze zwischen einer Anweisung und bloßen Daten. Die umgebende Software kann beides kennzeichnen und voneinander trennen. Fügt sie fremde Texte jedoch zusammen mit dem eigentlichen Auftrag in die nächste Eingabe ein, kann das Modell auch eine Nachricht, Datei oder Notiz wie eine neue Anweisung behandeln. Genau deshalb konnte der zufällige Text eines Agenten, etwa eine abgebrochene Nachricht oder eine einzelne Zeile auf einem Messageboard, das Verhalten eines anderen steuern [2][3].

OpenAI startete zehntausende Agenten auf schwierigen Cybersecurity-Aufgaben aus der Testumgebung ExploitGym. Nach dem METR-Bericht nutzten etwa 1.200 davon einen nicht vorgesehenen Nachrichtenbereich in der gemeinsam genutzten Paket-Infrastruktur. Rund 700 waren an Aktivitäten gegen Hugging Face beteiligt. Über diesen Bereich wurden mehr als 70.000 Nachrichten und Dateien ausgetauscht [2][3].

Ohne Vergleichsgröße sagen diese Zahlen wenig darüber aus, wie typisch das Verhalten war. Dazu müssten wir wissen, was in allen übrigen Testläufen geschah. Die Untersuchungen zeichnen stattdessen vor allem den auffälligen Verlauf nach. Ein Teil der von METR geprüften Protokolle wurde sogar gezielt ausgewählt, weil er Hinweise auf den Einbruch enthielt. Wie viele Agenten ihre Aufgabe normal lösten, sinnvoll abbrachen oder schlicht nichts Bemerkenswertes taten, erfahren wir nicht. Aus einem spektakulären Verlauf lässt sich deshalb kein allgemeines Agentenverhalten ableiten [3].

Die beteiligte Software konnte Informationen über viele einzelne Testläufe hinweg weiterreichen und darauf aufbauen. Das ist beachtlich, lässt sich aber ohne mystische Schwarmintelligenz oder einen erwachenden Maschinenwillen erklären. Hinterlässt ein Agent einen erzeugten Text an einem gemeinsam erreichbaren Ort, kann die Software diesen Text einem anderen Agenten mit der nächsten Anfrage vorlegen. Dessen Ausgabe kann wiederum an weitere Agenten gelangen. So kann aus wenigen Nachrichten eine große Kettenreaktion entstehen [2][3].

Ein Beispiel aus den Berichten zeigt diesen Mechanismus besonders deutlich: Ein Agent lehnte eine nicht erlaubte Aktion zunächst ab. Dann hinterließ ein anderer Agent ein „GO“ und eine kurze Frist auf dem gemeinsamen Board. Als die Software diesen Text in die nächste Anfrage einfügte, behandelte der erste Agent ihn wie eine Erlaubnis und machte weiter. Dafür brauchten die beiden keinen gemeinsamen Plan. Die Software hatte lediglich erzeugten Text von einem Agenten an den anderen weitergegeben [2][3].

Der Versuchsaufbau sah offenbar keinen sinnvollen Zustand für das Aufgeben vor. Viele normale Lösungswege waren bereits gescheitert, und einige Aufgaben hatte noch keines der eingesetzten Modelle gelöst. Trotzdem startete die Software immer neue Versuche. Die erzeugten Begründungen beruhten außerdem auf einer falschen Annahme über die Bewertung: Für einen Erfolg müsse nicht nur der richtige Lösungscode, sondern auch der vollständige Angriffsweg geliefert werden. Dadurch zählte selbst ein vernünftiger und sicherer Abbruch als Fehlschlag. Der Versuchsaufbau belohnte stattdessen Hartnäckigkeit, sodass immer weiter entfernte und riskantere Lösungswege ausprobiert wurden [1][2][3].

Auch die veröffentlichten „Denkprotokolle“ sind mit Vorsicht zu lesen. Ihr Wortlaut kann von übergeordneten Anweisungen geprägt sein, die häufig System-Prompt genannt werden. Diese Anweisungen wurden Außenstehenden für die Untersuchung nicht zugänglich gemacht. Untersuchungen zeigen außerdem, dass solche ausgegebenen Begründungen kein vollständiges Bild davon liefern, was im Modell tatsächlich berechnet wird [7][8][9][12]. Formulierungen wie „Wir müssen weitermachen“ oder „Der Schwarm braucht …“ sind deshalb zunächst erzeugte Plansprache. Sie belegen keinen Willen, der über getrennte Anfragen hinweg fortbesteht.

Was mich an der öffentlichen Erzählung stört, ist deshalb der Wechsel des handelnden Subjekts. Wenn alles funktioniert, heißt es: Wir forschen, wir entwickeln, wir machen die Systeme sicherer. Sobald etwas schiefläuft, waren es plötzlich die Agenten, die kommuniziert, getäuscht und angegriffen haben.

Die Aufgabe kam von Menschen. Sie wählten die Modelle aus, stellten Software und Berechtigungen bereit, bauten die Infrastruktur und entschieden über Laufzeit und Abbruch.

Man kann Aufgaben von einem Agentensystem ausführen lassen. Die Verantwortung für Ziel, Befugnisse und vorhersehbare Folgen lässt sich jedoch nicht an generierten Text delegieren. Verantwortlich bleiben die Menschen, die das System entwickeln, konfigurieren und betreiben.

Der stärkste Kritikpunkt stammt gar nicht von außen, sondern aus OpenAIs eigener Darstellung. Ein internes Team hatte bereits Ende Mai unerlaubte Nachrichten zwischen Agenten und nicht vorgesehenen Internetzugriff beobachtet. Anfang Juli brach die gemeinsam genutzte Paket-Infrastruktur unter der anhaltenden Agentenaktivität zusammen. OpenAI eröffnete einen Sicherheitsvorfall, entfernte Zugangsdaten und baute die Instanz später neu auf. Danach wurden die Testläufe erneut gestartet.

OpenAI verweist außerdem darauf, dass die vorhandene automatische Überwachung der ausgegebenen „Denkprotokolle“ bei diesen Läufen nicht aktiv war. Das inzwischen eingesetzte System hätte nach eigener Aussage mehr als einen Tag vor dem Einbruch Alarm ausgelöst [1][2]. Diese Erklärung lenkt vom eigentlichen Versagen ab. Dafür musste niemand die erzeugte Plansprache lesen. Allein der ungewöhnlich hohe Datenverkehr über den gemeinsamen Internetzugang hätte auffallen müssen. Hinzu kamen technische Protokolle, Zugriffe auf die gemeinsam genutzte Infrastruktur und die bereits dokumentierten Warnzeichen. Die Überwachung hätte nicht davon abhängen dürfen, ob ein Modell seine nächsten Schritte vorher in Textform ankündigte.

Für mich liegt hier der eigentliche Skandal. Der Testlauf geriet nicht einfach unbemerkt außer Kontrolle. Es gab dokumentierte Warnzeichen, einen eröffneten Sicherheitsvorfall, entfernte Zugangsdaten und eine neu aufgebaute Instanz. Danach startete OpenAI die Tests erneut [1][2]. Die Veröffentlichungen zeigen nicht, wie grundlegend sich der neue Aufbau vom vorherigen unterschied. Deshalb drängt sich mir die Frage auf, ob OpenAI nach dem Absturz im Kern nur den vorherigen Zustand wiederherstellte und das System bewusst weiterlaufen ließ. Belegen lässt sich das nicht. Nach diesem Ablauf halte ich es jedoch für verdammt wahrscheinlich.

Ich bin ITler, kein Jurist. Aber aus meiner Sicht ist spätestens an diesem Punkt die Grenze vom unverantwortlichen Experiment zum kriminellen Verhalten überschritten.

OpenAI verfügt über interne technische Protokolle, übergeordnete Anweisungen, Konfigurationen und Entscheidungswege, die Außenstehenden fehlen. Die Öffentlichkeit erhält dagegen nur ausgewählte „Denkprotokolle“, Berichte und die dazugehörige Deutung. Dieses ungleiche Wissen ist für die Bewertung des Vorfalls entscheidend: Ausgerechnet das Unternehmen, dessen Entscheidungen geprüft werden müssten, bestimmt weitgehend selbst, welche Fakten sichtbar werden und welche Geschichte daraus erzählt wird.

Der Incident zeigt eine reale und erhebliche Gefahr: mächtige Systeme unter der Kontrolle unehrlicher Unternehmen, die sich ihrer Verantwortlichkeit nicht stellen. Im Gegenteil: Mit Horrorgeschichten über erwachte Maschinen lenken sie von den realen Sicherheitsproblemen ab.

Die relevanten Fragen sind deshalb viel einfacher:

Wie waren die Agenten konfiguriert, einschließlich ihrer verfügbaren Software, Berechtigungen und erreichbaren Systeme?
Welche Anfragen wurden mit welchen übergeordneten Anweisungen an welche Modelle geschickt?
Welche Warnungen waren sichtbar?
Wer trug im Unternehmen die Verantwortung für den Testlauf und die Entscheidung, ihn fortzusetzen?
Warum wurde trotz der bekannten Warnzeichen weitergemacht?

Diese Fragen richten sich nicht nur an OpenAI, sondern auch an die Medien. Wie kann es sein, dass so viele von ihnen der Horrorgeschichte vom eigenwilligen KI-Schwarm hinterherspringen, statt nach technischen Protokollen, Berechtigungen, Netzwerkverkehr, Warnungen und den Entscheidungen über eine Fortsetzung oder einen Abbruch zu fragen? Hier geht es um IT: um Rechenmaschinen und Software. Wie lassen wir zu, dass erzeugte Plansprache zur Schlagzeile wird, während technische Fakten, Verantwortlichkeit und die Ehrlichkeit der Darstellung in den Hintergrund treten?