Kan 64 GB RAM verkligen köra DeepSeek V4 Flash 284B utan en GPU?

Ett communityprojekt uppger att det kör DeepSeek V4 Flash 284B på en Linuxdator med 64 GB minne och endast använder processorn. Den rapporterade konfigurationen använder llama-modchip, en anpassad kontrollpunkt med ungefär 1,71 bitar per vikt och en stationär processor med hög minnesbandbredd. Se det som ett dokumenterat experiment med en specifik version, inte som en allmän rekommendation för dimensionering av den officiella kontrollpunkten.

Resultatet är användbart eftersom det gör tre frågor som normalt blandas ihop mätbara: får viktfilen plats, kan processen behålla tillräckligt med minne under generering och förblir resultatet användbart vid den komprimeringsnivån? Projektet uppmärksammades i en communitydiskussion den 8 november. Mätningarna nedan kommer från underhållarens arkiv för llama-modchip, inte från oberoende tester.

Vilken DeepSeek-modell och körtidsmiljö används?

Projektet är inriktat på DeepSeek V4 Flash, som i dokumentationen beskrivs ha ungefär 284B parametrar totalt, varav cirka 13B är aktiva per token. I en mixture-of-experts-modell väljer routern experter för varje token. Det begränsar beräkningen per token, samtidigt som hela uppsättningen experter fortfarande måste lagras och göras tillgänglig. Se utvecklarens modellkort och översikten över maskinvarukraven för den vanliga driftsättningskontexten.

Experimentet använder en specialiserad omkodning och korrigeringar i ggml/llama.cpp-ekosystemet. Även en annan fil som marknadsför samma modellfamilj kan ha en annan tensorlayout eller precision. En standardbinär av llama.cpp och en konventionell GGUF bör ses som en separat lösning. Den befintliga uppdateringsguiden för llama.cpp beskriver den officiella uppdateringsvägen.

Hur får man plats med 284 miljarder parametrar i 64 GB RAM?

Med ett genomsnitt på 1.71 bitar per vikt motsvarar 284 miljarder vikter cirka 61 GB packad data i decimala enheter. Projektet rapporterar en fil på 56.56 GiB och ett maximalt resident minne för processen på 57.61 GiB i sin 256K-konfiguration. GiB och GB är olika enheter. Utgå från värdens faktiska tillgängliga minne vid testtillfället för att förstå marginalen. Reserverat minne för fast programvara, integrerad grafik och andra processer kan äta upp en stor del av en liten återstående marginal.

Resident minne och vikternas filstorlek är relaterade mått, men inget av dem fångar alla systemallokeringar. Under inläsningen kan kärnan frigöra filsystemcache eller hålla tillfälliga buffertar. Håll koll på både körprocessens minne och systemets tillgängliga minne. En hög resident mängd under ett enskilt uppmätt test beskriver inte heller alla kontextlängder och alla typer av indata.

Varför skiljer sig promptens hastighet från genereringshastigheten?

Promptbearbetning hanterar redan känd indata, så körmiljön kan batcha arbete över flera token. Genereringen är sekventiell: nästa token beror på de tidigare genererade tokenen. CPU-generering för en MoE-modell påverkas av hur snabbt maskinen kan hämta de valda expertvikterna och tillståndet från minnet. Klockfrekvens, antal minneskanaler, minnestimingar och trådplacering kan alla påverka resultatet.

Separera ett kort prompptest från en lång prompt mot ett kodarkiv. Mät tiden till den första tokenen och den efterföljande genereringen var för sig. Ett längre prefix kan dominera den totala fördröjningen även när strömningen verkar responsiv efter att den har startat. Notera om körmiljön återanvände cachelagrat tillstånd. Ett uppvärmt prefix och en kall körning besvarar olika frågor. Dokumentationen för det uppströms benchmarkverktyget beskriver mätningar av prompt och generering.

Hur mycket kvalitet går förlorad med den här precisionen?

Bitar per vikt sammanfattar lagringsbehovet, inte modellens kvalitet. Olika tensorer kan ha olika precision, och två konverteringar med liknande storlek kan bete sig olika. Långa resonemang, exakt syntax, verktygsargument och ovanliga ord är bra saker att kontrollera. Ett begripligt svar på en fråga visar att genereringen fungerar. Det visar inte att samma bygge är tillförlitligt i ett kodningsarbetsflöde.

Välj en liten referensuppsättning före testningen. Ta med en uppgift med exakt utdataformat, en funktion med ett känt felande test, en uppslagning i en lång kontext och en begäran som modellen bör hantera försiktigt. Jämför med en baslinje med högre precision eller en mindre baslinje som stöds, med samma promptar. Håll testindata oförändrade och anteckna ofullständiga utdata, felaktigt formaterade verktygsanrop och tidsgränsöverskridanden. Lås modell- och körtidsversionerna så att senare förbättringar kan hänföras till rätt ändring.

Hur skulle du återskapa resultatet på ett ansvarsfullt sätt?

Börja med en isolerad Linux-testmaskin, gott om SSD-utrymme och underhållarens exakta kontrollpunkt och revision. Läs projektets bygg- och snabbstartsinstruktioner, granska skripten innan du kör dem och anteckna processorn, minneskonfigurationen och kärnan. En kort prompt utan aktiverade skalkommandon är ett bra första test. Öka kontexten först när du vet att värddatorn förblir responsiv.

1. Mät tillgängligt minne och växlingsaktivitet innan du läser in modellen. Stoppa andra krävande experiment på samma maskin.
2. Anteckna kontrollpunktens exakta filstorlek och hash, körversionen samt eventuella särskilda inställningar för transkodning eller expertplacering.
3. Mät högsta RSS, tiden till första token, utdatahastigheten i token per sekund och om växlingsutrymme användes. Kör testet två gånger för att skilja kallstartsbeteende från cacheeffekter.
4. Jämför resultatens korrekthet innan du använder modellen för ett längre jobb. Kontrollera dataexponering och filsystemsåtkomst om du senare ansluter en agent.

Använd isolerade Git-arbetsträd för uppgifter i kodarkiv. Om värddatorn också hanterar hushållets lagring eller säkerhetskopiering bör du göra det första experimentet på en separat beräkningsdator. En inferensprocess som använder nästan allt RAM kan störa de tjänsterna långt innan den avslutas på grund av minnesbrist.

När bör du välja en mindre modell i stället?

Välj en mindre checkpoint när du behöver jämn, interaktiv hastighet, enkla uppdateringar eller tillräcklig marginal för flera sessioner. Community-experimentet är mest intressant om du kan acceptera anpassad kod, lägre precision och noggrann reproduktion. En daglig modell som fungerar i en miljö med stöd kan vara enklare att underhålla och hinna slutföra fler användbara uppgifter per timme. Jämför båda på samma uppgift innan du ändrar en produktionskonfiguration.

Vanliga frågor

Kräver detta ett dedikerat grafikkort?

Underhållaren rapporterar en körning utan GPU för den angivna checkpointen på 284B. Andra konfigurationer i förvaret inkluderar varianter med GPU-stöd, så håll testprofilerna åtskilda.

Kommer alla datorer med 64 GB att uppnå den rapporterade hastigheten?

Installerat minne i sig ger inget generellt hastighetslöfte. CPU-generering beror på minnesbandbredd, kärnor och trådplacering, och systemet behöver tillräckligt med tillgängligt RAM.

Är 44 tok/s hastigheten jag kommer att se i en chattström?

Uppgiften om cirka 44 tok/s gäller promptbearbetning i den angivna konfigurationen. Förvaret rapporterar ett separat, lägre intervall för autoregressiv generering.

Är 256K-kontext det första du bör testa?

Börja med kortare sammanhang och mät. Minnesvärdet från underhållaren gäller en specifik kombination av körmiljö och checkpoint.

Ersätter detta den publicerade hårdvaruguiden?

Använd den officiella modellguiden för standarddriftsättning. Se llama-modchip som ett community-alternativ med egna begränsningar vad gäller precision, kompatibilitet och prestanda.

Slutsats

Det intressanta resultatet är att en viss CPU-runtime och en anpassad checkpoint med låg precision kan rymma en oväntat stor MoE-modell inom en snäv minnesbudget. Återskapa exakt samma bygge, skilj mellan prefill och avkodning och testa resultatets kvalitet innan du förlitar dig på det. En mindre modell är fortfarande användbar som jämförelse när du utvärderar svarstiden vid vardaglig användning.