Kan 64 GB RAM DeepSeek V4 Flash 284B echt zonder GPU draaien?

Een communityproject meldt dat het DeepSeek V4 Flash 284B uitvoert op een Linux-machine met 64 GB geheugen, uitsluitend met de CPU. De gerapporteerde opstelling gebruikt llama-modchip, een aangepast checkpoint van ongeveer 1,71 bits per gewicht en een desktop-CPU met een hoge geheugenbandbreedte. Beschouw dit als een gedocumenteerd experiment met een specifieke build, niet als een algemene aanbeveling voor de dimensionering van de officiële checkpoint.

Het resultaat is nuttig omdat het drie vragen die doorgaans op één hoop worden gegooid meetbaar maakt: past het gewichtsbestand, kan het proces tijdens het genereren voldoende geheugen vrijhouden en blijft de uitvoer bruikbaar bij dat compressieniveau? Het project kwam aan bod in een discussie van de community op 8 november. De onderstaande metingen komen uit de repository van de maintainer van llama-modchip, niet uit onafhankelijke tests.

Welk DeepSeek-model en welke runtime zijn hierbij betrokken?

Het project richt zich op DeepSeek V4 Flash, dat in de documentatie wordt omschreven als een model met in totaal ongeveer 284B parameters, waarvan er per token ongeveer 13B actief zijn. Bij een mixture-of-experts-model kiest de router experts voor elke token. Daardoor blijft de berekening per token beperkt, terwijl de volledige verzameling experts wel moet worden opgeslagen en toegankelijk moet zijn. Zie de modelkaart van de ontwikkelaar en het overzicht van de hardwarevereisten voor de gebruikelijke implementatiecontext.

Het experiment gebruikt een gespecialiseerde transcodering en patches voor het ggml/llama.cpp-ecosysteem. Zelfs een ander bestand dat dezelfde modelfamilie aankondigt, kan een andere tensorindeling of precisie hebben. Een standaard llama.cpp-binary en een conventionele GGUF moeten als een afzonderlijk traject worden beschouwd. De bestaande handleiding voor de llama.cpp-update behandelt het traject van de upstream-release.

Hoe passen 284 miljard parameters in 64 GB RAM?

Bij gemiddeld 1.71 bits per gewicht impliceren 284 miljard gewichten ongeveer 61 GB aan verpakte gegevens in decimale eenheden. Het project rapporteert een bestand van 56.56 GiB en een piek-resident geheugen van het proces van 57.61 GiB in de 256K-configuratie. GiB en GB zijn verschillende eenheden. Gebruik het daadwerkelijk beschikbare geheugen van de host tijdens de test om de marge te bepalen. Firmware-reserveringen, geïntegreerde grafische chips en andere processen kunnen een groot deel van een kleine resterende marge opslokken.

Resident geheugen en de bestandsgrootte van gewichten zijn verwante metingen, maar geen van beide omvat alle systeemtoewijzingen. Tijdens het laden kan de kernel de bestandssysteemcache vrijmaken of tijdelijke buffers vasthouden. Houd zowel het geheugen van de runner als het beschikbare systeemgeheugen in de gaten. Een hoge resident set tijdens één vastgelegde test zegt ook niets over alle contextlengtes en invoertypen.

Waarom verschillen promptsnelheid en generatiesnelheid?

Promptverwerking verwerkt invoer die al bekend is, zodat de runtime werk over meerdere tokens kan verdelen. Generatie verloopt sequentieel: het volgende token hangt af van de eerder gegenereerde tokens. CPU-generatie voor een MoE-model is gevoelig voor hoe snel de machine de geselecteerde expertgewichten en status door het geheugen kan verplaatsen. Kloksnelheid, aantal geheugenkanalen, geheugentimings en threadplaatsing kunnen allemaal de uitkomst beïnvloeden.

Scheid een korte prompttest van een lange repositoryprompt. Meet de tijd tot het eerste token en de daaropvolgende generatie afzonderlijk. Een langere prefix kan de totale latentie domineren, ook als de stream na de start responsief lijkt. Noteer of de runtime de gecachte status heeft hergebruikt. Een opgewarmde prefix en een koude run beantwoorden verschillende vragen. De documentatie van de upstream benchmarktool legt metingen van prompts en generatie uit.

Hoeveel kwaliteit verlies je bij deze precisie?

Bits per gewicht geeft een indicatie van de opslaggrootte, niet van de modelkwaliteit. Verschillende tensors kunnen een verschillende precisie krijgen, en conversies met ongeveer dezelfde bestandsgrootte kunnen zich anders gedragen. Langere redeneringen, exacte syntaxis, toolargumenten en ongebruikelijke woordenschat zijn goede punten om te controleren. Een leesbaar antwoord op één vraag laat zien dat de generatie werkt. Het bewijst niet dat dezelfde build betrouwbaar is voor een programmeerworkflow.

Kies vóór het testen een kleine referentieset. Neem een taak op met een exact uitvoerformaat, een functie met een bekende falende test, een opzoektaak met lange context en een verzoek dat het model voorzichtig moet behandelen. Vergelijk de resultaten met een baseline met hogere precisie of een kleiner ondersteund model, met dezelfde prompts. Houd de testinvoer ongewijzigd en noteer onvolledige uitvoer, onjuist opgemaakte toolaanroepen en time-outs. Leg de revisies van het model en de runtime vast, zodat latere verbeteringen aanwijsbaar zijn.

Hoe zou je het resultaat op verantwoorde wijze reproduceren?

Begin met een geïsoleerde Linux-testmachine, voldoende SSD-ruimte en exact het checkpoint en de revisie van de beheerder. Lees de bouw- en snelstartinstructies van het project, inspecteer scripts voordat je ze uitvoert en noteer je CPU, geheugenconfiguratie en kernel. Een korte prompt zonder ingeschakelde shelltools is een goede eerste test. Vergroot de context pas als je weet dat de host responsief blijft.

1. Meet het beschikbare geheugen en de wisselgeheugenactiviteit voordat je het model laadt. Stop andere zware experimenten op dezelfde machine.
2. Noteer de exacte bestandsgrootte en hash van het checkpoint, de versie van de runner en eventuele speciale instellingen voor transcodering of expertplaatsing.
3. Leg het piekgeheugengebruik (RSS), de tijd tot het eerste token, het aantal uitvoertokens per seconde en het eventuele gebruik van wisselgeheugen vast. Voer de test twee keer uit om koudstartgedrag van cache-effecten te onderscheiden.
4. Vergelijk de juistheid van de uitvoer voordat je het model voor een grotere taak gebruikt. Controleer of gegevens kunnen uitlekken en of het bestandssysteem toegankelijk is als je later een agent koppelt.

Gebruik geïsoleerde Git-worktrees voor repositorytaken. Als de host ook opslag- of back-updiensten voor het huishouden levert, voer het eerste experiment dan uit op een aparte computermachine. Een inferentieproces dat al het RAM gebruikt, kan die diensten verstoren lang voordat er een out-of-memory-fout optreedt.

Wanneer kies je beter een kleiner model?

Kies een kleiner checkpoint als je consistente interactieve snelheid, eenvoudige updates of voldoende ruimte voor meerdere sessies nodig hebt. Het community-experiment is vooral interessant als je aangepaste code, lagere precisie en een zorgvuldige reproductie acceptabel vindt. Een dagelijks model dat in een ondersteunde runtime past, is mogelijk eenvoudiger te onderhouden en kan per uur meer nuttig werk afronden. Vergelijk beide met dezelfde taak voordat je een productieconfiguratie wijzigt.

Veelgestelde vragen

Is hiervoor een losse GPU nodig?

De maintainer vermeldt een CPU-only-run voor het opgegeven 284B-checkpoint. Andere configuraties in de repository bevatten varianten met GPU-ondersteuning, dus houd de testprofielen gescheiden.

Haalt elke pc met 64 GB de gerapporteerde snelheid?

Alleen op basis van het geïnstalleerde geheugen kun je geen algemene uitspraak over de snelheid doen. CPU-generatie hangt af van geheugenbandbreedte, kernels en threadplaatsing, en het systeem moet voldoende beschikbaar RAM hebben.

Is 44 tok/s de snelheid die ik in een chatstream zal zien?

De genoemde snelheid van ongeveer 44 tok/s heeft betrekking op promptverwerking in de aangehaalde setup. De repository vermeldt een lager, afzonderlijk bereik voor autoregressieve generatie.

Is een context van 256K de eerste instelling die je moet proberen?

Begin met een kortere context en meet de prestaties. Het geheugencijfer van de maintainer is gekoppeld aan een specifieke runner- en checkpointconfiguratie.

Vervangt dit de gepubliceerde hardwarehandleiding?

Gebruik de officiële modelhandleiding voor standaardimplementatie. Beschouw llama-modchip als een community-oplossing met eigen beperkingen op het gebied van precisie, compatibiliteit en prestaties.

Conclusie

Het interessante resultaat is dat een specifieke CPU-runtime en een aangepast low-bit-checkpoint een onverwacht groot MoE-model binnen een krap geheugenbudget kunnen laten passen. Reproduceer exact de build, maak onderscheid tussen prefilling en decoderen en test de uitvoerkwaliteit voordat je erop vertrouwt. Een kleiner model blijft een nuttige referentie bij het evalueren van de dagelijkse latentie.