open/portfolio-optimiser
1
0
Fork 0
Code Issues Releases 3 Activity

docs(fase1a): «uansett modell» hvilte på en måling jeg aldri leste ferdig

Browse source 
Advisor felte påstanden ETTER at forrige commit var pushet. Rapporten sa at
600 s-taket er bindende «UANSETT modell», med `llama3.2:1b brukte OGSÅ >10 min»
som belegg. Men den målingen sprengte Bash-timeouten, gikk til bakgrunnen, og
ble aldri lest til slutt — «>10 min» var det jeg SÅ ved én kikk, ikke et resultat.

Målt nå ved manuell stopp: prosessen sto på 18 min 54 s UTEN å fullføre, og
loggen har ingen `POST "/api/generate"` for kallet. Det gir en NEDRE grense
(kallet oversteg taket med god margin) og ingen øvre.

Påstanden er derfor snevret til «på denne maskinen i denne tilstanden», med
konfunderingen uttalt: CPU-en strupet seg 62 % → 54 % underveis, og to fremmede
Python-prosesser holdt ~1,8 kjerner. Et generelt utsagn om modellstørrelse ville
krevd en ren maskin og en fullført måling; ingen av delene finnes her.
Verifiseringsloggen har fått raden + en eksplisitt «ikke verifisert»-note.

Samme defektklasse som grep-en samme økt, ett nivå opp: der var instrumentet i
stykker, her var det i orden og jeg leste det bare aldri.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X737cbkG2uAXJ2Bvhf6X5M
This commit is contained in:
Kjell Tore Guttormsen 2026-08-13 20:19:31 +02:00
commit cb809b683c
1 changed files with 17 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

20
docs/2026-08-13-fase1a-lokal-ende-til-ende.md
View file

@ -129,9 +129,18 @@ framfor å brenne det tredje forsøket mot et kjent utfall.
Ett funn ble likevel lukket: **null trunkering** i loggen. Det større kontekstvinduet løser funn 4.
**Diagnosen flyttet seg, og det er den viktigste setningen i rapporten:** flaskehalsen er ikke
tankemodusen. Det er at 600-sekunders-taket er bindende på denne maskinvaren **uansett modell**.
En kontrollmåling med `llama3.2:1b` — en modell på 1,3 GB — brukte også over ti minutter på ett
kall med denne kontekststørrelsen, mens maskinen strupet seg fra 62 % til 54 % klokkefrekvens.
tankemodusen. Det er at 600-sekunders-taket er bindende **på denne maskinen i denne tilstanden**,
også for modeller som er langt mindre enn den shippede.
Kontrollmålingen: `llama3.2:1b` — en modell på 1,3 GB — sto **18 min 54 s uten å fullføre ett
enkelt kall** med denne kontekststørrelsen, og ble så stoppet manuelt. **Presist hva dette er:**
den nedre grensen er målt (kallet overskred 600-sekunders-taket med god margin), men den øvre er
det ikke — målingen ble aldri lest til slutt, så det finnes ikke noe totaltall for den.
**Og påstanden er bevisst snevret til denne maskinen i denne tilstanden**, ikke «uansett modell»:
målingen er konfundert av at CPU-en strupet seg fra 62 % til 54 % klokkefrekvens underveis, og at
to fremmede Python-prosesser holdt ~1,8 kjerner samtidig. Et generelt utsagn om modellstørrelse
ville krevd en ren maskin og en fullført måling; ingen av delene finnes her.
## Hva som er bevist, og hva som ikke er
@ -180,3 +189,8 @@ Claude-deployment. Foundry-tilgjengeligheten er dokumentert; klient-kompatibilit
| Prompt 4388 tokens, kuttet mot 4096 | Ollamas `truncating input prompt`-advarsel |
| `_DEFAULT_MAX_ROUNDS = 3`, `_DEFAULT_MAX_TOKENS = 100_000` | `run.py:110-111`; CLI-en har ingen `--max-*` |
| Haiku 4.5-priser; Claude på Foundry til standard API-rater | Anthropics modell-/prisdokumentasjon (`claude-api`-skillen) |
| `llama3.2:1b` 18 min 54 s **uten å fullføre** — nedre grense, ikke totaltid | `ps -o etime=` ved manuell stopp; ingen `POST "/api/generate"` i loggen for kallet |
**Ikke verifisert, uttalt:** at taket ville vært bindende på en URØRT maskin, eller for en vilkårlig
liten modell. Kontrollmålingen ble kjørt under termisk struping og fremmed last, og ble aldri
fullført. Påstandene over gjelder denne maskinen i denne tilstanden.