Was ist ein LLM? (aus IT-Sicht)

Über Large Language Models wird viel geschrieben, meist entweder als Heilsversprechen oder als Bedrohung. Für den praktischen Einsatz in der Softwareentwicklung ist beides wenig hilfreich. Nützlicher ist die nüchterne Frage: Was genau baue ich mir da in mein System ein, und wie verhält es sich im Betrieb?

Dieser Beitrag beschreibt ein LLM als das, was es aus IT-Sicht ist: eine Komponente mit klar benennbaren Eigenschaften, Kosten und Grenzen.

Tokens statt Wörter

Ein LLM verarbeitet keinen Text als Zeichen oder Wörter, sondern als Tokens. Ein Token ist ein häufig vorkommendes Textfragment, oft ein kurzes Wort oder eine Silbe. Das Wort „Optimierungsverfahren“ zerfällt so in mehrere Tokens, während „und“ ein einzelnes ist.

Das ist keine akademische Feinheit, sondern hat direkte Folgen im Betrieb:

• Kosten und Limits werden in Tokens gemessen, nicht in Zeichen. Wer mit Zeichen rechnet, verschätzt sich.
• Deutsch und Programmcode brauchen tendenziell mehr Tokens als englischer Fließtext. Derselbe Inhalt kostet je nach Sprache unterschiedlich viel.
• Die Token-Zahl eines Prompts lässt sich vorab bestimmen und sollte in kostensensiblen Anwendungen auch gemessen werden.

Parameter und Vorhersage

Der eigentliche „Verstand“ des Modells steckt in seinen Parametern, den Gewichten des neuronalen Netzes. Aktuelle Modelle haben Milliarden davon. Diese Zahl bestimmt grob die Fähigkeiten, vor allem aber den Speicherbedarf im Betrieb.

Die Aufgabe des Modells ist überraschend eng definiert: Es sagt, gegeben den bisherigen Text, das nächste Token vorher, genauer eine Wahrscheinlichkeitsverteilung über alle möglichen nächsten Tokens. Diese Vorhersage wird angehängt und der Vorgang wiederholt sich Token für Token. Was wie ein Gespräch aussieht, ist im Kern wiederholtes P(nächstes Token | bisheriger Text).

Daraus folgt eine wichtige Einsicht: Das Modell speichert kein Wissen wie eine Datenbank und rechnet nicht wie ein Programm. Es reproduziert statistische Muster aus den Trainingsdaten. Für die Architektur einer Anwendung ist das die zentrale Eigenschaft.

Das Kontextfenster

Prompt und Antwort teilen sich ein begrenztes Kontextfenster, ebenfalls in Tokens gemessen. Aktuelle Modelle reichen von einigen tausend Tokens bis zu rund einer Million; kleinere Modelle liegen darunter.

Für die Praxis heißt das: Alles, worauf sich das Modell beziehen soll, muss in dieses Fenster passen, also die Systemanweisung, der bisherige Gesprächsverlauf, eingefügte Dokumente und der Platz für die Antwort. Ein langes Dokument oder eine ganze Codebasis passt selten vollständig hinein. Die üblichen Antworten darauf sind Kürzen, Zusammenfassen oder gezieltes Nachladen relevanter Ausschnitte. Letzteres ist der Kern von Retrieval-Augmented Generation, ein eigenes Thema.

Ein Zahlenbeispiel macht das greifbar. Als grobe Faustregel entspricht ein deutsches Wort etwa 1,3 bis 2 Tokens. Ein Fenster von 128 000 Tokens fasst damit ungefähr 80 000 bis 95 000 Wörter. Davon geht laufend etwas ab: eine Systemanweisung von vielleicht 500 Tokens, ein Gesprächsverlauf von schnell einigen tausend und ein reservierter Platz für die Antwort, etwa 4 000 Tokens für eine ausführliche. Ein eingefügtes Dokument von 10 000 Wörtern belegt bereits rund 15 000 Tokens. Man sieht schnell: Das Budget ist endlich, und jedes zusätzliche Dokument konkurriert mit dem Platz für die Antwort.

Die Kosten skalieren mit den Tokens, die hineingehen, und denen, die herauskommen. Ein großes Kontextfenster ist also kein Freifahrtschein, sondern ein Kostenfaktor.

Inferenz: was beim Antworten passiert

Der Ablauf einer Anfrage ist immer gleich:

1. Der Text wird in Tokens zerlegt.
2. Das Netz berechnet eine Wahrscheinlichkeitsverteilung für das nächste Token.
3. Aus dieser Verteilung wird ein Token ausgewählt (Sampling), gesteuert unter anderem über die Temperatur, die bestimmt, wie „mutig“ gewählt wird.
4. Das Token wird angehängt, weiter bei Schritt 2, bis ein Stopp-Kriterium greift.

Zwei Kennzahlen sind hier betrieblich relevant: die Zeit bis zum ersten Token und die Ausgabegeschwindigkeit in Tokens pro Sekunde. Beide bestimmen, wie sich eine Anwendung anfühlt, und beide gehören ins Monitoring. Wichtig außerdem: Identische Eingaben liefern nicht garantiert identische Ausgaben. Wer Reproduzierbarkeit braucht, muss das aktiv einplanen.

Betrieb: Größe, Hardware, lokal oder gehostet

Die Parameterzahl entscheidet über den Speicherbedarf. Große Modelle brauchen entsprechend viel Speicher auf der GPU (dem Grafikprozessor). Quantisierung senkt diesen Bedarf, indem die Gewichte mit geringerer Genauigkeit gespeichert werden, meist mit vertretbarem Qualitätsverlust.

Grundsätzlich gibt es zwei Betriebsformen:

• Lokal oder selbst gehostet, etwa mit Werkzeugen wie Ollama oder llama.cpp. Vorteile sind Datenhoheit und Kontrolle, der Preis ist Hardware und Wartung.
• Über eine gehostete API (eine Programmierschnittstelle, die man über das Netz anspricht). Vorteile sind einfacher Einstieg und starke Modelle, der Preis ist Abhängigkeit und der Umstand, dass Daten das eigene System verlassen.

In regulierten Umfeldern, etwa im medizinischen Bereich, ist diese Entscheidung selten frei. Wo Daten das Haus nicht verlassen dürfen, fällt die Wahl auf lokalen Betrieb, mit allen Konsequenzen für Hardware und Betrieb.

Grenzen, die man einplanen muss

Ein LLM ist kein Faktenspeicher. Es kann plausibel klingende, aber falsche Aussagen erzeugen (Halluzinationen), sein Wissen endet am Trainingsstichtag, und es rechnet nicht zuverlässig. Aus IT-Sicht bedeutet das: Ausgaben sind nicht per se vertrauenswürdig. Sie gehören validiert, gegen Schemata geprüft und mit denselben Vorsichtsmaßnahmen behandelt wie jede andere unsichere Eingabe.

Fazit

Aus IT-Sicht ist ein LLM ein Vorhersager für das nächste Token, mit einem begrenzten, in Tokens gemessenen Kontextfenster, nicht-deterministischem Verhalten und klar benennbaren Kosten pro Token. Genau so sollte man es auch behandeln: als Komponente, die man misst (Latenz, Kosten, Fehlerraten), absichert und deren Ausgaben man nicht blind übernimmt.

In weiteren Beiträgen baue ich darauf auf: wie man ein LLM sauber in bestehende Software integriert, wann sich Retrieval-Augmented Generation lohnt und was der lokale Betrieb konkret bedeutet.