Quanta VRAM serve a un assistente documentale locale?

Un assistente locale per documenti non richiede VRAM dedicata quando la generazione viene eseguita da remoto o su un server di inferenza separato. Per l'inferenza sulla stessa macchina, 8 GB rappresentano una classe di partenza pratica per i modelli quantizzati di piccole dimensioni, mentre modelli più grandi, contesti più lunghi e l'esecuzione simultanea possono spingere il requisito ben oltre 16–24 GB. Definisci le dimensioni esatte del modello e del contesto operativo prima dell'acquisto, perché l'applicazione RAG in sé non determina il requisito di VRAM.

Decidi se l'assistente ha davvero bisogno di una GPU locale

Un assistente per documenti ha almeno due livelli: l'applicazione che archivia i file, suddivide il testo in segmenti, cerca o recupera i passaggi e presenta le risposte; e il backend del modello che esegue la generazione. Questi livelli non devono necessariamente funzionare sullo stesso hardware. Un server compatto può ospitare la libreria privata di documenti e lo stack di recupero, inviando le richieste al modello a un altro computer locale dotato di GPU o a un provider remoto.

La documentazione self-hosted di AnythingLLM rende esplicita questa separazione, consentendo all'applicazione di connettersi a servizi di modelli ed embedding esterni. I suoi requisiti self-hosted sono quindi molto inferiori rispetto all'hardware necessario per eseguire un LLM sulla stessa macchina.

Se il requisito è “i documenti devono restare sul mio server” e non “ogni token del modello deve essere generato su questo server”, acquistare un sistema con zero VRAM dedicata può essere una scelta valida. Devi comunque verificare quali dati testuali lasciano la macchina, dove vengono prodotti gli embedding, come il modello remoto gestisce le richieste e se il confine di privacy è adatto al caso d'uso.

La prima decisione d'acquisto è architetturale: l'inferenza remota o separata richiede di dimensionare CPU, RAM e spazio di archiviazione per il recupero; l'inferenza sulla stessa macchina rende la VRAM un vincolo primario nella scelta del modello.

Dimensiona i pesi del modello prima di aggiungere l'overhead RAG

La pianificazione della VRAM inizia dal modello esatto e dalla precisione. I pesi a piena precisione sono molto più grandi delle varianti a 8 o 4 bit, motivo per cui due utenti che dicono “eseguo un modello da 7B” possono avere requisiti di memoria molto diversi. La quantizzazione può consentire a un modello più piccolo e utile di funzionare su hardware comune, ma può anche modificare il comportamento dell'output e dovrebbe essere valutata con il compito documentale.

Hugging Face documenta che la quantizzazione riduce i costi di memoria e calcolo rappresentando pesi e attivazioni con tipi di dati a precisione inferiore e supportando i comuni percorsi a 8 e 4 bit. Questo rende la precisione una variabile d'acquisto, non semplicemente un'opzione software da attivare dopo aver scelto l'hardware.

Come regola approssimativa per la pianificazione attuale, i modelli a 4 bit della classe 7–8B spesso rientrano nell'intervallo 6–8 GB, quelli della classe 13–14B richiedono comunemente circa 10–12 GB, mentre quelli della classe 27–32B spesso necessitano di circa 20 GB abbondanti prima di aggiungere margine per il contesto. La guida al dimensionamento della VRAM di Spheron per il 2026 fornisce cifre simili per la pianificazione INT4 e aggiunge esplicitamente l'overhead di esecuzione oltre alla stima dei pesi.

Non acquistare una scheda dimensionata esattamente sulla dimensione del file del modello scaricato. Lascia spazio per il runtime e per lo stato del contesto, quindi verifica il modello effettivo nel motore di inferenza previsto. Un modello che si carica con un prompt di test minimo può comunque fallire o trasferire parte del carico altrove quando l'assistente riceve un contesto recuperato molto lungo.

La lunghezza del contesto può cambiare la fascia di VRAM dopo che il modello è entrato

Un assistente per documenti spesso necessita di più contesto rispetto a un chatbot occasionale, perché passaggi recuperati, citazioni, istruzioni di sistema, cronologia della conversazione e domande dell'utente vengono assemblati in un'unica richiesta. I pesi del modello possono rimanere invariati, mentre la cache key-value e gli altri stati della richiesta crescono con la lunghezza del contesto.

La documentazione di Ollama sul contesto rende visibile questo compromesso: la lunghezza predefinita del contesto aumenta con la VRAM disponibile, da 4K sotto i 24 GiB a 32K tra 24 e 48 GiB, fino a valori molto più elevati con 48 GiB o più. I valori predefiniti esatti dipendono dal runtime, ma la lezione per l'acquisto è che il lavoro documentale con contesti lunghi consuma memoria oltre ai pesi del modello.

Non rispondere aumentando il contesto indiscriminatamente. Il recupero dovrebbe selezionare il minor numero possibile di passaggi utili a rispondere alla domanda, mentre il chunking o il reranking dovrebbero eliminare il testo irrilevante prima della generazione. Un assistente per documenti che deve inserire ogni documento in un unico prompt sta usando la VRAM per compensare una progettazione debole del recupero.

Passa alla fascia di VRAM successiva quando il modello testato è sufficientemente accurato, ma i prompt documentali reali causano trasferimenti fuori dalla GPU, errori di memoria insufficiente o una latenza inaccettabile alla lunghezza del contesto di cui hai realmente bisogno. Se la qualità del recupero è scarsa prima che il contesto raggiunga il modello, correggi prima l'indice e il ranking.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Prevedi budget separati per embedding, reranking, OCR e attività simultanee

L'LLM locale non è l'unico componente che può utilizzare la memoria della GPU. Alcuni assistenti per documenti accelerano anche embedding, reranker, OCR, trascrizione vocale o modelli di visione sulla stessa GPU. L'esecuzione simultanea di questi modelli può ridurre la VRAM disponibile per il generatore, anche se ogni componente entra in memoria quando viene testato singolarmente.

L'articolo di ZimaSpace sul calcolo dell'impronta di memoria complessiva del modello spiega perché i buffer di esecuzione e lo stato delle richieste devono essere considerati insieme alla dimensione del checkpoint. Per un assistente per documenti, il contesto recuperato e i servizi paralleli aggiungono un ulteriore livello di pressione sulla memoria condivisa.

Anche l'esecuzione simultanea cambia la risposta. Due utenti attivi possono richiedere stati separati della cache KV, pur condividendo un unico modello residente. Un server orientato ai batch può migliorare l'utilizzo dell'acceleratore, ma non fa sparire la memoria necessaria per ogni richiesta. Misura la query documentale normale più lunga con il numero previsto di utenti simultanei.

Se il generatore è l'unico carico di lavoro sulla GPU, puoi dimensionare più vicino al suo set di lavoro testato. Se OCR, embedding, reranking e generazione devono sovrapporsi, acquista più VRAM, serializza le fasi pesanti oppure distribuisci i servizi tra risorse CPU e GPU. La scelta più economica è quella che mantiene la latenza richiesta senza pagare per un'accelerazione inutilizzata.

Usa le fasce di VRAM per restringere la scelta dei modelli, poi verifica la qualità

Una rosa di modelli utile può essere organizzata in base a ciò che l'assistente per documenti deve svolgere, anziché scegliere il modello più grande che entra. Con circa 6–8 GB di VRAM, inizia con modelli quantizzati a 4 bit della classe 7–8B e un recupero limitato. Con circa 12–16 GB, ottieni spazio per modelli più grandi, maggiore precisione o più contesto. Con circa 24 GB, molti modelli quantizzati della classe 27–32B diventano pratici con un margine operativo maggiore. Circa 40–48 GB o più rappresentano la fascia in cui i modelli a 4 bit della scala 70B iniziano a diventare realistici senza un trasferimento intenso fuori dalla GPU.

La guida di SitePoint del 2026 sugli LLM locali osserva che un modello 7B Q4_K_M può funzionare comodamente con circa 6 GB di VRAM. Altre guide attuali sul dimensionamento collocano i modelli quantizzati 14B e 32B più in alto, rafforzando la regola secondo cui la fascia dipende dal checkpoint esatto, non da un generico marchio “PC per l'IA”.

Crea un set di valutazione basato sui tuoi documenti prima di acquistare la fascia successiva. Includi domande che richiedano estrazione precisa, sintesi di più passaggi, rifiuto quando la fonte non contiene la risposta, tabelle o testo strutturato se pertinenti, e il contesto più lungo che prevedi di utilizzare. Confronta qualità delle risposte, comportamento delle citazioni, latenza al primo token, velocità di generazione e picco di VRAM.

Acquista più VRAM quando il modello più piccolo fallisce perché le sue capacità o la capacità di contesto sono realmente insufficienti. Non effettuare l'upgrade solo perché esiste un checkpoint più grande. Il recupero può rendere un modello più piccolo e veloce più utile per una base di conoscenza privata circoscritta rispetto a un modello più lento con un grounding debole.

Mantieni separato l'host di archiviazione e recupero dalla decisione sulla VRAM

Un assistente per documenti necessita anche di spazio persistente per i file originali, il testo estratto, gli indici, i database dell'applicazione, i log e i backup. Queste risorse consumano generalmente RAM di sistema e capacità del disco, non VRAM. Riunire tutte le risorse in un unico numero di “memoria IA” porta a decisioni hardware sbagliate.

La panoramica di ZimaSpace su un assistente IA privato su NAS descrive il ruolo dei file locali in un'architettura incentrata sul recupero. Questa architettura consente al sistema di archiviazione di rimanere stabile anche se l'hardware di inferenza viene aggiornato in seguito.

ZimaBoard 2 1664 è adatto quando il compito del server compatto è archiviare documenti, indicizzarli, eseguire applicazioni e orchestrare i servizi, mentre l'LLM funziona da remoto o su un computer separato dotato di GPU. La grafica Intel integrata non deve essere considerata VRAM dedicata per gli LLM.

Scegli l'host di archiviazione in base al volume dei documenti, ai backup, alla memoria necessaria per le applicazioni e ai requisiti di rete. Scegli l'acceleratore in base al modello esatto, alla quantizzazione, al contesto e alle attività simultanee. Mantenere separate queste decisioni consente di aggiornare la GPU senza ricostruire l'archivio documentale principale.

Verifica qualsiasi configurazione con GPU sulla stessa macchina prima dell'acquisto

Se vuoi archiviazione, recupero e generazione locale nello stesso involucro, il controllo finale prima dell'acquisto riguarda la memoria esatta della GPU disponibile per il runtime. Nomi di prodotto come “IA”, “Creator” o “RTX” non indicano se il modello locale scelto entrerà in memoria. È necessario verificare VRAM, supporto dei driver, accesso dai container, alimentazione, raffreddamento ed espansione fisica.

L'attuale ZimaCube 2 Creator Pack è l'opzione Zima da valutare quando si desiderano archiviazione multi-bay e una GPU NVIDIA dedicata nello stesso sistema. La pagina prodotto attuale identifica la famiglia della GPU, ma non pubblica un valore di VRAM nel testo principale delle specifiche; quindi non associarla a una fascia da 8, 16, 24 o 48 GB finché la memoria esatta della GPU installata non sarà confermata.

Prima del pagamento, esegui o richiedi, quando possibile, un test con un modello rappresentativo. Registra il picco di VRAM con la quantizzazione e il contesto normali, quindi ripeti il test con gli embedding, il reranker, l'OCR o gli altri servizi GPU dell'assistente attivi. Verifica che il runtime utilizzi effettivamente la GPU prevista invece di trasferire silenziosamente i livelli nella memoria di sistema.

La regola finale è acquistare la VRAM in base al set di lavoro convalidato, non alla categoria pubblicitaria. Usa zero VRAM dedicata quando l'inferenza può essere eseguita altrove; parti da circa 6–8 GB per i piccoli modelli locali quantizzati; passa a 12–16 GB per modelli più grandi o un margine maggiore; e valuta 24 GB o più solo quando il flusso documentale testato dimostra che le dimensioni del modello, il contesto o le attività simultanee lo richiedono.

Domande frequenti

RAG riduce la quantità di VRAM necessaria?

RAG può consentire a un modello più piccolo di rispondere sulla base delle informazioni recuperate invece di affidarsi alle conoscenze interne di un modello più grande, riducendo potenzialmente la fascia di modello necessaria. I passaggi recuperati consumano comunque memoria del contesto, quindi un recupero inefficiente che invia troppo testo può aumentare la pressione sulla VRAM.

Gli embedding richiedono la stessa VRAM del modello di chat?

No. I modelli di embedding hanno un proprio impatto su CPU, RAM o GPU e possono essere eseguiti sulla CPU o tramite un servizio separato. Se embedding e generazione condividono una GPU, misura il loro picco combinato invece di sommare sulla carta le dimensioni dei file dei modelli.