Skip to main content
Best Parts for a Local RAG Document-QA Workstation in 2026

Best Parts for a Local RAG Document-QA Workstation in 2026

RAG splits your budget three ways — embedding the corpus, serving the index, generating answers — and each job needs a different part to stay fast.

A 12GB RTX 3060 holds an 8B-14B generator plus an embedding model. Five parts for a private document-QA box, with index-size and prefill math for each tier.

Hardware at a Glance

Median generation throughput at 7–9B models (Llama 3.1 8B, Qwen 3 8B), Q4 quantization, from community-reported runs SpecPicks tracks. Street price is the second-lowest tracked listing within a sane band of MSRP, so no single listing sets it; prices move daily. Rows marked for comparison are not covered by this article — they are the nearest cards by VRAM, included so the throughput column has something to be read against.

GPUVRAM Llama-3-8B class, Q4Price Source
NVIDIA GeForce RTX 3060 12 GB 57.4 tok/s30 runs · 16 sources $387street smeltcore.com
NVIDIA GeForce RTX 5070for comparison 12 GB 59.1 tok/s5 runs · 5 sources $680street knightli.com
Arc B580for comparison 12 GB 40 tok/s19 runs · 12 sources $310street llama.cpp GitHub Discussions

As an Amazon Associate, SpecPicks earns from qualifying purchases. See our methodology.

Quick answer

A local RAG document-QA stack needs one GPU with at least 12 GB of VRAM, around 32 GB of system RAM and a separate SSD for the index. On an RTX 3060 12 GB, LocalScore records 51.6 tok/s generation with Llama 3.1 8B at Q4_K_M (LocalScore — RTX 3060). That model's file is only 4.92 GB (bartowski — Llama 3.1 8B GGUF), leaving room for an embedding model beside it.

Who this guide is for

You have a pile of documents that you cannot, or would rather not, paste into a hosted chatbot: contracts, internal wikis, research PDFs, support tickets, a decade of email exports. You want to ask questions of them in plain English and get answers that quote the source passage. That is retrieval-augmented generation, and in 2026 the software side of it is solved well enough — Ollama exposes an embeddings endpoint built for exactly this pipeline (Ollama — Embeddings), and llama.cpp's server ships embedding and reranking endpoints alongside chat (llama.cpp server README).

The hardware side is where builds go wrong, because RAG splits your budget across three different jobs with three different bottlenecks:

  1. Embedding the corpus. A one-time (or occasional) batch pass that turns every chunk of every document into a vector. It is throughput-bound and it loves a GPU.
  2. Storing and serving the index. Vectors plus an HNSW or IVF graph, queried on every question. This is a RAM and storage-latency job, and it runs 24/7.
  3. Generating answers. An interactive job where the retrieved chunks are stuffed into the prompt. Prefill speed decides how long you wait for the first word; VRAM decides which model you can run at all.

A build tuned for only one of those jobs — a big GPU on a starved host, or a fast CPU with no VRAM — leaves you waiting on the other two. The five picks below are chosen so each job has a part that covers it, and the Best Overall pick is the 12 GB card that makes the generation job cheap: the ZOTAC RTX 3060 Twin Edge OC.

Step 0: size your corpus before you size your build

Do this arithmetic before you open a single product page. It tells you whether you need a GPU for the embedding pass, how much disk the index takes, and which tier of build you are in.

Documents → chunks. Most embedding models cap their input. BGE-large-en-v1.5 takes at most 512 tokens per input (BAAI — bge-large-en-v1.5), and E5-large-v2's model card is explicit that "long texts will be truncated to at most 512 tokens" (intfloat — e5-large-v2). So your chunk size is set by the embedder, not by taste. As a worked example, 2,000 PDFs averaging 30 pages at roughly two 512-token chunks per page is about 120,000 chunks.

Chunks → index footprint. pgvector documents the cost exactly: each vector takes 4 × dimensions + 8 bytes, and a half-precision halfvec takes 2 × dimensions + 8 (pgvector README). A 1,024-dimension embedding is therefore 4,104 bytes, so 120,000 chunks is about 492 MB of raw vectors, or about 247 MB as halfvec. The graph index adds more on top; FAISS's index table puts HNSW at 4·d + M·2·4 bytes per vector (FAISS wiki — Faiss indexes), so an M of 32 adds 256 bytes per vector.

Chunks → embedding-pass hours. The ratio is what matters. Sentence-Transformers' published encoding speeds for msmarco-distilbert-base-v4 are 1,100 documents per second on a V100 versus 70 per second on an 8-core Xeon Platinum 8168 (SBERT — MS MARCO models) — roughly a 16× gap. Whatever your absolute speed, a pass that finishes in one hour on a GPU takes most of a day on CPU cores alone.

CorpusApprox. chunks1024-dim vectors (pgvector)Embedding passBuild tier
Personal notes, under 5,000 docsunder 50,000under ~205 MBCPU overnight is fineRyzen 5 5600G alone
Team wiki or contract archive, 5,000–50,000 docs50,000–500,000~205 MB – 2.05 GBGPU turns days into hoursRTX 3060 12 GB + 5600G or 5800X
Large archive, over 50,000 docsover 500,000over ~2.05 GBGPU required; re-indexing is a planned eventRTX 3060 12 GB + 5800X + 64 GB RAM

If you land in the first row, you can skip the GPU until you want a bigger generator. Everyone else should read on.

Comparison table

PickBest forKey specPrice contextVerdict
ZOTAC RTX 3060 Twin Edge OC 12GBBest overall12 GB GDDR6, 170 W$329 launch MSRP; check current priceCheapest card that holds an 8B–14B generator plus an embedder
MSI RTX 3060 Ventus 2X 12GBest value12 GB GDDR6, 235 mm longSame class as the ZOTAC; buy whichever is cheaper todayIdentical silicon in a short, single-8-pin card
AMD Ryzen 5 5600GAlways-on retrieval6C/12T, 65 W, Vega 7 iGPU$259 launch priceFrees all 12 GB of VRAM by driving the display itself
AMD Ryzen 7 5800XBest performance8C/16T, 105 W, PCIe 4.0Check current priceMost parsing and chunking throughput on AM4
Kingston A400 960GBBudget pick500 MB/s read, 300 TBWCheck current priceKeeps weights and index off the boot drive

Top picks

🏆 Best Overall: ZOTAC Gaming GeForce RTX 3060 Twin Edge OC 12GB

12 GB GDDR6 · 192-bit bus · 3,584 CUDA cores · 170 W

The ZOTAC Gaming GeForce RTX 3060 Twin Edge OC 12GB is the part the whole build hangs on. NVIDIA's specification lists 12 GB of GDDR6 on a 192-bit bus, 3,584 CUDA cores and 170 W of graphics-card power, with a 550 W system power recommendation (NVIDIA — RTX 3060 family specs); TechPowerUp's database confirms the GA106 configuration (TechPowerUp — RTX 3060 12 GB). It launched at $329 (NVIDIA — RTX 3060 announcement).

For RAG, the number that matters most is prompt processing, not generation, because every question arrives with several retrieved chunks attached. LocalScore records 1,488 tok/s of prompt processing and 51.6 tok/s of generation on Llama 3.1 8B Q4_K_M, and 753 tok/s prompt / 26.4 tok/s generation on Qwen2.5 14B Q4_K_M (LocalScore — RTX 3060). Put five 512-token chunks in a prompt — 2,560 tokens — and the 8B model spends about 1.7 seconds on prefill before the first word; the 14B model spends about 3.4 seconds. Both are usable. The llama.cpp community scoreboard shows the same card's raw ceiling at 2,137.5 tok/s prompt and 75.6 tok/s generation on the smaller Llama 2 7B Q4_0 (llama.cpp CUDA scoreboard).

Pros

  • 12 GB holds a 14B generator at Q4_K_M (8.99 GB file, per bartowski — Qwen2.5 14B GGUF) with an embedding model resident beside it.
  • The GPU embedding pass is where the ~16× GPU-over-CPU gap pays out on a real corpus.
  • 170 W board power keeps the PSU and cooling requirements ordinary.
  • Mature CUDA support across Ollama, llama.cpp, Sentence-Transformers and text-embeddings-inference.

Cons

  • A 14B model leaves little headroom: TYO Lab's 12 GB benchmark set notes that 14B models required --ctx-size 4096 to fit (TYO Lab — 64 GB RAM, 12 GB VRAM), which limits how many chunks you can retrieve per question.
  • Ampere-era throughput; newer cards finish the embedding pass faster.
  • The RTX 3060 is also sold as an 8 GB variant — confirm the listing says 12 GB.

Buy on Amazon → · See full details →

Price may vary — check the retailer page for current pricing.

💰 Best Value: MSI GeForce RTX 3060 Ventus 2X 12G

12 GB GDDR6 · 192-bit · 170 W · 235 × 124 × 42 mm · 1× 8-pin

The MSI GeForce RTX 3060 Ventus 2X 12G is the same GA106 chip with the same 12 GB, so every number in the pick above applies unchanged. MSI's datasheet for the OC edition lists a 1,807 MHz boost, 15 Gbps memory, 170 W power draw, a single 8-pin connector, a 550 W recommended PSU and a card size of 235 × 124 × 42 mm (MSI — Ventus 2X 12G OC datasheet).

The value argument is about the rest of the build, not the sticker. At 235 mm it fits compact mATX and small-form-factor cases that a triple-fan 3060 does not, and a single 8-pin connector means a basic 550 W unit covers it. For a document-QA box that lives in a closet or under a desk, that can remove a case upgrade from the bill entirely. Street prices between this card and the ZOTAC swap back and forth week to week, so compare both links and buy the cheaper one on the day — the silicon is identical.

Pros

  • Same 12 GB, same 170 W envelope, same software support as the Best Overall pick.
  • 235 mm length and a 42 mm thickness fit small cases.
  • One 8-pin connector and a 550 W PSU recommendation keep the power budget simple.

Cons

  • A two-fan cooler on a compact card runs louder under a long embedding pass than larger coolers.
  • No performance advantage whatsoever over the ZOTAC — this pick exists only on price and fit.

Buy on Amazon → · See full details →

Price may vary — check the retailer page for current pricing.

🎯 Best for Always-On Retrieval: AMD Ryzen 5 5600G

6 cores / 12 threads · 3.9–4.4 GHz · Radeon Vega 7 · 65 W

The AMD Ryzen 5 5600G is the host CPU for a machine that answers questions around the clock. Tom's Hardware's review lists it at 6 cores and 12 threads, 3.9/4.4 GHz, Radeon Vega 7 graphics and a 65 W TDP, with a $259 launch price (Tom's Hardware — Ryzen 5 5600G review).

Two things make it the right always-on part. First, the integrated GPU drives the monitor, so the RTX 3060's full 12 GB stays available for models — on a CPU without graphics, the desktop takes a slice of VRAM before you load anything. Second, the 65 W envelope suits a box that is idle most of the day and busy for seconds at a time. It also works as a GPU-less starter build for the first corpus tier: CPU embedding is practical at small scale, and Hugging Face's Intel work shows int8-quantized BGE models running up to 4.5× faster than full precision on CPU (Hugging Face — CPU-optimized embeddings).

Pros

  • Integrated graphics keep every megabyte of the discrete card free for models.
  • 65 W TDP suits 24/7 duty and ordinary air cooling.
  • Runs small corpora with no discrete GPU at all.

Cons

  • PCIe 3.0 connectivity, flagged as a con in Tom's review, lengthens model loads slightly; it does not affect generation once weights are resident.
  • Six cores parse PDFs more slowly than the 5800X on a big re-index.

Buy on Amazon → · See full details →

Price may vary — check the retailer page for current pricing.

⚡ Best Performance: AMD Ryzen 7 5800X

8 cores / 16 threads · 32 MB L3 · 105 W · PCIe 4.0

The AMD Ryzen 7 5800X is the pick when the corpus is large and changes often. AMD lists it at 8 cores and 16 threads, 32 MB of L3, a 105 W default TDP and PCIe 4.0 support, and notes that a discrete graphics card is required (AMD — Ryzen 7 5800X).

The GPU does the embedding math, but everything before it is CPU work: extracting text from PDFs, cleaning it, splitting it into chunks, tokenizing and batching. On a large re-index those stages are what keep the GPU waiting, and two extra cores plus a large L3 help. PCIe 4.0 also leaves a sensible path to a second card later — see the upgrade note below.

Pros

  • Most parsing and chunking throughput of the AM4 picks here.
  • PCIe 4.0 for faster model loads and a second GPU later.
  • 32 MB L3 helps the branchy, cache-sensitive work of document parsing.

Cons

  • No integrated graphics: the display runs on the RTX 3060 and takes some VRAM.
  • 105 W TDP needs a real tower cooler on an always-on machine.

Buy on Amazon → · See full details →

Price may vary — check the retailer page for current pricing.

🧪 Budget Pick: Kingston A400 960GB SATA SSD

960 GB · up to 500 MB/s read / 450 MB/s write · 300 TBW

The Kingston A400 960GB is the drive that keeps model weights and the vector index off your boot NVMe. Kingston's datasheet lists up to 500 MB/s read and 450 MB/s write for the 960 GB model, a 300 TBW endurance rating, a 3-year warranty and 0.195 W idle power (Kingston — A400 datasheet).

At 500 MB/s, loading the 8.99 GB Qwen2.5 14B file takes about 18 seconds and the 4.92 GB Llama 3.1 8B file about 10 seconds — noticeable if you swap models constantly, irrelevant if the server stays up. A home-scale index of a few hundred thousand chunks is a gigabyte or two, which SATA serves without drama. The Crucial BX500 1TB is a same-class alternative if it is cheaper on the day.

Pros

  • Nearly 1 TB for a model library plus indexes.
  • 300 TBW is plenty for an index that is rebuilt occasionally.
  • Near-zero idle draw for an always-on box.

Cons

  • SATA speeds make repeated model swapping slow compared with NVMe.
  • DRAM-less budget drive; not the place for a write-heavy database.

Buy on Amazon → · See full details →

Price may vary — check the retailer page for current pricing.

What to look for in a local RAG workstation

VRAM tier versus model size

Puget Systems' rule of thumb is to multiply a model's parameter count in billions by two to get gigabytes at 16-bit precision, and to plan an extra 15% on top of the model itself (Puget Systems — what hardware do you need to run a local LLM). At Q4_K_M the files shrink to the sizes above, but RAG adds residents the chat-only math forgets: the embedder, and often a reranker. BGE-reranker-v2-m3 is a 0.6B-parameter model (BAAI — bge-reranker-v2-m3), about 1.1 GB at 16-bit.

Embedding-model throughput

Smaller embedders are dramatically cheaper to run. BGE-small-en-v1.5 is 384 dimensions and about 33M parameters; BGE-large is 1,024 dimensions and about 335M (BAAI — bge-large-en-v1.5). Nomic-embed-text-v1.5 sits between them at 768 dimensions and about 137M parameters with an 8,192-token context (Nomic — nomic-embed-text-v1.5), and BGE-M3 offers 1,024 dimensions with an 8,192-token context (BAAI — bge-m3). On the GPU, Sentence-Transformers reports fp16 with Flash Attention and unpadding as its fastest configuration, 3.87× over fp32 (SBERT — speeding up inference).

Vector-index storage and IOPS

Use the pgvector formula from Step 0. Halving storage with halfvec is usually free in retrieval quality terms, and it keeps the HNSW graph in RAM on smaller machines — pgvector notes that indexes build significantly faster when the graph fits in maintenance_work_mem.

System RAM for chunking and re-ranking

Puget recommends 1.5–2× as much system RAM as VRAM; for a 12 GB card that is 18–24 GB, which rounds to a 32 GB kit. PDF extraction and index builds are the memory spikes, not inference.

Thermals and noise for an always-on box

A RAG server idles most of the day and bursts for seconds per question. Size cooling for the embedding pass — hours of sustained GPU and CPU load — not for the query traffic.

Upgrade path to 24 GB

When the 14B tier stops being enough, a second 12 GB card is the cheapest route to 24 GB; see the dual RTX 3060 24 GB build guide. A 27B-class model at Q4 does not fit on one 12 GB card, and offloading it to system RAM costs far more speed than it does in chat because RAG prompts are long.

What fits in 12 GB: embedding and generator pairings

Resident weights are file sizes for the generator (bartowski — Llama 3.1 8B GGUF, bartowski — Qwen2.5 14B GGUF) plus 16-bit parameter counts for the embedder and reranker from their model cards; BGE-M3 is Ollama's listed 1.2 GB (Ollama — bge-m3). Index size uses pgvector's 4 × d + 8 bytes per vector. Throughput is LocalScore's RTX 3060 measurement for the generator alone, before KV cache and any co-resident model.

Embedder + generatorEmbedding dim / max inputWeights resident (approx.)Index per 100,000 chunksGeneration on RTX 3060Prompt processing
BGE-small-en-v1.5 + Llama 3.1 8B Q4_K_M384 / 5120.07 + 4.92 ≈ 5.0 GB154 MB51.6 tok/s1,488 tok/s
BGE-large-en-v1.5 + Llama 3.1 8B Q4_K_M1,024 / 5120.67 + 4.92 ≈ 5.6 GB410 MB51.6 tok/s1,488 tok/s
BGE-large + BGE-reranker-v2-m3 + Llama 3.1 8B Q4_K_M1,024 / 5120.67 + 1.14 + 4.92 ≈ 6.7 GB410 MB51.6 tok/s1,488 tok/s
nomic-embed-text-v1.5 + Qwen2.5 14B Q4_K_M768 / 8,1920.27 + 8.99 ≈ 9.3 GB308 MB26.4 tok/s753 tok/s
BGE-M3 + Qwen2.5 14B Q4_K_M1,024 / 8,1921.2 + 8.99 ≈ 10.2 GB410 MB26.4 tok/s, context capped near 4K753 tok/s

The 8B rows leave generous room for KV cache and long retrieval contexts. The 14B rows trade that room for answer quality; TYO Lab measured Qwen2.5-Coder-14B at 35.8 tok/s with a 4,096-token context on a 12 GB card (TYO Lab), which is roughly the ceiling you should plan around.

Common pitfalls

  • Chunks longer than the embedder's window. Anything past 512 tokens on BGE-large or E5-large-v2 is silently truncated, so the tail of every oversized chunk never makes it into the index.
  • Changing the embedding model without re-indexing. Query vectors and document vectors must come from the same model. Swapping embedders means a full re-embed.
  • One server for everything. llama.cpp's --embedding flag restricts a server instance to the embedding use case, so plan on separate instances for the embedder and the chat model.
  • Retrieving too many chunks. Twenty 512-token chunks is 10,240 prompt tokens — about 13.6 seconds of prefill on a 14B model at 753 tok/s before the first word appears.
  • Index on the boot drive. Put weights and indexes on a dedicated SSD so a reinstall or a full boot disk never takes the knowledge base with it.

Frequently asked questions

How much VRAM does a local RAG stack actually need?

More than the generator alone implies, because the embedding model and any cross-encoder re-ranker are resident at the same time. A 12GB card comfortably hosts a 7B-14B generator at Q4_K_M alongside a large embedding model, but the same card gets tight once you add a re-ranker and push context past 16K tokens. Plan on 12GB as the floor and 24GB as the comfortable tier.

Do I need a GPU for the embedding pass, or will a CPU do?

A CPU works and is the right call for small corpora, since embedding is a one-time batch job rather than an interactive one. The tradeoff is wall-clock time: a pass that finishes in an evening on a discrete GPU can take a weekend on cores alone. If you re-index frequently, or your corpus runs to tens of thousands of documents, the GPU pays for itself quickly.

SATA or NVMe for the vector index?

For most home-scale indexes, SATA is sufficient. Retrieval latency is dominated by the embedding comparison and the generator's prefill, not by drive throughput, and a typical index for a few hundred thousand chunks is measured in single-digit gigabytes. Choose NVMe when you are loading and unloading multi-gigabyte model weights repeatedly, where sequential read time is the visible cost.

How much system RAM should I budget?

Thirty-two gigabytes is the practical target. Document parsing, chunking and index construction are memory-hungry in ways that inference is not, and PDF extraction in particular spikes hard on large files. Sixteen gigabytes will complete a small build but leaves no room to run the index server, the generator and a browser at once, which is exactly how these machines get used.

When is a local RAG build the wrong answer?

When your corpus changes hourly, when you need multi-user concurrency, or when answer quality on hard reasoning matters more than data residency. A hosted frontier model with a managed retrieval layer will beat a 12GB local rig on both quality and operational effort. Local wins on privacy, on fixed cost at high query volume, and on offline availability.

Citations and sources

  1. LocalScore — RTX 3060 accelerator page — Llama 3.1 8B Q4_K_M 1,488 tok/s prompt / 51.6 tok/s generation; Qwen2.5 14B Q4_K_M 753 / 26.4 tok/s. (accessed 2026-09-10)
  2. llama.cpp CUDA performance scoreboard — RTX 3060 Llama 2 7B Q4_0 pp512 2,137.5 tok/s, tg128 75.6 tok/s. (accessed 2026-09-10)
  3. TYO Lab — 64 GB RAM, 12 GB VRAM: the honest local LLM benchmark — 14B models at --ctx-size 4096; Qwen2.5-Coder-14B 35.8 tok/s. (accessed 2026-09-10)
  4. bartowski — Meta-Llama-3.1-8B-Instruct-GGUF — Q4_K_M 4.92 GB. (accessed 2026-09-10)
  5. bartowski — Qwen2.5-14B-Instruct-GGUF — Q4_K_M 8.99 GB. (accessed 2026-09-10)
  6. NVIDIA — GeForce RTX 3060 family specifications — 12 GB GDDR6, 192-bit, 3,584 CUDA cores, 170 W, 550 W system power. (accessed 2026-09-10)
  7. NVIDIA — GeForce RTX 3060 announcement — $329 launch price. (accessed 2026-09-10)
  8. TechPowerUp — GeForce RTX 3060 12 GB — GA106 configuration. (accessed 2026-09-10)
  9. MSI — GeForce RTX 3060 Ventus 2X 12G OC datasheet — 235 × 124 × 42 mm, 1× 8-pin, 550 W PSU. (accessed 2026-09-10)
  10. Tom's Hardware — AMD Ryzen 5 5600G review — 6C/12T, 65 W, Vega 7, $259, PCIe 3.0. (accessed 2026-09-10)
  11. AMD — Ryzen 7 5800X — 8C/16T, 32 MB L3, 105 W, PCIe 4.0. (accessed 2026-09-10)
  12. Kingston — A400 datasheet — 500/450 MB/s, 300 TBW, 0.195 W idle. (accessed 2026-09-10)
  13. Puget Systems — what hardware do you need to run a local LLM — 2× parameters rule, +15% overhead, 1.5–2× RAM vs VRAM. (accessed 2026-09-10)
  14. BAAI — bge-large-en-v1.5 — 1,024 dim, 512 tokens; bge-small 384 dim. (accessed 2026-09-10)
  15. intfloat — e5-large-v2 — 512-token truncation. (accessed 2026-09-10)
  16. Nomic — nomic-embed-text-v1.5 — 768 dim, 8,192 context. (accessed 2026-09-10)
  17. BAAI — bge-m3 — 1,024 dim, 8,192 tokens. (accessed 2026-09-10)
  18. Ollama — bge-m3 — 1.2 GB. (accessed 2026-09-10)
  19. BAAI — bge-reranker-v2-m3 — 0.6B parameters. (accessed 2026-09-10)
  20. SBERT — MS MARCO models — 1,100 vs 70 docs/s, V100 vs 8-core Xeon. (accessed 2026-09-10)
  21. SBERT — speeding up inference — fp16 + Flash Attention 3.87× over fp32. (accessed 2026-09-10)
  22. Hugging Face — CPU-optimized embeddings — int8 up to 4.5× faster. (accessed 2026-09-10)
  23. pgvector README4 × d + 8 bytes per vector, 2 × d + 8 for halfvec. (accessed 2026-09-10)
  24. FAISS wiki — Faiss indexes — HNSW memory per vector. (accessed 2026-09-10)
  25. Ollama — Embeddings — embeddings endpoint for RAG pipelines. (accessed 2026-09-10)
  26. llama.cpp server README--embedding and /rerank. (accessed 2026-09-10)

Prices and availability change frequently — the price shown on the retailer page at the time of your visit is authoritative. As an Amazon Associate, SpecPicks earns from qualifying purchases.

This piece is editorial synthesis based on publicly available information. No independent first-party benchmarking is reported.

— Mike Perry · Last verified 2026-09-10

Products mentioned in this article

Live Amazon & eBay pricing, plus full specs and alternatives on each product page.

As an Amazon Associate, SpecPicks earns from qualifying purchases; we also earn on qualifying eBay purchases via the eBay Partner Network. Prices shown were last tracked at crawl time and may vary — check the listing for the current price.

Watch a review

Friendly Fire: AMD Ryzen 7 5800X CPU Review & Benchmarks vs. 5600X & 5900X — Gamers Nexus on YouTube

Frequently asked questions

How much VRAM does a local RAG stack actually need?
More than the generator alone implies, because the embedding model and any cross-encoder re-ranker are resident at the same time. A 12GB card comfortably hosts a 7B-14B generator at Q4_K_M alongside a large embedding model, but the same card gets tight once you add a re-ranker and push context past 16K tokens. Plan on 12GB as the floor and 24GB as the comfortable tier.
Do I need a GPU for the embedding pass, or will a CPU do?
A CPU works and is the right call for small corpora, since embedding is a one-time batch job rather than an interactive one. The tradeoff is wall-clock time: a pass that finishes in an evening on a discrete GPU can take a weekend on cores alone. If you re-index frequently, or your corpus runs to tens of thousands of documents, the GPU pays for itself quickly.
SATA or NVMe for the vector index?
For most home-scale indexes, SATA is sufficient. Retrieval latency is dominated by the embedding comparison and the generator's prefill, not by drive throughput, and a typical index for a few hundred thousand chunks is measured in single-digit gigabytes. Choose NVMe when you are loading and unloading multi-gigabyte model weights repeatedly, where sequential read time is the visible cost.
How much system RAM should I budget?
Thirty-two gigabytes is the practical target. Document parsing, chunking and index construction are memory-hungry in ways that inference is not, and PDF extraction in particular spikes hard on large files. Sixteen gigabytes will complete a small build but leaves no room to run the index server, the generator and a browser at once, which is exactly how these machines get used.
When is a local RAG build the wrong answer?
When your corpus changes hourly, when you need multi-user concurrency, or when answer quality on hard reasoning matters more than data residency. A hosted frontier model with a managed retrieval layer will beat a 12GB local rig on both quality and operational effort. Local wins on privacy, on fixed cost at high query volume, and on offline availability.

Sources

— Mike Perry · Last verified 2026-09-10

Parts this article names

Amazon Associate — prices tracked 2026-09-11, may vary.

More guides & deep dives from the SpecPicks archive

Browse all articles & guides →

More buying guides from SpecPicks

Browse all buying guides →

Hardware benchmark data on SpecPicks

All benchmarks →