LLM-Betrieb: Cloud, eigenes Blech oder beides?

"Cloud oder eigene Hardware" ist bei LLMs selten eine Entweder-oder-Frage – in der Praxis sehen wir bei fast jedem Kunden am Ende ein hybrides Setup. Die eigentliche Arbeit besteht darin, sauber zu bestimmen, welche Anfragen wohin gehören, und das nicht nach Bauchgefühl, sondern nach einem nachvollziehbaren Entscheidungsrahmen.

Entscheidungsrahmen: Kosten, Datenschutz, Latenz, Skalierung

Vier Kriterien bestimmen, wo eine LLM-Anfrage am besten aufgehoben ist:

• Kosten – Cloud-Modelle rechnen pro Token, eigene Hardware hat feste Kosten unabhängig vom Volumen. Bei hohem, gleichmäßigem Anfragevolumen kippt die Rechnung zugunsten eigener Hardware; bei niedrigem oder stark schwankendem Volumen bleibt Cloud günstiger.
• Datenschutz – manche Anfragen (Verträge, Gesundheitsdaten, interne Strategiedokumente) sollten das eigene Netz grundsätzlich nicht verlassen, unabhängig vom Preis.
• Latenz – interaktive Anwendungen mit vielen kurzen Roundtrips profitieren von lokaler Inferenz ohne Umweg über das Internet.
• Skalierung – Cloud-Modelle skalieren praktisch unbegrenzt und sofort; eigene Hardware hat eine feste Obergrenze, die man vorher dimensionieren muss.

Kein Kriterium sticht die anderen automatisch – die Gewichtung hängt vom konkreten Anwendungsfall ab. Ein Kundenservice-Chatbot mit öffentlichen Produktfragen hat andere Anforderungen als eine interne Vertragsanalyse.

Hybrid-Routing in der Praxis

Der pragmatischste Ansatz, den wir in Projekten immer wieder umsetzen, ist ein Router, der Anfragen nach Komplexität und Sensibilität aufteilt:

Routine-Anfragen → lokales Modell

Klassifikation, Zusammenfassungen, einfache Extraktion, interne Suche – Aufgaben, bei denen ein gut quantisiertes, lokal betriebenes Modell zuverlässig genug ist und gleichzeitig sensible Inhalte im eigenen Netz hält.

Schwere Aufgaben → Premium-Cloud-Modell

Komplexes Schlussfolgern, lange Kontexte, Aufgaben mit hohem Qualitätsanspruch, bei denen ein Fehler teuer wird – hier lohnt sich der höhere Preis eines leistungsstarken Cloud-Modells, weil die Qualität den Unterschied macht, nicht die Kosten pro Anfrage.

Der Router selbst muss nicht kompliziert sein: eine einfache Klassifizierung der Anfrage (Länge, erkannte Sensibilität, Aufgabentyp) reicht in den meisten Fällen, um die Mehrheit der Anfragen automatisch korrekt zuzuweisen. Wichtig ist ein Fallback-Pfad: Wenn das lokale Modell bei einer Aufgabe erkennbar unsicher ist, sollte die Anfrage automatisch an das leistungsstärkere Cloud-Modell eskalieren, statt eine schwache Antwort auszuliefern.

Ein einfaches Routing-Beispiel

Ein typisches Setup, das wir für Kunden umsetzen: Eingehende Anfragen durchlaufen zunächst einen leichten Klassifizierer, der Länge, erkannte Themenfelder und ein grobes Komplexitätsmaß bestimmt. Kurze, klar strukturierte Anfragen (etwa "Fasse dieses Dokument in drei Sätzen zusammen") gehen an das lokale Modell. Anfragen mit Anzeichen von Mehrdeutigkeit, sehr langem Kontext oder explizit hoher Priorität gehen direkt an das Cloud-Modell. Diese einfache Regel deckt in der Praxis oft schon 70 bis 80 Prozent aller Anfragen korrekt ab, ohne dass ein aufwendiges Machine-Learning-Routing nötig wäre.

Kostenkontrolle und Budget-Gates

Ein Risiko, das bei Cloud-LLMs leicht unterschätzt wird: Ohne Obergrenze kann ein einzelner fehlerhafter Prozess (eine Endlosschleife, ein ungewollt teures Modell für eine triviale Aufgabe) in kurzer Zeit ein Budget sprengen, das eigentlich für einen ganzen Monat gedacht war. Sinnvolle Kostenkontrolle bedeutet: harte Budget-Gates pro Tag oder Woche, Alarmierung bei ungewöhnlichem Verbrauch, und ein bewusster Modell-zu-Aufgabe-Mapping, statt für jede Anfrage automatisch das teuerste verfügbare Modell zu wählen.

Eigene Hardware hat dieses Risiko strukturell nicht – die Kosten sind fix, egal wie viele Anfragen kommen. Das ist einer der unterschätzten Vorteile lokaler Modelle: planbare Kosten sind für ein Unternehmen oft wertvoller als im Schnitt niedrigere, aber schwankende Kosten.

Betriebsaspekte: Monitoring und Ausfallpfade

Egal ob Cloud, lokal oder hybrid – der LLM-Betrieb braucht dieselbe betriebliche Disziplin wie jede andere produktionskritische Komponente. Zwei Punkte, die häufig zu spät bedacht werden:

• Monitoring der Inferenz – nicht nur "läuft der Dienst", sondern auch Antwortqualität, Latenz-Trends und Kostenverlauf über die Zeit. Ein Modell, das langsam schlechtere Antworten liefert (z. B. durch eine fehlerhafte Prompt-Änderung), fällt sonst erst auf, wenn Kunden sich beschweren.
• Ausfallpfade – was passiert, wenn das lokale Modell nicht erreichbar ist oder die Cloud-API eine Störung hat? Ein robustes Setup hat einen definierten Fallback (zum jeweils anderen Pfad, oder im Zweifel eine einfache Regel-basierte Antwort statt eines Totalausfalls).

Diese Betriebsaspekte sind kein Nice-to-have, sobald ein LLM-Prozess Teil eines Kundenkontaktpunkts oder eines internen Kernprozesses wird. Ein LLM, das ohne Monitoring und Fallback läuft, ist letztlich ein Single Point of Failure mit zusätzlicher Unsicherheit über die Antwortqualität.

Ein oft unterschätzter Betriebsaspekt ist die Versionierung von Modellen und Prompts. Cloud-Anbieter aktualisieren ihre Modelle regelmäßig, teils mit spürbaren Verhaltensänderungen; lokale Modelle bleiben stabil, bis man selbst ein Update einspielt. Wer produktiv auf ein Cloud-Modell setzt, sollte Antwortqualität kontinuierlich mit festen Testfällen prüfen, statt sich darauf zu verlassen, dass ein Anbieter-Update keine Regression verursacht. Diese Disziplin unterscheidet einen soliden LLM-Betrieb von einem, der bei der nächsten stillen Modelländerung überrascht wird.

Empfehlung: Mit Hybrid starten

Für die meisten Unternehmen, die neu in den produktiven LLM-Betrieb einsteigen, ist der pragmatischste Startpunkt ein einfaches Hybrid-Setup: ein kleines, lokal betriebenes Modell für Routineaufgaben und Embeddings, kombiniert mit einer Cloud-API für alles, was Qualität, Kontextlänge oder Spitzenlast verlangt. Das begrenzt das Anfangsrisiko in beide Richtungen – man kauft keine überdimensionierte eigene Hardware, bevor der tatsächliche Bedarf bekannt ist, und man ist keiner unkontrollierten Cloud-Rechnung ausgesetzt.

Von diesem Startpunkt aus lässt sich die Balance mit echten Nutzungsdaten justieren: Steigt das Volumen bei Routineaufgaben deutlich, wächst die lokale Kapazität mit; bleiben komplexe Aufgaben selten, bleibt die Cloud-Anbindung schlank. Der Fehler, den wir am häufigsten sehen, ist die vorschnelle Festlegung auf eine der beiden Extreme, bevor überhaupt reale Nutzungsdaten vorliegen.