Ollama of LM Studio: configuratie bepaalt de keuze

Kies LM Studio als je lokale modellen vooral in een grafische omgeving wilt zoeken, laden en afstellen. Kies Ollama als terminalopdrachten en scripts het vertrekpunt zijn. Beide kunnen modellen via een lokale API aanbieden; voor de snelheid geeft de programmanaam alleen geen betrouwbare voorspelling.

Bij gebruik van hetzelfde GGUF-model lopen beide via een llama.cpp-kern. Toch kunnen de meegeleverde build, instellingen en hardware een zichtbaar verschil maken. Een snelheidsuitslag is daarom pas bruikbaar als je weet welk modelbestand, welke taak en welke configuratie zijn vergeleken.

Grafische bediening en terminalwerk

LM Studio biedt in de desktopapp een zichtbare route van model zoeken en downloaden naar laden, chatten en instellingen aanpassen. Dat past bij iemand die geregeld modellen verkent of promptinstellingen wil bijstellen. De uitleg van LM Studio over de app, lms en llmster beschrijft ook een commandoregeltool en een zelfstandige dienst zonder grafische interface. De app is dus het duidelijke startpunt voor grafisch werk, terwijl dezelfde productfamilie ook in scripts en op een machine zonder scherm kan dienen.

Bij Ollama begint een herhaalbare werkwijze eenvoudig met terminalopdrachten om een model op te halen en te starten. De snelstartgids van Ollama toont daarnaast de app en lokale API-aanroepen. Ollama uitsluitend als terminalprogramma beschrijven zou daardoor te beperkt zijn. Het onderscheid zit eerder in de handeling die je het vaakst uitvoert: modellen en instellingen verkennen in een venster, of een gekozen model met een opdracht opnieuw beschikbaar maken.

Voor een eenmalig gesprek kan de zichtbaarheid van instellingen zwaarder wegen dan de vorm van een startcommando. In een terugkerende taak is juist van belang hoe gemakkelijk je dezelfde modelkeuze en aanroep vastlegt. Beide programma’s kunnen in zo’n proces passen; een voorkeur voor een grafische interface sluit automatisering bij LM Studio niet uit.

Welke lokale API past bij je toepassing?

Voor bestaande OpenAI-clients is Ollama een directe kandidaat. De Ollama-documentatie voor OpenAI-clients gebruikt de lokale basis-URL http://localhost:11434/v1/ en toont aanroepen voor Chat Completions en Responses. Zij omschrijft de ondersteuning als een deel van de OpenAI-API. Een ander basisadres en een lokaal model kunnen dus voldoende zijn voor een eenvoudige toepassing, maar alleen wanneer de gebruikte endpoint en opties werkelijk worden ondersteund.

LM Studio kan eveneens een lokaal model via HTTP aanbieden. De serverdocumentatie van LM Studio noemt starten vanuit het tabblad Developer of met lms server start, plus een eigen REST-API en OpenAI- en Anthropic-compatibele endpoints. Voor een toepassing die al een bepaald clientprotocol gebruikt, is dat concreter dan een algemeen etiket als ‘API-ondersteuning’: het bepaalt welke aanroep je kunt aansluiten.

Compatibiliteit van een endpoint betekent nog geen volledige uitwisselbaarheid van toepassingen. Een chatclient die alleen tekst verstuurt vraagt iets anders dan software die gestructureerde antwoorden, toolaanroepen of gespreksstatus verwacht. De relevante vergelijking is daarom de volledige aanvraag en reactie van je eigen toepassing, inclusief het gekozen model en de opties. Een succesvolle verbinding met de server zegt op zichzelf weinig over de functies die daarna moeten werken.

Waarom de benchmark geen vaste winnaar oplevert

De benchmark van Mozilla gebruikte dezelfde GGUF-bestanden voor Ollama, LM Studio, llama.cpp en llamafile op een Mac Studio, een Linux-systeem met NVIDIA-GPU en een Steam Deck OLED. Bij gelijkgehouden gewichten en omgeving lagen de resultaten voor promptverwerking vaak dicht bij elkaar. Op de Steam Deck steeg die verwerking voor het geteste 9B-model met 63,3 procent toen de onderzoekers dezelfde llama.cpp/llamafile-code met andere Vulkan-shaderbibliotheken bouwden. Die stijging betreft de twee builds op dat apparaat; zij is geen rechtstreekse snelheidswinst van Ollama ten opzichte van LM Studio.

De onderlinge uitslagen waren ook niet overal gelijk. In de geteste Steam Deck-configuratie bleef de meegeleverde runtime van LM Studio achter, terwijl op de Mac de promptverwerking van verschillende servers dichter bijeen lag. Dat past bij de gedeelde kern zonder te betekenen dat de complete programma’s identiek presteren: wat een programma meelevert en hoe het op een platform draait, blijft meetellen.

Mozilla onderscheidde bovendien het verwerken van de invoer van het genereren van nieuwe tekst. Een lang document of groot codefragment maakt de eerste fase merkbaar; tijdens een gesprek valt vooral op hoe snel het antwoord verschijnt. Wie die metingen samenvoegt tot één ranglijst, kan een runtime belonen voor een onderdeel dat bij de eigen taak nauwelijks gewicht heeft. De gepubliceerde test mat doorvoer nadat de server draaide, maar geen laadtijd, tijd tot het eerste woord, geheugengebruik of gedrag bij gelijktijdige aanvragen.

Hetzelfde modelbestand is pas het begin van een eerlijke vergelijking

Een gelijke modelnaam garandeert niet dat beide programma’s dezelfde modelgewichten gebruiken. Een andere kwantisering kan de benodigde opslag en de prestaties veranderen; een andere backend of contextlengte verandert de werklast. Op Apple-hardware kunnen bovendien andere modelformaten in beeld komen dan GGUF. Wie de uitvoeringsomgeving wil vergelijken, moet daarom het exacte bestand vastzetten en vastleggen welke instellingen daadwerkelijk gelijk zijn.

Een vergelijking van de standaardinstellingen beantwoordt een andere, eveneens nuttige vraag: welke ervaring leveren de programma’s zonder aanpassingen? De Mozilla-meting hield de modelbestanden gelijk, maar liet eigen standaardinstellingen voor batching bestaan. Dat maakt haar waardevol als vergelijking van praktische configuraties, terwijl een verschil niet automatisch aan alleen de onderliggende modelkern kan worden toegeschreven.

De beschikbare hardware begrenst beide routes. Een model met een ruime context moet in het beschikbare geheugen passen; anders wordt een kleiner model of een andere kwantisering relevanter dan een wissel van programma. De test sloeg het grootste model op de Steam Deck over wegens geheugenbeperkingen. Dat laat zien waarom een uitslag van een zware GPU niet zonder meer voorspelt wat een draagbaar apparaat of een computer met minder geheugen zal doen.

De keuze in de praktijk

Voor grafisch modelbeheer is LM Studio de logischere eerste keuze; voor een werkwijze die begint met herhaalbare terminalopdrachten ligt Ollama voor de hand. Heeft een bestaande toepassing een specifieke API nodig, dan weegt de ondersteuning van haar concrete endpoint en functies zwaarder dan die bedieningsvoorkeur. Beide producten kunnen lokaal serververzoeken verwerken en beide bieden meer dan alleen hun meest herkenbare interface.

Als beide aanroepen en bediening passen, beslist de combinatie van modelbestand, build, instellingen en eigen hardware over de prestaties die voor jou tellen. Vergelijk dan invoerverwerking en tekstgeneratie afzonderlijk met dezelfde taak. Zo blijft een opvallende benchmarkuitslag verbonden aan de configuratie die haar veroorzaakte, in plaats van aan een vermeende algemene winnaar.