Die steigende Bedeutung von künstlicher Intelligenz und insbesondere von Large Language Models (LLMs) hat Entwickler und Unternehmen gleichermaßen dazu veranlasst, eigene, private KI-Modelle zu betreiben. Die Kernmotivation dahinter ist häufig die Kontrolle über Daten und die Fähigkeit, das Modell an spezifische Bedürfnisse anzupassen ohne externe Abhängigkeiten. In diesem Kontext gewinnt Google Cloud Run als serverlose Plattform mit GPU-Unterstützung an Attraktivität, da sie eine flexible, skalierbare und private Bereitstellung von OpenAI-kompatiblen LLMs ermöglicht. Im Folgenden erfahren Sie, wie Sie ein privates LLM auf Google Cloud Run einrichten und optimal nutzen können – von den Voraussetzungen über die Implementierung bis hin zu praktischen Anwendungsmöglichkeiten und Tipps zur Anpassung.
Zunächst einmal zeigt die Entwicklung im Bereich der offenen KI-Modelle, dass die Lücke in der Leistungsfähigkeit zwischen den besten Open-Source-Modellen und den großen kommerziellen Angeboten kontinuierlich schrumpft. Modelle wie DeepSeek und Qwen liefern mittlerweile eine beeindruckende Leistung, die für viele Anwendungsfälle völlig ausreichend ist. Diese offenen Modelle bieten inzwischen auch wichtige Funktionen wie die Funktionserkennung und strukturierte Ausgaben, was ihre Einsetzbarkeit enorm verbessert. Zudem erlaubt die gestiegene Verfügbarkeit leistungsfähiger GPUs sogar in Consumer-Hardware mehr Menschen, solche Modelle lokal zu betreiben. Wenn es jedoch darum geht, eine Anwendung mit mehreren Nutzern produktiv zu versorgen, stößt man oft auf eine entscheidende Hürde: Wie lässt sich ein Modell unkompliziert und zuverlässig auf eigener Infrastruktur bereitstellen? Hier setzt die Möglichkeit an, Google Cloud Run mit serverlosen GPUs zu verwenden.
Dadurch lässt sich eine skalierbare, private API bereitstellen, die mit OpenAI- und LangChain-kompatiblen Schnittstellen arbeitet. Die Implementierung eines solchen Endpoints erlaubt es, eigene Schlüssel für die Authentifizierung zu definieren und die Kommunikation abzusichern – ohne dass komplexes Infrastrukturmanagement nötig wäre. Der erste Schritt zur Einrichtung besteht darin, ein Projekt in der Google Cloud zu erstellen und dort die nötigen APIs zu aktivieren. Darunter fallen Artifact Registry, Cloud Build, Cloud Run sowie Cloud Storage. Wichtig ist, dass der Zugriff auf GPUs separat beantragt und freigeschaltet wird, da diese nicht standardmäßig im Kontingent enthalten sind. Google empfiehlt für diesen Zweck aktuell die Region europe-west1, was allerdings je nach Anwendungsfall und Kostenaspekten variieren kann. Zudem sind diverse IAM-Berechtigungen zu vergeben, um Build-Prozesse, Zugriff auf die Registry und das Ausrollen des Dienstes zu ermöglichen.
Im nächsten Schritt wird die Quellcodebasis verwendet, die auf GitHub zur Verfügung gestellt wird. Dieses Projekt erweitert die offizielle Anleitung von Google um einen leichten Proxy-Server, der innerhalb des Cloud Run-Dienstes läuft. Dieser Proxy sorgt für die API-Schlüssel-Authentifizierung und leitet Anfragen an die eigentliche LLM-Instanz weiter. Durch die klare Trennung gelingt es, eine OpenAI-kompatible Oberfläche zu schaffen, die als Ersatz für Standard-APIs dienen kann. Das Setup beinhaltet das Erstellen oder Ändern einer Umgebungsdatei (. env), in die die selbst generierten API-Schlüssel eingetragen werden. Diese Schlüssel werden verfiziert, sobald ein Client eine Anfrage an das Modell sendet. So bleibt der Zugang privat und kontrolliert. Die Modellgewichte sind dabei im Docker-Image eingebunden, was zwar zu längeren Deployments führt, jedoch die volle Verfügbarkeit des Modells bei einem Aufruf sichert.
Nach der erfolgreichen Bereitstellung ist der Cloud Run Service unter einer spezifischen URL erreichbar, die dann als Basis-URL für API-Abfragen verwendet wird. Sowohl die OpenAI Python SDK als auch die OpenAI JavaScript SDK können so angepasst werden, dass sie mit dem privaten Endpoint kommunizieren. Ebenso erlaubt LangChain die Integration mit minimalen Anpassungen, welche hauptsächlich die Angabe der Basiskomponente und der Authentifizierungs-Header betreffen. Was die Leistung betrifft, ist zu berücksichtigen, dass je nach gewähltem Modell und Hardware-Ausstattung eine gewisse Latenz entstehen kann. Beispielsweise liefert das Basis-Setup mit Qwen3:14b etwa 20 bis 25 Token pro Sekunde, was für viele Anwendungen ausreichend ist, aber bei besonders zeitkritischen Einsätzen schnellere, aber kleinere Modelle vorteilhaft sein können. Hierzu zählen Google’s Gemma 3 mit 4 Milliarden Parametern oder DeepSeek-R1.
Solche Modelle sind oft schneller, verzichten aber möglicherweise auf Funktionen wie komplexe Tool- oder Funktionsaufrufe. Die Anpassung des Modells ist dank der offen registrierten Modelle von Ollama unkompliziert. Im Dockerfile lässt sich die Variable MODEL ändern und so zum Beispiel auf Gemma 3 oder ein anderes Modell umschalten. Es ist jedoch entscheidend, anschließend auch die Client-Seite auf das neue Modell zu verweisen, damit Anfragen zuverlässig beantwortet werden. Dieses hohe Maß an Freiheit macht das Setup besonders attraktiv für Entwickler, die den Spagat zwischen Leistungsfähigkeit, Flexibilität und Datenschutz meistern wollen. Die private Bereitstellung von LLMs eröffnet vielfältige Chancen, insbesondere für Firmen und Entwickler, die sensible Daten besitzen oder spezifische Compliance-Anforderungen erfüllen müssen.
Die Möglichkeit, LLMs auch mit Open-Source-Modellen effizient zu betreiben, reduziert langfristig Abhängigkeiten von Cloud-Diensten großer Anbieter und minimiert mögliche Datenschutzrisiken. Zudem bietet die Plattform automatische Skalierung und eine vollständige Serverlosigkeit, wodurch Wartungsaufwand und Kosten optimal gemanagt werden können. Ein wesentlicher Punkt für die Praxis ist die Berücksichtigung von Cold-Starts, einem typischen Phänomen bei serverlosen Plattformen. Wenn der Dienst längere Zeit nicht genutzt wurde, benötigt er beim erneuten Start einige Sekunden, bis das Modell geladen und alle erforderlichen Ressourcen bereitgestellt sind. Dies sollte bei der Planung von Anwendungen berücksichtigt werden, insbesondere wenn schnelle Antwortzeiten unerlässlich sind. Zusätzlich bietet das System die Möglichkeit, mehrere API-Schlüssel zu verwalten und so differenzierte Zugriffsrechte zu vergeben.
Beispielsweise lassen sich Schlüssel für verschiedene Teams oder Anwendungen ausgeben und bei Bedarf einzeln widerrufen, ohne den Dienst komplett neu aufsetzen zu müssen. Dies erhöht die Sicherheit und Übersichtlichkeit im Betrieb. Für Entwickler, die sich intensiver mit komplexeren Nutzungsszenarien beschäftigen, sind die OpenAI- und LangChain-SDKs hervorragende Ausgangspunkte. Diese bieten nicht nur einfache Chat-Komplettierungs-Anfragen, sondern auch fortgeschrittene Features wie Chat-Plugins, Tool-Integration und strukturierte Datenverarbeitung. Die native OpenAI-Kompatibilität des Cloud Run Endpoints ermöglicht es, bestehende Anwendungen ohne große Umstellungen weiterzuführen und gleichzeitig die volle Kontrolle über die Infrastruktur zu behalten. Zusammenfassend bildet Google Cloud Run mit seiner Kombination aus serverloser Ausführung, GPU-Beschleunigung und ausgefeilter API-Verwaltung eine ideale Plattform für das Hosting privater LLMs, die kompatibel mit OpenAI sind.
Das vorgestellte Setup bietet sowohl Anfängern als auch erfahrenen Entwicklern eine umfassende Lösung, die die wichtigsten Herausforderungen der KI-Integration adressiert: Daten- und Zugriffs-sicherheit, Skalierbarkeit, einfache Handhabung und die Freiheit, das Modell an die eigenen Anforderungen anzupassen. Für alle, die sich mit der Zukunft der KI beschäftigen und dabei maximale Kontrolle behalten möchten, ist dieses Vorgehen ein strategischer Schritt – weg von großen schwarzen Boxen hin zu transparenten, flexiblen und selbst verwalteten KI-Diensten. Wer also auf der Suche nach einer leistungsfähigen und gleichzeitig privaten KI-Infrastruktur ist, sollte die Möglichkeiten von Google Cloud Run in Kombination mit Open-Source-LLMs unbedingt in Betracht ziehen.
