Zuerst die Begriffe: Cloud-LLM heißt, jede Anfrage geht per API an einen Anbieter — bezahlt wird pro Token, das Modell gehört jemand anderem. Lokal heißt, ein Open-Weight-Modell läuft auf eigener Hardware, betrieben mit Werkzeugen wie Ollama oder vLLM. Die Daten bleiben im Haus, die Kosten sind fix, und die Verantwortung für Betrieb und Qualität liegt vollständig beim eigenen Team. Beides sind legitime Architekturen. Problematisch wird es nur, wenn die Entscheidung aus Ideologie fällt statt aus einer Rechnung.
Wo lokale Modelle gewinnen
Drei Situationen sprechen klar für On-Premise. Erstens Datenschutz mit Nachweispflicht: Wenn Mandantendaten, Patientenakten oder Kundenverträge verarbeitet werden, ist „die Daten verlassen das Gebäude nicht" ein Argument, das jede Compliance-Diskussion abkürzt. Auftragsverarbeitung in der Cloud ist rechtlich machbar, aber erklärungsbedürftig — ein lokales Modell ist es nicht. Zweitens hohes, stabiles Volumen bei einfachen Aufgaben: Wer täglich zehntausende Dokumente klassifiziert, E-Mails vorsortiert oder Felder extrahiert, zahlt in der Cloud dauerhaft pro Aufruf für eine Aufgabe, die ein mittelgroßes lokales Modell gleichwertig löst. Ab einer bestimmten Menge schlägt die Fixkosten-Hardware jede Token-Rechnung. Drittens Latenz und Verfügbarkeit: Ein Modell im eigenen Netz antwortet ohne Internet-Umweg, ohne Rate-Limits und auch dann, wenn der Anbieter gerade Wartung hat.
Wo die Cloud vorn bleibt
Genauso klar sind die Fälle für die Cloud. Spitzenqualität: Bei komplexem Reasoning, mehrstufigen Analysen und heikler Kundenkommunikation liegen die großen Frontier-Modelle weiterhin deutlich vor allem, was auf einer einzelnen GPU läuft. Elastizität: Lastspitzen — die Marketingaktion, das Quartalsende — fängt die Cloud ab, ohne dass Hardware für den Spitzentag gekauft werden muss. Und Betriebsaufwand: Modell-Updates, Sicherheits-Patches, Treiber, Monitoring — in der Cloud ist das der Job des Anbieters, lokal ist es ein neuer Posten auf der eigenen Aufgabenliste. Wer kein Team hat, das diesen Posten trägt, kauft sich mit On-Premise keine Souveränität, sondern eine Baustelle.
Die Entscheidungsmatrix
- Aufgabenklasse: Klassifikation, Extraktion, Zusammenfassung, interne Suche — lokal gut machbar. Komplexes Reasoning und Außenkommunikation — Cloud.
- Volumen: Gelegentliche Nutzung spricht für die Cloud, dauerhaft hohes Volumen für eigene Hardware.
- Datenlage: Je sensibler die Daten und je strenger die Kundenverträge, desto stärker das On-Premise-Argument.
- Teamkapazität: Ohne jemanden, der GPU-Server betreiben kann und will, ist lokal keine Option — egal wie gut die Rechnung aussieht.
Die Frage ist nicht „Cloud oder lokal", sondern „welche Aufgabe wohin". Die meisten Systeme, die sich rechnen, sind hybrid: Massengeschäft lokal, Spitzenaufgaben in der Cloud — verbunden durch ein Routing, das pro Aufruf entscheidet.
Der hybride Mittelweg
In der Praxis setzt sich ein Muster durch: Ein lokales Modell übernimmt die häufigen, klar definierten Aufgaben und arbeitet als erster Filter. Nur was Unsicherheit zeigt oder erkennbar komplex ist, wird an ein Cloud-Modell eskaliert. Das senkt die API-Rechnung drastisch, hält sensible Routinedaten im Haus und nutzt die teuren Modelle dort, wo sie ihren Preis wert sind. Wie dieses Routing kostenmäßig gesteuert wird, beschreibt der Beitrag KI-Kosten senken: Token-Budgets und Model-Routing — und wer Firmenwissen anbinden will, findet die Grundlagen unter RAG: Firmenwissen für KI nutzbar machen.
Die ehrliche Kostenrechnung
Eine brauchbare GPU-Workstation für Modelle bis rund 30 Milliarden Parameter kostet einmalig einen niedrigen bis mittleren vierstelligen Betrag, dazu Strom und Abschreibung. Dagegen steht die monatliche API-Rechnung für dasselbe Volumen — plus ein Posten, den fast jede Vergleichsrechnung unterschlägt: Personalzeit. Einrichtung, Modell-Evaluierung, Updates und Störungsbeseitigung kosten Stunden, und Stunden kosten mehr als Tokens. Die Faustregel: Erst wenn die eingesparte API-Rechnung die Hardware in unter achtzehn Monaten amortisiert und jemand den Betrieb wirklich verantwortet, ist On-Premise eine Investition. Vorher ist es ein Hobby.
Der richtige Einstieg ist deshalb fast immer derselbe: mit Cloud-APIs starten, Volumen und Kosten pro Workflow messen, und erst dann die Aufgaben identifizieren, die sich lokal lohnen. Wer den Weg so herum geht, entscheidet mit Zahlen — und baut ein System, das beide Welten dort einsetzt, wo sie stark sind.