Warum LLMs überhaupt On-Premise

Die meisten Unternehmen starten mit einer Cloud-API. Das ist der schnellste Weg, ein Sprachmodell auszuprobieren, und für viele Anwendungsfälle bleibt es die richtige Wahl. Doch sobald echte Geschäftsdaten ins Spiel kommen — Kundenakten, Verträge, Konstruktionsdaten, Personalunterlagen — stellt sich die Frage, ob diese Daten das eigene Netz verlassen sollen. Genau hier wird On-Premise interessant.

Der stärkste Grund ist Datensouveränität. Wenn das Modell auf Ihrer eigenen Hardware läuft, verlässt kein einziger Datensatz Ihr Haus. Kein externer Anbieter verarbeitet Ihre Eingaben, keine Kopie liegt auf einem Server in einer anderen Jurisdiktion. Für DSGVO-relevante Prozesse und für Branchen mit strengen Vertraulichkeitsanforderungen ist das oft nicht nur bequem, sondern die Voraussetzung dafür, KI überhaupt einsetzen zu dürfen.

Der zweite Grund ist Kosten bei Volumen. Cloud-APIs rechnen pro Token ab. Bei gelegentlicher Nutzung ist das günstig. Wenn aber täglich Tausende von Anfragen laufen — Dokumente klassifizieren, Anfragen beantworten, Texte zusammenfassen — summieren sich diese Beträge schnell. Eigene Hardware verursacht eine einmalige Investition und danach im Wesentlichen nur Stromkosten. Ab einem gewissen Durchsatz kippt die Rechnung zugunsten von On-Premise.

Dazu kommen zwei weitere Punkte: kein Vendor-Lock-in — Sie wählen und wechseln offene Modelle frei, ohne an die Roadmap oder Preispolitik eines Anbieters gebunden zu sein — und die Fähigkeit, vollständig offline oder in abgeschotteten (air-gapped) Umgebungen zu arbeiten. Für Fertigung, Behörden oder sensible Forschung ist das oft ausschlaggebend.

Ehrlich betrachtet ist On-Premise kein Selbstläufer. Sie tauschen laufende API-Gebühren gegen eine Hardware-Investition und den Aufwand, das System selbst zu betreiben: Updates, Monitoring, Ausfallsicherheit. Wer das nicht mitplant, spart an der falschen Stelle.

Ob sich der Betrieb im eigenen Haus lohnt, hängt am Ende an Volumen, Datenanforderungen und Team. Wie wir das für konkrete Projekte planen, beschreiben wir auf unserer Seite zur KI-Entwicklung.

Welche Modellgröße Sie wirklich brauchen

Der häufigste Denkfehler beim Einstieg lautet: größer ist besser. Das Gegenteil ist oft der Fall. Die Größe eines Modells wird in Parametern gemessen — den einstellbaren Werten, die das Modell während des Trainings lernt. Mehr Parameter bedeuten mehr allgemeines Wissen, aber auch drastisch höheren Hardware-Bedarf. Für eine eng umrissene Aufgabe zahlen Sie diesen Aufschlag oft, ohne einen Vorteil zu bekommen.

Für viele Geschäftsanwendungen schlägt ein kleineres, auf die eigene Domäne feinabgestimmtes Modell einen riesigen Generalisten. Ein Modell, das gezielt auf Ihre Dokumente, Ihre Fachsprache und Ihre wiederkehrenden Aufgaben trainiert wurde, liefert bei genau diesen Aufgaben präzisere Ergebnisse als ein Allrounder — bei einem Bruchteil des Hardware-Bedarfs.

Grobe Orientierung nach Größenklasse

Als grobe Einordnung — nicht als feste Regel — lassen sich offene Modelle in Stufen denken:

7 bis 8 Milliarden Parameter (7–8B). Die praktische Einstiegsklasse. Solche Modelle laufen auf vergleichsweise bescheidener Hardware und sind erstaunlich fähig, wenn die Aufgabe klar umrissen ist: Klassifikation, Extraktion, Zusammenfassungen, ein Fachassistent mit angebundener Wissensbasis. Für die meisten ersten Projekte ist das der richtige Startpunkt.

Rund 13 Milliarden Parameter (~13B). Ein Mittelweg. Etwas mehr sprachliche Feinheit und Zusammenhangsverständnis, dafür spürbar mehr Hardware-Bedarf. Sinnvoll, wenn die 7–8B-Klasse an Grenzen stößt, ein großes Modell aber überdimensioniert wäre.

30 bis 70 Milliarden Parameter (30–70B). Die Oberklasse für den Eigenbetrieb. Hier gewinnen Sie breites Weltwissen und stärkeres mehrstufiges Denken — nützlich für offene, weniger vorhersehbare Aufgaben. Der Preis ist erheblicher Hardware-Aufwand, meist mit mehreren GPUs. Diese Klasse rechtfertigt sich, wenn die Aufgabe wirklich Breite und Tiefe verlangt.

Die richtige Wahl ist selten das größte Modell, das Ihr Budget hergibt. Sie ist das kleinste Modell, das die Aufgabe zuverlässig erledigt. Das spart nicht nur bei der Anschaffung, sondern auch dauerhaft im Betrieb.

Nahaufnahme einer GPU-Grafikkarte — die Komponente, die bestimmt, welche LLMs sich on-premise betreiben lassen
Der GPU-Speicher — nicht die reine Geschwindigkeit — entscheidet, welche Modelle laufen. Ihn richtig zu dimensionieren ist der Kern der On-Premise-Frage.

GPU-Speicher ist die echte Grenze

Wenn Menschen an KI-Hardware denken, denken sie an Geschwindigkeit. Bei LLMs ist die entscheidende Größe jedoch eine andere: der GPU-Speicher, oft als VRAM bezeichnet. Er ist der eigentliche Engpass, der darüber entscheidet, ob ein Modell auf einer Maschine überhaupt läuft — nicht, wie schnell es rechnet.

Der Grund ist einfach. Damit ein Modell arbeiten kann, müssen zwei Dinge gleichzeitig in den GPU-Speicher passen: die Modellgewichte (die eigentlichen Parameter) und der Kontext (die aktuelle Eingabe plus alles, was das Modell für seine Antwort im Blick behält). Passt beides nicht hinein, läuft das Modell nicht — Punkt. Eine schnellere GPU mit zu wenig Speicher hilft nicht.

Faustregel: Multiplizieren Sie die Parameterzahl in Milliarden mit den Bytes pro Parameter. In voller 16-Bit-Präzision sind das rund 2 Byte pro Parameter — ein 7B-Modell braucht also grob 14 GB allein für die Gewichte, plus Reserve für den Kontext. Bei geringerer Präzision sinkt dieser Bedarf deutlich (siehe nächster Abschnitt).

Diese Rechnung erklärt, warum die Auswahl der GPU beim VRAM beginnt und nicht bei der Rechenleistung. Erst wenn feststeht, dass Modell und Kontext in den Speicher passen, wird die reine Geschwindigkeit relevant — sie beeinflusst dann, wie schnell Antworten erscheinen und wie viele Nutzer parallel bedient werden können. Die erste Frage bei jeder Konfiguration lautet daher immer: Passt es überhaupt in den Speicher?

Quantisierung: Mehr aus weniger

Genau hier setzt eine Technik an, die den Hardware-Bedarf oft entscheidend senkt: die Quantisierung. Sie ist der wichtigste Hebel, um größere Modelle auf kleinerer Hardware zum Laufen zu bringen — und der Grund, warum die Faustregel aus dem letzten Abschnitt in der Praxis fast immer nach unten korrigiert wird.

Der Grundgedanke: Standardmäßig speichert ein Modell jeden Parameter mit hoher Präzision — mit vielen Nachkommastellen sozusagen. Quantisierung reduziert diese Präzision. Statt jeden Wert mit 16 Bit abzulegen, verwendet man 8 Bit oder sogar 4 Bit. Man rundet die Zahlen also gröber. Das klingt zunächst nach Qualitätsverlust — und ein wenig ist es das auch —, doch der Effekt ist erstaunlich gering, während die Einsparung erheblich ist.

Konkret bedeutet das: Ein Modell, das in voller Präzision rund 14 GB Speicher belegt, kann quantisiert auf einen Bruchteil davon schrumpfen. Damit passt ein Modell, das vorher zwei GPUs verlangte, plötzlich auf eine einzige — oder ein Modell, das gar nicht lief, läuft nun auf bezahlbarer Hardware.

Der Trade-off: Bei moderater Quantisierung ist der Qualitätsverlust für die meisten Geschäftsaufgaben kaum spürbar. Erst bei sehr aggressiver Reduktion beginnt die Antwortqualität merklich zu leiden. Der Sweet Spot liegt fast immer bei einer maßvollen Stufe, die Speicher spart, ohne das Ergebnis zu verwässern.

Für die Praxis heißt das: Bevor Sie eine größere oder teurere GPU kaufen, prüfen Sie, ob eine quantisierte Version des gewünschten Modells Ihre Anforderungen bereits erfüllt. In sehr vielen Fällen tut sie das — und macht eine deutlich günstigere Konfiguration möglich.

Beispiel-Konfigurationen

Aus Modellgröße, Speicherbedarf und Quantisierung ergeben sich in der Praxis einige typische Ausbaustufen. Die folgenden Beschreibungen kommen bewusst ohne Preise oder Benchmark-Zahlen aus — die ändern sich zu schnell und hängen zu stark vom Markt ab. Es geht um die Eignung, nicht um Spezifikationen.

Einstiegs-Workstation mit einer GPU

Eine einzelne, solide Consumer- oder Einsteiger-Profi-GPU in einer Workstation. Diese Stufe ist ideal, um kleine Modelle (7–8B, gern quantisiert) zu betreiben und ein Pilotprojekt aufzusetzen. Sie reicht, um Machbarkeit zu zeigen, erste Prozesse zu automatisieren und Erfahrung im eigenen Haus aufzubauen — ohne große Vorabinvestition. Für die Bedienung eines einzelnen Teams oder eines abgegrenzten Anwendungsfalls ist das oft schon ausreichend.

Mittelklasse-Server mit Profi-GPU

Ein dedizierter Server mit einer professionellen GPU, die deutlich mehr Speicher mitbringt. Diese Stufe trägt ein produktives Abteilungs-Tool: mittelgroße Modelle, mehrere gleichzeitige Nutzer, stabiler Dauerbetrieb. Sie ist der typische Zielzustand für ein Unternehmen, das ein LLM fest in einen Geschäftsprozess integriert hat und Verlässlichkeit braucht, aber kein Rechenzentrum aufbauen will.

Multi-GPU-System

Mehrere Profi-GPUs in einem Server, deren Speicher zusammengeschaltet wird. Diese Stufe wird nötig, wenn wirklich große Modelle (30–70B) laufen sollen oder viele Nutzer gleichzeitig bedient werden müssen. Sie bedeutet höhere Investition und mehr Betriebsaufwand, eröffnet dafür aber die volle Bandbreite dessen, was mit offenen Modellen im eigenen Haus möglich ist. Für die meisten Mittelständler ist das der Schritt, den man erst geht, wenn die kleineren Stufen ihre Grenzen erreicht haben — nicht der Startpunkt.

Wie diese Stufen konkret umgesetzt werden und was zur bestehenden IT passt, planen wir individuell — mehr dazu unter KI-Entwicklung.

Cloud vs. On-Premise: Kosten

Die Kostenfrage lässt sich nicht mit einer einzigen Zahl beantworten, aber sehr gut als Denkweise fassen: Es gibt einen Break-even-Punkt, an dem sich die Rechnung von der Cloud zur eigenen Hardware verschiebt. Wo dieser Punkt liegt, hängt vor allem am Volumen.

Wann die Cloud günstiger ist. Bei geringem oder stark schwankendem Volumen gewinnt die Cloud fast immer. Sie zahlen nur, was Sie tatsächlich nutzen, es gibt keine Vorabinvestition, und Sie starten in Stunden statt in Wochen. Für Prototypen, unregelmäßige Nutzung und Teams, die erst herausfinden, ob KI ihnen überhaupt hilft, ist die Cloud der vernünftige Weg. Auch die reine Rechenlast, die Sie nicht selbst warten müssen, hat ihren Wert.

Wann On-Premise gewinnt. Sobald das Volumen stetig hoch ist, kehrt sich das Bild um. Die einmalige Hardware-Investition amortisiert sich über die eingesparten API-Gebühren, und ab dem Break-even wird jeder weitere Verarbeitungsschritt praktisch zum Nulltarif erledigt. Dazu kommt der zweite, oft wichtigere Treiber: strenge Datenregeln. Wenn Ihre Daten das Haus ohnehin nicht verlassen dürfen, entfällt die Cloud als Option — und die Frage ist nicht mehr, ob On-Premise günstiger ist, sondern nur noch, wie Sie es sinnvoll dimensionieren.

Break-even-Denken statt fester Zahl: Rechnen Sie nicht mit einer pauschalen Grenze, sondern mit Ihrem eigenen Fall: erwartetes Anfragevolumen, wie stetig es ist, und ob Ihre Daten das Netz verlassen dürfen. Diese drei Größen entscheiden, auf welcher Seite des Break-even Sie stehen.

Richtig dimensionieren

Der teuerste Fehler beim Einstieg in On-Premise-LLMs ist derselbe wie bei jeder Infrastruktur-Entscheidung: Hardware kaufen, bevor man die tatsächliche Last kennt. Eine zu große Maschine bindet Kapital in ungenutzter Leistung. Eine zu kleine bremst genau in dem Moment, in dem der Anwendungsfall Erfolg hat und skalieren soll. Beides lässt sich vermeiden — aber nur, wenn die Reihenfolge stimmt.

Die richtige Reihenfolge lautet: erst die Aufgabe klären, dann das passende Modell wählen, dann den Speicherbedarf bestimmen, dann prüfen, ob Quantisierung die Anforderung senkt — und erst am Ende die Hardware festlegen. Wer diese Kette einhält, kauft nicht das größte verfügbare System, sondern das kleinste, das die reale Last trägt. Das ist fast immer die deutlich günstigere Entscheidung.

Genau diese Dimensionierung nehmen wir im KI-Readiness-Check vorab ab: Wir bestimmen Modellgröße, Speicherbedarf und eine passende Konfiguration, bevor irgendeine Anschaffung ansteht. So kaufen Sie, was die Last braucht — nicht, was ein Anbieter verkauft. Den Einstieg finden Sie hier: KI-Readiness-Check.