Ollamas v0.34.3-rc1 är en förhandsversion, märkt Pre-release den 19 september 2026. En av dess releasenoteringar säger att GET /api/show nu annonserar varje modells tänkkontroller och förval. Det löser första frågan i ett prestandatest: vilka lägen ska du ens jämföra? Men svaret är modellbundet. Releasens exempel för molnmodellen glm-5.3-flash:cloud visar low, high och max, med max som förval; det är inte en universell lista.
Läs först /api/version, sedan /api/show för den exakta modelltaggen. API-referensen för den stabila versionen dokumenterar ännu inte ett thinking-fält i show-svaret. Ett saknat fält på din burk betyder därför inte att modellen saknar stöd; börja med att kontrollera vilken serverversion som faktiskt svarar.
Läs modellens nivåer – utan att anta dem
Utgåvenoteringen visar följande form för sin modell. Spara hela svaret i testmappen tillsammans med version och modellnamn. Värdena är stöd i just den servern och just den modellen, inte ett löfte om vilket läge som passar din arbetsuppgift.
curl.exe -s http://localhost:11434/api/version
curl.exe -s http://localhost:11434/api/show -H "Content-Type: application/json" -d '{"model":"MODELLNAMN"}'
# releasens exempel för glm-5.3-flash:cloud
{"thinking":{"values":["low","high","max"],"default":"max"}}Thinking-dokumentationen säger att de flesta modeller tar think som true/false eller som low, medium, high och max, där max begär högsta nivån. “De flesta” är den viktiga begränsningen. GPT-OSS ska i stället få en av nivåsträngarna low, medium eller high; booleska värden ignoreras där. Om show-svaret eller modellens dokumentation inte erbjuder avstängt läge, stryk den raden ur provet.
Skicka samma fråga med en enda skillnad
För ett jämförbart prov fryser du modell, digest, Ollama-version, prompt, kontext, temperatur, seed och tokenbudget. Kallstartsartikeln beskriver varför serverns tidsfält ska hållas isär; här lägger vi bara till tiden tills första riktiga svarstoken kommer i ett strömmande chattsvar. Sätt bara think olika mellan körningarna.
curl.exe -N http://localhost:11434/api/chat -H "Content-Type: application/json" -d '{
"model":"MODELLNAMN",
"stream":true,
"think":"low",
"messages":[{"role":"user","content":"Förklara skillnaden mellan RAM och VRAM på tre korta meningar."}],
"options":{"temperature":0,"seed":42,"num_ctx":4096,"num_predict":96}
}'Kopiera begäran tre gånger och byt enbart "low" till de värden din modell faktiskt annonserar, exempelvis "high" och "max". Finns avstängt läge, gör en fjärde begäran med "think":false. Streaming spelar roll: dokumentationen placerar resonemanget i message.thinking och svaret i message.content för chat. Tid till första svarstoken är alltså klockslaget för första delen med icke-tomt message.content, inte den första thinking-delen.
Fyll tabellen med råvärden och sekunder
Mät varje rad minst tre gånger och redovisa medianen eller spannet, inte bara snabbaste svaret. Slutdelen av chat-svaret innehåller total_duration, load_duration, prompt_eval_count, prompt_eval_duration, eval_count och eval_duration. Tiderna är nanosekunder: dela med 1 000 000 000 för sekunder och behåll råvärdet. Dokumentationen säger inte om eval_count inkluderar tänktoken, så kalla det totalt antal genererade token och mät tänkspåret separat som antal tecken i message.thinking.
| Läge | Till första svarstoken (s) | Total tid (s) | eval_count | Tänkpår (tecken) |
|---|---|---|---|---|
| Av, om modellen stödjer det | — | — | — | — |
| Low | — | — | — | — |
| High | — | — | — | — |
| Max | — | — | — | — |
Tomma celler är avsiktliga: det finns inga egna benchmarkvärden här. Din första svarstid inkluderar klientens klocka och strömmen fram till innehåll; total_duration är serverns eget mått. Jämför dem inte som samma sak. Om modellen laddas om mellan raderna har du dessutom blandat in kallstart; håll den laddad eller kör hela uppsättningen kallt per rad och redovisa det.
Välj förvalet som din uppgift klarar
En högre nivå är inte automatiskt bättre och en snabbare rad är inte automatiskt tillräcklig. Läs svaren mot ett krav du skrivit före testet: i detta exempel exakt tre korta meningar som korrekt skiljer RAM från VRAM. Om low uppfyller kravet med mindre väntan kan det vara skriptets förval. Om high eller max behövs, dokumentera den uppmätta fördröjningen och sätt nivån uttryckligen i anropet i stället för att ärva ett okänt förval.
Skriv resultatet på driftkortet i driftguiden: modelltagg och digest, serverversion, tillåtna nivåer, vald nivå, prompt, mått och datum. Eftersom detta är en release candidate bör du också ha en väg tillbaka; versionsartikeln visar hur du antecknar den senaste fungerande utgåvan och testar återställningen. En ny version, ny modellfil eller ny kontextgräns är ett nytt testfall.
Källor och metod
- Ollama v0.34.3-rc1: Pre-release-status, datum och releasenoteringens exempel för
GET /api/show - Ollama Thinking: stödda think-värden, GPT-OSS-avgränsningen, CLI-exempel och strömmande thinking/content
- Ollama API – chat:
think, responsefält och användningsmått med nanosekunder och tokenantal - Ollama API – Show model details: stabilt dokumenterade svarsfält vid kontrollen
Källorna kontrollerades 19 september 2026. v0.34.3-rc1 är en Pre-release, och artikelns uppgift om thinking i /api/show avgränsas till releasenoteringen för den versionen. Releasens nivålista återges endast som exempel för dess namngivna molnmodell. Inga egna körningar eller uppmätta tider publiceras; tabellen är ett testprotokoll. API-referensen dokumenterar inte om eval_count omfattar tänktoken, därför används tecken i thinking-fältet som separat mått.
Kör en rad per annonserat läge, spara råsvaren och sätt först därefter ett uttryckligt think-värde i skriptet.