Två frågor samtidigt i Ollama: skilj kötid från långsam generering

Den första frågan svarar snabbt. När två klienter använder samma lokala modell känns den andra plötsligt seg. Börja med ett jämförelseprov: håll modellen laddad, frys prompt och kontext och skicka först ett anrop, sedan två tillsammans. Resultatet ska bli ett kapacitetsprotokoll som hjälper dig välja hur många anrop du accepterar.

Bestäm två gränser före körningen

Skriv ditt högsta acceptabla svarstidstak i sekunder och dina minnestak i GiB. Välj också om modellen måste ligga helt på GPU eller om CPU-delning är acceptabel. En inställning som gör båda svaren färdiga tidigare tillsammans kan fortfarande göra varje enskild användares väntan för lång. Bestäm därför om du prioriterar interaktiv svarstid eller mängden färdiga svar.

Ollamas FAQ beskriver OLLAMA_NUM_PARALLEL som gränsen för parallella anrop per modell och OLLAMA_MAX_QUEUE som antalet väntande anrop innan ytterligare anrop avvisas. Parallell bearbetning kräver mer kontextminne. Möjligheten beror på tillgängligt minne; inställningen är inget hastighetslöfte.

Använd uttryckliga provvärden i stället för antagna standardvärden. Här jämför du parallellitet 1 och 2 med kögränsen 2 i båda lägena. Siffrorna är små testkandidater, inte rekommenderade förval. Kontrollera din version och backend: ett konfigurationsvärde i startmiljön räcker inte som bevis för att två anrop faktiskt bearbetas parallellt.

Datum, operativsystem och GPU: ____________________
Ollama-version och backend enligt serverlogg: ____________________
Modelltagg, modell-ID och kvantisering: ____________________
Kontext: 4096 token    svarstak: 220 token
Krav per svar: högst ______ s
Krav för två färdiga svar tillsammans: högst ______ s
Minnestak RAM / VRAM: ______ / ______ GiB
Processorplacering som accepteras: ____________________

Starta en kontrollerad server

Stäng andra klienter som använder samma Ollama-server. Anteckna modellen med ollama ls, versionsutskriften från ollama --version och serverns version från /api/version. Spara även backenduppgiften ur loggen. Använd en redan hämtad lokal textmodell som ryms med provets kontext; ett molnmodellnamn hör inte till det här provet.

På Windows kan du avsluta Ollama-appen och starta en separat server i PowerShell enligt nedan. Kontrollera att den tidigare servern har stängts och att den nya startar utan portfel. Miljövariablerna ska tillhöra processen som kör servern. För appstart och Linux-tjänster finns motsvarande konfigurationssätt i FAQ:s avsnitt om servermiljön.

$env:OLLAMA_NUM_PARALLEL = "1"
$env:OLLAMA_MAX_QUEUE = "2"
$env:OLLAMA_MAX_LOADED_MODELS = "1"
ollama serve

Kör klientprovet i ett annat terminalfönster. När hela första läget är färdigt stoppar du testservern med Ctrl+C och startar samma kommando igen med OLLAMA_NUM_PARALLEL = "2". Behåll kögräns, modell och övriga inställningar. Spara startloggen för båda lägena. Återställ din tidigare serverstart efter provet.

Bakgrunden om driftkort och versionsanteckningar finns i driftguiden. Har modellen redan ont om minne, välj först en fungerande nivå med kontextprovet. Ändra inte kontexten mitt i samtidighetsjämförelsen för att få den andra raden att passa.

Samma nyttolast, en eller två klienttrådar

Spara koden som samtidighet.py och kör den med Python 3. Den använder standardbiblioteket och skickar samma JSON till Ollamas generate-endpoint. stream: false ger ett samlat svar; keep_alive håller modellen laddad mellan närliggande körningar. Parametrarna följer Ollamas parameterreferens. Byt modellnamnet i körkommandot till din exakta lokala tagg.

Först gör skriptet en uppvärmning. Därefter körs tre omgångar med ett respektive två anrop. En trådbarriär släpper parets klienttrådar tillsammans; starttiderna visar den faktiska skillnaden i klientstart. Det innebär inte att servern får eller börjar behandla anropen exakt samtidigt. Varje körning sparar status, hela svaret och klientens tider i en ny katalog.

import concurrent.futures
import json
import pathlib
import sys
import threading
import time
import urllib.error
import urllib.request

model, label = sys.argv[1:3]
url = "http://127.0.0.1:11434/api/generate"
payload = json.dumps({
    "model": model,
    "prompt": "Förklara skillnaden mellan RAM och SSD för en nybörjare. "
              "Skriv exakt fyra numrerade punkter med högst 25 ord per punkt.",
    "stream": False,
    "keep_alive": "10m",
    "options": {"num_ctx": 4096, "num_predict": 220,
                "temperature": 0, "seed": 42}
}).encode("utf-8")
out = pathlib.Path(label)
out.mkdir(exist_ok=False)

def request(name, barrier=None):
    req = urllib.request.Request(url, data=payload,
        headers={"Content-Type": "application/json"})
    if barrier:
        barrier.wait()
    started = time.perf_counter()
    status, body, error = None, None, None
    try:
        with urllib.request.urlopen(req, timeout=120) as reply:
            status = reply.status
            body = reply.read().decode("utf-8")
    except urllib.error.HTTPError as exc:
        status = exc.code
        body = exc.read().decode("utf-8", errors="replace")
    except Exception as exc:
        error = str(exc)
    ended = time.perf_counter()
    record = {"name": name, "start": started, "end": ended,
              "client_seconds": ended - started,
              "http_status": status, "error": error, "body": body}
    (out / (name + ".json")).write_text(
        json.dumps(record, ensure_ascii=False, indent=2), encoding="utf-8")
    if status != 200 or error:
        raise RuntimeError(f"{name}: avbryt och läs den sparade felposten")
    parsed = json.loads(body)
    if parsed.get("done") is not True:
        raise RuntimeError(f"{name}: ofullständigt svar")
    return record

request("warmup")
for repeat in range(1, 4):
    # Växla ordning för att minska en enkel ordningseffekt.
    for count in ([1, 2] if repeat % 2 else [2, 1]):
        barrier = threading.Barrier(count)
        with concurrent.futures.ThreadPoolExecutor(max_workers=count) as pool:
            futures = [pool.submit(request, f"r{repeat}-n{count}-{i}", barrier)
                       for i in range(1, count + 1)]
            for future in futures:
                future.result()
print("Klart. Läs svar och tider i", out)

python samtidighet.py DIN-MODELL:DIN-TAGG parallel-1
# Starta om servern med OLLAMA_NUM_PARALLEL = "2".
python samtidighet.py DIN-MODELL:DIN-TAGG parallel-2

Välj nya katalognamn om du gör om provet. Kör ollama ps och läs av samma RAM- och VRAM-mätare under varje läge. Spara toppvärden och processorplacering. Uppvärmningen räknas inte i jämförelsen. Om modellen hinner lastas ur mellan körningarna får du värma igen; keep-alive-artikeln visar hur laddningen kontrolleras.

Skriptets nätverkstimeout är 120 sekunder och fungerar som ett avbrottsskydd för klienten, inte som ett uppmätt kapacitetstak. Det gör inga automatiska återförsök. Ett fel stoppar kommande omgångar, men ett redan startat syskonanrop kan fortfarande slutföras. Undersök felposten och servern innan du kör igen.

Räkna på fyra separata mått

Fältet body i varje sparad post innehåller Ollamas JSON-svar som text. Läs dess räknare tillsammans med client_seconds. Enligt Ollamas dokumentation om användningsmått anges serverns tider i nanosekunder. Dividera med en miljard för sekunder.

• Klienttid: client_seconds mäter från strax före HTTP-anropet tills hela svaret har lästs. Det är provets användarnära väntemått, utan gränssnittets rendering.
• Genereringshastighet: eval_count / (eval_duration / 1e9) ger utmatade token per sekund. Saknas fälten eller är tiden noll lämnar du måttet tomt och undersöker svaret.
• Laddning och prompt: jämför load_duration, prompt_eval_duration och tokenräknarna. Anteckna prompt_eval_cached_count om versionen lämnar fältet; en skillnad i cacheträffar kan annars se ut som ändrad kapacitet.
• Parets sluttid: ta den senare end minus den tidigare start inom samma par. Två dividerat med denna tid ger färdiga svar per sekund för just paret, om båda svaren godkänns.

Dra inte bort serverns total_duration från klienttiden och döp resten till kötid. Den aktuella API-referensen ger inget separat kömått och specificerar inte en sådan subtraktion som kömätning. Klientens intervall innehåller även transport och läsning; serverfältets mätgränser behöver beläggas för ditt bygge. För en isolerad kötid behövs loggning eller instrumentering som visar när samma anrop köas och börjar bearbetas. Kallstartsartikeln går igenom tidsfaserna för ett anrop.

Fyll kapacitetsprotokollet och tolka mönstret

För varje par ordnar du svaren efter avslutningstid som tidigt och sent. Sammanfatta medianen för de tre tidiga respektive tre sena svaren; behåll råposterna eftersom tre omgångar är ett litet felsökningsprov. Fyll även medianen för de tre ensamanropen och för parets sluttid. Tabellen innehåller inga uppmätta resultat.

Godkänn svaret om det har exakt fyra numrerade punkter, varje punkt innehåller högst 25 ord och beskrivningen korrekt skiljer arbetsminne från beständig lagring. Läs hela svaret; en snabb men avbruten text klarar inte uppgiften. Notera antal godkända svar, HTTP-fel och om placeringen ändrades för varje rad.

Om den sena klienttiden ökar men tokenhastigheten och svarslängden liknar ensamanropets är väntan före eller utanför genereringen en rimlig arbetshypotes. Om båda svarens tokenhastighet sjunker och placeringen eller minnestrycket ändras behöver du undersöka resursdelning. Om loggen saknar belägg för parallell bearbetning beskriver du resultatet som två samtidiga klientanrop med begärd parallellitet 2.

Välj kögräns och ett stopp för återförsök

Välj parallellitet 2 bara om den raden klarar dina förhandskrav och ger en nytta som du faktiskt behöver. Om 1 ger bättre interaktiv väntan kan du behålla 1 och begränsa klientens pågående anrop. Ett större kövärde skapar mer utrymme att vänta; det ersätter inte ett godkänt kapacitetsprov.

Provet med två klienter fastställer inte den största säkra kön. Börja därför med en liten vald gräns och prova separat den begränsade burst du verkligen förväntar dig. Ändra bara kögränsen i det delprovet. Dokumentera antalet erbjudna anrop, accepterade svar, avvisningar och den längsta väntan. Avbryt när ditt tidstak överskrids.

FAQ:n anger HTTP 503 vid överbelastning; full kö är en möjlig förklaring som du kontrollerar mot serverloggen. Som lokal klientpolicy kan du välja högst ett nytt försök efter en paus, men bara när kapacitet har frigjorts och frågans tidsbudget återstår. Det är artikelns försiktiga exempelpolicy, inte en Ollama-standard. Vid timeout avstår klienten från att skicka en kopia tills det tidigare anropets läge är känt.

Vald parallellitet: ______    vald kögräns: ______
Högst pågående anrop från min klient: ______
Godkända svar och fel per provrad: ____________________
Längsta accepterade väntan: ______ s
Återförsök: högst ______; paus ______ s; total tidsbudget ______ s
Avstå när: tidsbudget slut / tidigare anrop oklart / fortsatt överbelastning
Kör om provet vid byte av version, backend, modell eller hårdvara.

Källor och metod

• Ollama Modelfile: kontext, tokenbudget och samplingparametrar
• Ollama FAQ: samtidighet, kö, servermiljö och laddade modeller
• Ollama Generate: nyttolast och svarsfält
• Ollama Usage: tider, tokenräknare och cachemått
• Ollama Version: serverns versionsnummer
• Ollama CLI: lista modeller och körande modeller

Källorna kontrollerades 5 september 2026. Metoden är ett föreslaget lokalt prov; ingen Ollama-benchmark har körts för artikeln. Resultatet gäller din dokumenterade konfiguration och prompt. CLI- och versionskontrollerna ovan följer CLI-referensen och versionsendpointen.

Spara kapacitetsprotokollet tillsammans med version och inställningar i ditt driftkort.