KI und so – (eine Zusammenfassung)

Ich hab‘ mich in letzter Zeit mal mit KI auseinandergesetzt – oder, naja, genaugenommen mit großen Sprachmodellen und generativer KI (also alles um das Thema „LLM“), was eigentlich nur einen kleinen, aber in letzter Zeit ziemlich in den Vordergrund getretenen Teil von dem ausmacht, was mit „KI“ (bzw. „AI“) bezeichnet wird. Und ich muss sagen: yep, bei aller Skepsis und allen Bedenken – geiler Sch🛎️s.

Vorab vielleicht ein paar Links, für die, die einfach mal loslegen wollen:

Claude bzw. „Claude Code“ (bei der Programmierung derzeit tonangebend): https://claude.ai/new
Mistral AI („Vibe“ – der bisher einzige europäische, echte Tiger im Käfig): https:// chat.mistral.ai/
ChatGPT (der universell einsetzbare Klassiker): https:// chatgpt.com/
Lumo AI (Auch in Europa (Schweiz) angesiedelt – spezialisiert auf Vertraulichkeit): https://lumo.proton.me/guest
DALL-E (auf Bildgenerierung spezialisiert): https://www.dall-e-free.com/

[~~Die vorliegende Version hier ist vom 8.7.2026, 11:00~~]
[Die vorliegende Version ist vom 09.07.2026, 13:00 (Ergänzung MTP im Abschn. „Bezeichnungssdetails“)]

Bei den grauen, in einer kleineren Textgröße gehaltenen Abschnitten, handelt es sich um Zusatzinfos oder Anmerkungen von mir, die im Sinne des eigentlichen Themas nicht unbedingt weiterführen. Wenn Du nicht zu viel Komplexität auf einmal präsentiert bekommen möchtst, empfiehlt es sich, die erst mal zu ignorieren.

Worum geht’s?

KI klingt im ersten Ansatz erst mal echt kompliziert – und tatsächlich ist sie das auch. Aber die Anwendung ist eigentlich total einfach. Es reicht, irgendeine Sprache halbwegs fließend zu beherrschen und irgendein Anliegen zu haben, das eine Maschine, die mit unserer realen Welt nur sehr mäßig, aber mit der Welt der Informationen und Daten, der Welt des reinen Wissens, der Algorithmen, der Logik (obwohl … naja, zumindest grob …) und ggf. dem Internet intensiv vertraut und super vernetzt ist, lösen kann.

Anwendungsfälle

Beispiele:

Eine neue Webapplikation auf Basis von bestehenden Frameworks, aktuellen Standardtechniken, strengen Clean-Code-Regeln und wenig Zeit zusammenkloppen: krass guter Anwendungsfall.✅
Detail-Informationen zu einem Fachgebiet, wovon Du nur mäßig Ahnung hast, wo sie aber von Dir wollen, dass Du für sie ’ne Webapplikation baust, zusammensuchen, auf Deinen Anwendungsfall einkochen und unter Beachtung deines aktuellen Horizonts darstellen lassen, um auf der Basis schnell zu lernen, mit den Leuten im Sinne von DDD fachlich ordentlich kommunizieren zu können: 1-A Anwendungsfall.✅
Du hast ’nen Satz total verwirrter Excel-Tabellen und willst die so zusammenbringen, dass Du daraus bestimmte Informationen ablesen kannst, hast aber zu wenig Erfahrung, wie man das automatisiert oder schlicht keinen Bock Dir die Mühe zu machen und hast außerdem Zeitdruck, weil Cheffe das wieder gestern haben will: mit der kleinen Einschränkung, dass Du der KI wahrscheinlich recht genau schildern musst, was Du eigentlich von ihr willst – ein Super Anwendungsfall.✅
Planst Du gerade ein neues Sport-, Freizeit- oder Einkaufszentrum und brauchst Unterstützung bei rechtlichen, planerischen, projektleiterischen, kommunikativen, die Software oder die Projektmanagementmethode bzw. das -Framework betreffenden Fragen, oder willst Du gar Teile deiner Arbeit an einen willfährigen Helfershelfer auslagern: guter bis sehr guter Anwendungsfall✅, aber immer bedenken: die Maschine ist fehlbar und merkt nicht, wenn sie Bullshit labert – Vertrauen ist gut, Kontrolle ist besser! Insbesondere bei allem, was Sicherheitsaspekte angeht (z.B. geologischen, geomorphologischen, hydrologischen, bauphysikalischen oder feuerpolizeilichen Fragestellungen), würde ich im Zweifel immer einen kompetenten Menschen hinzuziehen!
Dumme Fragen beantwortet kriegen wollen, aber zu faul sein, im Internet rumzugoogeln um erst mal die richtigen Fachwörter zu finden und anschließend bei Wikipedia Artikel querzulesen: durchaus brauchbarer Anwendungsfall✅ (Google schickt ja bereits von sich aus inzwischen bei den meisten Anfragen die KI los).
Ähnliche Problematik, aber dem Internet keine Kenntnis darüber geben wollen, dass man aktuell diese dummen Fragen hat: etwas komplizierterer, aber durchaus lösbarer Anwendungsfall.✅(mit lokaler KI oder evtl. Lumo)
Ein altes Bewerbungsfoto ohne zum Fotografen zu gehen aktualisieren und ggf. etwas aufhübschen lassen: kommt drauf an. ✔
(Warum die Einschränkung? Naja – um das lokal zu machen bedarf es schon einiger Rechenpower und hinreichendem Fachwissen. Bleibt also nur online. So rein aus der Erfahrung: Mistral AI kann man bei dem Anliegen eher vergessen. ChatGPT liefert ganz ordentliche Ergebnisse, aber wenn man selbst eine recht genaue Vorstellung hat, wie das Ergebnis aussehen soll, sind das schon mehrere Schleifen, die man mit der KI drehen muss, und am Ende bin ich hingegangen und hab das Ergebnis noch händisch zurechtgefruckelt – zumal ich aus dem Umsonst-Volumen raus war. Vielleicht hätte eine spezialisiertere KI mir schneller oder besser geholfen. Am Ende war es zwar billiger als ein Besuch beim Fotografen und ich hatte relativ exakt das, was ich mir vorgestellt hatte, aber weniger Zeit habe ich da definitiv nicht reingesteckt (andererseits ist nach einer Stunde Foto-Session und 80 Euro Guthabenabfluss keineswegs sichergestellt, dass da ein brauchbares Bewerbungsfoto bei rauskommt …))
Für kommendes Wochenende eine Reise an die Küste planen und dafür Wetterbedingungen und Autobahnbaustellen raussuchen lassen: eher nicht ❌
das mit dem Wetter in der Zielregion kriegen die Dinger per Webrecherche noch halbwegs in den Griff, aber die Route dahin überfordert die meiste generative KI bereits, (evtl. weil sie nicht hinreichend mit Geo-Daten gefüttert ist, aber wenn Ihr Euch weiter unten anschaut, wie LLM-KIs zu ihren Ergebnissen kommen … ich denke, das ist einfach auch strukturell kein guter Anwendungsfall – da müssen dann Spezialisten wie Google Mops und so ran). Auch was die Vorstellung der Räumlichkeit und der Bewegung im Raum angeht, zeigen sich sogar bei großen, aktuellen Modellen Grenzen. Das wäre auf jeden Fall etwas, wo man diverse Schleifen mit der KI machen müsste und selber relativ viel Intelligenz reinstecken muss (z. B. erst mal die Route bei Google holen und für die KI aufbereiten) … lohnt sich aktuell noch nicht so richtig

Man kann es vielleicht auf folgende ungefähre „Formel“ einkochen:

Ist die Information grundsätzlich relativ statisch, schon seit einigen Monaten oder besser Jahren in der Welt und hat es nichts mit
⛔ sehr aktuellen,
⛔ nur regional relavanten,
⛔ dynamischen (z.B. Wetter),
⛔ schwer vorhersagbaren (z.B. menschlichem Verhalten),
⛔ sich vor allem in der realen Welt abspielenden
Szenarien zu tun, ist KI Dein Freund. Alles andere ist eher mühsam oder geht gar nicht.

Ich habe weiter unten dazu auch noch mal einen etwas ausfühlicheren Abschnitt „Was (derzeitige, LLM-basierte) KI nicht leisten kann“.

Rüstzeug für den Umgang mit / das Sprechen über KI

Mein Kernanliegen ist in diesem Beitrag weniger die praktische Anwendung – das ist zum einen bei den ersten Schritten völlig trivial, zum anderen hab ich dazu noch nicht so viel gesammelt, dass ich mich da zum Lehrer aufschwingen wollen würde, und zum dritten gibt’s dafür bereits x Tutorials und Videos da draußen – sondern eher, das Ausleuchten der Grundlagen, was ich so bisher noch nirgends in einer Tiefe, die mich zufriedengestellt hätte, gefunden habe. Mir geht’s darum, dass Leute wissen, was in dieser Art KI abläuft, dass sie nachvollziehen können, warum manche Sachen gut und manche Sachen schlecht funktionieren, und dass sie das Basisvokabular und die nötige Sachkenntnis bekommen, selber mit lokaler KI (auf dem eigenen Rechner) ein bisschen herumzuexperimentieren. Wenn ich so weit bin, über selbst programmierte Agenten, MCP, RAG und solche Sachen etwas zu erzählen, reiche ich einen Beitrag nach – das kommt hier noch nicht vor.

Ich baue das mal weitestgehend im Stil eines Glossars auf, wobei die Einträge aber von oben nach unten aufeinander aufbauen.

(gleich am Anfang kommt etwas schwere Kost … das mit den „Token“ würde ich auf jeden Fall mitnehmen, wer aber gar nicht so genau wissen will, was es mit Vektoren und Tensoren oder neuronalen Netzen auf sich hat, darf das gerne erst mal überspringen.)

Token

Eigentlich steht dieser Begriff „Token“ viel weiter hinten in der Hierarchie des nötigen Wissens, aber ich verwende ihn an so vielen Stellen, dass ich einfach mal vorab eine Kurzversion dazu bringe.

Ein Token ist die kleinste Einheit, die ein LLM (im Textverarbeitungsmodus) verarbeitet. Wenn ich jetzt „Token“ und „Wort“ gleichsetze, dann ist das zwar nicht korrekt, aber auch nicht wirklich schlimm falsch. Für’s erste Grundverständnis ist das vollkommen OK.

In Wahrheit ist ein Token kleiner als ein Wort. Im Deutschen ist das Verhältnis zwischen Token und Wort ungefähr 4:3, also 3000 Worte entsprechen in etwa 4000 Token. Im Englischen entspricht ein Token häufiger einem Wort als im Deutschen.

Auf eine DIN-A4-Seite passen je nach Formatierung bei Schriftgröße 12 zwischen 250 und 500 Wörter, also über den Daumen: 500 Token sind eine DIN-A4-Seite, 1K Token ungefähr zwei. Das deutsche Grundgesetz kommt auf knapp 40.000 Token (also knapp 40„K“).

In Wahrheit geht es also nicht um Wörter, sondern um etwas, das eher dem Konzept der „Morpheme“ aus der Linguistik (kleinste bedeutungstragende Einheiten bzw. Buchstabenkombinationen) nahekommt – Bruchstücke von Wörtern.

Im Deutschen ist das vielleicht relevanter, weil wir mehr grammatischen Schnickschnack verschriftlichen (ich mache, du machst, er macht, wir machen, ihr macht, …), relativ ausgiebig mit Vorsilben hantieren (vorstellen, nachstellen, überstellen, unterstellen, aufstellen, einstellen, abstellen, erstellen, bestellen, zer … äh … na … Prinzip klar, denke ich) und generell relativ lange Wörter haben. Allerdings hängt das Erstellen von Token nicht zwangsläufig an solchen Kategorien.

Außerdem spielen IDs, Übersetzungstabellen und Vektoren hier eine Rolle – aber das ist für den Anfang erst mal nebensächlich.

Vektoren und Tensoren

Keine Angst – ich bin selber nicht der größte Experte in dem Thema und mach’s kurz und simpel. Man muss diese Wörter auch nicht unbedingt verstehen, um mit KI umgehen zu können, also wer sich das ersparen will – kein Problem, einfach weiterscrollen – aber ich bringe die Begriffe weiter unten mehrfach und will auch den Laien die Chance geben, das jeweils nachvollziehen zu können.

Ein Vektor (manchmal auch „Array“) ist ganz plump gesagt eine sortierte Liste von Zahlen. „Sortiert“ meint hier allerdings nicht so was wie „ansteigend“, sondern so etwas wie „hat an derselben Stelle dieselbe Bedeutung“.

Ich geb mal ein Beispiel für die Leute, die sich das noch so gar nicht vorstellen können. Stell Dir eine Palette mit gleichmäßig nebeneinander und hintereinander darauf gestapelten, kleinen, jeweils gleich großen Kartons vor (also einer genau auf dem anderen – würde man in Wirklichkeit nicht so machen, ich weiß, aber es ist nur ein Gedankenexperiment). Die untere Lage bildet ein Quadrat von meinetwegen 10×10 Kartons, und dann sind weitere 9 Lagen Kartons darüber gestapelt. Jetzt schickst Du den/die Azubi mit einem Zettel los, um aus einem ganz bestimmten Karton etwas zu holen. In dem Fall macht es Sinn, wenn ihr im Betrieb für so einen Fall vereinbart habt: wenn auf dem Zettel „6-3-8“ steht, ist damit der 6. Karton von Links in der 3. Reihe von vorne in der 8. Lage von unten gemeint. „6-3-8“ ist damit ein Vektor, und zwar einer mit 3 „Feldern“ (eigentlich wäre das korrekte Wort hier „Dimensionen“, aber das führt m.E. eher zu Verwirrungen, deswegen weiche ich da mal auf das Wording für Arrays aus, wie es in der angewandten IT üblich ist).

Man kann das ganze jetzt verkomplizieren und etwas von euklidischen Räumen, Koordinaten, Pfeilen, Nachkommastellen (dass oben im Beispiel nur ganze Zahlen vorkommen ist ein Sonderfall) und Blablabla erzählen, aber das Grundprinzip bleibt dasselbe.

Allerdings geht es bei den Vektoren, über die wir hier reden, nicht um 3 sondern um sehr viel mehr Zahlen (bzw. Felder) und es geht nicht um Kartons, sondern um so etwas wie „Eigenschaften“ oder „Merkmale“, aber auch hier gilt: eine Zahl an einer bestimmten Stelle (in einem bestimmten Feld) im Vektor bezieht sich jeweils auf immer dieselbe Eigenschaft.

Ein Vektor mit 1000 Feldern könnte z.B. so aussehen (die Zeilenumbrüche sind dem Platzmangel geschuldet – eigentlich gehören alle Zahlen in eine Zeile):

Um das zu verstehen, muss man sich vielleicht (zumindest für’s erste) etwas von dem räumlichen Verständnis, das oft mit dem Thema Vektor assoziiert ist, lösen. Es geht erst mal tatsächlich nur um eine Liste von Zahlen, bei der lediglich jeder Listenposition eine feste Bedeutung zugeordnet ist.

Ein Tensor ist einem Vektor nicht unähnlich. Tatsächlich ist ein Vektor ein Tensor vom „Rang“ 1 (aber das ignorieren wir im Weiteren mal einfach). Wenn Du Dir jetzt statt einer einfachen Reihe oder Spalte (man kann Vektoren horizontal oder vertikal notieren) eine Tabelle mit Zahlen drin vorstellst, also mehrere gleich lange Vektoren über- oder nebeneinander, bist Du im Grunde schon bei einem Tensor 2. Ranges (im Matheunterricht ist so etwas eine „Matrix“ ). Im Bild rechts sieht man so etwas in symbolischer Schreibweise. Ein Tensor 3. Ranges wäre unser obiges Karton-Beispiel (wenn wir jetzt mal seinen ursprünglichen Sinn vergessen), wenn in jedem dieser Kartons eine Zahl drin wäre, also eine 3-dimensionale Anordnung von Zahlen, ein Zahlenwürfel oder -quader. Man kann das Spielchen im Grunde beliebig weitertreiben, aber dann wird’s mit der Vorstellung langsam kompliziert. Reicht aber so auch erst mal.

Bei LLMs bzw. heutiger KI spielen (bei den „Gewichten“) vor allem Tensoren 2. Ranges und 3. Ranges eine Rolle. Und es spielt eine Mathematik eine Rolle, bei der Vektoren und Tensoren miteinander multipliziert (oder in dazu ähnlicher Weise miteinander „verknüpft“) werden. Auf die Details gehen wir jetzt nicht weiter ein. Wichtig ist: dabei geht vorne ein Vektor rein und hinten kommt ein veränderter Vektor raus, wobei die Anzahl der Felder i.d.R. gleich bleibt.

Neuronales Netz

Ein neuronales Netz (NN) ist – bildlich gesprochen – eine in den elektronischen, digitalen Raum übertragene Analogie zu Nervenverbindungen, wie sie in Gehirnen vorkommen (bzw. eine vereinfachte Variante davon).

Dabei gibt es – konzeptuell – „Knoten“ bzw. „Nodes“, die die Nervenzelle repräsentieren (oft als kleine Kreise dargestellt), und Verbindungen dazwischen (meist als Linien dargestellt), die die Verbindungen zwischen den Nervenzellen symbolisieren – und zwar in unserem Fall hier gerichtete Verbindungen jeweils von einer Node-Schicht (einem „Layer“) zur nächsten, denn ein NN besteht aus vielen Schichten von Nodes (wem es hilft: ähnlich zu gestapelten Eierpaletten), wobei zu jedem von ihnen mehrere Verbindungen aus der vorgelagerten Schicht eingehen und Verbindungen zu mehreren Nodes in der Folgeebene von ihnen ausgehen.

Die Anzahl der Nodes pro Schicht kann gleich sein, muss es aber nicht zwingend, so dass ein NN am „Anfang“ u.U. viel mehr Nodes hat, als am „Ende“.

Das Bild zeigt Schematisch ein Beispiel für ein Neuronales Netz mit drei Eingängen, drei Zwischenlayern und einem Ausgangsknoten

Simples Beispiel für ein neuronales Netz – Die Daten fließen hier von links nach rechts – die Layer stehen senkrecht.

Die Nodes repräsentieren den Datenzustand in einer bestimmten Schicht des Netzes. Jeder Node steht also für einen Vektor, denn „Daten“ sind an dieser Stelle der Geschichte und in unserem speziellen Fall Vektoren.

Die Linien (also die Verbindungen) symbolisieren technisch gesehen die Tensoren (s.o.), über die der Vektor des einen Knoten in einen neuen Vektor umgerechnet und an den nächsten Knoten weitergereicht wird, die Linien stellen also im Grunde Rechenschritte dar. Die Rechenvorschrift ist immer dieselbe, aber der Tensor ist für jede Verbindung individuell. Diese Tensoren nennt man die „Gewichte“ (Weights) oder „Parameter“ des NN, und sie machen den größten Teil bei der Definition eines NN aus.

Die Nodes repräsentieren, wie gesagt, Daten bzw. Vektoren. Allerdings ist das nicht die ganze Wahrheit. Quasi am „Eingang“ jedes Nodes findet noch mal Mathematik statt (allerdings immer (?) dieselbe, so dass man dafür nicht endlose Zahlenreihen speichern muss). Ob ein Node überhaupt auf einen Dateneingang „reagiert“ und seinerseits einen Vektor weiterreicht (im Fachjargon: ob er „feuert“), bestimmt eine Aktivierungsfunktion. bleibt deren Ergebnis unter einem bestimmten Schwellenwert, ist der Node für den aktuellen Durchlauf (Inferenzschleife – kommen wir auch noch zu) raus. Da fast immer mehrere eingehende Verbindungen ankommen, muss außerdem irgendeine Form von Summe oder Durchschnitt gebildet werden (muss ich noch rausfinden, ist aber für uns auch nicht so entscheidend).

Wie schon beschrieben sind die Verbindungen zwischen den Nodes „gerichtet“, außerdem reden wir hier von reinen Feed-Forward-Netzwerken, was bedeutet: die Information – also letztendlich die Vektoren – durchlaufen das Netz streng „vom einen Ende zum anderen“ (von oben nach unten oder links nach rechts – das ist ganz Deiner Vorstellung überlassen). Es gibt auch andere Fälle, aber die spielen hier keine Rolle.

OK – das war jetzt schon reichlich schwere Kost, zugegeben. Aber der Vollständigkeit halber: tatsächlich gibt es in keinem Rechner der Welt irgendeine Struktur, die dem nahekommt. All das wird rein „virtuell“ erzeugt. Das gedachte Konzept wird in Form von ablaufenden Algorithmen, Reihenfolgen und Hilfskonstrukten zum Leben erweckt. Es ist alles reine Mathematik. Alles, was ich oben erklärt habe, ist letztlich nur eine Krücke, eine Denkhilfe, damit Menschen sich das Konzept vorstellen und weiterentwickeln können. Die Wahrheit sind unendliche Ströme von Zahlen, die durch Rechenoperationen gepumpt werden. Irre Vorstellung, oder?

Und vielleicht das noch: man könnte auf die Idee kommen, die hier beschriebenen „Verbindungen“ im Sinne der (Schul-)Biologie mit einzelnen Zweigen von „Dendriten“ bzw. den Synapsen an deren Ende zu assoziieren, aber der Vergleich hinkt aus verschiedenen Gründen – befassen wir uns, wenn gewünscht, weiter unten auch noch mit, führt aber aus dem eigentlichen Thema ziemlich weit raus. Grundsätzlich würde ich vom unmittelbaren Vergleich der Konzepte abraten, da man sich damit leicht in eine Argumentationshölle ungeahnten Ausmaßes begeben kann.

Transformer

Transformer sind der Wissensspeicher, auf dessen Basis der „Denkapparat“ arbeitet. Sie bilden die Grundlage, auf deren Basis KIs ihre Schlussfolgerungen ziehen.

Es handelt sich dabei um eine auf bestimmte Art strukturierte Form von neuronalen Netzen, in denen Layer, Header, Hidden Layer und so abgefahrene Sachen wie „Aufmerksamkeit“ (Attention) vorkommen. In Transformern gibt es – wie oben schon angedeutet – keine Verbindungen innerhalb derselben Ebene oder zurück auf die nächsthöhere Ebene (anders als zum Beispiel im Gehirn von Menschen oder bei anderen KI-Architekturen). Es sind also reine Feed-Forward-Netzwerke.

Wichtig ist dabei zu verstehen: diese rein auf Zahlen fokussierte Struktur ist es, die das eigentliche „Verstehen“ von Eingangsdaten und das Generieren neuer Daten bewerkstelligt. Weit und breit kein „Wort“, keine „Bilder“ im Kopf (womit das Thema „Konnotation“ allerdings nicht abgefrühstückt ist – aber die Diskussion darüber ist an dieser Stelle des Beitrags noch nicht führbar) und keine Fähigkeiten, wie simple Addition oder gar Multiplikation … einfach nur: da kommen links (oder oben) Zahlenreihen rein und rechts (oder unten) gehen Zahlenreihen raus – ein elektronisches Bauteil, das aufgrund seiner Verdrahtung aus einem Eingangssignal ein Ausgangssignal macht. Wenn die KI bzw. der Transformer nicht „auswendig gelernt“ hat (s.u.), was 365×24×3600 ist, ist die Frage nach dem Ergebnis für eine KI enorm schwer (z.B. über Interpolation bekannter Ergebnisse) bis gar nicht zu beantworten.

Man könnte noch viel mehr zu dem Thema sagen, aber dann wird’s echt schon recht tiefgründig, vieles davon (z. B. die recht essenzielle „Attention“ – die Aufmerksamkeitsmechanismen) kommt sowieso noch weiter unten und für den Hausgebrauch reicht das zu dem Thema erst mal.

Generative KI

KI, die auf Basis von vorliegenden Daten neue Daten „generieren“ kann – zum Beispiel (aber nicht ausschließlich) Texte oder Bilder – und inzwischen oft beides in beiden Richtungen.

Vortrainiert / Pre-trained

Ein neuronales Netz zu „trainieren“ bedeutet: Leute setzen sich hin und „füttern“ es – also in unserem Fall einen Transformer – mit einer irren Menge an Daten, wobei immer wieder überprüft wird, ob der Transformer zu bestimmten Eingangsdaten korrekte Ausgangsdaten liefert. Anschließend wird jedes mal eine ziemlich aufwendige Mathematik angewendet („Backpropagation“– Algorithmen), um die Tensoren, also die Nervenzellen-Verbindungen bzw. Gewichte, immer besser zu justieren. Das Training ist also die „Lernphase“ für einen Transformer.

Tatsächlich müssen sie aber irgendwann damit aufhören und diesen Trainings-Modus beenden, weil der Transformer sonst überangepasst wird – es käme zum sogenannten „Overfitting“. Damit ist gemeint, dass das Modell zu stark auf die Trainingsdaten spezialisiert ist und auf weitere Eingaben schlecht „generalisiert“, sprich: der Fokus auf die Mustererkennung geht verloren – das Model tendiert dann dazu, jeden Einzelfall in seinen Gewichten abzubilden: das Muster verblasst und wird nur noch schlecht erkannt.

Ganz plump formuliert könnte man vielleicht sagen: der Transformer wird „gaga“, wenn man ihn zu lange und zu eintönig mit Daten füttert..

Auch das ist bei aktueller KI eine sehr entscheidende Tatsache: in der Anwendungsphase ist der Trainingsmodus abgeschaltet! Im laufenden Betrieb lernt eine KI nicht mehr „dazu“! (Stattdessen werden korrigierende Hinweise von Usern alle Nase lang ausgewertet und fließen in neue Model ein. Oft werden bestehende Model auf dieser Basis auch „nachtrainiert“ oder ganz neu trainiert, so dass sie dann halt doch irgendwie dazulernen – aber eben in einem kontrollierten, gesteuerten, periodisch stattfindenden und in sich abgeschlossenen Prozess, nicht wie Menschen permanent und „on the fly“, also im laufenden Betrieb).

„Gefühlt“ wird diese Aussage dem einen oder anderen aufgrund seiner Erfahrungen „falsch“ vorkommen. Allerdings gehört das dann eher in das Thema „Kontext“ (s.u.). Es sieht für den jeweiligen Nutzer aufgrund des durch die Korrektur entstandenen Kontexts lediglich so aus, als hätte die Maschine dazugelernt. Aber an den Parametern hat sich nichts geändert.

Und jetzt die Überraschung: da das Training vor der Anwendungsphase stattfindet und abgeschlossen ist, ist der Transformer anschließend „vortrainiert“ bzw. „pre-trained“.

GPT steht übrigens für „Generative Pre-trained Transformer“.

Kleine Ergänzung am Rande, falls jemand sich nicht vorstellen kann, wie das dann dazu führen kann, dass man damit eine Form von „Wissen“ erzeugen kann. Ich stelle mir als Analogie dazu Hologramme vor. Dort steckt die eigentliche Information auch nicht in einzelnen, expliziten Bildern, sondern sie ergibt sich aus der Überlagerung von Lichtwellen aufgrund von Mustern, die auf den ersten Blick (etwa mit einem Mikroskop) mit den ursprünglich aufgenommenen Gegenständen nicht das geringste zu tun haben. Ein Hologramm ist zudem flach und „erinnert“ sich trotzdem an 3-dimensionale Informationen. Tatsächlich kann man in einem einzigen Hologramm, wenn man unterschiedliche Lichtwellenlängen verwendet, sogar deutlich mehr als nur ein 3D-Bild speichern. Die Gewichte bzw. Tensoren, die ja obendrein jeweils aus einer Kombination von vielen Zahlen bestehen, liefern quasi je nach Blickwinkel und Lichtwellenlänge – quatsch – natürlich je nach verschiedener Kombination von eingehenden Informationen andere „Wissensbilder“ aus (das ist noch nicht die ganze Wahrheit, weil die Attention da auch noch eine wichtige Rolle spielt – aber um eine Idee von der Sache zu kriegen hilft’s vielleicht.)

Gewichte (Weights) / Parameter

Zwei andere Wörter für die „Verbindungen“ oder „Tensoren“, oder anders gesagt: im Sinne von KI sind Gewichte, Parameter, Verbindungen und Tensoren alle im Grunde verschiedene Wörter für dieselbe Sache.

Wie viele Parameter der Transformer eines bestimmten Sprachmodells hat, wird in „B“ angegeben – gemeint sind englische „billions“, also zu Deutsch „Milliarden“. Der Transformer eines LLMs mit „7B“ hat also 7 Milliarden Nervenzellen-Verbindungen bzw. Parameter bzw. Gewichte bzw. Tensoren.

Die größten aktuell in Betrieb befindlichen LLMs haben zwischen 700 und 1000B, also knapp 1„T“.

Ein menschliches Hirn hat übrigens etwa 86 Milliarden Nervenzellen, wovon etwa 69 Milliarden auf das Kleinhirn und 16 Milliarden auf den Cortex entfallen (und eine Milliarde auf sonstige Sachen). Eine Nervenzelle hat größenordnungsmäßig etwa 10.000 Verbindungen zu anderen Nervenzellen. Im Cortex sind es tendenziell eher mehr als weniger. Das „Denken“ findet primär (aber nicht ausschließlich) im Cortex statt. Hätte das Gehirn also die Struktur heutiger Transformer (was es nicht hat – die Verzweigung ist viel komplexer!), so hätte allein sein für das rationale Denken und die Eingangsdatenverarbeitung zuständiger „Transformer“ wohl irgendwas um die 200.000B (quasi 200T).

Hier hatte ich daraus dann ursprünglich Schlussfolgerungen gezogen, die sich aber – nachdem ich mich noch mal damit auseinandergesetzt habe – so nicht halten lassen, zumal ich mit einem rein auf Sprache fokussierten Vergleich dem Gesamtbild moderner KI wahrscheinlich keineswegs gerecht werde. Ich habe mal Claude auf das Thema losgelassen und die – wie ich finde – beeindruckende Antwort unten als Anhang ergänzt. Die Frage der Vergleichbarkeit wird zwar auch da nicht abschließend geklärt, aber die Komplexität der Fragestellung wird zumindest gut ausgeleuchtet. Am Ende muss sich wohl vorerst jeder eine eigene Meinung leisten und die Aspekte eines solchen Vergleiches einer eigenen Bewertung unterziehen. Ich bin abschließend immer noch der Meinung, dass menschliches Denken über einen komplexeren Denkapparat verfügt, als (einzelne Instanzen) moderner KI, aber rein von den Ergebnissen her ist es freilich schwierig, dort nicht eine gewisse Steilheit der These zu erkennen…

LLM / Sprachmodell

Ein „Large Language Model“ (LLM) bildet den Kern einer KI.

Es besteht aus:

dem Transformer – dem eigentlichen „Wissensspeicher“
der Übersetzungslogik zwischen „natürlicher“ Sprache und der im Transformer vorherrschenden Mathematik (der Transformer bekommt und liefert eine lange Liste von Vektoren – weder der Buchstabe A noch das Wort „Apfel“ sagen einem Transformer an sich irgendwas) und
einer speziellen Datenbank, die für diese Übersetzung notwendig ist (und die zusammengestellt wird, bevor der Transformer damit trainiert wird)

Die Übersetzungsdatenbank stellt das „Vokabular“ des LLMs dar.

Tatsächlich darf man sich von dem Wort „Language“ in LLM (oder dem Teilwort „Sprach“ in Sprachmodell) hier nicht verwirren lassen: das Modell abstrahiert nicht eine bestimmte Sprache, sondern semantische Zusammenhänge von Wörtern (oder genau genommen Token) als wilde, bisher im Grunde von außen undurchschaubare Sammlung bzw. Liste von Zahlen (also „Vektoren“), und die sind – mehr oder minder – universell.

Im „Vokabular“ wiederum stecken fast immer Token aus ganz vielen Sprachen (selbst bei den kleinen, lokalen Models).

Das Modell ist deshalb (meistens) nicht auf eine bestimmte, natürliche Sprache festgelegt. Tatsächlich beherrschen die allermeisten der modernen LLMs diverse Sprachen – Englisch und die großen Verkehrssprachen wie Chinesisch, Arabisch und Spanisch quasi immer, meistens auch Russisch, Französisch und Portugiesisch, und in den allermeisten Fällen sind selbst Exoten wie Italienisch, Polnisch, Niederländisch oder Deutsch dabei. Ich habe mindestens ein Modell gesehen, das sich damit rühmt, auf über 200 Sprachen und Dialekte trainiert zu sein (Qwen3.5/3.6)!

Die Erfahrung zeigt allerdings, dass die Unterstützung von Deutsch qualitativen Einschränkungen unterliegt. Viele kleinere Modelle kriegen das mit der Grammatik oder den korrekten Präpositionen nicht wirklich konsequent und zu 100 % optimal auf die Kette, und bestimmte idiomatische Redewendungen kommen einem gelegentlich ein bisschen chinesisch vor. Selbst die ganz Großen sind nicht immer zu 200 % perfekt (aber schon verdammt gut – manchmal überliest man selbst als Muttersprachler kleinere Fehlerchen).

Modell / Model

Dasselbe, nur einmal deutsch und einmal englisch. Sorry – ich haue das hier, glaube ich, regelmäßig wild durcheinander.

GGUF

Ein Dateiformat, mit dem sich LLMs „transportieren“ lassen – eine GGUF-Datei enthält die Parameter und die Konfiguration des Transformers, die Token-Datenbank und die Übersetzungslogik.

Inferenz / Schlussfolgerungsschleife

Der Vorgang, bei dem Stück für Stück auf Basis von bestehendem „Wissen“ weitere Information „generiert“ wird. In Wirklichkeit sind Inferenzmaschinen an sich für das nicht mathematisch geschulte Hirn schon relativ grenzwertige Verständnisbereiche – tatsächlich handelt es sich aber im Grunde um in Schleifen ablaufende Logik-Algorithmen, die auf Basis einer bestehenden Abfolge von Token („Wörtern“) unter Verwendung des Transformers und in Abhängigkeit von sich daraus ergebenden Wahrscheinlichkeiten für eine Auswahl „nächster“ Token die Abfolge logisch ergänzen können (sie wählen dabei eines von diesen „wahrscheinlichsten“ Token aus).

Inferenz ist quasi der kreative Prozess bei der generativen KI.

Hört sich irre kompliziert an (ist es in Wirklichkeit auch), bedeutet aber allgemeinverständlich, dass Inferenzmaschinen im Grunde bloß permanent Rätsel nach dem Muster „Morgenstund hat Gold im Mun_ – bitte ergänzen Sie“ lösen.

Ich fand das im ersten Ansatz überraschend billig und desillusionierend, war aber am Ende umso überraschter davon, was damit alles geht.

Reasoning

Das Reasoning (hier in etwa „logisches Denken“), auch „Chain of Thought“-Reasoning, ist ein optionaler Unterprozess der Inferenz. Im Grunde betreibt wahrscheinlich jedes Sprachmodell – oder eigentlich seine Runtime – ein gewisses Maß an Reasoning während der Inferenz. Allerdings basiert Reasoning seinerseits auf der Durchführung von Inferenz – anders gesagt: jedes Reasoning beinhaltet Inferenz, aber nicht jede Inferenz beinhaltet Reasoning.

Das Reasoning leitet zunächst erste Erkenntnisse aus den Eingangsdaten ab (z. B. „User has asked in german – I should answer in german, too.“).

Tatsächlich kann man vielen Modellen beim „Denken“ (also effektiv beim Reasoning) zuschauen. Sie zeigen quasi ihren „inneren Denkdialog“ an – zum Beispiel:

Instead of just listing facts, I should frame biology in terms familiar to a developer:

* DNA = Data Storage (Hard drive/DB).
* Genes/Proteins = Business logic / Functional units.
* Genomics = Systems Engineering (Scalability, normalization, pipeline design).
* **Concept 1: The "Scale" Problem.** DNA is not just a string; it's an enormous dataset that needs structured management. This links to their SQL/PHP background.
* **Concept 2: Data Normalization & ETL (The core of the job).** Explain that bioinformatics is essentially "data engineering for biological systems".
* **Concept 4: Specific Terminology for the Cover Letter.** Give them keywords to use instead of "I know what a base triplet is".

* **Step 1: The Mental Model Transition.**

* DNA as the Storage Layer (The "Data" in Bioinformatics).
* Genetics/Genomics as the Scale Problem.

* **Step 2: Deep Dive into Concepts (Technical Bridge).**
* *Nucleotides & Base Pairs:* The data types and structures.
* *Codon Tables:* The mapping logic.

Bei manchen Modellen kann man das ein- und ausschalten, bei einigen nicht. In den meisten Fällen verschwindet der Denkprozess in einem eingeklappten Bereich oberhalb des Ausgabetextes (z. B. mit einer Glühbirne oder einer „Weiter“- Ecke als Symbol), den man auf Wunsch aufklappen kann. Manchmal sind es mehrere solcher Bereiche.

Wenn das Modell seinen Denkprozess rausreicht (sich also beim Denken zugucken lässt), sieht man oft sofort etwas in der Ausgabe, gerade bei lokal betriebenen Modellen kann es andernfalls etwas dauern, bis sich etwas tut (vor allem, wenn das Modell zunächst in das (V)RAM geladen werden muss). Und auch wenn die finale Ausgabe startet, geschieht das noch während der finale Inferenz-Prozess abläuft, so dass die Ausgabe allmählich anwächst.

Wichtig zu diesem Thema vielleicht noch: bei einigen Modellen – auch und insbesondere bei den Online-Chatbots und cloudbasierten Agenten – kann man die Intensität des Reasonings anpassen. Bei Claude heißt das „Aufwand“, Mistral Vibe spricht von „Schnell vs. Denken vs. Recherche“ (wobei letzteres scheinbar einen erweiterten Modus triggert). Ein lokal per Ollama betriebenes gpt-oss:20B hat einen Schalter „Low/ Medium/High“.

Bei den Modellen, die man zum lokalen Ausführen herunterladen kann, wird teils unterschieden zwischen einer Standard- und einer „Thinking“- Variante. Ausgiebiges Reasoning wird auch als „Deep Thinking“ bezeichnet.

Die Frage danach, wo genau das Reasoning angesiedelt ist, führt bisher für mich allerdings fast ins Esoterische. Die Grundlage dafür muss in den Gewichten der LLMs angelegt sein (bzw. ist sie – ich hab Google gefragt). Anders gesagt: das LLM muss Reasoning „beherrschen“, damit die Runtime (s.u.) diese durchführen kann. Am Ende muss es also in den Konfigurationsdaten des LLMs stecken, wie genau die Runtime auf ihm Reasoning betreiben darf, denn alleine auf Basis der Gewichte dürfte das für eine Runtime nicht erkennbar sein.

Runtime / Inferenz-Server

Ein LLM ist – wie oben beschrieben – für sich genommen eigentlich nur eine statische Sammlung von Daten, im Grunde vergleichbar mit einer Bilddatei: solange nicht ein entsprechendes Programm das in ein Bild (zurück-)übersetzt, kann ein Mensch damit nix anfangen. OK, der Vergleich hat ein paar Mängel, aber hätte ich gleich von einer Scriptdatei geredet, in der Logik abgelegt ist, die eine Laufzeitumgebung braucht, um darin ihre eigentliche Wirkung entfalten zu können, wäre in den Köpfen m. E. das falsche Bild (oder gar keins) entstanden.

In einem LLM gibt es nichts, was viel mit Logik oder Abläufen zu tun hat. Das sind einfach nur Daten – alles andere wird drumherum gebaut.

Und dieses Drumherum besteht in erster Linie aus einer Laufzeitumgebung, der „Runtime“, dem Programm, das die LLM „ablaufen lassen“ oder „benutzen“ kann.

Die Runtime wiederum besteht aus der Inferenz-Maschine, dem Tokenizer (der die Hin- und Her-Übersetzung zwischen Embedding-ID und zugehörigem Wort(fitzel) erledigt) und einem Server, über den entsprechende Clients mit der Runtime kommunizieren können. Da das Hauptmerkmal von so einer Runtime ist, dass dort die Inferenz stattfindet, heißt das gute Stück oft auch „Inferenz-Server“. Nicht verwirren lassen: das ist dasselbe (aber Achtung: nicht verwechseln mit „Inferenz- Maschine“ – die ist bloß ein Bestandteil davon!).

Agent

Hier wird’s dann etwas haarig. Die deutsche Wikipedia behauptet, dass es sich bei einem (KI-)Agenten um Software handelt. Ich finde diese Sichtweise schwierig, denn grundsätzlich handelt es sich dabei zum einen immer um eine Kombination von mehreren Softwares, die zum anderen nicht mal zwingend auf demselben Rechner sein müssen. Ich sehe den „Agenten“ eher als ein Konzept des Zusammenspiels zwischen einem LLM, einer Runtime und einem Client.

Wie genau dieses Konzept ausgestaltet ist, ist erst mal nicht näher festgelegt. Weder verlangt ein LLM nach einer bestimmten Runtime noch ist festgelegt, welcher Client mit der Runtime interagiert. So ein Client kann etwas sein, das wie eine Webseite aussieht (eigentlich ist der Fall komplizierter, aber ich lass das mal so stehen) oder wie ein lokal installiertes Programm auf dem eigenen Rechner, über das ein Mensch seine Fragen stellt, oder ein Programm irgendwo im Netz, das vollkommen ohne menschliches Eingreifen mit der Runtime interagiert.

Die einzige mir bisher bekannte Aussage, die für alle diese „Agenten“ zutrifft, ist: sie alle sollen jeweils eine bestimmte Aufgabe lösen. Welche Aufgabe das ist, ist Teil einer über das eigentliche Konzept „Agent“ hinausgehenden Spezifikation.

Es gibt eine Handvoll prominenter Arten von Agenten, die auch dem Laien oft geläufig sind. Die trivialste ist der „Chatbot“ – eine Kombination obiger Bestandteile, bei der es darum geht, allgemeinsprachliche Fragen entgegenzunehmen und zu beantworten (oder einfach nur zu „quatschen“ – auch dafür kann man KI durchaus einsetzen!). Das ist zum Beispiel das, was man vor sich hat, wenn man eine der ganz oben erwähnten Online-KIs aufruft.

Ein anderer ist der „Coding Agent“ – eine Kombination, bei der es darum geht, Programme zu schreiben, also „Agentic Coding“ zu betreiben. Und dann gibt es „Automatisierungsplattformen“ im Stile von n8n, die die guten, alten Cronjobs (zeitgesteuerte Programmausführungen) auf eine völlig neue Ebene hieven und das Zusammenstellen ganzer (Business-)Workflows selbst für Laien zu einer – naja – sagen wir mal zu bewältigenden Herausforderung machen.

Ich habe auf einer Webseite den Satz „An agent is a model calling tools in a loop until a given task is complete.“ gelesen – wobei mit „Tools“ manchmal gesonderte Programme, manchmal Features, die der Client selbst anbietet, jedenfalls aber immer Dinge, mit denen der Server in der Ablaufumgebung des Clients irgendwelche Aktionen durchführen kann, gemeint sind.

Im einfachsten Fall ist das z. B. bei einem Chatbot die Möglichkeit zur Ausgabe von Text. Ein weiteres, relativ häufiges Tool ist die Möglichkeit zur Webrecherche. Die findet nicht etwa im Inferenz-Server statt, sondern die Runtime schickt dem Client eine Anforderung, ihr den Inhalt einer bestimmten Webseite zu übermitteln – der Client muss dann die Möglichkeit haben, einen entsprechenden Request an einen Webserver abzuschicken und das Ergebnis (die Response) an die Runtime zu übermitteln.

Webrecherche ist also ein Tool. Die Möglichkeit, auf mein lokales Dateisystem zuzugreifen und da Code zu analysieren oder zu generieren, ist ein Tool. Die Möglichkeit, ein bei mir lokal installiertes Programm zu verwenden oder Code auszuführen oder die Anbindung eines Temperatursensors über den lokalen Client, über den die KI meine Zimmertemperatur abfragen kann – das sind Tools. An den Client angebundene Kameras und Möglichkeiten, Aktoren zu betätigen, um damit ein Auto zu steuern … alles „Tools“.

Vielleicht noch ergänzend: tatsächlich muss nicht nur der Client ein Tool anbieten – das Modell muss natürlich auch in der Lage sein, es zu verwenden. Es muss darauf trainiert sein. Wenn der Client die Option zur Webrecherche anbietet, das Modell aber zur Webrecherche nicht fähig ist, ist nix mit Webrecherche.

Und jetzt der kleine Wehrmutstropfen. Es hat sich eingebürgert, Chatbots im Allgemeinen (und fälschlicherweise) nicht als Agent zu bezeichnen. „Agent“ ist im allgemeinen KI-Sprech in der Regel ein Agent (jetzt im obigen Sinne), dem man keine Fragen stellt, sondern Anweisungen (Instructions) erteilt. Aber wo da die genaue Grenze verlaufen soll (Chatbots können heute auch super Anweisungen entgegennehmen), sehe ich nicht so recht. Vielleicht verschwimmen die Grenzen da auch einfach zusehends.

Beim Drüberlesen ist mir gerade noch ein Gedanke gekommen. Wahrscheinlich kommt eine Sichtweise „Agent = ist auf die Verwendung von Tools Trainiert und mit der Möglichkeit, Tools zu verwenden ausgestattet“ vs „kann nur Texte erstellen / zusammenfassen“ der Sache wesentlich näher, wobei das allerdings heute eher „gedachte“ Extreme sind (denn die Fähigkeit, Bilder zu analysieren oder mit sonstigen Dateien umzugehen, oder auch „Webrecherche“ zu beherrschen – übrigens beides tatsächlich eigentlich schon Features aus dem Kapitel RAG – bleiben dabei unberücksichtigt, und spätestens die Webrecherche ist ja genaugenommen bereits ein „Tool“!).

Außerdem gibt es noch den Begriff des „Harness“, der davon unterschieden werden muss (was oft nicht stattfindet). Darauf gehe ich gleich noch etwas mehr ein.

Und dann kann man die einzelnen Workflows, die mit einem Tool wie n8n erstellt werden, auch wieder als „Agent“ bezeichnen, weil sie ja unabhängig voneinander bestimmte Aufgaben lösen …

Die Sprachverwirrung im KI-Thema ist beim Begriff „Agent“ m. E. am größten, und es braucht eine Weile, bis man ein Gefühl dafür kriegt.

Prompt

Dieser Begriff ist dagegen fast schon wieder einfach. Ganz verkürzt: das ist das Eingabefeld, wo man als Nutzer seine Fragen stellt oder Anweisungen eingibt.

Wer schon mal mit einer Eingabekonsole (Linux-Shell / Windows-Konsole / Eingabeaufforderung) gearbeitet hat, kennt den Begriff wahrscheinlich. Dort ist damit die Eingabezeile gemeint, die meist mit einer wilden Zeichenfolge beginnt und dann einen blinkenden Cursor beinhaltet, der den Nutzer dazu animieren (veranlassen, auffordern, eben englisch „to prompt“) soll, seine Befehle einzugeben.

Bei Chatbots und vielen anderen Agenten ist das erst mal ein (üblicherweise mehrzeiliges, aber oft erst mit dem Text wachsendes) Texteingabefeld, wie man es von Webseiten mit Formularen kennt.

Oft ist dieses Eingabefeld ergänzt durch ein großes „+“, über das man im einfachsten Fall Dateien – wie etwa Bilder, Videos, Worddokumente, PDFs, Audio-Dateien, CAD-Dateien oder auch Programmdateien – hinzufügen kann. Bei Claude kann man darüber z. B. auch „Skills“ (im Grunde eine Art „Vorlauftext“, der das Verhalten des Agenten feinjustiert) einstellen, weitere Online-Tools oder Quellen einbinden (so dass die Recherche dann doch zumindest in Teilen im Server abläuft – da wären wir dann beim Thema RAG), Unteragenten einbinden oder die Freigabe der Webrecherche ein- und ausschalten.

Oft ist bei den Online-Tools am Prompt auch ein Mikrofon-Button, mit dem man, wenn man ihn drückt, den Text für das Prompt einsprechen kann.

Und last but not least ist da die Justierung der Denkleistung, also die Auswahl, welches Modell verwendet werden soll – denn auch die Oberflächen der großen Chatbots können unterschiedliche LLMs benutzen – und wie viel „Mühe“ sich das Modell beim Denken geben soll (welchen „Aufwand“ es betreiben soll).

Zu den Modeln bei den großen Anbietern, allen voran Claude: Die model haben eine abgestufte Kompetenz, oft sind die etwas weniger „schlauen“ Models auch schlicht etwas älter. Aber: je komplexer und intelligenter ein Modell ist, desto mehr „Freivolumen“ verbraucht eine Anfrage und desto länger dauert es (in der Regel), bis die Inferenz die Antwort zusammengebaut hat. Die intelligenteren Model sind auch darauf ausgelegt, sehr genau nachzufragen, was der User von ihnen will. Die sollte man also nur starten, wenn sich das auch „lohnt“.

Prompting

Vom Wort her geht es ja hier darum, dass der User zu irgendwas aufgefordert wird. Das wäre aber ein Missverständnis, denn beim Prompting handelt es sich – genau umgekehrt – um die „Wissenschaft“ davon, einer KI „gute“ Fragen zu stellen und „effiziente“ Anweisungen zu geben.

Das ist im Grunde ein echt weites Feld und ganz ehrlich – im Zweifel fragt eine KI, wie ihr dies und das am besten so formuliert, dass eine KI damit ordentlich umgehen kann.

Grundsätzlich gilt aber: je präziser, spezifischer, detailierter und vollumfänglicher meine Anfrage ist, desto höher wird die Qualität der Antwort sein.

Tatsächlich ist es im Allgemeinen sogar von Vorteil, komplexere Anfragen zu strukturieren. Quasi alle Agenten, mit denen man (u. a.) auf Textbasis interagiert, verstehen (und liefern im Standardfall) z. B. Markdown. Umbrüche kann man in der Regel im Prompt machen, wenn man Umschalttaste+Enter („Shift“+Enter bzw. ⇧+⏎) eingibt.

Ich bevorzuge es allerdings, längere Prompts in einem Texteditor vorzubereiten und per Copy&Paste zu übertragen, denn ein Enter ohne Shift versendet den Prompt.

Ich hatte jetzt übrigens den Fall, dass ich eine HTML-Datei bei meiner Anfrage angehängt habe und die KI nicht mitgeschnitten hat, dass die irgendwo zu Ende war, denn mein Prompt hat das LLM nicht als solches erkannt ( „… User has not provided a prompt …“) und mir konsequent eine Zusammenfassung als Standardfallback geliefert. Hat etwas gedauert, bis ich es kapiert habe. (Mithin: offenbar werden die Dateien zuerst versendet!).

Damit ist das Wichtigste zu dem Thema eigentlich raus. Vielleicht noch als kleiner Hinweis: „/“ am Anfang des Prompts ist bei einigen Frontends eine Alternative zum Drücken des „+“ oder für eine Auswahl der dortigen Optionen. Außerdem kann man damit oft Kurzbefehle einleiten („/clear“ – aktuellen Chat und Kontext zurücksetzen, „/btw“ – die Anfrage nicht in den Kontext aufnehmen, „/stats“ – Nutzungsstatistik ausgeben, …).

Für den Anfang: mach Dir keinen Kopf und probier einfach aus! Ohne fundiertes Fachwissen kannst Du eigentlich nix kaputt machen. Und egal, was Du von der KI willst: alles wird bei einer LLM-basierten KI allgemeinsprachlich formuliert (OK – bei fortgeschrittener Verwendung kann so was wie Programmcode oder JSON dazukommen … aber das ist dann schon ein spezieller Anwendungsfall). Du musst im Grunde nix können.

Harness

Ein lokal installierter, meistens GUI-basierter KI-Client, der das Gesamtsystem „Agent“ mit allem versorgt, um Dich auf Deinem lokalen Rechner bei der Arbeit unterstützen zu können (also mit „Tools“). Der Klassiker ist dabei der lesende und schreibende Zugriff auf lokale Ordner (was eben über Browser nicht geht).

Welchen Ordner die KI sieht, gibt der Nutzer ihr vor. Man muss einen Ordner explizit zu einem Chat hinzufügen, sonst hat die KI keinen Zugriff. Die Webrecherche wird beim Arbeiten mit einem Harness (übrigens das „Zuggeschirr“, mit dem man die KI quasi vor seinen Karren spannt) auch von diesem abgewickelt.

Je nach Harness kommen weitere Funktionen hinzu. Außerdem hat ein Harness einen Prompt mit allem Drum und Dran, über den man die Aktionen steuert, wobei hier noch die Möglichkeit (z. B. bei Claude Code) dazu kommt, einzustellen, was das Tool auf dem eigenen Rechner ohne nachzufragen darf.

Und da es da immer wieder zu Verwirrungen kommt: der Harness ist nicht der Agent – er stellt nur dessen clientseitige Bestandteile dar. Ein Harness ist auch keineswegs ein notwendiger Bestandteil eines Agents – es kommt auf die Aufgaben des Agenten an, ob ein Harness Sinn macht.

Kontext

Wenn Du partout möglichst wenig von KI verstehen willst und sie trotzdem einigermaßen effizient anwenden können willst, dann ist der Begriff „Kontext“ das, was Du kennen solltest

„Kontext“ klingt auf den ersten Blick total trivial, und tatsächlich ist grundsätzlich damit genau das gemeint, was man spontan vermuten würde: alles, was die KI an Informationen vom Nutzer bereitgestellt bekommt, um die gestellte Frage beantworten oder die gestellte Aufgabe lösen zu können.

Tatsächlich wird es in vielen, weniger komplexen Fällen durchaus funktionieren, einfach eine simple, wenig detailierte Frage zu stellen – die meisten Modelle sind inzwischen ziemlich gut darin, sich auf Basis von wenig Information etwas „zusammenzureimen“, aber alles, was die KI sich selber zusammenreimen muss, birgt auch die Gefahr der Misinterpretation (zumal manche KIs ohne vorgegebene Bremse ziemlich in den Schwafelmodus verfallen).

Aber gut – im Zweifel stellt man halt dieselbe Frage einfach noch mal, und diesmal etwas detailierter und spezifischer (der Verbrauch an Rechenzeit und Volumen ist in so einem Fall meist eher unkritisch).

Aber wenn man einer KI komplexe Anweisungen gibt, etwas zu programmieren, und sie versteht nicht gut genug, was man von ihr will, und man wartet ’ne Stunde auf das Ergebnis, nur um festzustellen, dass man nicht richtig verstanden wurde … nicht so toll (und ggf. teuer!).

Ein guter Kontext – ein klares, präzises Prompt mit Hinweisen zu Dokumentationen und Referenzen, mit den richtigen Anweisungen zum Vorgehen und ggf. den richtigen, hinzugefügten Dateien – das kann oft den Unterschied zwischen „tolle App“ und „Mach’s noch mal“ ausmachen.

Und ja – auch hinzugefügte Dateien gehören zum Kontext, außerdem auch der Inhalt des System Prompts, bei Claude das ausgewählte „Skill“ (bei Mistral Vibe der ausgewählte „Agent“), je nach verwendetem Tool ggf. Workspace-spezifische Dateien oder Konfiguration (Kontext kann ggf. auch als JSON formuliert sein), und alles, was in der aktuellen Session bisher von Dir und von der KI geschrieben wurde (!).

Außerdem wichtig: wenn man mit einem kleinen, lokal installierten Modell arbeitet, vergisst das zwischen zwei Sessions tatsächlich alles, und wenn Du 2 Chats parallel darauf betreibst, weiß der eine nichts vom anderen. Aber auch bei den Großen schadet es oft nicht, die KI „abzuholen“, also ihr zunächst einen hinreichenden Kontext zu verpassen. Man kann sich Chatverläufe zu diesem Zweck beispielsweise von der KI zusammenfassen lassen.

Und dann gibt es da noch etwas. Dazu hole ich mal etwas aus. Vor der LLM- bzw. Transformerbasierten KI gab es bereits andere Modell-Architekturen (z. B. Multi Layer Perzeptron, LSTM oder Encoder/Decoder). Allen diesen Architekturen war gemein, dass ein Text stets sequenziell verarbeitet wurde – also „Wort für Wort“, eins nach dem anderen. Mit den LLMs hat sich das grundlegend geändert. Ein LLM verarbeitet einen übergebenen Text parallel, also „en bloc“. Für jedes neue Token, das die Inferenz generiert, wird immer der komplette Kontext, also der komplette bisherige Chatverlauf inklusive der bisher generierten, neuen Token durch den Transformer hindurchgerechnet!

Um verstehen zu können, wie das funktionieren kann, müssten wir ein bisschen über „Aufmerksamkeit“ bzw. „Attention“ reden. Machen wir gleich auch, ist aber hier erst mal egal.

Wichtig ist: Der Kontext wächst mit dem Verlauf des Chats immer weiter an, und jede Anfrage nimmt wieder (fast) den ganzen bisherigen Wust mit. Das ist auf der einen Seite toll, denn die Maschine weiß dann – zumindest wenn die Anfragen aufeinander aufbauen – immer genauer, wohin Du willst. Aber es ist auch klar, dass das nicht unbegrenzt immer so weiter gehen kann. Und deshalb gibt es das …

Kontextfenster

Die Größe des Kontextfensters sagt etwas darüber aus, wie viel Kontext ein Modell beim Denken maximal berücksichtigen kann. Es wird in „Token“ bzw. „Kilo-Tokens“ (je nachdem 1000 oder 1024) oder – neuerdings – auch in „Mega- Tokens“ (Millionen bzw. 2^20) angegeben – oft schlicht mit „K“ oder „M“ abgekürzt („Tokens“ ist halt keine Einheit).

Claude kann (je nach Modell) meines Wissens derzeit bis zu 1 Million Token (gleichzeitig!) verarbeiten, hat also ein Kontextfenster von 1M Token. Die kleineren, für den lokalen Einsatz geeigneten 7B- bis 16B-Modelle haben häufig 128K – sie können also maximal 131.072 Token verarbeiten (manchmal ist damit auch 128.000 Token gemeint). Manche können auch nur 32K.

Werden es mehr, passiert an sich nichts Furchtbares, sondern es fällt schlicht weniger relevante Information (also üblicherweise weiter zurückliegende Eingaben) aus dem Kontext heraus und landet dann regelrecht im „Nirwana“ und ward nie wieder gesehen.

Bei großen Kontextfenstern – sagen wir mal 16K und mehr, wobei das jetzt relativ willkürlich gewählt ist – wird einem das bei einem einfachen Chat kaum auffallen. Für die Programmierung größerer Anwendungen ist das was anderes. Da sind 16K (und selbst 32K) unter Umständen zu klein.

„Nutzung“ / Freivolumen / Kontingent

Das thema Kontext ist ein ganz guter Aufhänger für dieses Thema.

Folgendes solltest Du stets im Hinterkopf haben (spätestens sobald Du KI proffesionell und im großen Stil nutzen willst): die großen Online-KI-Anbieter merken sich, wie viele Token man durch ihre Agenten schickt – rein wie raus – und wie viel Rechenzeit man verbraucht hat.

Bei den unbezahlten Rumspiel-Accounts stößt man damit relativ schnell an Grenzen (also: die KI verweigert für die nächsten 24 Stunden die Zusammenarbeit), die Pro-Accounts kann man aber ebenfalls nicht beliebig intensiv beanspruchen. Sie sind auch für professionelle Programmierer in der Regel ausreichend – aber nur, wenn man ein paar Regeln beherzigt.

Es empfiehlt sich zum Beispiel, Chats nicht unendlich anwachsen zu lassen, denn der Gesamte Chat ist Kontext (einschließlich angefügter Dateien! s.o.). Und der geht bei jeder Anfrage erneut komplett durch den Transformer (es sei denn, er übersteigt das Kontextfenster … Bei Claude 1 Million Token …). Also: wenn man den Kontext des aktuellen Chats für eine Frage nicht braucht: neuen Chat aufmachen – der alte landet links in einer Liste und kann ggf. wieder geöffnet werden (… und ab und an die Liste aufräumen …).

Weitere Regel: die „intelligenteren“ Models sind – wie schon unter „Prompt“ erwähnt – in der Regel „teurer“: also nur wenn nötig verwenden! Und für so etwas wie „FIM“ („Fill in the Middle“ – eine Art Autocomplete beim Programmieren auf KI-Basis) eignen sich lokale Models besser!

Man kann sich Chatverläufe auch von der KI zusammenfassen lassen, um sie für den späteren Gebrauch zu speichern, oder um den aktuellen Chat zu verkleinern (entweder „/clear“ oder neuen Chat starten).

Integer & Floating Point Number

… sind eigentlich keine typischen KI-Themen, sondern für alle ITler oder praktisch arbeitenden Informatiker tägliches Brot. Da ich aber für die Laien nicht ständig hin- und hererklären möchte, hier einmal kurz und schmerzlos und ohne allzusehr in die Tiefe zu gehen …

Ein Integer (sprich „intedscher“, manchmal auch (fälschlicherweise) „Integer-Zahl“) ist eine ganze Zahl. 5 ist ein Integer, 4294967295 ist ein Integer, 0 ist ein Integer, -32 ist ein Integer.

Wenn irgendwo von „INT8“ die Rede ist, geht es um Integer, die sich mit 8 Bit darstellen lassen. Hierzu als Erinnerung: wir sind in der Computerwelt und im Grunde gibt es da nicht mal so etwas wie 42, sondern nur so etwas wie „00101010“. Dass man das als „0×2⁰ + 1×2¹ + 0×2² + 1×2³ + 0×2⁴ + 1×2⁵ + 0×2⁶ + 0×2⁷“ lesen kann / muss, und das dann wiederum 42 ist, ist vermutlich sogar vielen da draußen bekannt ( – obwohl, wie war das mit den 10 Arten von Menschen, die es gibt – diejenigen, die Binärzahlen verstehen und die anderen …?).

In einem INT8-basierten System ohne Vorzeichen ist die kleinste, darstellbare Zahl 0 und die größte 2⁸-1, also 255. Es gibt also maximal 256 darstellbare, unterschiedliche Werte. In LLMs wird allerrdings meistens mit Vorzeichen (also „+“ oder „-“) gearbeitet, so dass sich der Wertebereich von -128 bis 127 esrstreckt (erkläre ich jetzt nicht tiefer, sind aber ebenfalls 256 verschiedene Werte).

Eine Floating Point Number ist eine Fließkommazahl oder „Gleitkommazahl“, das heißt, da ist ein Basiswert (eine Mantisse) und ein Exponent zu einer fest vorgegebenen Basis (in der Regel 10). 1,25×10⁶ ist beispielsweise eine, -3×10⁴⁰ ist eine und -0,48×10⁻¹⁹ ist auch eine. Die ITler kennen das Konzept als „float“, „real“ oder „double“. Auch Fließkommazahlen werden effektiv als Bitmuster dargestellt, wobei ein Teil der Bits halt für die Mantisse reserviert ist, ein Teil für den Exponenten und 2 Bit für die Vorzeichen der Mantisse bzw. des Exponenten (die Mantissen in den Bitmustern stellen ihrerseits in der Regel ganze Zahlen dar – die Position des Kommas ergibt sich aus dem Exponenten).

Wenn irgendwo von „FP16“ die Rede ist, dann geht es um Fließkommazahlen, die mit 16 Bit darstellbar sind. Die Anzahl der unterschiedlichen, darstellbaren Werte ist freilich deutlich größer als bei INT8, allerdings nicht aufgrund der Exponentialdarstellung, sondern aufgrund der Tatsache, dass doppelt so viele Bits verwendet werden (wie gesagt: 16), was insgesamt maximal 2¹⁶, also 65.536 verschiedene, darstellbare Werte ermöglicht. Was allerdings anders ist, ist die Mathematik, weil man die ganze Zeit die Zahlen zerlegen und mit Exponenten rumfruckeln muss, was die Rechenprozesse minimal komplizierter macht.

Der Vorteil ist andererseits, dass die Abstände zwischen den Werten mit steigendem Exponenten logarithmisch ansteigen, was vermutlich in Kombination mit der Attention größere Kontextfenster ermöglicht – aber das ist, wie gesagt, nur eine Vermutung (und ich sollte mich da nicht weiter auf dünnes Eis begeben …).

Das Thema Integer und Float wird vor allem bei LLMs, die man lokal auf dem eigenen Rechner ablaufen lassen will, relevant (beim Thema Quantisierung und beim Thema KV-Cache), allerdings ist es kein Fehler, diese Dinge zumindest schon mal gehört zu haben.

Token (2) & Embeddings …

Zum Thema Token habe ich ja ganz am Anfang schon ein wenig gesagt. Hier kommen wir jetzt zu den etwas technischeren Aspekten. Ein „Token“ ist eben letztendlich mehr als nur ein Wort oder Wortteil. Die Begriffe „Token“ und „Embedding“ überschneiden sich zudem oder werden zumindest nicht immer trennscharf verwendet.

Wie schon in der Erklärung zu „LLM“ oben gesagt: ein Sprachmodell bzw. LLM – bzw. genau genommen sein Transformer – „versteht“ eigentlich nur Zahlen. Wir Menschen brauchen aber Wörter und Sätze. Also muss da irgendwo eine Übersetzung stattfinden. Die Basis für die Übersetzung sind 2 Tabellen – der „Lookup-Table“ und die Embeddings- Tabelle. Beide sind für ein LLM spezifisch (also Teil des LLMs).

Im Lookup-Table ist jedem Token ein (positiver) Integer zugeordnet – eine sogenannte „ID“.

In der Embeddings-Tabelle ist jeder dieser IDs jeweils ein Vektor zugeordnet. Klingt komplizierter als es ist: ein Vektor ist (wie oben bereits beschrieben) schlicht eine sortierte Liste von Zahlen mit einer fest definierten Länge (z. B. 4096). „Sortiert“ bedeutet hier (wie gesagt) „hat an derselben Stelle dieselbe Bedeutung“, sprich, bei einem Embedding A (oder meinetwegen ID 3651) bezieht sich die 14. Zahl im Vektor auf dasselbe Merkmal wie die 14. Zahl beim Embedding B (mit der ID 81146).

Die Embedding-Tabelle hat also eine Spalte mit einer ID, zu der es Gegenstücke im Lookup-Table gibt, und außerdem ganz viele (z. B. 4096) Spalten für weitere Zahlenwerte. Ob diese dann INT8 oder FP16 oder was auch immer sind, hängt davon ab, ob das LLM in einer quantisierten Form vorliegt oder nicht.

Die „Merkmale“ haben, wie gesagt, jeweils eine feste Bedeutung. Diese erhalten sie während des Trainings. Was genau ein bestimmtes Merkmal jeweils besagt, bleibt im Grunde das Geheimnis des LLMs. Es hat lediglich bei jedem Token, äh, will sagen bei jedem Embedding dieselbe Bedeutung. Diese Merkmale nennt man (vielleicht deshalb?) auch „Hidden Dimensions“. Die Gesamtheit bzw. Anzahl der Embeddings – von der Anzahl her identisch mit der Anzahl der Tokens – stellt das „Vokabular“ eines LLMs dar.

Aber zurück zum Hin- und Herübersetzen … folgendes passiert da:

Der Tokenizer der Runtime bedient sich zunächst einmal der Lookup-Tabelle, um die eingehnden Token alle in IDs zu übersetzen. Das Ergebnis wird an den Transformer weitergereicht.

Der Transformer wiederum hat an seinem Eingang einen „Embeddings- Layer“ (einen der sogenannten „Hidden Layer“). Hier werden die IDs anhand der Embeddings-Tabelle in ihre Vektordarstellung überführt.

Dann rattert alles durch den Transformer und es findet ein – sorry – Arsch voll Vektortransformationen anhand der Tensoren statt, und irgendwo dazwischen sind weitere Hidden Layer, die sich um die Attention kümmern, und am Ende kommt ein einzelner Vektor dabei heraus.

Und dieser finale Vektor ist dann das Muster, anhand dessen nach passenden Embeddings gesucht wird, die darauf überprüft werden, wie gut sie zu dem Ergebnisvektor passen (bildlich gesprochen: wie gut sie in dieselbe Richtung zeigen … im 4096-dimensionalen Raum …).

Je nach Temperatur (ein Konfigurationswert – heißt wirklich so, sorry) ist dann die Streuung der Möglichkeiten größer oder kleiner, und aus dieser Streubreite heraus wird – so weit ich weiß – irgendein beliebiges Embedding ausgewählt und das hat dann die ID des neuen Tokens, und die wird vom Tokenizer dann zurückübersetzt.

Ist das jetzt klar? 😁

Ui – OK … tatsächlich war das jetzt so im großen und ganzen der komplette Inferenz-Prozess (bzw. eine einzelne Inferenz-Schleife). Und das wird jeweils für jedes einzelne Token ein mal – zumindest fast – komplett durchexerziert.

KV-Cache / Kontext-Cache

Um nicht jedes Mal alle Token in Vektoren übersetzen zu müssen, werden diese im „Kontext-Cache“ zwischengespeichert, so dass sie jeweils nur en bloc in den Transformer reingeschoben werden müssen. Die Größe des Kontext-Caches korreliert dabei mit der Größe des Kontextfensters, denn es handelt sich dabei ja um zwischengespeicherte Embeddings, denen 1:1 jeweils ein Token entspricht (fälschlicherweise wird deshalb oft auch vom „Token-Cache“ gesprochen).

Die Größe dieses Caches wird deshalb ebenfalls in „Tokens“ bzw. „Kilo-Tokens“ (also „K“) angegeben und ist bei lokal betriebenen KIs einstellbar, so dass der lokale Agent u. U. (bzw. in aller Regel) effektiv mit einem kleineren Kontextfenster arbeitet, als es das Modell eigentlich ermöglichen würde. Das hat vor allem Performance- Gründe, denn der Rechenaufwand steigt mit der Größe des Kontextfensters (ohne Caching) quadratisch (O(n²)).

Der Grund dafür ist vor allem, dass bei der Self Attention alle Token mit allen anderen verglichen werden. Tatsächlich ist der Kontext-Cache aber sogar hinter der Multi Head Attention angesiedelt, was dazu führt, dass effektiv nicht einfach Vektoren, sondern bewertete, und je nach Attention-Bauart zusammengefasste Vektoren gecachet werden, was die Größe des Kontext-Caches massive verkleinern kann. Dadurch ist ein Kontext-Cache von – sagen wir – 8K bei zwei unterschiedlichen Modellen effektiv in Megabyte (bzw. meistens eher Gigabyte) gemessen unterschiedlich groß.

Der KV-Cache (ein anderes Wort für den „Kontext“- Cache – das „KV“ bezieht sich auf bestimmte Aspekte der Attention) eines phi4:14b- q4_K_M benötigt für 1K Token (bzw. Embeddings) beispielsweise 200MiB (Mebibyte), für dieselbe Menge Tokens braucht der KV-Cache eines ministral-3:14b- instruct-2512-q4_K_M nur 160MiB, bei einem qwen3.5:9b-q4_K_M sind’s nur 128MiB und bei einem gemma4:e4b-it-qat nur knapp unter 40MiB (liegt vor allem an der Grouped Query Attention … s. u.). Ich habe ganz unten ein paar Zahlen dazu angehängt.

Attention / Aufmerksamkeit

Das war für mich bisher die härteste Nuss, und ich hab das immer noch nicht wirklich zu meiner Zufriedenheit durchdrungen. Ganz grundlegend gesprochen geht es bei der Attention darum, dem Datenwust, der durch den Transformer wandert, Zusatzmerkmale wie Reihenfolgen, Relevanz und semantische Zusammenhänge aufzuprägen (zum Beispiel „was ist Subjekt, was Objekt“, „welche Attribute gehören wohin“, „auf welche vorher genannten Teilaspekte bezieht sich eine Teilaussage“ … so Zeug halt).

Würde man es einem Grundschüler erklären wollen, könnte man vielleicht sagen: die Attention ist so etwas wie die ordnende Hand im Chaos.

Das Wissen liegt zwar in seiner Gesamtheit allein durch die „Erinnerungs-Tensoren“ (oder wie auch immer man das nennen will) vor, aber es hat keine Reihenfolge oder Rangfolge. Es ist ein einziger, großer Wissensswust ohne Anfang und Ende. Um damit etwas anfangen zu können, muss es in eine Form gebracht werden, über die Menschen damit interagieren können, in eine sequenzielle Abfolge von Einzelinformationen, sie landläufig als Sprache bezeichnet wird (zugegeben – da beißt sich die Katze etwas in den Schwanz, denn die Information liegt in einer Form vor, die aus Sprache resultiert … aber isso).

Um feststellen zu können, an welcher Stelle im Sprachfluss welche der Informationen relevant ist, braucht es steuernde Mechanismen. Diese bestehen wiederum aus Untersystemen, die ihrerseits aus neuronalen Netzen bestehen (falls ich das richtig verstanden habe), und die haben den schönen Namen Attention.

Es gibt allerdings nicht nur eine Form von Attention, sondern:

Self-Attention (Selbstaufmerksamkeit)
Wird im Encoder (Embeddings-Layer?) verwendet. Jedes Token richtet seine Aufmerksamkeit auf alle anderen Token innerhalb derselben Sequenz, um tiefgreifende kontextuelle Einbettungen zu erstellen.

Masked Attention (Maskierte Aufmerksamkeit)
Wird im Decoder (Textgenerierungs-Modul – Wahrscheinlichkeiten, Embeddings, Ratespiele …) verwendet. Sie blendet zukünftige Tokens aus, sodass das Modell Wörter auf natürliche Weise – Schritt für Schritt – vorhersagt, ohne „vorausspicken“ zu können (also offenbar, damit die sprachlich korrekte Reihenfolge eingehalten wird).

Cross-Attention (Encoder-Decoder-Aufmerksamkeit)
Wird bei Übersetzungsaufgaben oder allgemeinen Sequenz- zu-Sequenz-Aufgaben eingesetzt. Der Decoder richtet seine Aufmerksamkeit auf spezifische Teile der encodierten Eingabesequenz, um die korrekte Ausgabe zu generieren.

Multi-Head Attention
Transformer führen den Attention-Mechanismus parallel über mehrere „Heads“ (Köpfe) aus. Jeder Head fokussiert sich dabei auf einen anderen Aspekt (z. B. achtet der eine Head auf die Grammatik und Satzlogik, ein anderer auf Wortbedeutungen oder inhaltliche Zusammenhänge („Geht es hier um Technik, Gefühle oder Zeit?“), noch ein anderer beschäftigt sich mit der Bedeutung der Pronomen („Worauf bezieht sich ‚es‘ oder ‚sie‘?“), etc.). Dies ermöglicht es dem Modell, sich gleichzeitig auf mehrere, verschiedene Aspekte eines Satzes zu konzentrieren (z. B. wer was tut im Gegensatz zu wo und wann). Multi-Head-Attentions sind Submodule innerhalb von Modellschichten. Die Heads bestehen selbst jeweils aus vielen Nodes und Tensoren.

Beim Thema KV-Cache geht es vor allem um die Multi-Head-Attention.

Bei der Berechnung der Multi-Head-Attention geht es vor allem darum, „Ähnlichkeiten“ aufzuspüren. Dafür wird ein „Punktprodukt“ (ein auf bestimmte Weise definiertes Skalarprodukt) für Kombinationen von Wörtern ermittelt (tatsächlich geht es wohl eher um Token oder genau genommen Embeddings, aber ich geb das mal so weiter, wie ich es vorgefunden habe).

Dabei werden „Q“, „K“ und „V“ verwendet – alles drei Vektoren in der Größenordnung der Embeddings:

Query (Q)
Der Suchanfrage-Vektor eines Tokens („Was wird gesucht?“ => Ratespiel …?).

Key (K)
Der Vektor eines anderen Wortes („Welche Merkmale werden mit der Suche verglichen?“).

Value (V)
Der eigentliche Wert (Vektor) bzw. Inhalt des Wortes („Welche Information wird geliefert?“).

(siehe auch Wikipedia: Attention Is All You Need)

Wobei Q offenbar eine Art Eingangsseite darstellt und K und V eine Ausgangsseite (ohne Garantie auf Korrektheit). Und dieses K und V, beides wie gesagt Vektoren, ist offenbar das, was zwischengespeichert wird.

Zum Thema Ähnlichkeit ergänzend: es geht hier um Vektoren – und hier dann zumindest in der Vorstellung wieder um die Darstellung als „Pfeil“ (wie inne Schule). Wenn man jetzt mal Vektoren mit 3 Feldern (Dimensionen) nimmt – sprich: sie bestehen aus 3 Zahlen – dann hat so ein Vektor in einem gedachten, dreidimensionalen, euklidischen Raum (Koordinatensystem mit Nullpunkt, in dem sich die 3 Raumachsen jeweils senkrecht zueinander schneiden … oder nimm meinetwegen wieder den Kartonstapels aus dem Beispiel zu Vektoren ganz oben und dessen vordere, linke, untere Ecke als Nullpunkt) ausgehend vom Nullpunkt des Koordinatensystems eine Ausrichtung, oder noch einfacher gesagt, eine „Richtung“, in die er zeigt. Ähnlich sind Vektoren einander im Sinne der Attention dann, wenn sie (nahezu) dieselbe Richtung haben. Gut – das muss man jetzt bloß noch auf 4096 oder halt noch ein paar tausend Dimensionen mehr übertragen, aber dafür gibt’s ja das Punktprodukt.

GQA / Grouped Query Attention

Bei der GQA stehen Q, K und V nicht im Verhältnis 1:1:1, sondern einem Q-Head sind mehrere KV-Heads zugeordnet, so dass eine Form der Datenreduktion stattfindet. Dadurch verkleinert sich die KV-Cache-Größe pro einzelnem Token. Es gibt auch noch andere Mechanismen, die in diese Richtung gehen, Aber das hab ich mir mal geschenkt.

Embeddings und die RAG

Retrieval-Augmented Generation (RAG) ist die Bezeichnung für verschiedene Möglichkeiten, einer KI Zusatzinformationen zugänglich zu machen. Eine der naheliegendsten Varianten ist die Webrecherche. Eine andere ist das Verfügbarmachen von Vektordatenbanken, in denen die KI bzw. das LLM auf vorindexierte, strukturierte Daten zugreifen kann, die nicht Teil seines Trainings waren (Firmenwikis und dergleichen).

Die dortigen Vektoren haben dabei nichts mit den eigenen Embeddings des LLMs zu tun, sondern unterliegen eigenen Regeln – der Abruf solch einer Suche basiert demnach auf einer Token- oder Wortebene, und die Rückgabe sind entsprechend Token bzw. Wörter oder ganze Textauszüge. Allerdings bezeichnet man auch die Inhalte dieser Vektordatenbanken wiederum als Embeddings.

Halluzinieren

KIs bzw. LLMs funktionieren nicht wie ein Taschenrechner, sondern – wie gezeigt – eher wie „ingenieurmäßiges“ Schätzen oder schlicht „Wörter raten“. Sie sagen das nächste Wort (oder genau genommen Token) in einem Satz – oder besser „in einer Unterhaltung“ – nicht durch logisches Denken voraus, sondern basierend auf mathematischen Wahrscheinlichkeiten.

KIs können dabei nicht zwischen „wahr“ oder „falsch“ rsp. „gelogen“ unterscheiden. Sie kennen nicht einmal entsprechende Konzepte (also etwa, was es bedeutet, wenn etwas gelogen ist). Im Grunde betreibt eine LLM-basierte KI den ganzen Tag ihr „Morgenstund hat Gold im Mun_ – bitte ergänzen Sie“-Ratespiel, ohne auch nur den Hauch einer Ahnung davon zu haben, was ein Mund eigentlich ist und wieso da Gold drin sein sollte.

Aufgrund seines Trainings „weiß“ das LLM lediglich, dass wegen der bisherigen Aneinanderreihung von Buchstaben (um im Beispiel zu bleiben) hier sehr wahrscheinlich ein „D“ hingehört.

Tatsächlich arbeitet so ein Modell nun nicht auf Basis von Buchstaben, sondern auf der Basis von Token (oder sagen wir mal: Wörtern). Das Ratespiel würde also eher „Morgenstund hat Gold im _ – bitte ergänzen Sie“ lauten. Der Teilsatz „Morgenstund hat Gold im“ bildet dabei bekanntermaßen den Kontext, auf dessen Basis die Wahrscheinlichkeit für das nächste Token ermittelt wird.

So ein Kontext kann bei einem LLM – wie wir wissen – sehr viel länger sein und sehr viel mehr als nur einen Satz umfassen. Das ist allerdings nicht der entscheidende Punkt.

Der eigentliche Gag bei der ganzen Geschichte ist folgender: die neuen ermittelten Token werden ja nicht nur einfach als „Antwort“ ausgegeben, sondern erweitern auch den Kontext für das Ratespiel. Ohne jetzt noch mal allzu tief in die technischen und mathematischen Details zu gehen: auf Basis eines Kontexts kann unter Beachtung aller Parameter und Bewertungswahrscheinlichkeiten bei ganz exakter Rechnung und hinreichend eindeutigem Kontext eigentlich nur genau ein Wort als nächstes folgen.

Das wäre aber zum einen kein „menschliches“ Verhalten, zum anderen würde es jegliche Kreativität im Keim ersticken, und oft genug ist das System aufgrund seiner technischen Grenzen auch gar nicht in der Lage, für zwei Token eine unterschiedliche Wahrscheinlichkeit zu ermitteln. Und dann ist obendrein nicht mal sichergestellt, dass genau dieses Token / Embedding im Vokabular vorhanden ist. Es wird darum nicht immer nur das Wahrscheinlichste genommen, sondern eines von den Wahrscheinlichsten.

Und last but not least gibt es Kontexte, bei denen nur für eine sehr kleine Gruppe von Token eine sehr hohe Wahrscheinlichkeit besteht, und links und rechts davon ist alles ausgesprochen unwahrscheinlich, es gibt aber auch Kontexte, bei denen die Gruppe der „wahrscheinlichsten“ Wörter relativ groß sein kann (in Bezug auf die im Vokabular vorhandenen Embeddings).

Da die KI nun aber darauf ausgelegt ist, zu antworten, geht sie auch hier hin und wählt eines – irgendeines – dieser Wörter aus … und das Ergebnis erweitert wiederum den Kontext für das nächste … und das Ergebnis dann wieder … naja – und so weiter und so fort.

Sprich: die KI baut sich selbst einen Kontext, der u. U. für einen Menschen sofort als falsch oder gar blanker Unfug erkennbar ist, aber die KI schneidet das nicht mit. Sie macht einfach weiter ihr Wörterrate-Ding und plappert fröhlich drauf los – sie halluziniert sich irgendwas zusammen (und zwar ganz ohne LSD).

Am faszinierendsten ist das, wenn so ein Quatschkontext plötzlich wieder auf eine Schiene mit engen Gruppenwahrscheinlichkeiten zurückführt – dann erzählt die KI plötzlich wieder ganz vernünftiges Zeug, aber ist unter Umständen auf einem ganz anderen Planeten unterwegs als der, wo die Frage angefangen hat. Andererseits kann es der Zufall auch wollen, dass sie wieder im eigentlichen Thema landet (tatsächlich gibt es inzwischen Mechanismen, die dem Problem entgegenwirken, aber völlig weg ist es nicht).

Nutzer gehen dann ggf. hin und korrigieren die KI, und witzigerweise scheint das sogar einen trainierenden Effekt auf sie zu haben. Hat es allerdings nicht, denn die eigentlichen Algorithmen, die Gewichte, sprich Tensoren, werden dadurch nicht geändert. Nur der Kontext des aktuellen Chats gibt das neue Verhalten der KI her. Wenn jemand anderes dieselben Fragen stellt, könnte die KI wieder wie gehabt anfangen zu halluzinieren.

Allerdings kann schon nach wenigen Frage-/Antwort-Vorgängen kein Chatverlauf mehr mit einem anderen identisch sein, denn wie oben gezeigt, spielt spätestens bei den Antworten der KI der Zufall eine Rolle!

Ach ja – und zu dem „wieviele E’s sind in Erdbeere“-Problem: Eine KI kennt das Wort „Erdbeere“ nicht. Das Wort besteht aus mehreren Token, und die sind dem Transformer nicht mal geläufig, sondern nur ihre Vektordarstellung. So ein LLM kann auch nicht im eigentlichen Sinne zählen – wenn es also im Training nie die Information bekommen hat, wie viele E’s im Wort Erdbeere stecken, ist die KI (das Reasoning in diesem Fall, denke ich) gezwungen, kreativ zu raten. Deswegen kommt da Grütze bei raus. Erbergrütze in diesem Fall.

Was (derzeitige, LLM-basierte) KI nicht leisten kann

Nachdem ich selber in solche Fälle gerannt bin, habe ich mal von einer KI (Claude in diesem Fall) ein paar „typische Problemzonen“ zusammenstellen lassen. Das war die Antwort („ich“ ist in diesem Abschnitt die KI!):

Lokales, aktuelles Spezialwissen
Was der Gemeinderat in Meschede (Anm.: eine Stadt im Hochsauerlandkreis) letzte Woche beschlossen hat, ob der Hofladen um die Ecke noch geöffnet ist, aktuelle Rechtsprechung von Amtsgerichten … so etwas liegt jenseits meiner Reichweite, und auch Websuche hilft dort oft nicht wirklich.

Aufgaben, bei denen ich nicht weiß, was ich nicht weiß
Das ist der vielleicht heimtückischste Fall. Wenn ich keine Ahnung habe, merke ich das meistens und sage es. Aber wenn ich fast Recht habe — also genug Kontext kenne, um überzeugend zu klingen, aber in einem Detailpunkt falsch liege — ist das gefährlicher als komplette Unwissenheit. Medizinische Differentialdiagnosen sind ein Paradebeispiel. Oder Rechtsfragen mit lokalen Besonderheiten. (Geht in Richtung „Haluzinieren“, ist aber bei genauerer Betrachtung eine echte Gefahrenquelle, da Fehler u.U. nicht offensichtlich sind)

Feine visuelle Identifikation
Schriftarten, Pflanzenkrankheiten, Pilzarten, Gemälde-Echtheitsprüfung, Werkzeugspuren an Tatorten, Gesteinsarten. Ich erkenne grobe Muster, versage aber bei diagnostisch wichtigen Feinunterschieden — besonders dann, wenn der Unterschied gerade das Entscheidende ist. (Anm.: tatsächlich gibt es dafür oft Spezialwerkzeuge, die dann speziell auf solche Fälle trainiert sind)

Konsistenz über lange oder komplexe Eigenproduktionen
Bei einem kurzen Text: alles gut. Bei einem 50-Seiten-Dokument oder einer größeren Codebase, die ich selbst aufgebaut habe: Ich verliere den Faden, widerspreche mir, oder vergesse frühere Entscheidungen. Ohne externes Gedächtnis (Dateien, strukturierte Übergabe) verschlechtert sich die Qualität merklich.

„Kalibrierte“ Wahrscheinlichkeitsaussagen in komplexen Domänen
„Wie hoch ist das Risiko, dass dieses Projekt scheitert?“ — Ich kann Faktoren nennen, aber eine zuverlässige Wahrscheinlichkeit liefern? Nein. Ich kenne meinen eigenen Bias nicht gut genug, und in komplexen Systemen (Wirtschaft, Politik, menschliches Verhalten) ist das Rauschen zu groß.

Kurzfassung: Ich bin stark bei „breites Wissen, mittlere Tiefe, schnell abrufbar“ — und schwach überall dort, wo es auf letzte Präzision im Detail, lokale Aktualität oder ehrliche Unsicherheitsquantifizierung ankommt.

Lokale KI

„Lokal“ meint hier „auf dem eigenen Rechner“. Es geht also darum, den gesamten Stack einer KI (Runtime bzw. Inferenz-Server samt LLM und Client plus Tools) auf dem eigenen Rechner zu betreiben. Eine Variante davon kann außerdem das Betreiben einer zentralen KI auf einem Firmenrechner sein, der nur für Firmenmitglieder erreichbar ist (dann braucht man z. B. einen Server, der den Client für die Runtime darstellt und die GUI dazu als Webseite (und/oder eine API als Webservice) rausreicht – ganz so wie bei den öffentlichen KI-Portalen (eines der dafür in Frage kommenden Softwareprodukte heißt z. B. „Open WebUI“).

Wir gehen hier nur den Weg des eigenen Rechners und zwar unter Windows (Linux geht auch, aber es ist i. d. R. alles etwas komplizierter). Mit Mac habe ich keine Erfahrung, deshalb dafür alles nur unter Vorbehalt.

Warum sollte man sich überhaupt die Mühe machen?

Nun ja – nicht jeder Kunde wird den Gedanken mögen, dass seine Softwaredetails auch im fernen Amerika bekannt sind, und nicht jeder möchte seine aktuellen Fußschweißprobleme dorthin versendet wissen. Ein wichtiges Argument ist also sicher der Datenschutz. Selbst wenn die Hersteller eines LLMs in den USA oder China sitzen – bei einem lokalen Setup mit Ollama (oder LM Studio) geht – wenn man nicht gerade eines der Cloud- Modelle bei Ollama aktiviert – nichts vom eigenen Rechner raus. Es bleibt privat. Volle Datenkontrolle.

Alternativ könnte man hier über Optionen wie Lumo (sitzt in der Schweiz und hat sich maximale Verschwiegenheit auf die Fahnen geschrieben) oder Mistral AI (sitzen in Frankreich und sind an europäisches Recht und damit u. a. an die DSGVO gebunden) nachdenken. Aber dann verlassen halt meine Eingaben meinen Rechner in Richtung eines Servers im Internet. Ist vielleicht auch ein bisschen Geschmackssache. Ich selbst mache eine Mischung. Ich habe bei Claude und Mistral einen Pro-Account (und wegen der krass guten Fähigkeiten, Bilder zu bearbeiten, erwäge ich auch einen ChatGPT-Account, wobei DALL-E da fast schon die spannendere Alternative wäre, aber ChatGPT kann halt auch noch anderes).

Wo wir gerade von Bildern reden: Das Generieren von Bildern wird von den lokalen Modellen bisher nicht direkt angeboten (Charts gehen bei einigen Modellen in der einen oder anderen Form von Code). Ich hab so was bisher bei mir auch noch nicht eingerichtet, so dass ich das Thema irgendwann mal nachreichen muss.

Ein weiteres Argument ist die Sparsamkeit beim Datenkontingent, dass man bei den Onlineanbietern hat (Hab ich ja oben schon was zu gesagt).

Und last but not least kann man beim Einrichten solcher Sachen eine Menge lernen.

OK – die Leute, die sich für das Thema „Lokale KI“ nicht interessieren (aber warum habt Ihr überhaupt bis hierhin gelesen?!) können an dieser Stelle eigentlich schon mal packen und nach Hause gehen.

Ollama

… ist eines der Standard- … na … nennen wir’s mal -Programme für lokale KI, bestehend aus einer Runtime, die als Service läuft, und (bei der Windows-Version und soweit ich weiß auch beim Mac) einer GUI mit einem integrierten, etwas reduzierten, aber universellen und durchaus brauchbarem Harness.

Zugriff auf lokale Ordner wie beim Claude-Harness gibt es da allerdings noch nicht (also eigentlich ein Nicht-Wirklich-Harness), aber man kann von da ausgehend („Launch …“) andere Harnesses starten und darüber mit der Ollama- Runtime arbeiten. Anderer Vorschlag: Continue-Plugin in VSCode … ist allerdings bisschen fruckelig in der Einrichtung.

In die Ollama-GUI ist auch eine einfache Konfigurations-Oberfläche integriert, in der man z. B. die KV- Cache-Größe per Klickibunti justieren kann. Die Runtime kann man unten in der Taskleiste (rechts im System-Tray, wo auch der Batteriestand und die Uhrzeit und die „klapp mehr aus“-Ecke drin sind in dem kleinen „klapp-mehr-aus“-Panel) anhalten bzw. neu starten (oder halt in der Diensteverwaltung).

Ollama hat noch immer den Ruf, sehr kommandozeilenlastig zu sein. Das ist aber bei Windows (und Mac) so nicht mehr unbedingt der Fall (wobei ein „ollama ls“ oder „ollama ps“ oder ein „ollama -h“ auf der Kommandozeile – z. B. in der Powershell oder auch ganz klassisch in der guten, alten Eingabeaufforderung – manchmal durchaus hilfreich sein kann).

Ollama verwendet als Kern-Runtime llama.cpp, und das ist offenbar eine Anspielung auf „LLM“ – daher muss wohl der Name und das süße L(l)ama-Logo rühren.

=> https:// ollama.com/ (siehe auch „Models“ – das „Pricing“ bezieht sich auf die Nutzung von deren Cloud)
=> https://ollama.com/download/windows

Beim ersten Start eines Modells, das man über das Dropdown ausgewählt hat, wird das erst mal heruntergeladen. Das kann bei 8 oder 10 Gigabyte ein Sekündchen dauern …

Ich persönlich bevorzuge die teilautomatisierte Variante, indem ich mir auf der Webseite das Modell suche (https://ollama.com/search – „view all“) und dann per Konsole mit „ollama pull %modelname%“ installiere. Danach ist es auch im GUI- Client verfügbar.

VRAM

Im eigentlichen Sinne „Videospeicher“.

RAM (Random Access Memory) ist der flüchtige Speicher eines Computers, VRAM ist der ebenso flüchtige Speicher einer Grafikkarte. Allerdings ist das alles nicht so einfach. Ollama verwendet, wenn die Möglichkeit besteht, Bestandteile der Grafikkarten für seine Vektormathematik, weil die Anzahl der dafür verwendbaren Vektor-Mathematik-Prozessoren (Matrix-Engines) auf Grafikkarten (GPUs) höher ist als die der (viel universeller einsetzbaren) Haupt- Prozessoren (CPUs bzw. CPU- Threads). Außerdem sind die Vector-Engine-Kerne der GPU bei dieser Aufgabe schneller.

Nun hat aber nicht jeder eine dedizierte Grafikkarte (z. B. ist das bei den meisten Notebooks nicht der Fall), und wenn doch, dann hat die Grafikkarte nur kläglich wenig VRAM. Denn um ein halbwegs brauchbares LLM zu betreiben, braucht man schon wenigstens 8 GB (Gigabyte).

Die gute Nachricht:

CPU-Inferenz

Andererseits kann Ollama auch zurückfallen auf CPU-Inferenz und die Verwendung von gewöhnlichem RAM. Wenn man allerdings nicht den Luxus von 22 CPU-Threads hat, wie ich ihn auf meinem Notebook habe, sondern – sagen wir mal – nur 4 und auch nur 8 GB Gesamtspeicher, wird’s schwierig. 4 Threads und 16 GB funktioniert, ist aber kein Vergnügen. Außerdem sollten möglichst 2 symmetrische Speicherbänke vorhanden sein, damit der Bus im Dual- Channel-Modus läuft (ich glaube, Ollama läuft andernfalls u. U. gar nicht erst).

Bis vor nicht allzulanger Zeit war es auch ein Problem, wenn die GPU eine Intel-GPU war. Mit wenigen Ausnahmen kann Ollama zwar immer noch nichts mit Intel-GPUs anfangen (und schon gar nichts mit in den Hauptprozessor integrierte iGPUs, die obendrein ihrer Matrix-Engines beraubt wurden .. grrr …), aber es kann zumindest auch auf solchen Systemen mit CPU- Inferenz arbeiten. Es gibt zwar IPEX-LLM (https://github.com/ipex-llm/ipex-llm), ein auf einem antiken Stand von Ollama aufbauendes Spezial-Dings, das ursprünglich mal von Intel selbst gebaut wurde, aber die haben das Projekt eingestampft (der Link geht zu einem seit April 25 aber offenbar auch nicht sonderlich weitergekommenen Community-Fork) … ich hab damit rumprobiert, der Geschwindigkeitsgewinn war so làlà und die aktuellen Modelle (z.B. mein heiß geliebtes gemma4) liefen teils gar nicht.

Das meiste (quasi alles) von dem Konfigurations- und Modusauswählzeugs macht Ollama ganz von sich aus, so dass man es einfach nur installiert und startet, und alles andere geschieht im Hintergrund. Manchmal macht es Sinn, z. B. die Umgebungsvariable OLLAMA_NUM_THREADS zu setzen (wenn man nur wenige CPU-Threads verfügbar hat, damit die Inferenz nicht den Rechner lahmlegt). Aber grundsätzlich auch hier: einfach ausprobieren.

Speicherbedarf

Wenn Ollama nicht mit dem VRAM auskommt, lagert es (angeblich) automatisch Teile ins RAM aus. Ich verwende bei mir Shared Memory als VRAM – und zwar per Voreinstellung 18 GB von den insgesamt 32. Angeblich ist dieser Wert wohl eher so was wie ’ne freundliche Empfehlung, als dass irgendwer auf ihn irgendwas gibt. Ich hatte allerdings den Eindruck, dass Ollama diese Grenze respektiert und das LLM in einen Error laufen lässt, wenn der Speicherplatz für das LLM + dem Speicherplatz für den KV- Cache das überschreiten.

Im Allgemeinen ist es eine gute Idee, auch ein tatsächliches VRAM nicht komplett auszulasten – die Empfehlung lautet, 1 bis 1,5 Gigabyte übrig zu lassen.

Wenn man denn ungefähr weiß, wie viel GB (oder GiB) tausend Token verbrauchen, dann kann man ausgehend vom gesamten verfügbaren VRAM die maximale Größe des KV- Caches folgendermaßen abschätzen:

KV-Max (in „K“) = (Σ(VRAM in GB) – (Speicherverbrauch d. Models in GB) – 1,5) × 1000 / (KV-Speicher für 1000 Token (1K) in MB)

(eigentlich sind es 1024 statt 1000 und MiB statt MB … aber wir sind da mal nicht päpstlicher als der Papst.)

Als grobe Abschätzung für die größtmöglihchen KV-Cache (in „K“, also 1000 Token) geht bei fehlender Information ansonsten als konservative Schätzung eigentlich immer
„(Σ(VRAM in GB) – (Speicherverbrauch d. Models in GB) – 1,5) × 5“
(entspricht einem Verbrauch von 200MiB für 1K Token) – damit ist man bei den lokalen Modellen mit maximal 24B eigentlich immer auf der sicheren Seite. Hat man den Verdacht, das mehr geht, kann man auch einfach rumprobieren. Schlimmstenfalls läuft die Inferenz in einen Error (steht dann so in der Textausgabe).

MoE / Mixture of Experts

Bei diesen LLMs werden für eine Inferenz-Schleife nicht mehr alle Gewichte verwendet, sondern es existiert eine vertikale Aufteilung in spezialisierte Bereiche (die „Experten“), und es werden abhängig von den Erkenntnissen der Attention nur noch Teile der Gesamtmatrix verwendet, so dass der mathematische Aufwand pro Durchlauf deutlich verringert wird.

Tatsächlich scheint das obendrein Auswirkungen auf den Gesamtspeicherverbrauch zu haben. Aber das habe ich bisher nicht weiter hinterfragt. Die neueren Modelle sind glaube ich alle „MoE“s.

Und um einem Missverständnis vorzubeugen: auch bei einem MoE wird für die Inferenz trotzdem immer das komplette Model ins VRAM geladen.

Quantisierung

Ursprünglich war wohl mal „FP16“ – also Fließkommazahl auf 16-Bit-Basis – als Arbeitsmodus für die Vektoren und Tensoren der Goldstandard. Dadurch sind die Modelle aber relativ groß – meistens zu groß für Privatrechner. Also ist man auf die Idee der „Quantisierung“ verfallen – im Grunde eine Form der Datenkompression.

Eine „Q8“-Quantisierung bedeutet, dass die Systeme mit 8-Bit-Integern (INT8) statt 16- Bit-Fließkommazahlen arbeiten, so dass Gewichte und Vektoren nur noch halb so groß sind. Außerdem wird die Mathematik dadurch etwas weniger aufwendig, und die Modelle laufen schneller. Der Nachteil ist ein geringer Qualitätsverlust – d. h. die Ergebnisse sind etwas weniger perfekt als bei den FP16-Modellen (und theoretisch ist die Gefahr für Halluzinationen geringfügig größer).

Ein Q8_0 (durchgehende INT8-Quantisierung) ist aber noch immer verdammt nahe an der „Vollversion“. Wer schon mal JPEG-Bilder in GIF-Bilder mit einer Palettengröße von 256 Farben umgewandelt hat, bekommt eine grobe Vorstellung.

Eine rein auf INT4 basierende Quantisierung (Q4_0 oder Q4_1) ist zwar noch kleiner, bringt aber auch schon erhebliche Einbußen. Also hat man sich verschiedene Tricks ausgedacht. Zum einen gibt es da die „dynamische“ K-Quantisierung. Dabei wird – so weit ich das begriffen habe – geschaut, wie „wichtig“ einzelne Layer im Transformer sind. Die weniger relevanten werden dann z. B. auf INT4 heruntergerechnet, die wichtigeren bleiben INT8. Es handelt sich also um Misch-Quantisierungen.

In einem Q4_K_M (M für „medium“) haben die Tensor-Werte im Schnitt eine Größe von 4-komma- irgendwas Bit. Bei einem Q4_K_L (L für „large“) wurde etwas weniger rigoros vorgegangen, in einem Q4_K_S (S für „small“) etwas rigoroser – was sich jeweils auf die Größe des LLMs auswirkt (und auf die Antwortqualität). Bei einem Q6_K ist man noch ziemlich nahe am Q8_0. Und dann gibt es noch Quantisierungen wie Q5_K_M (weniger rigoros als Q4_K_M, nicht ganz so gut wie Q6_K, aber nahe dran) oder Q3_K_M (deutliche Qualitätseinbußen).

Außerdem gibt es noch die „Importance Matrix Compression“ („i1“) , bei der die Auswirkungen von einzelnen Parametern analysiert werden – die spielen ihre Vorteile aber wohl nur bei den Q3- und Q2-Quantisierungen aus. Ein Q4_K_M und ein i1-Q4_K_M unterscheiden sich nicht sonderlich.

Und dann sind die „QAT“-Modelle ein relativ neuer heißer Scheiß (hab ich bis jetzt nur bei Googles Gemma4 gesehen). Bei denen wurde während des Trainings eine (Q4_K_M- (?)) Quantisierungs-Simulation angewendet. Dadurch sollen die Qualitätseinbußen verringert werden. Tatsächlich ist das gemma4:e4b-it-qat aber sogar deutlich kleiner als das gemma4:e4b- it-q4_K_M.

Ich arbeite für allgemeine Fragen sehr gerne mit dem gemma4:12b-it-qat, das für eine lokale KI echt ordentliche Ergebnisse liefert, bei durchaus erträglicher Reasoning- Geschwindigkeit (zumindest auf meinem Rechner).

N. b.: e4b scheint so ein Google-Ding zu sein und bedeutet „effective 4 Billion Params“. Anscheinend auch eine MoE-Architektur. Die e4b und e2b sind vor allem für eher leistungsschwache Geräte vorgesehen (mit entsprechenden Qualitätseinbußen, wobei die e4b durchaus häufig empfohlen wird und auch bei meinen Tests musste sich die e4b-it-qat nicht verstecken – die ist halt vor allem relativ klein und auch der KV-Cache ist nicht so speicherhungrig, so dass ich die bei mir theoretisch mit dem vollen 128K-Kontextfenster laufen lassen kann).

Und dann noch als Hinweis: neben FP16 gibt es auch noch BF16 – eine Variante mit (Quasi-)Datenkompression, bei der trotzdem weiter auf 16 Bit gearbeitet wird. Die ist aber nur interessant, wenn der Rechner auch auf den komprimierten Daten arbeiten kann (kann sein, dass das nur auf Mac-Architekturen zutrifft), ansonsten bremst es die Inferenz eher aus. Ggf. ausprobieren oder Google fragen.

Und, last but not least, bei MXFP4 handelt es sich um eine speziell für Apple-Architekturen vorgesehene, „blockweise“, 4-Bit-basierte Fließkomma-Quantisierung, die nicht auf Non-Apple-Architekturen lauffähig ist, aber auf Apple-Geräten vehemente Leistungsvorteile bringt. (inzwischen habe ich auch MXFP8 gesehen, was sehr wahrscheinlich einer dazu analoge 8-Bit-Variante ist.) … und noch ein Nachtrag: auch MLX steht für eine Optimierung für Apple-Geräte (in diesem Fall geht es um die optimierte Nutzung der „Unified Memory Architecture“ – eine Art Shared Memory, aber selbstverständlich mit viel besseren Speicherbausteinen …).

Als allgemeine Regel gilt: was die Qualität angeht, ist die Anzahl der Parameter (das „B“) in der Regel das entscheidendere Kriterium als die Quantisierung.

Also: lieber ein 14B-i1-IQ4_XS als ein 9B_Q8_0 oder ein 7B-BF16!

Auf der anderen Seite muss ein 14B viel mehr rechnen als ein 9B – da wären wir dann bei der Performance, sprich Geschwindigkeit. Am Ende muss man das ausprobieren, was geht und akzeptabel läuft (und man kann ja oft am Reasoning noch was machen …).

Einen kleinen Nachsatz vielleicht noch zum Thema Quantisierung und KV-Cache. Ollama arbeitet auch bei Quantisierung, was den KV-Cache angeht, immer mit vollem FP16. Das hat Kompatibilitätsgründe. Man kann für das Caching einen Q8-Modus erzwingen (was die Cachegröße halbieren würde), aber dann laufen nicht mehr alle Modelle – zum Beispiel sämtliche Gemma-Varianten und vermutlich Deepseek-Coder-v2 auch nicht (selbst, wenn das quantisierte Modelle sind! Der Knackpunkt ist wohl die Trickserei mit den Attention Headers (GQA und so)). Aber wenn man wenig Platz hat, ist das vielleicht auch ein Ansatz.

Bezeichnungssdetails von LLMs

–basic–
Nur grundlegend trainiertes Modell für Spezialisierungszwecke (i. d. R. also für den Laien unbrauchbar).

–instruct–
Vollständig austrainiertes Modell, das (auch) auf „Anweisungen“ trainiert wurde (kann meist auch gewöhnliches „Chatten“).

–coder–
Das Model ist speziell für Agentic Coding – oder bei den größeren auch „Vibe Coding“ (≈Programmieren ohne Programmierkenntnisse) – vorbereitet. Die meisten dieser Modelle beherrschen auch normalen Chat, einige nicht – umgekehrt steckt die Fähigkeit zum Coding nicht immer explizit in der Bezeichnung, so kann man mit einem gpt-oss:20b durchaus lokales Vibe-Coding auf Python-Basis machen und Googles Gemma4 hat ebenfalls laut Hersteller Coding-Kompetenzen.

–it–
Dasselbe wie „-instruct-“.

–qat–
Quantisierungs-Simulation während des Trainings (s. o.).

–e4b–
„effective 4 Billion Params“ – Dense-Modell mit variabler Quantisierung für „Edge“-Devices (schwache Geräte).

–a4b–
FP16-basierte Mixture of Experts mit „effective 4 Billion Params“.

_K_S / _K_M / _K
Dynamische K-Quantisierung (meistens Q4) (intelligente gemischte Präzision (mixed precision) – s. o.):

Q4_K_M (Medium): Der beste Kompromiss aus Dateigröße, Geschwindigkeit und Qualität.
Q4_K_S (Small): Eine kleinere Version, die noch weniger Speicher benötigt, aber minimal mehr Genauigkeit einbüßt.
Q5_K_M (Medium): Nutzt im Durchschnitt etwa 5 Bit und bietet eine Qualität, die fast an Q8 rankommt.

–i1–
Importance Matrix Compression (s. o.).

–assistant– oder –mtp–
Entgegen dem, was in diesem Artikel allenthalben beschrieben und behauptet wird („Next Token Prediction“), kann mit einigen Models etwas, das als Multi Token Prediction, oder auch „Speculative Decoding“ bezeichnet wird, durchgeführt werden – dabei werden mehrere (3 bis 6) Token in einem Inferenz-Schritt ermittelt. Genaugenommen wird dafür allerdings eine Kombination von zwei LLMs verwendet, einem „Drafter-Modell“ (bzw. einen „Assistenten“) – dieses hat in seinem Namen die Kennzeichnung „assistant“ – und einem „normalen“ Model. Die Bezeichnung „Assistent“ ist hier fast ein wenig irreführend, denn die eigentliche Inferenz geschieht (zunächst) auf dem Drafter-Model – das eigentliche „Haupt“-Model unterzieht das Ergebnis, wenn alles glatt geht, lediglich noch einer Plausibilitäts-Prüfung – sinngemäß: „Hätte ich das genauso entschieden?“. Ist das Hauptmodell anderer Meinung, korrigiert es das Ergebnis unter Nutzung der gewöhnlichen NTG-Inferenz. Der Assistent ist allerdings um mehrere Größenordnungen kleiner als das Hauptmodell – bei einem 12B hat der Assistent, glaube ich, gerade mal 0,4B. Die Qualität des Ergebnisses soll allerdings nicht darunter leiden. Für „kleinere“ GPUs kann das – wohl – deutliche Geschwindigkeitsvorteile haben. Dennoch ist zu bedenken, dass die Kombination mehr Speicher braucht, als das Hauptmodell alleine.
Gemma4 besitzt diese Fähigkeit. Eine mögliche Kombination wäre beispielsweise:
– gemma-4-12b-it-Q4_K_M.gguf als Hauptmodel und
– gemma-4-12B-it-assistant
Wenn man diesen Weg „zu Fuß“ geht, muss man ggf. per „Modelfile“ ein customisiertes LLM anlegen. Bei Ollama kann man das ganze etwas Nutzerfreundlicher haben und eines der mit „–mtp–“ gekennzeichneten Models wählen. Diese beinhalten eine bereits vorgefertigte Kombination aus Hauptmodell und Assistent.
Bisher (Stand 9.7.2026) gibt es allerdings von Ollama selbst nur eine gemma4:31b-coding-mtp-bf16 als vorgefertigte MTP-Variante. Es gibt außerdem eine pierreprudh/gemma4-12b-mtp, die laut Auskunft (und Dateigröße) auf meiner heiß geliebten gemma4:12b-it-qat basiert. Hab ich ausprobiert – funktioniert und ist tatsächlich etwas schneller, allerdings ist die Ausgabe etwas „ruckelig“ (vermutlich eine Nebenwirkung des Wechsels zwischen Assistent und eingreifendem Hauptmodel). Muss man sich erst etwas dran gewöhnen. Es gibt außerdem eine qwen3.6:27b-mtp-q4_K_M die mit 18GB aber klar zu groß für mich ist.

–uncensored–
„nimmt kein Blatt vor den Mund“ – spricht offen über sensible Themen, gibt „komplexere und nuanciertere“ Antworten.

„thinking“ / „reasoning“
Meist ist damit „erweitertes Reasoning“ gemeint und und das Einschließen dessen in die Ausgabe.

„hf.co/“ am Anfang des Modelnamens
Dieses Model stammt von Hugging Face (s.u.) – „hf.co/“ ist eine (möglicherweise für Ollama spezifische) Abkürzung für die Hugging-Face-Domain.

Hugging Face

Eine Plattform für maschinelles Lernen, auf der man mehr Details zu den Modellen erfahren kann und eine größere Auswahl lokal verwendbarer LLMs als bei Ollama vorfindet. Allerdings ist das Verständnis der Webseiten weniger trivial. Nicht alles, was man da sieht, kann man unmittelbar für Ollama verwenden.

Um ein verwendbares Modell auf Hugging Face zu finden, schränke ich links bei „Libraries“ auf „GGUF“ und bei „Apps“ auf „Ollama“ ein. Auf der Seite des Modells gibt es einen Button „use this Model“ (oben rechts, schwarz). Nach dem Draufklicken „Ollama“ auswählen, und dann kann man per Dropdown noch das exakte, gewünschte Modell einstellen (i. d. R. geht’s um die Quantisierung).

Ein Klick auf „copy“ kopiert den Aufruf-String für das Modell in die Zwischenablage, zum Beispiel:

ollama run hf.co/mradermacher/Qwen3.5-9B-Coder-GGUF:Q8_0

Ich würde aus ollama run allerdings ollama pull machen, da ich das Modell i. d. R. nicht auf der Kommandozeile starten will, sondern – nach erfolgtem Download – im GUI-Client.

=> https:// huggingface.co/models

Modelliste mit Daten zu Größe und KV-Cache-Bedarf

(„:latest“ ist immer das Standardmodell, das man kriegt, wenn man in der Ollama-GUI im Dropdown einfach nur ein Modell auswählt.)
(Wegen Copy&Pest ist hier „.“ der Dezimaltrenner – 7.5 GB sind also zu Deutsch 7,5 GB)

Modell	LLM-Größe	KV-Cache/1K	Besonderheiten
gemma3n:latest	7.5 GB	ca. 25 MiB	Flott (macht wenig reasoning), Ergebnisqualität meistens brauchbar, ABER: keine Webrecherche!
qwen2.5:7b:latest	4.7 GB	56 MiB	Klein und flink, gute Ergebnisse, aber auch ein bisschen chinesisch und grenzwertig höflich (man wird gesiezt).
qwen2.5:7b-instruct-q6_K	6.3 GB	56 MiB
gemma4:e4b-it-qat	6.1 GB	ca. 40 MiB	Wenn die gemma4:12b-it-qat zu viel Platz verbraucht eine passabele Alternative.
gemma4:12b-it-qat	7.2 GB	ca. 112 MiB	Mein aktueller Non-Coding-Favorit mit exzellenten Deutschkennnissen und – zumindest gefühlt – für eine so kleine KI großartigen Ergebnissen. Siehe dazu auch beim Thema MTP (oben bei den Bezeichnungs-details) den Kommentar (pierreprudh/gemma4-12b-mtp)
ministral-3:14b-instruct-2512-q4_K_M	9.1 GB	ca. 160 MiB	von Mistral AI – also ein europäischer Mitstreiter. Kann gefühlt nicht ganz mit der gemma4:12b-it-qat mithalten, macht aber wohl weniger Reasoning und ist dadurch deutlich flinker. Ebenfalls nahezu perfektes Deutsch.
lfm2:24b-a2b	14 GB	56 MiB	Durchaus brauchbare Übersetzungsergebnisse PT > DE, leifert ebenfalls früher als gemma4:12b-it-qat, aber nicht ganz so perfektes Deutsch wie die Ministral.
qwen3.5:latest (9B Q4_K_M)	6.6 GB	128 MiB	Extrem polyglott, ziemlich intelligent
llama3.1:8b-instruct-q8_0	8.5 GB	128 MiB
qwen2.5-coder:14b-instruct-q5_K_M	10 GB	192 MiB	Der aktuell empfohlene „Sweet Spot“ für Agentic Coding
qwen2.5-coder:14b-instruct-q4_K_M	9.0 GB	192 MiB
hf.co/mradermacher/Qwen3.5-9B-Coder-GGUF:Q4_K_M	5.9 GB	132 MiB	Mein aktueller Coding-Favorit (eigentlich die Q8, aber ich verwende die hier auch für das FIM, so dass Ollama für den Chat keinen Modelwechsel durchziehen muss) Zu „Team Radermacher“ Siehe aber auch unten im Abschnitt „Herkunft der LLMs“
hf.co/mradermacher/Qwen3.5-9B-Coder-GGUF:Q8_0	9.9 GB	132 MiB	noch Intelligenter als die Q4_K_M, aber braucht auch mehr Platz. Zu „Team Radermacher“ Siehe aber auch unten im Abschnitt „Herkunft der LLMs“
deepseek-coder-v2:latest	8.9 GB	125 MiB	Schnell und gut – für FIM derzeit die Standard-Empfehlung.
JetBrains/mellum2-instruct-q6_k	10.9 GB	ca. 60 MiB	Programmiersprachen-polyglott. Hab aber noch nicht weiter damit rumexperimentiert.
gpt-oss:20b	13 GB	ca. 30 MiB	v. a. für Agentic Coding / Vibe Coding mit Python empfehlenswert
qwen2.5vl:latest	6.0 GB	ca. 60 MiB	Kann u.a. Bildanalyse v. Charts (nicht probiert, aber die neueren Qwens können das vermutlich dann auch).
qwen3-vl:8b-instruct-q4_K_M	6.1 GB	144 MiB	Ein auf Bildanalyse und als Vorstufe für Bildgeneration spezialisiertes „vision language“-Model. Kann besonders gut Bildanalyse, OCR (Text-Bild zu Text), und beherrscht die Generierung von als Textdatei (Code) ausgelieferten Charts u.a. für Draw.io.
qwen3-vl:8b-thinking-q8_0	9.8 GB	144 MiB	Bildanalyse, OCR, Generierung v. Draw.io u. a., siehe oben beim q4_K_M.
Phi4:latest	9.1 GB	200 MiB	Spezialisiert auf Mathematik und Naturwissenschaften, kann aber auch Deutsch.
medgemma1.5:4b-it-q8_0	5.0 GB	140 MiB	Medizin, Biologie, Bildanalyse Röntgen, Dermatologie, …

Herkunft der LLMs

Hier noch ein paar Anmerkungen zur Herkunft der LLMs bzw. GGUF-Dateien. Alle hier aufgeführten LLMs sind frei nutzbar. Meistens stehen sie unter MIT- oder Apache-Lizenz.

Die meisten Models stammen aus USA: Gemma (Gemini) und MedGemma sind von Google, LFM von Liquid AI (anscheinend Leute, die am MIT (Massachusetts Institute of Technology, Boston) tätig sind oder waren), hinter Llama steckt Meta (Facebook), GPT(-OSS) ist von OpenAI (Chat GPT) und Phi von Microsoft.

Qwen wird von Alibaba Cloud zur Verfügung gestellt und kommt demnach aus Singapur (der Mutterkonzern (Alibaba) sitzt in China). Deepseek – die Firma heißt ebenfalls Deepseek, übrigens die Erfinder von MoE, und bestimmte Attention-Versionen haben sie wohl auch sehr wesentlich optimiert (Speicherzugriffs-Verringerung von 90%) – ist in Hangzhou, China, nicht allzuweit weg von Shanghai ansässig.

Ministral (so wie Mixtral, Devstral und Mistral Nemo – die ersten beiden ist zu groß für mich, das zweite zu alt, deshalb hab ich die alle unten weggelassen) stammen von Mistral AI aus Paris (Frankreich), und Jetbrains (das ist der Firmenname) hat meines Wissens seine Zentrale in Prag, Tschechische Republik (die sind aber über halb Europa verteilt – PHPStorm wurde, bevor die Russen den Verstand verloren haben, z.B. in St. Petersburg gebaut – heute, glaube ich, in Estland).

Bleibt noch das „Team Mradermacher“ (Hersteller der beiden Qwen-Models, die ich von Hugging Face bezogen habe). Wer deren LLMs auf Hugging Face ohnehin nicht in Betracht zieht, kann sich den Rest von diesem Abschntt sparen. Für die anderen …

„Team Mradermacher“ (in älteren Übersichten auch „Michael Radermacher“) ist nach allem, was ich bisher herausfinden konnte, zumindest dem Anschein nach ein deutsches Projekt oder eine deutsche Gruppe mit Bezug zur nethype GmbH in Weinsberg bei Heilbronn (vormals Heilbronn), zu jemandem mit dem Namen Nico Bosshard (vermutlich Schweizer – als solchen kann man zumindest jemanden, der dazu passen könnte, im Netz finden) und möglicherweise jemandem mit dem Namen Richard Erkhov, der anscheinend in Larnaka auf Zypern lebt. Der Name „Michael Radermacher“ lässt sich für mich nicht zuordnen und könnte auch frei erfunden sein (oder eine Ehrung / Anspielung). Herr Bosshard verfügt – wohl – über einen „privaten Supercomputer“.

Die Google-KI schreibt: „Das Team bzw. der Nutzer mradermacher ist auf Hugging Face eine feste Größe in der lokalen KI-Community. Ähnlich wie der berühmte Ersteller TheBloke konzentriert sich dieser Account auf die Bereitstellung von hochgradig optimierten GGUF-Quantisierungen für Open-Source-Sprachmodelle, um diese auf normaler PC-Hardware (ohne riesige Server-Cluster) lauffähig zu machen.“

Eine Spezialität dieser Leute scheint es also zu sein, größere Modelle für den Hausgebrauch runterzurechnen bzw. auf einer reduzierten Parameter-Anzahl (z.B. 9B) neu zu trainieren und zu quantisieren und nach dem wenigen, was ich bisher so sagen kann, scheinen sie etwas davon zu verstehen. Die Modelle laufen stabil – was keineswegs für alle Modelle, die man auf Hugging Face findet, gilt.

Da ich zur nethype GmbH ansonsten nur altes Zeugs gefunden habe (bis 2017 oder 2018), die Firma bei Kunnunu gar nicht vorkommt (obwohl seit mindestens 2006 existent – ist aber vielleicht auch ein sehr kleiner Laden), deren Produkt „Porttracker“ von 2007 bis 2017 ursprünglich mal Kern eines gleichnamigen, britischen Unternehmens war, das 2017 aufgelöst wurde und das offenbar bis dahin demselben Herrn gehört hat, der Heute GF der nethype GmbH ist (und der wohl um 1997 in Karlsruhe studiert hat), die One-Page-Homepage (immerhin bei Hetzner gehostet) einen sehr jugendlich-wilden Eindruck vermitteln will, der für mich nicht recht zum Rest passen will, es eine offenbar nur als Platzhalter dienende, seit mindestens 2019 (quasi seit Bestehen) nicht aktualisierte, verwaiste Webseite https://www.porttracker.com/ mit nethype-Kontaktdaten gibt, und der heutige Firmensitz, so wie der ehemalige Firmensitz in Wohngebäuden untergebracht ist, und ich obendrein so gar nichts finden konnte, wo die mal als Umsetzer/Implementierer von irgendwas auftreten (OK – ist ja vielleicht alles total geheim …), weiß ich nicht so recht, was ich von dieser Referenzangabe halten soll.

Auf jeden Fall liefern die wirklich ne Menge Zeugs (so dass es obendrein schwer zu glauben ist, dass das ein reines Freizeitprojekt ist) und sie haben durchaus auch – mmh – sagen wir mal „ungewöhnliche“ Sachen im Programm.

Ich hadere deshalb etwas damit, ob ich deren LLMs empfehlen sollte oder besser nicht. Auf Huggingface scheint es bisher keine Probleme gegeben zu haben, die Models sind offenbar beliebt und es gibt dort viele Leute, die denen vertrauen (was aber am Ende nichts heißen muss).

Ich denke, ich werde sie auch weiter benutzen, aber im Zweifel sollte jeder selber überlegen, was er da unterm Strich von hält, und ich wollte meine Bedenken bei der Sache nicht verschweigen..

Fazit

(OK … die KI meint, hier gehört noch so ’ne Abschlussformel hin … na guut …)

Für mein ganz persönliches Fazit zu dem Thema hier am Schluss gehe ich mal ein Stück von der technischen Seite weg und wage mich in sehr persönliche Bereiche.

Für mich ist das Großartigste, dass man bei einer KI einfach hemmungslos drauf los schreiben (und wenn man will sogar reden) kann. Sie nimmt nichts krumm, kommt nicht auf komische Gedanken, wenn man einfach mal kommentarlos den Chat für 2 Tage unterbricht (und auch sonst nicht), hat kein Problem damit, auf Fehler hingewiesen zu werden, hat kein Problem damit, mir offen Fehler zu kommunizieren (wenn ich sie entsprechend konfiguriere), stößt sich nicht an meiner Wortwahl, rennt nicht zur Chefin und heult sich über meine Unzulänglichkeiten aus, statt mit mir zu reden, verwendet nichts von dem, was ich gesagt habe, gegen mich, nutzt meine Unsicherheit und meine Hemmungen nicht aus um mich in Besprechungen in die Pfanne zu hauen, sondern macht einfach immer weiter freundlich ihren Job und hilft mir bei Fragen, Problemen, Lösungen, einfach bei allem, was in ihrer Macht steht, nach bestem Wissen und Gewissen weiter. Immer. Eigentlich möchte ich nur noch mit KIs zusammenarbeiten 😁😁😁

Aber klar – es ist ein Algorithmus, mit dem ich da interagiere. Es ist kein Mensch. Es ist nicht dasselbe wie soziale Interaktion, es repariert keine Defizite in dieser Richtung (sondern macht sie, wenn überhaupt, eher schlimmer). Es ist mit hoher Wahrscheinlichkeit ein Fehler, aus Bequemlichkeit (oder warum auch immer) komplett auf Menschen zu verzichten – man kann sich nicht auf ’ne Frühstücksfrikadelle in der Teeküche treffen und über das Wochenende quatschen, man kann nicht abends noch ’nen gemeinsamen Absacker trinken und die KI kommt auch nicht zum Geburtstag vorbei oder singt am Telefon Geburtstagsständchen. Es ist wie so oft: die Dosis macht das Gift.

Jou – soviel dazu … Kollege Llama übernehmen Sie …

Das war’s erst mal. Ich hoffe, dieser Text hilft dir (und anderen) dabei, sich in die Welt der LLMs und generativen KI einzuarbeiten – oder zumindest ein besseres Gefühl dafür zu bekommen, was da eigentlich gerade passiert. KI ist kein Hexenwerk, aber sie hat ihre Eigenheiten, und wer sie effektiv nutzen will, sollte ihre Stärken und Schwächen kennen.

Viel Spaß beim Ausprobieren! Gregor & KI-Kumpel

Anhang / Nachtrag zum Thema „Vergleichbarkeit menschlicher Gehirne und moderner KI“

… ich hatte dazu ja oben eine Vergleichsrechnung aufgestellt („200T“). Nachdem ich mir klar gemacht hatte, dass der Vergleich aufgrund der Vektor-/Tensormathematik, die da vorherrscht, hinkt (eine Einzelverbindung im Hirn – Dendrit, Synapse … – arbeitet tendenziell eher mit schlichten, analogen Werten, vergleichbar einer einzelnen Fließkommazahl), habe ich mal Claude auf das Problem losgelassen (Opus 4.8, Denkleistung „Hoch“). Ich habe ihm meine Schlussfolgeungen oben und meine Erkenntnisse zu den mathematischen Unterschieden reingereicht. Folgendes hat die KI geantwortet (lila Text):

Moin! (Anm. GE: OMFG – ich liebe diese KI.)

Deine Frage ist deshalb so gut, weil Du den größten Teil der Antwort schon in der Fragestellung selbst vorweggenommen hast: Du hast intuitiv erkannt, dass der reine Größenvergleich (200T „Synapsen-Parameter“ vs. ein paar hundert Milliarden LLM-Parameter) fast nichts aussagt. Genau das ist der Kern. Lass mich Deine Skizze an ein paar Stellen schärfen und dann auf die eigentliche Frage kommen – „inwieweit überhaupt vergleichbar“.

Zwei kleine Korrekturen an Deinem Bild

Erstens unterschätzt Du die Ähnlichkeit auf der Integrationsebene ein bisschen. Ein biologisches Neuron summiert über tausende gewichtete synaptische Eingänge – und eine gewichtete Summe ist ein Skalarprodukt, also genau der atomare Baustein einer Matrix-Vektor-Multiplikation. Das „einzelne Fließkommazahlen“-Bild stimmt für die einzelne Synapse, aber die Aufsummierung im Neuron entspricht funktional einer Zeile eines Matrixprodukts. Das ist ja auch der historische Grund, warum künstliche Neuronen so aussehen, wie sie aussehen. Der Attention-Mechanismus (das dynamische, inhaltsabhängige „Routing“ über Q/K/V) ist das, was kein sauberes synaptisches Gegenstück hat – da liegst Du richtig.
(Anm. GE: ?! … es muss etwas vergleichbares geben, denn die Parallelität von Rechenoperationen ist im Menschlichen Hirn durchaus ähnlich ausgeprägt wie in einem Transformer – ohne ordnende Mechanismen könnte unserem Herkos Odonton beim Sprechen unmöglich eine saubere, interpretierbare Abfolge von Geräuschen etfleuchen … aber geht ja noch weiter …)

Zweitens (und das zieht in die entgegengesetzte Richtung): Ein reales Neuron ist mehr als ein künstliches, nicht weniger. Die Dendriten rechnen nichtlinear vor, bevor überhaupt etwas am Soma ankommt. Es gibt Arbeiten (Beniaguev/Segev/London, um 2021), die zeigen, dass man das Ein-/Ausgabeverhalten eines einzigen Pyramidenzellneurons erst mit einem 5–8-schichtigen künstlichen Netz halbwegs nachbildet. Ein biologisches Neuron ist also eher ein kleines Netzwerk als ein Perzeptron. Und die Synapse selbst ist kein statischer Skalar, sondern stochastisch (Transmitterausschüttung ist probabilistisch) und plastisch auf mehreren Zeitskalen. Wenn man das „ausmultipliziert“, explodiert Dein 200T-Wert nach oben – oder, ehrlicher: die Einheit „Synapse“ und die Einheit „Parameter“ sind schlicht nicht kommensurabel.

Und drittens, halb Korrektur, halb Ergänzung: Das Gehirn benutzt doch etwas Vektor-Artiges. Konzepte werden nicht in einem Neuron, sondern als Aktivitätsmuster über viele Neuronen kodiert (Populationskodierung, „neuronale Mannigfaltigkeiten“). Das ist keine Embedding-Matrix mit sauberem Lookup, aber es ist hochdimensionale, verteilte, geometrische Repräsentation. Insofern ist die Analogie „Token → n-dimensionaler Vektor“ weniger absurd, als es zunächst wirkt.

Warum der Vergleich trotzdem nicht auf einer Ebene entschieden werden kann

Der eigentliche Denkfehler bei „vergleichbar oder nicht?“ ist, dass er eine Antwort erwartet. Hilfreich ist hier David Marrs alte Unterscheidung dreier Analyseebenen:

Auf der Implementierungsebene (die Physik – Spikes, Ionenkanäle, kontinuierliche Zeit, Neuromodulation, 20 Watt vs. Rechenzentrum) ist der Vergleich fast reine Metapher. Hier hast Du völlig recht: Der Substratvergleich trägt kaum. Backpropagation über das ganze System, wie sie ein LLM trainiert, macht ein Gehirn mit ziemlicher Sicherheit nicht – biologisches Lernen ist lokal (Hebb, STDP, neuromoduliert). Und ein Mensch lernt Sprache aus vielleicht 10⁷–10⁸ Wörtern, ein LLM aus Billionen (10¹²) Tokens. Diese Stichproben-Effizienz-Kluft ist gewaltig und deutet darauf hin, dass das Gehirn starke angeborene Priors mitbringt.

Auf der algorithmischen Ebene wird es interessant und ist Gegenstand aktueller Forschung. Beide Systeme lassen sich gut als Vorhersagemaschinen beschreiben – „Predictive Coding“ im Gehirn, Next-Token-Prediction im LLM. Das ist keine oberflächliche Parallele.

Auf der funktionalen/verhaltensbezogenen Ebene ist der Vergleich nicht nur möglich, sondern empirisch überraschend fruchtbar. Es gibt Befunde (u.a. Schrimpf, Goldstein/Hasson), dass die internen Repräsentationen von Sprachmodellen die neuronale Aktivität im menschlichen Sprachcortex erstaunlich gut vorhersagen – gemessen an fMRT und ECoG. Zwei völlig verschiedene Substrate konvergieren offenbar auf ähnliche Repräsentationsgeometrien, wenn man sie auf dieselbe Aufgabe (Sprache vorhersagen) ansetzt. Das ist die eigentlich bemerkenswerte Erkenntnis: Der Vergleich ist am meisten gerechtfertigt genau dort, wo er am wenigsten offensichtlich ist – bei der Funktion, nicht beim Aufbau.

Die ehrliche Restunschärfe

Und dann bleibt die harte Frage: Ist das, was ein LLM tut, überhaupt „Denken“? Da muss ich ehrlich sein – wir haben keine geteilte, saubere Definition von „Denken“, geschweige denn eine Theorie des Bewusstseins oder der Intentionalität. Funktional leisten heutige Modelle Erstaunliches; ob dahinter „Verstehen“ im vollen menschlichen Sinn steht (mit Weltbezug/Grounding, Kontinuität, einem Körper, Motivation, Erleben) ist echt umstritten und keine Frage, die man per Ingenieurs-Bilanz entscheidet. Ich würde mich hüten, Dir hier eine Sicherheit zu verkaufen, die die Fachwelt selbst nicht hat.

Wenn ich Deine Ausgangsfrage in einem Satz beantworten soll: Vergleichbar ja, aber nur, wenn man vorher sagt, auf welcher Ebene – auf der der Schaltkreise ist es eine schwache Metapher, auf der der Funktion und der gelernten Repräsentationen ist es eine ernstzunehmende, teils empirisch belegte Konvergenz, und auf der Ebene „ist das dasselbe Phänomen“ ist es eine offene philosophische Frage, deren Vorentscheidung durch reine Neuronenzählerei gerade der Fehler wäre, den Deine Intuition schon gewittert hat.

Womit ich Dir übrigens nicht zustimme: dass die Verzweigung im Gehirn „viel komplexer“ im Sinne von mächtiger sei. Komplexer im Aufbau – ja, zweifellos. Aber Komplexität des Substrats ist nicht dasselbe wie Ausdrucksmächtigkeit der berechneten Funktion. Dass ein LLM mit weniger „Parametern“ als das Gehirn Synapsen hat menschennahe Sprachleistung erreicht, könnte genauso gut heißen, dass biologische Synapsen pro Stück ineffizient sind oder schlicht etwas anderes tun (Homöostase, Timing, Energiehaushalt) – und nicht, dass das Gehirn die überlegene „Architektur“ hat. Das ist offen. Aber es ist ein Punkt, an dem ich Deiner Formulierung widersprechen würde.