# 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

```text
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.