Sprachmodelle verstehen
42°OS kann KI-gestützte Workflows bauen — und dafür werden Sprachmodelle (LLMs, Large Language Models) genutzt. Dieses Kapitel erklärt was ein Sprachmodell ist, welche Varianten es gibt und was das für den Einsatz in Unternehmen bedeutet.
Was ist ein Sprachmodell?
Ein Sprachmodell ist ein KI-System das Text versteht und Text erzeugt. Es wurde auf enormen Mengen an Textdaten trainiert und hat dabei statistische Muster der Sprache gelernt — was typischerweise nach was folgt, wie Konzepte zusammenhängen, wie Texte strukturiert sind.
Bekannte Sprachmodelle: GPT-4 (OpenAI), Claude (Anthropic), Gemini (Google), Llama (Meta, Open Source), Mistral (Open Source).
Was ein Sprachmodell kann:
- Text analysieren und verstehen
- Inhalte aus unstrukturierten Texten extrahieren
- Texte klassifizieren, zusammenfassen, übersetzen
- Strukturierte Ausgaben aus unstrukturierten Eingaben erzeugen
Was es nicht kann:
- Mit Sicherheit rechnen (es rät auf Basis von Mustern)
- Auf aktuelle Informationen zugreifen (es kennt nur was im Training war)
- Sich erinnern (jeder Aufruf beginnt von vorne — sofern kein Gedächtnis explizit gebaut wird)
Cloud-LLM vs. On-Premises-LLM
Cloud-LLM
Das Modell läuft auf Servern des Anbieters (OpenAI, Anthropic, Google). Der Text der verarbeitet werden soll — die Eingabe — wird über das Internet an den Anbieter geschickt, dort verarbeitet und das Ergebnis zurückgeschickt.
42°OS → [Text der verarbeitet werden soll] → Internet → OpenAI-Server
↓
42°OS ← [Ergebnis] ← Internet ←──────────────────────────────
Vorteile:
- Leistungsfähigste Modelle verfügbar (GPT-4, Claude Opus, ...)
- Kein eigener Hardware-Aufwand
- Immer aktuell
Einschränkungen:
- Die Daten verlassen das Unternehmen — jeder Text der ans Modell geschickt wird, geht über externe Server. Sensible Kundendaten, Betriebsgeheimnisse, Personaldaten dürfen so möglicherweise nicht verarbeitet werden.
- Abhängigkeit vom Anbieter und dessen Verfügbarkeit
- Kosten pro Anfrage (Token-basiert)
- Internetverbindung erforderlich
On-Premises-LLM
Das Modell läuft auf einem Server beim Kunden oder im dedizierten Deployment. Die Daten verlassen das Unternehmen nie.
42°OS → [Text] → lokaler LLM-Server (im selben Netzwerk)
↓
42°OS ← [Ergebnis] ←─────
gus:tav ist das Sprachmodell das 42grad für On-Premises-Deployments einsetzt — ein lokales Modell das keine Verbindung nach außen braucht.
Vorteile:
- Vollständige Datensouveränität — kein Datentransfer nach außen
- Funktioniert ohne Internetverbindung
- Keine Kosten pro Anfrage
- Volle Kontrolle über Modell-Version und Updates
Einschränkungen:
- Erfordert leistungsfähige Hardware (besonders GPU für gute Performance)
- Modelle sind in der Regel kleiner als die großen Cloud-Modelle — etwas weniger leistungsfähig
- Höherer Initialaufwand
Die Entscheidung in der Praxis
Für viele Mittelständler ist On-Premises-LLM der entscheidende Vorteil von 42°OS gegenüber anderen Lösungen. Wenn ein Rechnungsworkflow Lieferantennamen, Beträge und Positionen aus PDFs extrahiert, enthält diese Daten möglicherweise vertrauliche Geschäftsinformationen — die nicht auf OpenAI-Servern landen sollten.
Die Faustregel: wenn die zu verarbeitenden Daten vertraulich sind oder Compliance-Anforderungen unterliegen, ist On-Premises-LLM die richtige Wahl.
Das Kontextfenster
Das Kontextfenster ist die maximale Menge an Text die ein Sprachmodell in einer einzigen Anfrage verarbeiten kann — Eingabe und Ausgabe zusammen.
Es wird in Tokens gemessen. Ein Token entspricht ungefähr 3-4 Zeichen oder 0,75 Wörtern. Ein Kontextfenster von 100.000 Tokens fasst grob 75.000 Wörter — etwa 150 Seiten Text.
Kontextfenster
├── System-Prompt (Anweisung an das Modell)
├── Eingabe (der zu verarbeitende Text)
└── Ausgabe (die erzeugte Antwort)
↑
alles zusammen darf das Limit nicht überschreiten
Warum ist das relevant?
Lange Dokumente: Ein 50-seitiger Vertrag passt möglicherweise nicht in ein kleines Kontextfenster. Lösung: das Dokument in Abschnitte aufteilen und abschnittsweise verarbeiten.
Konversationsgedächtnis: Wenn ein Assistent die letzten 20 Nachrichten kennen soll, wird die gesamte Gesprächshistorie bei jeder Anfrage mitgeschickt. Das verbraucht Kontextfenster. Irgendwann muss älterer Kontext verworfen werden.
Kosten: Bei Cloud-LLMs werden Tokens bezahlt. Ein großes Kontextfenster kostet mehr pro Anfrage. Effizienz bei der Prompt-Gestaltung spart Geld.
Performance: Größere Kontextfenster sind langsamer. Für zeitkritische Workflows macht es Sinn, nur die wirklich relevanten Informationen ins Modell zu schicken.
Praktische Konsequenz für 42°OS-Workflows
Der Generative AI Agent schickt die gesamte eingehende Nachricht plus den System-Prompt an das Modell. Wenn vorherige Agenten viele Daten in die Nachricht geschrieben haben, kann das Kontextfenster schnell eng werden.
Strategie: mit dem Message Formatting Agent oder JavaScript Agent die Nachricht vor dem LLM-Aufruf auf die wirklich relevanten Felder reduzieren. Nur was das Modell braucht, soll es auch sehen.
Tokens und Kosten bei Cloud-LLMs
Bei Cloud-LLMs wird pro Token bezahlt — separat für Eingabe-Tokens (Input) und Ausgabe-Tokens (Output). Ausgabe ist typischerweise teurer als Eingabe.
Orientierungswerte (Stand 2026, variieren je Modell und Anbieter):
- Einfache Klassifizierung (kurzer Text, kurze Antwort): wenige Cent pro 1.000 Anfragen
- Komplexe Extraktion aus langen Dokumenten: deutlich mehr
Für Workflows die tausende Male täglich laufen, summieren sich Token-Kosten erheblich. Das ist ein weiterer Grund warum der Grundsatz "LLM nur wenn nötig" nicht nur die Zuverlässigkeit verbessert, sondern auch Kosten senkt.
Bei On-Premises-LLMs gibt es keine Token-Kosten — nur die Infrastrukturkosten des Servers.
Zusammenfassung
| Cloud-LLM | On-Premises-LLM (gus:tav) | |
|---|---|---|
| Daten verlassen das Unternehmen | Ja | Nein |
| Leistung | Sehr hoch | Gut |
| Internetabhängigkeit | Ja | Nein |
| Kosten | Pro Token | Infrastruktur fix |
| Datenschutz | Abhängig vom Anbieter | Vollständig kontrollierbar |
| Geeignet für | Unkritische Daten, maximale Leistung | Sensible Daten, Compliance, Off-Grid |