È davvero possibile eseguire DeepSeek V4 Flash 284B con 64 GB di RAM senza una GPU?

Un progetto della community riporta di aver eseguito DeepSeek V4 Flash 284B su una macchina Linux con 64 GB usando solo la CPU. La configurazione riportata usa llama-modchip, un checkpoint personalizzato con circa 1,71 bit per peso e una CPU desktop con un’elevata larghezza di banda della memoria. Consideralo un esperimento documentato con una build specifica, non una raccomandazione generale per dimensionare le risorse necessarie al checkpoint ufficiale.

Il risultato è utile perché permette di misurare tre aspetti che di solito vengono confusi: se il file dei pesi entra in memoria, se il processo riesce a mantenere memoria sufficiente durante la generazione e se l’output resta utile a quel livello di compressione. Il progetto è stato presentato in una discussione della community dell’8 novembre. Le misurazioni riportate di seguito provengono dal repository del manutentore di llama-modchip, non da test indipendenti.

Quale modello DeepSeek e quale runtime sono coinvolti?

Il progetto è destinato a DeepSeek V4 Flash, descritto nella sua documentazione come un modello con circa 284B parametri totali e circa 13B attivi per token. In un modello a miscela di esperti, il router seleziona gli esperti per ciascun token. Questo limita il calcolo per token, ma l’insieme completo degli esperti deve comunque essere memorizzato e reso accessibile. Consulta la scheda del modello dello sviluppatore e la panoramica dei requisiti hardware per il normale contesto di distribuzione.

L’esperimento usa una transcodifica specializzata e patch all’ecosistema ggml/llama.cpp. Anche un altro file che pubblicizza la stessa famiglia di modelli può avere un layout dei tensori o una precisione diversi. Un binario standard di llama.cpp e un GGUF convenzionale vanno considerati un percorso a parte. La guida all’aggiornamento di llama.cpp esistente illustra il percorso della versione upstream.

Come fanno 284 miliardi di parametri a entrare in 64 GB di RAM?

Con una media di 1.71 bit per peso, 284 miliardi di pesi implicano circa 61 GB di dati compressi in unità decimali. Il progetto riporta un file da 56.56 GiB e un picco di memoria residente del processo pari a 57.61 GiB nella configurazione a 256K. GiB e GB indicano unità diverse. Per capire quanto margine hai, verifica la memoria effettivamente disponibile sull'host al momento del test. Le riserve del firmware, la grafica integrata e gli altri processi possono consumare gran parte di un margine già ridotto.

La memoria residente e la dimensione del file dei pesi sono misurazioni correlate, ma nessuna delle due tiene conto di tutte le allocazioni di sistema. Durante il caricamento, il kernel può recuperare la cache del filesystem o mantenere buffer temporanei. Tieni d'occhio sia la memoria del runner sia quella disponibile nel sistema. Inoltre, un valore elevato del set residente durante un singolo test non descrive tutte le lunghezze di contesto e tutti i tipi di input.

Perché la velocità di elaborazione del prompt e quella di generazione sono diverse?

L'elaborazione del prompt gestisce un input già noto, quindi il runtime può raggruppare il lavoro su più token. La generazione è sequenziale: il token successivo dipende da quelli generati in precedenza. La generazione su CPU di un modello MoE dipende dalla velocità con cui la macchina riesce a trasferire dalla memoria i pesi degli esperti selezionati e il relativo stato. Frequenza di clock, numero di canali, temporizzazioni della memoria e assegnazione dei thread possono influire sul risultato.

Separa un breve test del prompt da un prompt lungo basato su un repository. Misura separatamente il tempo al primo token e quello della generazione successiva. Un prefisso più lungo può incidere molto sulla latenza totale, anche quando lo streaming sembra reattivo una volta avviato. Registra se il runtime ha riutilizzato uno stato memorizzato nella cache. Un prefisso già elaborato e un'esecuzione a freddo rispondono a domande diverse. La documentazione dello strumento di benchmark upstream spiega le misurazioni del prompt e della generazione.

Quanta qualità si perde con questa precisione?

I bit per peso riassumono l'archiviazione, non la qualità del modello. Ai diversi tensori può essere assegnata una precisione diversa e due conversioni di dimensioni simili possono comportarsi diversamente. Il ragionamento lungo, la sintassi esatta, gli argomenti degli strumenti e il vocabolario insolito sono aspetti da verificare con attenzione. Una risposta leggibile a una domanda dimostra che la generazione funziona. Non dimostra che la stessa build sia affidabile per un flusso di lavoro di programmazione.

Scegli un piccolo insieme di riferimento prima dei test. Includi un'attività con output in formato esatto, una funzione con un test fallito noto, una ricerca in un contesto lungo e una richiesta a cui il modello dovrebbe rispondere con cautela. Confronta i risultati con una baseline supportata di precisione superiore o più piccola, usando gli stessi prompt. Mantieni invariati gli input di test e annota gli output incompleti, le chiamate agli strumenti malformate e i timeout. Blocca le revisioni del modello e del runtime, così da poter attribuire eventuali miglioramenti successivi.

Come riprodurresti il risultato in modo responsabile?

Inizia con una macchina di test Linux isolata, ampio spazio SSD e il checkpoint e la revisione esatti indicati dal manutentore. Leggi le istruzioni per la compilazione e l'avvio rapido del progetto, esamina gli script prima di eseguirli e annota CPU, configurazione della memoria e kernel. Un prompt breve senza strumenti shell abilitati è un buon primo test. Aumenta il contesto solo dopo aver verificato che il sistema host resti reattivo.

1. Misura la memoria libera e l'attività dello swap prima del caricamento. Interrompi gli altri esperimenti che richiedono molte risorse sulla stessa macchina.
2. Annota le dimensioni esatte del file del checkpoint e il relativo hash, la versione del runner e qualsiasi impostazione speciale di transcodifica o posizionamento degli esperti.
3. Registra il picco di RSS, il tempo al primo token, i token di output al secondo e l'eventuale uso dello swap. Esegui il test due volte per distinguere il comportamento a freddo dagli effetti della cache.
4. Confronta la correttezza dell'output prima di usare il modello per un lavoro più lungo. Verifica l'esposizione dei dati e l'accesso al filesystem se in seguito colleghi un agente.

Per le attività sui repository, usa worktree Git isolati. Se l’host fornisce anche servizi di archiviazione o backup per la casa, svolgi il primo esperimento su una macchina di calcolo separata. Un processo di inferenza che occupa quasi tutta la RAM può interferire con questi servizi ben prima che il sistema esaurisca la memoria.

Quando conviene scegliere un modello più piccolo?

Scegli un checkpoint più piccolo quando ti servono prestazioni interattive costanti, aggiornamenti semplici o margine sufficiente per più sessioni. L’esperimento della community è più interessante se puoi accettare codice personalizzato, precisione inferiore e una riproduzione accurata. Un modello per l’uso quotidiano che rientra in un runtime supportato può essere più facile da mantenere e completare più attività utili all’ora. Confrontali sulla stessa attività prima di modificare una configurazione di produzione.

FAQ

È necessaria una GPU dedicata?

Il manutentore segnala un’esecuzione solo su CPU per il checkpoint specifico da 284B. Altre configurazioni nel repository includono varianti con supporto della GPU, quindi mantieni separati i profili di test.

Qualsiasi PC con 64 GB raggiungerà la velocità riportata?

La sola memoria installata non consente di fare affermazioni generali sulla velocità. La generazione su CPU dipende dalla larghezza di banda della memoria, dai kernel e dall’assegnazione dei thread, e il sistema deve disporre di RAM sufficiente.

È questa la velocità che vedrò durante una chat?

Il dato di circa 44 tok/s si riferisce all’elaborazione del prompt nella configurazione citata. Il repository riporta un intervallo separato e inferiore per la generazione autoregressiva.

Il contesto da 256K è la prima impostazione da provare?

Inizia con un valore più basso e misura. Il dato sulla memoria del manutentore si riferisce a una specifica configurazione di runner e checkpoint.

Questo sostituisce la guida hardware pubblicata?

Per una distribuzione standard, segui la guida ufficiale del modello. Considera llama-modchip una soluzione della community, con vincoli specifici di precisione, compatibilità e prestazioni.

Conclusione

Il risultato interessante è che uno specifico runtime per CPU e un checkpoint personalizzato a bassa precisione possono far rientrare un modello MoE sorprendentemente grande in un budget di memoria limitato. Riproduci esattamente la build, distingui il prefill dalla decodifica e verifica la qualità dell’output prima di farci affidamento. Un modello più piccolo resta un utile termine di confronto per valutare la latenza nell’uso quotidiano.