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
chore: update docs/HANDOFF-LOCAL-LLM-GITEA-MCP.md via opax-mcp
2026-07-22 02:01:51 +00:00

358 lines
13 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-22 03:55 CEST
### ✅ FASE 05 — 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.95.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`
### 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
```bash
# 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.95.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.02.5 GB | ~34 | God | **Beste raske tool-kandidat nå** |
| `gemma3:12b` | ~8 GB | ~1.52 | God | Allsidig, men ikke tool-modell |
| `qwen2.5:7b` | ~5.56 GB | forventet ~2.53 | 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 |
| `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 testes før modellstack fryses
### Exit-kriterier Fase 7
- [x] `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 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 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
```bash
# 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)
```bash
# 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 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` 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 primær flaskehals for tyngre lokale modeller 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 46: 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 |