Files
nanobot-runtime/projects/devops/state.md
2026-09-14 07:36:16 +02:00

3.0 KiB
Raw Blame History

timestamp
timestamp
draft

Project devops

Kde to je

  • Projekt založen jako volný prostor pro admin/root poznámky o infrastruktuře a provozu.
  • LibreChat: běží jako podman kontejnery; jako Code Interpreter sandbox vybrán LibreCodeInterpreter (nsjail, 3 kontejnery). Research hotový (2026-09-13), rozhodnutí o nasazení (sdílená Docker VM vs dedikovaná Proxmox VM) ještě nepadlo.
  • Ollama na nvidia.hell: po incidentech 12.13. 9. 2026 zaevidován root cause pádů — kauzální řetěz: ollama rozhoduje load podle VRAM ne volné RAM + vypíná mmap (podmínka na 9,5 GiB stroji nesplnitelná nikdy, regrese od 2026-06-05) + PLE host buffer u gemma4 + přerušený load leakuje napinovanou host paměť (neviditelná pro ps/nvidia-smi/cgtop, detekce jen nr_foll_pin delta v /proc/vmstat), uvolní jen reboot (rmmod driveru ověřeně NE). Cgroup pojistka (MemoryMax=6G, MemorySwapMax=0, bez MemoryHigh) ověřena zátěžovým testem: 240/240 SSH heartbeatů, load 3,41 vs 81 při incidentu. Skutečný zdroj zátěže = nanobot.hell (dávky přes ~10 modelů + embedding), LibreChat jen zesilovač. Reporty v artifacts/2026-09-13_ollama-nvidia-full-report.md (ucelený, s kuchařkou pro triáž) a artifacts/2026-09-13_ollama-nvidia-negative-findings.md (negativní zjištění), shrnutí v memory.md 2026-09-14. Zavržené cesty: earlyoom i jakákoli externí kill varianta, MemoryHigh pod MemoryMax, navýšení RAM (headroom konstanta 7,5 GiB), limit počtu modelů, OLLAMA_LOAD_TIMEOUT, upgrade ollamy, mmap override (neexistuje), ballooning (balloon: 0 + pevná paměť), rmmod jako remedy.

Co dál

  • Rozhodnout umístění LibreCodeInterpreter (AI stack VM vs dedikovaná VM) a nasadit — viz memory.md 2026-09-13 pro capability požadavky (SYS_ADMIN, NET_ADMIN, apparmor:unconfined).
  • Ollama open body dle priority (report §11): (1) zastavit dávky z nanobot.hellneplatí jako provozní riziko (dávky byly testovací tool-calling requesty, běžný provoz nanobot nesahá na lokální modely); (2) retest cgroup pojistky bez MemoryHigh (odblokováno rebootem; kritéria: heartbeat bez výpadku, MemAvailable > 2 GiB, dmesg constraint=MEMCG); (3) doladit MemoryMax podle memory.peak; (4) rozhodnout osud gemma4 (PLE ~5,9 GiB host bufferu, na 9,5 GiB stroji nikdy); (5) OLLAMA_KV_CACHE_TYPE=q4_0 zrušit nebo nepoužívat granite-code; (6) drobnosti: apt purge earlyoom (rc), llama-server --log-verbosity 4, zabbix Hostname=Zabbix server → nvidia, LibreChat titleConvo duplicitní requesty, otázka real-time monitoringu (hlídač co killuje = zavržená cesta).
  • Návrh k rozhodnutí: izolovat embedding pipeline (wiki skill) ze ollamy na statický llama.cpp server (llama-server --embeddings --pooling last, stejný GGUF, /v1/embeddings) — obejde load path, kde vzniká leak; po ní nanobot nezůstane na lokální ollamě žádný provoz krom cloud proxy. Vyžaduje: úprava wiki_embed.py klienta, config.yaml endpoint, reindex --full.
  • Uživatel bude psát poznámky; podle obsahu doladit strukturu projektu.