OSVauco/docs/HANDOFF-LOCAL-LLM-GITEA-MCP.md

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-22 03:55 CEST

✅ FASE 0–5 — FERDIG

✅ FASE 6 – CPU-optimalisering — FERDIG

✅ FASE 6-TILLEGG – Boot-warming — FERDIG

✅ DNS – NS-bytte utført — FERDIG 2026-07-21 23:44 CEST

✅ OPAX-MCP – GITEA_URL permanent + deploy — FERDIG 2026-07-21 23:53 CEST

✅ SMOKE-TEST – Alle 37 tools — FERDIG 2026-07-22 00:25 CEST

✅ FASE 6.5 – VM-oppgradering + modellarkitektur — VERIFISERT 2026-07-22

🟡 FASE 7 – 14B-validering utført, arkitektur justeres — PÅGÅR

⏳ GPG-SIGNERING – Commits verified — PÅGÅR

⏳ FASE 8 – Backup / snapshot-strategi — PLANLAGT

---

FASE 6.5 — OPPDATERT LOKAL LLM-STACK (2026-07-22)

Bekreftet drift

• gitea-cpu-vm er oppe i us-central1-b
• VM kjører nå på e2-highmem-4 (4 vCPU / 32 GB RAM)
• Statisk IP beholdt: 34.170.51.84
• Gitea svarer på port 3000
• Ollama svarer på port 11434

Bekreftet ressursstatus

• Disk: ca. 99 GB total
• Ny modellstack etter 14B-nedlasting: ca. 29 GB modeller totalt
• Systemet har fortsatt god diskmargin, men CPU er nå den reelle begrensningen

Faktisk modeller lokalt per 2026-07-22

• gemma3:4b
• gemma3:12b
• qwen2.5:3b
• qwen2.5:14b
• qwen2.5-coder:14b

Verifisert ytelsesfunn

• gemma3:4b holder ca. 4.9–5.0 tok/s varm og fungerer interaktivt
• qwen2.5:14b målte ca. 1.4 tok/s varm på faktisk VM
• Kort prompt ga ca. 249s eval-duration på varm modell ved stream: false
• Konklusjon: qwen2.5:14b er for treg som standard interaktiv agent på nåværende CPU-VM

Revidert anbefalt modellarkitektur

• Frontmodell: gemma3:4b
  • Brukes for raske svar, enkel resonnering og billig default
• Lett tool-/agentmodell: qwen2.5:3b
  • Brukes for tool calling som må være responsivt nok i praksis
• Neste kandidat for mellomlag: qwen2.5:7b
  • Skal testes som mulig erstatning for qwen2.5:14b som standard Qwen-lag
• Kode-/repo batch-modell: qwen2.5-coder:14b
  • Beholdes for repo-forståelse, patching, refaktorering og tyngre asynkrone kodeoppgaver
• Ikke anbefalt nå: qwen2.5:14b som interaktiv standardmodell
  • For treg på CPU til primær bruk
• Ikke anbefalt nå: gemma3:27b
  • Uaktuell før videre CPU-/ytelsesløft; forventes tregere enn 14B-laget

Operativ ruting

1. Start med gemma3:4b
2. Eskaler til qwen2.5:3b når oppgaven trenger tools og respons fortsatt må være praktisk
3. Bruk qwen2.5-coder:14b kun når oppgaven er tydelig kode-/repo-orientert og kan tåle høy latency
4. Test qwen2.5:7b som mulig nytt mellomlag før eventuell fjerning av qwen2.5:14b
5. Ikke last ned gemma3:27b nå

Viktige vurderinger

• CPU, ikke RAM eller disk, er nå flaskehalsen
• qwen2.5:14b ga svak praktisk interaktiv ytelse til tross for vellykket installasjon
• qwen2.5-coder:14b beholdes foreløpig fordi use casen er batch/dev-assistanse, ikke chat-latency
• qwen2.5:7b er neste rasjonelle kandidat for bedre balanse mellom kvalitet og fart
• qwen2.5-coder:32b og gemma3:27b utsettes

Neste konkrete steg

• Test / vurder:
  • ollama rm qwen2.5:14b
  • ollama pull qwen2.5:7b
• Test deretter:
  • enkel chat-latency
  • tool calling
  • RAM- og diskpåvirkning
  • om qwen2.5:7b kan overta rollen som standard Qwen-lag

# Foreslått neste endring
ollama rm qwen2.5:14b
ollama pull qwen2.5:7b

# Bekreft etterpå
curl http://localhost:11434/api/tags
free -h
du -sh /usr/share/ollama/.ollama/models

---

LÅST SYSTEMKONFIGURASJON – GITEA-CPU-VM (komplett)

VM-spesifikasjon (oppdatert 2026-07-22)

• Maskintype: e2-highmem-4 (4 vCPU / 32 GB RAM)
• Zone: us-central1-b
• Statisk IP: 34.170.51.84

Systemd-dropins

override.conf    — OLLAMA_HOST=0.0.0.0:11434
max-models.conf  — MAX_LOADED_MODELS=2 + KEEP_ALIVE=-1
warmup.conf      — ExecStartPost=/usr/local/bin/ollama-warmup.sh

Operative parametere for Emma-kall

num_ctx            = 2048
num_batch          = 256
OLLAMA_NUM_THREADS = ikke satt (autodetect)

Ytelsesbudsjett per Emma-turn (varm)

3-kall turn:   ~23.5s
5-kall turn:   ~42.5s
Boot-penalty:  ~0s (warmup-skript)
Tok/s:         4.9–5.0 (gemma3:4b)

Gitea-dataplassering

/opt/gitea/data/repositories/chris/OSVauco.git/   ← Bare repo
/opt/gitea/data/gitea.db                          ← SQLite metadata
/opt/gitea/data/custom/conf/app.ini               ← Konfig

---

OPAX-MCP KONFIGURASJON – LÅST

Variabel	Verdi
GITEA_URL	http://34.67.252.59:3000
OLLAMA_BASE_URL	http://34.67.252.59:11434
EMMA_MODEL	gemma3:4b
EMMA_FAST_MODEL	gemma3:4b
EMMA_LIGHT_MODEL	qwen2.5:3b
OSVAUCO_AGENT_URL	https://osvauco-agent-357036551735.us-central1.run.app

Deploy verifisert: get_connector_status → live, gitea: online, tool_count: 37

---

DNS – FULLFØRT 2026-07-21

NS-bytte: Proisp → Google Cloud DNS 23:44 CEST

Record	Type	Verdi
vauco.no.	A	34.98.77.173 (LB)
www.vauco.no.	A	34.98.77.173 (LB)
opax.vauco.no.	A	34.98.77.173 (LB)
git.vauco.no.	A	34.67.252.59
MX / SPF / DKIM / DMARC	TXT/MX	Google Workspace komplett

---

SMOKE-TEST – FULLFØRT 2026-07-22 00:25 CEST

Kategori	Status	Merknad
✅ Ollama / Emma	Grønn	gemma3:4b varm, 14s respons
✅ Connector	Grønn	live, 37 tools
✅ Gitea read + write	Grønn	Commits og push OK
✅ GCP / Cloud Run	Grønn	osvauco-agent Ready, rev 00695
✅ Workspace / Gmail	Grønn	3 brukere, kalender, e-post OK
✅ Terminal / Billing	Grønn	Billing dramatisk ned fra 5. juli
🟡 Jason	Grønn m/merknad	Kjører gemini-2.5-flash (ikke Pro)

Smoke-test observasjoner

• qwen2.5:3b har tool-calling capabilities — gemma3:4b har det ikke
• GCE list_instances tom — ikke kritisk, Cloud Console på mobil
• Jason mode-parameter gir 400 — bruk kun prompt
• GPG-signering pågår — commits fortsatt unverified

---

FASE 7 – LOKAL HJERNE / DERIVAT-MODELL (pågår)

Mål

Erstatte stor API-modell (Gemini/Claude/Perplexity) med lokal modell som hjerne i OPAX-arkitekturen. Redusere API-avhengighet på sikt.

Arkitektur (nå vs mål)

NÅ:
Perplexity/Gemini  ←  Hjerne (stor API-modell)
       ↓ tool calls
   OPAX-MCP
       ↓
Emma gemma3:4b    ←  Lokal inferens (svak)

MÅL:
Lokal stor modell  ←  Hjerne (lokal, gratis)
       ↓ tool calls
   OPAX-MCP
       ↓
Emma gemma3:4b    ←  Lokal inferens (rask)

Kandidatmodeller for e2-highmem-4 (32 GB RAM) — oppdatert 2026-07-22 03:55

Modell	RAM	Tok/s CPU	Agentevne	Vurdering
gemma3:4b (nå)	2.9 GB	~5	Svak	Front/hurtig default
qwen2.5:3b	~2.0–2.5 GB	~3–4	God	Beste raske tool-kandidat nå
gemma3:12b	~8 GB	~1.5–2	God	Allsidig, men ikke tool-modell
qwen2.5:7b	~5.5–6 GB	forventet ~2.5–3	God	Neste kandidat som mellomlag
qwen2.5:14b	~9 GB	målt ~1.4	Sterk	For treg som interaktiv agent
qwen2.5-coder:14b	~9 GB	forventet ~1.4	Kode-sterk	Batch / async kodebruk
gemma3:27b	~17 GB	forventet <1	Tilnærmet god	Ikke aktuell nå
qwen2.5-coder:32b	~20 GB	<1	Svært sterk	Utsatt — for tung

Validerte funn

• qwen2.5:14b installert og verifisert
• Varm enkel chat-test ga ca. 249.3s eval-duration og 1.4 tok/s
• Resultatet vurderes som for tregt for interaktiv standardbruk
• Dette flytter qwen2.5:14b fra planlagt standardmodell til mulig batch-/asynkronmodell
• qwen2.5:7b er neste kandidat som må testes før modellstack fryses

Exit-kriterier Fase 7

• qwen2.5:14b installert og testet
• qwen2.5:7b installert og testet
• Beslutning tatt: fjern eller behold qwen2.5:14b
• qwen2.5-coder:14b testet på konkret kode-/repo-oppgave
• Ytelsesmåling: RAM-bruk, swap=0
• Endelig ruting besluttet for fast / light / coder / batch
• GEMINI.md-lignende systemd-prompt/konfig for Emma laget

Derivat-strategi

Emma skal få eget identitetsdokument (tilsvarende GEMINI.md for Jason) med:

• Personlighet og tone
• Arbeidsregler og prioriteringer
• Tool-bruksprinsipper
• Vauco OS-kontekst

---

FASE 8 – BACKUP / SNAPSHOT-STRATEGI (planlagt)

Mål

Sikre at Gitea-CPU-VM (34.67.252.59) aldri er single point of failure for source of truth.

Strategi: Daglig GCP Disk Snapshot

Kilde:    Gitea-CPU-VM persistent disk
Frekvens: Daglig (02:00 CEST)
Bevaring: 7 snapshots (rullerende — siste 7 dager)
Kostnad:  ~$0.026/GB/mnd — 50 GB disk = ~$1.30/mnd

Implementasjon

# Opprett snapshot-policy
gcloud compute resource-policies create snapshot-schedule gitea-daily-backup \
  --region=us-central1 \
  --max-retention-days=7 \
  --on-source-disk-delete=keep-auto-snapshots \
  --daily-schedule \
  --start-time=00:00 \
  --storage-location=us-central1

# Koble policy til disk
gcloud compute disks add-resource-policies gitea-cpu-vm \
  --resource-policies=gitea-daily-backup \
  --zone=us-central1-b

Hva snapshots dekker

• ✅ /opt/gitea/data/repositories/ — alle git-objekter
• ✅ /opt/gitea/data/gitea.db — brukere, tokens, metadata
• ✅ /opt/gitea/data/custom/conf/app.ini — konfig
• ✅ Ollama-modeller (/usr/share/ollama/)
• ✅ Systemd-dropins og warmup-skript

Restore-prosedyre (ved VM-tap)

# 1. Opprett ny disk fra snapshot
gcloud compute disks create gitea-restore \
  --source-snapshot=<snapshot-name> \
  --zone=us-central1-b

# 2. Koble til ny VM eller eksisterende
# 3. Gitea starter automatisk — alt er intakt

Exit-kriterier Fase 8

• Snapshot-policy opprettet og koblet til disk
• Første snapshot verifisert i GCP Console
• Restore-prosedyre testet (restore til tmp-disk)
• Kostnad bekreftet (~$1.30/mnd)

---

ÅPNE PUNKTER

1. GPG-signering — få commits verified (pågår)
2. git.vauco.no — verifiser propagering
3. Test qwen2.5:7b som nytt mellomlag
4. Beslutt om qwen2.5:14b skal fjernes etter 7B-test
5. Test qwen2.5-coder:14b på konkret kode-/repo-oppgave
6. Mål RAM/swap under modell-last
7. Emma derivat-dokument (tilsvarende GEMINI.md)
8. Fase 8: Snapshot-policy aktiveres
9. Gitea passord byttes (eksponert i chat)

FASTE SANNHETER

• Gitea er source of truth
• Lokale modeller er hovedretning — mål er å fase ut API-avhengighet
• Gitea-VM (34.67.252.59) er permanent målmaskin
• Dev-snap (34.170.51.84) er Jason sin arbeidsstasjon — kan ikke stenges før lokal hjerne er verifisert
• Denne handoffen overstyrer alt annet
• CPU er nå primær flaskehals for tyngre lokale modeller på denne VM-en

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 — GITEA_URL permanent + deployed
• ✅ Boot-warming verifisert
• ✅ DNS migrert til Google Cloud DNS
• ✅ Smoke-test alle 37 tools — FERDIG
• ✅ VM oppgradert til e2-highmem-4 (32 GB RAM) — FERDIG
• ✅ qwen2.5:14b installert og ytelsestestet — FERDIG
• ⏳ git.vauco.no live — propagering pågår
• ⏳ GPG-signering verified — pågår
• ⏳ qwen2.5:7b testet og vurdert — planlagt
• ⏳ Endelig mellomlag valgt (qwen2.5:7b vs behold qwen2.5:14b) — planlagt
• ⏳ qwen2.5-coder:14b verifisert i konkret kodeflyt — planlagt
• ⏳ Fase 7: lokal hjerne verifisert — pågår
• ⏳ Fase 8: daglig snapshot-backup — planlagt

OPPDATERINGSLOGG

Dato	Handling
2026-07-21	FASE 4–6: CPU-optimalisering, boot-warming fullført
2026-07-21 23:44	DNS: NS-bytte utført hos Proisp
2026-07-21 23:53	OPAX-MCP: GITEA_URL + OLLAMA_BASE_URL → 34.67.252.59, deployed
2026-07-22 00:05	Smoke-test plan klar, Fase 7 (lokal hjerne) lagt inn
2026-07-22 00:25	Smoke-test fullført — alle kategorier grønne
2026-07-22 00:55	Fase 8 (backup/snapshot) lagt inn, GPG-signering pågår
2026-07-22 03:29	FASE 6.5 lagt inn: e2-highmem-4 verifisert, ny modellarkitektur (Gemma4b → Qwen14b → Qwen-coder-14b → Gemma27b), neste steg: pull qwen2.5:14b + qwen2.5-coder:14b
2026-07-22 03:55	Handoff oppdatert etter 14B-validering: qwen2.5:14b målt til ~1.4 tok/s varm og vurdert for treg som interaktiv standardmodell; qwen2.5:7b satt som neste kandidat; gemma3:27b og coder32b utsatt