Small Language Models – die effiziente und sichere OnPrem-Lösung?

Dem aufmerksamen Leser dürfte in den oben beschriebenen Anwendungsfällen etwas aufgefallen sein. Ein Rezept zu erstellen oder Inspiration für einen kreativen Namen zu suchen birgt in den seltensten Fällen ein Risiko. Eine Mail an den Kollegen hingegen kann auch gerne mal sensible, unternehmensinterne Informationen beinhalten. Was passiert mit den Daten in dem Moment, in dem ich ein öffentliches LLM damit beauftrage, diese weiterzuverarbeiten?

Für Führungskräfte ist es nahezu unmöglich, den Einsatz von KI grundsätzlich zu verhindern. Beschäftigte werden immer Wege finden, die Tools zu nutzen, die ihnen ihre Arbeit erleichtern. Diese Motivation gilt es grundsätzlich zu schätzen, nicht aber, wenn dies außerhalb der geregelten Freigabeprozesse geschieht. Letzteres Phänomen wurde bisher unter dem Begriff „Schatten-IT“ zusammengefasst. Im Zusammenhang mit nicht genehmigten KI-Anwendungen spricht man mittlerweile auch von „Schatten-KI“. Diesem Verhalten kann durch Regulatorik und Richtlinien entgegengewirkt werden. Hierzu haben wir bereits im August 2025 Gesetze und Standards vorgestellt, die sich mit dem Management und der Nutzung von KI-Systemen beschäftigen  [1].

Falls die oben genannte Regulatorik nicht ausreicht oder eine weitere Maßnahme gegen die ungewollte Nutzung öffentlicher LLMs gewünscht ist, wäre es möglich, eine lokale LLM-Lösung bereitzustellen. Mithilfe einer sogenannten „On-Prem-KI“ könnte dem Kontrollverlust der Unternehmen- und Kundendaten vorgebeugt werden, und als Administrator hätte man die volle Kontrolle über die Nutzung dieses Systems.

Die teilweise sehr hohen Hardwareanforderungen von State-of-the-Art-LLMs und das notwendige technische Verständnis zur lokalen Integration dieser halten kleine und mittelständische Unternehmen jedoch oft davon ab, ein solches On-Prem-LLM zu implementieren. Neue Entwicklungen in Modellkompression und Speicheroptimierung erlauben es, effiziente „Small Language Models“ zu trainieren und somit die Hardwareanforderungen zu minimieren.

Der folgende Artikel setzt sich zum Ziel, die Hemmschwelle zur selbst gehosteten KI zu minimieren. Dazu werden zunächst Large Language Models vorgestellt, und es wird beschrieben, wie aus diesen dann schlankere und weniger ressourcenintensive Small Language Models hervorgehen. Es wird außerdem auf Dimensionierungsfragen einer lokalen KI im Unternehmenskontext eingegangen, und abschließend werden Tipps und Hinweise zur Implementierung vorgestellt.

Large Language Models

Mit der Veröffentlichung von ChatGPT [2] im November 2022 sind LLMs aus der Forschung in die breite Öffentlichkeit getreten. Das allgemeine technische Verständnis, wie LLMs überhaupt dazu in der Lage sind, menschengleiche Antworten zu verfassen, ist allerdings nicht sonderlich weit verbreitet. Ich möchte einleitend ein paar Begrifflichkeiten erläutern, die im Laufe des Artikels relevant werden.

„Pre-Trained Models“ sind bereits „fertige“ Modelle, die auf Grundlage riesiger Datensätze für einen Use Case trainiert wurden. Diese Modelle werden oft mit der dazugehörigen Parameteranzahl beschrieben. So haben Sie vielleicht schon einmal von „Mistral 7B“ [3] oder Ähnlichem gelesen. 7B steht dabei für 7 Milliarden (B – engl. „billion“) Parameter. Bei diesem Wert handelt es sich nicht um die genaue Parameteranzahl, sondern lediglich um einen Rundungswert. Parameter sind modellinterne Konfigurationsvariablen, die steuern, wie Daten verarbeitet und Vorhersagen getroffen werden. Während des Trainingsprozesses eines Modells werden diese Parameter gesetzt. Die Minimierung der Fehler-, Kosten- oder Verlustfunktion optimiert diese Parameter weiter, um das bestmögliche „Pre-Trained Model“ zu schaffen.

Das „Pre-Trained Model“ wird im laufenden Betrieb in den VRAM (Video Random Access Memory) der GPU geladen. Die Faustformel [4] hierzu lautet:

Ein kleines Rechenbeispiel: Abbildung 1 folgend beinhaltet GPT-3 etwa 175 Milliarden Parameter. Bei einer Präzision von FP16 (Floating Point 16), also 2 Byte pro Parameter, liegt der benötigte VRAM in GB bei:

Ungeachtet der Tatsache, dass GPT-3 längst nicht mehr Stand der Technik ist, sollte bereits auffallen, dass 350 Gigabyte VRAM nur den wenigsten Hobbybastlern und Unternehmen zur Verfügung stehen. Jetzt könnte man sich vielleicht denken:

„Wie praktisch, dass öffentliche LLMs diese Rechenpower zur Verfügung stellen. Wir müssen uns um keine Hardware kümmern und können die (kostenlose) Power des Cloud-Computing mit ChatGPT, Gemini und Co. nutzen.“

Warum dieser Gedanke naiv ist und vor allem im Unternehmenskontext einige Risiken mit sich bringt, klären wir im nächsten Abschnitt.

Probleme von öffentlichen LLMs im Unternehmenskontext

Ich werde mich in diesem Abschnitt auf ChatGPT als Marktführer (über 82 % Marktanteil, Stand Juli 2025 [5]) beschränken. Die meisten angesprochenen Punkte lassen sich ebenfalls auf die Konkurrenz (Gemini, Claude etc.) anwenden.

Wir starten gleich mit dem heiklen Thema „Umgang mit Nutzerdaten“. Es ist schwer zu sagen, wie genau die großen Anbieter wie OpenAI (ChatGPT) mit den Daten, die in das Eingabefeld eingetragen werden, umgehen. Abbildung 2 demonstriert die Einstellungen zur Datenkontrolle in ChatGPT. Klicken Sie als angemeldeter Nutzer unter Einstellungen auf den Unterpunkt „Datenkontrolle“, so wird bei Ihnen vermutlich die Funktion „Das Modell für alle verbessern“ aktiviert sein. Diese Funktion ist standardmäßig aktiviert und erlaubt es OpenAI, die Modelle mit den Daten, die in das Eingabefeld eingegeben werden, zu trainieren. Wenn Sie ChatGPT ohne Account verwenden, können ebenfalls alle Daten zu Trainingszwecken genutzt werden, und es gibt keine Möglichkeit, diese Option auszuschalten [6].

Wollen sie einen sicheren Umgang mit den Daten, dann sollte auf die Business-Version zurückgegriffen werden. Diese kostet mit 29€/Benutzer/Monat (je nach Mitarbeiteranzahl) eine ganze Menge Geld. Wird bei der Anzahl der Mitarbeiterzugänge gespart, so werden am Ende des Tages wieder Schatten-KIs genutzt, und Sie als Unternehmen haben nichts gewonnen.

Ein weiterer Punkt ist, dass Sie Ihr Unternehmen von einem internationalen Anbieter abhängig machen. Durch ungewisse Preisentwicklungen und eventuelle geopolitische Spannungen kann es künftig zu Problemen bei der Nutzung eines solchen Dienstes kommen.

Nun liegt der Gedanke nahe, dass man als Unternehmen ein solches LLM selbst betreiben und somit den Problemen des Datenschutzes, der teils teuren Abo-Modelle und der Abhängigkeit von einem internationalen Unternehmen entgehen könnte. Der Gedanke ist nachvollziehbar und richtig. Betrachtet man noch einmal die Parameteranzahlen der Modelle in Abbildung 1, so wird in Kombination mit dem Rechenbeispiel klar, dass der benötigte VRAM schnell hunderte von Gigabyte groß werden kann. Um dieses hohe initiale Investment zu umgehen, gibt es die Möglichkeit, „kleinere“ Modelle, sogenannte Small Language Models (SLMs), zu nutzen.

Small Language Models

Die Transferleistung von den beschriebenen LLMs hin zu den SLMs ist trivial. Einfach gesagt geht es darum, die Parameteranzahl zu reduzieren und dabei möglichst wenig Einbußen bezüglich der Performance hinnehmen zu müssen. Die Performance von LLMs skaliert zwar mit der Parameteranzahl, die Beziehung ist aber nicht linear [7]. Ab einem gewissen Punkt nehmen die Leistungsgewinne ab, während die Rechen- und Energiekosten stark ansteigen.

Ein SLM basiert (wie sein großer Bruder, das LLM) auf einer Architektur, der neuronale Netze zugrunde liegen. Diese sogenannten Transformer-Modelle haben sich zum Standard innerhalb von NLP (Natural Language Processing) entwickelt. Dem Begriff des Transformers sind die meisten, vielleicht unbewusst, schon über den Weg gelaufen. Schaut man sich die Abkürzung „GPT“ (z. B. in ChatGPT) einmal genauer an, so steht GPT hier für „Generative Pretrained Transformer“, also einen generativen, bereits trainierten Transformer.

Interessierte Leser möchte ich auf das Paper „Attention Is All You Need“ [8] von Google aus dem Jahre 2017 verweisen. Hier wird die Transformer-Architektur technisch detailliert vorgestellt.

Modellkomprimierung

Um ein LLM jetzt zu einem SLM zu transformieren, gibt es einige Techniken, die unter dem Oberbegriff „Modellkomprimierung“ zusammengefasst werden können. Der Begriff „Komprimierung“ dürfte aus der Bild- und Videoverarbeitung bekannt sein. Hierbei geht es darum, die Dateigröße signifikant zu verkleinern und dabei möglichst wenig Verlust der Qualität zu verursachen. Modellkomprimierung verfolgt das gleiche Ziel. Die Parameteranzahl soll so gering wie möglich gehalten werden, während die Modell-Performance weitgehend erhalten bleibt. Gängige Methoden der Modellkomprimierung sind:

• Bereinigung
• Quantisierung
• Low-Rank-Faktorisierung
• Wissensdestillation

Die Bereinigung entfernt weniger wichtige, redundante und unnötige Parameter aus einem neuronalen Netz. Beim Bereinigen von Parametern ist es wichtig, die Balance zwischen Reduktion und Leistung des Modells zu finden.

Die Umwandlung von Daten hoher Genauigkeit in Daten mit niedrigerer Genauigkeit, die sogenannte Quantisierung, stellt eine weitere Stellschraube der Modellkomprimierung dar. Modellgewichte und Aktivierungswerte können hier beispielsweise von 32-Bit-Gleitkommazahlen in 8-Bit-Ganzzahlen konvertiert werden. Quantisierung kann entweder in das Modelltraining integriert (Quantization-Aware Training, QAT) oder nach dem Training durchgeführt werden (Post-Training-Quantization, PTQ).

Eine weitere Komprimierungstechnik ist die „Low-Rank-Faktorisierung“. Diese Technik reduziert die Größe und Komplexität eines Modells durch das Approximieren von großen Gewichtungsmatrizen durch Matrizen niedrigeren Rangs. Dieser Ansatz nutzt die Redundanz innerhalb der Gewichte eines neuronalen Netzes und ermöglicht kompaktere Modelle ohne nennenswerten Genauigkeitsverlust [9].

Wissensdestillation beschreibt den Prozess, das gelernte Wissen eines großen „Lehrermodells“ auf ein kleineres „Schülermodell“ zu übertragen. Das Schülermodell wird dahingehend trainiert, dass die Vorhersagen, die es trifft, mit denen des Lehrermodells übereinstimmen, und dass der zugrunde liegende Denkprozess nachgeahmt wird [10].

Mixture-of-Experts

Nachdem LLMs mit den oben beschriebenen Methoden zu SLMs konvertiert wurden, kann eine weitere Optimierung vorgenommen werden. „Mixture-of-Experts“ bzw. „Intelligentes Routing“ beschreibt den Prozess, mehrere (auf einen Use Case spezialisierte) SLMs hinter einen Router zu schalten, siehe Abbildung 4. Der Router implementiert hierbei ebenfalls ein SLM, welches die Aufgabe hat, den Prompt an das passende Modell weiterzuleiten. Diese Methode erlaubt es, ein breites Wissen in mehrere kleine Modelle zu unterteilen und somit die Hardwareanforderungen für die Inferenz auf dem Level eines SLMs zu halten.

Small Language Models im Unternehmenskontext

Wir wissen jetzt also, was Large Language Models und die Nachteile von Cloud-basierten LLMs im Unternehmenskontext sind. Ebenfalls wissen wir, wie SLMs von LLMs abgeleitet werden. Wie können wir nun das optimale SLM für unser Unternehmen auswählen und implementieren? Um diese Frage zu beantworten, müssen zwei zentrale Fragen beantwortet werden:

• Welche Use Cases soll meine lokale KI abdecken?
• Wie viele parallele Nutzer erwarte ich?

Den spezifischen Use Case innerhalb des Unternehmens zu klären ist einer der wichtigsten Schritte in der Planung einer lokalen KI. Wenn Sie mit der Größe des ausgewählten Modells „übers Ziel hinausschießen“, entstehen unnötige Kosten in Anschaffung und Betrieb. Falls Sie ein zu kleines Modell für Ihren Anwendungsfall wählen, werden Ihre Mitarbeitenden eventuell auf öffentliche LLMs zurückgreifen, da die Ergebnisse und die Performance der lokalen Lösung unbefriedigend sind. Tabelle 1 präsentiert Beispiel-Use-Cases zu verschiedenen Modellgrößen. Die Hardwarekosten ergeben sich folglich aus der getroffenen Auswahl.

Außerdem ist es wichtig abzuschätzen, wie viele parallele Nutzer zu erwarten sind. Skalieren Sie ihr lokales SLM für 10 parallele Nutzer und es sind letztendlich durchschnittlich 20, so leidet auch hier die Performance, und es wird eventuell auf öffentliche LLMs zurückgegriffen.

Parameter Spanne	Typische Aufgaben	Performance	Trade-Offs	VRAM (bei FP16)	Mögliche GPU	Open-Source Modelle
1-3 Mrd.	Mobile Inferenzen, Einfaches NLP	Schnell	Geringes Kontext-Verständnis	2-6 GB	RTX 3050/3060	Gemma 2B, Mistral Tiny
7-13 Mrd.	Chat, Zusammenfassung	Gute Balance	Moderate Rechenkosten	14-28 GB	RTX 4090	LLaMA 3 8B, Mistral 7B
30-70 Mrd.	Fortgeschrittenes Denken, Code	Hohe Genauigkeit	Benötigt Enterprise GPUs	60-140 GB	A100 80GB, H100 94 GB	LLaMA 3 70B, Yi 34B
100+ Mrd.	Forschung	Top Performance	Hohe Kosten und Latenzen	200+ GB	H100 x4+	Falcon 180B, Qwen 2 110B

Tabelle 1: Parameteranzahl und dazugehörige Use Cases (lediglich eine Auswahl, keine Vollständigkeit)

Wollen verschiedene Nutzer verschiedene SLMs nutzen, so muss die GPU alle angefragten Modelle in den VRAM laden können. Daraus lässt sich folgende Bedingung ableiten:

Wollen verschiedene Nutzer dasselbe Modell nutzen, so muss lediglich dieses eine Modell in den VRAM geladen werden. Somit werden Modellgröße und Aktivierungen nur einmalig berechnet. Der KV-Cache skaliert linear mit der Anzahl der parallelen Nutzer. Für mehrere Nutzer auf demselben Modell lässt sich also nachfolgende Bedingung festhalten:

Ich empfehle die folgende Website zum Überschlagen der VRAM-Anforderungen: https://apxml.com/tools/vram-calculator

Als Ergebnis wird unter anderem die zu erwartende Tokens/s angegeben. Ein flüssiges Erlebnis beim Chatten mit einem SLM liegt bei etwa 20 Tokens/s. Ein Token entspricht etwa einem Dreiviertel Wort, bzw. 100 Token entsprechen etwa 75 Wörtern. Um auszuloten, welche Tokens/s-Rate für sie noch akzeptabel ist, empfehle ich folgende Website: https://shir-man.com/tokens-per-second/

Implementierungshinweise

Nachdem der Use Case und die zu erwartende Anzahl an parallelen Nutzern bestimmt wurden, steht die benötigte Hardware für die unternehmensinterne KI fest. Im Folgenden beschreibe ich Tipps und Hinweise für die Inbetriebnahme des lokalen SLMs.

Um SLMs downloaden, managen und ausführen zu können, wird ein sogenannter „Model-Runner“ benötigt. Hier möchte ich zwei gängige Frameworks vorstellen, die, abhängig vom Use Case und von der Nutzeranzahl, ihre Vor- und Nachteile mit sich bringen.

Ollama ist ein lokaler Model-Runner. Einfach gesagt: Ollama erlaubt es, LLMs/SLMs zu downloaden und lokal auf Ihrem Computer laufen zu lassen. Das Framework arbeitet im Hintergrund und bietet ein Command-Line-Interface (CLI). Ollama profitiert von:

• einfacher Installation
• guter OS-Unterstützung
• CPU-Inferenz-Unterstützung
• Echtzeit-Wechsel zwischen verschiedenen Modellen nach Start des Ollama-Servers

vLLM wurde 2023 das erste Mal vorgestellt [11] und verfolgt das gleiche Ziel wie Ollama. Allerdings werden zusätzliche Optimierungen in der Speichernutzung angewandt. In diesem Zusammenhang stellen die Autoren den Attention-Algorithmus „PagedAttention“ vor, welcher in der vLLM-Bibliothek implementiert ist. Dieser Algorithmus ist inspiriert von den klassischen Praktiken für virtuellen Speicher und Paging. Das Paper bewirbt vLLM als ein Framework, welches:

• einen stark optimierten Key Value (KV) Cache besitzt und die flexible, gemeinsame Nutzung des KV-Cache innerhalb von Anfragen und anfragenübergreifend ermöglicht.
• Diese Optimierung wird in Abbildung 5 Hier ist zu erkennen, wie vLLM seine Stärken in der Bearbeitung paralleler Anfragen ausspielen kann.

Während Ollama schnell aufgesetzt ist und viele Betriebssysteme unterstützt werden, bietet vLLM eine insgesamt bessere Performance, vor allem aber in Bezug auf parallele Anfragen. Außerdem bietet vLLM die Möglichkeit, das Setup durch mehrere Knoten zu einem sogenannten „Ray“-Cluster zu skalieren. Welches der beiden Frameworks für Ihre lokale Implementierung eines SLMs am besten passt, muss im Einzelfall geklärt werden.

Sowohl Ollama als auch vLLM stellen ein CLI zur Interaktion bereit. Während ein CLI für „Techies“ vielleicht eine angenehme Art der Interaktion darstellt, ist eine GUI-basierte Interaktion für Mitarbeitende vermutlich die intuitivere Lösung.

Um zu verhindern, dass Mitarbeitende wegen der komplexen Nutzeroberfläche auf öffentliche LLMs zurückgreifen, ist es wichtig, ein benutzerfreundliches Frontend mit bekannten Strukturen zu implementieren. Ich empfehle hier „Open WebUI“. Mit über 115.000 Sternen auf GitHub (Stand 11.2025) handelt es sich aktuell um eines der populärsten KI-Interfaces. Nutzer bekommen eine bekannte, browserbasierte Benutzeroberfläche im Stil eines ChatGPT geboten und finden sich intuitiv zurecht. Open WebUI kann sowohl mit Ollama als auch mit vLLM verknüpft werden. Abbildung 6 stellt den schematischen Aufbau einer lokalen SLM-Implementierung dar.

Neben Open WebUI gibt es noch weitere Frontend-Anbieter mit individuellen Vor- und Nachteilen. Vollständigkeitshalber möchte ich hier noch einige „Konkurrenten“ nennen:

• Lobechat (67.000 GitHub Sterne)
• Page Assist (7.000 GitHub Sterne)
• Anything LLM (51.000 GitHub Sterne)

Welches Frontend für Ihren spezifischen UseCase am besten passt, ist auch hier im Einzelfall zu klären und durch ausführliche Tests zu evaluieren.

Fazit

Ein KI-basierter Chatbot als Sparringspartner im alltäglichen Berufsleben ist aus den meisten Bürojobs kaum mehr wegzudenken. Um die Nutzung der KI aber sicher und unabhängig zu gestalten, ist es für Unternehmen notwendig, sich mit den Möglichkeiten der selbst gehosteten KI auseinanderzusetzen. Hier kann schon mit relativ wenig Budget viel erreicht werden. Verschiedene Optimierungsverfahren erlauben es, LLMs in SLMs zu komprimieren und die Hardwareanforderungen drastisch zu verringern. Diese Entwicklungen, in Kombination mit optimierter Speichernutzung durch Frameworks wie vLLM, führen dazu, dass eine lokal gehostete KI für kleine und mittelständische Unternehmen kein Zukunftstraum mehr ist. Für Unternehmen besteht nun die Chance, sich von internationalen Konzernen unabhängig zu machen und die Kontrolle über sensible Daten zu wahren. Pilotprojekte mit wenig Nutzern können die Nutzbarkeit validieren, und die lokale KI kann mit dem Unternehmen skalieren.

Es gibt kein allgemeingültiges Rezept dafür, wie eine lokale KI implementiert werden kann. Ziel eines Unternehmens sollte es aber sein, die Notwendigkeit einer lokalen KI zu evaluieren und daraus folgend die unternehmensspezifischen Parameter wie Use Case, Modell, Hardware, Model Runner und Frontend abzuleiten.