DGX Spark vs Strix Halo vs Gorgon Halo: quale hardware scegliere per l’IA locale?

DGX Spark vs Strix Halo vs Gorgon Halo: quale piattaforma per i tuoi scenari LLM locali?

Un sistema con 192 GB di memoria unificata non è automaticamente più veloce di uno con 128 GB. Una scheda tecnica da 1 PFLOP non dice a che velocità un large language model (LLM) genera token. Un AI benchmark senza risultati separati di prefill (elaborazione del prompt) e decode (generazione dei token) può dare un quadro fuorviante delle prestazioni reali.

Queste differenze contano quando confronti la piattaforma NVIDIA, l’opzione AMD con 128 GB e le configurazioni più recenti fino a 192 GB per l’IA locale / i LLM locali.

Tutte e tre possono gestire carichi di lavoro che un tempo richiedevano grandi tower con GPU discreta: inferenza privata, agenti di codice, RAG, contesto lungo e pipeline multi-modello. Lo fanno, però, con approcci diversi.

Per confrontarle in modo efficace, conviene partire da cinque domande:

1. Il modello e i dati necessari all’esecuzione stanno in memoria?
2. Quanto velocemente il sistema elabora un prompt lungo (prefill)?
3. Quanto velocemente genera token (decode)?
4. Il tuo software dipende da CUDA?
5. Cosa succede quando il carico di lavoro supera i 128 GB?

La distinzione più importante resta comunque chiara.

La domanda centrale di questa guida è: come scegliere tra il dispositivo NVIDIA con 128 GB, l’opzione Strix AMD con 128 GB e i sistemi desktop di classe Gorgon con 192 GB per l’inferenza LLM locale — soprattutto il bivio tra le capacità di 128 GB e 192 GB — senza trattare uno screenshot isolato di token/s come una classifica.

Confronto rápido

Questa tabella serve a orientarsi tra le piattaforme. Non implica che una colonna sia ovunque più veloce: dipende dallo scenario.

AMD indica Gorgon Halo come precedente nome in codice sulla scheda del Ryzen AI Max+ PRO 495 (fino a 192 GB, Radeon 8065S). In questa guida «Gorgon Halo» indica dunque quel precedente nome in codice e serve da scorciatoia per gli acquirenti della classe desktop Ryzen AI Max+ PRO 495 con 192 GB — non un’architettura consumer distinta disponibile sul mercato.

Pianificazione rapida: Cosa cambia davvero tra 128 GB e 192 GB

Se 128 GB bastano già con margine, tratta 192 GB come una riserva di capacità.

Mappa dei colli di bottiglia hardware per LLM

Questa mappa è il vero punto di partenza per scegliere tra queste piattaforme nel 2026 — non uno screenshot isolato di token da usare come classifica.

Perché confrontare proprio queste tre piattaforme

Dal PC «AI» alla workstation locale

Il marketing «AI PC» si appoggia ancora ai TOPS di NPU. Chi sceglie sul serio hardware per LLM locali guarda soprattutto la memoria unificata, i percorsi di inferenza GPU/APU e la capacità del sistema di ospitare agenti privati, RAG e lavoro a contesto lungo su desktop — ecco perché DGX Spark, AMD Strix Halo (128 GB) e le configurazioni fino a 192 GB compaiono insieme quando si cerca un mini PC IA / una workstation compatta.

Perché la capacità di memoria è diventata una specifica chiave

Quando si è iniziato a eseguire in locale pesi di classe 70B e 120B+, 128 GB e 192 GB hanno smesso di sembrare un lusso e sono diventati «ma almeno ci sta?». La memoria unificata spiega perché queste tre opzioni desktop condividono l’attenzione: promettono un unico pool abbastanza grande per l’hardware LLM locale che un tempo richiedeva una tower multi-GPU.

(I dettagli dei chip da 128 GB vs 192 GB li approfondiamo più avanti nella FAQ e nella guida Ryzen AI Max+ 395 vs PRO 495.) Sulla scheda AMD, il Ryzen AI Max+ PRO 495 elenca il precedente nome in codice Gorgon Halo, la Radeon 8065S (40 CU) e fino a 192 GB di LPDDR5X-8533 — è il silicio da 192 GB a cui questa guida fa riferimento quando tratta gli SKU desktop.)

Cos’è AMD Strix Halo?

Piattaforma e Ryzen AI Max

Strix Halo è la piattaforma APU di fascia alta di AMD che unisce una CPU Zen 5 solida, una iGPU Radeon ampia e un bus largo di memoria unificata LPDDR5X in sistemi compatti. Nelle ricerche si digita spesso AMD Strix Halo; il Ryzen AI Max+ 395 (spesso cercato anche come Ryzen AI Max 395) è uno dei chip più noti che implementano questa piattaforma negli SKU mini PC Strix Halo e workstation (incluso il profilo Ryzen AI Max+ 395 128 GB).

Se confronti un PC Strix Halo con un dispositivo NVIDIA, parti dalla capacità di memoria, dal percorso software (ROCm/llama.cpp) e dal formato — non solo dal nome del chip.

Perché Strix interessa l’AI locale

La piattaforma conta per l’AI locale perché combina:

• Una memoria unificata ampia (spesso fino a 128 GB sulle configurazioni di punta tipo Strix Halo 128 GB)
• Vero calcolo GPU per l’inferenza LLM (non solo marketing NPU) — con GPU RDNA 3.5 e NPU XDNA 2 sul silicio di punta
• Chassis compatti — dai design mini PC AMD ai sistemi desktop più densi
• Abbastanza margine per il software x86 di tutti i giorni oltre al modello

Non è «una 4090 discreta in un case minuscolo». È un approccio APU AMD prima di tutto: ospitare pesi grandi in un’unica memoria unificata, accettare che il decode sia spesso limitato dalla banda e ottimizzare il percorso software (ROCm, Vulkan, llama.cpp, Ollama).

Cos’è AMD Gorgon Halo?

È il punto che molti confronti Spark vs Strix trascurano ancora.

Capacità: AMD 128 GB vs classe 192 GB

La scheda prodotto AMD elenca Gorgon Halo come precedente nome in codice del Ryzen AI Max+ PRO 495 (Radeon 8065S, 40 CU, fino a 192 GB LPDDR5X-8533). In questa guida «Gorgon Halo» indica dunque quel precedente nome in codice e serve da scorciatoia per gli acquirenti della classe desktop con 192 GB — non un’architettura consumer distinta disponibile sul mercato.

Per chi acquista, la distinzione utile è più semplice:

• Opzione AMD di classe 128 GB → spesso sufficiente per molti stack LLM locali tenuti in memoria
• Configurazione 192 GB → più margine quando pesi, cache KV e stack multi-servizio non entrano più

Rispetto a Strix, quindi, è soprattutto una questione di capacità (con clock e riserva di memoria dipendenti dalla configurazione), pensata per i carichi di lavoro che già urtavano contro il limite dei 128 GB — RAG multi-servizio, contesto più lungo, file di pesi MoE più pesanti, quantizzazioni più alte.

Rispetto al dispositivo NVIDIA con 128 GB, la domanda cambia ancora: il dispositivo NVIDIA resta centrato su CUDA e su un pool coerente di 128 GB; i sistemi AMD a più memoria rispondono a «e se 128 GB di memoria effettivamente disponibile sono il vero limite?».

Perché una capacità di memoria più alta conta per i LLM locali

La capacità conta di più con pesi più grandi, cache KV più lunghe, stack multi-servizio o quantizzazioni meno aggressive.

Più memoria è sempre meglio?

No. La capacità fissa: cosa puoi caricare; le prestazioni dipendono ancora dalla banda, dal calcolo e dal software.

Cos’è NVIDIA DGX Spark?

Le specifiche che contano per l’IA

Dalla pagina prodotto NVIDIA, le specifiche del DGX Spark che contano per l’IA locale / l’inferenza LLM (e per leggere con cautela le affermazioni di prestazioni) sono, in sintesi:

• Superchip GB10 Grace Blackwell (NVIDIA GB10)
• 128 GB di memoria unificata coerente @ 273 GB/s dichiarati
• Prestazioni Tensor (marketing) classe FP4 (fino a ~1 PFLOP FP4 sparse — teorico)
• Stack software CUDA, DGX OS, playbook / strumenti orientati a NIM
• Storage locale veloce (configurazione Founders con NVMe di grande capacità)
• Rete ConnectX-7 per scenari multi-dispositivo

Il listino Founders Edition è attualmente a 4.699 $ (solo contesto di prezzo — questa guida non è un confronto tariffario).

Perché CUDA fa parte della storia Spark

Per molti acquirenti la piattaforma NVIDIA non è «un altro sistema con 128 GB». È l’accesso all’ecosistema NVIDIA CUDA: framework, kernel, ricette di fine-tune e stack di serving/inferenza che già presuppongono NVIDIA. Quello strato software fa parte delle prestazioni LLM misurate, non è un accessorio.

In pratica, NVIDIA DGX Spark punta a chi vuole un sistema coerente con Blackwell con strumenti DGX, non solo un altro dispositivo con 128 GB.

Differenze hardware chiave (dettaglio)

Il confronto rapido sopra è sufficiente per molti acquirenti. Questa tabella aggiunge il livello di specifiche più dettagliato.

Le specifiche che contano davvero per i LLM

Per l’inferenza LLM tre numeri non sono intercambiabili:

1. Capacità di memoria — pesi + KV + runtime stanno?
2. Banda di memoria — a che velocità il decode può leggere i pesi?
3. Potenza di calcolo + software — quanto è veloce il prefill, e quali kernel esistono?

TOPS e PFLOPS da soli non rispondono a queste domande.

Capacità di memoria vs banda per i LLM locali

Perché 128 GB può contare più dei FLOPS GPU

Se il modello non entra in memoria, i FLOPS non servono. Ecco perché le discussioni su hardware LLM locale si concentrano su Strix Halo 128 GB e sul pool da 128 GB di Spark — e perché Gorgon 192 GB rappresenta un’opzione concreta per chi è limitato dalla capacità di memoria.

Perché più memoria non accelera automaticamente l’inferenza

Una volta che il carico di memoria ci sta, aggiungere RAM raramente aumenta da sola i token/s. Sulle APU a memoria unificata il decode è spesso limitato dalla banda. La capacità in più riduce soprattutto lo swapping, lo scaricamento e le quantizzazioni più aggressive rese necessarie dalla mancanza di memoria.

Cosa cambia la banda di memoria

La banda si vede soprattutto in:

• Decode (generazione token per token)
• Streaming dei pesi per modelli densi grandi
• Prestazioni LLM limitate dalla memoria quando la GPU aspetta il bus

I 273 GB/s dichiarati di Spark e il picco di 256 GB/s di Strix aiutano a capire perché, in alcuni test pubblici a confronto diretto, i gap di generazione restano modesti — anche quando i gap di prefill sono ampi. Le configurazioni da 192 GB del Max+ PRO 495 raggiungono anch’esse un picco teorico di 273 GB/s via 256 bit × LPDDR5X-8533 (il throughput sostenuto OEM può differire).

Cosa succede quando allunghi il contesto?

Un contesto più lungo fa crescere la cache KV. Gli agenti di codice e il RAG che reinviano prompt enormi gravano sul prefill e sull’occupazione della cache. È una mappa di colli di bottiglia diversa rispetto ai turni brevi di un chatbot.

Perché la dimensione del modello non basta più per scegliere l’hardware di IA locale

«Quanta memoria serve per un modello da 70B?» è la domanda sbagliata se presa da sola.

Un budget di memoria realistico per i LLM locali include:

1. Pesi del modello (dipende dalla quantizzazione)
2. Cache KV (dipende dalla lunghezza di contesto)
3. Overhead di runtime (framework, grafi CUDA/ROCm, OS)
4. Contesto/strumenti (buffer agente, buffer di retrieval)
5. Più modelli/servizi (embedder, reranker, secondo LLM)

Quindi la stessa etichetta «70B» può stare comoda su 128 GB in uno stack e risultare stretta in un altro. La pianificazione della capacità è una somma, non un semplice conteggio di parametri.

(Vedi la tabella di pianificazione rapida sopra per le fasce 64 / 128 / 192 GB.)

Inferenza LLM per classe di modello

LLM piccoli e medi

Per chat 7B–32B con un large language model di medie dimensioni, calcolo, maturità software, costo e consumo contano spesso più della corsa ai 192 GB. Un mini PC IA sull’opzione AMD da 128 GB può essere la scelta sensata se i tuoi modelli ci stanno già.

Modelli di classe 70B

Qui capacità di memoria, quantizzazione e banda pesano insieme. Le due piattaforme da 128 GB restano sullo stesso terreno; a fare la differenza sono CUDA rispetto ai percorsi ROCm e il modo in cui il carico di lavoro si divide tra prefill e decode.

Modelli 120B+

La capacità diventa il primo vincolo. Quantizzazione e politica di contesto decidono se il sistema è usabile. La configurazione da 192 GB punta a questa fascia, non a una «chat 14B più veloce».

Grandi modelli MoE

Parametri totali ≠ parametri attivi. Un MoE 200B+ può sembrare imponente su una slide pur attivando solo una frazione di expert per token. Serve comunque capacità per tenere i pesi in memoria, ma il costo di decodifica segue il lavoro attivo più il routing. La qualità del runtime conta quanto la cifra di marketing — ecco perché il MoE merita spazio in ogni guida seria sull’inferenza LLM su desktop.

Perché i modelli da 200B+ parametri non sono sempre pesanti come sembrano

Nei modelli densi la maggior parte dei parametri resta attiva a ogni token. Nei MoE si attivano solo alcuni expert, quindi il calcolo per token può sembrare più leggero del conteggio dei parametri.

L’attivazione sparse riduce il calcolo per token, ma non elimina il bisogno di tenere i pesi in memoria. Ecco perché un grande MoE può ancora richiedere capacità fino a 192 GB anche quando il decode resta gestibile — e perché parametri totali, occupazione dei pesi, parametri attivi, cache KV e token/s misurati vanno tenuti distinti in ogni lettura di un LLM benchmark.

Perché i benchmark LLM possono fuorviare

Prefill vs decode

Il prefill elabora il prompt in ingresso (spesso pesante di calcolo e parallelo).

Il decode emette i token uno per uno (spesso dipendente dalla banda / latenza).

Questa distinzione spiega anche perché i numeri di prestazioni del DGX Spark possono sembrare irregolari da un test all’altro: il prefill può aprire un grande gap in una configurazione, mentre il decode resta vicino. Un sistema può sembrare veloce su un chatbot breve e lento su «analizza questo repo da 20k token».

I token al secondo non dicono tutto

I risultati cambiano con la lunghezza del prompt, il contesto, il batch size, la quantizzazione, il backend, il modello e il runtime. Un solo numero etichettato «benchmark DGX Spark» o «LLM benchmark» senza queste indicazioni è incompleto. Anche un AI benchmark va letto con le stesse cautele.

Perché due benchmark mostrano risultati diversi

I test pubblici a confronto diretto sono utili come indicazioni di tendenza — non come una classifica multi-piattaforma.

Quellen: HardwareCorner, IntuitionLabs, Memeburn.

In quel confronto pubblicato, Spark ha mostrato un vantaggio sostanziale di prefill, mentre i risultati di decode erano molto più vicini: utile per flussi con prompt pesanti, non un vincitore universale per ogni compito LLM locale.

CUDA vs ROCm: la differenza software

CUDA su Spark

Nei dibattiti DGX Spark vs AMD, CUDA è spesso uno dei principali fattori di scelta: supporto ai framework, percorsi TensorRT-LLM/vLLM, ricette di fine-tune e meno tempo a inseguire fork — anche quando esistono sistemi AMD con 128 GB. Sul percorso AMD, l’iGPU Radeon e ROCm/Vulkan portano gran parte dell’inferenza.

ROCm e l’hardware AMD

Sui sistemi di Gorgon, l’inferenza AI e LLM reale passa spesso da AMD ROCm, Vulkan, Llama.cpp, Ollama, LM Studio e simili. Lo stack funziona; il livello di intervento richiesto all’operatore può essere più alto.

Perché il software può cambiare le prestazioni hardware

Stesso silicio, backend diverso → prefill/decode diversi. Le prestazioni di inferenza dipendono dallo stack, non solo dalla scheda tecnica del chip.

         Applicazione IA
               ↓
     Modello / Quantizzazione
               ↓
      Runtime di inferenza
     ↙                  ↘
  CUDA                  ROCm/Vulkan
     ↘                  ↙
        GPU / APU
             ↓
     Architettura memoria
             ↓
      Raffreddamento / Alimentazione

Capacità hardware vs complessità di avvio e gestione

Le specifiche grezze sono solo metà della scelta. L’altra metà è quanto è impegnativo mettere in servizio un modello in modo affidabile:

• Percorso NVIDIA: strumenti nativi CUDA, più ricette «pronte all’uso» per gli stack comuni (vLLM / TensorRT-LLM / playbook). Spesso si paga un premio per una configurazione e una gestione più semplici — non solo per uno screenshot di token.
• Percorso AMD: molte installazioni desktop reali passano da Llama.cpp, Vulkan, Ollama, LM Studio e ROCm dove supportato. Funziona; il livello di intervento richiesto all’operatore varia di più a seconda del modello e del runtime.

Quindi «Spark vale la pena rispetto a un sistema AMD con 128 GB?» si traduce spesso in: ecosistema CUDA + meno complessità + il gap di prefill pubblicato in alcuni test a confronto diretto — contro prezzo, comodità Windows/x86 e un decode che può risultare vicino.

Esperimenti di scenario (da domande reali degli utenti)

Invece di copiare token/s da Reddit, trasforma i dibattiti LocalLLM ricorrenti in verifiche concrete:

Scenario 1 — «Voglio eseguire un modello da 70B in locale.» Controlla capacità → quantizzazione → banda → runtime.

Scenario 2 — «Voglio un agente di codice locale.» Controlla contesto + cache KV → fluidità del decode → strumenti per agenti (CUDA può contare).

Scenario 3 — «Voglio eseguire modelli da 120B+.» Controlla prima la capacità → quantizzazione → se il sistema con più memoria aiuta più del percorso prefill di NVIDIA per i tuoi prompt lunghi.

Scenario 4 — «Voglio tenere più modelli in memoria.» Controlla la memoria libera dopo OS/runtime → concorrenza → gestione termica sui run lunghi.

Mini PC vs workstation IA compatta per LLM locali

Quando scegli un mini PC basato su Strix per l’IA locale, guarda oltre il nome del processore. Per formato e montaggio, vedi anche la nostra guida per montare una workstation IA locale. Capacità di memoria, raffreddamento, espansione dello storage e potenza sostenuta contano più dell’etichetta da brochure per i carichi di inferenza prolungati.

Nessun formato vince in assoluto: va adattato al ciclo d’uso. E per l’inferenza LLM su desktop, TOPS NPU ≠ prestazioni LLM: calcolo GPU/APU, memoria unificata e runtime dominano.

Dove si colloca ACEMAGIC?

Quale configurazione ACEMAGIC scegliere in base al carico di lavoro?

Hardware IA locale vs GPU cloud

Quando ha senso l’hardware locale

Privacy, inferenza ripetuta, lavoro offline, agenti quotidiani prevedibili, loop di sviluppo che lanci ogni ora: qui l’hardware locale ha senso.

Quando le GPU cloud hanno più senso

Job enormi occasionali, training a raffica, modelli che ancora non entrano in memoria, esperimenti distribuiti: qui le GPU cloud spesso hanno più senso.

Come pensare al costo totale

Calcola il costo delle ore che esegui davvero, non un’affermazione virale del tipo «si ripaga in N mesi» senza i tuoi log di token. Il locale conviene per privacy e costo marginale; il cloud per l’elasticità.

Come scegliere l’hardware LLM locale nel 2026

1. Parti dalla classe di dimensione del modello — 7B / 14B / 32B / 70B / 120B+ — poi aggiungi subito contesto e bisogni multi-servizio.
2. Controlla la capacità di memoria — il carico di memoria è completo?
3. Controlla la banda di memoria + calcolo — il decode sarà accettabile?
4. Controlla la lunghezza di contesto — cache KV e percorso prefill.
5. Controlla il software — CUDA è obbligatorio o bastano ROCm/llama.cpp?
6. Controlla la gestione termica e il formato — ciclo d’uso del mini PC vs della workstation.

Matrice di decisione hardware IA locale

I TOPS di NPU restano utili per il marketing AI PC, ma questa matrice privilegia memoria, banda e stack software. Non esiste una tabella con un unico vincitore. Sugli stack di classe 128 GB, scegli in base al software, al comportamento prefill/decode e alla progettazione del sistema. Se superi il limite di capacità, 192 GB diventa un altro tipo di vantaggio — non un numero di benchmark più alto.

Riepilogo

Scegliere tra queste tre opzioni desktop significa adattarsi al tuo carico di lavoro, non cercare un unico vincitore:

1. La capacità di memoria determina quali modelli puoi caricare; le prestazioni di inferenza dipendono anche dalla banda, dal calcolo e dallo stack software. 192 GB aiutano quando pesi, cache KV o stack multi-servizio non entrano nei 128 GB — non aumentano automaticamente i token/s.
2. Prefill ≠ decode. Nel test a confronto diretto pubblicato su GPT-OSS 120B MXFP4 con Llama.cpp, il prefill di Spark era molto avanti mentre il decode restava vicino — da leggere come indicativo, non come classifica universale.
3. Classe 128 GB: percorso CUDA / meno complessità sul percorso NVIDIA contro l’approccio desktop x86 basato su Strix Halo di AMD (es. M1A PRO+ o F9A-395), in base allo stack software e al formato. Il Ryzen AI Max 395 (e la variante con «+», Ryzen AI Max+ 395) è lo stesso silicio di riferimento Strix che incontri nei confronti; in pratica, le ricerche «Ryzen AI Max 395» e «Ryzen AI Max+ 395» puntano allo stesso chip di piattaforma.
4. Classe 192 GB: quando il carico di memoria è il limite, l’F9A-PRO495 corrisponde al Max+ PRO 495 / 192 GB LPDDR5X-8533 (Radeon 8065S). «Gorgon» resta qui il precedente nome in codice / scorciatoia per gli acquirenti di quel livello. A volte nelle ricerche compare Ryzen AI Max PRO 495 senza il «+»; il nome del prodotto conserva il «+».
5. Scegli in base al collo di bottiglia che hai davvero: capacità di memoria prima, poi banda/calcolo, poi la complessità di CUDA vs ROCm/llama.cpp, poi gestione termica ed espansione.

FAQ

Il dispositivo NVIDIA con 128 GB vale la pena rispetto all’opzione AMD con 128 GB per l’inferenza LLM locale?

Dipende da cosa stai acquistando. Nel test a confronto diretto GPT-OSS 120B MXFP4 pubblicato sopra, il prefill di Spark era molto avanti mentre il decode era vicino. Il sovrapprezzo paga più spesso l’ecosistema CUDA, una messa in opera più semplice e gli strumenti orientati a DGX — non un’affermazione universale di generazione 5× più veloce. L’opzione AMD con 128 GB resta competitiva per molte configurazioni di mini PC IA Windows/x86 pesanti di decodifica.

Per il salto di chip da 128 GB a 192 GB, vedi anche il nostro confronto Ryzen AI Max+ 395 vs PRO 495

Di quanta RAM ho bisogno per eseguire un LLM 70B in locale?

Pianifica pesi + cache KV + runtime + margine, non solo l’etichetta dei parametri. Molte configurazioni della classe 70B stanno comode in 128 GB di memoria unificata con le quantizzazioni comuni; contesto lungo, quantizzazioni più alte o stack multi-servizio alzano il budget. Usa la tabella di pianificazione sopra — è un orientamento, non un limite rigido.

Posso eseguire modelli 120B su 128 GB di memoria unificata?

Sì, con quantizzazione aggressiva e lunghezza di contesto limitata, ma perdi margine per cache KV, modelli di embedding e reranker. È lì che l’hardware di classe Gorgon con 192 GB aggiunge valore. La capacità resta il primo filtro; le prestazioni usabili, il secondo.

L’F9A-PRO495 «supporta» 120B Q4 o fino a 300B MoE?

Queste cifre sono obiettivi di capacità di prodotto (quantizzazione + contesto + runtime), non una promessa di token/s. Un MoE 300B non equivale a un modello denso da 300B: avere i pesi in memoria non implica generare in fretta. Esigi misure riproducibili prima di prenderle per prestazioni.

192 GB è meglio di 128 GB per i LLM locali?

192 GB offre più margine per modello e cache KV, ma non aumenta automaticamente i token/s quando il carico di lavoro è già a 128 GB. Sceglilo per gli stack limitati dalla capacità (quantizzazioni più alte, multi-modello, contesto lungo, pesi MoE più pesanti) — non come un aumento di velocità «gratis».

Quando la configurazione da 192 GB conta più di uno qualsiasi dei due sistemi da 128 GB?

Quando il carico di memoria non entra più: RAG multi-modello, file di pesi MoE più pesanti, quantizzazioni più alte o cache KV lunghe. Vedi anche la FAQ 192 GB vs 128 GB sopra.

Più memoria unificata significa token più veloci?

No. Tenere i pesi in memoria non è la stessa cosa di generare token in fretta — banda, calcolo, quantizzazione e runtime fissano sempre il ritmo.

I TOPS NPU sono un buon criterio per scegliere hardware LLM locale?

In genere no. Per l’inferenza LLM su desktop, GPU/APU + memoria + software dominano i risultati di inferenza AI più delle slide di TOPS NPU.

Mini PC o workstation desktop?

Chat e agenti leggeri stanno spesso bene in un mini PC. Modelli grandi, RAG multi-servizio e inferenza di lunga durata orientano verso una workstation — inclusa una workstation compatta tipo F9A quando ti serve memoria fino a 192 GB.

Fonti

• AMD Ryzen AI Max+ PRO 495 (precedente nome in codice Gorgon; max 192 GB; Radeon 8065S)
• AMD Ryzen AI Max+ 395 / Strix Halo (max 128 GB LPDDR5X-8000)
• NVIDIA DGX Spark specifiche prodotto
• Benchmark LLM HardwareCorner su Spark ; IntuitionLabs ; Memeburn