Öppna och lokala modeller
En öppen modell är en fil med vikter som du kan ladda ner och köra på din egen dator, så länge filen får plats i minnet och licensen tillåter det. Här går vi igenom hur du läser av storlekar som 7B eller 70B, kollar upp licensen och väljer mellan ett snabbt svar eller en modell som tänker högt först.
Nybörjare
Vad du laddar ner
En basmodell är en fil med inlärda tal, så kallade vikter, plus en kort header som talar om hur de ska läsas. B:et i 7B eller 70B står för miljarder parametrar, alltså ett sparat tal per parameter. Med 16-bitars precision tar varje tal 2 bytes, så en fil med 7 miljarder parametrar landar på ungefär 14 GB och en med 70 miljarder på runt 140 GB – innan minnet för själva samtalet räknas in. Kvantisering innebär att varje tal sparas med färre bitar. llama.cpp, ett program som kör modeller direkt på din dator, stöder heltal från ungefär 1,5 bitar upp till 8 bitar.
Står det öppen på en nedladdningssida betyder det att du kan hämta hem vikterna. Licensen avgör vad du får göra sedan. Gemma 4, från Google DeepMind, använder Apache License 2.0. Du får använda, ändra och dela den vidare, även i en färdig produkt, så länge du skickar med licensen, märker ut filer du har ändrat och behåller de ursprungliga notiserna. Den ger dig patenträttigheter från bidragsgivarna och friskriver garanti. En modell du laddar ner kan fortfarande förbjuda kommersiell användning eller ställa krav på hur den får användas. Läs alltid licensen på modellkortet innan du sätter igång ett kundprojekt.
En resonerande modell skriver först ut sina tankesteg och sedan ett kortare svar. I Gemma 4 startar tänkandet om systemprompten börjar med <|think|>. Stegen tar tid och fyller upp kontextfönstret, så för en kort fråga passar det snabbare läget utan tänkande bättre. Om en lokal körning kraschar finns det tre vanliga orsaker att kolla: minnet tog slut så processen stängdes ner, filen på disken stämmer inte med kortet, eller så saknade prompten felmeddelandet och den omgivande funktionen.
Får den här modellen plats på min dator?
Jag har [RAM] GB arbetsminne och [grafikminne] GB grafikminne. Jag vill köra [modellnamn]. Förklara vad en viktfil är. Uppskatta om en modell med 7 miljarder parametrar och en modell med 70 miljarder parametrar skulle få plats i 16-bit (2 bytes per tal) och i ungefär 4-bit, innan minne för samtalet räknas in. Läs licensen på modellkortet och berätta på enkel svenska vad jag får göra med vikterna, inklusive kommersiell användning. Om programmet avslutas under laddningen, ge mig de tre första sakerna jag ska kontrollera. Ta inte för givet att modellen redan får plats.
Medel
Läs kortet och ladda sedan filen
Läs modellkortet innan du laddar ner. Där ser du antal parametrar, kontextfönster, licens och vilka indata som stöds. På kortet för Gemma 4 anger E2B och E4B 128 000 tokens. Modellerna 12B, 26B A4B och 31B anger 256 000. E2B har 2,3 miljarder effektiva parametrar och 5,1 miljarder med inbäddningar. Modellen 26B A4B är en mixture-of-experts-modell som rymmer cirka 25,2 miljarder parametrar men bara använder ungefär 3,8 miljarder per token – en hastighet som kortet jämför med en modell kring 4 miljarder. Den täta (dense) 31B-modellen använder alla 30,7 miljarder vid varje token. Eftersom alla experter ligger kvar i filen styrs diskutrymmet av totalen, medan tokens per sekund styrs av det aktiva antalet.
GGUF är filformatet som llama.cpp läser in som en enda fil. Filnamnen visar storlek och kodning, till exempel Q4_K_M eller F16. En 4-bit-fil är ungefär en fjärdedel så stor som motsvarande i 16-bit. Kvalitetsförlusten märks först på exakt kod, långa matematiska beräkningar och ovanliga ord. Samtalsminnet växer i takt med hur många tokens du sparar, så en modell som fungerar fint för en kort chatt kan krascha vid en längre prompt.
I README-filen för llama.cpp används kommandot llama cli -hf ggml-org/Qwen3.5-0.8B-GGUF för att hämta en liten öppen fil och starta en chatt, och llama serve för ett lokalt API. Om processen avslutas (kill) under laddningen är filen större än det lediga minnet. Missar svaret din funktion helt kan prompten ha kapats, eller så var tänkandet påslaget för en ändring på en enda rad. Anteckna alltid modell-id, kodning, kontextlängd och vilket kommando du körde.
Planera en lokal körning som går att upprepa
Här är ett modellkort: [klistra in modellkortet] Ge mig antal parametrar, kontextfönster, licens och berätta om modellen är dense eller en mixture of experts. Om både totalt och aktivt antal parametrar anges, tala om vilken siffra som styr filstorleken och vilken som styr tokens per sekund. Uppskatta filstorleken för 16-bit-vikter räknat på 2 bytes per parameter, och en uppskattad storlek för 4-bit på ungefär en fjärdedel av det. Nämn också vilket minne som tillkommer utöver själva filen. Ge mig sedan stegen för att testa llama.cpp med en minimal öppen GGUF innan jag laddar ner modellen, och lista de fyra fälten jag bör anteckna så att en senare körning matchar den här.
Expert
Svarstider, diffar och en jobbkö
llama.cpp kör en modell på en maskin, på CPU eller GPU (CUDA, Metal eller Vulkan), och kan lägga överblivna vikter i systemminnet. vLLM hanterar många anrop samtidigt med modellen fast laddad i grafikminnet. Dess offline-API kan generera svar, chatta och köa upp batcher med continuous batching. Använd llama.cpp för att testa om modellen får plats och vLLM när du vill ha en delad kö.
Tiden till första synliga token och den totala svarstiden ökar när tänkandet är på, eftersom modellen skriver sitt resonemang först. I Gemma 4 slår du på det med <|think|> i början av systemprompten. Ta inte med tidigare tankesteg i senare samtalsrundor, utom vid verktygsanrop. Minnet för key-value växer med kontextlängden och antalet parallella jobb, så sätt ett tak för varje körning. Ladda in 4-bit-vikter när 16-bit inte får plats, och välj 8-bit eller 16-bit för precisa kodändringar.
När du vill granska kod skickar du med en git diff, det fallerande testet och en regel om att orörda filer ska lämnas ifred. Fråga vilket handtag som läcker eller vilken lista som växer utan gräns, och kör sedan testerna själv. HumanEval betygsätter korta funktioner mot enhetstester. Dess kodarkiv underhålls inte längre och har själva testkörningen utkommenterad så att modellens kod bara körs i en sandbox. SWE-bench mäter hur stor andel riktiga GitHub-ärenden från 12 Python-arkiv som löses, med 2 294 i det fulla testsetet och 500 i det manuellt granskade Verified-setet.
Testramverket från EleutherAI upprepar publicerade tester via llama.cpp eller vLLM. Logga datum, maskin, kvantisering, maxtak för kontext och version av testramverket tillsammans med resultatet. En delad DGX Station skulle kunna fungera som en kö med ett jobb i taget för en 70B-modell med högre precision eller en hel testomgång.
Granska en diff och specificera körloggen
Jag klistrar in en git diff och ett fallerande test. Skriv inte om filer som inte berörs av diffen. Peka ut det handtag som aldrig stängs eller datastrukturen som växer utan gräns, och föreslå sedan minsta möjliga ändring. Vänta på att jag kör testerna själv. Beskriv också separat hur man mäter tid till första token, tokens per sekund och aktivt minne vid laddning, vid första token och efter att programmet avslutats. Ange om jobbet bör köras i llama.cpp på en enskild dator eller som ett jobb i en kö på en delad NVIDIA DGX Station (748 GB sammanhängande minne). Lista fälten som ska sparas tillsammans med ett testresultat från EleutherAI lm-evaluation-harness: datum, maskin, kvantisering, kontexttak och version av testramverket. Diff: [klistra in] Fallerande test: [klistra in]
Får filen plats?
Dessa gigabyte-siffror är ren matematik utifrån antalet parametrar: 2 bytes per parameter i 16-bit, och ungefär en fjärdedel av det i 4-bit. En verklig GGUF-fil är ofta lite större eftersom vissa lager behåller en högre precision, och minnet för själva samtalet tillkommer. Mät filen och kontrollera hur mycket ledigt minne du har på din dator.
| Klass | 16-bit-vikter | 4-bit, riktmärke | Var den oftast hör hemma |
|---|---|---|---|
| 7B | cirka 14 GB | cirka 4 GB | Många datorer med 8–16 GB grafikminne, så länge kontexten hålls kort |
| Gemma 4 31B (30,7 miljarder enligt kortet) | cirka 61 GB | cirka 15 GB | En arbetsstations-GPU eller en dator med mycket delat minne |
| 70B | cirka 140 GB | cirka 35 GB | En kraftfull arbetsstation. Lång kontext gör att det blir trångt på ett vanligt grafikkort |
| NVIDIA DGX Station | 748 GB sammanhängande minne: 252 GB HBM3e vid grafikprocessorn och 496 GB LPDDR5X vid processorn | Samma minnespool, med högre precision och längre kontext | En arbetsstation av typen DGX Station, om Polaris köper en. NVIDIA uppger stöd för modeller upp till cirka 1 biljon parametrar |
Om 16-bit inte vill ladda, testa 8-bit innan du går ner till 4-bit när du jobbar med kod. Om 4-bit laddar men kraschar mitt i chatten, sänk kontextlängden innan du kastar filen.
Vad en delad körning sparar
Om Polaris köper en delad maskin bör en tung körning där vara ett eget köobjekt med modell-id, kodning, kontexttak, uppgift (chatt, diffgranskning eller testramverk) och en tidsgräns. Resultatraden ska innehålla datum, maskinens namn och kommandot som kördes. Ett jobb i taget är det självklara valet, eftersom en andra modell i samma minne delar på resurserna. Marknaden och jobbtavlan har inte öppnat än, och det finns ingen delad kö att ansluta sig till idag. Du kan redan nu spara en sådan rad på din egen dator.
Kontroller innan du litar på ett lokalt svar
- Jämför filnamnet med modellkortet: parameterklass och kodning.
- Kontrollera ledigt minne före laddning, och igen efter att processen har avslutats.
- Börja med en kort kontext. Öka den först när du har fått ett fungerande svar.
- Låt tänkandet vara avstängt för rena syntaxfel. Slå på det när felet berör flera filer.
- Kör testerna själv innan du litar på ett svar som säger att de gick igenom.
- Använd en sandbox för benchmark-kod. Kodarkivet för HumanEval levereras med körningen utkommenterad tills du själv accepterar risken.
- Spara licensfilen bredvid vikterna om du delar dem vidare. Apache-2.0 kräver själva licensen, information om ändringar och ursprungliga upphovsangivelser.
En gemensam DGX Station, med de 748 GB sammanhängande minne som NVIDIA anger för systemet, skulle fungera som en kö med ett jobb i taget för öppna modeller och testkörningar som inte får plats på en bärbar dator. Om den gemensamma stationen
Källor
- NVIDIA DGX StationOfficiell specifikationssida: 748 GB sammanhängande minne (252 GB HBM3e plus 496 GB LPDDR5X), samt NVIDIAs uppgift om att systemet hanterar modeller upp till cirka 1 biljon parametrar.
- llama.cppLokal inferens i C/C++, heltalskvantisering från cirka 1,5-bit till 8-bit, samt README-kommandon för en liten GGUF-chatt och en lokal server.
- Gemma 4 model cardStorlekar, kontextlängder, antal parametrar för mixture-of-experts, styrning av tänkande och uppgiften om Apache-2.0. Sidans text lyder under Creative Commons Attribution 4.0. Den här sidan sammanfattar den.
- Apache License, Version 2.0Licenstexten: användning, ändring, distribution, patenträttigheter, krav på notiser och friskrivning från garanti.
- vLLM offline inferenceAktuell stabil dokumentation för LLM.generate, LLM.chat och API:erna för köhantering, inklusive hur batch-körningar håller en GPU sysselsatt.
- Language Model Evaluation HarnessEleutherAIs ramverk för att upprepa publicerade tester mot en lokal fil, inklusive en server via llama.cpp och en backend för vLLM.
- SWE-benchTopplista för felrättning i kodarkiv: 2 294 ärenden från 12 Python-arkiv i hela datamängden, 500 i det manuellt granskade Verified-setet, mätt i andel lösta problem.
- HumanEvalDet ursprungliga testramverket för korta programmeringsuppgifter. Kodarkivet underhålls inte längre och uppmanar till att bara köra modellgenererad kod i en sandbox.