Ollama använder CPU: felsök GPU-läget

Om Ollama använder CPU börjar felsökningen med att identifiera servern och läsa modellens placering medan den är laddad. Ett långsamt svar är inte tillräckligt för att slå fast CPU-fallback. Målet här är ett daterat diagnoskort: samma modell, samma endpoint, kolumnen PROCESSOR och en relevant loggrad. Därefter väljer du en avgränsad åtgärd och kontrollerar samma modell igen.

Identifiera vilken lokal server som svarar

Skriv ned adressen i det program där problemet märks. Jämför den med adressen du använder i terminalen. Om ett gränssnitt pekar på en container men terminalen frågar värddatorns app blir utskrifterna två olika observationer. Märk därför varje resultat med både endpoint och startform: app, systemtjänst, manuell server eller container. Ett modellnamn som finns på båda ställena räcker inte för att identifiera servern.

Ollamas FAQ anger standardbindningen 127.0.0.1:11434 och miljövariabeln OLLAMA_HOST för annan adress. Kontrollera din befintliga konfiguration före nästa steg. Ändra inte serverns bindning för att få ett felsökningskommando att fungera. Rikta i stället kontrollen mot den server som programmet redan använder.

För en app eller tjänst behöver du också läsa hur den startas. FAQ skiljer mellan plattformarnas sätt att sätta serverns miljövariabler. Ett värde i en ny terminal är inte bevis för vilket värde en redan startad app har. Spara adressen och startformen i diagnoskortet; vänta med att ändra en global miljövariabel tills du vet vilken process ändringen skulle påverka.

Läs ollama ps medan modellen är laddad

Enligt FAQ:s GPU-avsnitt visar ollama ps modeller som för tillfället ligger i minnet. Välj ett exakt modellnamn som redan finns i din installation. Förladda modellen med ett API-anrop utan prompt och kör ps direkt efteråt. Exemplet nedan är för PowerShell och en avsedd server på standardadressen. Bekräfta adressen först; om ditt program använder en annan endpoint behöver terminalen använda den adressen.

# Kör bara efter att du bekräftat den avsedda adressen.
# OLLAMA_HOST sätts i denna terminalsession.
$env:OLLAMA_HOST = 'http://127.0.0.1:11434'
$diagnosModell = Read-Host 'Ange exakt namn på en befintlig lokal modell'
$laddning = @{ model = $diagnosModell } | ConvertTo-Json
Invoke-RestMethod -Method Post -Uri "$env:OLLAMA_HOST/api/generate" -ContentType 'application/json' -Body $laddning | Out-Null
ollama ps

FAQ:s kortare variant, ollama run med en tom sträng som prompt, fungerar inte i Windows PowerShell 5.1: där skickas den tomma strängen inte vidare, så kommandot öppnar en interaktiv chatt och ps körs först när du lämnar den. Anropet ovan går dessutom uttryckligen till samma adress som ps-kontrollen. En embeddingmodell svarar med fel på detta anrop; välj en modell som genererar text.

Spara hela raden för din modell, inklusive namnet och PROCESSOR. Om listan är tom ska du inte fylla i CPU som resultat. Kontrollera först om du laddade modellen på samma server och om den fortfarande är kvar i minnet. Artikeln om keep-alive och minne behandlar livstiden separat. Ändra inte den inställningen samtidigt som du undersöker GPU-upptäckten.

För en befintlig container gör du kontrollen i den avsedda containerns miljö och noterar dess namn. Ollama i Docker visar installationens GPU-väg, modellvolym och ps-kontroll. Här fortsätter du med diagnosen efter observationen; du behöver inte skapa om containern bara för att samla den första raden.

PROCESSOR visar placering, inte beläggningsprocent

FAQ definierar tre former. Tabellen återger betydelsen, inte ett uppmätt resultat på din dator.

Procenten är alltså inte ett mått på GPU:ns aktuella utnyttjande. Använd inte raden för att uppskatta hur mycket snabbare ett svar borde vara. Om modellen är helt på GPU men första svaret dröjer har du en annan fråga att undersöka. Följ då metoden för att mäta kallstart i Ollama och behåll GPU-observationen som en egen uppgift.

Jämför GPU-upptäckten i loggen med aktuellt stöd

Ollamas felsökningsdokumentation beskriver loggplatsen efter startform. Välj bara raden för den server du redan identifierat. Kommandona läser befintliga loggar och ändrar ingen drivrutin.

# Windows-app, PowerShell
Get-Content -LiteralPath "$env:LOCALAPPDATA\Ollama\server.log" -Tail 120

# macOS-app, terminal
tail -n 120 ~/.ollama/logs/server.log

# Linux med systemd, terminal
journalctl -u ollama --no-pager -n 120

# Befintlig container: ersätt namnet med ditt faktiska containernamn
docker logs --tail 120 ollama-server

Vid manuell serverstart läser du terminalen där servern körs. Leta kring den relevanta starten och modellens laddning. Om utdraget saknar starten behöver du läsa längre tillbaka; frånvaro i de sista raderna bevisar inte utebliven GPU-upptäckt. Spara en faktisk rad och dess tid i stället för att skriva en egen sammanfattning som om den kom från loggen.

Felsökningsdokumentationen beskriver NVIDIA-inventering av kompatibilitet och tillgängligt GPU-minne samt att loggmeddelanden kan variera mellan utgåvor. Att servern hittar ett kort och att din modell ligger helt där är två skilda observationer. Matcha därför upptäckten med modellraden; kräv inte en viss äldre loggsträng för att godta observationen.

Den aktuella sidan om hårdvarustöd skiljer mellan NVIDIA, AMD på olika operativsystem, Metal och Vulkan. Jämför ditt exakta kort, operativsystem, drivrutin och Ollama-version med rätt avsnitt. Artikeln återger ingen komplett stödlista. Ett kortnamn från ett annat operativsystems lista är inget kompatibilitetsbesked för din installation.

Välj en åtgärd och kontrollera samma modell igen

Om adresserna skiljer sig är nästa åtgärd att rikta observationerna mot samma avsedda server. Om loggen visar utebliven upptäckt börjar du med stödjämförelsen och den dokumenterade anvisningen för din startform. Gör inget blint drivrutinsbyte och kopiera inga rättighetsändringar eller experimentella overrides från en annan plattform. Saknas ett tydligt nästa steg har du ändå ett användbart underlag för fortsatt felsökning.

Om GPU:n upptäcks men placeringen är blandad granskar du modellval och minnesvillkor först. FAQ:s avsnitt om samtidiga anrop beskriver hur kontext och parallellism påverkar minnesbehovet. Håll dessa lika i jämförelsen. En mindre modell kan vara en separat jämförelse, men skriv då ett nytt diagnoskort; blanda inte dess rad med den ursprungliga modellens resultat.

Efter en motiverad ändring laddar du samma modell på samma endpoint och läser ps igen. Anteckna vad du ändrade, vilket datum det gjordes och den nya loggraden. Om utfallet förblir CPU kan du avgränsa fortsatt arbete utan att börja om: serveridentiteten är kontrollerad och placeringen är dokumenterad.

Datum och klockslag:
Endpoint och startform:
Modell, exakt namn:
Ollama-version / OS / GPU / drivrutin:
PROCESSOR medan modellen är laddad:
Loggrad med tid, från samma server:
Stödavsnitt som jämförts:
En vald åtgärd:
Samma modell efter åtgärden:

Lämna okända fält tomma tills du har belägg. Diagnoskortet är färdigt när observationen och nästa avgränsade åtgärd går att förstå tillsammans. Det behöver inte innehålla ett löfte om att GPU-läget kan aktiveras för just din kombination.

Källor och metod

• Ollama FAQ: endpoint, laddning, PROCESSOR och minnesvillkor.
• Ollama Hardware support: kontroll av aktuell plattform och hårdvara.
• Ollama Troubleshooting: loggplatser och GPU-upptäckt.

Primärkällorna kontrollerades 14 oktober 2026. Kommandona är dokumentationsbaserade exempel; de har inte körts mot läsarens dator. Inga egna prestandatal eller genomförda hårdvaruprov redovisas. Kontrollera stödet på nytt när versions- eller plattformsförutsättningarna ändras.