Ollama Cloud: Lokal und Cloud-Hybrid
Nicht genug lokaler VRAM, aber Sie möchten ein riesiges Modell mit Hunderten von Milliarden Parametern verwenden? Ollama Cloud bietet eine dritte Option: Das Modell läuft auf Cloud-GPUs, während Ihr Code und Ihre Toolchain keinerlei Unterschied bemerken.
Dieses Kapitel stellt vor, wie Cloud-Modelle ausgeführt werden, den direkten API-Zugriff, den reinen lokalen Modus und den Ausmusterungsmechanismus und bietet abschließend eine Auswahlstrategie für die hybride Nutzung.
Was ist ein Cloud-Modell
Ein Cloud-Modell ist ein neuer Modelltyp in Ollama: Die Gewichte werden in der Ollama-Cloud gespeichert, die Inferenz erfolgt auf dem offiziellen GPU-Cluster, und die lokale Seite übernimmt nur die Weiterleitung von Anfragen.
Es löst einen ganz konkreten Schmerzpunkt: Flaggschiff-Open-Source-Modelle mit Hunderten von Milliarden Parametern erfordern oft Hunderte GB VRAM, was den lokalen Einsatz für Einzelpersonen und kleine Teams unmöglich macht, doch der Bedarf, sie zu nutzen, ist real.
Verfügbare Cloud-Modelle tragen das Cloud-Tag in der Modellbibliothek. Nehmen wir die qwen3.5-Familie als Beispiel: Die Flaggschiff-Spezifikation ist qwen3.5:cloud.
Vier Möglichkeiten, Cloud-Modelle auszuführen
Schließen Sie zuerst die einmalige Vorbereitung ab: Registrieren Sie sich und melden Sie sich bei Ihrem Ollama-Konto an, dann führen Sie den pull-Befehl für das Cloud-Tag aus (es ist nur ein "Zeiger" und lädt keine Gewichte herunter).
Melden Sie sich mit Ihrem Ollama-Konto an (für Cloud-Modelle erforderlich):
ollama signin
Geben Sie Ihre E-Mail in das Anmeldefenster ein, das im Browser erscheint (falls später eine Telefonverifizierung erforderlich ist, funktioniert auch eine chinesische Telefonnummer):
Der Pull des Cloud-Tags ist fast augenblicklich abgeschlossen:
ollama pull qwen3.5:cloud
Wenn man es ausführt, ist die Erfahrung identisch mit der von lokalen Modellen:
ollama run qwen3.5:cloud
In der Oberfläche sehen Sie ein Cloud-Symbol:
Python-Aufrufe
Beispiel
# Der einzige Unterschied zu lokalen Modellen: Der Modellname enthält :cloud
stream = chat(
model='qwen3.5:cloud',
messages=[{'role': 'user', 'content': 'Stellen Sie das Python Rookie Tutorial in einem Satz vor'}],
stream=True,
)
for chunk in stream:
print(chunk.message.content, end='', flush=True)
JavaScript-Aufrufe
Beispiel
const response = await ollama.chat({
model: 'qwen3.5:cloud',
messages: [{ role: 'user', content: 'Stellen Sie das Python Rookie Tutorial in einem Satz vor' }],
stream: true,
})
for await (const chunk of response) {
process.stdout.write(chunk.message.content)
}
curl-Aufrufe
Beispiel
"model": "qwen3.5:cloud",
"messages": [{ "role": "user", "content": "Stellen Sie das Python Rookie Tutorial in einem Satz vor" }],
"stream": false
}'
Transparente Weiterleitung: lokale API kann auch Cloud-Modelle aufrufen
Das Elegante an Cloud ist, dass die Weiterleitungslogik vollständig vom lokalen Dienst übernommen wird.
Wenn ein :cloud-Modell von localhost:11434 angefordert wird, übernimmt der lokale Dienst automatisch Authentifizierung und Weiterleitung an die Cloud, und Ihr Anwendungscode, Agent-Tools und Editor-Integrationen bekommen davon nichts mit.
Das bedeutet, dass bestehende Integrationen sofort die Fähigkeiten großer Modelle nutzen können: Ändern Sie den Modellnamen von Claude Code in qwen3.5:cloud, und dieselbe Toolchain wechselt zur Flaggschiff-Spezifikation.
Derzeit gibt es eine bekannte Einschränkung: Cloud-Modelle unterstützen noch keine strukturierte Ausgabe (den format-Parameter). Aufgaben, die JSON-Schema-Einschränkungen erfordern, sollten weiterhin lokalen Modellen zugewiesen oder in der Anwendungsschicht geparst werden.
Direkte Verbindung zu ollama.com/api
Zusätzlich zur Weiterleitung über den lokalen Dienst können Sie auch die lokale Instanz überspringen und die Cloud-API direkt aufrufen, was für Szenarien geeignet ist, in denen auf dem Server kein Ollama installiert ist.
Erstellen Sie zunächst einen API-Schlüssel auf der Einstellungsseite der offiziellen Website und übergeben Sie ihn dann im Bearer-Format:
Beispiel
curl https://ollama.com/api/chat \
-H "Authorization: Bearer $OLLAMA_API_KEY" \
-d '{
"model": "qwen3.5",
"messages": [{ "role": "user", "content": "Stellen Sie das Python Rookie Tutorial in einem Satz vor" }],
"stream": false
}'
# Die Cloud kann auch verfügbare Modelle auflisten
curl https://ollama.com/api/tags
Das offizielle SDK unterstützt auch die Angabe von Host und Authentifizierungs-Header. Zur Verbindungsmethode siehe das Beispiel Client(host=...) im Kapitel Programmzugriff; ändern Sie einfach den Host zu https://ollama.com.
API-Schlüssel laufen derzeit nicht ab, aber Sie können sie jederzeit auf der Einstellungsseite der offiziellen Website widerrufen; sie sind gleichbedeutend mit Ihren Zugangsdaten für die Cloud-Nutzung, daher sollten Sie sie nicht in Code-Repositories committen.
Reiner lokaler Modus: die Cloud vollständig deaktivieren
Teams, die keinerlei Toleranz dafür haben, dass Daten ihre Domäne verlassen, können die Cloud-Funktionen von Ollama vollständig deaktivieren, wodurch es zu reiner lokaler Software wird.
Wählen Sie eine der beiden Deaktivierungsmethoden, und starten Sie dann Ollama neu, damit die Änderung wirksam wird:
Beispiel
# { "disable_ollama_cloud": true }
# Methode 2: Umgebungsvariable
OLLAMA_NO_CLOUD=1 ollama serve
# Nachdem es wirksam geworden ist, zeigt das Log an: Ollama cloud disabled: true
Das Deaktivieren von Cloud-Funktionen führt auch zum Verlust von Cloud-Modellen und Online-Suchfunktionen, aber alle lokalen Modellfunktionen bleiben unberührt. In Kombination mit ausgehender Firewall-Blockierung können Sie einen vollständig physisch isolierten Modelldienst aufbauen.
Mechanismus zur Außerbetriebnahme von Cloud-Modellen
Cloud-Modelle haben einen Lebenszyklus: Wenn stärkere Open-Source-Modelle veröffentlicht werden, mustert das offizielle Team regelmäßig alte Cloud-Modelle aus und benachrichtigt Nutzer im Voraus per E-Mail und über Ankündigungen auf der offiziellen Website, während es auch empfohlene Alternativen bereitstellt.
Die offizielle Ankündigung erfolgt in Form einer Zuordnungstabelle "Außerbetriebnahmedatum - Modell - empfohlener Ersatz"; zum Beispiel wird ein Cloud-Modell an einem bestimmten Datum offline genommen und auf eine neue Version migriert; ändern Sie einfach den Modellnamen entsprechend.
Zwei technische Empfehlungen:
Erstens: Wenn Sie in automatisierten Workflows auf Cloud-Modelle verweisen, machen Sie den Modellnamen zu einem Konfigurationselement, anstatt ihn fest zu codieren, sodass Sie bei einer Außerbetriebnahme-Umstellung nur die Konfiguration ändern müssen.
Zweitens: Halten Sie lokale Alternativmodelle mit gleichwertigen Fähigkeiten für geschäftskritische Anwendungen bereit, damit Sie sofort auf sie zurückgreifen können, wenn ein Cloud-Modell außer Betrieb genommen wird oder das Netzwerk gestört ist.
Die Außerbetriebnahme gilt nur für Cloud-Modelle: lokal heruntergeladene Modellgewichte sind immer nutzbar, weshalb dieses Tutorial stets den lokalen Ansatz betont.
Auswahlstrategie: Wann welche verwendet werden sollte
| Szenario | Empfohlene Lösung | Grund |
|---|---|---|
| Alltägliche Aufgaben, die in den VRAM passen | Lokales Modell | Keine Kosten, keine Latenz, Daten verlassen das Gerät nie |
| Datenschutzsensible Daten | Lokales Modell (oder reiner lokaler Modus) | Konform und kontrollierbar |
| Riesiger Modellbedarf / keine GPU-Geräte | Cloud-Modell | Keine Hardwareinvestition nötig, Toolchain unverändert |
| Neue Modelle ausprobieren | Erst Cloud testen, dann lokalisieren, nachdem der Nutzen bestätigt wurde | Vermeiden, Hardware nur zur Evaluierung zu kaufen |
| Langfristige automatisierte Workflows | Lokal als Primär + Cloud als Backup | Cloud hat einen Ausmusterungsmechanismus; lokal besteht kein derartiges Risiko |
Die Best Practice für Hybrid-Architektur in einem Satz: Der tägliche Datenverkehr läuft lokal, schwere Aufgaben nutzen :cloud bei Bedarf, und alle Modellnamen gehören in Konfigurationsdateien.
Weitere Erweiterungen