Technical Report
Datum:
Dieser Artikel wurde verfasst von
Consultant, Offensive Security
Consultant, Offensive Security
KI-Modelle, insbesondere die sogenannten Large Language Models (LLMs), haben durch Anbieter wie OpenAI und Anthropic in den vergangenen Jahren große Aufmerksamkeit erlangt. Heute kommen sie in zahlreichen Anwendungsbereichen beispielsweise als Werkzeuge zur Textverarbeitung oder Automatisierung zum Einsatz. Diesem praktischen Einsatz stehen jedoch zwei zentrale Herausforderungen entgegen: laufende Nutzungskosten bei proprietären Anbietern (z.B. OpenAI oder Anthropic) und datenschutzrechtliche Bedenken bei der Integration solcher externen KI-Dienste. Eine mögliche Lösung für diese Probleme stellt das Self-Hosting eigener KI-Dienste (LLM-Instanzen) dar.
Dieses Insight gibt einen einführenden Überblick darüber, was für einen lokalen Betrieb eines LLMs benötigt wird und beleuchtet essenzielle Aspekte, die dabei berücksichtigt werden sollten.
Sollen LLMs eingesetzt werden, muss zuerst die Entscheidung getroffen werden, welches KI-Modell genutzt werden soll (Model Selection). Eine Möglichkeit ist die Nutzung proprietärer Modelle, wobei in diesem Fall kein Eigenbetrieb möglich ist. Proprietäre LLMs befinden sich im alleinigen Besitz des jeweiligen Herstellers. Weder die Trainingsdaten noch Modelleigenschaften wie bspw. die Modellgewichte, welche bestimmen, wie ein Modell Eingaben verarbeitet und Ausgaben erzeugt, sind öffentlich zugänglich. Da die Hersteller proprietärer Modelle häufig über deutlich umfangreichere Ressourcen für Entwicklung und Training verfügen, weisen diese LLMs in der Regel eine höhere Leistungsfähigkeit als Open-Source-Modelle auf. Üblicherweise werden proprietäre LLMs als Software as a Service (SaaS) bereitgestellt. Sie werden vom Hersteller in dessen Cloud-Infrastruktur betrieben, sodass der Zugriff ausschließlich über die kommerzielle API des jeweiligen Anbieters erfolgt.
Für den Anwender bedeutet dies, dass sowohl der Betrieb des Modells als auch die Verarbeitung der übermittelten Daten außerhalb der eigenen Infrastruktur stattfinden. Daraus ergeben sich hohe Nutzungskosten und datenschutzrechtliche Einschränkungen, denn sämtliche an ein solches Modell übermittelte Daten können vom Hersteller potenziell für das Training neuer Modelle oder zu anderen datenschutzgefährdenden Zwecken weiterverwendet werden.
Eine Alternative hierzu stellt das Self-Hosting von LLMs dar. Dabei wird das Modell auf der eigenen Infrastruktur betrieben, wodurch zum einen die Abhängigkeit von einem einzelnen Anbieter entfällt, und zum anderen eine deutlich höhere Flexibilität ermöglicht wird, da Modelle für spezifische Anwendungsfälle nachträglich angepasst werden können (Finetuning).
Modelle, welche zum Self-Hosting genutzt werden können, sind entweder als Open-Source- oder Open-Weight-Modell verfügbar. Im Gegensatz zu Open-Weight-Modellen enthalten Open-Source-Modelle zusätzlich zu den Modellgewichten den Trainingscode und den zum Training genutzten Datensatz bzw. vollständige Details über die Zusammensetzung des Datensatzes, falls der Datensatz nicht zur Verfügung gestellt werden kann. Dies erhöht die Transparenz und Nachvollziehbarkeit des Modells und ermöglicht es, seine Funktionsweise und einen möglichen Bias besser zu bewerten.
Für die tatsächliche Nutzung eines LLMs sind darüber hinaus jedoch nicht nur die Eigenschaften und die Entstehung des Modells, sondern auch dessen Bereitstellung und Ausführung von Bedeutung. Erst durch ein geeignetes Deployment kann ein trainiertes LLM produktiv genutzt werden.
Doch was genau bedeutet es eigentlich, ein LLM auszuführen bzw. zu betreiben?
Die Ausführung eines LLMs wird in der Fachliteratur auch als „Inferenz“ bezeichnet. Damit wird die Fähigkeit eines LLMs beschrieben, Eingaben des Nutzers, sogenannte Prompts, verarbeiten und daraufhin eine Antwort generieren zu können. Vereinfacht gesagt beschreibt das also den Moment, in dem das trainierte Modell sein Wissen anwendet. Inferenz spielt für LLMs eine zentrale Rolle, da Faktoren wie Antwortgeschwindigkeit, Speicherbedarf und Rechenleistung maßgeblich davon abhängen, wie effizient dieser Prozess umgesetzt wird.
Soll ein LLM lokal betrieben werden, benötigt man dafür eine entsprechende Inferenz-Software, über die Anfragen entgegengenommen und an das Modell geschickt werden. Diese Software stellt typischerweise serverartige Funktionen zur Verfügung, die das Verwalten des LLMs über eine API ermöglicht. Hierzu zählen beispielsweise API-Endpunkte, die auf Inferenz-Aufgaben wie Textgenerierung und Tokenisierung ausgelegt sind. Zu den populärsten Projekten gehören dabei unter anderem „vLLM“ und „llama.cpp“. Zudem wird für die einfache lokale Nutzung häufig auf das „Ollama“-Projekt zurückgegriffen. Ollama basiert auf llama.cpp und kapselt dessen Funktionen so, dass neben Funktionen zur Modellverwaltung auch eine einfache Ersteinrichtung und ein unkomplizierter Betrieb möglich sind.
Auch wenn es scheint, dass mit dem Modell und der Inferenz-Software nun alle nötigen Komponenten für den eigenen Betrieb eines LLMs berücksichtigt wurden, fehlte bisher eine fundamentale Komponente in der Betrachtung: die Hardware. Ohne geeignete Rechenressourcen kann das ausgewählte LLM entweder gar nicht oder lediglich mit geringer Leistung betrieben werden.
Grundsätzlich lässt sich ein LLM auf zwei verschiedene Arten betreiben:
Bei der CPU-basierten Variante wird das LLM zur Laufzeit in den Hauptspeicher des Computers geladen und die anschließende Inferenz vollständig durch die CPU durchgeführt. Der Vorteil dieser Methode liegt vor allem in den geringeren Hardwarekosten, da keine dedizierte GPU erforderlich und RAM in der Regel günstiger als vergleichbarer VRAM ist. Allerdings sind CPUs nicht auf die massiv parallelen Berechnungen optimiert, die bei der Verarbeitung von u.a. LLMs auftreten. LLMs basieren zu einem großen Teil auf Matrixoperationen, die sich sehr gut parallelisieren lassen. Genau für diese Art von Berechnungen sind GPUs ausgelegt, weshalb die GPU-basierte Inferenz in vielen Anwendungsszenarien eine deutlich höhere Inferenz-Leistung ermöglicht.
Der Einsatz einer GPU bietet somit enorme Leistungsvorteile, erfordert jedoch zusätzliche Investitionen in geeignete Hardware. Entscheidend ist dabei insbesondere die Größe des verfügbaren VRAMs. Reicht dieser nicht aus, um das Modell vollständig zu speichern, müssen Teile des Modells zwischen GPU und RAM kontinuierlich verschoben werden. Dieser Vorgang reduziert die Inferenzgeschwindigkeit erheblich.
Die Modellgröße wird typischerweise an der Anzahl der Parameter eines Modells bemessen. Parameter sind die während des Trainings erlernten Werte (Gewichte), die bestimmen, wie ein Modell Eingaben verarbeitet und Ausgaben erzeugt. Die Anzahl der Parameter liegt bei modernen LLMs normalerweise im Milliardenbereich. Mit steigender Parameteranzahl wachsen gleichzeitig der Speicherbedarf und üblicherweise auch die Leistungsfähigkeit des Modells. Größere Modelle können daher oft anspruchsvollere Aufgaben bewältigen und komplexere Zusammenhänge erfassen, eignen sich aufgrund des erhöhten Speicherbedarfs jedoch häufig weniger für den lokalen Betrieb auf herkömmlicher Hardware. Zudem garantiert eine hohe Anzahl an Parametern nicht automatisch auch eine höhere Modellleistung, da diese unter anderem von der Qualität der Trainingsdaten, der Modellarchitektur und der verwendeten Quantisierung abhängt.
Die Anforderungen an die Hardware hängen vom eingesetzten LLM ab. Insbesondere die Modellgröße bestimmt, wie viel Haupt- oder Videospeicher für die Inferenz benötigt wird. Da sich LLMs äußerst rasant entwickeln, wäre an dieser Stelle eine Auflistung konkreter Modelle nicht zielführend. Stattdessen haben sich in den letzten Jahren verschiedene Open-Source- bzw. Open-Weight-Modellfamilien etabliert, unter anderem:
Name der Modellfamilie | Entwickler |
Gemma | |
LLaMA | Meta |
Nemotron | NVIDIA |
Qwen | Alibaba Cloud |
GLM | Z.ai |
Kimi | Moonshot AI |
In der Praxis empfiehlt es sich, zusätzlich eine Speicherreserve von etwa 10-15% einzuplanen, damit neben den Modellgewichten auch temporäre Datenstrukturen und Laufzeitdaten im RAM/VRAM Platz finden.
Es steht ein System mit 16 GB RAM und 16 GB VRAM zur Verfügung. Das aktuelle Modell der Gemma-Modellfamilie, Gemma 4, soll mit der gängigen Quantisierung „Q4_K_M“ vollständig auf der GPU ausgeführt werden. Gemma 4 steht bei dieser Konfiguration primär mit folgenden Parametergrößen zur Verfügung: 12B, 26B und 31B („B“ ≙ „Billion“, dt.: „Milliarden“). Je nach Modellgröße beträgt der benötigte VRAM etwa 7,6 GB, 18 GB, beziehungsweise 20 GB. Für das betrachtete System kommt daher lediglich die 12B-Variante infrage, da nur sie vollständig in den verfügbaren VRAM geladen werden kann.
Für das Self-Hosting von LLMs werden also im Wesentlichen drei Komponenten benötigt:
Ausblick
Mit den in diesem Insight vorgestellten Grundlagen sollte nun klar sein, welche Komponenten für das Self-Hosting eines Large Language Models benötigt werden und welche Rolle sie im Gesamtsystem einnehmen. Wie ein solches Self-Hosting-Setup in der Praxis aussehen kann, zeigen wir in einem separaten Insight. Dort erläutern wir Schritt für Schritt, wie ein LLM mithilfe eines geeigneten LLM-Backends lokal eingerichtet, ausgeführt und für eigene Anwendungen bereitgestellt werden kann.