Lokala LLM: När molnet inte är ett alternativ

Hos många företag börjar AI-resan på nästan samma sätt: någon skaffar ett ChatGPT-konto, ser hur effektivt det är och snart bygger utvecklingsteamet en intern app ovanpå OpenAIs eller Anthropics API:er. Det är bekvämt, går ju snabbt att komma igång och du slipper tänka på servrar och infrastruktur. Förr eller senare stöter många ändå på en vägg. Den väggen stavas dataskydd.

Viss information kan helt enkelt inte lämna dina egna servrar. Det kan gälla patientjournaler i vården, försvarshemligheter, olistade finansiella rapporter, klientuppgifter på en advokatbyrå eller er mest känsliga källkod. När molnet inte är ett alternativ på grund av säkerhetskrav eller interna policys. Vad gör du då? Svaret är att plocka hem intelligensen. Du behöver alltså köra lokala språkmodeller, LLM.

Varför molnet ibland är en återvändsgränd

Det mest uppenbara skälet att köra AI lokalt är integritet och kontroll. När du skickar en prompt till en molntjänst skickar du i praktiken din data till en server i USA eller till ett europeiskt datacenter som ju ofta kontrolleras av ett amerikanskt bolag. Även om leverantörer lovar att inte träna på din data är själva överföringen ofta ett hinder för företag med hårda compliance-krav. Om du brottas med de juridiska frågorna rekommenderar jag att du läser vår praktiska guide till GDPR och AI.

Ett annat tungt skäl är kostnadskontroll. Molnmodellen bygger på att du betalar per token in och ut. Om du bygger en tjänst som ska analysera miljontals interna dokument kan API-kostnaderna nog dra iväg rejält. Med en lokal modell gör du en engångsinvestering i hårdvara. Därefter kan du köra modellen dygnet runt utan andra kostnader än elen.

Sedan har du latens och offline-krav. I vissa industriella tillämpningar, eller i system som körs långt från stabil uppkoppling, måste besluten fattas omedelbart och lokalt. Du kan förstås inte lita på att ett API-anrop ska åka över Atlanten och tillbaka i tid.

Hårdvaran: sanningen om VRAM och processorer

När man pratar om att köra AI lokalt brukar första frågan vara: vilken dator behövs? Svaret handlar i praktiken om en enda sak, nämligen VRAM, alltså minnet på grafikkortet.

Att köra en stor språkmodell kräver mycket minne. Processorkraften är ofta sekundär. Det är minnesbandbredden som avgör hur snabbt modellen kan skriva text.

För utvecklare som vill testa och bygga lokalt har Mac med M‑chip blivit en oväntad favorit. Anledningen är Apples arkitektur med enhetligt minne. I en vanlig PC är systemminnet och grafikkortsminnet separerade, men i en Mac delar de på samma pott. Det betyder att en Mac Studio med 128 GB minne kan ladda in väldigt stora modeller som annars skulle kräva flera dyra serverkort från Nvidia.

När vi pratar om produktion, där modellen ska ligga på en server och svara många samtidiga användare, är det fortfarande Nvidia som gäller. För mindre behov kan en server med ett par RTX 4090 räcka. För tyngre företagsmiljöer handlar det om datacenterkort som A100 eller H100.

En enkel tumregel för minneskrav är denna: du behöver ungefär 1 GB VRAM per miljard parametrar i modellen, givet 4-bitars kvantisering. En mindre modell med 8 miljarder parametrar, till exempel Llama 3 8B, drar alltså cirka 6 till 8 GB VRAM och kan köras på en vanlig laptop. En större modell med 70 miljarder parametrar kräver över 40 GB VRAM, vilket i praktiken innebär flera grafikkort.

Prestanda: att hantera förväntningarna

Låt oss vara ärliga: en modell du kör på en laptop eller en ensam server slår inte GPT-4 i svåra resonemang. När du väljer lokalt byter du rå, generell kapacitet mot integritet, kontroll och möjlighet att nischa.

Men du behöver sällan GPT-4-nivå. Tänk på det som att köpa bil. Du behöver ju inte en Ferrari för att åka till Ica. För specifika, avgränsade uppgifter, som att extrahera strukturerad information ur PDF-fakturor, sammanfatta mötesanteckningar eller skriva standardiserad kod, kan mindre öppna modeller prestera riktigt bra.

Modeller som Metas Llama 3, Mistral eller Qwen har blivit förvånansvärt kapabla trots sin storlek. Särskilt om du kombinerar dem med RAG (Retrieval-Augmented Generation), där modellen först söker i dina interna dokument innan den svarar, eller om du finjusterar modellen för ditt användningsområde. Läs mer om hur du kan tänka strategiskt i vår artikel om att välja rätt AI-modell för företaget.

Mjukvaran: verktygen som gör det möjligt

För bara ett par år sedan var det bökigt att få igång en lokal modell. Du behövde kompilera från källkod och bråka med Python-beroenden. Idag är verktygen faktiskt betydligt mognare.

Ollama Detta är det enklaste sättet att komma igång. Ollama fungerar lite som Docker, fast för modeller. Du laddar ner programmet, öppnar terminalen och skriver ollama run llama3. Programmet laddar automatiskt ner modellen och ger dig en chattprompt. Perfekt för utvecklare som vill ha en lokal AI-assistent eller snabbt bygga prototyper.

vLLM När du ska köra i produktion och hantera många samtidiga användare räcker Ollama sällan till. Då använder du vLLM. Det är en servermotor byggd för hög genomströmning. Den använder en teknik som kallas PagedAttention för att minska minnesförbrukningen när många ställer frågor samtidigt. vLLM är i praktiken ett standardval när du hostar egna modeller i större drift.

LM Studio För dig som inte kodar men ändå vill köra lokalt är detta program guld värt. Det erbjuder ett grafiskt gränssnitt som påminner om ChatGPT. Du kan bläddra bland tusentals modeller, klicka på ladda ner och börja chatta direkt. Enkelt, men ändå flexibelt nog för att prova egna data.

Så kommer du igång

Mitt råd är att börja smått. Ladda ner Ollama eller LM Studio på din arbetsdator. Hämta en mindre modell som Llama 3 8B eller Mistral. Känn på hastigheten, testa att ställa frågor om känslig data som du ju aldrig skulle klistra in i en molntjänst, och se hur det fungerar i praktiken.

Funderar du på AI men är osäker på var du ska börja, så är du långt ifrån ensam. Vi brinner faktiskt för att få AI att fungera i vardagen och pratar gärna om din situation. Börja smått, tänk stort. Hör av dig.