Kallstart eller långsam modell? Mät laddning, prompt och generering var för sig

Mörk teknisk interiör där en serverkapsling står i en öppen zon bredvid en avskild dörrkammare, belyst med grönt ljus. — Två avskilda zoner i samma tekniska rum — en påminnelse om att mäta laddning och körning var för sig.

En ensam tidtagning säger bara att du väntade. Den säger inte vad du väntade på. Med ett kallt och ett varmt anrop till samma lokala Ollama-modell kan du skilja modelladdningen från promptbearbetningen och själva tokengenereringen. Resultatet blir en diagnos för just din maskin och konfiguration — inte en generell topplista.

Tre tider svarar på tre olika frågor

Ollamas svar från /api/generate och /api/chat kan innehålla användningsmått. Alla tidsvärden anges i nanosekunder. De tre fält som behövs för det här provet är:

load_duration: tiden som Ollama redovisar för att ladda modellen.
prompt_eval_duration: tiden för att bearbeta indatan. Läs den tillsammans med prompt_eval_count, antalet indatatoken.
eval_duration: tiden för att generera utdata. Läs den tillsammans med eval_count, antalet genererade token.

total_duration är användbart som serverns totalmått, men det pekar inte ut orsaken. Om två körningar har samma total men den ena lägger tiden på modelladdning och den andra på generering kräver de olika åtgärder. En extern tidtagning runt klienten kan dessutom omfatta sådant som inte syns i serverfältet, exempelvis klientens behandling av svaret.

Rå tid räcker inte när antalet token skiljer sig. Räkna därför också prompt_eval_count / (prompt_eval_duration / 1 000 000 000) och motsvarande kvot för eval_count. Då får du indatatoken respektive utdatatoken per sekund. Det är främst ett jämförelsetal mellan dina egna körningar med samma protokoll.

Lås protokollet innan du mäter

Anteckna förutsättningarna före första körningen. Ett modellnamn räcker inte, eftersom samma namn eller tagg senare kan peka på ett annat innehåll. Anropet GET /api/tags visar bland annat modellens digest, format, parameterstorlek och quantization_level. GET /api/version visar den Ollama-version som servern faktiskt kör.

Spara minst följande i testloggen:

operativsystem, processor, grafikprocessor och mängd RAM eller VRAM;
Ollama-version samt om tjänsten körs direkt, i virtuell miljö eller i container;
modellens namn, digest, parameterstorlek och kvantisering;
exakt prompt, endpoint och samtliga options;
kontextgräns, utdatagräns och om andra förfrågningar kördes samtidigt.

Har du inte redan låst modellvariant och kvantisering behöver du göra det före mätningen. Guiden om lokalt modellval visar vilka modelluppgifter som ska följa med ett jämförbart prov.

Håll också bakgrundslasten så lika som möjligt. Ollamas dokumentation beskriver att förfrågningar kan köas när tillgängligt minne inte räcker för att ladda en ny modell. Ett test samtidigt som en annan användare kör inferens mäter därför mer än modellen. För den första diagnosen: kör ensam, med samma nätanslutning till samma lokala server.

Provet: en kall och en varm körning

Exemplet använder /api/generate med icke-strömmande svar, så alla mätfält hamnar i ett enda JSON-svar. Byt MODELLNAMN mot den modell du redan har installerad. På macOS och Linux används normalt curl; i PowerShell på Windows kan du skriva curl.exe för att anropa samma program.

1. Dokumentera servern och modellen

curl.exe -s http://localhost:11434/api/version
curl.exe -s http://localhost:11434/api/tags

Kopiera versionsnumret och den valda modellpostens digest och kvantiseringsnivå till testloggen. Kör inte vidare om du inte säkert kan identifiera rätt post.

2. Lasta av modellen

curl.exe -s http://localhost:11434/api/generate -H "Content-Type: application/json" -d '{"model":"MODELLNAMN","keep_alive":0}'

Ollamas FAQ anger att keep_alive: 0 lastar av modellen direkt. Kontrollera vid behov med ollama ps att modellen inte längre står som laddad. Det här skapar en kall modellkörning i Ollamas mening; det tömmer inte operativsystemets filcache och motsvarar inte en omstartad dator.

3. Kör det kalla anropet

curl.exe -s http://localhost:11434/api/generate -H "Content-Type: application/json" -d '{"model":"MODELLNAMN","prompt":"Förklara skillnaden mellan RAM och VRAM på exakt tre korta meningar.","stream":false,"keep_alive":-1,"options":{"num_ctx":4096,"num_predict":96,"temperature":0,"seed":42}}' -o kall.json

Det negativa värdet för keep_alive lämnar enligt dokumentationen modellen laddad. num_predict sätter en maximal utdatamängd, medan seed, temperature och num_ctx hålls uttryckligen lika. De inställningarna gör jämförelsen mer kontrollerad, men de är ingen garanti för identiska svar mellan olika runtime-, modell- eller hårdvaruversioner.

4. Kör samma anrop varmt

curl.exe -s http://localhost:11434/api/generate -H "Content-Type: application/json" -d '{"model":"MODELLNAMN","prompt":"Förklara skillnaden mellan RAM och VRAM på exakt tre korta meningar.","stream":false,"keep_alive":-1,"options":{"num_ctx":4096,"num_predict":96,"temperature":0,"seed":42}}' -o varm.json

Begäran ska vara byte för byte likadan som den kalla, inklusive prompt och options. Den enda avsedda skillnaden är att modellen nu finns kvar i minnet. Lastas den ändå om har provet fångat just det, och då ska du kontrollera minnestryck, parallella modeller och serverns keep-alive-konfiguration innan du jämför tokenhastighet.

5. Läs ut fälten och städa efteråt

$cold = Get-Content .\kall.json -Raw | ConvertFrom-Json
$warm = Get-Content .\varm.json -Raw | ConvertFrom-Json

$cold | Select-Object total_duration,load_duration,prompt_eval_count,prompt_eval_duration,eval_count,eval_duration
$warm | Select-Object total_duration,load_duration,prompt_eval_count,prompt_eval_duration,eval_count,eval_duration

När provet är klart kan du skicka samma tomma anrop med keep_alive: 0 igen för att frigöra minnet. Om du använder strömmande svar i ditt verkliga arbetsflöde finns användningsfälten i den sista delen, där done är true. I just diagnosprovet minskar stream: false risken att du råkar mäta eller spara en ofullständig del.

Upprepa tre par och jämför medianen

Ett enda kallt–varmt par kan påverkas av en tillfällig bakgrundsprocess. Kör därför tre par med samma ordning: lasta av, kör kallt, kör varmt. Spara alla sex JSON-svar. Jämför medianen för varje fält i stället för att välja den snabbaste körningen.

Använd en enkel tabell med en rad per anrop:

Körning	Laddning	Prompt: token/tid	Utdata: token/tid	Total
Par 1 kall	`load_duration`	`count / duration`	`count / duration`	`total_duration`
Par 1 varm	`load_duration`	`count / duration`	`count / duration`	`total_duration`
Par 2–3	Samma fält och samma enheter

Konvertera nanosekunder till sekunder genom att dividera med en miljard. Behåll gärna originalvärdet bredvid det avrundade; då kan någon annan kontrollera din uträkning senare.

Så tolkar du mönstret

Hög laddningstid bara i den kalla körningen. Då är modelladdningen en betydande del av väntan för sällsynta anrop. Jämför modellens storlek med tillgängligt minne och pröva sedan ett medvetet keep-alive-värde mot din minnesbudget. Ett längre värde kan minska återkommande laddning men håller samtidigt minne upptaget; det är en driftavvägning, inte en kostnadsfri fartknapp.

Prompttiden dominerar både kallt och varmt. Kontrollera först att prompt_eval_count verkligen är lika mellan körningarna. Prova därefter en kortare och en längre version av samma testunderlag, en ändring i taget. Om token per sekund är likartat men den långa prompten tar längre tid har du främst mätt mer indata, inte en plötsligt långsammare runtime.

Genereringstiden dominerar. Jämför eval_count och beräknad utdatatakt. En modell som avslutar före gränsen på 96 token ska inte jämföras i rå sekunder med en som använder hela utrymmet. Behåll därför både antal token och tid i tabellen.

Det varma anropet laddar också modellen. Kontrollera om modellen försvann ur ollama ps, om en annan modell trängde undan den eller om ett serverövergripande OLLAMA_KEEP_ALIVE påverkar körningen. API-parametern ska enligt FAQ:n ha företräde framför den miljövariabeln, vilket gör en avvikelse värd att dokumentera med exakt version och logg.

Den externa väntan är mycket längre än total_duration. Mät då klienten och transporten separat. Ändra inte modell, kvantisering och klient på samma gång; annars går det inte att säga vilken förändring som flyttade tiden.

Det resultatet får — och inte får — säga

Provet kan säga vilken del som dominerar på den dokumenterade maskinen, med den dokumenterade modellfilen, kvantiseringen, Ollama-versionen och lasten. Det kan också visa om återkommande modelladdning är relevant för just ditt anropsmönster.

Det kan inte visa att en modell eller dator är ”snabbast” i allmänhet. Byter du modellens digest, kvantisering, kontextgräns, runtimeversion, drivrutin, maskin eller samtidighet har du ett nytt testfall. Behåll den gamla raden och skriv en ny i stället för att skriva över resultatet.

För ett beslut om uppgradering är den användbara frågan därför inte ”hur många token per sekund fick jag?”, utan ”vilket av de tre leden förändrades när jag bytte exakt en sak?”.

Källor

Ollamas dokumentation kontrollerades 19 september 2026. API-fält, standardvärden och runtimebeteende är versionskänsliga. Nästa kontroll sker vid en förändring av Usage-, Generate- eller FAQ-sidorna, eller senast 19 oktober 2026.

Nästa steg

Spara testprotokollet bredvid modell- och runtimeversionerna, så att nästa mätning går att jämföra utan att förutsättningarna gissas.

Öppna driftguiden