On-Premise oder Cloud: Wo Ihr LLM laufen sollte

Die Frage kommt in fast jedem Erstgespräch, oft noch vor der Frage nach dem Anwendungsfall: Können wir das On-Premise betreiben, oder müssen die Daten in die Cloud. Dahinter steht meist ein verständliches Unbehagen. Unternehmensdaten an eine API zu schicken, deren Innenleben man nicht kennt, fühlt sich nach Kontrollverlust an. Ein Server im eigenen Rechenzentrum fühlt sich nach Sicherheit an.

Gefühle sind allerdings eine schlechte Grundlage für Infrastrukturentscheidungen. Ein selbst betriebenes LLM ist keine Appliance, die man einsteckt und vergisst, sondern ein anspruchsvolles Stück Betrieb mit eigener Hardware, eigenem Personalbedarf und einem Qualitätsniveau, das unter dem der großen Cloud-Modelle liegt. Umgekehrt ist die Cloud-API nicht automatisch die richtige Antwort, denn es gibt Konstellationen, in denen On-Premise schlicht Pflicht ist. Die Entscheidung verdient eine nüchterne Prüfung entlang von vier Fragen: Warum, was kostet es, was verliert man, und gibt es einen Mittelweg.

Echte Gründe für On-Premise, und gefühlte

Es gibt harte Gründe, ein Modell im Haus zu betreiben. Vertragliche Vorgaben von Kunden oder Auftraggebern, die eine Verarbeitung außerhalb der eigenen Infrastruktur ausschließen. Regulatorische oder sicherheitsbedingte Netztrennung, etwa in Umgebungen ohne Internetzugang. Datenkategorien, deren Weitergabe an Dritte aus rechtlichen oder standesrechtlichen Gründen nicht oder nur mit unverhältnismäßigem Aufwand zulässig wäre. Wer in einer dieser Situationen ist, braucht keine Abwägung mehr, sondern eine gute On-Premise-Architektur.

Daneben stehen die gefühlten Gründe, und sie tragen selten. Die Cloud ist unsicher ist als Pauschalurteil nicht haltbar, seriöse Anbieter bieten Auftragsverarbeitungsverträge, EU-Datenregionen und die Zusicherung, Eingaben nicht für Training zu verwenden. Wir wollen unabhängig sein klingt gut, aber die Abhängigkeit verschiebt sich nur: weg vom API-Anbieter, hin zu GPU-Lieferanten, Modell-Herausgebern und dem eigenen Betriebsteam. Der ehrliche Test lautet: Kann jemand das konkrete Verbot benennen, schriftlich und mit Quelle. Wenn ja, ist der Grund echt. Wenn die Antwort bei einem allgemeinen Unbehagen bleibt, lohnt sich der Blick auf die Alternativen, bevor Hardware bestellt wird.

Hardware und Betrieb realistisch rechnen

Wer On-Premise ernsthaft erwägt, sollte die volle Rechnung aufmachen, nicht nur den Preis der Grafikkarten. Leistungsfähige Modelle brauchen Server-GPUs mit viel Speicher, oft im Verbund. Dazu kommen Strom und Kühlung im Dauerbetrieb, Redundanz für den Ausfallfall, und die Dimensionierung auf Lastspitzen: Eine eigene Maschine hat eine feste Kapazität, während eine API mit der Nachfrage atmet. Wer für die Spitze dimensioniert, bezahlt die restliche Zeit Leerlauf. Wer für den Durchschnitt dimensioniert, hat zur Spitze Wartezeiten.

Der größere Posten ist aber selten die Hardware, sondern der Mensch. Ein produktiver Inferenz-Betrieb braucht jemanden, der Modellversionen sichtet und testet, den Serving-Stack aktuell und sicher hält, Monitoring und Alarmierung betreibt und bei Störungen erreichbar ist. Das ist eine dauerhafte Teilzeit- bis Vollzeitaufgabe, je nach Anspruch an Verfügbarkeit. In der Kalkulation vieler Projekte fehlt genau diese Zeile, und sie ist über die Jahre gerechnet häufig die teuerste.

Der Qualitätsabstand und was er im Alltag bedeutet

On-Premise heißt in der Praxis: offene Modelle. Die haben ein beachtliches Niveau erreicht, aber bei komplexen Aufgaben, langem mehrstufigem Schlussfolgern und strikter Regelbefolgung bleibt ein spürbarer Abstand zu den führenden Cloud-Modellen. Dieser Abstand ist kein abstrakter Benchmark-Wert, sondern übersetzt sich in Arbeit: Aufgaben müssen kleinteiliger zerlegt, Prompts sorgfältiger gebaut, Ausgaben strenger nachgeprüft werden. Ein Feature, das mit einem Frontier-Modell in zwei Wochen steht, kann mit einem selbst gehosteten Modell ein Mehrfaches an Engineering kosten, um dieselbe verlässliche Qualität zu erreichen.

Für eng umrissene Aufgaben wie Klassifikation oder Extraktion ist der Abstand oft vernachlässigbar. Für einen Assistenten, der frei über heterogene Dokumente arbeiten soll, ist er es nicht. Die Einordnung liefert auch hier ein eigenes Eval-Set: dieselben Prüffälle gegen das Cloud-Modell und den On-Premise-Kandidaten laufen lassen und die Differenz beziffern, bevor entschieden wird.

Hybride Architekturen: nur das Sensible bleibt im Haus

Zwischen alles lokal und alles in der Cloud liegt ein Mittelweg, der in der Praxis oft die beste Antwort ist: Nur die sensiblen Teilschritte laufen im Haus. Typische Muster:

• PII-Redaktion vor der API: Ein kleines lokales Modell erkennt und maskiert personenbezogene Angaben, erst der bereinigte Text geht an das Cloud-Modell.
• Lokale Vorklassifikation: Ein lokaler Schritt entscheidet, ob ein Dokument eine geschützte Kategorie berührt. Nur unkritische Inhalte verlassen das Haus, der Rest wird lokal oder gar nicht maschinell verarbeitet.
• Zentrales Gateway: Alle LLM-Aufrufe laufen durch einen eigenen Dienst, der Redaktion, Protokollierung und Routing übernimmt. Welches Modell wo antwortet, ist dann Konfiguration statt Umbau.

Solche Architekturen holen einen Großteil der Datenhoheit zu einem Bruchteil der On-Premise-Kosten, weil die lokale Komponente klein und anspruchslos bleiben darf.

TCO über die Nutzungsdauer

Am Ende gehört beides in eine Gesamtkostenrechnung über die geplante Nutzungsdauer, üblicherweise drei bis fünf Jahre. Auf der On-Premise-Seite stehen Anschaffung und Abschreibung der Hardware, Strom, Kühlung, Stellfläche, Wartungsverträge und der Personalaufwand für den Betrieb, weitgehend unabhängig von der tatsächlichen Nutzung. Auf der Cloud-Seite stehen nutzungsabhängige Token-Kosten plus Integrationsaufwand, dafür ohne Sockel. Die Konsequenz: On-Premise rechnet sich mit der Auslastung. Bei konstant hohem Volumen auf engen Aufgaben kann die eigene Maschine günstiger werden, bei schwankender oder wachsender Nutzung ist die API fast immer im Vorteil, weil sie mitwächst und weil sinkende Token-Preise und bessere Modelle ohne eigene Investition ankommen. Eine gekaufte GPU wird dagegen jedes Jahr älter, während die Anforderungen es nicht tun.

Fazit

Die Frage On-Premise oder Cloud beantwortet sich entlang harter Kriterien, nicht entlang von Bauchgefühl. Echte Gründe für den Eigenbetrieb sind vertragliche Vorgaben, Netztrennung und Datenkategorien, die das Haus nicht verlassen dürfen. Wo diese fehlen, spricht die Rechnung meist für die Cloud: Der Betrieb eigener Inferenz-Hardware ist teurer und personalintensiver als erwartet, und der Qualitätsabstand offener Modelle kostet Engineering. Der unterschätzte Mittelweg ist die hybride Architektur, bei der ein kleines lokales Modell die sensiblen Teilschritte übernimmt und der Rest über die API läuft. Wer die Entscheidung so trifft, mit benannten Vorgaben, einem Eval-Vergleich und einer ehrlichen TCO-Rechnung über die Nutzungsdauer, muss sie später selten revidieren.