Nyhet · Ollama 0.33.3 · promptcache

Ollama 0.33.3 visar cachade prompttoken – mät återanvändningen utan att lura hastigheten

Det nya fältet visar hur stor del av prompten som kom från cache. Behåll ändå hela tokenantalet: cacheandel och verklig promptbearbetning svarar på olika frågor.

Av C. Leijon · Publicerad · Senast granskad · 9 min läsning

Ett svart serverchassi med en öppen sektion där grönt ljus lyser över kretskort och staplade komponenter.
Cacheprovet skiljer återanvända prompttoken från den del som behöver bearbetas på nytt.
Uppdaterat 19 september 2026

Artikeln skrevs mot förhandsversionen v0.33.3-rc2. Fältet ingår i den skarpa utgåvan Ollama v0.33.3 (utgåvepunkten ”Report cached prompt tokens”) och finns kvar i v0.34.0–v0.34.2. Råden om separat testmiljö nedan gäller varje versionsbyte, inte bara en förhandsversion; rc-taggarna är inte längre publicerade releaser hos Ollama.

Ollama v0.33.3-rc2 var förhandsversionen som först redovisade cachade prompttoken separat. Det gör en gammal mätfälla synlig: två körningar kan ha lika många logiska prompttoken, men den andra kan återanvända en stor del ur cache. Dividerar du hela prompten med tiden för den icke-cachade bearbetningen får du då ett tal som blandar två olika mängder. Spara i stället totalen, cacheträffen och den bearbetade resten var för sig.

Beslutet i en rad

Jämför inte prompttakt förrän du har räknat bort prompt_eval_cached_count från prompt_eval_count och kontrollerat att version, modelldigest, prompt och options är lika.

Tre fält beskriver två olika mängder

Ändringen bakom releasen, Ollama PR #17943, behåller prompt_eval_count som promptens logiska totalantal. Det nya prompt_eval_cached_count visar hur många av dessa token som lästes ur cache. Ollamas aktuella Usage-referens anger samtidigt att prompt_eval_duration mäter tiden för att utvärdera den icke-cachade delen och att tidsvärdet står i nanosekunder.

FältVad du spararVad det inte är
prompt_eval_countHela den logiska prompten i tokenInte antalet som beräknades på nytt
prompt_eval_cached_countPrompttoken som lästes ur cacheInte extra token ovanpå totalen
prompt_eval_durationTid för den icke-cachade utvärderingen, i nanosekunderInte hela anropets svarstid

Räkna därför bearbetade prompttoken = prompt_eval_count - prompt_eval_cached_count. Cacheandelen blir prompt_eval_cached_count / prompt_eval_count × 100. Bearbetningstakten blir bearbetade prompttoken / (prompt_eval_duration / 1 000 000 000). Ett illustrativt svar med 100 logiska token, 80 cachade och 0,25 sekunders prompttid betyder 20 bearbetade token, 80 procents cacheandel och 80 bearbetade token per sekund. Talet 400, som fås om hela totalen divideras med samma tid, är inte en jämförbar rå prefill-takt.

Skilj också noll från saknat värde. Ett cachefält som saknas i svaret är inte samma sak som ett fält som rapporterar noll. Saknas fältet ska raden därför märkas ”orapporterat”, inte fyllas med noll. Annars blandar du ett äldre eller ofullständigt svar med en verifierad nollträff.

Gör versionsbytet återställningsbart

Installera inte en ny version över den Ollama-instans som andra klienter behöver. Använd en testdator, en virtuell maskin med kontrollpunkt eller en annan separat instans som du kan kasta. Hämta paketet för rätt operativsystem från den exakta utgåvesidan för den version du provar, inte från en odaterad nedladdningslänk. Spara före installationen den tidigare installationsfilen eller VM-kontrollpunkten, och dokumentera sedan båda versionslägena med ollama --version.

Frys även modellens identitet. Ett modellnamn kan vara oförändrat även om innehållet bakom namnet byts. Spara därför den valda modellpostens digest från GET /api/tags tillsammans med prompten, num_ctx, num_predict, temperatur och seed. AI-burkens driftguide äger den fulla rutinen för version, konfiguration och återställning; här räcker det att du kan återgå till exakt den instans som fanns före provet.

Starta testet först när ollama --version visar den avsedda versionen och den sparade modellposten fortfarande har samma digest. Låt ingen annan klient skicka anrop under paret. Ändras runtime, modell eller samtidighet mellan rad ett och två mäter tabellen mer än cacheåteranvändning.

Skicka exakt samma API-kropp två gånger

Ollamas Generate-referens visar fälten i svar från POST /api/generate. Exemplet nedan använder stream: false, så varje körning kan sparas som ett komplett JSON-objekt. Byt bara MODELLNAMN mot den redan dokumenterade testmodellen. Objektet i $body skapas en gång och återanvänds; därmed kan ingen prompt- eller optionsrad råka glida mellan anropen.

$body = @{
  model = "MODELLNAMN"
  prompt = "Förklara skillnaden mellan RAM och VRAM på exakt tre korta meningar."
  stream = $false
  options = @{
    num_ctx = 4096
    num_predict = 96
    temperature = 0
    seed = 42
  }
} | ConvertTo-Json -Depth 4

Invoke-RestMethod -Method Post -Uri http://localhost:11434/api/generate `
  -ContentType "application/json" -Body $body |
  ConvertTo-Json -Depth 10 | Set-Content -Encoding utf8 .\cache-01.json

Invoke-RestMethod -Method Post -Uri http://localhost:11434/api/generate `
  -ContentType "application/json" -Body $body |
  ConvertTo-Json -Depth 10 | Set-Content -Encoding utf8 .\cache-02.json

Gör inga uppvärmningsanrop mellan raderna. Det första svaret är provets utgångsläge och det andra är den möjliga återanvändningen. Kräv inte att rad två måste träffa cache: utfallet ska observeras i svaret. Behöver du först skilja modelladdning från promptbearbetning följer du den separata metoden för kall och varm Ollama-körning; det här paret ska inte användas för att mäta båda frågorna samtidigt.

Bygg resultatet utan att fylla i luckor

Följande PowerShell-utdrag behåller skillnaden mellan ett saknat fält och ett rapporterat nollvärde. Det beräknar cacheandel och bearbetningstakt endast när cachemåttet faktiskt finns och prompttiden är större än noll.

$files = '.\cache-01.json', '.\cache-02.json'

foreach ($file in $files) {
  $r = Get-Content $file -Raw | ConvertFrom-Json
  $hasCached = $null -ne $r.PSObject.Properties['prompt_eval_cached_count']
  $cached = if ($hasCached) { [int]$r.prompt_eval_cached_count } else { $null }
  $processed = if ($hasCached) {
    [Math]::Max(0, [int]$r.prompt_eval_count - $cached)
  } else { $null }
  $seconds = [double]$r.prompt_eval_duration / 1000000000
  $hitRate = if ($hasCached -and $r.prompt_eval_count -gt 0) {
    100 * $cached / [double]$r.prompt_eval_count
  } else { $null }
  $processedRate = if ($hasCached -and $seconds -gt 0) {
    $processed / $seconds
  } else { $null }

  [pscustomobject]@{
    Run = $file
    LogicalPromptTokens = $r.prompt_eval_count
    CachedPromptTokens = $cached
    ProcessedPromptTokens = $processed
    CacheHitPercent = $hitRate
    PromptSeconds = $seconds
    ProcessedPromptTokensPerSecond = $processedRate
  }
}
KörningLogiska tokenCachade tokenBearbetade tokenCacheandelBearbetad takt
1______ eller orapporterat______ %___ token/s
2______ eller orapporterat______ %___ token/s

En giltig cachejämförelse har samma logiska promptantal på båda raderna. Om det skiljer sig ska du först kontrollera den sparade requestkroppen, modellens promptmall och digest. Den som samtidigt ändrar num_ctx gör ett annat experiment; använd i så fall kontextprovet med fasta steg och håll cachefrågan utanför slutsatsen.

Läs CLI-raden som en bearbetningstakt

Samma åtskillnad finns i den utförliga CLI-visningen. Kör samma prompt två gånger och spara mätutskriften i varsin fil. I PowerShell går sammanfattningen från --verbose till standard error, så 2> fångar den medan modellsvaret fortfarande visas i terminalen.

ollama run --verbose MODELLNAMN "Förklara skillnaden mellan RAM och VRAM på exakt tre korta meningar." 2> .\cli-cache-01.txt
ollama run --verbose MODELLNAMN "Förklara skillnaden mellan RAM och VRAM på exakt tre korta meningar." 2> .\cli-cache-02.txt

När cacheantalet är större än noll kan utskriften innehålla den separata raden prompt eval cached. Ändringen räknar då prompt eval rate på den icke-cachade delen, inte på hela prompt eval count. En lägre CLI-takt i den andra körningen kan därför sammanfalla med kortare prompttid: färre nya token bearbetades och kvoten beskriver just dessa token. Jämför både duration, logiskt antal och cacheantal innan du uttalar dig om hastighet.

Tre utfall ger tre olika slutsatser

Samma total, positiv cacheträff i körning två. Då har du observerat återanvändning för just denna modell, prompt, runtime och lokala instans. Redovisa cacheandelen och den bearbetade takten var för sig. Säg inte att modellens råa prefill-kapacitet ökade bara för att total väntetid sjönk.

Samma total, cachefältet är 0 på båda raderna. Då rapporterade versionen ingen cacheträff i just paret. Upprepa två nya identiska körningar och spara även serverloggen innan du felsöker vidare. Ändra inte prompten för att försöka framtvinga det utfall du ville se.

Cachefältet saknas. Då kan testet inte besvara cachefrågan. Kontrollera först serverversionen som faktiskt svarade, inte bara klientens versionsrad. Behåll JSON-filen som ofullständig mätning och sätt inget nollvärde i efterhand.

Det här är lokal tokenredovisning, inte en prisräknare. Fälten visar vad Ollama rapporterar om prompten och cachen i den egna körningen. De säger inget i sig om debitering, cachelivslängd eller prismultiplikatorer hos en molnleverantör.

Källor

Källorna kontrollerades 3 september 2026. Ingen egen installation eller benchmark ligger bakom artikeln och inga provutfall presenteras som uppmätta. Kontrollerat igen 19 september 2026: fältet prompt_eval_cached_count och definitionerna i Usage-referensen står oförändrade; funktionen ingår i den skarpa v0.33.3 och i v0.34.0–v0.34.2. Rc-taggarna är inte längre publicerade releaser hos Ollama, så källänken pekar på v0.33.3. Prova varje versionsbyte i en separat miljö med en kontrollerad återställningsväg.

Nästa steg

Spara samma JSON-kropp två gånger, fyll tabellen, kontrollera att begäran är oförändrad och jämför sedan det cacheutfall som Ollama faktiskt rapporterar.

Kontrollera tidsleden