Ollama Cloud o server proprio: cosa cambia davvero

Cosa cambia con Ollama Cloud e cosa invece resta invariato

Ollama Cloud esegue il modello su ollama.com anziché sul tuo hardware, mantenendo lo stesso comando ollama e la stessa API REST che utilizzi già. Cambiano due elementi: il nome del modello richiesto e la posizione della credenziale. Il resto dell’applicazione rimane esattamente invariato.

Questa comodità comporta anche un rischio. Nel codice, una richiesta a un modello cloud ha lo stesso aspetto di una richiesta a un modello locale. È quindi facile perdere di vista quali prompt vengono elaborati su una macchina sotto il tuo controllo e quali vengono inviati a un’azienda che non controlli. Questa guida traccia questa distinzione e mostra come mantenere un modello locale come fallback, in modo che un singolo valore di configurazione determini quale delle due modalità utilizzare.

Se non hai ancora configurato il componente locale, inizia da eseguire Ollama sul tuo VPS . Tutto ciò che segue presuppone un ollama funzionante su un sistema Linux.

Due modi per raggiungere Ollama Cloud

Esistono due percorsi per accedere ai modelli ospitati e non sono intercambiabili. La scelta determina dove viene salvata la credenziale, quale nome del modello specificare e cosa mostrerebbe una cattura dei pacchetti sul server.

Percorso uno: il daemon locale inoltra la richiesta. Esegui l’accesso una volta, quindi richiedi un modello il cui nome termina con -cloud.

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

Alcuni modelli cloud riportano invece il tag cloud senza altri elementi, ad esempio gemma4:cloud. È il formato mostrato attualmente dalla documentazione cloud di Ollama per l’applicazione e la CLI. Considera entrambe le terminazioni, -cloud o :cloud, come modelli cloud.

ollama signin collega questa macchina al tuo account ollama.com. ollama signout la scollega. Dopo l’accesso, l’applicazione continua a comunicare con la porta locale già utilizzata:

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

Osserva di nuovo quell’URL. Indica localhost, ma l’inferenza non viene eseguita lì. Il daemon locale riconosce il suffisso -cloud, inoltra la richiesta a ollama.com e restituisce la risposta in streaming. Questo è il vantaggio principale del percorso uno: un’applicazione già configurata per usare l’API Ollama sulla porta 11434 non richiede alcuna modifica al codice. È sufficiente specificare un nome del modello diverso.

Percorso due: il client chiama direttamente ollama.com. In questo caso il daemon locale non è coinvolto. Crea una chiave in https://ollama.com/settings/keys, quindi inviala come token bearer.

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
  }'

Osserva il nome del modello. Nel percorso due è gpt-oss:120b, senza il suffisso -cloud. Il suffisso serve a indicare al daemon locale di inoltrare la richiesta al servizio upstream, quindi appartiene soltanto al percorso uno. Quando chiami https://ollama.com sei già sul servizio remoto e devi specificare il nome semplice. L’elenco autorevole di questi nomi proviene direttamente dall’host:

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

Esegui questo comando invece di affidarti a un elenco di modelli pubblicato in un articolo, incluso questo. Il catalogo cambia e api/tags è sempre aggiornato.

Quali chiamate del client cambiano e quali no

Le librerie ufficiali Python e JavaScript ricevono l'host e gli header quando si crea il client. Dopo quella riga, il resto non cambia. Nel primo percorso, il costruttore è vuoto perché il valore predefinito è il demone locale:

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)

Nel secondo percorso, il costruttore contiene l'host e il 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)

La chiamata client.chat(), il ciclo di streaming, l'elenco dei messaggi e la struttura della risposta sono identici in entrambi i casi. Per questo il passaggio tra un servizio hosted e uno self-hosted richiede una modifica alla configurazione, non una riscrittura. Anche localmente, l'interfaccia compatibile con OpenAI si comporta allo stesso modo: configurare un SDK OpenAI per usare http://localhost:11434/v1/ con api_key='ollama', un segnaposto richiesto dall'SDK che il server locale ignora.

Dove risiede la credenziale e chi può utilizzarla

Nel percorso due, la credenziale è OLLAMA_API_KEY nell'ambiente. Non inserirla nella cronologia della shell né nel repository. In un servizio systemd, specificarla in una riga Environment= oppure in un file dell'ambiente di proprietà di root con modalità 600.

Il percorso uno è quello che sorprende più spesso. L'autenticazione appartiene al demone, non all'utente. Le FAQ di Ollama documentano l'identità del servizio su Linux in /usr/share/ollama/.ollama/id_ed25519.pub, di proprietà dell'utente di servizio ollama. L'API locale non prevede l'autenticazione per richiesta. Di conseguenza, ogni chiamante che può raggiungere la porta 11434 eredita il tuo account e utilizza la tua quota. Questo è accettabile finché il demone è in ascolto sull'interfaccia di loopback. Quando imposti OLLAMA_HOST=0.0.0.0:11434 per raggiungerlo da un'altra macchina, una porta aperta diventa un rapporto di fatturazione aperto. Per questo, prima di ampliare l'indirizzo di bind, leggi come configurare l'autenticazione davanti a un endpoint Ollama.

Perché lo stesso modello offre un contesto più breve in locale

Questa è la differenza che spesso sfugge a chi presume che un modello si comporti allo stesso modo in entrambi i casi. Non è così, e la causa è la memoria.

Ollama sceglie la lunghezza predefinita del contesto locale in base alla memoria video rilevata sul sistema.

[
  {
    "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"
  }
]

Una VPS senza GPU si trova nel livello più basso, quindi un modello locale parte da 4,096 token di contesto, mentre una macchina con una scheda di grandi dimensioni parte da 262,144. I modelli cloud ignorano questi livelli: Ollama documenta che, per impostazione predefinita, usano la lunghezza massima del contesto, perché la memoria che lo contiene non appartiene al sistema locale.

Di conseguenza, lo stesso prompt che funziona con gpt-oss:120b-cloud può essere troncato senza avviso quando viene inviato a un modello locale su una macchina con poca memoria. Aumenta esplicitamente il limite locale:

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

Con systemd, impostalo come Environment="OLLAMA_CONTEXT_LENGTH=32768" con systemctl edit ollama.service, quindi systemctl daemon-reload && systemctl restart ollama. Considera il costo di questa impostazione: un contesto più lungo richiede una cache key-value più grande, e questa cache occupa RAM aggiuntiva oltre a quella richiesta dai pesi del modello. Se aumenti troppo il valore, la generazione rallenta oppure il modello non viene caricato. Impostare correttamente num_ctx e OLLAMA_CONTEXT_LENGTH spiega i calcoli, mentre quali modelli rientrano nella memoria disponibile tratta l'aspetto relativo ai pesi.

Che cosa lascia realmente la macchina

Siate precisi su questo punto, perché è il motivo principale per cui la maggior parte degli utenti sceglie il self-hosting.

In esecuzione locale, non lascia la macchina alcun dato. L'informativa sulla privacy di Ollama dichiara chiaramente che, per l'uso locale, «non raccogliamo, memorizziamo, trasmettiamo né possiamo accedere ai prompt, alle risposte, alle interazioni con i modelli o agli altri contenuti elaborati localmente». Esiste una sola precisazione: scaricare un modello resta un download da ollama.com e l'informativa include tra i dati raccolti i «metadati del download del modello» e l'indirizzo IP. Il registry sa quali modelli avete scaricato. Non sa che cosa avete chiesto loro.

Nel percorso cloud, l'intero prompt e l'intera risposta vengono inviati a una terza parte. Non esiste una versione parziale di questo comportamento. Ogni token inviato e ogni token ricevuto viene elaborato su ollama.com. L'informativa afferma che l'azienda elabora «i prompt e le risposte per un periodo transitorio, allo scopo di fornire il servizio», che «non utilizza gli input o gli output per addestrare modelli di intelligenza artificiale» e descrive «misure tecniche progettate per ridurre al minimo la conservazione del contenuto dei prompt e delle risposte». È un impegno ragionevole. Resta comunque l'impegno di un soggetto terzo sui dati che gli avete consegnato, non una caratteristica della vostra macchina. Valutatelo come fareste con qualsiasi promessa di un fornitore e rileggetelo prima di inviare dati che, per obblighi contrattuali o legali, dovete conservare sulla vostra infrastruttura.

Il rischio riguarda il percorso uno. Il codice indica http://localhost:11434, le regole del firewall non sono cambiate e il prompt attraversa comunque Internet, perché il suffisso -cloud nel nome del modello determina il routing. Un URL localhost non indica dove è stata eseguita l'inferenza. Lo indica il nome del modello. Questo è particolarmente importante quando il prompt contiene dati che gestite in self-hosting proprio per mantenerli privati: se eseguite un tracker della posizione in self-hosting affinché la cronologia dei vostri spostamenti non raggiunga mai una terza parte, chiedere a un modello -cloud di riepilogarne una settimana invia comunque quella cronologia a ollama.com.

Su un server che non deve mai inoltrare un prompt, eliminate del tutto questa possibilità. Ollama documenta una modalità solo locale: impostate OLLAMA_NO_CLOUD=1 nell'ambiente del servizio oppure "disable_ollama_cloud": true in ~/.ollama/server.json, quindi riavviate il servizio. Il demone perde l'accesso ai modelli cloud e alla ricerca web, quindi il nome accidentale di un modello cloud non può causare alcuna fuga di dati.

Mantenere un modello locale come fallback

Poiché entrambi i percorsi usano la stessa API, puoi rendere la scelta un'impostazione runtime invece di duplicare il codice.

La versione più semplice non richiede alcun codice. Mantieni l'applicazione configurata per usare il demone locale e inserisci il nome del modello nella configurazione. Impostalo su llama3.2 per eseguire il modello sul tuo server. Impostalo su gpt-oss:120b-cloud e lo stesso demone inoltrerà le richieste a ollama.com. Basta una variabile d'ambiente, senza eseguire nuovamente il deploy.

Se vuoi che il modello locale sia il valore predefinito e che il cloud gestisca il sovraccarico, crea entrambi i client e scegli quale usare per ogni richiesta:

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 viene fornito come dipendenza del pacchetto ollama, quindi non devi installare altro. ConnectError gestisce il caso in cui il demone sia arrestato. ResponseError gestisce il caso in cui il demone sia attivo ma rifiuti la richiesta, ad esempio perché il modello locale non è mai stato scaricato.

La riga print non è ornamentale. Un fallback silenzioso invia a tua insaputa a terzi, al primo riavvio del demone durante un aggiornamento, un prompt che intendevi mantenere sul tuo hardware. Registra ogni fallback e, per i dati sensibili, genera un errore invece di eseguire il fallback. La policy di fallback più sicura per un deployment orientato alla privacy consiste nel generare un errore esplicito.

Un altro elemento rende il modello locale un valore predefinito affidabile: mantienilo residente in memoria. Il caricamento a freddo su un VPS che usa soltanto la CPU può richiedere decine di secondi. È proprio questo che spinge inizialmente a usare il percorso cloud. Mantenere il modello in memoria con keep_alive elimina il ritardo della prima richiesta.

Cosa confrontare prima di decidere

Non confrontare solo i prezzi e non fidarti di un prezzo letto in un articolo, compresa la data di questo articolo. Confronta quattro aspetti e verifica ciascuno sulle pagine del fornitore:

• Disponibilità dei modelli. Esegui curl https://ollama.com/api/tags per visualizzare il catalogo hosted aggiornato. I modelli che puoi eseguire in locale sono invece limitati dalla RAM e dalla VRAM disponibili.
• Limiti del contesto. I modelli hosted usano per impostazione predefinita il limite massimo. I modelli locali usano il limite previsto dal livello di VRAM, come indicato sopra. Se il carico di lavoro riguarda documenti lunghi, questo aspetto determina da solo la scelta.
• Limiti di richieste. L'inferenza hosted è soggetta a limiti di utilizzo. Se superi il limite, l'API restituisce 429 Too Many Requests. Il tuo server non ha un limite di richieste, ma ha invece un limite rigido di concorrenza. Si tratta di un tipo di errore diverso e spesso peggiore.
• Policy di conservazione. Leggi il testo effettivo della policy, annota la data in cui l'hai consultato e verificalo di nuovo prima di ogni rinnovo.

Per i costi, non rifare qui i calcoli. Quando un GPU VPS supera la fatturazione per token analizza correttamente il punto di pareggio, compreso l'aspetto che molti dimenticano: un server GPU inattivo viene fatturato come uno occupato.

E un router davanti a più provider?

La terza opzione è un router: un proxy che espone una singola API alla tua applicazione e distribuisce le richieste su più backend. Un proxy LiteLLM self-hosted o un servizio gestito come OpenRouter svolgono entrambi questa funzione. Il vantaggio è concreto: una sola configurazione client, più modelli e failover quando un provider attraversa un periodo di problemi. È l'estensione naturale del pattern di fallback descritto sopra, generalizzato oltre due backend. È però importante considerare il costo. Un router gestito da terzi è un ulteriore operatore che vede i tuoi prompt. Di conseguenza, la questione della conservazione dei dati che ponevi a un provider deve ora essere posta a due operatori. Un router self-hosted mantiene questo passaggio sulla tua macchina, ma aggiunge un secondo servizio da eseguire, aggiornare e monitorare. I router risolvono la scelta del modello e la disponibilità. Non risolvono il problema della privacy, perché il prompt finisce comunque ovunque lo inoltri la route.

Gli errori che vedrai realmente

L'API documenta i codici di stato e ciascuno indica un problema diverso. 429 Too Many Requests significa che hai raggiunto un limite di frequenza: riduci la frequenza delle richieste e riprova, invece di riconnetterti in un ciclo. 502 Bad Gateway è il codice specifico di questo caso: viene restituito quando non è possibile raggiungere un modello cloud. Nel percorso uno significa che il tuo daemon funziona e che il problema riguarda il servizio upstream. 404 Not Found associato al nome di un modello significa che il modello non esiste sull'host indicato. In genere si tratta di un nome -cloud inviato direttamente a https://ollama.com oppure di un modello locale che non hai mai scaricato. Per i modelli locali l'accesso non c'entra, perché l'API locale non richiede autenticazione. Gli errori arrivano in formato JSON e, durante lo streaming, compaiono come una riga del tipo {"error":"an error was encountered while running the model"} all'interno della risposta NDJSON. Per questo un client di streaming ingenuo può stampare una risposta parziale e poi interrompersi senza spiegazioni. Analizza ogni riga dello stream e verifica la presenza di una chiave error.

Sul lato locale, il caso classico è un rifiuto della connessione sulla porta 11434. Significa che non c'è alcun processo in ascolto su quella porta: controlla systemctl status ollama e, se il daemon è in esecuzione, verifica se OLLAMA_HOST lo ha spostato su un'altra porta. Un altro caso comune è una richiesta che funziona dalla shell ma fallisce da un container, perché il localhost del container non è quello dell'host.

Esiste anche un caso di errore senza alcun messaggio: l'assenza di connessione Internet. Il percorso cloud smette completamente di funzionare, mentre quello locale non rileva il problema. Se porti il computer fuori sede o il provider subisce un problema di routing, questa differenza rappresenta l'intero comportamento del prodotto.

Quando conviene ciascuna scelta

Usa Ollama Cloud quando il carico è discontinuo, quando il modello è troppo grande per il tuo VPS oppure quando stai ancora valutando se vale la pena basarci il progetto. Pagare per richiesta è più conveniente che pagare una GPU inattiva, utilizzata per venti minuti al giorno, e un modello con 120 miliardi di parametri non può entrare in un server che noleggi al prezzo di un pranzo.

Esegui il modello autonomamente quando i prompt non devono lasciare la tua infrastruttura, quando la macchina deve funzionare offline oppure quando il carico è abbastanza costante da mantenere occupata una GPU noleggiata. Il carico costante è il segnale più affidabile: l'inferenza a consumo è costosa proprio quando viene eseguita continuamente. Se arrivi al punto in cui la gestione di una singola richiesta da parte di Ollama diventa il collo di bottiglia, vLLM gestisce meglio il carico concorrente rispetto a Ollama, e questo richiede di cambiare motore, non host. Se preferisci acquistare questa configurazione privata invece di realizzarla, confrontare un server AI privato disponibile solo su preventivo con la realizzazione autonoma su una GPU noleggiata mostra cosa comporta effettivamente il progetto e quando conviene acquistare una semplice API.

La maggior parte delle implementazioni reali finisce per usare entrambe le soluzioni. Va bene, purché la suddivisione sia intenzionale. Inserisci il nome del modello nella configurazione, registra ogni fallback e potrai sempre rispondere all'unica domanda davvero importante: quali di questi prompt hanno lasciato l'infrastruttura?

FAQ

Ollama Cloud vede i miei prompt?

Sì. Nel percorso hosted il prompt completo e la risposta completa vengono inviati a ollama.com ed elaborati lì. L'informativa sulla privacy di Ollama dichiara che elabora «i tuoi prompt e le tue risposte temporaneamente per fornire il servizio» e che «non usa i tuoi input o output per addestrare modelli di IA», oltre a descrivere misure pensate per ridurre al minimo la conservazione dei dati. Si tratta di un impegno del fornitore relativo ai dati che hai già trasferito. Per i modelli locali, la stessa informativa dichiara che l'azienda «non raccoglie, archivia, trasmette né può accedere ai tuoi prompt, alle tue risposte, alle interazioni con i modelli o ad altri contenuti elaborati localmente». Se il requisito è che i contenuti non lascino mai la tua infrastruttura, solo il percorso locale lo soddisfa.

Perché la mia applicazione punta ancora a localhost se il modello viene eseguito nel cloud?

Perché il daemon locale funziona da proxy. Quando esegui ollama signin e poi richiedi un modello cloud, il cui nome termina con -cloud o :cloud, il daemon inoltra la richiesta a ollama.com e trasmette la risposta in streaming attraverso la porta 11434. L'URL dell'applicazione non cambia, ed è proprio questo il vantaggio: non è necessaria alcuna modifica al codice. Questo significa anche che l'indirizzo localhost non fornisce alcuna informazione sul luogo in cui è stata eseguita l'inferenza. Controlla il nome del modello, non l'URL. Un tag cloud nel nome indica che il prompt ha attraversato Internet.

Perché lo stesso modello usa localmente un contesto molto più breve?

Ollama sceglie un valore predefinito locale in base alla memoria video disponibile: circa 4k token sotto 24 GiB di VRAM, 32k tra 24 e 48 GiB e 256k a partire da 48 GiB. Un VPS senza GPU rientra nel livello più basso. Per impostazione predefinita, i modelli cloud vengono configurati con la lunghezza massima del contesto, perché la memoria che lo contiene appartiene al fornitore. Aumenta il valore locale con OLLAMA_CONTEXT_LENGTH, come OLLAMA_CONTEXT_LENGTH=32768 ollama serve oppure come riga Environment= sotto systemctl edit ollama.service. Ricorda che un contesto più lungo richiede una cache key-value più grande nella RAM. Su un server di dimensioni ridotte, aumentare questo valore può rallentare la generazione o impedire il caricamento del modello.

Posso passare automaticamente a un modello locale quando il cloud non è raggiungibile?

Sì, bastano poche righe, perché entrambi i percorsi usano la stessa API. Crea due oggetti Client: uno senza l'argomento host per il daemon locale e uno con host="https://ollama.com" e un'intestazione Authorization: Bearer. Quindi intercetta httpx.ConnectError e ollama.ResponseError attorno alla prima chiamata. Scegli deliberatamente la direzione del fallback. Usare prima il locale con un fallback sul cloud significa che un prompt che intendevi mantenere privato può lasciare la macchina durante un normale riavvio del daemon. Registra quindi ogni fallback e, per i carichi di lavoro sensibili, genera un errore invece di eseguire il fallback.