chore: update docs/HANDOFF-LOCAL-LLM-GITEA-MCP.md via opax-mcp
Some checks are pending
Check Python Version Consistency / Check Python Version (push) Waiting to run

This commit is contained in:
chris 2026-07-21 20:32:21 +00:00
parent 773482cfa3
commit e354051034

View File

@ -7,7 +7,7 @@ Denne handoffen er det eneste autoritative arbeidsdokumentet for sporet "lokal L
---
## FREMDRIFT OPPDATERT 2026-07-21 22:22 CEST
## FREMDRIFT OPPDATERT 2026-07-21 22:30 CEST
### ✅ FASE 0 Lås situasjonen — FERDIG
- Handoff opprettet som eget dokument
@ -66,26 +66,23 @@ Ingen regresjon på tidligere grønne tools. Hele kjeden er verifisert i samme r
### ⏳ FASE 6 CPU-optimalisering før permanent migrering — PÅGÅR
Formål: Verifisere at Emma-arkitekturen fungerer akseptabelt på Gitea-CPU-VM før permanent cutover fra dev-snap.
Bakgrunn:
Research og testprotokoll viser at problemet ikke bare er VM-spesifikasjoner, men Emma-loopen selv. Emma MCoT gjør typisk 46 sekvensielle LLM-kall per brukerturn (embed → think → choose_action → execute_action, evt. compress). På gitea-cpu-vm er kaldstart målt til ca. 4879 sekunder per modell, noe som gjør resident modellstrategi og keep_alive kritisk.
Bekreftede regler:
- `OLLAMA_KEEP_ALIVE=-1` er obligatorisk baseline
- resident modellstrategi må avklares eksplisitt (1 varm modell vs 2 varme modeller)
Bekreftede regler (oppdatert etter testing):
- `OLLAMA_KEEP_ALIVE=-1` er obligatorisk baseline ✅ BEVIST
- `OLLAMA_MAX_LOADED_MODELS=2` er valgt strategi ✅ LÅST
- `qwen2.5:7b` er ikke baseline-kandidat på gitea-cpu-vm
- CPU-optimalisering utføres direkte på gitea-cpu-vm (ikke dev-snap, da `num_gpu 0` ignoreres av Ollama der)
- CPU-optimalisering utføres direkte på gitea-cpu-vm (ikke dev-snap)
- alle resultater føres tilbake i OPPDATERINGSLOGG samme dag
Testrekkefølge:
1. ✅ Kaldstart / keep_alive baseline — FERDIG 2026-07-21
2. ⏳ Resident modell-strategi (1 vs 2 modeller)
2. ✅ Resident modell-strategi (1 vs 2 modeller) — FERDIG 2026-07-21
3. ⏳ Parameter-matrise (`num_ctx`, `num_batch`, `OLLAMA_NUM_THREADS`)
4. ⏳ Full Emma MCoT end-to-end
5. ⏳ Belastningstest med samtidig Gitea + agent-last
Exit-kriterium:
- ✅ keep_alive-strategi bevist effektiv
- ⏳ resident modellvalg låst
- ✅ resident modellvalg låst: **MAX_LOADED_MODELS=2, begge Forever**
- ⏳ optimal parameterkombinasjon dokumentert
- ⏳ full Emma-loop latency akseptert
- ⏳ 2-timers belastningstest bestått uten OOM og uten swap
@ -112,28 +109,55 @@ Merk: dev-snap ignorerer `num_gpu 0` i options-feltet — GPU brukes uansett der
| 1.4 UNTIL=Forever | gemma3:4b: **Forever** ✅ / qwen2.5:3b: ~2 min ⚠️ (ikke satt keep_alive=-1) | ✅ PASS |
| 1.5 Varme kall ×5 | load_s: 0.9841.048s (ikke 0, men ikke 117s) | ✅ PASS |
### RAM-tilstand etter Fase 1
```
total used free shared buff/cache available
Mem: 15Gi 6.8Gi 3.8Gi 492Ki 5.3Gi 8.8Gi
Swap: 0B 0B 0B
NAME SIZE PROCESSOR UNTIL
gemma3:4b 2.9 GB 100% CPU Forever
qwen2.5:3b 2.2 GB 100% CPU ~1 min (utløper)
```
**RAM med 2 modeller lastet:** 6.8 GB used / 8.8 GB available — god margin, ingen swap ✅
### Konklusjoner Fase 6.1
1. **Kaldstart-range bekreftet:** gemma3:4b = 117s, qwen2.5:3b = 71s (verre enn antatt 4879s for gemma3)
1. **Kaldstart-range bekreftet:** gemma3:4b = 117s, qwen2.5:3b = 71s
2. **`OLLAMA_KEEP_ALIVE=-1` er bevist nødvendig og effektiv** — eliminerer 117s kaldstart fra kall 2+
3. **Varme kall koster ~1s load + ~0.9s eval = ~2s per kall** — 46 kall per Emma-turn = 812s ren LLM-tid
4. **keep_alive=-1 må settes eksplisitt per kall per modell** — arves ikke automatisk
5. **`num_gpu 0` i options ignoreres på dev-snap** — fremtidige CPU-tester kjøres direkte på gitea-cpu-vm
6. **RAM-margin er god med 2 modeller:** 5.1 GB (2.9+2.2) i Ollama + 8.8 GB available — ingen OOM-risiko ved normal last
---
## FASE 6.2 RESIDENT MODELL-STRATEGI — RESULTATER 2026-07-21
Kjørt på: **gitea-cpu-vm** (34.67.252.59)
### Målinger
| Test | Konfigurasjon | Resultat | Status |
|---|---|---|---|
| 2.1 Begge modeller uten MAX-begrensning | Default (MAX=ubegrenset) | Begge lastet: gemma3:4b + qwen2.5:3b i RAM, Swap=0 | ✅ PASS |
| 2.3 Modellbytte med MAX=1 | OLLAMA_MAX_LOADED_MODELS=1 | gemma3:4b reload: 9.31s / qwen2.5:3b reload: 5.6s — kun én modell i `ollama ps` | ✅ PASS |
| 2.4 Begge modeller med MAX=2 + KEEP_ALIVE=-1 | OLLAMA_MAX_LOADED_MODELS=2 + OLLAMA_KEEP_ALIVE=-1 | Begge Forever, 6.8 GB used, 8.9 GB available, Swap=0 | ✅ PASS |
### RAM-tilstand etter Fase 6.2 (final konfigurasjon)
```
total used free shared buff/cache available
Mem: 15Gi 6.8Gi 3.7Gi 492Ki 5.4Gi 8.9Gi
Swap: 0B 0B 0B
NAME SIZE PROCESSOR UNTIL
qwen2.5:3b 2.2 GB 100% CPU Forever
gemma3:4b 2.9 GB 100% CPU Forever
```
### ✅ RESIDENT MODELL-STRATEGI LÅST
**Valgt konfigurasjon i `/etc/systemd/system/ollama.service.d/max-models.conf`:**
```
[Service]
Environment="OLLAMA_MAX_LOADED_MODELS=2"
Environment="OLLAMA_KEEP_ALIVE=-1"
```
**Begrunnelse:**
- 2 modeller i RAM bruker 5.1 GB (2.9+2.2) — 8.9 GB gjenværende available er trygg margin
- Bytte-kostnad med MAX=1: 59s per bytte × 46 kall per Emma-turn = 2054s ekstra latency per turn
- Med MAX=2 og begge Forever: 0s bytte-overhead — 812s raskere per Emma-turn
- Swap=0 bekreftet under alle testscenarier
- `OLLAMA_KEEP_ALIVE=-1` satt på systemd-nivå eliminerer behov for per-kall keep_alive-parameter
---
@ -166,4 +190,5 @@ qwen2.5:3b 2.2 GB 100% CPU ~1 min (utløper)
| 2026-07-21 | FASE 4 | Full smoke test grønn, alle 8 tools OK |
| 2026-07-21 | FASE 5 | Blueprint frosset, FASE 5 lukket |
| 2026-07-21 | FASE 6 | FASE 6 åpnet — CPU-optimalisering neste |
| 2026-07-21 | FASE 6.1 | Kaldstart/keep_alive baseline fullført: gemma3:4b=117s, qwen2.5:3b=71s, varme kall ~1s, keep_alive=-1 bevist effektiv, RAM OK |
| 2026-07-21 | FASE 6.1 | Kaldstart/keep_alive baseline fullført: gemma3:4b=117s, qwen2.5:3b=71s, varme kall ~1s, keep_alive=-1 bevist effektiv |
| 2026-07-21 | FASE 6.2 | Resident modell-strategi låst: MAX_LOADED_MODELS=2 + KEEP_ALIVE=-1 på systemd-nivå, begge modeller Forever, RAM 6.8/15 GB, Swap=0 |