nanobot: 2026-09-13 21:38:42

projects/ai/memory.md

@@ -87,3 +87,14 @@ https://www.librechat.ai/docs/local/docker
 5. Čas v summary skriptu je wall-clock celého běhu včetně prvního načtení modelu; `load_duration` z API se vypisuje zvlášť (load>0 jen při prvním requestu).
 
 **Doporučení pro agenta / tool use:** granite4.1:8b (nejlepší balance), ministral-3 (nejrychlejší), qwen3 (spolehlivost, pomalejší).
+- 2026-09-13: Cena/výkon srovnání plných desítek + rozhodnutí testovat finální kandidáty doplněk: uživatel si vybral tři finalisty (lfm2.5-thinking, granite4.1:8b, ministral-3), lfm vypadá nejlépe (nejmenší velikost + rozumný čas). Domluveno: na finalisty pustím **náročnější sadu testů** pro lepší rozlišení — vstupní 10 scénářů už je plní neseparuje (všichni 10/10).
+- 2026-09-13: Uživatelova zkušenost: **Ollama na nvidia.hell je výrazně nestabilní** — padá, když něco nezvládne (neznámý request, špatně zvládnutý model/template) nebo když přetíží stroj (paměť). Pro uživatele **v praxi nepoužitelné**; je z toho dost zklamaný.
+
+Koreluje s dřívějšími nálezy z tool-call testů (2026-09-12/13), kdy nestabilita nebyla ojedinělá, ale systémový vzorec:
+- Memory watchdog na nvidia.hell opakovaně zabíjel llama-server (`Remote end closed connection`) — sejmul ho aya-expanse (hned na S1), qwen3.5 (na S10 s 5 nástroji), dřív i gemma4/gemma4:e4b (9.6 GB).
+- Více nástrojů v promptu = vyšší paměťové nároky = watchdog kill. Pády nejsou náhodné — spouští je kombinace velkého modelu + většího kontextu.
+- phi4-mini-reasoning: reasoning CoT tolik zpomalí, že ~3 min bez odpovědi — Ollama se nezachytí ani graciozně.
+- gemini-3-flash-preview:cloud vracel HTTP 410 Gone — mrtvý cloud pointer v instanci.
+
+Závěr uživatele: současný stav (modely pod 10 GB na této GPU instanci) není použitelný pro reálný provoz, jen pro testy. Otevřené otázky pro případné hledání řešení: stabilizace Ollama serveru (limit paměti per model, OLLAMA_MAX_LOADED_MODELS, auto-restart), alternativní runtime (llama.cpp server přímo, vLLM), nebo kapacitnější hardware.
+- 2026-09-13: Research alternativ k Ollama (uživatel: nestabilita na nvidia.hell je v praxi nepoužitelná). Root cause potvrzen: watchdog killy = OOM na RAM, llama-server je stejně llama.cpp — problém je Ollamina heuristika offloadingu/kontextu, ne engine sám. Alternativy ověřeny z více zdrojů (codersera, local-llm.net, inventivehq, r/LocalLLaMA thread k postu „Friends Don't Let Friends Use Ollama", duben 2026): (1) llama.cpp llama-server + llama-swap — konsensus komunity, OpenAI-compatible API, hot-swap modelů, explicitní -c/-ngl kontrola → doporučeno uživateli; (2) vLLM — pro multi-user serving, na RTX 4060 tight (safetensors, KV cache overhead), odloženo; (3) LM Studio/Jan — zavrhnuté (Electron, closed source); (4) zůstat na Ollama + hardening (OLLAMA_MAX_LOADED_MODELS=1, systemd Restart/MemoryMax) — fallback. Čeká se na rozhodnutí uživatele, nabídka přípravy llama-swap yaml + systemd unit + litellm wiring.