Wie wir die KI-Kosten um 80 % gesenkt haben, indem wir Ollama auf Azure betrieben haben - eine Produktions-Story

Das Problem, das wir lösen wollten

Bei PANTA Flows entwickeln wir Tools zur Workflow-Automatisierung. Wie viele moderne AI-SaaS-Produkte haben auch wir begonnen, Möglichkeiten zu prüfen, KI in unser Produkt zu integrieren – insbesondere für Zusammenfassungen und kleinere Sprachaufgaben, die unseren Nutzer:innen helfen, schneller Entscheidungen zu treffen. Die naheliegende Wahl? OpenAI oder Claude.

Doch als wir die Zahlen durchgerechnet haben, sah das Kostenbild nicht besonders gut aus. Für unser erwartetes Volumen von rund 200 Anfragen pro Tag – nach jedem Maßstab eher moderat – hätten wir mit 300–500 € pro Monat für Modelle auf GPT-4-Niveau rechnen müssen. Und genau hier lag der Punkt: Wir brauchten kein GPT-4.

Wir brauchten ein Modell, das zuverlässig Dokumente zusammenfassen oder Kernaussagen extrahieren kann. Ein Modell mit rund 3 Milliarden Parametern wäre dafür völlig ausreichend.

Also stellten wir uns eine andere Frage:

„Was wäre, wenn wir das Modell einfach selbst betreiben?“

Warum ein selbst gehostetes LLM für uns sinnvoll war

Wir haben keinen Chatbot gebaut.

Wir brauchten keine komplexen Reasoning-Fähigkeiten.

Unsere konkreten Use Cases waren:

• Zusammenfassung von Workflow-Beschreibungen

• Erstellung von Szenen aus Skripten sowie Zusammenfassung von Dateien

• Kleine Klassifikationsaufgaben

Für solche Aufgaben ist ein quantisiertes, kleines Modell auf CPU-Basis nicht nur akzeptabel – es ist vollkommen ausreichend.

Die zentrale Erkenntnis war: Wir brauchten nicht die Intelligenz von GPT-4, sondern die Verfügbarkeit auf GPT-4-Niveau.

Self-Hosting brachte uns:

• Planbare Kosten – ein fixer VM-Preis pro Monat, keine Token-Abrechnung

• Datenschutz – keine Daten verlassen unsere Infrastruktur

• Geschwindigkeit – Antwortzeiten unter 2 Sekunden bei warmen Requests

• Kontrolle – wir besitzen und steuern den gesamten Stack

Die Wahl des richtigen Modells

Nach der Evaluierung verschiedener Optionen haben wir uns für Qwen 2.5 3B entschieden – ein quantisiertes Modell mit 1,9 GB (Q4_K_M).

Warum genau dieses Modell?

Architekturentscheidung: Einfach gewinnt

Bevor wir auf das technische Setup eingehen, möchte ich darüber sprechen, was wir bewusst entschieden haben, nicht zu bauen.

In einer frühen Planungsphase haben wir unter anderem folgende Optionen in Betracht gezogen:

• Docker-Container mit Auto-Scaling

• Azure Container Apps

• Message Queues (Azure Service Bus, Redis)

• API-Gateway-Wrapper

Wir haben all das verworfen. Der Grund:

Bei 200 Anfragen pro Tag entspricht das im Schnitt etwa einer Anfrage alle sieben Minuten. Kubernetes, Container-Orchestrierung oder Message-Queues einzuführen, würde Probleme lösen, die wir aktuell noch gar nicht haben. Allein der zusätzliche Engineering-Aufwand hätte den potenziellen Nutzen deutlich übertroffen.

Unsere finale Architektur ist daher bewusst schlicht gehalten - fast schon langweilig.

Keine Queues. Keine Container. Keine Orchestrierung. Nur eine VM, auf der ein Prozess läuft.

Infrastructure Setup

Die VM

Wir haben uns für eine Azure Standard_D2as_v4 entschieden –

mit 2 vCPUs, 8 GB RAM und Ubuntu 22.04 LTS als Betriebssystem.

Speicheraufteilung:

Knapp bemessen, aber für sequenzielle Inferenz bei geringem Traffic völlig ausreichend. Gesamtkosten: ca. 65,78 € pro Monat.

Bei der Festplatte haben wir die standardmäßige 30-GB-OS-Disk beibehalten, jedoch von Premium SSD auf Standard SSD gewechselt. Dadurch konnten wir zusätzlich etwa 7–10 € pro Monat sparen.

Da Ollama das Modell bei der ersten Anfrage vollständig in den Arbeitsspeicher lädt, spielt die Festplattengeschwindigkeit nur beim Kaltstart eine Rolle. Der Unterschied zwischen Premium- und Standard-SSD beträgt hier vielleicht rund drei Sekunden beim Start – den Aufpreis war uns das nicht wert.

VNet-Planung - der Teil, bei dem wir fast einen Fehler gemacht hätten

Genau hier lassen die meisten Anleitungen ein entscheidendes Detail aus.

Wir arbeiten mit drei Umgebungen: Dev, Stage und Prod.

Jede davon läuft als separater Azure App Service.

Unser erster Impuls war, einfach Port 11434 auf der VM zu öffnen und es dabei zu belassen.

Das wäre jedoch ein Sicherheitsdesaster gewesen, da Ollama standardmäßig keine Authentifizierung besitzt.

Jede Person mit der öffentlichen IP unserer VM hätte Inferenz-Requests ausführen und damit Compute-Kosten verursachen können.

Stattdessen haben wir eine saubere VNet-Subnetzstruktur entworfen:

Jeder App Service ist über VNet Integration mit seinem eigenen dedizierten Subnetz verbunden.

Alle Subnetze befinden sich im gleichen VNet, sodass sie privat miteinander kommunizieren können.

Ollama benötigt dadurch keinen öffentlich geöffneten Port.

Das Ergebnis: Port 11434 ist vollständig vom Internet abgeschirmt.

Nur unsere Backend-Services können darauf zugreifen – und zwar ausschließlich über eine private IP-Adresse.

Ollama deployen

Installation

Einfach. Das Installations-Script übernimmt alles – einschließlich der Einrichtung eines systemd-Services.

Konfiguration des Services

Die Standardinstallation von Ollama bindet sich an 127.0.0.1, also ausschließlich an localhost.

Da unsere App Services über das VNet darauf zugreifen müssen, muss Ollama auf allen Netzwerk-Interfaces lauschen.

Zusätzlich haben wir Queue- bzw. Concurrency-Einstellungen ergänzt, um parallele Requests sauber abzufangen und stabil zu verarbeiten.

Unsere finale Konfiguration unter /etc/systemd/system/ollama.service:

Aufschlüsselung der Umgebungsvariablen:

Variable	Wert	Grund
OLLAMA_HOST	0.0.0.0:11434	Akzeptiert Traffic aus dem VNet
OLLAMA_NUM_PARALLEL	1	Stabil für 2 vCPUs; verhindert CPU-Thrashing bei parallelen Requests
OLLAMA_MAX_QUEUE	5	Puffer für Traffic-Spitzen
OLLAMA_MAX_LOADED_MODELS	1	Hält das Modell dauerhaft im RAM („warm“) geladen

Warum wir keinen Azure Service Bus gebraucht haben

Das ist die Frage, die uns am häufigsten gestellt wird:

„Warum habt ihr keine richtige Queue verwendet?“

Ollama verfügt bereits über eine eingebaute Queue-Mechanik.

Für unser Traffic-Muster funktioniert das in etwa so:

Azure Service Bus kostet über 10 € pro Monat und bringt zusätzliche operative Komplexität mit sich. Die integrierte Queue von Ollama kostet 0 € und benötigt nur drei Zeilen Konfiguration. Die Rechnung ist also ziemlich eindeutig.

Anbindung des Backends

Backend-Integrationscode

Unsere Umgebungsstrategie ist klar und sauber aufgebaut:

Performance in der Produktion

Reale Kennzahlen aus unserem Deployment:

Für ein Startup, das KI-Workloads mit geringem Traffic betreibt, ist die Performance mehr als ausreichend.

Der größte Gewinn war jedoch die Kostenreduktion:

Für ein Early-Stage-Produkt ist das ein spürbarer Unterschied.

Wann wir darüber hinaus skalieren würden

Unser aktuelles Setup bewältigt rund 200 Anfragen pro Tag problemlos.

In folgenden Situationen würden wir über ein Scaling hinaus nachdenken:

Das Schöne an dieser Architektur ist, dass Skalierung schrittweise erfolgen kann.

Wir müssen nichts neu entwerfen – wir fügen einfach weitere Ebenen hinzu, wenn der Traffic steigt.

Wichtigste Erkenntnisse

1. Selbst gehostete LLMs sind für kleine bis mittlere Workloads absolut praktikabel – man sollte nicht automatisch davon ausgehen, dass man Managed-AI-Services benötigt.

2. Einfache Architektur schlägt „clevere“ Architektur – oft reichen eine VM und ein laufender Prozess völlig aus.

3. VNet-Integration ist das richtige Sicherheitsmodell – Ollama sollte niemals öffentlich erreichbar sein.

4. Die integrierte Queue von Ollama wird unterschätzt – für etwa 200 Requests pro Tag braucht man kein Redis.

5. Die Netzwerk-Topologie sollte zuerst geplant werden – Subnetz-Entscheidungen lassen sich später nur schwer ändern.

6. Cold-Starts lassen sich lösen – mit OLLAMA_MAX_LOADED_MODELS=1 bleibt das Modell im Speicher geladen.

Was als Nächstes geplant ist

• Azure-Monitor-Alerts für CPU- und Memory-Auslastung der VM einrichten

• Einen Keep-Warm-Cronjob implementieren, um Cold-Starts vollständig zu vermeiden

• Größere Modelle (z. B. 7B) evaluieren, sobald die VM skaliert wird

• Streaming-Responses ergänzen, um die wahrgenommene Antwortgeschwindigkeit zu verbessern

Wenn du ein ähnliches Setup aufbaust oder Fragen zu unserem Ansatz hast, kannst du dich gerne melden.