Det första grova provet är om modellvikter, kontext och körmiljön ryms samtidigt med marginal. Därefter avgör minnesbandbredd, beräkningskapacitet och samtidighet hur snabbt systemet känns.
Bygg en minnesbudget
En modells parameterantal är inte samma sak som dess faktiska minnesbehov. Kvantisering minskar utrymmet för vikterna, men du behöver också plats för kontextcache, runtime, grafikdrivrutin och operativsystem. Längre kontext och flera samtidiga förfrågningar kan göra en installation instabil även om en kort enkel prompt fungerar.
Budgeten har fyra poster. De tre första går att räkna fram innan du laddar ner något; den fjärde är den du inte får låna av.
1. Vikterna
Enklaste mätningen är modellfilens storlek på disk — den är i praktiken vad vikterna tar i minnet. Vill du räkna före nedladdningen: parametrar × bitar per vikt ÷ 8. En fyrbitarskvantisering landar i verkligheten kring 4,5–5 bitar per vikt, eftersom delar av modellen sparas med högre precision.
2. KV-cachen
Kontexten är inte gratis. Cachen växer linjärt med antalet tokens:
2 × lager × KV-huvuden × huvuddimension × kontextlängd × byte per element
Tvåan är nyckel och värde. Lager, KV-huvuden och huvuddimension står i modellkortet eller i filens metadata. Modeller med grupperad frågeuppmärksamhet har betydligt färre KV-huvuden än uppmärksamhetshuvuden, och det är därför posten är hanterbar alls — saknas den egenskapen blir cachen flera gånger större.
3. Runtime, buffertar och drivrutin
Beräkningsbuffertar, drivrutinens egen reservation och operativsystemets behov när minnet delas. Den här posten går att uppskatta till ett par gibibyte, men ska mätas i den installation du faktiskt kör.
4. Marginal
Nominellt minne är inte användbart minne. En del är upptaget av skärm och drivrutin innan modellen ens startar.
Ett räknat exempel
Exemplet är påhittat och visar räkningen. Sätt in modellkortets egna värden — och mät sedan utfallet, eftersom runtimeposten varierar.
| Post | Räkning | Utfall |
|---|---|---|
| Vikter | 8 miljarder parametrar × 4,9 bitar ÷ 8 | ≈ 4,6 GiB |
| KV-cache | 2 × 32 lager × 8 KV-huvuden × 128 × 8 192 tokens × 2 byte | 1,0 GiB |
| Runtime och buffertar | uppmätt i den egna installationen | ≈ 1,5 GiB |
| Summa | en samtidig förfrågan | ≈ 7,1 GiB |
| Användbart på ett kort med 12 GiB | nominellt minus skärm och drivrutin | ≈ 11 GiB |
| Marginal | ≈ 3,9 GiB |
Lägg nu till samtidighet. Fyra parallella förfrågningar behöver fyra KV-cachar: posten går från 1,0 till 4,0 GiB och summan till drygt 10 GiB. Marginalen är i praktiken borta, trots att en enskild prompt fortfarande svarar precis som förut. Det är den vanligaste anledningen till att en pilot som fungerade för en person blir instabil som delad tjänst.
Tre sätt att få ner budgeten, i den ordning som brukar kosta minst kvalitet: korta kontexten till vad arbetslasten faktiskt behöver, kvantisera KV-cachen om runtimen stöder det, och först därefter byt till en mindre modell eller hårdare kvantisering. Hur du hittar den längsta kontext som fortfarande får plats på din egen maskin står i Längre kontext kostar minne. Kör provpaketet från pilotspecifikationen efter varje ändring — alla tre påverkar resultatet och inte bara minnessiffran.
Planera inte för att precis fylla allt tillgängligt minne. Mät en representativ körning och behåll marginal för längre indata, uppdateringar och andra processer.
Tre vanliga maskinprofiler
| Profil | Styrka | Begränsning | Passar när |
|---|---|---|---|
| CPU och vanligt RAM | Låg starttröskel och stor minnesmängd kan vara billig | Ofta långsammare tokenproduktion | Du provar små modeller, batchjobb eller accepterar väntetid |
| Separat GPU | Hög beräkningskapacitet och moget verktygsstöd | Modellen begränsas av GPU-minnet eller måste delas mellan GPU och RAM | Interaktiv användning och hög svarshastighet är viktigt |
| Delat minne | CPU och GPU använder samma minnespool | Prestanda och maximal användbar minnesandel varierar mellan system | Du vill köra modeller som ryms bekvämt i den gemensamma poolen |
Mät hela arbetslasten
En chatt med en användare säger lite om en intern tjänst med flera samtidiga klienter. Skriv därför ner inmatningens typiska längd, önskad svarslängd, antal samtidiga förfrågningar och hur länge användaren får vänta. Mät starttid, tid till första token, fortsatt genereringshastighet, maximal minnesanvändning och vad som händer när två eller fler anrop överlappar.
Inköpsordningen
- Välj två eller tre modellkandidater från modellguiden.
- Kör samma provpaket på en maskin du redan har eller kan låna.
- Dokumentera minne, svarstid, kvalitet och effektförbrukning för normalfallet.
- Identifiera flaskhalsen: kapacitet, bandbredd, beräkning eller samtidighet.
- Köp bara om mätningen visar att hårdvaran löser just den flaskhalsen.
Glöm inte driften
En server kräver fysisk plats, kylning, ström, uppdateringar, åtkomstkontroll och reservrutin. En bärbar dator är lätt att börja med men svår att dela stabilt. Räkna därför både inköpspris och arbetet för att hålla tjänsten säker och tillgänglig.
Källor
- Ollama — kontextlängd och ökat minnesbehov
- Ollama — CPU/GPU-placering, parallella anrop och minnesskalning
- LM Studio — aktuella systemkrav per operativsystem
- llama.cpp — hårdvarubackends och hybridkörning mellan CPU och GPU
Källorna kontrollerades 1 september 2026 och ska kontrolleras på nytt senast 30 september 2026. Mätvärden beror på modell, kvantisering, runtime, drivrutin och maskin.