On-premise LLM för svenska företag: komplett implementations-guide 2026

När behöver svenska företag on-premise LLM 2026?

On-premise LLM är inte default-svaret 2026 utan ett medvetet val när triggers finns. Alice Labs beslutstriggers från 100+ svenska implementationer: Läs även AI-kurs för företag.

1. Sekretessomfattad data. Sekretesslagen (2009:400), Säkerhetsskyddslagen (2018:585), Patientdatalagen (2008:355) för känslig hälsodata, eller Finansinspektionens föreskrifter för icke-outsourcable data.
2. Cloud Act-exponering oacceptabel. Bank, försäkring, life sciences och offentlig sektor där risken för amerikansk myndighetsbegäran är strategiskt oacceptabel oavsett tekniska garantier.
3. Schrems III-osäkerhet. För organisationer som vill vara robusta mot det scenariot att Data Privacy Framework 2.0 invalideras av EU-domstolen 2026-2027.
4. Hög volym. Över 5 miljoner tokens per dag flyttas break-even från pay-as-you-go till self-host i termer av ren token-kostnad, förutsatt att teamet finns.
5. Hårt latenskrav. Under 50 ms TTFT för voice, edge-agenter eller realtidsintegration i industriella styrsystem.
6. Full audit-kontroll krävd. När regulator kräver möjlighet att auditera hela inferens-pipeline, inklusive modellvikter, quantization, deterministic sampling och alla systemloggar.
7. IP-känslig träningsdata eller fine-tuning. När den fine-tunade modellen i sig är konkurrensfördel som inte får lämna organisationen.

Om ingen av dessa triggers gäller: välj hyperscaler-hostad eller EU-hostad LLM. On-premise innebär signifikant operationell tyngd som inte är motiverad utan en tydlig drivkraft. Se vår systerguide Enterprise LLM och datasuveränitet i Sverige 2026 för fullständig beslutsmatris per bransch.

Modellval 2026: Llama 3.3, Mixtral 8x22B, Qwen 2.5, DeepSeek-V3

Sammanfattat

Fyra open-weights-modeller dominerar svensk self-host 2026. Llama 3.3 70B (Meta Community License) är default. Mixtral 8x22B (Apache 2.0) för sparse MoE-throughput och permissiv licens. Qwen 2.5 72B (Apache 2.0) för kodtunga workloads och multi-language. DeepSeek-V3 671B (custom license) för frontier-nivå kvalitet till bråkdel av OpenAI-kostnad. Val drivs av licens, use-case och GPU-budget.

Fyra öppna modeller är produktionsstandard för svensk enterprise self-host 2026:

Rekommendation per use-case:

• General enterprise-chat + RAG: Llama 3.3 70B som default. Bäst balanserad, störst community, stark svensk kvalitet efter LoRA.
• Hög throughput: Mixtral 8x22B. Sparse MoE ger 3-4x throughput per GPU jämfört med Llama 70B för samma kvalitet på många benchmarks.
• Kod-heavy (code review, code generation): Qwen 2.5 Coder 32B eller 72B slår Llama och Mixtral tydligt.
• Frontier-nivå reasoning: DeepSeek-V3 eller R1. Matchar GPT-4o och Claude 3.5 Sonnet på många benchmarks. Kräver större GPU-fleet (671B parametrar).
• Edge / on-device: Llama 3.3 8B, Mistral Small 3, Phi-4. Runs på enskild L40S eller till och med RTX 5090.

Alice Labs default för svensk regulated industry 2026: Llama 3.3 70B med LoRA-fine-tuning för svensk domän, med Qwen 2.5 Coder som specialiserad coding-modell och en Llama 3.3 8B som edge-fallback.

GPU-krav: H100, H200, A100, L40S för olika modellstorlekar

Sammanfattat

Llama 3.3 70B FP16 kräver 140 GB VRAM = 2x H100 80GB per instans, 8x H100 för produktions-throughput. Mixtral 8x22B FP16 kräver 280 GB = 4x H100. Med int8-quantization halveras behovet: 70B fits på 1x H100 eller 2x L40S. DeepSeek-V3 kräver 8x H200 för FP8. A100 är fortfarande kostnadseffektivt för utveckling. L40S är budget-alternativ för lägre throughput.

GPU-planning är den enskilt viktigaste teknisk-ekonomiska frågan för svensk self-host. VRAM-behov per modell (FP16, ingen quantization, inga context-buffers):

Produktions-throughput. VRAM för modellvikter är minimum. Continuous batching med vLLM konsumerar ytterligare 20 till 60 GB per instans för KV-cache beroende på context length och batch size. Praktisk konfiguration för Llama 3.3 70B:

• Dev/staging: 2x H100 80GB, tensor parallel 2, batch size 8, ~15 samtidiga requests.
• Produktion (mid-market): 8x H100 80GB i 1 nod, tensor parallel 8, batch size 64, ~200 samtidiga requests.
• Produktion (enterprise): 4x noder om 8x H100 (32 GPU:er), pipeline parallel över noder plus tensor parallel inom nod, ~1000 samtidiga requests.

NVIDIA H100 vs H200 vs A100 vs L40S:

• H100 80GB SXM5. Produktionsstandard 2026. 3 TB/s memory bandwidth, FP8 support. Cirka 350 000 SEK per GPU vid volyminköp.
• H200 141GB. H100:s efterträdare. 141 GB VRAM och 4,8 TB/s bandwidth möjliggör större modeller (DeepSeek-V3) per nod. Cirka 450 000 SEK per GPU.
• A100 80GB. Föregående generation. 2 TB/s bandwidth. Fortfarande kostnadseffektivt för dev/staging. Cirka 200 000 SEK second-hand 2026.
• L40S 48GB. Budget-alternativ. 864 GB/s bandwidth. Bäst för inference av mindre modeller (upp till 70B med int8). Cirka 90 000 SEK per GPU.

Quantization: int8, int4, GPTQ, AWQ, GGUF

Sammanfattat

Quantization sänker VRAM-behov och ökar throughput mot marginell kvalitetsförlust. int8 (BitsAndBytes eller GPTQ) halverar VRAM med under 2 procents förlust på benchmarks. int4 (AWQ eller GGUF-Q4) sänker till 25 procent VRAM med 3 till 8 procents förlust. FP8 (Marlin) på H100/H200 kombinerar bra kvalitet med hastighet. Fine-tuning bör göras före quantization för bäst resultat.

Quantization är gapet mellan teoretiskt VRAM-behov och praktisk produktions-realitet. Fyra format dominerar 2026:

• int8 (BitsAndBytes, GPTQ). Halverar VRAM. Under 2 procents kvalitetsförlust på MMLU-Pro för de flesta 70B-modeller. Standard-tradeoff för produktions-serving.
• int4 (AWQ, GGUF-Q4). Sänker VRAM till 25 procent av FP16. 3 till 8 procents kvalitetsförlust beroende på benchmark. Rätt val för edge, mindre GPU-budget eller kostnadskänslig batch-inferens.
• FP8 (Marlin, TransformerEngine). Native FP8 på H100 och H200. Nästan ingen kvalitetsförlust och 2x throughput jämfört med FP16. Kräver H100/H200 (inte A100 eller L40S).
• GPTQ vs AWQ. GPTQ är äldre standard, bra kompatibilitet. AWQ (Activation-aware Weight Quantization) är nyare och ger typiskt 1 till 3 procent bättre kvalitet än GPTQ vid samma bit-width. AWQ är default 2026.
• GGUF (Ollama, llama.cpp). CPU-inference-format. Rätt val för edge-deploy där GPU inte finns eller är oöverkomlig. GGUF-Q4 kör Llama 3.3 8B i acceptabel hastighet på moderna CPU:er.

Praktisk regel från Alice Labs: fine-tuna först på FP16, sedan quantize med AWQ till int4 eller int8 för produktions-serving. Att fine-tuna på redan-quantized-modell ger typiskt 5 till 15 procent sämre kvalitet.

Serving-stack: vLLM, TGI, Ollama, LMDeploy

Sammanfattat

vLLM (UC Berkeley) är produktions-serving-standard 2026 med PagedAttention, continuous batching, tensor parallel, prefix caching. Text Generation Inference (TGI, HuggingFace) är näst största val, bra observability. Ollama är utvecklarvänligt (llama.cpp-baserat) men inte produktionsklassat för hög QPS. LMDeploy från Shanghai AI Lab har bra Kina-modell-support. NVIDIA Triton med TensorRT-LLM för max-latens-kritiska scenarier.

Fem serving-stacks dominerar 2026:

• vLLM. Alice Labs default. PagedAttention plus continuous batching ger 5 till 24x throughput jämfört med naive HuggingFace serving. Tensor parallel inom nod. Prefix caching för RAG-workloads. OpenAI-compatible API.
• Text Generation Inference (TGI, HuggingFace). Nästan lika snabbt som vLLM. Bra Prometheus-observability inbyggd. HuggingFace-native integration. Val när teamet är djupt in i HuggingFace-eco.
• Ollama. Utvecklarvänligt CLI, llama.cpp-baserat. Rätt val för lokal utveckling och proof-of-concept. Inte produktionsklassat för hög QPS men excellent för dev-loops och små interna verktyg.
• LMDeploy (Shanghai AI Lab). Bra Kina-modell-support (Qwen, DeepSeek). Konkurrenskraftig throughput. Mindre community än vLLM.
• NVIDIA Triton med TensorRT-LLM. Max prestanda för latens-kritiska scenarier. Kräver NVIDIA-specifik kompilering. Val för voice-agenter och realtid där varje ms räknas.

Alice Labs stack för svensk produktion: vLLM 0.7+ på Kubernetes med KServe, prefix caching aktiverat, Prometheus plus Grafana för metrics, Langfuse för LLM-observability, Istio för service mesh, Cilium för network policy.

Fine-tuning för svenskt affärsspråk: LoRA, QLoRA, DPO

Sammanfattat

LoRA (Low-Rank Adaptation) tränar små adapter-matriser istället för hela modellen. QLoRA gör samma sak på 4-bit-quantized bas. 500 till 5 000 träningsexempel räcker för de flesta svenska enterprise-use-cases. DPO (Direct Preference Optimization) adderas efter LoRA för preferens-alignment. Träning tar timmar (LoRA) till dagar (full fine-tuning) på 4-8 H100. Ekonomi: LoRA ger 90 procent av full fine-tuning-kvalitet till 5 procent av kostnaden.

Fine-tuning-strategi 2026:

1. Steg 1: LoRA-adaptation. 500 till 5 000 domän-exempel. Träning tar 4 till 24 timmar på 4x H100. Alpha 16-32, rank 8-16, target modules q_proj, k_proj, v_proj, o_proj. Ger 90 procent av full fine-tuning-kvalitet till 5 procent av kostnaden.
2. Steg 2: DPO för preferens-alignment. Om ni har par av (bra_svar, dåligt_svar). 1 000 till 10 000 par. Kör efter LoRA. Ger tonalitet och format-consistency som SFT ensamt inte når.
3. Steg 3 (frivilligt): Full fine-tuning. Endast om LoRA + DPO inte räcker. Kräver 8x H100 i 3 till 14 dagar. Kostar tio till hundra gånger LoRA.

Data-strategier för svenskt affärsspråk:

• Domän-specifika exempel: juridiska texter för legal, medicinska journaler för sjukvård, finansiella rapporter för bank.
• Ton- och stil-mall: 100 till 500 exempel som visar ert varumärkes röst.
• Instruktionsformat: använd samma chat-template som basmodellen (Llama 3.1 template för Llama 3.3).
• Data-hygien: ta bort dubbletter, kontrollera PII, verifiera korrekthet i minst 10 procent av exemplen manuellt.

Deployment: svensk sovereign cloud vs bare-metal vs hyperscaler-tenant

Sammanfattat

Tre deploy-alternativ: (1) svensk sovereign cloud GPU (City Network, Elastx, Glesys) för sovereign kombinerad med snabb time-to-value, premium 30-100%. (2) Bare-metal i eget datacenter för max kontroll och lägst löpande kostnad efter CapEx-amortering. (3) Hyperscaler dedicated (Azure ND-series i Sweden Central, AWS EC2 P5 i Frankfurt) som mellanting. Val drivs av data-känslighet, tidshorisont och intern kompetens.

Tre deploy-alternativ dominerar 2026:

1. Svensk sovereign cloud GPU. City Network, Elastx, Glesys, GleSYS och Iver (tidigare EvroCloud) erbjuder H100- och L40S-instanser i svensk jurisdiktion. Premium 30 till 100 procent över hyperscaler-listpris. Rätt val för sekretessomfattad data där sovereignty är kärnkrav.
2. Bare-metal i eget datacenter. Max kontroll, lägst löpande kostnad efter CapEx-amortering (3 år). Kräver egen personal för fysisk drift, kylning, elektricitet, säkerhet. Kapitalinvestering: 2 till 8 MSEK för 8x H100-nod inkl. nätverk, kylning, PDU.
3. Hyperscaler dedicated (Azure ND, AWS P5, GCP A3). ND H100 v5 i Sweden Central. P5.48xlarge i Frankfurt. A3 i europe-west4. Snabbast time-to-value, högst rörlig kostnad. Rätt val för prototypfas och low-volume produktion.

Alice Labs beslutsmodell:

• Prototypfas (månad 1-3): Hyperscaler dedicated H100. Snabbast till working prototype.
• Pilot (månad 3-9): Svensk sovereign cloud GPU. Sovereignty klart, utan CapEx-lock-in.
• Produktion (månad 9+): Beslut CapEx vs OpEx baserat på 3-års-TCO och intern kompetens. Bare-metal för organisationer som redan har HPC-team. Sovereign cloud för lean-team.

TCO-modellering i SEK: CapEx bare-metal vs OpEx cloud

Sammanfattat

Bare-metal 8x H100-nod svensk mid-market: 3-4 MSEK CapEx plus 400-800 kSEK/år drift (personal, el, support). 3-års-TCO: 4,5-6,5 MSEK. Svensk sovereign cloud 8x H100-tenant: 1,2-1,8 MSEK/år. 3-års-TCO: 3,6-5,4 MSEK. Hyperscaler dedicated H100: 1,5-2,5 MSEK/år. 3-års-TCO: 4,5-7,5 MSEK. Break-even bare-metal vs sovereign cloud: månad 24-30 för mid-market.

Alice Labs TCO-modell 2026 för 8x H100-produktionsdeployment (Llama 3.3 70B, ~200 samtidiga requests, 5-10M tokens/dag):

Antaganden: Llama 3.3 70B, int8 quantization, vLLM serving, ~200 samtidiga requests, 5-10M tokens/dag. Personal och supporttid ingår i löpande. Bare-metal CapEx amorteras över 3 år. Pay-as-you-go referens: 8M tokens/dag GPT-4o Sweden Central.

Praktiska slutsatser för svenska CFO:er 2026:

• Under 2M tokens/dag: pay-as-you-go LLM API alltid billigast. Ingen self-host-kalkyl motiverad.
• 2-5M tokens/dag: pay-as-you-go med Provisioned Throughput reservation eller sovereign cloud GPU. Beroende av sovereignty-krav.
• Över 5M tokens/dag: sovereign cloud eller bare-metal. Break-even nås typiskt månad 12-30.
• Över 20M tokens/dag: bare-metal ger tydligt lägst 3-års-TCO.

Alice Labs fem vanligaste anti-patterns i svenska self-host-projekt

Sammanfattat

Fem vanligaste self-host-anti-patterns 2026: (1) välja on-premise utan tydlig sovereignty- eller volym-trigger, (2) underskatta MLOps-personalbehov (minst 2 heltider), (3) hoppa quantization och köra FP16 i produktion trots ingen kvalitetsvinst, (4) välja Ollama för produktion (utvecklarverktyg, ej production-grade), (5) fine-tuna på quantized bas istället för FP16.

Från Alice Labs 100+ svenska implementationer, fem anti-patterns vi ser gång på gång:

1. Self-host utan trigger. Vanligaste misstaget. Team väljer on-premise av felaktig anledning ("vi vill vara oberoende") utan tydlig sovereignty-, volym- eller latens-trigger. Resultat: 3x kostnad jämfört med hyperscaler och kvartalslång försening.
2. Underskatta MLOps-personalbehov. Produktions-self-host kräver minst 2 heltider (senior MLOps-ingenjör och ML-plattforms-ingenjör). Utan detta blir driftstiden lidande och incidenter droppar.
3. Hoppa quantization. FP16-serving i produktion utan quantization använder 2x GPU-resurser för 0-2 procents extra kvalitet. Nästan alltid fel val ekonomiskt.
4. Välja Ollama för produktion. Ollama är fantastiskt för utveckling men saknar continuous batching och robust concurrency. Använd vLLM eller TGI för produktion.
5. Fine-tuna på quantized bas. Kvalitetsförlust 5-15 procent jämfört med fine-tuning på FP16 följt av quantization. Fine-tuna alltid först på FP16.

Boka en self-host-arkitekturgenomgång via AI-implementation för svensk mid-market.