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 ein kleiner, aber in letzter Zeit ziemlich in den Vordergrund getretener Teil von dem ausmacht, was mit „KI“ (bzw. „AI“) bezeichnet wird. Und ich muss sagen: yep, bei aller Skepsis und allen Bedenken – geiler Scheiß.

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/

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, (mit Einschränkungen) bauphysikalischen, 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 geologischen, geomorphologischen und hydrologischen Fragestellungen und bei allem, was Sicherheitsaspekte angeht (und Bauphysik ist da sicher mit drin), 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. ✔
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, weil sie nicht hinreichend mit Geo-Daten gefüttert ist (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 „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, dynamischen, komplexen, sich vor allem in der realen Welt abspielenden Szenarien zu tun, ist KI Dein Freund. Alles andere ist eher mühsam.

Rüstzeug für den Umgang mit KI

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 nicht um Wörter, sondern um etwas, das eher dem Konzept der „Morpheme“ aus der Linguistik (kleinste bedeutungstragende Einheiten bzw. Buchstabenkombinationen) nahekommt (also Bruchstücke von Wörtern). 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“.

Stell Dir einen 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 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 „Merkmalen“, aber auch hier gilt: eine Zahl an einer bestimmten Stelle (in einem bestimmten Feld) im Vektor bezieht sich jeweils auf immer dieselbe Eigenschaft.

Ein Tensor ist einem Vektor nicht unähnlich. Tatsächlich ist ein Vektor ein Tensor vom „Rang“ 1. 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“ ). 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 ein 3-dimensionale Anordnung von Zahlen, ein Zahlenwürfel. 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 vor allem Matritzen (Tensoren 2. Ranges), und Tensoren 3. Ranges eine Rolle. Und es spielt eine Mathematik eine Rolle, bei der Vektoren und Tensoren miteinander multipliziert (oder sonstwie miteinander „verkü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 (in der Biologie „Dendriten“?) – 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, wobei zu jedem von ihnen mehrere Verbindungen aus der vorgelagerten Schicht eingehen und Verbindungen zu mehreren Nodes in der Folgeebene von ihnen ausgehen.

Technisch gesehen sind die Linien (also die Verbindungen) in Wahrheit Tensoren (s.o.), über die der Vektor des einen Knoten in einen neuen Vektor umgerechnet und an den nächsten Knoten weitergereicht werden, 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 den Datenzustand in einer bestimmten Schicht des Netzes. 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 raus.

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 „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.

Transformer

… sind eine auf bestimmte Art strukturierte Form von neuronalen Netzen, in denen Layer, Header, Embedding 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).

Die Transformer bilden das Herzstück der aktuellen, großen Sprachmodelle – quasi den Wissensspeicher.

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 / Pretrained

„Vortrainiert“ bedeutet: Leute haben sich hingesetzt und ein neuronales Netz – also in unserem Fall einen Transformer – mit einer irren Menge an Daten gefüttert, immer wieder geschaut, ob der Transformer zu bestimmten Eingangsdaten korrekte Ausgangsdaten liefert und anschließend eine ziemlich aufwendige Mathematik angewendet („Backpropagation“– Algorithmen), um die Tensoren, also die Nervenzellen-Verbindungen bzw. Gewichte, immer besser zu justieren.

Tatsächlich müssen sie aber irgendwann damit aufhören und diesen Modus beenden, weil der Transformer sonst überangepasst wird (Overfitting). Overfitting bedeutet, 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.

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 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 nichts zu tun haben. Ein Hologramm ist zudem flach und „erinnert“ sich trotzdem an 3-dimensionale Informationen.

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.

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).

Mit anderen Worten: klar – die moderne KI ist bei vielen Aufgaben von der Geschwindigkeit her einem Menschen haushoch überlegen (u. a. weil sie viel weniger rechnet und weil sie das digital und elektronisch macht und keine im Vergleich dazu relativ gemächlich stattfindenden, biophysikalischen Prozesse ablaufen müssen), aber was die Gesamtheit der Möglichkeiten angeht, ist jeder bildungsferne Quärdenker, Armsbürger oder AfD-Wähler um Klassen besser ausgestattet als jede der leistungsfähigsten KIs auf dem Planeten. Muss man sich mal auf der Zunge zergehen lassen (und in Verzweiflung versinken angesichts der Tatsache, wie diese Leute damit umgehen).

LLM / Sprachmodell

Ein „Large Language Model“ 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) – das „Vokabular“ des LLMs.

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 Token aus ganz vielen Sprachen.

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 Sprachen 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 und Deutsch dabei. Ich habe mindestens ein Modell gesehen, das sich damit rühmt, auf über 200 Sprachen und Dialekte trainiert zu sein!

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.

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.

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 sie 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 quadratisch (O(n²)).

Da allerdings die Attention hier auch noch mit reinspielt und effektiv nicht einfach Vektoren, sondern bewertete Vektoren zwischengespeichert werden, und diese je nach Bauart der Attention(s) mehr oder weniger „eingedampft“ (komprimiert / verkleinert) werden, 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 (ganz plump: was ist Subjekt, was Objekt, welche Attribute gehören wohin, auf welche vorher genannten Teilaspekte bezieht sich eine Teilaussage … so Zeug halt).

Es gibt 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 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. 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.

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 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.

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. Es geht also um Datenschutz. Selbst wenn die Hersteller eines LLMs in den USA oder China sitzen – bei einem 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 ü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 in der einen oder anderen Form bei einigen). 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).

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 in dem Dingsda, wo auch der Batteriestand und die Uhrzeit und die „klapp mehr aus“-Ecke drin sind) 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 geht bei fehlender Information 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.

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 (scheint bei mir der Fall zu sein), 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.

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–
Spezialisiert für Agentic Coding vorbereitet (einige Modelle können auch normalen Chat, einige nicht).

–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.).

–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.

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), ABER: keine Webrecherche!
qwen2.5:7b:latest	4.7 GB	56 MiB	klein und flink
qwen2.5:7b-instruct-q6_K	6.3 GB	56 MiB
gemma4:e4b-it-qat	6.1 GB	ca. 40 MiB
gemma4:12b-it-qat	7.2 GB	ca. 112 MiB	mein aktueller Non-Coding-Favorit
ministral-3:14b-instruct-2512-q4_K_M	9.1 GB	ca. 160 MiB	Mistral AI
lfm2:24b-a2b	14 GB	56 MiB	sehr gute Übersetzungsergebnisse PT > DE
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
hf.co/mradermacher/Qwen3.5-9B-Coder-GGUF:Q8_0	9.9 GB	132 MiB
deepseek-coder-v2:latest	8.9 GB	125 MiB	schnell, für FIM empfohlen
JetBrains/mellum2-instruct-q6_k	10.9 GB	ca. 60 MiB	programmiersprachen-polyglott
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	Bildanalyse v. Charts
qwen3-vl:8b-instruct-q4_K_M	6.1 GB	144 MiB	Bildanalyse, OCR, Generierung v. Draw.io u. a.
qwen3-vl:8b-thinking-q8_0	9.8 GB	144 MiB	Bildanalyse, OCR, Generierung v. Draw.io u. a.
Phi4:latest	9.1 GB	200 MiB	Mathematik, Naturwissenschaft
medgemma1.5:4b-it-q8_0	5.0 GB	140 MiB	Medizin, Biologie, Bildanalyse Röntgen, Dermatologie, …

Fazit

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

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! 🚀