Ollama Cloud oder eigener Server: Was ändert sich?

Was sich bei Ollama Cloud ändert und was nicht

Ollama Cloud führt das Modell auf ollama.com statt auf Ihrer eigenen Hardware aus. Dabei bleiben derselbe ollama-Befehl und dieselbe REST API erhalten, die Sie bereits verwenden. Es ändern sich zwei Dinge: der angeforderte Modellname und der Speicherort der Zugangsdaten. Der Rest Ihrer Anwendung bleibt unverändert.

Diese Bequemlichkeit birgt auch ein Risiko. Eine Anfrage an ein Cloud-Modell sieht in Ihrem Code genauso aus wie eine Anfrage an ein lokales Modell. Daher kann leicht unklar werden, welche Prompts auf einem von Ihnen kontrollierten Rechner verarbeitet und welche an ein Unternehmen gesendet werden, das Sie nicht kontrollieren. Dieser Leitfaden grenzt die beiden Varianten voneinander ab. Anschließend wird gezeigt, wie Sie ein lokales Modell als Fallback beibehalten, sodass ein einzelner Konfigurationswert entscheidet, welche Variante verwendet wird.

Wenn Sie die lokale Variante noch nicht eingerichtet haben, beginnen Sie zuerst mit Ollama auf Ihrem eigenen VPS ausführen. Im Folgenden wird von einer funktionierenden ollama-Installation auf einem Linux-System ausgegangen.

Zwei Wege zu Ollama Cloud

Es gibt zwei Wege zu den gehosteten Modellen. Sie sind nicht austauschbar. Der gewählte Weg bestimmt, wo das Zugangstoken gespeichert wird, welchen Modellnamen Sie angeben und was eine Paketaufzeichnung auf Ihrem Server zeigen würde.

Weg 1: Ihr lokaler Daemon leitet die Anfrage weiter. Sie melden sich einmal an und fordern anschließend ein Modell an, dessen Name mit -cloud endet.

ollama signin
ollama pull gpt-oss:120b-cloud
ollama run gpt-oss:120b-cloud

ollama signin verknüpft dieses System mit Ihrem ollama.com-Konto. ollama signout hebt die Verknüpfung auf. Nach der Anmeldung kommuniziert Ihre Anwendung weiterhin mit dem lokalen Port, den sie bereits verwendet hat:

curl http://localhost:11434/api/chat -d '{
  "model": "gpt-oss:120b-cloud",
  "messages": [{"role": "user", "content": "Why is the sky blue?"}],
  "stream": false
}'

Lesen Sie diese URL noch einmal. Dort steht localhost, und die Inferenz findet nicht dort statt. Der lokale Daemon erkennt das Suffix -cloud, leitet die Anfrage an ollama.com weiter und streamt die Antwort zurück. Genau das ist der Zweck von Weg 1: Eine Anwendung, die bereits auf die Ollama API auf Port 11434 zeigt, benötigt keinerlei Codeänderung, sondern nur einen anderen Modellnamen.

Weg 2: Ihr Client ruft ollama.com direkt auf. Der lokale Daemon ist dabei überhaupt nicht beteiligt. Erstellen Sie unter https://ollama.com/settings/keys einen Schlüssel und senden Sie ihn als Bearer-Token.

export OLLAMA_API_KEY=your_api_key
curl https://ollama.com/api/chat \
  -H "Authorization: Bearer $OLLAMA_API_KEY" \
  -d '{
    "model": "gpt-oss:120b",
    "messages": [{"role": "user", "content": "Why is the sky blue?"}],
    "stream": false
  }'

Beachten Sie den Modellnamen. Bei Weg 2 lautet er gpt-oss:120b und hat kein Suffix -cloud. Das Suffix weist Ihren lokalen Daemon an, die Anfrage an den Upstream-Dienst weiterzuleiten. Es gehört daher nur zu Weg 1. Wenn Sie https://ollama.com aufrufen, befinden Sie sich bereits dort und geben den Namen ohne Suffix an. Die verbindliche Liste dieser Namen stammt direkt vom Host:

curl https://ollama.com/api/tags

Führen Sie stattdessen diesen Befehl aus, anstatt einer Modellliste aus einem Artikel zu vertrauen, auch nicht der aus diesem Artikel. Der Katalog ändert sich, und api/tags ist immer aktuell.

Welche Client-Aufrufe ändern sich, und welche nicht

Die offiziellen Python- und JavaScript-Bibliotheken erhalten Host und Header beim Erstellen des Clients. Nach dieser Zeile ändert sich nichts mehr. In Pfad eins ist der Konstruktor leer, weil standardmäßig der lokale Daemon verwendet wird:

from ollama import Client

client = Client()

messages = [{'role': 'user', 'content': 'Why is the sky blue?'}]

for part in client.chat('gpt-oss:120b-cloud', messages=messages, stream=True):
  print(part['message']['content'], end='', flush=True)

In Pfad zwei enthält der Konstruktor den Host und das Token:

import os
from ollama import Client

client = Client(
    host="https://ollama.com",
    headers={'Authorization': 'Bearer ' + os.environ.get('OLLAMA_API_KEY')}
)

messages = [{'role': 'user', 'content': 'Why is the sky blue?'}]

for part in client.chat('gpt-oss:120b', messages=messages, stream=True):
  print(part['message']['content'], end='', flush=True)

Der Aufruf client.chat(), die Streaming-Schleife, die Nachrichtenliste und die Struktur der Antwort sind in beiden Fällen identisch. Deshalb ist der Wechsel zwischen einem gehosteten und einem selbst gehosteten Dienst eine Konfigurationsänderung und keine Neuentwicklung. Die OpenAI-kompatible Schnittstelle verhält sich lokal genauso: Richten Sie ein OpenAI-SDK auf http://localhost:11434/v1/ mit api_key='ollama', das der lokale Server benötigt und anschließend ignoriert.

Wo das Zugangsdaten-Token liegt und wer es verwenden kann

Bei Pfad zwei steht das Zugangsdaten-Token als OLLAMA_API_KEY in Ihrer Umgebung. Halten Sie es aus der Shell-History und aus Ihrem Repository heraus. Legen Sie es bei einem systemd-Dienst in einer Environment=-Zeile oder in einer root gehörenden Umgebungsdatei mit dem Modus 600 ab.

Pfad eins überrascht viele. Die Anmeldung gehört zum Daemon, nicht zu Ihnen. Die Ollama-FAQ dokumentiert die Dienstidentität unter Linux in /usr/share/ollama/.ollama/id_ed25519.pub. Diese Datei gehört dem Dienstbenutzer ollama. Die lokale API verwendet keine Authentifizierung pro Anfrage. Daher übernimmt jeder Aufrufer, der Port 11434 erreichen kann, Ihr Konto und verbraucht Ihr Kontingent. Solange der Daemon auf dem Loopback-Interface lauscht, ist das unproblematisch. Sobald Sie OLLAMA_HOST=0.0.0.0:11434 setzen, damit ein anderer Rechner den Dienst erreicht, wird aus einem offenen Port eine offene Abrechnungsbeziehung. Lesen Sie daher wie Sie eine Ollama-API mit vorgeschalteter Authentifizierung absichern, bevor Sie die Bind-Adresse erweitern.

Warum dasselbe Modell lokal weniger Kontext liefert

Dieser Unterschied überrascht viele, die davon ausgehen, dass sich ein Modell auf beiden Wegen identisch verhält. Das ist nicht der Fall. Die Ursache ist der verfügbare Speicher.

Ollama wählt die lokale Standard-Kontextlänge anhand des Videospeichers, den es auf dem System erkennt.

[
  {
    "label": "Under 24 GiB VRAM",
    "default_context_tokens": "4,096"
  },
  {
    "label": "24 to 48 GiB VRAM",
    "default_context_tokens": "32,768"
  },
  {
    "label": "48 GiB VRAM or more",
    "default_context_tokens": "262,144"
  }
]

Ein VPS ohne GPU befindet sich in der untersten Stufe. Daher startet ein lokales Modell mit 4,096 Kontext-Tokens, während ein System mit einer großen Grafikkarte mit 262,144 startet. Cloud-Modelle ignorieren diese Stufen. Laut Ollama werden sie standardmäßig auf ihre maximale Kontextlänge gesetzt, weil der Speicher für diesen Kontext nicht Ihnen gehört.

Daher kann derselbe Prompt, der mit gpt-oss:120b-cloud funktioniert, bei einem lokalen Modell auf einem kleinen System unbemerkt abgeschnitten werden. Erhöhen Sie die lokale Obergrenze ausdrücklich:

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

Setzen Sie den Wert unter systemd als Environment="OLLAMA_CONTEXT_LENGTH=32768" mit systemctl edit ollama.service und führen Sie anschließend systemctl daemon-reload && systemctl restart ollama aus. Beachten Sie, was Sie dafür benötigen: Ein längerer Kontext bedeutet einen größeren Key-Value-Cache. Dieser Cache benötigt zusätzlich zum Speicher für die Modellgewichte RAM. Wenn Sie den Wert zu hoch setzen, wird die Generierung langsamer oder das Modell kann nicht geladen werden. num_ctx und OLLAMA_CONTEXT_LENGTH korrekt setzen erklärt die Berechnung. Welche Modelle in den tatsächlich verfügbaren Speicher passen behandelt die Modellgewichte.

Was Ihre Maschine tatsächlich verlässt

Seien Sie hier genau. Das ist der Grund, aus dem die meisten Leser ihre Dienste selbst hosten.

Bei lokaler Ausführung verlässt nichts die Maschine. Die Datenschutzrichtlinie von Ollama stellt ausdrücklich fest: Für die lokale Nutzung gilt: „Wir erfassen, speichern, übertragen oder haben keinen Zugriff auf Ihre Prompts, Antworten, Modellinteraktionen oder andere Inhalte, die Sie lokal verarbeiten.“ Ein Vorbehalt bleibt: Das Abrufen eines Modells ist weiterhin ein Download von ollama.com. Die Richtlinie nennt außerdem „Metadaten zu Modelldownloads“ und Ihre IP-Adresse als erfasste Daten. Die Registry erfährt, welche Modelle Sie abgerufen haben. Sie erfährt nicht, was Sie die Modelle gefragt haben.

Bei der Ausführung über den Cloud-Pfad werden der vollständige Prompt und die vollständige Antwort an einen Drittanbieter übertragen. Eine teilweise lokale Variante gibt es hier nicht. Jedes von Ihnen gesendete und jedes von Ihnen empfangene Token wird auf ollama.com verarbeitet. Laut Richtlinie verarbeitet das Unternehmen „Ihre Prompts und Antworten vorübergehend, um den Dienst bereitzustellen“, verwendet „Ihre Eingaben oder Ausgaben nicht zum Trainieren von KI-Modellen“ und beschreibt „technische Maßnahmen zur Minimierung der Speicherung von Prompt- und Antwortinhalten“. Das ist eine angemessene Zusage. Es bleibt jedoch eine Zusage eines anderen Anbieters zu Daten, die Sie ihm übergeben haben, und keine Eigenschaft Ihrer eigenen Maschine. Bewerten Sie diese Zusage wie jede andere Zusicherung eines Anbieters. Lesen Sie sie erneut, bevor Sie Inhalte senden, die Sie vertraglich oder gesetzlich auf Ihrer eigenen Infrastruktur aufbewahren müssen.

Die Falle ist Pfad eins. Ihr Code verwendet http://localhost:11434, Ihre Firewall-Regeln sind unverändert und Ihre Eingabeaufforderung verlässt weiterhin das Netzwerk, weil das Suffix -cloud im Modellnamen das Routing bestimmt. Eine localhost-URL sagt nichts darüber aus, wo die Inferenz ausgeführt wurde. Das ergibt sich aus dem Modellnamen. Das ist besonders wichtig, wenn die Eingabe Daten enthält, die Sie gezielt selbst hosten, um sie privat zu halten: Wenn Sie einen selbst gehosteten Standort-Tracker betreiben, damit Ihr Bewegungsverlauf niemals einen Drittanbieter erreicht, senden Sie diesen Verlauf trotzdem an ollama.com, wenn Sie ein -cloud-Modell bitten, eine Woche davon zusammenzufassen.

Lokales Modell als Fallback beibehalten

Da beide Pfade dieselbe API verwenden, können Sie die Auswahl als Laufzeiteinstellung statt als Abzweigung im Code umsetzen.

Die einfachste Variante benötigt überhaupt keinen Code. Lassen Sie Ihre Anwendung auf den lokalen Daemon zeigen und legen Sie den Modellnamen in der Konfiguration ab. Setzen Sie ihn auf llama3.2, läuft die Anwendung auf Ihrem eigenen Rechner. Setzen Sie ihn auf gpt-oss:120b-cloud, leitet derselbe Daemon die Anfragen an ollama.com weiter. Eine Umgebungsvariable genügt; ein erneutes Deployment ist nicht erforderlich.

Wenn das lokale Modell standardmäßig verwendet werden und die Cloud nur bei Überlastung einspringen soll, erzeugen Sie beide Clients und wählen Sie pro Anfrage:

import os
from httpx import ConnectError
from ollama import Client, ResponseError

LOCAL_MODEL = os.environ.get("LOCAL_MODEL", "llama3.2")
CLOUD_MODEL = os.environ.get("CLOUD_MODEL", "gpt-oss:120b")

local = Client(host="http://127.0.0.1:11434")
cloud = Client(
    host="https://ollama.com",
    headers={"Authorization": "Bearer " + os.environ["OLLAMA_API_KEY"]},
)

def chat(messages):
    try:
        return local.chat(LOCAL_MODEL, messages=messages)
    except (ConnectError, ResponseError) as err:
        print(f"local inference failed ({err}); sending this prompt to ollama.com")
        return cloud.chat(CLOUD_MODEL, messages=messages)

httpx wird als Abhängigkeit des Pakets ollama installiert. Sie müssen daher nichts zusätzlich installieren. ConnectError behandelt den Fall, dass der Daemon nicht läuft. ResponseError behandelt den Fall, dass der Daemon läuft, Anfragen aber ablehnt, etwa weil das lokale Modell noch nie heruntergeladen wurde.

Die Zeile print ist nicht bloß dekorativ. Ein stiller Fallback führt dazu, dass ein Prompt, den Sie auf Ihrer eigenen Hardware behalten wollten, beim ersten Neustart des Daemons während eines Upgrades unbemerkt an einen Dritten gesendet wird. Protokollieren Sie jeden Fallback. Bei sensiblen Daten sollten Sie den Fehler auslösen, statt auf den Fallback auszuweichen. Für ein datenschutzorientiertes Deployment ist es am sichersten, bei Fehlern den Vorgang ausdrücklich abzubrechen.

Ein weiterer Punkt macht das lokale Modell zu einer zuverlässigen Standardeinstellung: Halten Sie es im Speicher. Das Laden eines nicht residenten Modells kann auf einem VPS ohne GPU mehrere zehn Sekunden dauern. Das veranlasst Benutzer häufig erst, auf den Cloud-Pfad auszuweichen. Modell mit keep_alive im Speicher halten entfernt diese Verzögerung bei der ersten Anfrage.

Was Sie vor dem Abschluss vergleichen sollten

Vergleichen Sie nicht nur den Preis. Vertrauen Sie auch nicht auf einen Preis, den Sie in einem Artikel lesen, einschließlich des Preises in diesem Artikel. Vergleichen Sie vier Punkte und prüfen Sie jeden davon auf den Seiten des jeweiligen Anbieters:

• Verfügbarkeit der Modelle. Führen Sie curl https://ollama.com/api/tags für den aktuellen Katalog der gehosteten Modelle aus. Welche Modelle Sie lokal ausführen können, hängt dagegen von Ihrem RAM und VRAM ab.
• Kontextlimits. Gehostete Modelle verwenden standardmäßig ihr maximales Kontextlimit. Lokale Modelle verwenden standardmäßig das für die jeweilige VRAM-Klasse vorgesehene Limit. Wenn Sie lange Dokumente verarbeiten, entscheidet dieser Punkt die Frage allein.
• Ratenlimits. Gehostete Inferenz wird nach Nutzung abgerechnet. Überschreiten Sie das Limit, antwortet die API mit 429 Too Many Requests. Auf Ihrem eigenen Server gibt es kein Ratenlimit, sondern stattdessen eine harte Grenze für die gleichzeitige Verarbeitung. Das führt zu einem anderen Fehler und ist häufig problematischer.
• Aufbewahrungsrichtlinie. Lesen Sie den tatsächlichen Richtlinientext, notieren Sie das Datum, an dem Sie ihn gelesen haben, und prüfen Sie ihn vor jeder Verlängerung erneut.

Für die Kostenseite müssen Sie die Berechnung hier nicht wiederholen. Wann ein GPU-VPS die Abrechnung pro Token übersteigt behandelt den Break-even-Punkt korrekt und berücksichtigt auch den oft vergessenen Aspekt: Ein ungenutzter GPU-Server kostet genauso viel wie ein ausgelasteter.

Was ist mit einem Router vor mehreren Anbietern?

Die dritte Option ist ein Router, also ein Proxy, der mit Ihrer Anwendung über eine API kommuniziert und die Anfragen an mehrere Backends weiterleitet. Ein selbst gehosteter LiteLLM-Proxy oder ein gehosteter Dienst wie OpenRouter übernimmt diese Aufgabe. Der Vorteil ist unmittelbar erkennbar: eine Client-Konfiguration, mehrere Modelle und ein Fallback, wenn ein Anbieter vorübergehend Probleme hat. Dabei handelt es sich um eine natürliche Erweiterung des oben beschriebenen Fallback-Musters, verallgemeinert auf mehr als zwei Backends. Die Kosten sollten Sie jedoch berücksichtigen. Ein gehosteter Router ist ein weiterer Betreiber, der Ihre Prompts sieht. Die Frage nach der Aufbewahrung, die Sie einem Anbieter gestellt haben, müssen Sie nun auch einem zweiten stellen. Ein selbst gehosteter Router hält diesen Hop auf Ihrem eigenen Rechner. Dafür erhalten Sie einen zusätzlichen Dienst, den Sie betreiben, patchen und überwachen müssen. Router lösen die Auswahl des Modells und die Verfügbarkeit. Das Datenschutzproblem lösen sie nicht, weil der Prompt weiterhin dort landet, wohin ihn die Route weiterleitet.

Die Fehler, die Sie tatsächlich sehen

Die API dokumentiert die Statuscodes. Jeder Statuscode weist auf ein anderes Problem hin. 429 Too Many Requests bedeutet, dass Sie ein Rate Limit erreicht haben. Warten Sie daher und versuchen Sie die Anfrage erneut, statt in einer Schleife die Verbindung neu herzustellen. 502 Bad Gateway ist der für dieses Thema relevante Statuscode. Er wird zurückgegeben, wenn ein Cloud-Modell nicht erreicht werden kann. Bei Pfad eins bedeutet das, dass Ihr Daemon funktioniert, der Upstream jedoch nicht. 404 Not Found bei einem Modellnamen bedeutet meist, dass das Suffix nicht zum Host passt, ein -cloud-Name direkt an https://ollama.com gesendet wurde oder ein unqualifizierter Name an einen Daemon gesendet wurde, bei dem Sie sich nie angemeldet haben. Fehler werden als JSON übertragen. Während eines Streams erscheinen sie als Zeile wie {"error":"an error was encountered while running the model"} innerhalb der NDJSON-Antwort. Deshalb kann ein einfacher Streaming-Client eine teilweise Antwort ausgeben und anschließend ohne Erklärung stoppen. Analysieren Sie jede gestreamte Zeile und prüfen Sie, ob sie einen Schlüssel error enthält.

Auf der lokalen Seite tritt klassischerweise eine Verbindungsverweigerung auf Port 11434 auf. Das bedeutet, dass der Daemon nicht läuft. Prüfen Sie systemctl status ollama. Ein weiterer häufiger Fall ist eine Anfrage, die in Ihrer Shell funktioniert, aber aus einem Container fehlschlägt, weil der localhost des Containers nicht der Host ist.

Es gibt auch einen Fehlerfall ganz ohne Fehlermeldung: kein Internet. Der Cloud-Pfad funktioniert dann überhaupt nicht mehr, während der lokale Pfad davon nichts bemerkt. Wenn Sie Ihre Maschine unterwegs verwenden oder bei Ihrem Provider eine Routing-Störung auftritt, ist dieser Unterschied der gesamte Zweck des Produkts.

Die richtige Wahl für jeden Anwendungsfall

Verwenden Sie Ollama Cloud, wenn die Auslastung unregelmäßig ist, das Modell zu groß für Ihren VPS ist oder Sie noch entscheiden, ob Sie auf diesem Modell aufbauen möchten. Die Abrechnung pro Anfrage ist günstiger, als für eine ungenutzte GPU zu zahlen, die täglich zwanzig Minuten läuft. Ein Modell mit 120 Milliarden Parametern passt nicht auf einen Server, den Sie zum Preis eines Mittagessens mieten.

Betreiben Sie das Modell selbst, wenn die Prompts Ihre Infrastruktur nicht verlassen dürfen, der Rechner offline arbeiten muss oder die Auslastung konstant genug ist, dass eine gemietete GPU ausgelastet bleibt. Eine konstante Auslastung ist das aussagekräftige Kriterium: Abgerechnete Inferenz ist genau dann teuer, wenn sie dauerhaft läuft. Wenn der Durchsatz von Ollama bei Einzelanfragen zum Engpass wird, verarbeitet vLLM eine parallele Auslastung besser als Ollama. Dabei wechseln Sie den Inference-Server, nicht den Host.

In den meisten realen Umgebungen werden beide Varianten eingesetzt. Das ist unproblematisch, solange die Aufteilung bewusst erfolgt. Hinterlegen Sie den Modellnamen in der Konfiguration und protokollieren Sie jeden Fallback. Dann können Sie die entscheidende Frage jederzeit beantworten: Welche dieser Prompts haben die Infrastruktur verlassen?

FAQ

Sieht Ollama Cloud meine Prompts?

Ja. Beim gehosteten Pfad werden der vollständige Prompt und die vollständige Antwort an ollama.com gesendet und dort verarbeitet. In der Datenschutzrichtlinie von Ollama steht, dass das Unternehmen „Ihre Prompts und Antworten vorübergehend verarbeitet, um den Dienst bereitzustellen“ und „Ihre Eingaben oder Ausgaben nicht zum Trainieren von KI-Modellen verwendet“. Außerdem werden Maßnahmen beschrieben, die darauf ausgelegt sind, die Speicherung zu minimieren. Das ist eine Zusage des Anbieters für Daten, die Sie bereits übermittelt haben. Für lokale Modelle besagt dieselbe Richtlinie, dass das Unternehmen „Ihre Prompts, Antworten, Modellinteraktionen oder andere Inhalte, die Sie lokal verarbeiten, nicht erfasst, speichert, überträgt oder darauf zugreift“. Wenn die Anforderung lautet, dass Inhalte Ihre Infrastruktur niemals verlassen dürfen, erfüllt nur der lokale Pfad diese Anforderung.

Warum zeigt meine Anwendung weiterhin auf localhost, wenn das Modell in der Cloud ausgeführt wird?

Weil der lokale Daemon als Proxy arbeitet. Wenn Sie ollama signin ausführen und anschließend ein Modell anfordern, dessen Name mit -cloud endet, leitet Ihr Daemon diese Anfrage an ollama.com weiter und streamt die Antwort über Port 11434 zurück. Die URL Ihrer Anwendung ändert sich nicht. Genau das ist der Zweck: Eine Codeänderung ist nicht erforderlich. Das bedeutet auch, dass die Adresse localhost keine Aussage darüber liefert, wo die Inferenz stattgefunden hat. Prüfen Sie den Modellnamen, nicht die URL. Ein Suffix -cloud bedeutet, dass der Prompt das Internet durchlaufen hat.

Warum liefert mir dasselbe Modell lokal einen deutlich kürzeren Kontext?

Ollama wählt anhand des verfügbaren Videospeichers einen lokalen Standardwert: etwa 4k Tokens bei weniger als 24 GiB VRAM, 32k zwischen 24 und 48 GiB sowie 256k ab 48 GiB. Ein VPS ohne GPU fällt in die unterste Stufe. Cloud-Modelle werden standardmäßig auf ihre maximale Kontextlänge eingestellt, weil der dafür benötigte Speicher dem Anbieter gehört. Erhöhen Sie den lokalen Wert mit OLLAMA_CONTEXT_LENGTH, entweder als OLLAMA_CONTEXT_LENGTH=32768 ollama serve oder als Environment=-Zeile unter systemctl edit ollama.service. Beachten Sie, dass ein längerer Kontext einen größeren Key-Value-Cache im RAM benötigt. Auf einem kleinen Server kann eine Erhöhung daher die Generierung verlangsamen oder verhindern, dass das Modell geladen wird.

Kann ich automatisch auf ein lokales Modell zurückfallen, wenn die Cloud nicht erreichbar ist?

Ja. Dafür sind nur wenige Zeilen erforderlich, weil beide Pfade dieselbe API verwenden. Erstellen Sie zwei Client-Objekte: eines ohne Host-Argument für den lokalen Daemon und eines mit host="https://ollama.com" sowie einem Authorization: Bearer-Header. Fangen Sie anschließend httpx.ConnectError und ollama.ResponseError um den ersten Aufruf herum ab. Legen Sie die Richtung bewusst fest. Lokale Verarbeitung mit Cloud-Fallback kann dazu führen, dass ein Prompt, den Sie vertraulich halten wollten, bei einem routinemäßigen Neustart des Daemons die Maschine verlässt. Protokollieren Sie daher jeden Fallback. Bei sensiblen Workloads sollten Sie den Fehler weitergeben, statt einen Fallback zu verwenden.