Ollama rækker ikke, når hele firmaet vil have AI

Det begynder næsten altid på samme måde. En udvikler installerer Ollama på arbejdsstationen med det gode grafikkort, henter en model med én kommando og har ti minutter senere en lokal chatbot, der ikke sender et eneste ord ud af huset. Så vil kollegaen også prøve. For at kollegaen kan komme til, sætter nogen OLLAMA_HOST=0.0.0.0, så serveren lytter på hele netværket og ikke kun på maskinen selv.

Det er her, det går galt. I januar 2026 fandt sikkerhedsfirmaerne SentinelOne og Censys 175.000 Ollama-servere, der stod åbent på internettet i 130 lande. Knap halvdelen af dem tilbød værktøjskald, altså mulighed for at få modellen til at udføre handlinger og ikke kun skrive tekst. Ollama har ingen indbygget adgangskontrol. Det er et bevidst valg fra udviklerne, der mener, at du selv skal sætte en proxy foran.

Ollama er ikke et dårligt værktøj. Det er bare bygget til én maskine og én bruger, og i det øjeblik flere skal dele de samme grafikkort, har du brug for en anden slags software: en inference-orkestrator, der fordeler modeller, maskiner og brugere. Udvikleren Stefy Lanza fra Nexlab har netop sammenlignet de værktøjer, der findes i september 2026. Kort fortalt afhænger valget af din hardware. Én maskine peger mod Ollama, en stak Mac'er mod exo, en afdelings GPU-servere mod GPUStack eller Xinference, og mange samtidige brugere på én model mod vLLM.

Ollama er perfekt, lige indtil kollegerne vil være med

Med 181.000 stjerner på GitHub er Ollama det mest populære værktøj i hele sammenligningen, og det er fortjent. Du installerer ét program, skriver ollama pull efterfulgt af et modelnavn og har et svar. Sætter du Open WebUI foran, får du en chatbrugerflade, som også kolleger uden teknisk baggrund kan bruge. Til en bærbar eller en enkelt stationær computer er der ingen grund til at gøre det mere kompliceret.

Grænsen viser sig, når flere spørger på samme tid. Red Hat målte i 2025 Ollama mod vLLM på det samme grafikkort, et Nvidia A100 med 40 GB, og med den samme model, Llama 3.1 8B. Ved én bruger var forskellen lille. Ved fuld belastning leverede vLLM 793 tokens i sekundet mod Ollamas 41. Selv da Red Hat skruede op for, hvor mange forespørgsler Ollama måtte behandle parallelt, fladede kurven ud, mens vLLM blev ved med at skalere næsten lineært.

Forskellen skyldes to teknikker, som vLLM er bygget op omkring. Med continuous batching bliver nye forespørgsler lukket ind i den beregning, der allerede kører, i stedet for at vente på, at den forrige bliver færdig. PagedAttention styrer modellens KV-cache, den arbejdshukommelse, hvor modellen gemmer sine mellemregninger for de ord, den allerede har læst, så pladsen ikke går til spilde. Resultatet er, at det samme grafikkort kan betjene langt flere mennesker ad gangen.

Sikkerheden er den anden grænse. I maj 2026 blev sårbarheden CVE-2026-7482 offentliggjort. En angriber uden login kunne uploade en manipuleret modelfil og få Ollama til at lække indholdet af sin hukommelse: miljøvariabler, API-nøgler, systemprompter og andre brugeres samtaler. Fejlen er rettet i version 0.17.1, men den ramte præcis de installationer, der var blevet åbnet mod netværket, så kollegerne kunne komme til.

Motor, orkestrator eller router?

Ordet orkestrator dækker over flere forskellige ting, og de er lette at blande sammen. Nederst ligger motorerne, der faktisk kører modellen på grafikkortet. Oven på dem ligger orkestratorerne, der holder styr på maskiner, modeller og brugere. Helt forrest kan der stå en router, der fordeler trafikken og fører regnskab, men aldrig selv kører en model.

Næsten alle værktøjerne taler et OpenAI-kompatibelt API. Det betyder, at et program skrevet til OpenAIs API kan pege på din egen server i stedet, typisk blot ved at ændre en adresse og en nøgle. Det er den egenskab, der gør det realistisk at flytte trafik hjem uden at skrive applikationerne om.

LiteLLM fortjener en særlig bemærkning, fordi det ofte bliver forvekslet med en løsning til selvhosting. Det er det ikke. LiteLLM står foran over hundrede udbydere og dine egne servere med nøgler, budgetter og forbrugsopgørelser, og det er typisk det, du sætter foran, når flere teams deler de samme modeller. Selve arbejdet skal stadig udføres af en af de andre.

Helt i den tunge ende ligger Nvidia Dynamo og llm-d. Sidstnævnte blev startet af Red Hat sammen med CoreWeave, Google Cloud, IBM Research og Nvidia. Begge deler en forespørgsel op i to faser og lægger dem på hver sine grafikkort: prefill, hvor hele inputtet læses, og decode, hvor svaret skrives ord for ord. Ifølge Lanza løser de problemer, der begynder ved et helt rack, og er det forkerte værktøj under det. Deres idé om at sende en forespørgsel derhen, hvor samtalens cache allerede ligger, er dog ved at sive ned i de mindre projekter.

vLLM, LocalAI og exo side om side

Tabellen samler de syv værktøjer, der er mest relevante, hvis du har et eller flere grafikkort i huset og vil have ét fælles endpoint foran dem. Stjernetallene er fra 20. september 2026 og er tjekket mod GitHub dagen efter.

LocalAI kommer tættest på at kunne det hele. Hver motor kører i sin egen container, der kræves ikke noget grafikkort, og siden juni har værktøjet haft en ægte distribueret tilstand. Med --p2p genererer det en fælles nøgle, instanserne finder selv hinanden, og en ny router ved både, hvor meget grafikhukommelse hver maskine har, og hvor samtalens cache allerede ligger. Motorernes container-images er signeret med cosign, så du kan kontrollere, at det, du kører, er det, udviklerne har bygget. Prisen for bredden er ifølge Lanza, at LocalAI er et godt stykke langsommere end en dedikeret motor.

GPUStack og Xinference er de to driftskonsoller til virksomheder. Begge består af en central styring med arbejdsmaskiner og en webkonsol, begge har et firma i ryggen, henholdsvis Seal og Xorbits, og ifølge Lanza er det dem, han faktisk ser i drift som klynger i Asien. GPUStack er den mest driftsorienterede med brugere og roller, API-nøgler med forbrugsmåling, Grafana og automatisk genstart af modeller, der går ned. Den understøtter acceleratorer fra ni leverandører, blandt dem de kinesiske Ascend, Hygon og Moore Threads, selv om flere af dem stadig står som eksperimentelle i dokumentationen. Xinference dækker til gengæld flere modeltyper og har et større indbygget katalog.

CoderAI er Lanzas eget projekt, og han skriver selv, at det skal læses med det i baghovedet. Det særlige er en trappe i tre trin: En model kører på dit eget grafikkort, derefter på en anden maskine, du ejer, og til sidst på et grafikkort, der lejes per sekund hos RunPod med prisloft og budget. Det kan også fordele billed-, lyd- og OCR-opgaver over alle maskiner og træne LoRA-tilpasninger på tværs af dem. Til gengæld mangler det Kubernetes, understøttelse af Apple og et fællesskab, og funktionerne til flere maskiner er ifølge Lanza selv kun testet mod simuleringer, ikke over et rigtigt netværkskabel.

To navne er værd at kende, selv om de ikke har en række i tabellen. SGLang er med 36.000 stjerner en motor i samme liga som vLLM og kører blandt andet under GPUStack, Xinference og Nvidia Dynamo. Hugging Faces egen server, TGI, er derimod væk. Den blev arkiveret i marts 2026, og kører du den stadig, er det tid til at finde en afløser.

En stak Mac'er er blevet en AI-server

Den mest overraskende konklusion i sammenligningen handler ikke om Nvidia. Lanza skriver, at intet andet værktøj kommer i nærheden af exo, hvis din hardware er Apple Silicon. Værktøjet finder selv de andre Mac'er på netværket, deler modellen op i forhold til, hvor meget hukommelse hver maskine har, og bruger Apples egen MLX-motor. På nyere macOS kan maskinerne tale sammen med RDMA over Thunderbolt 5, hvor de læser direkte i hinandens hukommelse uden om processoren. Udviklerne bag exo oplyser selv, at det giver 1,8 gange så høj hastighed på to maskiner og 3,2 gange på fire.

Apple har tydeligvis set det samme. I morgen, den 22. september, kommer den nye Mac Studio med M5 Ultra i butikkerne, og i pressemeddelelsen skriver Apple direkte, at flere Mac Studio kan kobles sammen over Thunderbolt 5 med op til tre gange så høj ydelse på distribueret AI-inferens. M5 Ultra kan fås med op til 512 GB fælles hukommelse, selv om netop den udgave først kommer sidst i oktober. Startprisen er 5.499 dollars i USA.

Hukommelsen er hele pointen. På en Mac deler processor og grafikdel den samme hukommelse, så en model på 70 milliarder parametre, der fylder over 40 GB, kan ligge i én kasse. Et Nvidia RTX 5090 har 32 GB. Nvidias eget svar er DGX Spark, en lille computer med 128 GB fælles hukommelse, der blev lanceret til 3.999 dollars i oktober 2025, og hvor to enheder kan kobles sammen.

Der er et stort forbehold. På Linux kører exo i september 2026 kun på processoren, mens understøttelse af Nvidia og AMD stadig er under udvikling. Har du ikke Apple-hardware, er exo ikke noget for dig endnu.

Hvor meget hardware kræver en lokal AI-model?

Valget af orkestrator giver først mening, når du ved, hvor store modeller du vil køre. Tallene herunder gælder for 4-bit kvantisering, hvor modellens vægte gemmes med lavere præcision, så de fylder omkring en fjerdedel af originalen mod et lille kvalitetstab. Lange samtaler kræver mere, fordi KV-cachen vokser med hvert ord, så betragt tallene som et minimum.

Selvhosting løser en del af det juridiske. Når modellen kører på dine egne maskiner i EU, sendes der ingen data til et tredjeland, og du har ikke brug for en databehandleraftale med en AI-leverandør. Men det løser ikke resten. Logning, backup, adgangsstyring og dataflowet til de systemer, modellen taler med, er stadig dit ansvar, og de 175.000 åbne Ollama-servere viser, hvor let det ansvar bliver glemt. Hvilke opgaver der skal hjem, og hvilke der fint kan blive i skyen, er en afvejning af risiko, pris og kvalitet, og det er typisk dér, AI-rådgivning til virksomheder begynder.

For mange ender svaret som en blanding. Samme mønster ses hos udviklere, der bruger lokale AI-kodeagenter til det daglige arbejde og skyen til de svære opgaver. Den lokale model klarer det rutineprægede og det følsomme, og den store model i skyen tager resten.

Vælg efter dine maskiner, ikke efter stjernerne

Stjernetallet siger noget om fællesskabet, men intet om, hvorvidt værktøjet passer til din situation. Lanzas egen anbefaling er bygget op efter hardware og behov, og den er den mest brugbare del af hele sammenligningen.

Udvikleren, der installerede Ollama på arbejdsstationen, gjorde ikke noget forkert. Fejlen opstår først den dag, maskinen bliver fælles, og nogen åbner porten i stedet for at skifte værktøj. Tommelfingerreglen er derfor enkel. Så længe det er din maskine, er Ollama nok. Når den bliver firmaets, er det tid til en orkestrator, en proxy med login foran og en beslutning om, hvem der har adgang.

Kilder: Nexlab · Red Hat Developer · The Hacker News · NVD · Apple · exo · LocalAI