Hur du väljer rätt öppen källkods-modell och hårdvara

Att driftsätta en privat LLM börjar med två beslut som är djupt sammanvävda: vilken modell man ska köra och vilken hårdvara man ska köra den på. Få paret fel och du antingen överspenderar på kapacitet du inte använder eller undersätter den beräkning som ditt användningsfall faktiskt behöver. Den goda nyheten är att det öppna källkodsekosystemet har mognat till den punkt där det finns en väl testad modell för nästan varje budget och uppgift – om du vet hur du matchar dem.

Börja från användningsfallet, inte riktmärket

Det vanligaste misstaget vid modellurval är att leda med riktmärkesresultat snarare än uppgiftskrav. En modell som uppnår toppresultat på ett kodningsriktmärke kan vara överdrivet stor för att sammanfatta supportärenden och kan introducera latens som gör den olämplig för realtidsanvändning. Innan du väljer en modellstorlek, definiera ditt användningsfall exakt: Vad är den genomsnittliga inlängden i tokens? Kräver uppgiften flerstegsbeslutning eller är det primärt klassificering och extraktion? Hur många samtidiga användare kommer systemet att betjäna? Vad är den acceptabla svarstiden? Vilka språk måste modellen hantera flytande? Dessa frågor begränsar ditt sökutrymme mycket mer användbart än någon topplista.

Modellstorleksnivåer: 7–8B, 32–70B och 405B+

Det öppna källkodsmodelllandskapet har konsoliderat kring tre praktiska storleksnivåer. Modeller i intervallet 7–8B parametrar – såsom Mistral 7B, Llama 3.1 8B och Qwen2.5 7B – är anmärkningsvärt kapabla för fokuserade uppgifter: dokumentklassificering, extraktion, sammanfattning och FAQ-liknande frågesvar över ett hämtningskorpus. De körs bekvämt på en enda konsument- eller prosument-GPU och levererar låg latens även utan tung optimering. Intervallet 32–70B – Llama 3.3 70B, Qwen2.5 32B, Mixtral 8x7B – är där generell slutledning, flerspråklig flytande och instruktionsföljning förbättras avsevärt. Dessa modeller kan hantera komplexa analytiska uppgifter, längre sammanhang och mer nyanserad generering. De kräver professionella GPU:er men förblir möjliga för en enda serverdriftsättning. Ovanför 70B levererar modeller som Llama 3.1 405B frontlijekapacitet men kräver flerGPU-setup och noggrann infrastrukturplanering; de är bäst reserverade för användningsfall där kvalitet är den primära begränsningen och budget inte är det.

• 7–8B-modeller: bäst för fokuserade, höggenomströmningsuppgifter – klassificering, extraktion, RAG över strukturerade data. Enskild GPU, lägst kostnad.
• 32–70B-modeller: stark generell slutledning, flerspråkigt stöd, längre sammanhang. Enskild avancerad GPU eller liten flerGPU-nod.
• 405B+-modeller: frontlinjekvalitet för de mest krävande uppgifterna. FlerGPU krävs; planera infrastrukturen noggrant.
• Mixture-of-experts (MoE)-arkitekturer (t.ex. Mixtral) kan leverera 70B-klassens kvalitet till en kostnad som liknar 13B aktiva parametrar – värt att utvärdera om genomströmning spelar roll.

Matcha modeller till GPU:er: VRAM är den bindande begränsningen

GPU VRAM är den primära begränsningen som avgör vilka modeller du kan köra och med vilken hastighet. En modell måste rymmas i VRAM för inferens – med ytterligare utrymme för KV-cachen, som växer med kontextlängd och batchstorlek. Som en ungefärlig guide: en 7–8B-modell i 16-bitars precision kräver ungefär 14–16 GB VRAM; en 32B-modell behöver ungefär 64 GB; en 70B-modell behöver ungefär 140 GB. Det är därför en enskild 24 GB GPU (som NVIDIA RTX 3090 eller 4090) är det naturliga hemmet för 7–8B-modeller, ett 48 GB-kort (RTX 6000 Ada) eller 80 GB A100/H100 täcker intervallet 32–70B på ett enda kort och allt större kräver flerGPU-konfigurationer med NVLink- eller InfiniBand-sammankopplingar.

Kvantisering: nå bortom din VRAM-budget

Kvantisering minskar precisionen på modellvikter – från 16-bitars flyttal till 8-bitars heltal (INT8) eller 4-bitars (GPTQ, AWQ, GGUF Q4) – vilket dramatiskt minskar VRAM-kraven. En 70B-modell kvantiserad till 4-bitars kan rymmas i ungefär 35–40 GB VRAM, vilket gör den tillgänglig på en dubbel 24 GB GPU-setup. Kvalitetsavvägningen beror på kvantiseringsmetoden och uppgiften: för de flesta produktionsanvändningsfall är INT8 nästan förlustfritt och väl implementerad 4-bitarskvantisering bevarar majoriteten av modellkvaliteten för uppgifter som inte är mycket känsliga för subtila slutledningsfel. Kvantisering är inte en lösning – det är en förstklassig driftsättningsstrategi som Privonis rutinmässigt använder för att maximera kapacitet per euro av hårdvarubudget.

Den rätta frågan är inte "vilken modell är bäst?" utan "vilken modell är tillräcklig för denna uppgift, med den hårdvarubudget vi har?" Kvantisering stänger klyftan mellan de två svaren mer än de flesta team förväntar sig.

Riktmärkning innan du köper: utvärderingsfärst-metoden

Inget riktmärke ersätter utvärdering av en modell på dina faktiska data och uppgifter. Innan du åtar dig hårdvara rekommenderar Privonis att köra en strukturerad utvärdering: definiera en representativ uppsättning indata från ditt produktionsanvändningsfall, fastställ kvalitetskriterier (noggrannhet, formatföljning, latens vid din målbatchstorlek) och testa två eller tre kandidatmodeller på hyrda moln-GPU-instanser. Det kostar några hundra euro och tar vanligtvis en dag eller två. Resultatet är en evidensbaserad hårdvaruspecifikation snarare än en gissning – och det avslöjar ofta att en mindre, snabbare modell uppfyller dina behov, vilket sparar betydande kapitalutgifter.

• Definiera utvärderingsindata från verkliga produktionsdata innan du väljer modell.
• Testa på hyrd GPU-kapacitet först – molninstanser för utvärdering, lokal driftsättning för produktion.
• Mät det som spelar roll: uppgiftsnoggrannhet, p95-latens, tokens per sekund vid din förväntade batchstorlek.
• Överväg att finjustera en mindre modell innan du skalar till en större – en finjusterad 7B-modell överträffar ofta en generisk 70B-modell på smala uppgifter.
• Planera för KV-cachen: längre sammanhang förbrukar VRAM snabbt; riktmärk vid maximal förväntad kontextlängd.

Hur Privonis vägleder urvalsprocessen

Att välja rätt kombination av modell och hårdvara är ett av de mest effektfulla besluten i en privat AI-driftsättning. En välmatchad stack levererar den kvalitet du behöver till en kostnad som gör affärsärendet tydligt; en dåligt matchad antingen överspenderar på ledig beräkning eller underpresterar på uppgifter som spelar roll. Privonis har praktisk erfarenhet av att välja, kvantisera, finjustera och riktmärka öppna källkods-LLM:er över ett brett spektrum av europeiska företagsanvändningsfall. Vi hjälper dig att undvika den dyra prova-och-felade cykeln och att komma fram till en driftsättningskonfiguration som är rätt dimensionerad från start – och som förblir hanterbar i takt med att modeller och dina användningsfall utvecklas.