1.9 KiB
Ollama-Pool
Der Pool verteilt vollständige Inferenzrequests auf bis zu 64 unabhängige Ollama-Instanzen. Er teilt kein einzelnes Modell über mehrere Hosts auf. Jeder verwendete Node lädt das jeweilige Modell lokal.
Ablauf
Embedding / AI-THINK Request
│
▼
Pool-Router
├─ Health/Modelprüfung
├─ Routing
├─ Per-Node Inflight-Limit
├─ Cooldown bei retryfähigem Fehler
└─ optionaler Failover
│
├── Ollama A
├── Ollama B
└── Ollama C
Retryfähig sind Netzwerkfehler, Timeouts, HTTP 408, HTTP 429, HTTP 5xx und ungültiges äußeres Ollama-JSON. Andere 4xx-Fehler werden nicht auf weitere Nodes gespiegelt.
OLLAMA_FAILOVER_ATTEMPTS=0 bedeutet maximal alle konfigurierten Nodes versuchen.
Modellkonsistenz
Mit OLLAMA_REQUIRE_SAME_MODEL_DIGEST=true werden die Digests aus /api/tags verglichen. Unterschiedliche Chat- oder Embedding-Digests machen den Pool inkompatibel, statt still unterschiedliche Ergebnisse zu erzeugen.
Sicherheit
Ollama sollte nicht öffentlich erreichbar sein. Nutze ein separates KI-Netz, Firewall-Regeln, VPN oder einen abgesicherten Reverse Proxy. Das Brain implementiert keine zusätzliche Authentifizierung gegenüber Ollama.
Gemeinsame Research/Ollama-Queue
SearXNG-Suchen, Web-Fetches und Ollama-Requests teilen den über BRAIN_RESEARCH_OLLAMA_MAX_INFLIGHT begrenzten Work-Limiter. Der Status weist aktive und wartende Operationen jetzt zusätzlich nach Typ aus (searxng.*, web.fetch, ollama.chat, ollama.embedding).
Ein Ollama-Aufruf belegt den gemeinsamen Work-Slot erst, nachdem ein kompatibler Ollama-Node tatsächlich reserviert werden konnte. Ein Request, der nur auf GPU-/Node-Kapazität wartet, blockiert deshalb keinen SearXNG- oder Fetch-Slot mehr. Die Node-Reservierung wird bei einem Queue-Fehler wieder freigegeben; Release-Funktionen sind idempotent.