Sprachmodelle haben sich in kürzester Zeit von einer Forschungskuriosität zum zentralen Baustein digitaler Wertschöpfung entwickelt. Die zugrundeliegende Transformer-Architektur, 2017 in einem Forschungspapier mit dem selbstbewussten Titel „Attention Is All You Need" vorgestellt, hat eine technologische Dynamik ausgelöst, die Unternehmen jeder Größe vor eine strategische Frage stellt: Wie wird aus einem beeindruckenden Prototyp ein produktionsreifes System, das echten Geschäftswert liefert?

Die Antwort ist weniger trivial, als es die Flut an Demos und Proof-of-Concepts vermuten lässt. Denn zwischen einer funktionierenden Demo und einem robusten, skalierbaren Produktivsystem liegen erhebliche technische, organisatorische und strategische Hürden. Wer diese Hürden unterschätzt, riskiert nicht nur gescheiterte Projekte, sondern auch Abhängigkeiten, die sich langfristig als teuer und einschränkend erweisen.

Die Kluft zwischen Demo und Produkt

Die erste und vielleicht wichtigste Erkenntnis für Unternehmen, die LLMs produktiv einsetzen wollen: Eine funktionierende Demo ist kein Produkt. Prototypen lassen sich in wenigen Stunden erstellen – ein API-Aufruf, eine hübsche Oberfläche, ein beeindruckendes Ergebnis. Doch der Weg zur Produktion erfordert die Auseinandersetzung mit Fragen, die im Demo-Kontext schlicht nicht auftauchen.

Typische Herausforderungen beginnen bereits bei der Infrastruktur. Modelle mit Milliarden von Parametern erzeugen Docker-Images, die ein Vielfaches dessen wiegen, was klassische DevOps-Teams gewohnt sind. Wo ein konventioneller Microservice mit wenigen hundert Megabyte auskommt, starten quantisierte Sprachmodelle bei mehreren Gigabyte – und das ist bereits das Ergebnis erheblicher Komprimierung. Das ursprüngliche Modell kann leicht 32 Gigabyte oder mehr umfassen. Für DevOps-Teams, die nie mit solchen Dimensionen gearbeitet haben, ist das eine fundamentale Umstellung.

Hinzu kommen Fragen der GPU-Verfügbarkeit, der Speicherarchitektur und der Latenz. Selbst aktuelle Consumer-GPUs mit 24 GB VRAM reichen für viele Modelle nicht aus. Enterprise-Deployments erfordern häufig Multi-GPU-Setups oder spezialisierte Inferenz-Hardware. Laut einer aktuellen Analyse verschieben Sicherheits- und Governance-Bedenken den Übergang von Pilotprojekten in die Produktion bei vielen Unternehmen erheblich.[1]

Dieser Gap zwischen Demo und Produkt ist kein Zeichen von Inkompetenz – er spiegelt die genuine Neuartigkeit der Technologie wider. Teams, die bereits klassische ML-Modelle erfolgreich deployt haben, stoßen bei LLMs auf qualitativ neue Anforderungen. Die Größe der Modelle, die Komplexität der Datenaufbereitung (ETL) und die besonderen Anforderungen an Inferenz-Pipelines unterscheiden sich fundamental von allem, was im Bereich klassischer Machine-Learning-Operationen etabliert ist.

Warum die Frage nach eigener KI-Infrastruktur strategisch ist

Eine der folgenreichsten Entscheidungen im Kontext von LLMs betrifft die Frage: Eigenes Modell oder API-Konsument? Beide Wege haben ihre Berechtigung, doch die Risiken einer vollständigen Abhängigkeit von externen Anbietern werden häufig unterschätzt.

Vendor Lock-in als unterschätztes Risiko

Was passiert, wenn der Anbieter, auf dessen API die gesamte eigene Wertschöpfung aufbaut, seine Preise signifikant erhöht? Wenn die Kosten pro Token von zwei Cent pro Million auf ein Vielfaches steigen, kann ein bisher profitables Geschäftsmodell über Nacht kippen. Und selbst wenn das Unternehmen dann versucht, auf eigene Infrastruktur umzuschwenken, sind die Kosten für GPUs und Speicher möglicherweise ebenfalls gestiegen – ein Effekt, der sich in den letzten Jahren bei GPU- und RAM-Preisen deutlich gezeigt hat.

Das Risiko ist dabei nicht hypothetisch. Unternehmen, die sich bereits in einem Vendor-spezifischen Ökosystem befinden, stehen vor der Herausforderung fragmentierter Governance, erhöhter Audit-Komplexität und wachsender regulatorischer Exposition.[2] Die Analogie zu historischen Fällen, in denen Unternehmen ihre Kernkompetenz an Dritte auslagerten und dadurch ihre Wettbewerbsfähigkeit verloren, ist dabei keineswegs überzogen.

Argumente für eigene Modelle

Wer eigene Modelle betreibt, gewinnt an mehreren Fronten:

  • Datenschutz und Datensouveränität: Sensible Unternehmens- und Kundendaten verlassen nie die eigene Infrastruktur.
  • Vollständige Kontrolle: Über Sampling-Parameter, Guardrails, Kontextfenster und Modellverhalten lässt sich granular bestimmen, was das Modell kann und was nicht.
  • Spezialisierte Guardrails: Für regulierte Branchen (Finanzen, Gesundheit, Recht) lassen sich Sicherheitsmechanismen implementieren, die über das hinausgehen, was API-Anbieter ermöglichen.
  • GEO (Generative Engine Optimization): Die Frage, wie ein Unternehmen in den Antworten von KI-Systemen erscheint, wird zunehmend strategisch relevant. Wer ein eigenes Modell betreibt, kann steuern, welche Informationen Nutzer bei internen oder öffentlichen Suchen erhalten – unabhängig davon, wie externe LLMs das Unternehmen bewerten.

Open-Source-Modelle bieten Unternehmen dabei zunehmend die Möglichkeit, Kontrolle, Anpassbarkeit und Kosteneffizienz in Einklang zu bringen, ohne auf Leistungsfähigkeit verzichten zu müssen.

Unter der Haube: Was ein Large Language Model tatsächlich ist

Für fundierte Entscheidungen über LLM-Strategien ist ein grundlegendes Verständnis der Technologie unerlässlich – nicht auf dem Niveau eines ML-Forschers, aber tief genug, um die richtigen Fragen zu stellen und Risiken einzuschätzen.

Autoregressive Transformer-Architektur

Ein Large Language Model ist im Kern eine autoregressive Transformer-Architektur, die Sequenz-zu-Sequenz-Aufgaben löst. „Autoregressiv" bedeutet: Das Modell nimmt eine Eingabesequenz, verarbeitet sie Token für Token und versucht, das jeweils nächste Element vorherzusagen. Diese Vorhersage wird zur Sequenz hinzugefügt, und der Prozess wiederholt sich. Im Grunde ist es ein hochkomplexes Ratespiel – allerdings eines, das auf Milliarden von Parametern und Billionen von Trainingstokens basiert.

Ab etwa einer Milliarde Parameter zeigen diese Modelle emergentes Verhalten: die Fähigkeit, syntaktische Muster in Kontexten anzuwenden, die nie explizit trainiert wurden. Das ist bemerkenswert, denn es bedeutet, dass das Modell zwar keine neue Bedeutung erschafft, aber die Syntax menschlicher Sprache auf eine Weise generalisieren kann, die erstaunlich nützliche Ergebnisse hervorbringt.

Tokenisierung und die Grenzen der Vokabulare

Bevor ein LLM Text verarbeiten kann, muss dieser in numerische Repräsentationen umgewandelt werden – das Modell kann ausschließlich mit Zahlen arbeiten. Dieser Prozess, die Tokenisierung, zerlegt Text in Subwort-Einheiten und ordnet ihnen numerische Werte zu. Das klingt simpel, birgt aber eine fundamentale Herausforderung: Sprache ist unendlich, Vokabulare müssen endlich sein.

Jedes zusätzliche Token im Vokabular erhöht die Matrixmultiplikation an kritischen Stellen im Modell und damit den Rechen- und Speicherbedarf. Größere Vokabulare ermöglichen differenziertere Verarbeitung, erfordern aber mehr Compute. Enterprise-Modelle verschaffen sich hier häufig Vorteile durch umfangreichere Vokabulare – ein Aspekt, der bei der Bewertung verschiedener Modelle oft übersehen wird.

Kontextfenster: Das Arbeitsgedächtnis des Modells

Das Kontextfenster bestimmt, wie viel Information ein Modell gleichzeitig verarbeiten kann – sowohl in der Eingabe als auch in der Ausgabe. Von 4.000 Tokens Anfang 2023 sind Kontextfenster auf 128K oder sogar 256K Tokens gewachsen, aber: Die Skalierung unterliegt denselben Restriktionen wie die Vokabulargröße. Jede Erweiterung erhöht die Matrixmultiplikation und damit die Kosten.

Die Lösung liegt weniger in immer größeren Kontextfenstern als vielmehr in intelligentem Kontextmanagement – ein Thema, das unter dem Begriff Context Engineering zunehmend an Bedeutung gewinnt.

Vom Prompting zum Context Engineering

Die Art, wie Unternehmen mit LLMs interagieren, hat sich fundamental weiterentwickelt. Was 2023 als Prompt Engineering begann – die Kunst, die richtige Frage zu formulieren –, hat sich zu einer eigenständigen Ingenieursdisziplin entwickelt: Context Engineering.

Prompt Engineering: Statistische Voreinstellung

Ein Prompt ist im Kern eine statistische Voreinstellung. Er verändert nicht das Modell selbst, sondern beeinflusst die Wahrscheinlichkeitsverteilung, nach der das Modell seine Antwort generiert. Die Erkenntnis, dass bereits einfache Anweisungen wie „Denke Schritt für Schritt" die Qualität der Ausgaben dramatisch verbessern können, war ein Durchbruch – und gleichzeitig ein Hinweis auf die Natur dieser Systeme.

Der Grund: Wenn das Modell Zwischentokens generiert, die das Problem reformulieren, aktiviert es statistische Muster, die in den Trainingsdaten mit Experten-Antworten assoziiert sind. Die Formulierungen, die typischerweise in qualitativ hochwertigen, strukturierten Erklärungen vorkommen, verschieben die Wahrscheinlichkeitsverteilung in Richtung besserer Antworten.

Context Engineering: Die nächste Evolutionsstufe

Context Engineering geht über einzelne Prompts hinaus. Es umfasst die systematische Gestaltung des gesamten Kontexts, der einem Modell zur Verfügung steht – inklusive Systemanweisungen, abgerufener Dokumente, Tool-Ergebnisse, Gesprächsverläufe und strukturierter Metadaten. Die Disziplin kontrolliert nicht, wie das Modell antwortet, sondern was es sieht, wenn es antwortet.[4]

Aktuelle Ansätze behandeln den Kontext als modulare Architektur mit austauschbaren Komponenten.[5] Für Unternehmen, die LLMs in produktive Systeme integrieren, bedeutet das: Der Kontext muss so präzise kuratiert werden wie ein Datenbank-Schema. Irrelevante Informationen verschwenden nicht nur Tokens, sondern verschlechtern aktiv die Qualität der Ausgaben.

Wer individuelle Webanwendungen und Softwarelösungen entwickelt, steht vor der Aufgabe, diese Kontextarchitekturen nahtlos in bestehende Systemlandschaften zu integrieren – von der Datenanbindung über API-Schnittstellen bis hin zur Frontend-Darstellung.

Die Trainingspipeline: Drei Phasen zum einsatzfähigen Modell

Das Training eines LLM durchläuft mehrere Phasen, die jeweils unterschiedliche Ziele verfolgen und unterschiedliche Herausforderungen mit sich bringen.

Phase 1: Self-Supervised Pre-Training

In der ersten Phase trainiert das Modell auf riesigen Textmengen im Selbstlernverfahren. Die Trainingsdaten dienen gleichzeitig als Ziele: Das Modell lernt, das nächste Token in einer Sequenz vorherzusagen, indem es ein Sliding Window über den Text führt. Interessanterweise hat die Forschung gezeigt, dass die Menge und Diversität der Daten in dieser Phase wichtiger ist als ihre spezifische Kuratierung. Selbst vermeintlich „verrauschte" Datenquellen wie YouTube-Transkripte oder Foren-Beiträge tragen zum emergenten Verhalten der Modelle bei.

Die sogenannten Chinchilla Scaling Laws definieren dabei das optimale Verhältnis zwischen Modellparametern und Trainingsdaten. Das Paper demonstrierte, dass ein 70-Milliarden-Parameter-Modell ein 280-Milliarden-Parameter-Modell übertreffen kann, wenn das Verhältnis von Daten zu Parametern optimal gewählt wird.[3]

Phase 2: Reinforcement Learning (RLHF/GRPO)

In der zweiten Phase lernt das Modell, seine Antworten nach menschlichen Präferenzen auszurichten. Zwei Ansätze dominieren:

  • Proximal Policy Optimization (PPO): Entwickelt von OpenAI, basierend auf globalem Feedback (Daumen hoch/runter) für vollständige Antworten. Ein separates Reward-Modell bewertet die Qualität der Ausgaben.
  • Group Relative Policy Optimization (GRPO): Entwickelt von DeepSeek, bewertet einzelne Teile der Antwort separat. Ein mathematisches Ergebnis kann falsch sein, aber der Lösungsweg korrekt aufgesetzt – und wird entsprechend differenziert bewertet.

Dieses Reinforcement Learning ist der Grund, warum LLMs auf sensible Fragen mit ausgewogenen Antworten reagieren. Das Modell „weiß" noch immer alles aus seiner Vortrainingsphase, wird aber statistisch in bestimmte Antwortmuster gelenkt. Genau deshalb funktionieren sogenannte Jailbreaks: Sie erzeugen Eingaben, bei denen das Reward-Modell keine klare Präferenz hat.

Phase 3: Supervised Fine-Tuning

Für kritische Anwendungsfälle – etwa Suizidprävention in Chatbots oder die korrekte Verarbeitung von Echtzeitdaten – reicht Reinforcement Learning nicht aus. Hier kommt Supervised Fine-Tuning zum Einsatz: Experten schreiben exakte Antworten auf konkrete Fragen, und das Modell trainiert direkt auf diesen Paaren. Das Ergebnis ist deterministisches Verhalten in genau definierten Szenarien.

Halluzinationen: Zwischen Feature und Bug

Eines der meistdiskutierten Themen im LLM-Kontext ist die Fähigkeit der Modelle, plausibel klingende, aber faktisch falsche Informationen zu erzeugen. Aus statistischer Sicht ist diese emergente Kreativität ein Feature – das Modell generalisiert über seine Trainingsdaten hinaus. Aus Ingenieurssicht ist es ein Bug – ein zusätzlicher Fehlerpunkt in einem System, das bereits zahlreiche Fehlerquellen hat.

Die pragmatische Wahrheit liegt dazwischen: Das Halluzinationsrisiko lässt sich durch eine Kombination von Maßnahmen auf ein Niveau reduzieren, das für die allermeisten Anwendungsfälle akzeptabel ist – durch Temperature-Steuerung, Logit-Manipulation, kontextfreie Grammatiken und RAG-Pipelines. Es wird nie exakt null erreichen. Aber auch klassische Infrastruktur erreicht nie 100% Verfügbarkeit. Es geht um Error Budgets, nicht um Perfektion.

Retrieval-Augmented Generation (RAG) hat sich dabei als einer der wirksamsten Ansätze etabliert. Indem dem Modell relevante, verifizierte Informationen direkt im Kontext bereitgestellt werden, lassen sich Halluzinationen laut verschiedenen Studien um bis zu 80% reduzieren. Der entscheidende Punkt: RAG verändert nicht das Modell, sondern dessen Informationsgrundlage – und macht Antworten gleichzeitig nachvollziehbar und auditierbar.

Praktische Optimierung: LoRA, Quantisierung und Distillation

Nicht jedes Unternehmen muss ein Modell von Grund auf trainieren. Es gibt ein abgestuftes Arsenal an Techniken, um existierende Modelle an spezifische Anforderungen anzupassen.

LoRA (Low-Rank Adaptation)

LoRA nutzt einen eleganten mathematischen Trick: Statt die vollständige Gewichtsmatrix eines Modells zu verändern, wird eine wesentlich kleinere Matrix trainiert, die sich aus dem Produkt zweier niedriger dimensionaler Matrizen ergibt. Das Ergebnis: Spezialisierte Anpassungen in der Größenordnung von 160 Kilobyte – verglichen mit einem Basismodell von potentiell mehreren Terabyte.

Der besondere Vorteil: LoRA-Adapter müssen nicht mit dem Basismodell zusammengeführt werden. Sie lassen sich dynamisch laden und entladen, je nach Anfrage. Ein Basismodell kann so mit verschiedenen Spezialisierungen betrieben werden, ohne dass Ressourcen für separate Modell-Instanzen benötigt werden.

Quantisierung

Quantisierung reduziert die Präzision der Modellgewichte – beispielsweise von 32-Bit-Gleitkommazahlen auf 8 oder 4 Bit. Der Informationsverlust ist dabei erstaunlich gering, die Einsparung an Speicher und Rechenleistung dagegen erheblich. Ein 32-GB-Modell kann durch Quantisierung auf unter 5 GB schrumpfen und damit auf Consumer-Hardware lauffähig werden.

Distillation

Bei der Distillation trainiert ein kleineres „Schüler"-Modell auf den Ausgaben eines größeren „Lehrer"-Modells. Das erklärt, warum Open-Source-Anbieter ihre Modelle in verschiedenen Größen veröffentlichen (70B, 32B, 7B, 3B): Das große Modell wird vollständig trainiert, die kleineren Varianten werden destilliert. Der Informationsverlust ist dabei geringer, als man intuitiv erwarten würde – die Modelle „fühlen" sich in ihrer Leistungsfähigkeit erstaunlich ähnlich an.

Agentic Workflows und die Zukunft der LLM-Integration

Ein Bereich, der die Art und Weise verändert, wie LLMs in produktive Systeme eingebettet werden, sind agentenbasierte Workflows. Statt einzelne Anfragen zu beantworten, orchestrieren LLMs hier komplexe Abläufe: Sie analysieren Probleme, führen Tool-Aufrufe durch, evaluieren Zwischenergebnisse und iterieren autonom.

Code statt JSON: Der Trend zu Code Mode

Ein vielversprechender Ansatz gewinnt zunehmend an Bedeutung: Code Mode als Alternative zu JSON-basierten Protokollen wie MCP (Model Context Protocol). Die Logik dahinter ist bestechend einfach: LLMs sind aufgrund ihrer Trainingsdaten besser im Generieren von Code als im Generieren von JSON. JSON erzeugt durch seine repetitiven Strukturen (Klammern, Doppelpunkte, Tabulatoren) einen sogenannten Vanishing Gradient, der die semantische Qualität der eingebetteten Informationen mindert.

Wenn Tool-Aufrufe stattdessen als Funktionsaufrufe in Code formuliert werden, bewegt sich das Modell in einem Raum mit rigider Syntax – genau dort, wo seine emergenten syntaktischen Fähigkeiten am stärksten zur Geltung kommen. Für Unternehmen, die komplexe, automatisierte Workflows auf Basis von LLMs aufbauen, ist das ein relevanter architektonischer Faktor.

Sicherheit und Sandboxing

Mit der zunehmenden Fähigkeit von LLMs, Code zu generieren und auszuführen, wachsen die Sicherheitsanforderungen. Wenn ein Modell in der Lage ist, beliebigen Code zu erzeugen und auszuführen, muss die Ausführungsumgebung entsprechend abgesichert sein. Containerisierung, Sandboxing und strikte Berechtigungskonzepte werden zu unverzichtbaren Bestandteilen jeder produktiven LLM-Architektur.

Für Unternehmen, die ihre digitale Infrastruktur strategisch weiterentwickeln, bedeutet das: LLM-Integration ist kein isoliertes KI-Projekt, sondern ein architektonisches Thema, das Sicherheit, Performance und Systemdesign gleichermaßen betrifft.

Evaluation: Das ungelöste Kernproblem

Eines der fundamentalsten und gleichzeitig am wenigsten gelösten Probleme im LLM-Bereich ist die Evaluation. Wie bewertet man die Qualität einer Antwort in einem System, das mit qualitativen, nicht quantitativen Daten arbeitet?

Für geschlossene Aufgaben – Mathematik, Faktenabfragen, Code-Generierung – existieren Benchmarks. Für offene, sprachliche Aufgaben fehlt jedoch ein universelles Evaluationsframework. Die derzeit genutzten Ansätze (menschliches Feedback, Reward-Modelle, automatisierte Evaluatoren) sind alle mit signifikanten Einschränkungen behaftet:

  • Menschliches Feedback skaliert nicht auf Milliarden von Evaluationen.
  • Reward-Modelle abstrahieren menschliche Präferenzen in einer Weise, die nicht immer reflektiert, was „gut" tatsächlich bedeutet.
  • Automatisierte Evaluatoren fügen eine weitere Black Box in ein bereits undurchsichtiges System ein.

Ein bewährter pragmatischer Ansatz: Holdout-Datensätze mit kritischen Fragen, die das Modell während des gesamten Trainings- und Fine-Tuning-Prozesses nie sieht. Erst im Inferenzmodus wird das Modell mit diesen Fragen konfrontiert – und die Ergebnisse zeigen, ob die Kernfähigkeiten erhalten geblieben sind. Denn eines der größten Risiken beim Fine-Tuning ist katastrophales Vergessen: Das Modell wird in einem Bereich besser, verliert aber unbemerkt Fähigkeiten in anderen Bereichen.

Der Weg zum produktionsreifen LLM-System

Aus den beschriebenen Herausforderungen und Lösungsansätzen ergibt sich eine klare Hierarchie für den Einstieg in produktive LLM-Systeme:

Stufe Ansatz Aufwand Kontrolle Typischer Einsatz
1 Prompting & Context Engineering Niedrig Begrenzt Schnelle Prototypen, interne Tools
2 RAG-Integration Mittel Mittel Wissensmanagement, Kundenservice
3 LoRA / Fine-Tuning Mittel–Hoch Hoch Spezialisierte Fachdomänen
4 Eigenes Training Sehr hoch Vollständig Differenzierung, regulierte Branchen

Die Empfehlung: Immer mit der niedrigsten Stufe beginnen, die das Problem löst. Prompting und Context Engineering sind nicht nur günstiger, sondern auch reversibel. Ein Fine-Tuning verändert das Modell permanent und birgt das Risiko unbeabsichtigter Nebenwirkungen. Training von Grund auf ist nur dann sinnvoll, wenn die Differenzierung im Modellmarkt ein strategisches Ziel darstellt.

Ausblick: Spezialisierung statt Skalierung

Die nächste Phase der LLM-Entwicklung wird voraussichtlich nicht von immer größeren Modellen geprägt sein, sondern von kleineren, hochspezialisierten Expertenmodellen, die in Ensemble-Architekturen zusammenarbeiten. Die Idee: Statt ein einzelnes monolithisches Modell zu haben, das alles mittelmäßig kann, werden mehrere fokussierte Modelle orchestriert, die jeweils in ihrem Spezialgebiet herausragend sind.

Dieser Trend korrespondiert mit der Entwicklung hin zu Code Mode und agentenbasierten Workflows: Wenn Modelle in der Lage sind, Tool-Aufrufe und Delegationen zuverlässig durchzuführen, können sie auch andere Modelle als Werkzeuge nutzen. Das Ergebnis wäre ein System, das näher an menschliche Problemlösungsstrategien heranrückt – nicht durch Brute-Force-Skalierung, sondern durch strukturierte Arbeitsteilung.

Für Unternehmen, die heute die Weichen für ihre KI-Strategie stellen, bedeutet das: Die Investition sollte nicht in ein einzelnes, möglichst großes Modell fließen, sondern in eine flexible, modulare Architektur, die verschiedene Modelle und Techniken orchestrieren kann. Wer seine Systeme mit sauber definierten API-Schnittstellen und einer durchdachten Softwarearchitektur aufbaut, schafft die Grundlage, um von kommenden Entwicklungen zu profitieren, ohne die gesamte Infrastruktur neu aufbauen zu müssen.

Bei mindtwo begleiten wir Unternehmen bei der Konzeption und Umsetzung digitaler Systeme, die auf Langlebigkeit, Skalierbarkeit und technische Präzision ausgelegt sind. Wer die Integration von KI-Komponenten in bestehende oder neue Plattformen strukturiert angehen möchte, findet in uns einen erfahrenen Partner – von der strategischen Beratung bis zur technischen Implementierung.

References