chris/OSVauco
1
0
Fork 0
Code Issues 1 Pull Requests Actions 2 Packages Projects Releases Wiki Activity
4c4b582e25
OSVauco/docs/HANDOFF-LOCAL-LLM-GITEA-MCP.md
chris baf60c1dda
Some checks are pending
Check Python Version Consistency / Check Python Version (push) Waiting to run
Details
chore: update docs/HANDOFF-LOCAL-LLM-GITEA-MCP.md via opax-mcp
2026-07-22 02:01:51 +00:00

13 KiB
Raw Blame History

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