Cumulare Due Abbonamenti Ollama Pro sulla Stessa Macchina con Docker

Publié le 08 May 2026

tempo di lettura : 14 minutes

Due abbonamenti Pro, una sola macchina, una sola carta bancaria, e zero conflitti di rete. Come Docker mi ha permesso di raddoppiare la mia capacità di inferenza cloud senza acquistare un secondo PC.

Introduzione

Uso Ollama Pro da diversi mesi per alimentare le mie sessioni OpenCode con modelli cloud. Il trucco è che anche con un abbonamento Pro, si viene rapidamente limitati dal rate limiting quando si avviano più agenti in parallelo. La soluzione evidente: un secondo abbonamento.

Ma allora è un dramma.

Ollama identifica ogni macchina tramite una chiave SSH unica — la famosa Device Key. Due istanze sullo stesso OS condividerebbero la stessa identità, ed è impossibile collegare due account Pro allo stesso dispositivo. E come immagini, non stavo per comprare un secondo laptop solo per quello.

La soluzione: imbrogliare. Far credere a Ollama che stia eseguendo su due macchine diverse, mentre in realtà condividono la stessa CPU, la stessa RAM e la stessa connessione di rete. Docker ci offrirà una bolla di isolamento perfetta.

Failed to generate image: PlantUML preprocessing failed: [From <input> (line 10) ]

@startuml




...
... ( skipping 130 lines )
...
skinparam StereotypeI {
  BackgroundColor white
  BorderColor black
}
skinparam StereotypeN {
  BackgroundColor white
  BorderColor black
}
skinparam UseCaseStereoType {
  FontColor black
  FontName Verdana
}
skinparam BoxPadding 10
skinparam DefaultFontSize 12

left to right direction

node "Macchina Fisica" {
  frame "Ollama Istanza A (Nativa)" as Native {
    database "Identità
^^^^^
 Syntax Error? (Assumed diagram type: class)

@startuml
!theme plain
skinparam BoxPadding 10
skinparam DefaultFontSize 12

left to right direction

node "Macchina Fisica" {
  frame "Ollama Istanza A (Nativa)" as Native {
    database "Identità
/usr/share/ollama/.ollama/id_ed25519" as KeyA
    portin "API
:11434" as PortA
  }

  frame "Istanza Ollama B (Docker)" as Docker {
    database "Identità\n~/ollama-b-data/id_ed25519" as KeyB
    portin "API\n:11435" as PortB
  }
}

cloud "Ollama Cloud" {
  actor "Conto Pro A
(email 1)" as AccountA
  actor "Conto Pro B\n(email 2)" as AccountB
}

KeyA --> AccountA : "Chiave SSH A"
KeyB --> AccountB : "Chiave SSH B"
PortA --> AccountA : "Richieste A"
PortB --> AccountB : "Richieste B"

note bottom of Docker
  Conteneur isolé : identité SSH distincte,
  port réseau distinct, volume persistant
end note
@enduml

Perché due volte la stessa cosa?

Prima di considerarmi malato mentale, lasciami spiegare il caso d’uso.

Con un unico abbonamento Pro, posso avviare un modello come`deepseek-v4-pro:cloud`in una sessione OpenCode. Il problema si presenta quando voglio due sessioni simultanee. Le quote di rate limiting fanno sì che la seconda sessione sia lenta o venga rifiutata completamente.

Con due abbonamenti Pro indipendenti :

  • Sessione OpenCode 1 → Conto Pro A`localhost:11434`)

  • Session OpenCode 2 → Compte Pro B (localhost:11435)

Ogni sessione ha il suo proprio quota, il suo proprio contesto e non ostacola l’altra. È del multi-processing umano.

Due abbonamenti Pro = due email diversi. La stessa carta bancaria funziona — il sistema di pagamento Ollama non blocca le sottoscrizioni multiple dallo stesso metodo di pagamento. L’ho verificato.

Il cuore del problema: la chiave del dispositivo

Quando installi Ollama, una coppia di chiavi SSH ed25519 viene generata nella directory di identità :

$ cat /usr/share/ollama/.ollama/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...

Questa chiave viene caricata sui server di Ollama durante il`ollama signin`. È lei che dice « questa macchina appartiene a un account Pro ». Se le tue due istanze condividono lo stesso file`id_ed25519`, condividono la stessa identità. Fine della partita.

La parade: dare alla nostra seconda istanza il suo proprio directory di identità, isolato in un volume Docker.

Preparazione — Passo dopo passo

Prerequisito

  • Un’installazione nativa funzionante di Ollama (script ufficiale`curl | sh`)

  • Docker installato e funzionante

  • Portainer o docker-compose per il deployment

  • Due account Ollama con due email distinti

Ho utilizzato la versione`0.20.2`— quella fornita dallo script ufficiale e dall’immagine Docker corrispondente.

Passo 1: Creare il Volume

Una semplice directory sull’host servirà da volume persistente per l’identità dell’istanza B:

mkdir -p ~/ollama-b-data

Questa cartella verrà montata nel contenitore Docker come`/root/.ollama`, lì dove Ollama memorizza le sue chiavi d’identità, la sua cronologia e i suoi modelli.

Passo 2: Avvia il contenitore Docker

# docker-compose.yml
services:
  ollama-instance-b:
    image: ollama/ollama:0.20.2
    container_name: ollama-instance-b
    ports:
      - "11435:11434"
    volumes:
      - /home/cheroliv/ollama-b-data:/root/.ollama
    environment:
      - OLLAMA_HOST=0.0.0.0
    restart: always

Cosa sta succedendo qui :

  • Il porto11435dell’host è mappato sul11434interno del contenitore. Così, l’istanza Docker ascolta su`:11435`senza conflitto con l’istanza nativa che occupa`:11434`.

  • Il volume`~/ollama-b-data`è montato su`/root/.ollama`— lì verrà memorizzata l’identità SSH.

  • `OLLAMA_HOST=0.0.0.0`permette al contenitore di accettare connessioni esterne.

Ho distribuito questa stack tramite Portainer, ma un semplice`docker compose up -d`funziona altrettanto bene.

Passo 3: Recupera la Chiave Pubblica

Il contenitore essendo vuoto al primo avvio, Ollama genera automaticamente una nuova coppia di chiavi SSH nel volume. Si recupera la chiave pubblica:

$ docker exec ollama-instance-b cat /root/.ollama/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDDQ+dvnfmuo49q5O8LOlvgZ39SKORFw47ry9k4H2jPc

Verifico che questa chiave sia diversa da quella dell’istanza nativa :

# Instance native
$ cat /usr/share/ollama/.ollama/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGyF...(différente)

# Instance Docker
$ cat ~/ollama-b-data/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDDQ...(différente)

Due chiavi distinte, due identità separate. Il gioco è fatto.

Se il tuo contenitore si riavvia, riutilizza le chiavi presenti nel volume. L’identità è persistente. Non perderai l’associazione con l’account Pro.

Passo 4 : Registra la Chiave su Ollama.com

Direzione https://ollama.com/settings/keys → Aggiungi chiave SSH. Si incolla la chiave pubblica dell’istanza Docker e si conferma.

Poi, si collega questa identità all’account Pro B:

$ docker exec -it ollama-instance-b ollama signin

Il navigatore si apre, ci si connette con l’email dell’account B e il token è associato alla chiave SSH del contenitore. Si verifica che tutto sia OK :

$ docker exec -it ollama-instance-b ollama signin
User: cherolivpro

Passo 5 : Testare con un Piccolo Modello Gratuito

Prima di valutare il prezzo di un abbonamento Pro, voglio essere certo che il tubo funzioni. Faccio un pull di un piccolo modello locale e gratuito per validare la connettività :

$ docker exec ollama-instance-b ollama pull qwen3:0.6b
pulling manifest
pulling 7f4030143c1c: 100% ▕██████████████████▏ 522 MB
success

$ curl -s http://localhost:11435/api/tags
{"models":[{"name":"qwen3:0.6b","model":"qwen3:0.6b",...}]}

Il porto`11435`risponde, il modello è servito. L’istanza B è vivente.

Una volta rassicurato, passo al pull del vero modello cloud Pro :

$ docker exec ollama-instance-b ollama pull deepseek-v4-pro:cloud
pulling manifest
pulling 31c3059e137e: 100% ▕██████████████████▏  344 B
success

344 byte per il manifesto di un modello cloud — normale, l’inferenza viene eseguita lato server, non in locale. Ed ecco il test definitivo :

$ curl -s http://localhost:11435/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"deepseek-v4-pro:cloud","messages":[{"role":"user","content":"Dis bonjour en une phrase courte."}]}'

{
  "id": "chatcmpl-480",
  "model": "deepseek-v4-pro",
  "choices": [{
    "message": { "content": "Bonjour !" },
    "finish_reason": "stop"
  }],
  "usage": { "total_tokens": 181 }
}

Buongiorno anche a te, istanza B.

La trappola dell’API `/v1/models

Ho perso 20 minuti su un dettaglio stupido. Quando ho configurato il provider`ollama-b`In OpenCode, niente appariva nel selettore dei modelli. Niente. Nulla.

La ragione? L’API`/v1/models`dell’istanza B restituiva`{"object":"list","data":null}`al posto di`{"object":"list","data":[]}`quand nessun modello era stato estratto. Il valore`null`faceva bloccare il parsing lato OpenCode, che non mostrava il provider.

La soluzione: dichiarare i modelli esplicitamente nella configurazione OpenCode anziché fare affidamento sulla scoperta dinamica.

~/.config/opencode/opencode.json
{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama (local)",
      "options": { "baseURL": "http://localhost:11434/v1" },
      "models": {
        "gemma4:e2b": { "name": "Gemma 4 E2B (local)" }
      }
    },
    "ollama-b": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama Instance B (Docker)",
      "options": { "baseURL": "http://localhost:11435/v1" },
      "models": {
        "qwen3:0.6b": { "name": "Qwen3 0.6B (B)" },
        "deepseek-v4-pro:cloud": { "name": "DeepSeek V4 Pro (B)" }
      }
    }
  }
}

Con questa dichiarazione esplicita, OpenCode vede immediatamente il provider B e i suoi modelli. Un riavvio di sessione, e il selettore`/models`visualizza le due istanze una accanto all’altra.

Se non vedi il tuo provider personalizzato in`/models`, non perdere tre ore a riavviare il tuo terminale. Dichiara i modelli manualmente in`opencode.json`— risolve il problema immediatamente.

Risultato: Due Sessioni, Due Conti, Zero Conflitto

Alla fine, posso lanciare due sessioni OpenCode contemporaneamente :

Session 1 → /models → Ollama (local) → deepseek-v4-pro:cloud → Compte A
Session 2 → /models → Ollama Instance B (Docker) → deepseek-v4-pro:cloud → Compte B

Ogni session ha il proprio quota, il proprio rate limit, e non si calpestano i piedi. Stessa macchina, stessa carta blu, due email diverse.

E il meglio? Il contenitore Docker è`restart: always`. Sopravvive ai riavvii del sistema senza intervento manuale.

Lezioni Apprese

  1. Docker isola tutto, persino l’identità— Un semplice bind mount di volume è sufficiente per dare a un contenitore il proprio set di chiavi SSH, rendendolo indistinguibile da una macchina fisica diversa agli occhi di Ollama.

  2. Due email, stessa CB— Ollama non blocca le sottoscrizioni multiple dallo stesso metodo di pagamento. Solo l’email deve essere distinta.

  3. Test gratuito prima di pagare — Un ollama pull qwen3:0.6b (modèle libre, 522 Mo) permet de valider toute la chaîne réseau sans débourser un centime. Vous validez le plomberie d’abord, vous activez le Pro ensuite.

  4. /v1/models` con data: null rompe OpenCode— Se configuri un provider personalizzato con`"models": {}`, OpenCode tenta di scoprire i modelli tramite l’API. Se l’API risponde`data: null`, il provider non appare. Dichiari i modelli esplicitamente.

  5. Due conti, è un multi-processing umanoUn account Pro = una sessione OpenCode attiva. Due account = due sessioni parallele. Per chi gestisce contemporaneamente diversi progetti Gradle, è un game changer.

Per Andare Oltre

Articolo pubblicato il 2026-05-08

Articoli correlati

HyperFrames-Gradle: Converti l'AsciiDoc in video MP4
31 May 2026
L'architettura « Plugin Indipendente + Radice Consumatore » : Perché i miei build Gradle si duplicano
14 May 2026
Il Knowledge Graph come motore di raccomandazione: come ho ucciso gli « articoli correlati » cronologici
12 May 2026