oskar/homelab-codex-ws
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity
homelab-codex-ws/kb/services/ollama-piha.md
oskar 4658089e21 fix(kb): przepiecie wszystkich odwolan wewnetrznych po migracji 
126 plikow (md, yaml, sh, py) odwolywalo sie do sciezek sprzed migracji.

  15  markdown-linkow [..](..) -> policzona sciezka WZGLEDNA wobec pliku
      odsylajacego (wczesniej czesc z nich byla repo-root-relative i nie
      rozwiazywala sie z katalogu, w ktorym lezala)
 200  odwolan tekstowych (backticki, proza, yaml, importy w kodzie)
      -> nowa sciezka repo-root-relative, zgodnie z konwencja repo
   5  linkow rodzenstwa (gole nazwy plikow, np. "](DEPLOY.md)") — dzialaly
      tylko w starym katalogu; przeliczone recznie

Objete m.in.: CLAUDE.md (scripts/onboard/README.md -> kb/runbooks/
node-onboarding-tool.md, docs/backlog.md -> kb/phases/backlog.md),
README.md, .claude/skills/, 20 session logow, kod jobow.

Ostatnie 5 odwolan pochodzi z tresci wciagnietej rebasem z origin/master
(session log 2026-07-31, override node-agenta na SOLARII, dwie pozycje
backlogu) — wskazywaly na docs/incidents/, docs/kb/modules/ i
services/narty27/README.md sprzed migracji.

Dodany wzajemny link miedzy kb/services/control-plane.md (stub kodu)
a kb/subsystems/control-plane.md (opis, deprecated) — dwa dokumenty o tym
samym systemie, latwe do pomylenia.

Weryfikacja na 790 plikach: 0 odwolan do starych sciezek,
0 martwych linkow markdown. Lint OKF: 190/190 plikow ZGODNE.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-04 16:58:46 +02:00

2.3 KiB
Raw Blame History

okf type visibility status updated links
0.1 service private active 2026-07-30
../runbooks/ollama-piha-deploy.md

ollama-piha

Local CPU Ollama on PIHA, serving exactly one purpose: the fallback embed backend for kb-query while SOLARIA (the GPU node, ~16 h/day powered off) sleeps. Model: bge-m3 — the same model as SOLARIA's Ollama, because query embeddings must live in the same vector space as the pgvector index (document_chunk.embedding VECTOR(1024)); a different/smaller model is not an option (module 5 phase 4 plan §2 decision 2).

Expected latency: bge-m3 embeds in ~207 ms on SOLARIA's GPU vs ~790 ms on x86 CPU; on the Pi 5 expect single seconds per query (plus model load, since the model is never resident — see below). Slower but alive beats fast but dead.

Design constraints

  • OLLAMA_KEEP_ALIVE=0 (pinned in compose): PIHA is the RAM-bound 8 GB box shared with Home Assistant. The model is unloaded immediately after every call — a transient ~1.5–2 GB spike per embed, ~100 MB idle daemon, never a resident cost.
  • mem_limit: 2560m (host override, hosts/piha/runtime/ollama-piha/): hard cgroup ceiling, plan §2 D2 starting value. The cgroup OOM killer restarts this container instead of the host OOM killer picking a victim (which could be Home Assistant). Confirm/trim after live calibration.
  • Bind: 127.0.0.1 + LAN_BIND_IP (192.168.31.5) only — kb-query calls it over the host LAN interface (same pattern as kb-query → kb-postgres:5433). Never 0.0.0.0, never a Tailscale bind, no public ingress.
  • Storage: Docker named volume ollama_piha_models (NVMe data-root), not a bind mount — the ollama image runs as in-container root and would break PIHA's uid pattern (host oskar=1004, containers uid 1000, setgid group pi) if it wrote to a shared bind directory.

Relation to kb-query

kb-query's router (services/kb-query/app/embed_router.py) health-checks SOLARIA with a ~30 s cache and only sends embeds here while SOLARIA is down. kb-query verifies at first use that this backend actually serves bge-m3 (/api/tags) and refuses to embed against a mismatched model. Configuration: EMBED_FALLBACK_URL=http://192.168.31.5:11434 in services/kb-query/.env. See kb/services/kb-query.md for the fallback verification plan (tests A/B/C).