Was kostet die Open-WebUI-Bereitstellung? Kostenvergleich zwischen lokalem Ollama und Cloud-KI-API

Die Preisübersicht eines API-Anbieters weist Eingabe- und Ausgabetokens als getrennte Abrechnungskategorien aus (offizielle Preisübersicht). Für die Open-WebUI-Bereitstellungskosten heißt das: Nicht die Chat-Oberfläche allein entscheidet über das Budget, sondern vor allem die Inferenz, die Auslastung der bereitgestellten Maschinen und der laufende Betrieb. Bei geringer oder unklarer Nutzung sollten Teams zuerst die Cloud-KI-API kalkulieren; bei stetiger Auslastung und vorhandener Betriebskompetenz lohnt sich der Vergleich mit lokalem Ollama. Eine hybride Verbindung kann sensible oder stark schwankende Arbeitslasten besser abbilden als eine pauschale Entweder-oder-Entscheidung.

Dieser Beitrag richtet sich an Entwickler und Plattformingenieure, die Open WebUI für ein Team bereitstellen möchten.
Er unterstützt technische Verantwortliche beim Vergleich lokaler Modelle und Cloud-KI-APIs.
Auch IT-Verantwortliche, die Gesamtkosten und Betriebsaufwand planen, finden hier ein ausfüllbares Schätzmodell.

Welche Kosten entstehen neben der Oberfläche?

Open WebUI ist eine Anwendung zur Bereitstellung einer Chat-Oberfläche und zur Verbindung mit Modellanbietern. Die offizielle Bereitstellungsdokumentation beschreibt unterschiedliche Deployment- und Betriebswege; sie macht daraus jedoch nicht automatisch einen vollständigen KI-Dienst. Für die Budgetplanung sollte deshalb zwischen Anwendungsschicht, Inferenzschicht und Betriebsschicht unterschieden werden.

Anwendungsschicht: Hierzu gehören die Ausführungsumgebung für Open WebUI, Speicher für Konfiguration und persistente Daten, Netzwerkzugriff sowie die Absicherung der Benutzerkonten. Die konkrete Ressourcengröße hängt unter anderem von gleichzeitigen Sitzungen, gespeicherten Unterhaltungen und dem gewählten Deployment ab. Eine kleine interne Oberfläche und ein breit genutzter Teamdienst sind nicht ohne Prüfung als gleichwertige Installationen anzusetzen.

Inferenzschicht: Das Modell kann über einen lokalen Ollama-Dienst oder über einen unterstützten Cloud-Anbieter angebunden werden. Lokal entstehen vor allem Kosten für geeignete Hardware, deren Auslastung, Strom und Speicher. Bei einem API-Modell richten sich die variablen Ausgaben dagegen nach Anbieter, Modell, Abrechnungsregeln und tatsächlichem Aufrufvolumen. Open WebUI vermittelt zwischen Oberfläche und Anbieter; die Modellrechnung verschwindet dadurch nicht.

Betriebsschicht: Dazu zählen Wartung, Aktualisierungen, Überwachung, Sicherungen, Fehlerbehebung und die Zeit der zuständigen Administratoren. Die Wartungshinweise von Open WebUI machen deutlich, dass ein produktiver Dienst nicht mit der einmaligen Installation erledigt ist. Wiederherstellbarkeit und Aktualisierungsprozesse müssen in die Planung einfließen, nicht erst nach einem Ausfall.

Damit wird auch klar, welche scheinbar „kostenlose“ Variante teuer werden kann: Eine bereits vorhandene Maschine mag keine neue Anschaffung erfordern, bindet aber weiterhin Strom, Speicherplatz und Arbeitszeit. Umgekehrt lässt sich ein API-Aufruf schnell starten, doch fehlende Nutzungsgrenzen oder ein ungeeignetes Modell können die laufenden Ausgaben unvorhersehbar machen.

Für einen belastbaren Vergleich sollte jede Ausgabe einer Schicht zugeordnet werden. Andernfalls werden API-Kosten mit Hardwarekosten verglichen, während Einrichtung, Absicherung und Bereitschaftsdienst auf einer Seite unberücksichtigt bleiben.

Lokales Ollama und Cloud-KI-API im Kostenvergleich

Die folgende Tabelle bewertet die Modelle relativ nach typischen Kosteneigenschaften. Sie enthält bewusst keine Preise: Diese ändern sich je nach Hardware, Anbieter, Modell, Standort und Vertragsbedingungen. Die Bewertungen sind eine Entscheidungshilfe, keine Garantie für einen konkreten Betrieb.

Kriterium	Lokales Ollama	Cloud-KI-API	Hybrider Betrieb
Kostenverlauf	Eher fixe Ressourcen- und Wartungskosten	Eher nutzungsabhängige Ausgaben	Fixe Basis plus variable Nutzung
Risiko bei geringer Auslastung	Hoch: bereitgestellte Hardware kann ungenutzt bleiben	Niedriger, sofern keine Mindestabnahme gilt	Mittel: hängt von der Größe der lokalen Basis ab
Aufwand für Infrastruktur	Hardware, Updates, Monitoring und Sicherungen selbst organisieren	Weniger Modellinfrastruktur selbst betreiben; Anwendung und Zugriff bleiben eigene Aufgaben	Zusätzliche Konfiguration und Zuständigkeiten für beide Wege
Anpassung an Lastspitzen	Durch lokale Kapazität begrenzt	Häufig einfacher über Nutzung zu skalieren; Limits des Anbieters prüfen	Geeignet, wenn Lasten sinnvoll aufgeteilt werden
Datenkontrolle	Lokale Verarbeitung kann die Kontrolle erleichtern; Zugriffs- und Sicherungskonzept bleibt erforderlich	Verarbeitung und Aufbewahrung hängen von den Anbieterbedingungen ab	Datenklassen müssen klar einem Pfad zugeordnet werden
Passender Einsatz	Regelmäßige Nutzung mit passender Hardware und Betriebskompetenz	Test, geringe Nutzung oder variable Nachfrage	Sensible Daten und wechselnde oder unterschiedliche Arbeitslasten
Bewertung für geringe Nutzung	Schwach	Stark	Mittel
Bewertung bei stabiler Last	Stark, wenn die Kapazität ausgelastet ist	Mittel bis stark, abhängig von Modellpreis und Nutzung	Stark, wenn Routing und Betrieb beherrschbar sind

Ollama lässt sich laut der Anleitung zum Verbinden mit Ollama als Modellquelle einrichten. Die Übersicht der unterstützten Anbieter-Verbindungen erläutert außerdem, dass sich Anbieter über die dafür vorgesehenen Verbindungswege einbinden lassen. Die verfügbaren Funktionen und Protokolle sollten vor einer produktiven Einrichtung anhand der jeweils aktuellen Dokumentation geprüft werden.

Die Tabelle zeigt vor allem, warum „lokal kostet nichts“ keine brauchbare Vergleichsannahme ist. Wurde die Maschine bereits angeschafft, ist ihr Kaufpreis zwar möglicherweise keine neue Ausgabe des Projekts. Für eine wirtschaftliche Bewertung zählen aber auch gebundene Kapazität, Energie, Ersatzplanung und die Frage, ob dieselbe Hardware für andere Aufgaben benötigt wird. Wird eigens ein Gerät beschafft oder eine Rechenumgebung gemietet, gehören die entsprechenden laufenden oder anteiligen Kosten in die Rechnung.

Bei der Cloud-Variante ist die Grundfrage eine andere: Wie viel wird tatsächlich abgerufen, und zu welchen Konditionen? Ein Preismodell kann Eingabe und Ausgabe unterschiedlich behandeln; auch Modellwahl und zusätzliche Funktionen können das Ergebnis verändern. Deshalb muss die Kalkulation auf der aktuellen Preisseite des konkret vorgesehenen Anbieters beruhen. Die Preisübersicht für API-Nutzung ist ein Beispiel für eine offizielle Quelle, die vor dem Eintragen von Beträgen auf Modell, Einheit und Abrechnungsbedingungen geprüft werden muss. Ein dort gefundener Preis darf nicht als allgemeingültiger Tarif für andere Anbieter oder Modelle übernommen werden.

Ab welcher Nutzung lohnt sich lokale Inferenz?

Eine allgemeine Schwelle, ab der lokale Inferenz günstiger wird, lässt sich ohne konkrete Nutzungsdaten nicht seriös angeben. Entscheidend ist nicht allein die Zahl der registrierten Benutzer, sondern wie häufig sie tatsächlich Anfragen stellen, wie lang Eingaben und Antworten sind, welches Modell verwendet wird und wie stark die lokale Ressource ausgelastet ist.

Für den Vergleich kann ein monatliches Modell mit Variablen verwendet werden:

Monatskosten lokal
= Hardwarekosten oder anteilige Gerätekosten
+ Strom
+ Speicher und Sicherungen
+ Netzwerk- und Infrastrukturkosten
+ Wartungszeit
+ Kosten für Ausfälle oder Bereitschaft

Monatskosten Cloud
= Summe der tatsächlich abgerechneten Modellaufrufe
+ gegebenenfalls zusätzliche Anbieterleistungen
+ Open-WebUI-Infrastruktur
+ Wartungszeit für Zugriff, Konten und Konfiguration

Monatskosten hybrid
= lokale Grundkosten
+ Cloud-Aufrufe für die zugewiesenen Arbeitslasten
+ zusätzlicher Aufwand für Routing, Überwachung und Datenschutzregeln

Für die API-Kalkulation sollten Eingabe- und Ausgabemengen getrennt erfasst werden. Eine kurze Frage mit ausführlicher Antwort kann anders zu Buche schlagen als ein langer Kontext mit knapper Ausgabe. Dazu kommen wiederholte Anfragen, Tests während der Entwicklung und Spitzenlasten. Statt die Benutzerzahl direkt mit einem geschätzten Betrag zu multiplizieren, ist es zuverlässiger, tatsächliche Abrechnungsdaten oder einen repräsentativen Nutzungszeitraum heranzuziehen und die Annahmen offenzulegen.

Bei lokaler Nutzung entscheidet die Auslastung über die Wirtschaftlichkeit mit. Ein Gerät, das dauerhaft bereitsteht und nur selten Anfragen beantwortet, verursacht Fixkosten ohne entsprechende Nutzung. Bei regelmäßigen Arbeitslasten kann sich das Verhältnis verschieben, sofern die vorhandene Kapazität genügt und kein zusätzlicher Betriebsposten übersehen wurde. Ist die Inferenz langsam oder müssen Anfragen wegen fehlender Kapazität aufgeschoben werden, kann eine vermeintliche Einsparung außerdem zu einem betrieblichen Nachteil werden.

Ein fairer Vergleich setzt daher dieselbe Leistungsklasse und denselben Zeitraum an. Vergleichen Sie nicht eine leistungsfähige API mit einem lokalen Modell, das eine andere Antwortqualität oder ein anderes Nutzungserlebnis bietet, ohne diesen Unterschied sichtbar zu machen. Ebenso wenig sollte ein voller Monat lokaler Bereitstellung gegen eine kurze API-Testphase gestellt werden. Dokumentieren Sie Modell, Nutzungsannahmen, Abrechnungszeitraum und den Umgang mit Lastspitzen.

Open WebUI mit lokalen und Cloud-Modellen verbinden

Ein Mischbetrieb ist möglich, wenn die lokale und die cloudbasierte Modellquelle passend angebunden und für die Nutzer verständlich getrennt werden. Open WebUI dokumentiert Verbindungen zu lokalen Modellen und externen Anbietern; die konkrete Konfiguration hängt von der bereitgestellten Version, den unterstützten Verbindungswegen und den Eigenschaften des jeweiligen Anbieters ab. Das sollte anhand der Anbieter-Dokumentation von Open WebUI geprüft werden, bevor verbindliche Aussagen zur verfügbaren Funktion getroffen werden.

Die wirtschaftliche Stärke eines hybriden Ansatzes liegt nicht darin, automatisch den günstigsten Weg für jede Anfrage zu finden. Sie entsteht, wenn es eine klare Zuordnung gibt: etwa lokale Verarbeitung für Aufgaben, die mit einem lokal verfügbaren Modell und der vorhandenen Hardware ausreichend erledigt werden, und eine Cloud-KI-API für Fälle, in denen ein anderes Modell oder kurzfristige zusätzliche Kapazität benötigt wird. Ohne Nutzungsregeln drohen hingegen doppelte Betriebsarbeit, unklare Verantwortlichkeiten und schwer erklärbare Rechnungen.

Für sensible Daten reicht die Auswahl eines lokalen Modells nicht als Datenschutzkonzept. Auch Zugriffsschutz, Protokollierung, Backups, Administratorrechte und die Behandlung von Konversationsdaten müssen geregelt sein. Bei einer externen API sind zusätzlich die Bedingungen des Anbieters und die eigene Datenklassifizierung zu prüfen. Die interne Datenschutzinformation kann als ergänzender Einstieg für Datenschutzfragen dienen; die Prüfung der konkreten Verarbeitung muss sich dennoch auf die tatsächlichen Dienste und Vereinbarungen beziehen.

Bei wechselnden Arbeitslasten ist eine dokumentierte Zuordnung pro Datenklasse und Anwendungsfall hilfreicher als eine pauschale Regel „lokal zuerst“. So lässt sich später nachvollziehen, weshalb eine Anfrage einen bestimmten Inferenzpfad verwendet hat.

Monatskosten mit eigenen Messwerten ermitteln

Die Schätzung sollte mit tatsächlich beobachteten Werten beginnen. Für die Cloud-Seite sind Anbieterabrechnung, Modell und Abrechnungseinheit maßgeblich. Für die lokale Seite braucht es Angaben zu den eingesetzten Ressourcen und zur Arbeitszeit. Wenn noch keine Nutzungsdaten vorhanden sind, sollte die erste Kalkulation ausdrücklich als Szenario und nicht als Prognose bezeichnet werden.

Tragen Sie folgende Größen in ein eigenes Arbeitsblatt ein:

Nutzerkreis: Zahl der vorgesehenen Konten sowie Gruppen mit unterschiedlichen Berechtigungen und Nutzungszwecken.
Nutzungsfrequenz: Anfragen je Nutzer und Zeitraum, getrennt nach normaler Nutzung, Testbetrieb und Spitzen.
Modellwahl: Das lokal vorgesehene Ollama-Modell und die konkrete Cloud-Alternative; Unterschiede in Qualität und Antwortverhalten gesondert notieren.
Ein- und Ausgabe: Gemessene oder anhand eines repräsentativen Tests geschätzte Eingabe- und Ausgabemengen.
Infrastruktur: Bestehendes Gerät, eigens beschaffte Hardware oder gemietete Umgebung; Kosten und Abrechnungszeitraum getrennt erfassen.
Auslastung: Anteil der bereitgestellten Ressourcen, der tatsächlich für die Inferenz verfügbar und genutzt ist.
Betriebszeit: Aufwand für Einrichtung, Aktualisierung, Kontrolle, Sicherung, Berechtigungen und Störungsbehebung.
Datenregeln: Welche Anfragen lokal bleiben müssen und welche an externe Anbieter übermittelt werden dürfen.
Annahmen: Zeitraum, zugrunde gelegte Preise, erwartete Last und Vorgehen bei Spitzen oder Ausfällen.

Prüfliste für eine belastbare Schätzung

[ ] Die Kosten für Open WebUI, Modellinferenz und laufenden Betrieb sind getrennt erfasst.
[ ] Für die Cloud-KI-API sind Modell, Eingabe- und Ausgabeeinheit sowie Preisquelle festgehalten.
[ ] Die gewählte offizielle Preisseite wurde am Tag der Kalkulation geprüft; der verwendete Tarif ist mit Anbieter und Modell dokumentiert.
[ ] Die Cloud-Schätzung basiert auf realen Abrechnungsdaten oder einem gekennzeichneten Nutzungsszenario.
[ ] Strom, Speicher, Sicherungen und anteilige Hardwarekosten sind bei lokaler Inferenz berücksichtigt.
[ ] Wartungs- und Bereitschaftsaufwand ist als Arbeitszeit eingetragen und nicht als kostenlos angenommen.
[ ] Lastspitzen und Mehrmodellbetrieb sind im Szenario berücksichtigt.
[ ] Für lokale und externe Verarbeitung sind Zugriffsrechte, Datenregeln und Zuständigkeiten dokumentiert.
[ ] Das Ergebnis nennt den betrachteten Zeitraum und alle Annahmen, statt einen allgemeingültigen Break-even-Wert vorzugeben.

Ein Schätzblatt sollte außerdem Szenarien nebeneinanderstellen: eine zurückhaltende Nutzung, den erwarteten Normalbetrieb und eine erhöhte Nachfrage. Das sind keine Vorhersagen, sondern Prüfvarianten, die sichtbar machen, welche Annahme das Ergebnis am stärksten beeinflusst. Wenn schon kleine Änderungen an Nutzeraktivität oder Modellwahl die Entscheidung umkehren, empfiehlt sich zunächst eine begrenzte Erprobung mit nachvollziehbarer Erfassung der Nutzung.

Entscheidung nach Auslastung, Datenschutz und Betriebsfähigkeit

Bei gelegentlichen Tests oder unsicherer Nachfrage spricht meist mehr dafür, zuerst die Cloud-KI-API mit klaren Nutzungsgrenzen zu kalkulieren. So wird die Entscheidung nicht durch eine eigens bereitgestellte, möglicherweise ungenutzte Inferenzmaschine vorweggenommen. Voraussetzung ist, dass die Datenrichtlinien den externen Anbieter zulassen und dass die variablen Ausgaben überwacht werden.

Bei stetiger Nutzung kann lokales Ollama in die engere Auswahl kommen, wenn passende Hardware verfügbar ist, die tatsächliche Auslastung ausreichend hoch ist und das Team Wartung sowie Störungen übernehmen kann. In die Rechnung gehören dann nicht nur Anschaffung oder Miete, sondern auch Speicher, Energie, Sicherung, Überwachung und Arbeitszeit. Fehlt internes Betriebswissen, kann die zusätzliche Betreuung den vermeintlichen Kostenvorteil aufzehren.

Bei vertraulichen Daten und zugleich schwankender Nachfrage kann ein hybrider Ansatz sinnvoll sein. Er setzt klare Regeln dafür voraus, welche Aufgaben lokal verarbeitet werden und wann eine Cloud-Verbindung zulässig ist. Auch muss feststehen, wer Berechtigungen, Anbieterzugänge und Kostenlimits verwaltet. Ein Mischbetrieb sollte nur gewählt werden, wenn diese zusätzliche Komplexität einen konkreten Nutzen für Datenschutz, Kapazität oder Verfügbarkeit bringt.

Die Entscheidung lässt sich auf drei Bedingungen herunterbrechen: Ist die Nutzung niedrig oder noch unbekannt, beginnen Sie mit einer begrenzten Cloud-Kalkulation. Ist die Nutzung stabil, die lokale Ressource passend und die Wartung personell abgedeckt, vergleichen Sie die realen lokalen Gesamtkosten mit den API-Abrechnungen. Müssen Datenklassen unterschiedlich behandelt werden oder schwankt die Last stark, prüfen Sie eine hybride Zuordnung und messen Sie die Kosten pro Pfad getrennt.

Wenn zusätzliche Kapazität nur zeitweise gebraucht wird

Eine vorhandene lokale Installation und eine Cloud-KI-API sind nicht die einzigen Möglichkeiten, Ressourcen für Tests oder zeitlich begrenzte Vorhaben bereitzustellen. Eine gemietete Mac-Umgebung kann für passende Entwicklungs- und Testaufgaben interessant sein, sofern die konkret angebotene Konfiguration die Anforderungen des gewählten Modells erfüllt. Sie ersetzt nicht automatisch eine API: Hardwareverfügbarkeit, Arbeitsspeicher, Modellkompatibilität und Betriebsaufwand müssen vorab geprüft werden.

Gegenüber einer API-Nutzung bringt eine solche Umgebung auch Nachteile mit sich: laufende Mietkosten unabhängig von jeder einzelnen Modellanfrage, eigener Einrichtungs- und Wartungsaufwand sowie eine an die verfügbare Hardware gebundene Kapazität. Gegenüber eigener Hardware entfällt dafür eine langfristige Anschaffung, und eine Testumgebung kann zeitlich begrenzt geplant werden. Für dauerhaft hohe Last oder Anforderungen an physische Schnittstellen kann ein eigenes Gerät geeigneter sein; für seltene Anfragen bleibt eine nutzungsabhängige API häufig die einfachere Vergleichsbasis.

Wenn die ausgefüllte Kostenübersicht einen zeitlich begrenzten Bedarf an Mac-Ressourcen zeigt, können Sie die verfügbaren Angaben zur Mac-Miete bei Zilmac mit Ihrem Modell- und Speicherbedarf abgleichen. Prüfen Sie die dort ausgewiesene Konfiguration und Mietbedingungen gegen Ihren konkreten Anwendungsfall, bevor Sie die Umgebung als Inferenzlösung einplanen.