LLM im Selbstbetrieb: Lohnt sich das?

Sobald der Einsatz von KI-Sprachmodellen in einem Unternehmen diskutiert wird, taucht fast unweigerlich eine zentrale Frage auf: Kann das Modell auch lokal betrieben werden? Besonders wenn es um sensible Daten, Datenschutzvorgaben oder Integrationen in bestehende Systeme geht, ist die Antwort darauf selten einfach.

Der Betrieb eines Large Language Models (LLM) auf eigener Hardware bietet potenzielle Vorteile wie mehr Kontrolle, Datenschutz und Unabhängigkeit von externen Anbietern. Gleichzeitig bringt er technische und organisatorische Herausforderungen mit sich: Welche Ressourcen werden benötigt?  Welche Modelle eignen sich für den lokalen Betrieb? Und welche Risiken oder Einschränkungen entstehen dabei?

Dieser Blogbeitrag beleuchtet die wichtigsten Aspekte, was es alles zu beachten gilt und welche Entscheidungen vor dem Einsatz eines lokal betriebenen LLM getroffen werden sollten. Im nächsten Teil dieser Serie analysieren wir ein reales Kundenprojekt und vergleichen verschiedene Modelle im Detail.

Wie evaluiere ich ein Modell?

Ähnlich wie bei klassischer Software, gibt es auch bei LLMs verschiedene Kriterien, die zur Bewertung herangezogen werden. Was bei klassischer Software der korrekten Funktionsweise entspricht, ist bei LLMs die Qualität der Antworten. Qualität meint hierbei eine inhaltliche und sprachliche Korrektheit. Diese Antwortqualität ist entscheidend, ob ein LLM-basiertes System sinnvoll eingesetzt werden kann. Wohingegen bei klassischer Software die Funktionalität durch Tests überprüft wird, gibt es bei LLMs stattdessen nur Testdaten, die in sogenannten Benchmarks zur Qualitätsbewertung genutzt werden. Die meisten LLMs haben ein zugehöriges Paper oder einen zugehörigen Report, in welchem diverse, standardisierte Benchmarks gemessen werden. Dies ist eine gute Orientierung, um LLMs grob zu bewerten und untereinander einzuordnen. Leider ist dies oftmals nicht ausreichend, um die Qualität für den individuellen Use Case zu bewerten. Deshalb ist es wichtig, eigene Testdaten zu erstellen, womit die Qualität eines LLMs für den individuellen Use Case bewertet werden kann. Bei einem Chatbot kann es sich dabei um Fragen mit zugehörigen Musterlösungen handeln, bei denen ein Chatbot die wichtigsten Fakten korrekt wiedergeben sollte.

Neben der Qualität der Antwort ist auch der Durchsatz entscheidend. Dieser Wert beschreibt dabei, wie schnell die Antwort generiert wird.

Die Herausforderung beim Selbstbetrieb eines LLMs ist es, Qualität und Durchsatz zu optimieren, ohne dass die Kosten dabei übermäßig ansteigen. Hierfür ist nicht nur die Wahl des Modells entscheidend, sondern auch, mit welchem Setup und Konfiguration der Betrieb läuft.

Wie wähle ich das richtige Modell aus?

Die Wahl des Modells ist entscheidend für die Funktionalität, Qualität und Performance einer Anwendung. Nicht nur die Größe des Modells, gemessen in der Anzahl der Parameter, ist dabei wichtig, sondern auch die Art des Modells. Im Open Source Bereich gibt es diverse Anbieter/Entwickler von Modellen, welche unterschiedliche Arten von Modellen mit unterschiedlichen Funktionen anbieten.

Größe von LLMs

LLMs gibt es in verschiedenen Größen, die sich in der Anzahl der Parameter unterscheiden, wobei mehr Parameter in der Regel eine bessere Qualität bedeuten. Die leichteste Möglichkeit die Qualität zu verbessern, ist ein leistungsfähigeres, größeres Modell zu verwenden. Ein größeres Modell benötigt aufgrund der höheren Anzahl an Parametern jedoch auch mehr Rechenleistung und Speicherplatz. Demnach kann mit der gleichen Hardware, bei einem größeren Modell, weniger Durchsatz erreicht werden. Um die Durchsatzrate bei einem größeren Modell gleich zu halten oder sogar zu erhöhen, wird deshalb mehr Hardware benötigt, was die Kosten erhöht. Daraus folgt, dass die drei Eigenschaften Qualität, Durchsatz und Kosten in einem Trade-Off stehen.

Arten von LLMs

Sprachmodelle werden in mehreren Schritten trainiert, man spricht von einer mehrstufigen Pipeline. Die Stufen dieser Pipeline entscheiden, wie sich ein Modell auf Anfragen verhält, z.B. ob es nur Texte ergänzen kann oder sich verhält wie ein Assistent, den man aus ChatGPT kennt. Die gängigsten Varianten von Modellen sind Base-Modelle, Instruct-/Chat-Modelle und Reasoning-Modelle.

Base-Modelle‍

Base-Modelle sind LLMs, bei denen das sogenannte Pretraining durchgeführt wurde. Dabei werden die Modelle mit Milliarden oder sogar Billionen von Wörtern aus dem Internet oder anderen Quellen wie Büchern trainiert. Diese Modelle vervollständigen Text, jedoch ist die Antwort oft nicht strukturiert, sondern erzeugt lediglich Text. Mit einigen Tricks können Base-Modelle auch strukturierte Antworten generieren, jedoch werden diese Modelle heutzutage nur als Grundlage für Finetuning genutzt. Finetuning bedeutet, dass das Modell auf spezifische Use Cases trainiert wird. Die finegetunten Modelle werden anschließend für den Produktiveinsatz genutzt, nicht jedoch die Base-Modelle. Auf HuggingFace haben Base-Modelle manchmal den Zusatz "Base" im Namen, oftmals wird jedoch kein Zusatz genutzt. Das Base-Modell von LLaMA 3-8B heißt auf HuggingFace "meta-llama/Meta-Llama-3-8B".

Instruct-/Chat-Modelle

Instruct-/Chat-Modelle sind finegetunte Modelle, die eine Chatfunktion bieten. Dabei werden Modelle mit einer User- und Assistant-Rollenverteilung mit einer breiten Palette an Fragen und Antworten trainiert. Je nach Modell sind dies typische Dialoge, aber auch spezifische Use Cases wie Zusammenfassungen oder Umschreibungen. Auch ein Training mit menschlichen Präferenzen (sogenanntes Reinforcement Learning from Human Feedback, RLHF) wird bei diesen Modellen genutzt. Instruct-/Chat-Modelle sind durch ChatGPT populär geworden, bilden aber auch die Basis für viele produktive Use Cases. Auf HuggingFace haben Instruct-/Chat-Modelle den Zusatz "instruct" oder "chat" im Namen. Das Instruct-Modell von LLaMA 3-8B heißt auf HuggingFace "meta-llama/Meta-Llama-3-8B-Instruct".

Reasoning-Modelle

Reasoning-Modelle sind eine spezielle Art von Modellen, die vor der Beantwortung einer Frage eine Art von Denkprozess durchführen. Proprietäre-Modelle wie o1 oder o3 von OpenAI verbergen diesen Denkprozess, andere Modelle, wie DeepSeek-R1, legen diesen Denkprozess offen. Reasoning-Modelle sind besonders für komplexe Use Cases geeignet, beispielsweise mathematische Aufgaben. Diese Modelle können auch einen Finetuning oder RLHF Schritt haben, wodurch sie auch für menschliche Interaktionen ausgelegt sind. Das bekannteste Open-Source-Reasoning-Modell ist DeepSeek-R1, wobei auch Alternativen wie QwQ existieren. Auf HuggingFace hat sich keine einheitliche Namensgebung für Reasoning-Modelle etabliert.

Generell empfiehlt es sich, in Produktion ein Instruct-/Chat-Modell oder ein Reasoning-Modell zu nutzen. Je nach Komplexität des Use Cases sollte zwischen diesen beiden Modellen gewählt werden. Reasoning-Modelle haben eine höhere Performance bei mathematischen Aufgaben, jedoch entsteht ein Overhead durch den Denkprozess des Modells.

Zusätzliche Funktionalitäten von LLMs

Die meisten LLMs fokussieren sich auf die Verarbeitung von Texten, wobei Text sowohl zur Eingabe als auch zur Ausgabe genutzt wird. Jedoch gibt es einige weitere Funktionen, die für spezielle Use Cases benötigt werden.

Benötigt ein Use Case nicht nur Text Ein- und Ausgaben, sondern weitere Dateiformate wie Bilder, so können Multimodale-Modelle genutzt werden. Diese Modelle unterstützen dabei unterschiedliche Eingabeformate, wie Text, Bild, Audio oder sogar Video. Die häufigste Variante sind sogenannte Vision-Modelle, welche zusätzlich auch Bilder interpretieren können.

Die meisten Sprachmodelle beschränken die Eingabe von Text auf eine Länge von 32.000 oder 64.000 Tokens. Man bezeichnet die Länge der Eingabe als Context Window. Wenn längere Texte verarbeitet werden müssen, beispielsweise ganze Bücher, gibt es auch Modelle, bei denen das Context Window auf z.B. 1 Million Tokens erhöht wurde. Hierbei ist jedoch zu beachten, dass längere Context Windows nicht nur mehr Ressourcen benötigen, sondern die Länge auch einen negativen Einfluss auf die Qualität haben könnte.

Übersicht von Open Source LLMs

Open Source Modelle und zugehörige Dokumentation und Paper finden sich auf HuggingFace. Hier ist eine Übersicht über die aktuell populärsten Open Source Modelle (Stand: März 2025):

Meta LLama 3 Reihe:

• Base und Chat/Instruct Modelle von 1B bis 405B, teilwiese Multimodal

Alibaba Qwen 2.5 Reihe:

• Base und Chat/Instruct Modelle von 0,5B bis 72B
• Coding, Math und Reasoning Varianten mit Qwen2.5-Coder, Qwen2.5-Math und QwQ

Mistral:

• Diverse Modelle wie Mistral Small 24B, teilweise Multimodel oder mit der Mixture-of-Experts Architektur

DeepSeek:

• DeepSeek-V3: 671B Base und Chat/Instruct Modell, zusätzlich Reasoning Variante DeepSeek-R1

Allen Institute for AI:

• Komplettes Open Source Modell OLMo (Daten, Trainingscode und Modell)
• Erweiterungen wie OLMoE als MoE Modell, PixMo als Bildmodell
• Tulu: Open Source State-of-the-Art Finetuning von LLama 405B

HuggingFace:

• SmolLM: Kleine Modelle mit von 135M bis 1,7B Parameter, teilweise Multimodal
• Diverse zusätzliche Ressourcen, wie z.B. FineWeb Trainingsdatenset

Finetuning von LLMs

Um die Performance von LLM-Anwendungen zu verbessern, gibt es zwei wichtige Techniken: Kontextanreicherung oder Finetuning.

Kontextanreicherungen sind Techniken, bei welchen Daten in die Eingabe von LLMs übergeben werden, wodurch das LLM diese Daten zur Beantwortung der Frage nutzen kann. Die bekannte Variante ist das sogenannte Retrival Augmented Generation (RAG), welches bei Chatbots genutzt wird. Dabei wird eine Dokumentensuche ausgeführt (Retrival), wobei das Ergebnis der Suche in die Eingabe des Modells geladen wird (Augmented), um daraufhin eine Antwort zu generieren (Generation). Kontextanreicherungen verändern nicht das Modell, sondern dienen lediglich dazu, Fakten für ein Modell nutzbar zu machen.

Finetuning hingegen ist eine Technik, bei welcher ein Modell auf spezifische Use Cases trainiert wird. Das Modelltraining von einem Base Modell zu einem Instruct-/Chat-Modell ist ein Beispiel für Finetuning, bei welchem das Modell auf Dialoge trainiert wurde, um Nutzeranfragen strukturiert beantworten zu können. Finetuning wird genutzt, um Fähigkeiten von LLMs zu verbessern oder dem LLM neue Fähigkeiten beizubringen. Zu diesen Fähigkeiten kann Fachsprache (z.B. Medizindiagnosen oder Gesetzestexte) zählen oder auch sprachliche Fähigkeiten wie Zusammenfassungen oder Umschreibungen. Kleinere Modelle, die spezifisch für einen Use Case trainiert sind, können eine höhere Qualität für den Use Case liefern als größere, nicht finegetunte Modelle. Finetuning ist jedoch ein eigenes Thema für sich, das den Rahmen dieses Artikels sprengen würde.

Wie betreibe ich lokal ein LLM?

Nachdem ein Modell ausgewählt wurde, stellt sich die Frage, wie dieses Modell betrieben werden kann. Nicht nur ist hierbei die genutzte Hardware wichtig, sondern auch die Software, durch welche das Modell ausgeführt wird. Die Software wird dabei auch Engine genannt und bietet eine Vielzahl an Konfigurationsmöglichkeiten, um die Performance des Modells zu optimieren.

Benötigte Hardware

Neuronale Netze und damit auch LLMs bestehen mathematisch zu einem Großteil aus Matrixmultiplikationen. CPUs können Matrixmultiplikationen durchführen, jedoch sind Grafikkarten (GPUs) und spezielle Hardware (TPUs) speziell für diese Operationen ausgelegt. In Produktion sollten LLMs deshalb auf GPUs betrieben werden. NVIDIA GPUs sind derzeit die populärste Wahl. Dies liegt nicht nur an der reinen Leistung der Chips, sondern auch an dem Software-Ökosystem, welches für NVIDIA GPUs existiert.

Bei der Wahl der GPUs gibt es dabei zwei Faktoren zu berücksichtigen: die Anzahl der mathematischen Operationen und die Größe des Speichers. Der Speicher ist dabei ein limitierender Faktor, da ein LLM vollständig im Speicher der GPU, auch VRAM genannt, liegen muss, um effizient betrieben zu werden. Zwar gibt es auch Techniken, bei welchen das Modell nur teilweise im Speicher liegt und bei Bedarf nachgeladen wird (sogenanntes Memory Offloading), jedoch ist dies aufgrund der Performanceeinbußen nicht empfehlenswert für den produktiven Einsatz. Die Anzahl der mathematischen Operationen beschreibt, wie viele Berechnungen eine Grafikkarte ausführen kann, gemessen in Kommazahlen pro Sekunde (FLOPS). Je mehr FLOPS eine Grafikkarte hat, desto schneller kann ein Modell betrieben werden.

Engines zur Ausführung

Um ein LLM ohne viel Aufwand auf Consumer Hardware, wie einem Notebook, zu testen, wird oftmals Ollama oder LM Studio genutzt. Diese Tools machen von Techniken wie Memory Offloading Gebrauch, um das Modell auf der meisten Hardware lauffähig zu machen.

Für den Betrieb eines Modells in Produktion sind Features wie Memory Offloading weniger relevant, stattdessen sind Durchsatzoptimierungen, Speicheroptimierungen, Resilienz und Ähnliches wichtiger. Die bekanntesten Tools für den produktiven Einsatz sind:

• vLLM: 40,9k Sterne bei GitHub
• SGLang: 11,7k Sterne bei GitHub
• HuggingFace TGI: 9,9k Sterne bei GitHub
• NVIDIA TensorRT-LLM: 9,7k Sterne bei GitHub

Bei der Wahl des Tools sollten folgende Kriterien berücksichtigt werden:

• Hardware-Support: Wird die vorhandene Hardware unterstützt?
• Modell-Support: Wird das vorhandene LLM unterstützt? Kann das Tool um eigene LLM-Architekturen erweitert werden?
• Weitere Features: Gibt es spezielle Features wie Speculative Decoding, die genutzt werden sollen?

Der Modelldurchsatz sowie der Speicherverbrauch werden von all diesen Tools optimiert. Je nach Version/Release ist ein Tool schneller als ein anderes, hier gibt es aber stetige Optimierung. Empfehlenswert ist es deshalb, die Performance nicht als Hauptfaktor bei der Wahl des Tools zu betrachten, sondern vielmehr durch optimierte und angepasste Konfiguration die Performance zu verbessern.

Optimierungen

Zwar ermöglicht eine Engine eine simple Ausführung eines LLMs durch einfaches Starten. Leider ist die Standardkonfiguration nicht die optimale Konfiguration, da Hardware, Modell und Use Case individuell sind. Deshalb ist es wichtig, die Konfiguration der Engine zu optimieren, um die Performance zu maximieren.

KV-Cache
Die Generierung eines neuen Tokens benötigt bei der Inferenz eines Modells Informationen von allen vorherigen Tokens. Diese Informationen werden im sogenannten KV-Cache gespeichert. Wenn beispielsweise ein Prompt 1000 Tokens hat, werden für jedes dieser 1000 Tokens im Prompt zwei Vektoren pro Layer (Key Vektor und Value Vektor) im KV-Cache gespeichert. Diese werden für die Generierung von Token 1001 benötigt. Nach der Generierung wird der KV-Cache um Token 1001 erweitert.

Der KV-Cache und damit der Speicherverbrauch wächst nicht nur mit der Länge des Contexts, sondern auch mit der Größe des Modells. Werden also große Context Windows benötigt, so wird auch mehr VRAM benötigt, was bei der Hardware berücksichtigt werden muss

Batching
Neuronale Netze, und demnach auch LLMs, können mehrere Eingaben gleichzeitig in einem sogenannten Batch verarbeiten. Dies erhöht den Durchsatz, da Eingaben zeitgleich verarbeitet werden. Die Batchgröße, also die Anzahl gleichzeitiger Eingaben, muss dabei so gewählt werden, dass der Speicherverbrauch des KV-Caches nicht über den VRAM hinausgeht. Zusätzlich müssten Anwendungen so konzipiert werden, dass Anfragen gebündelt werden, um Batching zu ermöglichen.

Nutzung mehrerer GPUs
Ein Modell kann auf mehreren GPUs laufen. Nicht nur könnte das Modell dupliziert werden (was Data Parallel heißt), sondern ein Modell selbst kann auf mehreren GPUs verteilt laufen. Dies macht die Ausführung von größeren Modellen erst möglich. Wenn ein Modell auf mehrere GPUs verteilt wird, kann dies durch die Aufteilung unterschiedlicher Schichten auf unterschiedliche GPUs verteilt werden (Pipeline Parallel), aber auch einzelne Schichten selbst können auf mehreren GPUs verteilt laufen (Tensor Parallel). Eine optimale Aufteilung gibt es nicht, da Faktoren wie die Kommunikationsgeschwindigkeit zwischen GPUs (und gegebenenfalls auch mehrerer unterschiedlicher Server Nodes) eine wichtige Rolle spielen. Experten können jedoch durch Profiling und Experimente eine optimale Aufteilung und damit eine optimale Ausnutzung der Hardware erreichen.

Quantisierung
Die Parameter eines LLM sind in der Regel im Datentyp Float32 gespeichert, was 32 Bit pro Parameter bedeutet. Quantisierung reduziert die Anzahl der Bits, die pro Parameter gespeichert werden. Dabei werden die Gewichte und Aktivierungen auf eine geringere Anzahl von Bits reduziert, wodurch der Speicherverbrauch reduziert, und der Durchsatz erhöht wird. Eine Reduzierung von dem 32 Bit Float32 Datentyp in den für Neuronale Netze üblichen 16 Bit Datentyp bfloat16 ist dabei unproblematisch. Bei der Reduzierung in noch kleinere Datentypen, wie beispielsweise zu 8 Bit Ganzzahl, wird die Qualität jedoch leiden. Quantisierung ist also ein Trade-off zwischen Speicherverbrauch, Durchsatz und Qualität. Nicht nur das Modell selbst, sondern auch der KV-Cache kann quantisiert werden.

Prompt Caching
Prompts und der zugehörige KV-Cache können gecacht werden. Wird bei einem Chatbot beispielsweise immer der gleiche System-Prompt genutzt, so muss dieser nicht bei jeder Anfrage durch das Modell inferiert werden, sondern lediglich aus dem Cache geladen werden. Dieser Cache kann sogar für parallele Anfragen geteilt werden.

Speculative Decoding
Ein kleines Modell berechnet beispielsweise die nächsten 10 Token einer Antwort. Das große Modell kann alle diese 10 Token validieren und die richtig vorhergesagten Token nutzen. Falls das große Modell andere Token vorhersagen würde, dann werden diese Token überschrieben. Das heißt, um 10 Token vorherzusagen, würde im Best Case 10 Forward Passes des kleinen Modells und 1 Forward Pass des großen Modells benötigt werden. Im Worst Case 10 Forward Passes des kleinen Modells und 10 Forward Passes des großen Modells. Im Average Case bietet dies jedoch einen signifikant höheren Durchsatz bei gleicher Qualität. Der Nachteil ist jedoch, dass der Speicherverbrauch für 2 Modelle genutzt wird. Techniken wie Chunked Prefill und Predicted Output funktionieren ähnlich.

Fazit

Der Betrieb eines LLMs auf eigener Hardware bringt eine erhebliche Komplexität mit sich. Von der Auswahl des richtigen Modells über die benötigte Infrastruktur bis hin zu vielschichtigen Optimierungen – jedes dieser Themen erfordert spezialisiertes Wissen und sorgfältige Planung.

Ob dieser Aufwand gerechtfertigt ist, hängt stark von den individuellen Anforderungen ab. Wer höchste Datenschutzstandards einhalten muss, maximale Flexibilität benötigt oder Abhängigkeiten von Drittanbietern vermeiden will, kann vom lokalen Betrieb profitieren. Für viele Anwendungsfälle kann jedoch eine gehostete Lösung praktikabler und wirtschaftlicher sein.

Im zweiten Teil dieser Serie wird anhand eines realen Kundenprojekts gezeigt, wie verschiedene Modelle evaluiert werden. Dazu werden unterschiedliche Arten von Modellen gegenübergestellt, sowohl in Bezug auf die Qualität, den Durchsatz und die damit verbundenen Kosten.

LLMs optimal nutzen – mit der richtigen Strategie!

Die Entscheidung zwischen lokalem Betrieb und gehosteter Lösung erfordert tiefgehendes Know-how. Von der Modellwahl bis zur Infrastruktur – wir von CodeCamp:N helfen Dir, die optimale Strategie für Deine Anforderungen zu entwickeln.

Lass uns gemeinsam herausfinden, welche Lösung für Dich die beste ist!