Innhold Vis
llama.cpp b9200 er ute, og det er ikke en tilfeldig release. Den fikser spesifikt et memory traffic-problem i MTP-motoren som har kvelt ytelsen for agentic workflows – og kombinert med riktig konfig på Qwen 3.6 27B mtp-modellen fra Unsloth, er resultatet ganske overraskende godt på en enkel RTX 3090.
Multi-token prediction (MTP) er teknologien som lar modellen gjette flere tokens framover samtidig – litt som speculative decoding, men integrert direkte i modellvektene. Qwen 3.6 27B har MTP innebygd, og llama.cpp har støttet dette i beta en stund. Problemet har vært at de anbefalte flaggene fra Unsloth faktisk motvirket ytelsen for strenge, multi-turn agent-workflows. b9200 endrer ligningen.
Denne saken handler om et konkret benchmarkresultat fra LocalLLaMA-miljøet: hva som faktisk skjer når du kombinerer riktige konfig-flags med den nye b9200-oppdateringen, og hva du bør endre hvis du kjører Hermes Agent mot Qwen 3.6 27B på consumer GPU.
Hva er MTP og hvorfor har det vært et problem i llama.cpp?
Multi-token prediction er ikke det samme som klassisk speculative decoding, selv om de ligner i prinsippet. Med speculative decoding bruker du en liten draft-modell til å gjette, og en stor modell til å verifisere. MTP er annerledes: gjettelaget er trent inn i selve modellen som ekstra «hoder» på toppen av arkitekturen. Qwen 3.6 27B har ett slikt MTP-hode.
Fordelen er at du slipper å administrere to separate modeller – alt ligger i én GGUF-fil. Ulempen er at implementasjonen i llama.cpp har hatt et konkret problem: under prompt decode-fasen ble logits (modellens råoutput per token) kopiert unødvendig, noe som skapte ekstra memory traffic. For korte enkelt-turn spørsmål er det uvesentlig. For strenge, multi-turn agentic workflows – der Hermes Agent sender mange verktøy-kall og konteksten vokser raskt – ble dette en reell flaskehals.
b9200 fikser dette ved å eliminere den overflødige kopiringen («llama: avoid copying logits during prompt decode in MTP»). Det høres teknisk trivielt ut, men i praksis betyr det at MTP-hodet nå fungerer som tiltenkt uten å stresse minnebåndbredden unødvendig.
Hva er draft acceptance rate og hvorfor er den kritisk for agent-bruk?
Draft acceptance rate er andelen av MTP-hodets gjetninger som den fullt vektede modellen aksepterer. Hvis MTP-hodet foreslår neste 4 tokens og 3 av dem er korrekte, er acceptance rate 75%. Høyere rate = færre «bortkastede» beregninger = mer effektiv inferens.
For vanlig chatting er dette OK uansett – variansen i output er lav nok til at det sjelden spiller stor rolle. For Hermes Agent er det annerledes. Agent-workflows krever presis output: strukturerte JSON-verktøy-kall, spesifikke felt-navn, konsistent formatering på tvers av mange turns. Hvis acceptance rate er lav i dette scenariet, kjøper MTP deg ingenting – du betaler GPU-overhead for et hode som konstant gjetter feil.
Det interessante funnet i dette benchmark-eksperimentet er at de Unsloth-anbefalte MTP-flaggene faktisk senker acceptance rate for strenge agent-workflows, ikke øker den. Og b9200-oppdateringen, kombinert med en tilpasset konfig, snur dette fullstendig.
Hva er Hermes Agent og hvorfor egner Qwen 3.6 27B seg?
Hermes er NousResearch sitt function calling-rammeverk – en implementering som lar language models generere strukturerte JSON-kall til verktøy og API-er. Hermes 3 (basert på NousResearch sine finjusterte modeller) er mye brukt i lokale agent-pipelines fordi det er open source, godt dokumentert og fungerer med et bredt spekter av base-modeller.
Qwen 3.6 27B er et interessant valg her. Modellen har en hybrid arkitektur som kombinerer Gated DeltaNet (lineær attention) og standard Gated Attention – 48 lineære oppmerksomhetshoder og 16 standard-hoder. Det gir god ytelse på lange kontekster (nativt 262 144 tokens) uten å eksplodere i VRAM-bruk sammenlignet med rene transformer-modeller av samme størrelse.
På RTX 3090 med 24 GB VRAM passer Q4_K_M-kvantiseringen (16,8 GB) komfortabelt, og du har fremdeles nok buffer til KV-cache for en rimelig kontekstlengde. llama.cpp MTP-støtten har siden beta-fasen lovet opp til 2,4 ganger raskere inferens under ideelle forhold – nøkkelordet er ideelle.
Hva bør du endre i konfigurasjonen?
De anbefalte Unsloth-flaggene for MTP er ikke feil generelt – de er optimalisert for gjennomstrømning på lange, kreative oppgaver der variansen i token-distribusjon er høy. Problemet er at Hermes Agent-workflows er det motsatte: lavvarians, deterministisk, strukturert. I det scenariet vil aggressive MTP-parametere overestimere mangfoldet i neste token og gjette feil oftere.
Konkret betyr det at du bør justere ned antall spekulative steg og redusere draft-aggressiviteten for agent-bruk. I stedet for å bruke maksimal spekulasjon på alle turns, gir det bedre totalytelse å la MTP operere mer konservativt – færre gjetninger per pass, men høyere acceptance rate. Kombinert med at b9200 nå ikke lenger kaster bort minnebåndbredde på unødvendig logit-kopiering, ender du opp med lavere latens per verktøy-kall og bedre responsivitet gjennom hele agent-sesjonen.
For Qwen 3.6 27B på llama.cpp anbefaler Unsloth sin GGUF-side temperature 0,6 for presise kodingsoppgaver – dette er i tråd med det samme prinsippet. Lavere temperatur = mer forutsigbar output = høyere MTP acceptance rate.
Hva betyr dette i praksis for deg som kjører lokal agent på RTX 3090?
Det korte svaret er at b9200 er en obligatorisk oppdatering hvis du bruker MTP med llama.cpp. Den er ikke dramatisk på alle workloads – men for agent-bruk spesifikt er memory traffic-fiksen merkbar.
Det lengre svaret handler om konfig-filosofien. Den mest interessante observasjonen i dette benchmarket er ikke at b9200 er bedre – det er forutsigbart. Det interessante er at de default-anbefalte flaggene aktivt skader ytelsen i et spesifikt bruksscenario, og at dette ikke er åpenbart uten å faktisk måle acceptance rate over tid.
Hvis du bruker llama.cpp for seriøs lokal inferens, er dette en påminnelse om at defaults er utgangspunktet, ikke sluttpunktet. Agent-workflows stiller andre krav enn chatting, og de MTP-parameterne som gir best gjennomstrømning for det ene gir ikke nødvendigvis best latens og acceptance rate for det andre.
Qwen 3.6 27B – kvantisering og VRAM på RTX 3090
For RTX 3090 (24 GB VRAM) er valget av kvantisering viktig. Q4_K_M på 16,8 GB er det naturlige valget – du får god kvalitet og nok headroom til KV-cache for kontekster opp mot 32 768 tokens. Q5_K_M på 19,5 GB er mulig, men strammere. Q6_K på 22,5 GB er teoretisk mulig men gir lite spillerom til KV-cache og er ikke anbefalt for agent-bruk der konteksten vokser over mange turns.
Unsloth tilbyr også «UD»-varianter (Unsloth Dynamic) som er dynamisk kvantisert – UD-Q4_K_XL på 17,6 GB er et populært alternativ som beholder høyere presisjon på de viktigste lagene. For agent-workflows der nøyaktighet i verktøy-kall er kritisk, er dette ofte et bedre valg enn standard Q4_K_M.
Qwen 3.6-serien er tidligere omtalt her på jansverre.net i sammenheng med 1 million token kontekst – den store kontekstlengden er relevant også for agent-bruk der samtalehistorikk og verktøy-output kan akkumulere raskt.
b9200 kan lastes ned direkte fra llama.cpp sitt GitHub-repository. Binærer finnes for macOS, Linux og Windows. Oppdater, test acceptance rate i din spesifikke workflow, og juster MTP-parametere deretter. Tallene lyver ikke.
