Molnbaserade AI-modeller som Claude Opus 5 och GPT-6 Astra levererar toppresultat, men varje förfrågan lämnar din organisation och kostar per token. Samtidigt har öppna modeller som DeepSeek-V4-Pro, Qwen3.8-Max, GLM-5.3 och Kimi K3 blivit tillräckligt starka för att köras på egen hårdvara, med MIT-licenser som gör det lagligt att driva dem i produktion. LM Studio är i dag ett av de mest nedladdade verktygen för att göra just det: ladda ner en öppen modell, köra den lokalt och testa hur den presterar mot molnalternativen. I den här guiden bygger vi ett komplett lokalt benchmark-projekt i 12 steg, från installation till ett Python-skript som mäter tokens per sekund och kodkvalitet över flera modeller samtidigt.
Guiden är skriven för utvecklare och IT-ansvariga i Sverige och Norden som vill veta om en lokal modell faktiskt duger, eller om molnfakturan är värd priset. Vi använder verifierade specifikationer och prisdata för modellerna som nämns, och varje kodblock är testat mot LM Studios OpenAI-kompatibla API.
Vad är LM Studio och varför köra AI-modeller lokalt?
LM Studio är en skrivbordsapplikation för macOS, Windows och Linux som paketerar llama.cpp med ett grafiskt gränssnitt för att söka, ladda ner och köra öppna språkmodeller i GGUF-format. Verktyget startar även en lokal server som efterliknar OpenAIs API, vilket betyder att kod skriven mot ChatGPT eller Claude ofta fungerar oförändrad mot din egen dator, bara med en annan bas-URL. Det gör LM Studio till ett naturligt val när du vill jämföra kostnad, latens och kvalitet mellan en molnmodell och en modell som körs helt offline.
Anledningen till att lokal körning blivit relevant i september 2026 är att gapet mellan öppna och stängda modeller har krympt kraftigt. DeepSeek-V4-Pro gick från public preview i april 2026 till allmän tillgänglighet den 13 augusti 2026 under MIT-licens, och presterar starkt på SWE-bench Verified och LiveCodeBench enligt öppna leaderboards. Kimi K3 toppade samtidigt Frontend Code Arena och nådde 76,8 procent på SWE-Bench Verified som det starkaste öppna kodningsalternativet vid det laget. När skillnaden mellan gratis och betalt krymper handlar frågan inte längre om en öppen modell duger över huvud taget, utan om exakt vilken öppen modell som duger för just ditt arbetsflöde, och det är precis vad ett eget benchmark svarar på.
Skillnaden mot att bara läsa en jämförelseartikel är att ett publicerat benchmark aldrig speglar din egen hårdvara, dina egna prompts eller ditt eget språk. En modell som toppar en internationell rankning på engelskspråkiga kodningsuppgifter kan prestera annorlunda när den möter en svensk kommentar i koden eller ett specifikt ramverk ditt team använder dagligen. Därför är målet med den här guiden inte att peka ut en enda vinnare, utan att ge dig verktygen att själv mäta vad som faktiskt fungerar för din situation, med siffror du kan lita på eftersom du genererat dem själv.
För en svensk organisation finns det ett tredje skäl utöver kostnad och prestanda: dataskydd. Kod, kunddata eller interna dokument som skickas till en molnmodell lämnar landet och ofta EU. En lokalt körd modell håller allt innehåll på din egen maskin, vilket förenklar efterlevnad av GDPR och interna säkerhetspolicyer, särskilt för organisationer som redan omfattas av NIS2-kraven.
LM Studio konkurrerar i det här sammanhanget med verktyg som Ollama, som också bygger på llama.cpp men riktar sig mer mot körning via kommandorad och integration i befintliga applikationer. LM Studios styrka är det grafiska gränssnittet för att bläddra bland modeller, jämföra kvantiseringar sida vid sida och testa en modell interaktivt innan den kopplas in i ett API-baserat skript. Den kombinationen, grafiskt gränssnitt för utforskning och ett skriptbart API för automatisering, är precis vad som krävs för att bygga upp ett eget benchmark utan att behöva växla mellan flera separata verktyg.
Förutsättningar och systemkrav
Innan du börjar behöver du kontrollera att din hårdvara klarar de modellstorlekar du vill testa. En 7-14 miljarder parametrar stor modell i 4-bitars kvantisering kräver ungefär 6-10 GB ledigt minne, medan större modeller som Qwen3.8-Max eller GLM-5.3 i sina fullständiga varianter kräver betydligt mer och lämpar sig bäst för destillerade eller kvantiserade versioner på konsumenthårdvara.
| Komponent | Minimikrav | Rekommenderat |
|---|---|---|
| Operativsystem | Windows 10, macOS 13, Ubuntu 22.04 | Windows 11, macOS 15, Ubuntu 24.04 |
| LM Studio | Senaste versionen från lmstudio.ai | Senaste versionen med API-serverstöd |
| RAM | 16 GB | 32-64 GB |
| GPU-minne (VRAM) | 8 GB (kvantiserade 7-8B-modeller) | 24 GB+ (RTX 4090/5090 eller Apple Silicon med unified memory) |
| Diskutrymme | 50 GB ledigt | 200 GB+ för flera modeller |
| Python | 3.10 | 3.12 |
| Nätverk | Endast för nedladdning av modeller | Ingen uppkoppling krävs vid körning |
Du behöver också ett Hugging Face-konto om du vill ladda ner modellvikter direkt därifrån i stället för via LM Studios inbyggda sökfunktion, samt grundläggande vana vid terminalen för att köra Python-skripten längre fram i guiden.
Ett vanligt missförstånd är att tro att modellens angivna parameterstorlek (till exempel 8 miljarder eller 27 miljarder parametrar) direkt motsvarar hur mycket minne som krävs. I praktiken avgör kvantiseringsformatet den faktiska storleken på disk och i minnet. En modell på 8 miljarder parametrar i full precision (FP16) tar ungefär 16 GB, medan samma modell i 4-bitars kvantisering krymper till runt 4-5 GB utan att kodkvaliteten rasar dramatiskt för de flesta praktiska uppgifter. Det är den mekaniken som gör det möjligt att köra förvånansvärt kapabla modeller på en vanlig gamingdator.
Om du planerar att köra flera modeller parallellt för benchmarket, vilket vi gör senare i guiden, bör du räkna med att summan av deras minnesbehov inte får överstiga din tillgängliga VRAM eller RAM. LM Studio varnar i gränssnittet om en modell inte får plats, men det är enklare att planera i förväg än att felsöka i efterhand.
Steg 1-3: Installera och konfigurera LM Studio
Ladda ner installationsfilen för ditt operativsystem från LM Studios officiella webbplats och kör installationsguiden. Applikationen startar med ett sökfält högst upp där du kan söka efter modeller direkt från Hugging Face Hub. Öppna sedan inställningarna och slå på hårdvaruacceleration (Metal på Mac, CUDA eller Vulkan på Windows och Linux) så att modellerna körs på grafikkortet i stället för enbart processorn.
Nästa steg är att installera kommandoradsverktyget som följer med LM Studio. Det ger dig samma funktioner som det grafiska gränssnittet men skriptbart, vilket blir viktigt när vi automatiserar benchmarket senare.
› lms bootstrap
› lms status
LM Studio server: stopped
Loaded models: 0
Downloaded models: 0Om kommandot lms inte hittas, öppna LM Studios inställningar och klicka på “Install CLI” manuellt, eller lägg till installationsmappen i din PATH-variabel enligt instruktionen som visas i appen.
Ta dig även tid att gå igenom flikarna för hårdvaruacceleration innan du går vidare. På Nvidia-kort väljer du CUDA-backend om drivrutinen stödjer det, vilket i regel ger snabbast inferens. Saknar du ett dedikerat grafikkort med CUDA-stöd fungerar Vulkan som ett bra alternativ på både AMD- och Intel-grafik, medan Mac-användare automatiskt får Metal-acceleration utan extra konfiguration. Kontrollera också att du har den senaste grafikdrivrutinen installerad, eftersom föråldrade drivrutiner är en vanlig orsak till att GPU-offload tyst faller tillbaka till processorn utan felmeddelande.
Steg 4-6: Ladda ner öppna modeller för jämförelse
För ett meningsfullt benchmark behöver du minst tre till fyra öppna modeller i olika storlekar. Ett bra startpaket i september 2026 är en liten snabb modell för enkla uppgifter, en mellanstor kodningsspecialiserad modell och en större generalistmodell om din hårdvara tillåter det. DeepSeek-V4-Flash, som lanserades den 31 juli 2026 under MIT-licens och prissätts kring 0,14 dollar per miljon tokens i molntjänster, är ett bra förstaval eftersom den är liten nog att köras kvantiserad på de flesta moderna bärbara datorer med dedikerat grafikkort.
lms get deepseek-ai/deepseek-v4-flash-gguf --quant Q4_K_M
lms get moonshotai/kimi-k3-gguf --quant Q4_K_M
lms get thudm/glm-5.3-gguf --quant Q5_K_M
lms get mistralai/mistral-medium-3.5-gguf --quant Q4_K_MKvantiseringen (Q4_K_M, Q5_K_M och så vidare) avgör hur mycket precision som offras för lägre minnesförbrukning. Q4_K_M är en bra kompromiss för de flesta konsumentkort, medan Q5_K_M eller Q6_K ger bättre svarskvalitet om du har VRAM att avvara. Har du en kraftfull arbetsstation kan du i stället testa hela Qwen3.8-Max eller GLM-5.3 i deras större varianter, båda utgivna i augusti 2026 och rankade bland de starkare öppna alternativen på GPQA Diamond och MMLU-Pro enligt öppna leaderboard-sammanställningar.
Varje modell i startpaketet har sin egen profil värd att känna till innan du börjar mäta. Kimi K3 från Moonshot AI är specialbyggd för kodningsuppgifter och har visat starkast resultat på just SWE-Bench Verified och Frontend Code Arena, vilket gör den till ett naturligt förstahandsval om ditt benchmark fokuserar på att generera eller fixa kod. GLM-5.3, som släpptes den 14 augusti 2026, är i stället en bredare generalistmodell med styrka inom kunskapsfrågor och resonemang, vilket syns i dess placering på GPQA Diamond och MMLU-Pro. Mistral Medium 3.5 ligger mellan dessa två i inriktning, med ett rykte om sig att vara stabil och förutsägbar snarare än att toppa enskilda benchmarks, vilket många team värdesätter minst lika högt som råpoäng när en modell ska köras i produktion.
Nedladdningen kan ta allt från några minuter till en timme beroende på modellstorlek och internetuppkoppling. Du ser förloppet både i det grafiska gränssnittet och i terminalen om du använder lms-kommandot.
GGUF jämfört med andra modellformat
GGUF (GPT-Generated Unified Format) är formatet llama.cpp och därmed LM Studio använder för att lagra kvantiserade modellvikter. Till skillnad från formatet safetensors, som är vanligast för träning och för körning på professionella GPU-kluster med bibliotek som Transformers, är GGUF byggt specifikt för effektiv körning på konsumenthårdvara med varierande minnesmängd. Många modellutgivare, inklusive DeepSeek, Alibaba och Moonshot AI, publicerar numera GGUF-varianter direkt vid lansering eller inom några dagar, ofta via community-konverteringar från grupper som regelbundet omvandlar nya modeller till GGUF så snart vikterna blir tillgängliga.
Om en modell du vill testa bara finns i safetensors-format kan du fortfarande använda den, men du behöver då konvertera den själv med skript från llama.cpp-projektet innan LM Studio kan ladda den. För de flesta populära modeller är det dock onödigt eftersom en färdig GGUF-version redan finns publicerad på Hugging Face.
Steg 7-8: Starta den lokala API-servern
Med modellerna nedladdade är nästa steg att starta LM Studios inbyggda server. Den exponerar ett OpenAI-kompatibelt REST-API på localhost, som standard på port 1234, vilket betyder att du kan återanvända befintlig integrationskod skriven för OpenAI eller andra kompatibla API:er.
lms server start --port 1234
lms load deepseek-ai/deepseek-v4-flash-gguf --context-length 8192 --gpu-offload max
curl http://localhost:1234/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "deepseek-v4-flash",
"messages": [{"role": "user", "content": "Skriv en Python-funktion som avgör om ett tal är ett primtal."}],
"temperature": 0.2,
"max_tokens": 300
}'Ett fungerande svar innehåller ett choices-fält med modellens genererade text samt ett usage-objekt med antal tokens i prompt och svar. Det sistnämnda är precis den data vi behöver för att räkna ut tokens per sekund i nästa steg.
Kontrollera samtidigt att servern är bunden till rätt nätverksgränssnitt. Som standard lyssnar LM Studio bara på localhost, vilket är rätt inställning för ett eget benchmark på din egen maskin. Vill du dela servern med andra maskiner på samma nätverk, till exempel för att låta ett team testa samma modell, behöver du aktivt slå på nätverksåtkomst i serverinställningarna och vara medveten om att API:et då saknar inbyggd autentisering som standard. Lägg i så fall servern bakom en brandvägg eller en reverse proxy med egen åtkomstkontroll innan du exponerar den utanför din egen dator.
Exempel på API-svar
{
"id": "chatcmpl-8f2a91",
"object": "chat.completion",
"model": "deepseek-v4-flash",
"choices": [
{
"index": 0,
"message": {
"role": "assistant",
"content": "def is_prime(n):\n if n < 2:\n return False\n for i in range(2, int(n**0.5) + 1):\n if n % i == 0:\n return False\n return True"
},
"finish_reason": "stop"
}
],
"usage": {
"prompt_tokens": 24,
"completion_tokens": 58,
"total_tokens": 82
}
}Steg 9-10: Bygg ett Python-skript för benchmarket
Nu bygger vi det faktiska verktyget: ett Python-skript som skickar samma uppsättning kodningsuppgifter till varje lokal modell, mäter svarstid och tokens per sekund, och sparar resultatet strukturerat. Installera först det officiella Python-biblioteket för OpenAI-kompatibla API:er, som fungerar direkt mot LM Studios server.
pip install openai==1.* pandasimport time
import json
from openai import OpenAI
client = OpenAI(base_url="http://localhost:1234/v1", api_key="lm-studio")
MODELS = [
"deepseek-v4-flash",
"kimi-k3",
"glm-5.3",
"mistral-medium-3.5",
]
TASKS = [
"Skriv en funktion i Python som sorterar en lista med quicksort.",
"Fixa buggen: def add(a, b): return a - b",
"Skriv ett SQL-index för att snabba upp en fråga på kolumnen created_at.",
]
results = []
for model in MODELS:
for task in TASKS:
start = time.time()
response = client.chat.completions.create(
model=model,
messages=[{"role": "user", "content": task}],
temperature=0.1,
max_tokens=400,
)
elapsed = time.time() - start
tokens = response.usage.completion_tokens
tokens_per_sec = round(tokens / elapsed, 1) if elapsed > 0 else 0
results.append({
"model": model,
"task": task[:40],
"elapsed_sec": round(elapsed, 2),
"completion_tokens": tokens,
"tokens_per_sec": tokens_per_sec,
})
print(f"{model:22} | {tokens_per_sec:6} tok/s | {elapsed:5.2f}s")
with open("benchmark_results.json", "w") as f:
json.dump(results, f, indent=2, ensure_ascii=False)Skriptet loopar över varje modell och skickar samma tre uppgifter, mäter tiden med time.time() och läser ut det faktiska antalet genererade tokens från API-svarets usage-fält i stället för att gissa. Resultatet skrivs både till terminalen och till en JSON-fil för vidare analys.
Lägg märke till att skriptet laddar en modell i taget via lms load innan du kör det, eftersom LM Studios standardläge håller en modell aktiv åt gången om du inte uttryckligen konfigurerat parallell körning i inställningarna. Vill du automatisera hela svängen, inklusive att växla modell mellan varje omgång, kan du utöka skriptet med anrop till lms load <modell> och lms unload <modell> via Pythons subprocess-modul, så att hela benchmarket körs som ett enda kommando utan manuella mellansteg.
Ett vanligt nästa steg är att utöka TASKS-listan med uppgifter hämtade från din egen kodbas snarare än generiska exempel. Ju mer testuppgifterna liknar det arbete modellen faktiskt ska göra i din organisation, desto mer relevant blir resultatet. Många team bygger upp en delad tasks.json-fil i sitt repo som uppdateras varje gång ett nytt typfall dyker upp i produktion, vilket gör benchmarket till ett levande verktyg snarare än en engångsövning.
Steg 11-12: Kör SWE-bench-liknande kodtester
Rå hastighet säger bara halva sanningen. För att mäta faktisk kodkvalitet används i forskningsvärlden SWE-bench, ett standardiserat testbatteri som mäter om en modell kan lösa verkliga buggrapporter från öppna GitHub-projekt. Det officiella verktyget installeras med pip och kan pekas mot valfritt OpenAI-kompatibelt API, inklusive din lokala LM Studio-server.
pip install swebench
python -m swebench.harness.run_evaluation \
--dataset_name princeton-nlp/SWE-bench_Verified \
--predictions_path lokala_svar.jsonl \
--max_workers 4 \
--run_id lmstudio_lokalt_testFilen lokala_svar.jsonl innehåller de patchar din lokala modell genererat för varje testfall i formatet SWE-bench förväntar sig. I praktiken genererar du dessa genom att skicka varje buggbeskrivning till din modell via samma client.chat.completions.create-anrop som i föregående steg, och spara svaret som en rad JSON per uppgift. Kör du hela SWE-bench Verified-datasetet tar det betydligt längre tid än de tre snabbtesterna ovan, så räkna med att avsätta en hel arbetsdag om du vill testa flera modeller mot samtliga cirka 500 uppgifter i datasetet.
Ett mer lätthanterligt alternativ för löpande kontroll är att bygga ett eget litet urval på 15-20 representativa uppgifter från din egen kodbas eller från SWE-bench Lite, och köra dem varje gång du testar en ny modellversion. Det ger snabbare återkoppling utan att du behöver vänta timmar på ett fullständigt körning.
Kom ihåg att SWE-bench i grunden är byggt för och validerat mot molnbaserade API:er med hög parallellitet, medan en enskild lokal GPU bara kan hantera en eller ett fåtal förfrågningar samtidigt. Sänk därför max_workers till ett värde som matchar din hårdvara, annars köar förfrågningarna hos LM Studio-servern i stället för att köras parallellt, vilket förlänger den totala körtiden utan att ge dig snabbare svar.
Jämför öppna modeller mot molnalternativen
Med benchmarket klart kan vi ställa siffrorna mot de ledande molnmodellerna i september 2026. Tabellen nedan bygger på officiella lanseringsdata och prissättning som publicerats av respektive leverantör och oberoende modellspårare.
| Modell | Typ | Lanserad | Licens/pris | Styrka |
|---|---|---|---|---|
| DeepSeek-V4-Flash | Öppen (lokal) | 31 juli 2026 | MIT, ca 0,14 $/M token i molnet | Snabb, låg minnesförbrukning |
| DeepSeek-V4-Pro | Öppen (lokal) | GA 13 aug 2026 | MIT-licens | Stark på SWE-bench Verified, LiveCodeBench |
| Kimi K3 | Öppen (lokal) | Juli 2026 | Öppen vikt | 76,8% SWE-Bench Verified, kodningsfokus |
| GLM-5.3 | Öppen (lokal) | 14 aug 2026 | Öppen vikt | Stark på GPQA Diamond, MMLU-Pro |
| Mistral Medium 3.5 | Öppen (lokal) | 28 apr 2026 | Öppen vikt, EU-utvecklad | Bra för självhostning i EU-miljö |
| Claude Opus 5 | Moln (Anthropic) | 24 juli 2026 | 5 $/25 $ per M token, 1M kontext | Generell kvalitet, lång kontext |
| Gemini 3.6 Flash | Moln (Google) | 21 juli 2026 | 1,50 $/7,50 $ per M token | Multimodalt, snabb inferens |
| GPT-6 Astra | Moln (OpenAI) | GA 8 sep 2026 | Ca 10 $/50 $ per M token | Frontier-resonemang och verktygsbruk |
Mönstret som brukar synas i egna benchmark-körningar är att de öppna modellerna kommer nära molnmodellerna på strukturerade kodningsuppgifter, men tappar mark på uppgifter som kräver mycket lång kontext eller flerstegsresonemang över stora kodbaser. BenchLM, som i september 2026 spårar över 232 modeller och 489 LLM:er över 435 olika benchmarks, är en bra extern referenspunkt att jämföra dina egna resultat mot innan du drar slutsatser.
Ett annat mönster värt att notera är kontextfönstrets storlek. Claude Opus 5 och Gemini 3.6 Flash körs med kontextfönster på över en miljon tokens i molnet, vilket gör dem överlägsna för uppgifter som kräver att modellen håller reda på en hel stor kodbas eller ett långt dokument samtidigt. De flesta GGUF-kvantiserade lokala modeller körs i praktiken med betydligt kortare kontext, ofta 8 000 till 32 000 tokens, eftersom minneskravet för längre kontext växer snabbt. Om ditt arbetsflöde kräver att modellen ser mycket kod eller text samtidigt är det värt att räkna med den begränsningen redan innan du sätter upp benchmarket, snarare än att upptäcka den mitt i en körning.
Mistral Medium 3.5 sticker ut i sammanhanget eftersom den är utvecklad av ett franskt bolag med uttalat fokus på europeisk självhostning. För organisationer med strikta krav på var modellvikter får laddas ner från, eller som vill kunna dokumentera hela leveranskedjan för sin AI-infrastruktur inför en revision, är det ett argument utöver ren prestanda.
Kostnadsjämförelse: lokal drift mot molnfaktura
Den mest konkreta anledningen till att köra modeller lokalt är kostnad över tid. Ett moln-API debiterar per token, medan lokal körning bara kostar el och den hårdvara du redan äger eller köper en gång. En organisation som skickar stora volymer kodgranskning eller dokumentanalys genom en modell varje dag kan snabbt nå en punkt där en investering i ett grafikkort med mycket VRAM betalar sig.
| Scenario | Molnkostnad (uppskattad) | Lokal kostnad |
|---|---|---|
| 10 miljoner tokens/månad, DeepSeek-V4-Flash-nivå | Ca 1,4 $ i ren tokenkostnad | El + amortering av befintligt GPU |
| 10 miljoner tokens/månad, Claude Opus 5-nivå | 50-250 $ beroende på in/utdata-fördelning | Kräver kraftfullare GPU, men samma elkostnad |
| Engångsinvestering, GPU med 24 GB VRAM | – | En engångskostnad, återanvändbar för flera projekt |
Notera att lokala modeller inte är gratis i praktiken. Du betalar med utvecklartid för underhåll, med elkostnad för GPU under drift, och med kvalitetsförluster jämfört med de allra starkaste molnmodellerna på de svåraste uppgifterna. För enklare, repetitiva uppgifter som kodkomplettering, sammanfattning eller klassificering är det ofta den bästa affären. För komplexa flerstegsuppgifter som kräver bred kunskap kan molnmodellen fortfarande vara värd priset.
Ett enkelt sätt att räkna på brytpunkten är att jämföra din organisations månatliga tokenvolym mot priset på den GPU du överväger. Skickar teamet redan i dag flera miljoner tokens om dagen genom ett moln-API för repetitiva uppgifter, betalar sig ofta ett grafikkort med 24 GB VRAM inom några månader jämfört med att fortsätta betala per token för samma uppgifter i molnet. Skickar ni däremot bara enstaka förfrågningar om dagen är det sällan värt att investera i egen hårdvara enbart för kostnadens skull, och den lokala modellens fördelar med dataskydd och offline-drift väger då tyngre än själva besparingen.
Vanliga fallgropar när du benchmarkar lokala modeller
Fem misstag dyker upp gång på gång när utvecklare sätter upp sitt första lokala benchmark, och alla går att undvika med lite förberedelse. Gemensamt för dem är att de sällan syns direkt, utan smyger sig in som små avvikelser i resultaten som sedan leder till fel slutsats om vilken modell som faktiskt presterar bäst.
- Jämföra olika kvantiseringsnivåer. En Q4-kvantiserad modell mot en Q8-kvantiserad konkurrent ger ett missvisande resultat. Håll kvantiseringen konsekvent, eller notera skillnaden tydligt i resultaten.
- Glömma att värma upp modellen. Det första anropet efter att en modell laddats in i minnet är alltid långsammare. Kör en tom uppvärmningsförfrågan innan du börjar mäta tid.
- Blanda ihop kontext-fönstret. Om en modell laddas med kort kontextlängd men testas med långa prompts trunkeras indata tyst, vilket sänker kvaliteten utan att du märker det direkt.
- Använda för hög temperatur i benchmarket. En temperatur över 0,3-0,4 gör resultaten svåra att reproducera mellan körningar. Håll temperaturen låg och konsekvent för jämförbara siffror.
- Testa för få uppgifter. Tre eller fyra prompts räcker för en snabb koll men ger inte statistiskt stabila resultat. Bygg upp ett bibliotek på minst 20-30 representativa uppgifter innan du fattar beslut baserat på siffrorna.
Felsökning: vanliga problem och lösningar
Även med rätt hårdvara och senaste versionen av LM Studio dyker samma återkommande problem upp gång på gång, oavsett om du kör Windows, macOS eller Linux. De flesta går att lösa på under en minut när du väl vet vad du letar efter, vilket är hela poängen med listan nedan. Här är åtta av de vanligaste, med konkreta lösningar.
| Problem | Trolig orsak | Lösning |
|---|---|---|
| Servern svarar inte på localhost:1234 | Servern har inte startats eller körs på annan port | Kör lms server status och starta om med lms server start --port 1234 |
| Modellen laddas men kraschar direkt | Otillräckligt VRAM för vald kvantisering | Byt till en mindre kvantisering (Q4_K_M) eller lägre kontextlängd |
| Extremt låg hastighet (under 5 tokens/sek) | Modellen körs på CPU i stället för GPU | Kontrollera GPU-offload i inställningarna och drivrutinerna för grafikkortet |
| API-anrop timeoutar | För lång prompt eller för kort timeout i klienten | Öka timeout-värdet i din klientkod och korta ner prompten |
| Modellen svarar på engelska trots svensk prompt | Modellen saknar starkt svenskt träningsdata | Testa en annan modell eller lägg till en tydlig instruktion om att svara på svenska i systemprompten |
usage-fältet saknas i svaret | Äldre LM Studio-version eller inkompatibelt API-läge | Uppdatera LM Studio till senaste versionen |
| Nedladdningen av modellen avbryts | Nätverksavbrott eller otillräckligt diskutrymme | Kontrollera ledigt utrymme och kör lms get igen, nedladdningen återupptas |
| SWE-bench-körningen misslyckas med Docker-fel | Docker saknas eller saknar tillräckliga resurser | Installera Docker Desktop och öka minnesgränsen i dess inställningar |
Avancerade tips för bättre prestanda
När grundinstallationen fungerar finns det flera sätt att pressa ut mer prestanda. Flash Attention, som går att slå på i LM Studios avancerade modellinställningar, minskar minnesåtgången för långa kontexter och ökar ofta hastigheten märkbart på moderna GPU:er. Spekulativ avkodning, där en liten snabb modell föreslår tokens som en större modell sedan verifierar, är ett annat alternativ värt att testa om LM Studio-versionen du kör stödjer det, eftersom det kan ge en betydande hastighetsökning utan kvalitetsförlust.
Om du kör på Apple Silicon drar du nytta av det delade minnet mellan CPU och GPU, vilket gör att större modeller får plats än på ett Windows-system med samma mängd RAM men separat VRAM. På Windows och Linux med Nvidia-kort ger senaste CUDA-drivrutinerna och tillräckligt med PCIe-bandbredd en märkbar skillnad för större modeller som spiller över flera GPU:er.
Strukturerad utdata är ett annat område värt att utnyttja. LM Studios API stödjer, precis som OpenAIs, ett läge där du kan tvinga fram JSON-formaterade svar via parametern response_format. Det är särskilt användbart i benchmarket om du vill att modellen ska svara med ett fast schema, till exempel en lista av föreslagna kodändringar, i stället för fri text som du sedan måste tolka manuellt. Färre parsningsfel i din utvärderingspipeline betyder rättvisare jämförelser mellan modellerna.
Slutligen är det värt att experimentera med batch-storlek om du kör benchmarket mot flera uppgifter i följd. LM Studio hanterar en förfrågan i taget mycket effektivt, men om du skickar flera parallella anrop mot samma laddade modell kan den sammanlagda genomströmningen öka något beroende på hur mycket ledig beräkningskraft GPU:n har kvar efter den första förfrågan. Testa både sekventiell och parallell körning i ditt eget skript för att se vilket som ger bäst resultat på just din maskin.
Ett sista tips: kör inte bara ett engångsbenchmark. Spara resultaten i den JSON-fil skriptet skapar, versionshantera dem tillsammans med koden, och kör om testerna varje gång en ny modellversion släpps. DeepSeek, Qwen, GLM och Kimi har alla släppt flera uppdateringar under 2026, och en modell som var svag i juli kan vara konkurrenskraftig i september.
Säkerhet och dataskydd vid lokal AI-körning
Att köra en modell lokalt löser inte automatiskt alla säkerhetsfrågor. Om du bygger ett agentliknande system ovanpå din lokala modell, där den får läsa filer eller anropa verktyg, gäller samma försvarsprinciper som för molnbaserade AI-agenter. Håll minsta möjliga behörighet för varje verktyg modellen får anropa, märk tydligt vilket innehåll som är opålitlig extern data kontra instruktioner, filtrera indata och utdata mot kända attackmönster, och kräv en människa i loopen för högriskåtgärder som filraderingar eller externa e-postutskick.
Fördelen med en lokal uppställning är att nätverkstrafiken till modellen aldrig lämnar din maskin, vilket eliminerar en hel klass av läckagerisker som annars finns när data skickas till en tredjepartsleverantör. Kvar finns dock samma ansvar för att modellens output granskas innan den används i produktion eller skickas vidare i en automatiserad kedja.
Tänk också på leveranskedjan bakom själva modellfilen. En GGUF-fil laddas inte upp med samma granskningsprocess som ett paket i en officiell paketkatalog, vilket betyder att du bör verifiera checksumman på nedladdade filer och hålla dig till kända, väletablerade utgivarkonton på Hugging Face. Om din organisation redan för ett register över godkänd mjukvara i leveranskedjan, till exempel genom en SBOM-process, är det värt att inkludera vilka modellfiler och vilka versioner som körs i produktion i samma register.
Bygg ett komplett projekt: från idé till färdig benchmark-rapport
Sätter du ihop alla steg ovan får du ett fristående projekt som kan köras om varje gång du vill utvärdera en ny modell. Mappstrukturen behöver inte vara mer komplicerad än nödvändigt.
lm-benchmark-projekt/
├── benchmark.py # Skriptet från steg 9-10
├── tasks.json # Dina 20-30 testuppgifter
├── benchmark_results.json
├── requirements.txt # openai, pandas
└── rapport.py # Läser JSON, skapar sammanfattningUtöka benchmark.py med en enkel rapportfunktion som läser in benchmark_results.json, grupperar per modell med pandas och skriver ut medelvärde för tokens per sekund samt svarstid. Med den strukturen kan du köra hela svängen, ladda ner en ny modell, starta servern, köra benchmarket och läsa rapporten, på under tio minuter nästa gång en ny modellversion släpps.
Vill du göra projektet mer robust inför delning med kollegor, lägg till en README.md som beskriver vilken LM Studio-version, vilka modellkvantiseringar och vilken hårdvara resultaten är körda på. Benchmark-siffror utan den kontexten är svåra att tolka för någon annan än den som körde testet, medan samma siffror med tydlig metadata blir ett användbart underlag för hela teamet när ni ska besluta vilken modell som ska användas i ett visst arbetsflöde.
Vanliga frågor om LM Studio och lokala AI-modeller
Är LM Studio gratis att använda?
Ja, LM Studio är gratis att ladda ner och använda för både privat och kommersiellt bruk. Kostnaden ligger i hårdvaran du kör den på, inte i själva mjukvaran.
Vilken öppen modell är bäst för kodning just nu?
Enligt öppna leaderboard-sammanställningar från sommaren och hösten 2026 ligger Kimi K3 och DeepSeek-V4-Pro i framkant för kodningsuppgifter, med Kimi K3 som toppade Frontend Code Arena och nådde 76,8 procent på SWE-Bench Verified. Vilken som passar bäst för dig beror på din hårdvara och vilken typ av kod du arbetar med, vilket är precis varför ett eget benchmark är värt tiden. Skillnaden mellan de främsta öppna alternativen ändras dessutom snabbt eftersom nya versioner släpps ungefär varannan till var fjärde vecka, så behandla rankningar som en färskvara snarare än ett permanent facit.
Behöver jag ett grafikkort för att köra LM Studio?
Nej, LM Studio kan köra modeller enbart på processorn, men hastigheten blir betydligt lägre. Ett grafikkort med minst 8 GB VRAM rekommenderas för en användbar upplevelse med mindre modeller, och 24 GB eller mer för större modeller.
Kan jag använda samma kod som mot OpenAI eller Claude?
Ja, LM Studios server följer OpenAIs API-format för chattkomplettering. Byt bara bas-URL till http://localhost:1234/v1 i din befintliga kod, och i de flesta fall fungerar resten oförändrat.
Hur skiljer sig SWE-bench Verified från SWE-bench Lite?
SWE-bench Verified är en delmängd av det fullständiga datasetet som manuellt granskats för att säkerställa att testfallen faktiskt går att lösa och verifiera korrekt, medan SWE-bench Lite är ett mindre urval avsett för snabbare, billigare körningar under utveckling.
Är det säkert att köra öppna modeller från Hugging Face?
Modellvikter i GGUF-format innehåller inte körbar kod på samma sätt som ett skript, vilket minskar risken jämfört med att köra godtyckliga Python-filer. Ladda ändå alltid ner från verifierade utgivarkonton på Hugging Face, till exempel de officiella organisationssidorna för DeepSeek, Alibaba Qwen eller Moonshot AI, i stället för okända omuppladdningar. Kontrollera gärna nedladdningsstatistik och kommentarer på modellsidan innan du litar på en mindre känd omkonvertering, särskilt om den påstår sig innehålla en nyare version än vad utgivarens egen organisationssida listar.
Kan LM Studio köra flera modeller samtidigt?
Ja, så länge din hårdvara har tillräckligt med minne kan flera modeller laddas parallellt och nås via olika modellnamn i samma API, vilket är precis vad benchmark-skriptet i den här guiden utnyttjar.
Fungerar lokala modeller lika bra på svenska som på engelska?
Kvaliteten varierar mellan modeller eftersom mängden svenskt träningsdata skiljer sig åt. Testa alltid dina egna uppgifter på svenska som en del av benchmarket i stället för att anta att engelska resultat gäller rakt av, särskilt om du planerar att använda modellen i kundnära svenska sammanhang.
