Technologie · Modelle & Tools
Lokale KI vs. Cloud: Wann sich eigene Modelle lohnen
Lokale KI vs. Cloud im Vergleich: Datenhoheit, Kosten bei Dauerlast, eine Beispielrechnung zur Amortisation und das Routing-Muster, das beide Welten kombiniert.
Von Boaz Lichtenstein
Die Frage „Cloud-KI oder eigene Modelle?“ wurde lange reflexhaft mit „Cloud, alles andere ist Bastelei“ beantwortet. Das stimmt so nicht mehr: Offene Modelle haben in zwei Jahren enorm aufgeholt, die Werkzeuge zum lokalen Betrieb sind alltagstauglich geworden, und die Hardware-Hürde sinkt. Zeit für eine nüchterne Abwägung.
Das Wichtigste in Kürze
- Offene Modelle haben stark aufgeholt – für viele Standardaufgaben reicht lokale KI heute völlig aus.
- Lokal punktet bei Datenhoheit, Kosten bei Dauerlast und Unabhängigkeit von Netz und Anbieter.
- Cloud bleibt bei komplexem Reasoning, Agenten-Aufgaben und Verlässlichkeit in Randfällen unerreicht.
- Ab einem bestimmten, planbaren Volumen schlägt gekaufte Hardware die API-Kosten oft schon nach wenigen Monaten.
- Das produktive Muster ist selten Entweder-oder, sondern Routing: einfache Aufgaben lokal, komplexe in die Cloud.
Was für lokal spricht
- Datenhoheit: Verträge, Patientendaten, Quellcode, Personalunterlagen – es gibt Daten, die das Haus nicht verlassen sollen oder dürfen. Lokale Inferenz macht die Datenschutz-Diskussion strukturell einfacher: kein Auftragsverarbeiter, kein Drittland, keine Frage, was mit den Prompts passiert. Für eine Kanzlei oder Arztpraxis ist das oft nicht nur bequemer, sondern der einzige praktikable Weg, KI überhaupt einzusetzen.
- Kosten bei Dauerlast: API-Preise sind pro Aufruf günstig, aber bei hohem, gleichmäßigem Volumen – Klassifizierung, Extraktion, Embeddings über Millionen Dokumente – schlägt gekaufte Hardware die Cloud oft nach Monaten (die Beispielrechnung weiter unten zeigt die Größenordnung).
- Latenz und Verfügbarkeit: Keine Netzabhängigkeit, keine Rate-Limits, keine Abkündigung des Lieblingsmodells über Nacht. Für Einsätze ohne verlässliches Netz – im Feld, auf Messen, in abgeschotteten Umgebungen – ist das oft das entscheidende Argument, nicht die Kosten.
Alle drei Argumente wiegen unterschiedlich schwer, je nach Branche: Für ein Softwareunternehmen ohne besonders sensible Daten ist Kosten bei Dauerlast meist der einzig relevante Punkt. Für eine Kanzlei, eine Arztpraxis oder ein Unternehmen mit strengen Geheimhaltungspflichten ist Datenhoheit dagegen nicht verhandelbar – selbst wenn die Cloud-Variante am Ende günstiger wäre, kommt sie für bestimmte Daten schlicht nicht infrage.
Was für die Cloud spricht
Die Spitzenmodelle der großen Anbieter bleiben lokal unerreicht – bei komplexem Reasoning, Code, langen Agenten-Aufgaben und Verlässlichkeit in Randfällen liegen Welten dazwischen. Dazu kommt: null Infrastruktur-Aufwand, sofortige Skalierung, immer das neueste Modell. Wer Kundenerlebnisse baut, bei denen Qualität direkt Umsatz ist, spart am falschen Ende, wenn er ein schwächeres Modell selbst hostet.
Ein Beispiel macht den Unterschied greifbar: Ein Kundenservice-Chat, der komplexe Reklamationen eigenständig bearbeitet, mehrere Systeme abfragt und am Ende eine Entscheidung formuliert, braucht genau die Fähigkeiten, in denen Spitzenmodelle vorn liegen – mehrstufiges Schlussfolgern, verlässliches Werkzeug-Handling, robustes Verhalten in ungewöhnlichen Fällen. Ein lokales Modell mag achtzig Prozent dieser Fälle ordentlich lösen, aber die verbleibenden zwanzig Prozent sind meist genau die, die am meisten Frustration und damit am meisten Umsatzschaden verursachen, wenn sie schiefgehen.
Aus der Praxis: Wer unsicher ist, wo die eigene Aufgabe liegt, testet beide Wege parallel an zwanzig bis dreißig realen Beispielen, bevor er sich festlegt – der Qualitätsunterschied zwischen einem guten lokalen und einem Spitzenmodell zeigt sich an echten Fällen schneller und ehrlicher als an jeder Beschreibung von außen.
Beispielrechnung: Wann sich eigene Hardware rechnet
Angenommen, ein Unternehmen verarbeitet dauerhaft ein hohes, gleichmäßiges Volumen – etwa Klassifikation und Embeddings für einen großen Produktkatalog. Über eine Cloud-API kann das bei entsprechendem Volumen schnell in den Bereich von 500 bis 1.500 Euro im Monat laufen. Ein dedizierter Server mit ausreichend Grafikspeicher kostet einmalig grob 6.000 bis 10.000 Euro, dazu laufend 150 bis 250 Euro für Strom und Wartung. Die Amortisation liegt bei diesem Beispiel-Volumen typischerweise im Bereich von sechs bis zwölf Monaten – danach läuft die Verarbeitung nahezu ohne laufende Zusatzkosten weiter. Bei niedrigerem oder unregelmäßigem Volumen dreht sich diese Rechnung schnell um: Dann bleibt die Cloud günstiger, weil die Hardware sonst ungenutzt Kapital bindet. Details zur Kostenmechanik selbst stehen in unserem Artikel zu KI-Kosten verstehen.
Lokale KI im Vergleich: Welche Hardware für welchen Bedarf
| Einsatzszenario | Typische Hardware | Modellgröße | Aufwand |
|---|---|---|---|
| Einzelperson, gelegentlich | Aktuelles Notebook mit viel RAM | Kompakt | Niedrig |
| Team, regelmäßige Nutzung | Mac mit Unified Memory oder Consumer-GPU | Mittel | Mittel |
| Unternehmen, Dauerlast | Dedizierter Server mit GPU | Mittel bis groß | Hoch bei Einrichtung, niedrig im Betrieb |
| Hochsensible Einzelfälle | Vom Netz getrennter Server | Je nach Aufgabe | Sehr hoch |
Faustregel: Je höher Volumen und Sensibilität, desto eher rechnet sich der Sprung von der Einzelplatz-Lösung zum dedizierten Server – für gelegentliche Nutzung bleibt das eigene Notebook meist die pragmatischste Wahl.
Das Muster in der Praxis: Routing
Die interessante Architektur ist nicht entweder–oder, sondern beides: Ein Router schickt einfache, hochvolumige oder sensible Aufgaben ans lokale Modell und eskaliert komplexe Fälle an die Cloud – mit anonymisierten oder pseudonymisierten Daten, wo nötig. So landen achtzig Prozent der Token dort, wo sie fast nichts kosten, und die zwanzig Prozent, die Intelligenz brauchen, dort, wo sie verfügbar ist.
Ein solches Setup entsteht in vier Schritten: Aufgaben nach Sensibilität und Komplexität einordnen; eine klare Regel festlegen, was lokal bleibt und was eskaliert; für eskalierte Fälle Anonymisierung oder Pseudonymisierung einrichten, wo die Daten es erfordern; und Kosten sowie Qualität laufend messen, um die Schwelle bei Bedarf nachzujustieren.
Welches lokale Modell dabei zum Einsatz kommt, ist eine eigene Entscheidung – die meisten produktiv nutzbaren lokalen Modelle sind offene Modelle mit frei herunterladbaren Gewichten, nicht Eigenentwicklungen. Wer das Routing-Muster aufbaut, sollte deshalb auch die Lizenzbedingungen des gewählten Modells prüfen – „lokal betreibbar“ und „für den geplanten Zweck lizenziert“ sind zwei getrennte Fragen, die beide vor dem Produktiveinsatz geklärt sein sollten.
Die häufigsten Fehler bei der Entscheidung
Alles auf Cloud setzen, weil es einfacher wirkt: Ohne Kostenblick auf das tatsächliche Volumen wird eine langfristig teurere Lösung zum Standard. Korrektur: Volumen und Wiederkehr der Aufgabe vor der Tool-Wahl kalkulieren.
Lokal aus Prinzip erzwingen: Auch komplexe, qualitätskritische Aufgaben werden auf ein lokales Modell gepresst, das dafür nicht ausreicht. Korrektur: Qualitätsanspruch der Aufgabe ehrlich einschätzen, bevor die Infrastruktur feststeht.
Hardware ohne Volumen-Kalkulation kaufen: Ein Server wird angeschafft, ohne die Beispielrechnung überhaupt zu machen. Korrektur: Amortisationsrechnung vor der Investition, nicht danach.
Kein Routing, sondern Insellösungen: Jede Abteilung entscheidet für sich, ob lokal oder Cloud – am Ende doppelte Infrastruktur ohne gemeinsame Regel. Korrektur: eine zentrale Routing-Regel für das ganze Unternehmen.
Sicherheitsversprechen von „lokal“ überschätzen: Ein eigener Server gilt automatisch als sicher, ohne dass Zugriffsschutz geprüft wurde. Korrektur: Lokale Inferenz ist ein Baustein der Datensicherheit, kein Ersatz für grundlegende IT-Absicherung.
Unterm Strich
Die Entscheidung ist damit keine Glaubensfrage, sondern eine Portfolio-Frage: Welche Aufgabe, welche Daten, welches Volumen – und daraus folgt der Ort. Wann lokal: hohes, planbares Volumen, sensible Daten, Netzunabhängigkeit gefragt. Wann Cloud: komplexe Einzelfälle, geringes oder unregelmäßiges Volumen, Qualität ist geschäftskritisch. Wer beide Kriterien ehrlich durchgeht, statt sich für ein Lager zu entscheiden, baut am Ende die günstigere und robustere Lösung – meist eine Kombination aus beidem. Der pragmatischste erste Schritt ist selten der große Infrastrukturkauf, sondern ein kleiner Test: eine Aufgabe, ein lokales Modell, ein Vergleich gegen die Cloud-Variante an echten Fällen. Was sich dabei zeigt, entscheidet zuverlässiger als jede Grundsatzdebatte.