DeepSeek Local Requirements: A Comprehensive Guide

Understanding DeepSeek Requirements

Definition of local requirements. Local requirements are the disk, memory, operating system and runtime that one specific weight file needs before it will answer a prompt on your own machine. They belong to the file, not to the brand. DeepSeek publishes open weights under MIT across a range running from an 82.5 GB one-bit build of V4-Flash to an 873 GB eight-bit build of V4-Pro, and both of those are DeepSeek.

That range is why most pages answering this query are wrong before they start. They pick one model, usually R1 from early 2025, and publish VRAM floors with no quantization named and no file size attached. Jan's guide to running R1 locally is the tidy example: six distill sizes, a VRAM number next to each, no build named and no date anywhere on the page. It puts both the 14B and the 32B distill at 16 GB or more, while Ollama's library shows the 14B tag as a 9.0 GB download and the 32B as 20 GB. Those are different purchases. So settle which model you mean first. For local use the story of 2026 is the Flash line: V4-Flash-0731 was the first flagship-family DeepSeek that fits in one machine's memory, and its successor V4.1-Flash-1017, released on 17 October 2026 and described by Unsloth as "the strongest open model to date", needs roughly three times the disk.

One footnote before you commit to V3.2-Speciale: its model card says it is "designed exclusively for deep reasoning tasks and does not support the tool-calling functionality", which rules it out for agent work no matter what hardware you put under it.

Importance of meeting system requirements. Miss the number and you usually do not get an error, you get a slow machine. Unsloth's wording for the 671B family is that if the memory is not there, "hard drive / SSD offloading will work with llama.cpp, just inference will be slower." Slower has been measured: one token per second for R1-0528 at IQ1_S on 64 GB of RAM with no GPU. A working install and an unusable one at the same time.

Two things multiply the requirement after you have sized it. Concurrency is the first. Ollama's FAQ says parallel request processing increases the context size by the number of parallel requests, so RAM scales with OLLAMA_NUM_PARALLEL times OLLAMA_CONTEXT_LENGTH, and that "for GPU inference, models must fit entirely in VRAM for concurrent loads". A setup that works for one person can fall over on the second.

Quantization quality is the other. Unsloth measures its DeepSeek V4 builds by KL divergence against full precision: UD-Q8_K_XL comes out around zero, UD-Q4_K_XL at 0.0102. Below Q2_K_XL the picture changes, and their advice is to avoid one-bit quantization for agentic use, where they report "excessive looping, empty responses, and broken tool-calling". If the plan is a forty-step tool loop rather than a chat window, that is worth measuring on your own prompts.

Worth pricing the alternative before buying anything. DeepSeek's own API now serves deepseek-flash from V4.1-Flash-1017; the old deepseek-v4-flash name is still accepted, but the model behind it is retired and those requests go to 1017 at the Flash price. Checked on 29 October 2026, that price is $0.15 per million input tokens on an off-peak cache miss and $0.60 per million output, doubling to $0.30 and $1.20 in peak hours, which run 01:00 to 04:00 and 06:00 to 10:00 UTC on weekdays. Local hosting wins where the data cannot leave the building. It does not automatically win on cost, and the build-versus-buy arithmetic deserves its own hour.

Hardware Requirements

Minimum hardware requirements. DeepSeek hardware requirements split cleanly in two, and which half you are in depends on whether you want the real model or a distill of it. For DeepSeek minimum requirements on the flagship family, Unsloth names 64 GB of RAM for R1-0528 at IQ1_S and measures it at one token per second with no GPU involved. It runs. Whether it is worth running is a separate decision.

The distills are the other floor, and they are what most "run DeepSeek locally" guides are actually describing. R1-0528-Qwen3-8B fits systems with 20 GB or more of RAM, with GGUF builds from 2.27 GB at UD-IQ1_S to 8.71 GB at Q8_0. Ollama's R1 tags run 1.1 GB at 1.5b through 20 GB at 32b and 43 GB at 70b. Those are Qwen and Llama models fine-tuned on R1 output, which the R1 model card states plainly, so they answer a friendlier question than the one in the title.

On the software side, the only vendor-published minimum worth quoting is LM Studio's: 16 GB of RAM recommended, and at least 4 GB of dedicated VRAM on Windows. Ollama publishes no minimum RAM, disk or CPU figure anywhere in its docs, whatever the aggregator posts claim it says.

Recommended hardware specifications. Here the numbers get useful, because Unsloth publishes measured pairs rather than round ones. For 5 or more tokens per second they name 180 GB of unified memory or combined RAM plus VRAM for R1-0528, and 226 GB for V3.1. The V4-Flash-0731 equivalent is a good deal lower: 110 GB of RAM runs the 3-bit build, and 169 GB covers the lossless 8-bit one. Anyone sizing a 2026 machine off a V3.1 page for that model overbuys by roughly 60 GB of RAM for no gain.

V4.1-Flash-1017 moves the other way. Unsloth's V4.1 page, checked on 29 October 2026, states 128 to 145 GB of total memory for the 1-bit builds, 176 to 205 GB for 2-bit, 256 to 290 GB for 3-bit, 305 GB for 4-bit and 315 GB for 8-bit, and every one of those figures assumes the Engram table stays on SSD. That table is "conditional memory": n-grams of up to four tokens look up a few rows per token, so llama.cpp can mmap it from disk and pull rows into the OS cache on demand. Your disk still has to hold the full file, and the cost of that trick on your own drive is something to measure, since nobody has published it.

Apple's Mac Studio is the tidiest single-box answer, since unified memory counts in full toward that total. The M5 Max starts at 36 GB and configures to 48, 64 or 128 GB; the M5 Ultra starts at 96 GB and goes to 256 or 512 GB, with 1.2 TB/s of memory bandwidth on the M5 Ultra. The 512 GB option became orderable on 28 October 2026, and it needs the 36-core CPU, 80-core GPU M5 Ultra. The ceiling is arithmetic. A 512 GB M5 Ultra holds V4-Flash-0731 at 8-bit with room to spare, and the whole V3.1 and R1 ladder up to UD-Q5_K_XL at 481 GB. It does not hold V4.1-Flash-1017 at 8-bit fully resident, because the 508.4 GB file leaves no headroom for the OS or context, so on that machine the Engram table goes to SSD and the stated 315 GB applies. It cannot hold V4-Pro at 4-bit either, which is 850 GB before context.

DeepSeek V3 hardware requirements. The V3.x and R1 671B family is still what most local setups run, and it is what the phrase deepseek v3 local requirements usually means. Full-precision V3.1 weights take 715 GB of disk. Unsloth's dynamic quants take it down to 170 GB at the bottom, which is where the deepseek v3 requirements conversation actually happens.

Both ladders are published file by file, for V4-Flash and for V4-Pro, and two oddities in them deserve an explanation. TQ1_0 is listed at 170 GB on the V3.1 page and 162 GB on the R1-0528 page for the same quant, so treat it as a range. And on V4, 4-bit is barely smaller than 8-bit, 155.1 GB against 162 GB, because the V4 checkpoints already ship as FP4 and FP8 mixed with the expert weights in FP4. Quantizing further mostly touches the non-expert tensors, a small slice of a mixture-of-experts model. Same pattern on V4-Pro: 850 GB against 873 GB.

V4.1-Flash-1017's ladder has the same squeeze at the top, 500.7 GB at 4-bit against 508.4 GB at 8-bit, for a different reason. Both carry the Engram table in MXFP8 at 202.8 GB. The lower rungs save most of their space by shrinking that table instead, to Q6_K at 161.3 GB on the 3-bit builds, Q5_K at 135.2 GB on 2-bit and IQ4_NL at 110.6 GB on 1-bit. The repo card itself sums it up as a "128GB+ RAM device" for the smallest 1-bit quant, 256 GB for 3-bit and 320 GB for full precision.

Essential GPU and VRAM requirements. The deepseek gpu requirements question has an uncomfortable answer for consumer hardware: nothing you can buy holds a flagship build. NVIDIA's GeForce lineup tops out at 32 GB on the RTX 5090, with 16 GB on the 5080, 5070 Ti and 5060 Ti, and 12 GB on the 5070. Against a 155 GB file that is not a shortfall you close by adding a second card.

So the GPU's job changes shape. Instead of holding the model it holds the dense tensors and the KV cache, while the mixture-of-experts weights sit in system RAM and stream from there. Unsloth measured that at around 5 tokens per second for a 2-bit V3.1 quant on a single 24 GB GPU with 128 GB of RAM, and their 1.66-bit TQ1_0 build targets the same shape of machine. Which reframes deepseek vram requirements as a question about how much of the dense path stays resident, not about fitting the weights.

Driver minimums are specific and worth checking before you blame the hardware. Ollama needs NVIDIA compute capability 5.0 or higher on driver 550 and newer, 570 and newer for compute capability 5.0 to 6.2, and the AMD ROCm v7 driver on Linux. vLLM needs compute capability 7.5 or higher, and CUDA 12.8 as a minimum on Blackwell parts such as B200 and GB200.

If the question is what hardware does DeepSeek use once you stop pretending it is a desktop model, the vLLM recipes answer it. V4-Flash is validated on H200 at 8x192 GB, MI300X at 8x192 GB, MI325X at 1x256 GB, MI355X at 4x288 GB, plus B200, B300, GB200 and RTX PRO 6000 at 8x96 GB, serving from an FP8 checkpoint of 148.66 GiB. V4-Pro wants eight GPUs on a B300 or H200 node with data and expert parallelism, and on H200 the context gets capped with --max-model-len 800000 rather than run at the full million.

System Requirements

Operating system compatibility. DeepSeek system requirements on the OS side are really runtime requirements, because DeepSeek ships weights and nothing else. There is no DeepSeek installer. What you install is llama.cpp, Ollama, LM Studio or vLLM, and they disagree in one place that catches people out.

The trap is vLLM. It is the fastest path to a served DeepSeek endpoint, it is what the official recipes are written against, and it does not run natively on Windows at all. LM Studio's macOS support is Apple Silicon only from macOS 14.0, so an Intel Mac is out regardless of how much RAM it has.

Required software dependencies. vLLM wants Python 3.10 through 3.13 and ships binaries compiled against CUDA 12.9 by default, with 12.8, 13.0 and 13.1 available as options. llama.cpp carries the widest backend list, covering CUDA, Metal, HIP for AMD, Vulkan, SYCL for Intel and plain CPU among others, and it supports integer quantization from 1.5-bit through 8-bit, which is why every GGUF ladder in this article exists at all. Ollama adds Vulkan on Windows and Linux and Metal on Apple devices.

Configuration and installation steps. Five steps, in the order that stops you from downloading 155 GB twice.

1. Install a runtime. On Linux, Ollama is one line: curl -fsSL https://ollama.com/install.sh | sh, then ollama serve and ollama -v to confirm. llama.cpp ships through package managers now too: brew install llama.cpp, winget install llama.cpp, or conda install -c conda-forge llama.cpp, with conda-forge carrying prebuilt CUDA, Vulkan and Metal variants. Build from source only for a backend the packages miss: cmake llama.cpp -B llama.cpp/build -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON, then cmake --build llama.cpp/build --config Release -j, and set -DGGML_CUDA=OFF on Apple hardware since Metal is on by default.

2. Pick the build, not the model. Reference syntax is repo name, colon, quantization variant: llama serve -hf unsloth/DeepSeek-V4-Pro-0813-GGUF:UD-Q4_K_XL. llama.cpp's current quick start is llama cli -hf <repo> and llama serve -hf <repo>; guides still showing llama-cli and llama-server are describing the older CLI surface, which is a decent staleness test for any tutorial you find.

3. Check the runtime actually has the weights. Both tags on `deepseek-v4.1-flash` in Ollama's library, cloud and 1017-cloud, are cloud tags listing a 1M context window and no download size, checked 29 October 2026, and the older `deepseek-v4-flash` entry now lists no models at all. ollama run deepseek-v4.1-flash sends your prompt to an API, which is fine deliberately and bad by accident, especially if the reason you went local was that the data cannot leave the building. Community uploads under personal namespaces do exist; we have not tested them and would not size a machine from them. For V4 and V4.1 the local path today is a GGUF through llama.cpp or LM Studio, or the safetensors through vLLM.

4. Use the sampler that matches the generation. V3.x and R1 want --temp 0.6 --top-p 0.95 --min-p 0.01. V4 wants --temp 1.0 --top-p 1.0, dropping top_p to 0.95 for agentic tasks. Carrying V3 sampling settings into a V4 build is one of the quieter ways to make a good download look broken. On V4 you also control reasoning through the chat template rather than a flag: --chat-template-kwargs '{"enable_thinking":false}' turns thinking off, and '{"reasoning_effort":"max"}' turns it up. V4.1 keeps temperature 1.0 and top_p 1.0, turns top-k and min-p off (--top-k 0 --min-p 0.0), and takes reasoning_effort as an integer from 1 to 100, where low is 50, medium 62, high 75 and max 100. One more V4.1 catch, as of 29 October: Unsloth's instructions build llama.cpp from an open pull request (#30817) rather than a release, so a packaged llama.cpp may not load the file yet.

5. Merge split GGUFs if your runtime needs them. Anything past roughly 162 GB arrives as numbered parts. ./llama.cpp/llama-gguf-split --merge DeepSeek-V3.1-Terminus-UD-Q2_K_XL-00001-of-00006.gguf merged_file.gguf puts them back together. Budget the disk for both copies while it runs.

Memory Requirements

DeepSeek memory requirements. Almost the whole deepseek local requirements question resolves into one rule, and Unsloth states it without hedging: "For the best performance, have your VRAM + RAM combined = to the size of the quant you're downloading." Their V4 documentation repeats it as total memory, RAM plus VRAM or unified, exceeding the quantized file size. Note what the rule does not say. It does not care which side of the split the memory sits on, which is why a Mac Studio and a workstation with one mid-range card and a lot of DIMMs land in the same place.

Their own figures show what "exceeding" means in practice. The 155.1 GB 4-bit V4-Flash file is listed as needing 162 GB, and the 162 GB lossless 8-bit file as needing at least 169 GB. Roughly 7 GB of headroom over the file, before you add context. Speculative decoding with the DSpark drafter adds about 10 GB more on top, and the drafter itself is a separate 10.9 GB download at Q8_0. On V4.1-Flash-1017 Unsloth phrases the headroom differently, as "roughly 5-10 GB above non-Engram weights", and the V4.1 drafter is 7.98 GB at Q8_0.

Impact of memory on performance. The measured points are few but they line up. R1-0528 at IQ1_S on 64 GB of RAM with no GPU gives 1 token per second. A 2-bit V3.1 quant on one 24 GB GPU with 128 GB of RAM gives around 5. R1-0528 at 180 GB of combined memory gives 5 or more, and V3.1 needs 226 GB to reach the same place. The curve is not smooth. There is a cliff where the weights stop being read off the SSD on every token.

At the other end, memory buys something different. Unsloth measured V4-Flash on a B200 at 120 tokens per second with DSpark speculative decoding against 60 without, which is where those extra 10 GB of drafter headroom pay for themselves. Nobody publishes comparable tokens-per-second numbers for DeepSeek on consumer GPUs or M-series Macs, and the figures circulating in blog posts carry no measurement conditions, so we are not going to repeat them here.

Optimization tips for memory usage. Four levers, roughly in the order worth trying them, and the first one does most of the work.

Offload the experts rather than whole layers. In a mixture-of-experts model the expert weights are the bulk and they are touched sparsely, so pushing them to system RAM while the dense path stays on the GPU is the cheapest trade available. --n-cpu-moe N is the current flag. The older regex form still shown on the V3.1 page gives three rungs: -ot ".ffn_.*_exps.=CPU" moves everything and uses the least VRAM, -ot ".ffn_(up|down)_exps.=CPU" moves the up and down projections, and -ot ".ffn_(up)_exps.=CPU" moves only the up projections. Work down until you run out of VRAM, then step back one.

Quantizing the KV cache comes next. --cache-type-k q4_0 and its siblings cut the cache rather than the weights, which matters far more at 128K context than at 8K. Unsloth prefers the _1 variants for better accuracy at a slight speed cost, and Ollama exposes the same thing as OLLAMA_KV_CACHE_TYPE with f16, q8_0 and q4_0.

After that, set the context you actually use. Ollama defaults to 4096 tokens, usually too small, while a llama.cpp build loading a V4 model will happily reserve a window you never fill. Unsloth's recommended --ctx-size for the 671B family is 16384, and that is a flag value rather than a model limit, since R1 itself is a 128K model.

Last, stop copying deprecated advice. --no-mmap and --mlock are both marked DEPRECATED in favor of --load-mode in the current llama.cpp server README, which is also where the flag descriptions in the table above come from, and almost every DeepSeek tutorial still leads with them. Small thing, but it tells you how old the rest of the page is.

Troubleshooting Common Issues

Identifying hardware compatibility problems. Start with placement rather than logs. ollama ps reports whether a model is running at 100% GPU, 100% CPU, or split, and that one line answers most of the "why is this so slow" questions before you open anything else.

Logs come next, and they live in different places per platform: ~/.ollama/logs/server.log on a Mac, journalctl -u ollama --no-pager --follow --pager-end on Linux, %LOCALAPPDATA%\Ollama\server.log on Windows, and docker logs <container-name> in a container.

For NVIDIA, Ollama's troubleshooting page gives a sequence: docker run --gpus all ubuntu nvidia-smi verifies the container runtime sees the card, sudo nvidia-modprobe -u and then sudo rmmod nvidia_uvm followed by sudo modprobe nvidia_uvm reload the driver module, sudo dmesg | grep -i nvidia surfaces kernel complaints, and CUDA_ERROR_LEVEL=50 turns on fuller diagnostics. One documented quirk is worth memorizing: on Linux, after a suspend and resume cycle Ollama sometimes stops discovering the NVIDIA GPU and falls back to the CPU without saying so. If a machine was fast yesterday and slow today and nothing else changed, check that first.

AMD has a separate list. Confirm group membership on /dev/kfd and /dev/dri, then run with AMD_LOG_LEVEL=3 and OLLAMA_DEBUG=1 and grep the log for "failure during GPU discovery". Ollama bundles ROCm 7, so a machine still on a ROCm 6.x driver produces timeouts rather than a useful error, and the fix is amdgpu-install plus a reboot. Multi-GPU AMD setups producing gibberish output are a known issue that the docs hand off to AMD's own guide rather than solve. One Windows oddity while we are here: control-character garbage in the terminal is a Windows 10 21H1 problem, fixed by moving to 22H1 or newer.

Solutions for insufficient system resources. When the memory is not there, some fixes cost you nothing and some cost you quality.

Drop a rung on the quant ladder first, because it is the only lever that changes the file rather than the machine. On the 671B family that is a real range, from 481 GB at UD-Q5_K_XL down to 251 GB at UD-Q2_K_XL. Stop at Q2_K_XL if you are doing anything agentic. On V4-Flash-0731 the ladder is compressed, so the useful move is 162 GB down to 103 GB rather than the fine-grained descent the older family allows. On V4.1-Flash-1017 it is long again, 508.4 GB down to 233 GB, and until someone measures agent behaviour on it, we would treat Unsloth's V4 warning about going below Q2_K_XL (334.8 GB on V4.1) as the default.

Pushing the experts to CPU with --n-cpu-moe or --cpu-moe is what makes a 24 GB card useful at all against a 200 GB model. After that, cut context: OLLAMA_CONTEXT_LENGTH=8192 ollama serve, /set parameter num_ctx 4096 inside the CLI, or "num_ctx": 4096 in the API options. And serve one request at a time, because OLLAMA_NUM_PARALLEL defaults to 1 and raising it is the fastest way to turn a working setup into an out-of-memory one.

If disk rather than memory is the constraint, OLLAMA_MODELS moves the model store somewhere with room, and OLLAMA_KEEP_ALIVE controls how long a model stays resident past its default 5 minutes. Setting any of these differs by platform: launchctl setenv and an app restart on macOS, systemctl edit ollama.service with an Environment= line under [Service] on Linux, and the Settings dialog followed by a restart from the Start menu on Windows.

And if none of that gets you there, SSD offload is the floor rather than a failure. It works, it is slow, and at 1 token per second it is a machine you use for overnight batch jobs and not for a chat window.

A pre-flight checklist worth twenty minutes. Run it before the download, not after.

1. Name the exact checkpoint and the exact build, not the family. "DeepSeek V3" is not a size; DeepSeek-V3.1-UD-Q2_K_XL is.

2. Take the file size, add about 7 GB of headroom, add your context, and add 10 GB if you plan to use speculative decoding. Compare that total to RAM plus VRAM in the machine you actually have.

3. Confirm your runtime hosts the weights locally. Search the model's tag list for a download size; if there is only a context window, it is a cloud tag.

4. Check the OS against the runtime, especially if the plan involves vLLM on Windows.

5. Check the driver against the vendor minimum, not against "it worked for another model".

6. Test the exact build you intend to ship on 100 of your own prompts at your real context length. Published divergence numbers hold in aggregate, not on your workload.

The deepseek local requirements question ends in one comparison, so make that the thing you do this week: open the file listing for the build you are planning to run, write the size down, and put it next to the total memory in the machine you plan to run it on. If the second number is smaller, everything else in the plan is theoretical. And if you would rather have someone size that against a real workload before a hardware order goes in, that is what the free audit is for.

FAQ