Zwei Ollama Pro‑Abonnements auf derselben Maschine mit Docker kombinieren

Publié le 08 May 2026

Lesezeit : 14 minutes

Zwei Pro-Abonnements, ein einzelner Rechner, eine einzige Bankkarte und kein Netzwerkkonflikt. Wie Docker mir erlaubt hat, meine Cloud-Inferenzkapazität zu verdoppeln, ohne einen zweiten PC zu kaufen.

Einführung

Ich verwende Ollama Pro seit mehreren Monaten, um meine OpenCode-Sitzungen mit Cloud-Modellen zu betreiben. Das Problem ist, dass selbst mit einem Pro‑Abonnement man schnell an das rate limiting stößt, wenn man mehrere Agenten gleichzeitig ausführt. Die offensichtliche Lösung: ein zweites Abonnement.

Aber dort ist es das Drama.

Ollama identifiziert jede Maschine anhand eines eindeutigen SSH-Schlüssels — sein berühmter Device Key. Zwei Instanzen auf demselben OS hätten die gleiche Identität, und es wäre unmöglich, zwei Pro-Konten mit demselben Gerät zu verknüpfen. Und wie du wohl vermutest, wollte ich keinen zweiten Laptop nur dafür kaufen.

Die Lösung: betrügen. Ollama glauben zu lassen, dass es auf zwei unterschiedlichen Maschinen läuft, obwohl sie CPU, RAM und Netzwerkverbindung teilen. Docker wird uns eine perfekte Isolationsblase bieten.

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 "Physikalische Maschine" {
  frame "Ollama Instanz A (einheimisch)" as Native {
    database "Identität
^^^^^
 Syntax Error? (Assumed diagram type: class)

@startuml
!theme plain
skinparam BoxPadding 10
skinparam DefaultFontSize 12

left to right direction

node "Physikalische Maschine" {
  frame "Ollama Instanz A (einheimisch)" as Native {
    database "Identität
/usr/share/ollama/.ollama/id_ed25519" as KeyA
    portin "API\n:11434" as PortA
  }

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

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

KeyA --> AccountA : "SSH-Schlüssel A"
KeyB --> AccountB : "SSH-Schlüssel B"
PortA --> AccountA : "Anfragen A"
PortB --> AccountB : "Anfragen B"

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

Warum zweimal das Gleiche?

Bevor du mich als psychisch krank bezeichnest, lass mich dir den Anwendungsfall erklären.

Mit einem einzigen Pro-Abonnement kann ich ein Modell wie`deepseek-v4-pro:cloud`in einer OpenCode-Session. Das Problem tritt auf, wenn ich zwei gleichzeitige Sitzungen möchte. Die Rate-Limiting-Quoten führen dazu, dass die zweite Session stockt oder vollständig abgelehnt wird.

Mit zwei unabhängigen Pro-Abonnements :

  • Session OpenCode 1 → Pro-Konto A`localhost:11434`)

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

Jede Sitzung hat ihr eigenes Kontingent, ihren eigenen Kontext, und stört die andere nicht. Das ist menschliches Multi-Processing.

Zwei Pro-Abos = zwei verschiedene E-Mail-Adressen. Die gleiche Bankkarte funktioniert — das Ollama-Zahlungssystem blockiert keine mehreren Abonnements vom gleichen Zahlungsmittel. Ich habe es überprüft.

Das Herz des Problems: Der Geräteschlüssel

Wenn Sie Ollama installieren, wird ein SSH-ed25519-Schlüsselpaar im Identitätsverzeichnis generiert:

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

Dieser Schlüssel wird auf die Server von Ollama hochgeladen beim`ollama signin`. Es ist sie, die sagt « diese Maschine gehört zu diesem Pro-Konto ». Wenn deine beiden Instanzen die gleiche Datei teilen`id_ed25519`, sie teilen die gleiche Identität. Spiel vorbei.

Der Trick: unserer zweiten Instanz ihr eigenes Identitätsverzeichnis geben, isoliert in einem Docker-Volume.

Vorbereitung — Schritt für Schritt

Voraussetzung

  • Eine funktionierende native Ollama-Installation (offizielles Skript`curl | sh`)

  • Docker installiert und funktionsfähig

  • Portainer oder docker-compose für die Bereitstellung

  • Zwei Ollama-Konten mit zwei unterschiedlichen E-Mails

Ich habe die Version verwendet`0.20.2`— die vom offiziellen Skript bereitgestellte und das entsprechende Docker-Image.

Schritt 1: Das Volume erstellen

Ein einfaches Verzeichnis auf dem Host dient als persistentes Volume für die Identität der Instanz B:

mkdir -p ~/ollama-b-data

Dieser Ordner wird im Docker-Container wie`/root/.ollama`, wo Ollama seine Identitätsschlüssel, seinen Verlauf und seine Modelle speichert.

Schritt 2: Docker-Container starten

# 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

Was hier passiert:

  • Der Hafen11435des Hosts wird auf das11434des Containers. Damit lauscht die Docker-Instanz auf`:11435`ohne Konflikt mit der nativen Instanz, die besetzt`:11434`.

  • Das Volumen`~/ollama-b-data`ist auf montiert`/root/.ollama`— das ist der Ort, an dem die SSH-Identität gespeichert wird.

  • `OLLAMA_HOST=0.0.0.0`Ermöglicht dem Container, externe Verbindungen anzunehmen.

Ich habe diesen Stack via Portainer bereitgestellt, aber ein einfaches`docker compose up -d`funktioniert genauso gut.

Schritt 3: öffentlichen Schlüssel abrufen

Da der Container beim ersten Start leer ist, erzeugt Ollama automatisch ein neues SSH-Schlüsselpaar im Volume. Wir erhalten den öffentlichen Schlüssel :

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

Ich überprüfe, dass dieser Schlüssel unterschiedlich von dem der nativen Instanz :

# 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)

Zwei unterschiedliche Schlüssel, zwei getrennte Identitäten. Der Trick ist gemacht.

Wenn Ihr Container neu startet, verwendet er die im Volume vorhandenen Schlüssel. Die Identität ist persistent. Sie werden die Zuordnung zum Pro-Konto nicht verlieren.

Schritt 4: Schlüssel auf Ollama.com speichern

Gehe zu https://ollama.com/settings/keys → SSH-Schlüssel hinzufügen. Wir fügen den öffentlichen Schlüssel der Docker-Instanz ein und bestätigen.

Dann verknüpfen wir diese Identität mit dem Pro B-Konto :

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

Der Browser öffnet sich, man meldet sich mit der E‑Mail des Kontos B an, und das Token wird dem SSH‑Schlüssel des Containers zugeordnet. Wir überprüfen, dass alles in Ordnung ist :

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

Schritt 5: Testen mit einem kleinen kostenlosen Modell

Bevor ich den Preis eines Pro-Abonnements nenne, möchte ich sicher sein, dass der Schlauch funktioniert. Ich ziehe ein kleines lokales und kostenloses Modell, um die Konnektivität zu prüfen :

$ 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",...}]}

Der Hafen`11435`antwortet, das Modell wird bereitgestellt. Instanz B ist lebendig.

Sobald ich beruhigt bin, ziehe ich das eigentliche Cloud-Pro-Modell:

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

344 Bytes für das Manifest eines Cloud-Modells — normalerweise erfolgt die Inferenz auf der Serverseite, nicht lokal. Und hier ist der ultimative Test:

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

Hallo auch dir, Instanz B.

Die Falle der API `/v1/models

Ich habe 20 Minuten wegen eines dummen Details verloren. Als ich den Provider konfiguriert habe`ollama-b`In OpenCode wurde nichts im Modellauswahlfeld angezeigt. Nichts. Nix.

Der Grund? Die API`/v1/models`der Instanz B zurückgab`{"object":"list","data":null}`statt`{"object":"list","data":[]}`wenn kein Modell gepullt wurde. Der Wert`null`ließ das Parsing auf der OpenCode-Seite abstürzen, das den Provider nicht anzeigte.

Die Lösung: die Modelle explizit in der OpenCode-Konfiguration deklarieren, statt sich auf die dynamische Entdeckung zu verlassen.

~/.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)" }
      }
    }
  }
}

Mit dieser expliziten Deklaration erkennt OpenCode sofort den Provider B und seine Modelle. Ein Neustart der Sitzung, und der Selektor`/models`zeigt die beiden Instanzen nebeneinander.

Wenn Sie Ihren benutzerdefinierten Provider nicht in`/models`, verbringe nicht drei Stunden damit, dein Terminal neu zu starten. Deklariere die Vorlagen manuell in`opencode.json`— Das löst das Problem sofort.

Ergebnis: Zwei Sitzungen, Zwei Konten, Kein Konflikt

Zum Schluss kann ich zwei OpenCode-Sitzungen gleichzeitig starten :

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

Jede Sitzung hat ihr eigenes Kontingent, ihr eigenes Rate-Limit, und sie treten sich nicht auf die Füße. Gleicher Rechner, gleiche blaue Karte, zwei verschiedene E-Mails.

Und das Beste? Der Docker-Container ist`restart: always`. Er überlebt Systemneustarts ohne manuellen Eingriff.

Gelernte Lektionen

  1. Docker isoliert alles, sogar die Identität— Ein einfacher Volume-Bind-Mount reicht aus, um einem Container sein eigenes Set an SSH-Schlüsseln zu geben, wodurch er für Ollama von einer anderen physischen Maschine nicht unterscheidbar ist.

  2. Zwei E-Mails, gleiche CB— Ollama blockiert keine mehrfachen Abonnements von derselben Zahlungsmethode. Nur die E-Mail-Adresse muss unterschiedlich sein.

  3. Kostenlos testen, bevor du bezahlst — 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` mit data: null bricht OpenCode— Wenn Sie einen benutzerdefinierten Provider mit`"models": {}`, OpenCode versucht, die Modelle über die API zu entdecken. Wenn die API antwortet`data: null`, der Provider wird nicht angezeigt. Deklarieren Sie die Modelle ausdrücklich.

  5. Zwei Konten sind menschliches Multi-Processing.— Ein Pro-Konto = eine aktive OpenCode-Session. Zwei Konten = zwei parallele Sitzungen. Für jemanden, der gleichzeitig mehrere Gradle-Projekte jongliert, ist das ein Game-Changer.

Um weiter zu gehen

Artikel veröffentlicht am 2026-05-08

Verwandte Artikel

HyperFrames-Gradle: AsciiDoc in MP4-Video umwandeln
31 May 2026
Audit meines LLM-Verbrauchs: SQLite, OpenCode, Ollama Cloud und warum mein Pro-Abonnement den globalen Markt sprengt
18 May 2026
Die Architektur « Unabhängiges Plugin + Konsumenten‑Wurzel » : Warum duplizieren sich meine Gradle-Builds?
14 May 2026
Der Knowledge Graph als Empfehlungs-Engine: Wie ich die chronologisch « verwandten Artikel » getötet habe
12 May 2026