Large Language Model (LLM)

Ein Large Language Model, kurz LLM, ist ein auf sehr großen Textmengen trainiertes Modell, dessen einzige Fähigkeit die Vorhersage des nächsten Textstücks ist. Aus dieser einen Fähigkeit entstehen Antworten, Zusammenfassungen, Übersetzungen und Programmcode, weil all das sich als Fortsetzung von Text formulieren lässt.

Wie funktioniert ein LLM?

Text wird in Token zerlegt, also in Wortbausteine. Das Modell berechnet für jede Position, welches Token als nächstes am wahrscheinlichsten folgt, wählt eines aus und rechnet weiter. Wort für Wort entsteht so die Antwort.

Was das Modell dabei kann, steckt in seinen Gewichten, und die stammen aus dem Training. Das erklärt zwei Eigenschaften, die im Alltag ständig auffallen. Das Modell kennt nichts, was nach seinem Trainingsschluss passiert ist. Und es hat keinen getrennten Faktenspeicher, weshalb es eine Halluzination genauso flüssig formuliert wie eine korrekte Auskunft.

Wie viel Text pro Anfrage berücksichtigt werden kann, begrenzt das Kontextfenster. Alles, was das Modell über euren Fall wissen soll, muss dort hinein.

Was ein LLM gut kann, und was nicht

Gut ist es bei Sprache: umformulieren, zusammenfassen, aus unstrukturiertem Text strukturierte Angaben ziehen, zwischen Sprachen wechseln, Tonfall halten. Das sind die Aufgaben, in denen es zuverlässig Zeit spart.

Schwach ist es bei allem, was Genauigkeit statt Plausibilität verlangt. Rechnen, exakte Zitate aus dem Gedächtnis, Zählen. Solche Teilaufgaben gehören an Werkzeuge übergeben statt an das Modell, und genau dafür existieren Anbindungen wie MCP.

Der praktische Umgang mit dieser Grenze ist einfach: Wissen wird beigelegt statt erwartet. Ein Modell, das aus mitgegebenen Dokumenten antwortet, arbeitet in einem RAG-Aufbau, und dessen Ergebnisse lassen sich belegen.

Was bei der Auswahl zählt

Nicht die Ranglisten. Für die meisten Anwendungen im Mittelstand sind die verfügbaren Modelle ausreichend gut, und der Unterschied zwischen einem Prototyp, der überzeugt, und einem, der es nicht tut, liegt fast immer an der Datenanbindung.

Wichtiger sind drei andere Fragen. Wo wird gerechnet, also welche Daten verlassen das Haus, was auch die Wahl zwischen Cloud und On-Premise-KI betrifft. Was kosten typische Anfragen im Betrieb, nicht im Test. Und wie aufwendig ist ein späterer Wechsel des Modells.

Wie sich die Kosten zusammensetzen

Abgerechnet wird nach Token, und zwar in beide Richtungen: für alles, was hineingeht, und für alles, was herauskommt. Ausgabe ist dabei deutlich teurer als Eingabe.

Daraus folgt eine Eigenart, die viele Kalkulationen sprengt. Der Verlauf eines Gesprächs wird bei jeder Anfrage vollständig mitgeschickt, damit das Modell den Zusammenhang kennt. Ein langes Gespräch bezahlt seinen Anfang deshalb immer wieder. Bei einem agentischen Workflow mit zwanzig Schritten ist das der größte Kostenblock, nicht die eigentliche Antwort.

Zwei Hebel wirken zuverlässig. Kürzen statt anhängen: Was für den nächsten Schritt nicht gebraucht wird, gehört aus dem Kontextfenster heraus. Und Aufgaben trennen: Ein kleines, günstiges Modell sortiert vor, das große beantwortet nur die Fälle, die es braucht.

Für eine belastbare Schätzung reicht eine einfache Rechnung. Nimm die typische Anfrage, zähle Eingabe und Ausgabe in Token, multipliziere mit der erwarteten Zahl der Vorgänge pro Monat. Diese Zahl weicht regelmäßig um eine Größenordnung von dem ab, was nach einem Test im Spielbetrieb vermutet wird.