Die Cost-First KI-Architektur: On-Premise als Standard, Cloud-Kosten nur bei Spitzenlast

Die meisten Teams behandeln KI-Infrastruktur als Entweder-oder-Entscheidung. Entweder in der Cloud betreiben und eine Rechnung akzeptieren, die mit jeder Anfrage wächst – oder auf eigener Hardware betreiben und eine harte Kapazitätsgrenze akzeptieren. Beide Sichtweisen lassen Geld auf dem Tisch liegen. Es gibt eine dritte Option, die die Wirtschaftlichkeit eigener Hardware für alltägliche Lasten nutzt und gleichzeitig die Elastizität der Cloud für die Momente bereitstellt, in denen sie tatsächlich benötigt wird – und KeepUrAi ist genau für diese Betriebsweise ausgelegt.

Dieser Leitfaden zeigt, wie Sie die Plattform so bereitstellen, dass die günstige Ressource die Hauptlast trägt und die teure Ressource nur dann abgerechnet wird, wenn die Nachfrage steigt.

Der wirtschaftliche Grundgedanke

Die Kosten für den Betrieb von KI werden von einem einzigen Faktor dominiert: GPU-Inferenz. Alles andere – die Web-Schicht, die API-Schicht, die Datenbank – ist günstig und selten der Engpass. Damit reduziert sich die gesamte Kostenfrage auf wo die GPU-Arbeit stattfindet.

Zwei Tatsachen machen die Entscheidung einfach:

On-Premise-GPUs haben nahezu null Grenzkosten. Sobald die Hardware bezahlt ist, ist jede zusätzliche Anfrage im Wesentlichen kostenlos. Strom ist die einzige Variable.
Serverlose Cloud-Inferenz hat nahezu null Leerlaufkosten. Anbieter wie Ollamas Cloud und Comfys Cloud-API rechnen pro Token oder pro Job ab. Wenn Sie nichts senden, zahlen Sie nichts.

Beides zusammen ergibt sich die optimale Strategie von selbst: Eigene Hardware absorbiert die Grundlast zu nahezu null Grenzkosten, und nur der Überlauf wird bei Pay-per-use-Cloud-Inferenz während Spitzenzeiten abgerechnet. Sie bezahlen nie für eine wartende Cloud-GPU, und Sie stellen Nutzer nie für Stunden in die Warteschlange, wenn die eigene GPU ausgelastet ist.

Die Architektur im Überblick

                    ┌─────────────────────────────────────────┐
                    │            ON-PREMISE (Grundlast)        │
   Nutzer  ────────▶│  Web + API + Gateway                     │
                    │  PostgreSQL + Vector Store (alle Daten)  │
                    │  Lokale GPU: Ollama + ComfyUI            │
                    └───────┬───────────────────────┬─────────┘
                            │                        │
        Überlauf nur bei   │                        │  nur Premium-Arbeit
        GPU-Auslastung     ▼                        ▼  (bewusste Eskalation)
        ┌───────────────────────────┐   ┌───────────────────────────────┐
        │  CLOUD (elastisch,        │   │  CLAUDE CODE (Frontier-Agent) │
        │  Pay-per-use)             │   │  Verbindet via MCP, keine GPU  │
        │  Ollama Cloud-Inferenz    │   │  Nutzt On-Premise-Wissen      │
        │  ComfyUI Cloud-Generierung│   │                               │
        └───────────────────────────┘   └───────────────────────────────┘

Die Anwendung bleibt vollständig On-Premise. Ihre Dokumente, Ihre Konversationen, Ihre Nutzerdaten – nichts davon wird verlagert. Die einzigen Dinge, die nach aussen übertragen werden, sind ein einzelner Inferenz-Aufruf (wenn Ihre lokale GPU beschäftigt ist) und der spezifische Kontext, den eine Premium-Aufgabe benötigt (wenn Sie sie bewusst eskalieren).

Schritt 1: Den vollständigen Stack On-Premise bereitstellen

KeepUrAi wird als vollständiger, eigenständiger Stack ausgeliefert und unterstützt drei Bereitstellungsmethoden – wählen Sie diejenige, die zu Ihrer Umgebung passt:

Debian / RPM-Pakete mit systemd, für eine traditionelle On-Premise-Server-Installation
Docker Compose, für eine containerisierte Einzelhost-Bereitstellung
Kubernetes (Helm), für eine geclusterte Bereitstellung, die Sie selbst verwalten

Alle drei installieren dieselben Komponenten: das Backend-API, das Web-Frontend, das Mobile-Gateway, PostgreSQL mit dem Vector Store und die lokalen KI-Dienste. Dies ist Ihre Grundlast-Schicht, und für die meisten Organisationen wird sie den Grossteil des täglichen Datenverkehrs auf Hardware verarbeiten, die Sie bereits kontrollieren.

Schritt 2: Ihre Daten behalten, wo sie sind

Die Datenschicht ist ein bescheidener, GPU-freier Rechner: PostgreSQL mit der pgvector-Erweiterung, der sowohl Ihre relationalen Daten als auch Ihre Retrieval-Augmented-Generation (RAG)-Einbettungen enthält. Er läuft komfortabel auf Standard-Hardware mit einer NVMe-Festplatte und einer angemessenen Menge RAM.

Entscheidend ist, dass diese Schicht für das Funktionieren der Architektur nie verschoben oder repliziert werden muss. Da nur Inferenz-Aufrufe in die Cloud überlaufen – keine Daten –, behalten Sie eine einzige On-Premise-Datenbank. Das eliminiert den teuersten und fehleranfälligsten Teil der meisten Hybrid-Designs: standortübergreifende Datenbanksynchronisation.

Schritt 3: Die Cloud als Überlaufziel konfigurieren

Die Plattform kennt bereits zwei Betriebsprofile – lokal (Ihre eigene GPU) und cloud (externe Inferenz-Endpunkte) – und stellt beide über Umgebungsvariablen bereit. Sie zeigen das Cloud-Profil auf die serverlosen Endpunkte, die Sie für den Überlauf verwenden möchten:

# Lokale Grundlast (Standard) — Ihre eigene GPU erledigt die Arbeit
SPRING_AI_OLLAMA_BASE_URL=http://localhost:11434
COMFYUI_MODE=local

# Cloud-Überlaufziel — nur per Anfrage abgerechnet
SPRING_AI_OLLAMA_BASE_URL=<ollama-cloud-endpunkt>
SPRING_AI_OLLAMA_CHAT_OPTIONS_MODEL=<cloud-katalog-modell>
COMFYUI_MODE=cloud
COMFYUI_CLOUD_API_KEY=<ihr-cloud-api-schlüssel>

Da die Plattform den gesamten KI-Datenverkehr über ihr eigenes Backend leitet – Frontends und Mobile-Clients rufen nie direkt einen KI-Dienst auf –, haben Sie einen einzigen, zentralen Ort, um zu entscheiden, ob eine gegebene Anfrage lokal oder in der Cloud bedient wird. Dieser zentrale Kontrollpunkt macht eine saubere Überlaufpolitik möglich.

Schritt 4: Die Warteschlange absorbiert Last, bevor Sie Geld ausgeben

KeepUrAis Chat-Pipeline ist von Grund auf asynchron. Anstatt eine Verbindung offen zu halten, während ein Modell nachdenkt, übermittelt der Client eine Anfrage und fragt das Ergebnis ab:

POST /ask/submit      → gibt sofort eine Job-ID zurück
GET  /ask/status/{id} → gibt Fortschritt und die Antwort beim Streamen zurück

Das ist kostenrelevant. Da Nutzer ohnehin abfragen, kann Ihre lokale GPU-Warteschlange eine erhebliche Last absorbieren, bevor jemand eine vermeidenswerte Verzögerung erlebt. Die praktische Regel ist einfach: On-Premise zuerst in die Warteschlange stellen und erst dann in die Cloud überlaufen, wenn das Warten inakzeptabel wird. Warten in eigener Hardware ist kostenlos; Überlaufen kostet Geld. Der asynchrone Pfad lässt Sie diesen Unterschied ausnutzen, anstatt für jede Verzögerung von wenigen Sekunden zu zahlen.

Schritt 5: Kostenschranken setzen

Eine Cost-First-Architektur verdient Cost-First-Kontrollen. Drei Richtlinien halten die Rechnung kalkulierbar:

| Kontrolle | Zweck | |---|---| | Konservativer Überlaufschwellwert | Nur in die Cloud überlaufen, wenn die lokale GPU tatsächlich ausgelastet ist, damit günstige Hardware die maximale Arbeit erledigt. | | Tägliche Cloud-Ausgabenobergrenze | Jenseits einer Budgetgrenze den Überlauf stoppen und stattdessen On-Premise in die Warteschlange stellen – mit etwas mehr Latenz für eine harte Kostengrenze. | | Konversations-Affinität | Wenn eine Konversation in die Cloud überläuft, die verbleibenden Turns dort behalten, anstatt mitten im Thread hin und her zu wechseln. |

Zusammen stellen diese sicher, dass die Cloud ein Druckventil ist, kein Standard – und dass ein Datenverkehrs-Spike nie still in eine unkontrollierte Rechnung münden kann.

Eine Premium-Fähigkeitsebene mit Claude Code hinzufügen

Die bisherigen zwei Ebenen unterscheiden sich nur darin, wo die Inferenz läuft. Dasselbe Prinzip – nur für das zahlen, was die Anfrage erfordert – gilt auch dafür, wie leistungsfähig die Engine sein muss. Nicht jede Aufgabe ist gleich: Die meisten sind Routine, einige sind wirklich schwierig. KeepUrAi ermöglicht es Ihnen, Claude Code, Anthropics agentisches Coding-Tool, als bewusste, hochleistungsfähige Ebene für die Arbeit zu verbinden, die dies rechtfertigt.

Claude Code verbindet sich mit der integrierten Agent-Schnittstelle der Plattform (MCP), wird wie jeder andere verbundene Agent authentifiziert und über dasselbe Gateway wie Ihr übriger Datenverkehr geleitet. Es benötigt keine GPU und keine eigene Bereitstellung – es ist ein Agent, den Ihre Entwickler bereits betreiben, verbunden mit Ihrem privaten Hub. Einmal verbunden, kann es:

Ihre On-Premise-Dokumente und Wissensdatenbank über begrenzte, prüfbare Tool-Aufrufe durchsuchen
Bilder generieren und Texte mit den Diensten der Plattform übersetzen
Aufgaben übernehmen, die Nutzer über die Web- oder Mobile-App einreichen, sie abschliessen und die Ergebnisse zurückgeben

Dies rundet eine dreistufige Kostenleiter ab, bei der jede Stufe proportional zu dem Wert abgerechnet wird, den sie liefert:

  Stufe 1  Lokale GPU       ──▶  Standard-Chat, RAG, Suche       (nahezu null Grenzkosten)
  Stufe 2  Cloud-Überlauf   ──▶  dieselbe Arbeit bei Spitzenlast  (Pay-per-Token, nur bei Spitzen)
  Stufe 3  Claude Code      ──▶  komplexe, agentische, wertvolle Arbeit (Pay-per-use, bewusst aufgerufen)

Die Kostenlogik ist dieselbe wie beim Überlaufventil: Routinelasten erreichen Stufe 3 nie und bleiben daher günstig; nur die schwierigen, wertvollen Aufgaben eskalieren dorthin. Und da Claude Code über kontrollierte Tool-Aufrufe auf Ihr privates Wissen zugreift – statt eines vollständigen Datenexports –, kombinieren Sie frontier-grade Reasoning mit Ihrem eigenen On-Premise-Kontext, ohne frontier-grade Hardware dafür kaufen zu müssen.

Die Erfahrung konsistent halten

Es gibt einen Kompromiss, den es ehrlich zu planen gilt. Arbeit, die von der Cloud-Überlaufebene – oder von der Claude Code-Ebene – bedient wird, wird von einem Modell verarbeitet, das nicht byte-für-byte identisch mit Ihrem lokalen ist. Für die meisten allgemeinen Assistenzaufgaben ist dieser Unterschied gering, aber es lohnt sich, ihn zu managen:

Wählen Sie ein Cloud-Katalogmodell, dessen Verhalten Ihrem lokalen nahe kommt.
Verwenden Sie Konversations-Affinität (Schritt 5), damit eine einzelne Konversation nie mitten drin die Stimme wechselt.
Reservieren Sie den Überlauf für interaktive, latenzsensible Anfragen und die Premium-Ebene für Aufgaben, deren Schwierigkeit dies rechtfertigt; lassen Sie Batch- und Hintergrundarbeit in der On-Premise-Warteschlange warten, wo Konsistenz und Kosten beide lokal sprechen.

Wenn Datenschutz die Priorität ist

Dieser Leitfaden optimiert für Kosten unter der Annahme, dass das gelegentliche Senden von Inferenz – oder einer bewusst eskalierten Aufgabe – an einen externen Anbieter akzeptabel ist. Wenn Datenresidenz oder Vertraulichkeit das übergeordnete Anliegen ist, läuft dieselbe Plattform in einem vollständig On-Premise-Profil ohne externe Aufrufe: Jedes Token bleibt auf Ihrer Hardware. Die Architektur ist unverändert; Sie lassen einfach beide Ausgangsventile geschlossen – die Cloud-Überlaufebene und die externe Agentenebene – und betreiben ausschliesslich auf Stufe 1. Der Punkt ist, dass Sie entscheiden, wo die Grenze liegt, pro Bereitstellung, anstatt dass die Plattform für Sie entscheidet.

Eine Einstiegs-Checkliste

Bevor Sie mit Cost-First-Überlauf live gehen, bestätigen Sie:

[ ] Der vollständige Stack ist bereitgestellt und bedient Datenverkehr von On-Premise-Hardware
[ ] PostgreSQL mit dem Vector Store hält alle Anwendungsdaten lokal
[ ] Lokales Ollama und ComfyUI verarbeiten die Grundlast
[ ] Cloud-Inferenz-Endpunkte sind konfiguriert und als Überlaufziel erreichbar
[ ] Ein Überlaufschwellwert ist konservativ gegen lokale GPU-Auslastung gesetzt
[ ] Eine tägliche Cloud-Ausgabenobergrenze ist eingerichtet
[ ] Konversations-Affinität ist für übergelaufene Sitzungen aktiviert
[ ] Claude Code ist als authentifizierter Agent verbunden, auf die Arbeit beschränkt, die es rechtfertigt
[ ] Monitoring zeigt die lokale / Cloud / Premium-Anfragenaufteilung und -ausgaben im Zeitverlauf

Fazit

Die günstigste elastische KI-Architektur ist kein zweites Rechenzentrum in der Cloud, und es ist kein Load-Balancer, der Ihre gesamte Anwendung in ein teureres Zuhause überführt. Es ist eine einzige, grösstenteils On-Premise-Bereitstellung, die ihre alltägliche Arbeit auf Hardware erledigt, die Sie bereits besitzen, bei Spitzen auf Pay-per-use-Cloud-Inferenz zurückgreift und nur für die Arbeit, die es verdient, auf einen Frontier-Agenten eskaliert – bezahlt für Spitzen und schwierige Probleme, nie für Leerlaufkapazität.

KeepUrAi ist genau für diese Form konzipiert: ein selbstgehosteter Stack, Ihre Daten lokal gehalten, lokale und Cloud-Inferenz-Profile eingebaut, Claude Code als Premium-Fähigkeitsebene verbindbar und die zentrale Kontrolle, um anfrage-für-anfrage zwischen ihnen zu wählen. Wenn Sie abwägen, wie eine Cost-First-Hybrid-Bereitstellung für Ihre eigene Arbeitslast aussehen könnte, besprechen wir dies gerne mit Ihnen.