oskar/homelab-codex-ws
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity
homelab-codex-ws/kb/runbooks/ollama-piha-deploy.md
oskar 3292ab54e2 feat(kb): SPLIT service+runbook — 10 serwisow -> 20 dokumentow 
Wzorzec mechaniczny: sekcje deploy/verify/install/testy wycinane do
kb/runbooks/<serwis>-*.md, reszta zostaje dokumentem type: service.
Wzajemne `links` w obie strony. Tresc sekcji nietknieta — przenoszone
doslownie, dodany wylacznie naglowek H1 nowego runbooka.

kb-query, paperless-worker, planner-agent, ha-diag-agent, ollama-piha,
narty27, home-assistant, ha-mcp, job-gmail-header-backfill, job-mail-body-ingest.

Weryfikacja: dla kazdego pliku multizbior niepustych linii
(main + runbook) == oryginal z HEAD. Zero zgubionych, zero dodanych.

Recon szacowal 13 splitow service+runbook; faktycznie 2-typowych jest 10,
pozostale 5 (paperless, nextcloud, gokapi, fleet-prometheus, deploy-runner)
sa 3-typowe i ida osobno jako splity wielotypowe.

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

2.3 KiB
Raw Blame History

okf type visibility status updated links
0.1 runbook private active 2026-07-30
../services/ollama-piha.md

ollama-piha — deploy i kalibracja

Deploy (PIHA, master, after merge)

cd ~/homelab-codex-ws && git pull
cp services/ollama-piha/env.example services/ollama-piha/.env   # LAN_BIND_IP
docker compose -f services/ollama-piha/docker-compose.yml \
  -f hosts/piha/runtime/ollama-piha/docker-compose.override.yml \
  --env-file services/ollama-piha/.env up -d

Then pull the model — this does NOT happen automatically:

docker exec ollama-piha ollama pull bge-m3

Verify:

services/ollama-piha/healthcheck.sh          # checks container + API + bge-m3 present
time curl -s http://127.0.0.1:11434/api/embeddings \
  -d '{"model":"bge-m3","prompt":"test kalibracyjny"}' | head -c 80

(deploy-node.sh on PIHA also picks this service up from hosts/piha/services.yaml once .env exists — the ollama pull bge-m3 step stays manual either way.)

Calibration (plan §5 step 4 — gate, not formality)

Before trusting the fallback under load, on live PIHA at a normal (not night-quiet) hour: run a few embeds as above while watching docker stats ollama-piha, note peak RAM and wall time. Verdict per plan §5 step 5: keep as default fallback / tune mem_limit / fall back to explicit 503 degradation.

Calibration status: measured 2026-07-27 — verdict GO (live PIHA under normal load, 3 consecutive /api/embeddings calls after ollama pull bge-m3; full protocol in docs/sessions/2026-07-27-kb-f4-fallback.md §4):

  • Latency: 5.25 s (cold start) / 4.41 s / 4.16 s — single seconds as expected, no warm-up between calls by design (OLLAMA_KEEP_ALIVE=0 releases the model after every request, ollama ps shows nothing resident in between).
  • RAM: idle ~66 MiB, burst peak ~983 MiB (docker stats sampled at 0.3 s) — well inside the 2560m ceiling; host available never dropped below ~1.3 GiB.
  • Kept as default fallback (no feature flag). The measurement was taken against the same container configuration this repo deploys (image, OLLAMA_KEEP_ALIVE=0, mem_limit: 2560m), so it carries over; only the model storage differed (bind mount then, named volume now), which does not affect RAM/latency.