OSVauco/docs/HANDOFF-LOCAL-LLM-GITEA-MCP.md
chris e354051034
Some checks are pending
Check Python Version Consistency / Check Python Version (push) Waiting to run
chore: update docs/HANDOFF-LOCAL-LLM-GITEA-MCP.md via opax-mcp
2026-07-21 20:32:21 +00:00

195 lines
8.7 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# HANDOFF-LOKAL-LLM-GITEA-MCP.md
# EGEN HANDOFF UFRAVIKELIG STYRINGSDOKUMENT
# GJELDER FRA NÅ OG FREM TIL 100 % FERDIGSTILLELSE
## 0. STATUS OG KOMMANDO
Denne handoffen er det eneste autoritative arbeidsdokumentet for sporet "lokal LLM-fabrikk + OPAX-MCP + Gitea stabilisering + blueprinting til Gitea-VM".
---
## FREMDRIFT OPPDATERT 2026-07-21 22:30 CEST
### ✅ FASE 0 Lås situasjonen — FERDIG
- Handoff opprettet som eget dokument
- dev-snap/GPU-VM er aktiv verifikasjonsbase
- Gitea er eneste source of truth
- Lokal LLM-bane er primær retning
### ✅ FASE 1 Lokale modeller lever — FERDIG
- Ollama kjører på Gitea-CPU-VM (34.67.252.59:11434)
- Modeller tilgjengelig via MCP: `gemma3:4b`, `qwen2.5:3b`
- Modeller på dev-snap localhost: `qwen2.5:7b`, `gemma3:4b`, `llama3.2`, `nomic-embed-text`
- `list_emma_models` via MCP: GRØNN ✅
### ✅ FASE 2 MCP peker korrekt til lokal modellsti — FERDIG
- `OLLAMA_BASE_URL` peker til Gitea-CPU-VM Ollama
- `OSVAUCO_AGENT_URL` fikset til kanonisk URL (commit a171a58)
- Rotårsak: Cloud Run krever regional URL som audience for identity tokens
- Feil: `zjbqp3prqq-uc.a.run.app` → Riktig: `osvauco-agent-357036551735.us-central1.run.app`
- 5 filer oppdatert av Gemini-agent, build SUCCESS 55182237 (21. juli 18:38)
- opax-mcp revisjon: opax-mcp-00122-m4n
### ✅ FASE 3 Gitea read-only grønn — FERDIG
- Rotårsak: `GITEA_URL` var ikke satt i opax-mcp Cloud Run service
- Gitea kjører på: `http://34.67.252.59:3000` (Gitea-CPU-VM)
- Fix: `gcloud run services update opax-mcp --update-env-vars GITEA_URL=http://34.67.252.59:3000`
- opax-mcp revisjon etter fix: opax-mcp-00123-g7d
- Alle 4 read-only tools GRØNNE:
-`list_commits`
-`get_file`
-`get_file_content`
-`list_repo_files`
- `get_connector_status`: `gitea_status: online`
### ✅ FASE 4 Hel kjede samtidig grønn — FERDIG 2026-07-21 20:57 CEST
Full smoke test kjørt og alle tools grønne samtidig:
| Tool | Status | Resultat |
|---|---|---|
| `get_connector_status` | ✅ | live, gitea online, 37 tools |
| `get_health` | ✅ | OK |
| `get_build_status` | ✅ | Siste build SUCCESS 55182237 |
| `describe_service` | ✅ | osvauco-agent-00695-8lk Ready |
| `list_workspace_users` | ✅ | 3 brukere returnert |
| `list_emma_models` | ✅ | gemma3:4b, qwen2.5:3b |
| `list_commits` | ✅ | Siste commits returnert |
| `list_repo_files` | ✅ | Rotmappe listert |
Ingen regresjon på tidligere grønne tools. Hele kjeden er verifisert i samme runde.
### ✅ FASE 5 Frys blueprint på dev-snap — FERDIG
- Blueprint dokumentert i `docs/BLUEPRINT-DEV-SNAP.md`
- Full env-var, modell- og serviceoversikt frosset
- Avklart at nåværende `OLLAMA_BASE_URL` og `GITEA_URL` i praksis har pekt mot dev-snap i aktiv verifikasjonsperiode
- Gitea-CPU-VM står fast som permanent målmaskin
### ⏳ 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.
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)
- 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) — 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: **MAX_LOADED_MODELS=2, begge Forever**
- ⏳ optimal parameterkombinasjon dokumentert
- ⏳ full Emma-loop latency akseptert
- ⏳ 2-timers belastningstest bestått uten OOM og uten swap
---
## FASE 6.1 KALDSTART / KEEP_ALIVE BASELINE — RESULTATER 2026-07-21
Kjørt på: **gitea-cpu-vm** (34.67.252.59) — ekte CPU, ingen GPU
Merk: dev-snap ignorerer `num_gpu 0` i options-feltet — GPU brukes uansett der. Alle tester kjørt direkte på gitea-cpu-vm.
### Kaldstart-målinger
| Test | Modell | load_s | eval_s | tok/s | Processor | Status |
|---|---|---|---|---|---|---|
| 1.1 Ekte kaldstart | gemma3:4b | **117.69s** | 1.02s | 4.9 | 100% CPU | ✅ PASS |
| 1.2 Ekte kaldstart | qwen2.5:3b | **71.13s** | 1.73s | 6.4 | 100% CPU | ✅ PASS |
| 1.3 keep_alive=-1 load | gemma3:4b | 76.93s (kald→varm) | — | 5.9 | 100% CPU | ✅ PASS |
### keep_alive=-1 verifikasjon
| Test | Resultat | Status |
|---|---|---|
| 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 |
### Konklusjoner Fase 6.1
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
---
## 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
---
## ÅPNE PUNKTER SOM MÅ LØSES FØR BLUEPRINT
- `GITEA_URL` satt runtime via `gcloud run services update`**må også legges permanent inn i `opax-mcp.yaml` i repo og rebuildes**
- `git.vauco.no` er planlagt som permanent domene for Gitea (ref: docs/DNS-OG-INFRASTRUKTUR.md) — erstatter IP når DNS er oppe
- Gitea-commits er ikke GPG-signert — vurder om dette skal fikses
## FASTE SANNHETER (uendret)
- Gitea er source of truth
- Lokale modeller er hovedretning
- dev-snap/GPU-VM er nåværende verifikasjonsflate
- Gitea-VM (34.67.252.59) er planlagt permanent målmaskin
- Denne handoffen overstyrer alt annet
## DEFINITION OF DONE
- ✅ Lokale modeller lever og kan brukes lokalt
- ✅ OPAX-MCP bruker lokal modellbackend korrekt
-`list_emma_models` er grønn
- ✅ Gitea read-only tools er grønne
- ✅ GCP/Workspace-kjernen er fortsatt grønn
- ⚠️ Konfigurasjon konsolidert — delvis (GITEA_URL må inn i repo)
- ⏳ Ingen skjult API-/agentavhengighet som hovedbane — ikke verifisert
- ✅ dev-snap-oppsettet dokumentert godt nok til blueprinting — FASE 5 FERDIG
- ⏳ CPU-optimalisering verifisert på Gitea-VM — FASE 6 pågår
## OPPDATERINGSLOGG
| Dato | Fase | Handling |
|---|---|---|
| 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 |
| 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 |