Ollama 0.32.15 halverar tiden till första token — men bara mellan anrop

Ollama 0.32.15 publicerades den 19 augusti 2026. En rad i utgåvenoteringen har spridit sig snabbt: en cache för upplöst modellmetadata mellan anrop som enligt Ollamas egen mätning ungefär halverar tiden till första token, från cirka 995 ms till cirka 524 ms. Om du nu uppdaterar, startar om servern, kör ett kallt anrop och tittar på load_duration kommer du med stor sannolikhet att se samma siffra som förut. Det betyder inte att ändringen uteblev. Det betyder att den inte ligger där du mätte. Metoden för att mäta finns redan i provet som skiljer laddning, prompt och generering åt; den här texten handlar om vilken av de mätpunkterna som faktiskt ska köras om.

Det här står i utgåvan

Utgåvenoteringen för v0.32.15 listar fem ändringar: ett nytt onboardingflöde i skrivbordsappen vid första start, metadatacachen, en rättning av en bugg där chat och generate kunde låsa sig efter ett parserfel mitt i en ström, en normalisering av systemmeddelanden för Qwen 3.8, samt uppdateringar av MLX och llama.cpp. Prestandaraden lyder att ändringen cachar upplöst modellmetadata mellan anrop och skär tiden till första token ungefär på hälften, med tillägget att siffrorna kommer från en benchmark.

De tre reservationerna är hela nyheten. "Mellan anrop" säger var vinsten uppstår, "ungefär" säger att det inte är ett mätetal du ska förvänta dig exakt, och "i benchmarks" säger att mätningen är gjord på någon annans maskin med någon annans modell.

Vad cachen tar bort — och vad den inte rör

Ändringen kommer från en sammanslagen pull request med titeln "Add a model metadata cache to reduce Ollama's per-request overhead". Beskrivningen anger problemet rakt: ett chat- eller generate-anrop läste GGUF-metadata flera gånger i varje inferensanrop, vilket kostade ungefär 300 ms per anrop. Det var alltså inte en engångskostnad vid start utan en avgift som togs ut om och om igen.

Lösningen cachar upplöst metadata och modellförmågor, invaliderar cachen automatiskt när modellens manifest ändras, hindrar dubblerade samtidiga laddningar och tar bort ett dubblerat modelluppslag i schemaläggningen. Den gäller endpointerna för generate, chat och embeddings. Filerna som ändras ligger i serverlagret, inte i den process som kör själva modellen — och det syns i mätningen: i båda körningarna ligger tiden mellan token på ungefär 9,5 ms och utdatatakten på ungefär 106 token per sekund och användare.

Därför rör sig inte kallstarten

En cache som lever mellan anrop har ingenting att återanvända vid det första anropet efter att servern har startat. Det anropet får fylla cachen. Vinsten uppstår från och med det andra anropet i följd — precis som utgåvenoteringens egen formulering antyder.

Lägg därtill proportionerna. Vid en verklig kallstart domineras väntan av att modellens vikter läses in i RAM eller VRAM, och den tiden redovisas separat i load_duration. Om laddningen tar åtta sekunder är ett par hundra millisekunder mindre än fyra procent av väntan, alltså väl inom spridningen mellan två enskilda körningar. Du kan ha fått hela förbättringen och ändå inte kunna se den i ett kallt prov.

En detalj till, som är lätt att snubbla på: cachen invalideras när modellens manifest ändras. Har du precis kört ollama pull på samma modell betalar nästa anrop kostnaden igen. Mät alltså inte direkt efter en nedladdning och tro att du mätte runtimeversionen.

Den mätpunkt du ska köra om

Tid till första token är inte ett fält Ollama returnerar. De dokumenterade svarsfälten är total_duration, load_duration, prompt_eval_count, prompt_eval_duration, eval_count och eval_duration. Inget av dem heter tid till första token, och strömmande svar levererar samma uppsättning fält. Vill du se det utgåvan talar om måste du ta tiden utanför servern: från att anropet skickas till att den första delen av strömmen kommer tillbaka.

Fyra villkor gör den mätningen läsbar:

• Kasta det första anropet. Det är anropet som fyller cachen. Jämför anrop två och framåt.
• Håll modellen laddad under hela serien, så att modelladdningen inte kommer in i tidtagningen och gör serien obegriplig.
• Ändra en sak. Samma modell, samma kvantisering, samma prompt, samma inställningar — bara runtimeversionen skiljer.
• Läs den externa tiden mot serverns fält. Faller din externa väntan medan prompt_eval_duration och eval_duration står stilla har du isolerat just den här ändringen. Rör sig allting samtidigt har du ändrat mer än en sak.

Här kommer den obehagliga delen: mätningen kräver en baslinje från före uppdateringen. Har du ingen sådan kan du inte längre visa vad 0.32.15 gjorde på din maskin. Det du kan göra är att ta baslinjen nu, medan 0.32.15 är den version du kör, så att nästa utgåva går att bedöma. Ett protokoll som redan finns nedskrivet är billigare än ett du måste hitta på i efterhand.

Läs benchmarksiffran som det den är

Siffrorna i pull requesten kommer från ett externt benchmarkverktyg mot en fast datamängd, med en enda modell, tio anrop och en samtidig förfrågan i taget.

Medianen flyttar sig knappt 270 ms. Det ligger nära de ungefär 300 ms per anrop som beskrivningen anger, och det är den siffra som bäst beskriver ett typiskt anrop. Medelvärdet flyttar sig drygt 470 ms, alltså mer — men medelvärdet dras av enstaka långsamma anrop, och det högsta värdet i utgångsläget låg över fyra sekunder. Rubriksiffran "halverad" är alltså en egenskap hos medelvärdet i just den serien.

Två saker till talar för försiktighet. Körningarna hade inte samma last: den genomsnittliga indatalängden var cirka 1 338 token före och cirka 832 token efter, och utdatalängden skilde sig också. Det är inte ett kontrollerat prov med identisk indata, utan två serier ur samma datamängd. Och modellen var en stor blandmodell — hur mycket 300 ms betyder i din vardag beror på om dina anrop tar en sekund eller trettio. Använd siffran som storleksordning, inte som faktor att räkna med.

Resten av utgåvan förtjänar din uppmärksamhet

Om du kör Ollama som tjänst bakom en egen applikation är rättningen sannolikt viktigare än prestandaraden. Buggen gjorde att chat och generate kunde låsa sig efter ett parserfel mitt i en ström. En endpoint som slutar svara kostar betydligt mer än 300 ms per anrop.

Normaliseringen av systemmeddelanden för Qwen 3.8 är den ändring som kan påverka vad du får ut. Skickar du ett systemmeddelande som inte ligger först i meddelandelistan hanteras det nu konsekvent — vilket också innebär att beteendet kan skilja sig från före uppdateringen. Kör dina promptprov igen i stället för att anta att svaren är identiska.

Uppdateringarna av MLX och llama.cpp är den vanligaste orsaken till att en mätning efter en Ollama-uppgradering blir svårtolkad. De kan flytta genereringshastigheten oberoende av metadatacachen. Byter du dessutom modellfil samtidigt blir det ännu svårare; hur mycket en granne på kvantiseringsskalan kan flytta både minne och kvalitet står i guiden till Q4, Q5 och Q8. Onboardingflödet i skrivbordsappen gäller nya installationer och påverkar inte en server som redan är i drift.

Uppdatera som en ändring, inte som en reflex

En prestandaförbättring är fortfarande en versionsändring. Notera vilken version du körde före och efter, kör samma provpaket båda gångerna och ha en väg tillbaka om något beter sig annorlunda. Rutinen för det — inklusive vem som äger driftkortet och hur en runtimeuppdatering hanteras som en kontrollerad ändring — står i driftguiden, och tid till första token är redan en av de mätpunkter den anger. Det enda den här utgåvan ändrar är vilket anrop i serien du ska titta på.

Den vanligaste fallgropen är att uppdatera och mäta i samma rörelse och sedan redovisa skillnaden som en enda effekt. I den här utgåvan finns minst tre saker som kan flytta en siffra: metadatacachen, llama.cpp-uppdateringen och MLX-uppdateringen. Kör du dessutom bara ett anrop per version mäter du i praktiken cachens tomma första träff. Tre upprepningar per version, avlästa på medianen i stället för på ett enskilt värde, är ett rimligt minimum — samma princip som mätartikelns kalla–varma prov vilar på.

Källor och metod

• Ollama v0.32.15 — utgåvenoteringen med de fem ändringarna och prestandaraden
• Ollamas utgåvelista — publiceringsdatum och föregående version
• Pull request 17752 — metadatacachen, invalideringen och mättabellerna
• Ollama API — svarsfälten för generate och strömmande svar

Källorna kontrollerades 21 augusti 2026, då v0.32.15 var den senaste utgåvan. Siffrorna i tabellen är Ollamas egna benchmarkvärden och inte ett löfte för en enskild maskin. Kontrollerat igen 10 september 2026: Ollama har sedan dess släppt v0.33.0 (21 augusti) och senare utgåvor, senast v0.34.0 (5 september). Texten beskriver v0.32.15 och uppdateras inte för varje ny utgåva; mätmetoden gäller även för senare versioner.

Skriv in runtimeversionen och den mätpunkt du faktiskt jämför på i samma driftkort som resten av ändringarna.