Ollama avbryter svaret: tokenbudget, stoppord och timeout

Svaret slutar efter en halv mening. Det kan locka dig att genast höja en gräns, men börja med att spara vad Ollama faktiskt skickade. Ett avslut i modellen, en stoppsekvens och ett avbrutet klientanrop behöver undersökas på olika sätt. Den sista synliga meningen räcker inte för att välja åtgärd.

Målet här är ett litet felsökningsunderlag: exakt modell och version, skickad tokenbudget, stoppinställningar, slutobjekt och eventuellt klientfel. Du gör sedan ett omprov där en misstänkt inställning ändras. Det ger en prövbar förklaring till just din körning, utan att göra ett längre svar till bevis på högre kvalitet.

1. Spara en lokal baslinje

Använd en redan installerad textmodell som du vet körs lokalt. Välj inte en molnmodell eller en fjärrmodell bakom ett lokalt modellnamn. Ollamas CLI-referens visar modellistan med ollama ls. Kopiera ditt exakta namn och tagg från den egna installationen, och bekräfta modellens ursprung innan du fortsätter. Adressen till den lokala servern säger inte ensam var modellberäkningen sker.

Öppna en separat provmapp och spara den version installationen rapporterar samt modellistan. Visa också modellens Modelfile med det dokumenterade exportkommandot. Läs samtliga stopprader och anteckna klientens egna inställningar bredvid dem. Det som syns i modellfilen är inte hela underlaget om chattprogrammet skickar ytterligare alternativ.

ollama --version
ollama ls
$modell = Read-Host 'Exakt namn och tagg för din installerade lokala textmodell'
ollama show --modelfile $modell |
    Set-Content -Encoding UTF8 ./Modelfile.original

2. Samla ett helt API-svar

Följande läsarprov använder Windows PowerShell 5.1 och generate-API:t. Frågan beställer åtta numrerade punkter. En medvetet liten första budget, 64 tokens, gör det möjligt att undersöka en gräns utan att ändra frågan. Värdet är ett försöksval, ingen allmän rekommendation. Håll modell, fråga, stopp och övriga alternativ fasta under jämförelsen.

Enligt streamingdokumentationen ger stream: false ett sammanhållet JSON-svar. Det förenklar insamlingen här. Provet återskapar inte automatiskt allt som din chattklient skickar; jämför därför dess verkliga anrop separat om felet bara finns där.

$anrop = @{
    model = $modell
    prompt = 'Skriv exakt åtta numrerade punkter om hur man testar en säkerhetskopia. Varje punkt ska vara en hel mening.'
    stream = $false
    options = @{ num_predict = 64 }
}
$timeoutSek = 120
function Invoke-LokaltProv {
    param([string]$fil)
    $svar = $null
    $json = $anrop | ConvertTo-Json -Depth 8
    $bytes = [System.Text.Encoding]::UTF8.GetBytes($json)
    try {
        $svar = Invoke-RestMethod -UseBasicParsing -Method Post `
            -Uri 'http://127.0.0.1:11434/api/generate' `
            -ContentType 'application/json; charset=utf-8' `
            -Body $bytes -TimeoutSec $timeoutSek -ErrorAction Stop
        $svar | ConvertTo-Json -Depth 20 |
            Set-Content -Encoding UTF8 $fil
        $svar | Select-Object model, done, done_reason, eval_count
        $svar.response
    } catch {
        $_ | Out-String | Set-Content -Encoding UTF8 ($fil + '.fel.txt')
        throw
    }
}
Invoke-LokaltProv -fil './prov-64.json'

Spara även requesten och klockslaget för varje försök. Microsofts referens för Invoke-RestMethod dokumenterar JSON-hanteringen och klientparametern TimeoutSec. Här är 120 sekunder ett valt väntetak. Ett fel sparas separat så att ett gammalt lyckat svar inte får representera det misslyckade försöket.

3. Läs avslutet innan du väljer åtgärd

API-referensen beskriver done som avslutsflagga, done_reason som avslutsorsak och eval_count som antal genererade tokens. Ett sant done säger inte att åtta punkter blev färdiga. Kontrollera texten mot beställningen: finns åtta numrerade punkter och är den åttonde meningen avslutad? Bedöm sakuppgifterna separat.

Referensen visar stop men publicerar ingen fullständig enum. I den granskade runnerimplementationens completionväg översätts stopp av typen limit till length; övriga avslut i den grenen får stop. Den interna typens strängkonvertering bekräftar dessa namn. Det är stöd för tolkningen i den kodvägen, inte ett facit för samtliga modeller eller installerade versioner.

Tabellen är ingen uttömmande värdelista. Generate-handlern innehåller också särskilda svar med load och unload. Om du får ett annat värde sparar du det ordagrant och kontrollerar den egna versionens beteende i stället för att översätta det till timeout på egen hand.

4. Prova bara den misstänkta gränsen

Om underlaget pekar mot tokenbudgeten använder du samma funktion igen och ändrar enbart num_predict från 64 till 256. Parametertabellen beskriver num_predict som gränsen för förutsagda tokens. num_ctx beskriver kontextfönstret. Att höja det senare är därför inte samma försök; fortsätt vid behov i artikeln om kontext och minnesgräns.

$anrop.options.num_predict = 256
Invoke-LokaltProv -fil './prov-256.json'

Jämför de två sparade slutobjekten och räkna punkterna igen. Om det korta försöket rapporterar length och det längre når åtta avslutade punkter har du stöd för att budgeten begränsade det första försöket. Om båda slutar tidigt med stop behöver nästa spår undersökas. Mer utrymme innebär inget löfte om korrekt innehåll eller att modellen slutför beställningen.

5. Kontrollera egna stoppsträngar och klientens väntetak

Enligt Modelfile-referensen avbryter stop genereringen när mönstret påträffas, och flera stopprader kan anges. En egen sträng som ”Slutsats” kan därför krocka med vanlig svarstext. Spara den exakta strängen, inklusive blanksteg och radbrytningar. Ändra bara den misstänkta egna inställningen i ett nytt prov; behåll tokenbudget och timeout från jämförelsebasen.

Radera inte modellens alla stoppmarkörer som en generell reparation. Om misstanken gäller den importerade modellens chattformat behöver du granska mallen och dess ursprung i artikeln om Ollamas promptmall. Ett stop-värde och ett kort svar bevisar inte ensamma ett fel i en viss stopprad.

Vid ett uttryckligt klientfel om timeout gör du i stället ett separat försök där requesten är oförändrad och bara väntetaket höjs, exempelvis från 120 till 240 sekunder. Börja från samma sparade baslinje, inte från ett samtidigt budgetbyte. Anteckna om ett helt slutobjekt nu kommer fram och jämför med klientens faktiska feltext. Enbart frånvaron av slutobjekt visar inte att timeout var orsaken.

Strömmande anrop kräver att klienten läser de enskilda JSON-objekten och kontrollerar avslutet, inte bara visar response-texten. Behåll sista mottagna objektet, eventuell error-text och anslutningens status. Om direktprovet fungerar men chatten slutar tidigt blir nästa konkreta kontroll skillnaderna i skickade alternativ och klientens transporthantering.

Lämna ett underlag som går att upprepa

Spara en rad per försök: modell och version, fråga, num_predict, egna och lagrade stopp, klienttimeout, done, done_reason, eval_count och klientfel. Markera vilken enda inställning som ändrades samt om åtta punkter blev färdiga. Skriv ”orsak inte fastställd” när observationerna inte skiljer hypoteserna åt. Då kan nästa felsökning börja med bevarade data i stället för minnet av en avklippt mening.

Källor och metod

• Ollama Generate API – request och responsefält.
• Ollama Streaming – strömmande och sammanhållet svar.
• Ollama Modelfile – stop, tokenparametrar och export.
• Ollama CLI – modellistan.
• Ollamas runnerkod, interna avslutstyp och API-handler – granskad implementation.
• Microsoft PowerShell 5.1 – HTTP-anrop och TimeoutSec.

Primärkällorna kontrollerades 24 okt 2026. Dokumentation och main-kod är löpande; kontrollera din installerade version vid avvikelse. Exemplen är föreslagna läsarprov. Redaktionen har inte kört en lokal modell eller mätt en förbättring.