Ollama traag op Mac? Controleer laden, context en geheugen

Ollama kan traag zijn omdat een model nog laadt, een prompt een grote context heeft, een deel van het model op de CPU draait of de Mac onder geheugendruk staat. Die gevallen vragen elk een andere aanpak. Gedownloade modellen verwijderen kan schijfruimte vrijmaken, maar maakt het model dat nu een antwoord genereert niet automatisch sneller.

Vergelijk koud laden met een tweede verzoek

Houd het model, de prompt en de instellingen gelijk. Voer een kort verzoek uit en herhaal het terwijl het model geladen blijft. Als alleen het eerste verzoek traag is, is laden een nuttige aanwijzing. Als beide traag genereren, onderzoek dan de uitvoering en het geheugen. Leg de vergelijking vast in plaats van één antwoord als benchmark te behandelen.

De API-documentatie van Ollama bevat afzonderlijke timingvelden zoals load_duration, prompt_eval_duration en eval_duration in voltooide antwoorden. Die onderscheiden laden, het lezen van de prompt en het genereren van uitvoer. Vergelijk tokensnelheden van verschillende modellen, contextgroottes of prompts niet alsof ze één wijziging meten.

Meet één lokale aanvraag per fase

Voor een lokale server op de gebruikelijke poort maakt de volgende aanvraag de timingvelden makkelijker te inspecteren door één JSON-antwoord te retourneren. Vervang MODEL_NAME door een al geïnstalleerd lokaal model uit ollama list; gebruik voor deze vergelijking geen cloudmodel. De aanvraag voert inferentie uit en verbruikt resources, maar verwijdert geen modelgegevens.

curl -sS http://localhost:11434/api/generate \
  -H 'Content-Type: application/json' \
  -d '{"model":"MODEL_NAME","prompt":"Explain what a file cache does in two sentences.","stream":false,"options":{"num_predict":128}}'

Voer dezelfde aanvraag opnieuw uit terwijl het model geladen blijft. Met streaming uitgeschakeld toont de terminal het antwoord pas na voltooiing, dus deze opdracht is bedoeld voor de geretourneerde timingvelden, niet om de eerste token op het oog te timen. Als de aanvraag mislukt, bewaar dan de fout en stop de vergelijking in plaats van een ontbrekend veld als nul te interpreteren.

De gedocumenteerde duurwaarden zijn in nanoseconden. Deel een duur door 1.000.000.000 om seconden te krijgen. Voor de uitvoersnelheid deel je eval_count door eval_duration / 1,000,000,000, mits de duur positief is. Als rekenvoorbeeld: 100 tokens over 5,000,000,000 nanoseconden is 20 tokens per seconde; dat is geen gemeten resultaat voor welke Mac of welk model dan ook.

Deel uitvoertokens niet door de totale duur en noem dat dan pure generatiesnelheid. Dat zou ook het laden en het invoerwerk omvatten. Let ook op of de herhaalde prompt gebruikmaakt van gecachte invoer, want een snellere tweede aanvraag kan zowel door een warm model als door hergebruik van de prompt komen. Bewaar het volledige antwoord in plaats van alleen het meest gunstige getal te rapporteren.

Bekijk wat er werkelijk geladen is

Inspecteer in Terminal de huidige status:

ollama ps

De Ollama FAQ legt de kolom PROCESSOR uit. Die kan GPU, CPU of een splitsing tonen. De hardwaregids documenteert Metal-versnelling op Apple GPU's. Als je verwachtte dat een lokaal model de GPU zou gebruiken, is het actieve resultaat nuttiger dan een aanname op basis van de naam van de Mac.

Controleer ook of het verzoek naar de lokale server gaat die je inspecteert. Een front end kan naar een andere host of een cloudmodel wijzen. In dat geval beschrijft de lokale ollama ps-uitvoer het externe verzoek niet.

Verklein de context voordat je de modelgrootte de schuld geeft

Modelbestanden zijn maar een deel van de geheugenbehoefte. Een grotere context vraagt extra geheugen, en gelijktijdige verzoeken voegen werk toe. De documentatie over contextlengte van Ollama beschrijft hardwareafhankelijke standaardwaarden en de contextinstelling van de app. Ga er niet van uit dat elke installatie dezelfde standaardwaarde heeft.

Gebruik voor een gecontroleerde test een korte prompt, één verzoek en een kleinere context die nog steeds de informatie bevat die voor die test nodig is. Als de volledige coderingstaak later meer context vereist, herstel dan genoeg om de betekenis te behouden. Een sneller antwoord dat stilzwijgend vereiste instructies verliest, is geen geslaagde optimalisatie.

Probeer een kleiner model of een andere kwantisering alleen als aparte vergelijking. Dat verandert zowel het resourcegebruik als de antwoordkwaliteit. Houd een paar representatieve vragen bij zodat je kunt beoordelen of de snellere optie nuttig blijft.

Test een contextwijziging zonder die permanent te maken

Voor een korte diagnostische prompt accepteert de API een contextoptie per aanvraag. Voeg in de voorgaande aanvraag "num_ctx":4096 toe binnen options, naast num_predict, met een lokaal model dat die context ondersteunt. Dit is een voorbeeld van een testgrootte, geen aanbevolen instelling voor elk model of elke codeertaak.

Houd het model en de prompt ongewijzigd, inspecteer vervolgens het draaiende model met ollama ps en vergelijk de geheugendruk. Verklein de context niet rond een groot gesprek en ga er niet van uit dat het antwoord nog steeds elke instructie bevat. Vergelijk eerst een kleine taak die past; test daarna de werkelijke werklast met genoeg context voor de invoer.

De FAQ en de aparte pagina over contextlengte beschrijven standaardwaarden verschillend, dus deze gids gaat niet uit van één universele standaardwaarde. Een app-instelling, een front end of een optie op aanvraagniveau kan de actieve waarde ook beïnvloeden. Waar de geïnstalleerde versie CONTEXT in ollama ps rapporteert, noteer je die waarde naast PROCESSOR in plaats van die af te leiden uit de bestandsgrootte van het model.

Een lagere geheugenwaarde is niet de enige succesvoorwaarde. De taak moet nog steeds met acceptabele antwoorden worden voltooid, en de rest van de Mac moet bruikbaar blijven. Als een kleinere context belangrijke feiten weglaat of de wijziging geen herhaalbaar verschil maakt, verwijder je de testoptie en herstel je de vorige werkende opzet.

Houd de hele Mac in het oog tijdens het genereren

Open Activiteitenweergave › Geheugen en houd de druk in het oog tijdens het genereren, niet pas nadat het antwoord klaar is. Apple Silicon gebruikt gedeeld systeemgeheugen, dus andere apps tellen ook mee. Dat een model op schijf past, betekent niet dat het comfortabel naast de rest van je werkbelasting past.

Sla je werk op en sluit een onnodige zware taak, en herhaal dan hetzelfde verzoek. Als de druk verbetert en de vertraging daarmee verandert, heb je een nuttige aanwijzing. De gids over geheugendruk legt uit hoe je de indicatoren van de Mac leest zonder elke gecachte byte als verspilling te zien.

Laad een inactief model uit zonder het te verwijderen

Wacht eerst tot elk verzoek dat het model gebruikt klaar is. Gebruik ollama stop gevolgd door de exacte naam uit ollama ps om een geladen model dat je niet meer nodig hebt vrij te geven:

ollama stop MODEL_NAME

Vervang MODEL_NAME voordat je de opdracht uitvoert. Dit laadt het model uit het geheugen. Het verwijdert de gedownloade bestanden niet, en het volgende verzoek kan opnieuw de laadkosten betalen. Een model tussen verzoeken herhaaldelijk uitladen kan de ervaring daardoor juist trager maken.

Als schijfruimte de werkelijke beperking is, bekijk opgeslagen modellen dan apart in de richtlijn voor het opruimen van AI-modellen. Bewaar lokaal gemaakte modellen en alles wat je niet betrouwbaar opnieuw kunt downloaden. Vergelijk voor prestaties één wijziging tegelijk en houd het resultaat gekoppeld aan dezelfde werkbelasting.

Onderzoek een verschil met het serverlogboek

Als de lokale aanvraag traag blijft of de verdeling over processors onverwacht is, wijst de troubleshootinggids van Ollama het Mac-serverlogboek aan op ~/.ollama/logs/server.log. Lees het deel rond het tijdstip van de test en zoek naar laadfouten, problemen met geheugentoewijzing of de gekozen uitvoeringsbackend. Bij een handmatig gestarte server staan de bijbehorende meldingen mogelijk in plaats daarvan in de terminal.

Noteer de Ollama-versie, de exacte modeltag, de context, de verdeling over processors en de fase die de timings domineert. Controleer logfragmenten op privéprompts en lokale paden voordat je ze deelt. Wijzig niet meerdere GPU- of serveromgevingsvariabelen alleen omdat ze in een oud optimalisatiebericht staan; het logboek moet eerst het verschil aanwijzen dat een wijziging moet oplossen.