Run DeepSeek V4 Flash on a VPS

Can you run DeepSeek V4 Flash on a VPS?

DeepSeek V4 Flash does not run on an ordinary VPS, and Ollama's library will not put it on your disk at all. Every tag Ollama publishes for this model ends in -cloud, which means inference runs on Ollama's servers and no weights land on your machine. Running it on hardware you rent means a community GGUF build served by llama.cpp, and the smallest published build asks for about 92 GB of memory. The arithmetic comes first here, because the arithmetic is the whole decision.

What the Ollama library actually offers

The model page at ollama.com/library/deepseek-v4-flash listed three tags when it was read on 17 August 2026: deepseek-v4-flash:cloud, deepseek-v4-flash:0731-cloud, and deepseek-v4-flash:preview-cloud. There is no plain tag. Ollama's documentation says cloud models "are automatically offloaded to Ollama's cloud service", so the pull registers the model on your machine while the computation happens somewhere else.

That path works, and it costs you no RAM at all. It needs an account on ollama.com.

ollama signin
ollama pull deepseek-v4-flash:0731-cloud
ollama run deepseek-v4-flash:0731-cloud

ollama list should now show deepseek-v4-flash:0731-cloud. Pin the dated tag rather than the bare cloud one. Both pointed at the same digest on the day this was written, but a floating tag moves when the vendor publishes a new build, and a model that changes underneath a running agent produces bug reports nobody can reproduce. If Ollama is not installed yet, the Ollama on a VPS install guide covers the service and the systemd unit.

Be clear about the trade. Your prompt leaves your network. If that is acceptable for your use, you can stop reading here, because you do not need a 128 GB server.

How big is DeepSeek V4 Flash really?

The published parameter counts disagree, and neither of them sizes a server. Ollama's library page calls it "284B total parameters and 13B activated". DeepSeek's own model card for DeepSeek-V4-Flash-0731 lists 304B total parameters under an MIT licence. Both figures are real. Neither tells you how much memory to rent.

File sizes tell you that. Unsloth publishes GGUF conversions of the 0731 weights, and the 6 builds below span the useful range. The disk figures come from the repository file listing and the memory figures from Unsloth's run guide, both read on 17 August 2026.

[
  {
    "label": "UD-IQ1_S",
    "disk_gb": 82.5,
    "memory_gb": 92
  },
  {
    "label": "UD-Q2_K_XL",
    "disk_gb": 96.8,
    "memory_gb": 102
  },
  {
    "label": "UD-IQ3_XXS",
    "disk_gb": 104,
    "memory_gb": 110
  },
  {
    "label": "UD-Q3_K_XL",
    "disk_gb": 128,
    "memory_gb": 135
  },
  {
    "label": "UD-Q4_K_XL",
    "disk_gb": 155,
    "memory_gb": 162
  },
  {
    "label": "UD-Q8_K_XL",
    "disk_gb": 162,
    "memory_gb": 169
  }
]

Disk size is the download. The memory column sits above the file size in every row, because the weights are not the only thing in RAM. The key/value cache (KV cache), which is the running state the model keeps for every token in your context window, lives there too, along with the compute buffers llama.cpp allocates when it loads the model.

Read the two ends of that ladder. The smallest build, UD-IQ1_S, is 82.5 GB on disk and wants 92 GB of memory. The lossless one, UD-Q8_K_XL, is 162 GB on disk and wants 169 GB. Everything you can run sits between those two numbers.

The top of the ladder is flat, which is worth knowing before you pick. UD-Q8_K_XL is 162 GB on disk against 155 GB for UD-Q4_K_XL, so a server that can hold one very nearly holds the other. The real choices are lower down, where each step costs real gigabytes. What each quantisation level costs in output quality covers that side of the trade.

Which quantisation fits the server you can rent?

Start from the memory you have, not from the model you want. Run this on the candidate box before you download anything:

free -g
nproc
df -h /

free -g prints total and available memory in gibibytes. Compare the available figure, not the total, against the memory column above, and leave headroom for the operating system and anything else the box runs. Here is how common plan sizes land:

• A 64 GB plan reaches nothing on the list. No flag closes a gap that large.
• A 96 GB plan reaches UD-IQ1_S and only that, with very little left over, since the build asks for 92 GB.
• A 128 GB plan reaches UD-IQ3_XXS at 110 GB. It does not reach UD-Q3_K_XL, which asks for 135 GB.
• A 192 GB plan reaches every build in the chart, including UD-Q8_K_XL at 169 GB.

Disk is a separate check. df -h / has to show free space for the download on top of whatever the system already uses, so a 160 GB volume with 40 GB in use will not hold UD-Q4_K_XL at 155 GB.

Most general purpose VPS plans stop far below all of this. If your plan tops out at 8 GB or 16 GB of RAM, the honest answer is that you picked the wrong model, not the wrong settings. That is where running Qwen 3.8 27B on a VPS becomes the useful comparison, and what it takes to self-host Kimi K3 shows the same arithmetic at the other end of the scale.

What happens on a box that cannot hold the weights

The failure looks different depending on how you start the server.

It gets slow and never recovers. llama.cpp maps the weight file into memory instead of reading all of it in, so a server with too little RAM does not refuse to start. It starts, produces the first tokens, then crawls, because each new token reads expert weights that the kernel has already evicted from the page cache. Watch it with vmstat 1. The si and so columns count memory pages swapped in and out per second, and on a healthy box they stay at zero. Steady non zero values mean the machine is reading the model off disk to answer you.

The kernel kills the process. Pass --no-mmap and llama.cpp allocates the whole model up front, so the shortfall becomes a failed allocation instead of slow paging. The process then disappears without printing anything useful of its own. Look in the kernel log:

sudo dmesg -T | grep -i 'killed process'

A line beginning Out of memory: Killed process with llama-server named in the parentheses is your answer. The out of memory killer stopped it, which is why llama.cpp's own output ends mid sentence and explains nothing.

Nothing starts, because the download never finished. The volume filled first. df -h / shows the filesystem at 100 percent, and the part files on disk are unusable. Delete them and free space before retrying, or the next attempt fills the same disk again.

Build llama.cpp and pin one exact build

llama.cpp is the practical local runtime here, because these quantisations ship as several .gguf parts and llama.cpp loads the remaining parts once you point it at the first one. The differences between Ollama and llama.cpp cover where each tool fits.

sudo apt update
sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build
cmake --build build --config Release -j "$(nproc)"

libssl-dev is the one package people skip. llama.cpp's build guide says the project "will build and run without SSL support" when the OpenSSL development libraries are missing, and without SSL support the built in downloader cannot fetch anything over HTTPS. Install it before you build, so you do not build twice.

Start the server with the quantisation named explicitly:

./build/bin/llama-server \
  -hf unsloth/DeepSeek-V4-Flash-0731-GGUF:UD-IQ1_S \
  --threads "$(nproc)" \
  --ctx-size 8192 \
  --host 127.0.0.1 --port 8080

The -hf flag takes a repository name and a quantisation tag after the colon, and llama.cpp caches what it downloads. Always write the tag. Which build you get is the difference between a server that loads and a server that thrashes, so it is not a choice to leave to a default.

To keep the download separate from the run, or to place it on a specific volume, fetch it by hand first:

pip install -U "huggingface_hub"
hf download unsloth/DeepSeek-V4-Flash-0731-GGUF \
  --include "UD-IQ1_S/*" --local-dir ./models
ls -lh ./models/UD-IQ1_S/

ls shows the parts, named DeepSeek-V4-Flash-0731-UD-IQ1_S-00001-of-000NN.gguf and so on. Point the server at part one and llama.cpp reads the split index inside the file to find the rest:

./build/bin/llama-server \
  --model ./models/UD-IQ1_S/DeepSeek-V4-Flash-0731-UD-IQ1_S-00001-of-*.gguf \
  --threads "$(nproc)" --ctx-size 8192 --host 127.0.0.1 --port 8080

Check that it can generate before you wire anything to it:

curl -s http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":"Reply with the single word: ready"}]}'

A JSON response containing a choices array means the weights loaded and the model is producing tokens. Keep --ctx-size small at first. The 1M token context in the model card is a property of the model, not a promise about your server, because the KV cache for a long context is memory on top of the weights. Raise it in steps while watching free -g. Context length and the num_ctx setting covers the same trade on the Ollama side.

How fast is CPU only inference here?

Measure it. Do not take a tokens per second figure from a write-up, including this one.

The mechanism that decides throughput on a CPU is memory bandwidth. Producing one token means reading that token's active expert weights out of RAM, and a general purpose VPS has far less memory bandwidth than a GPU. The mixture of experts design helps, because only a small share of the total parameters is active for any one token, which is the reason this model gets discussed for local use at all. It does not turn a shared vCPU plan into an inference server.

Smaller quantisations move fewer bytes per token. On a CPU that makes the low end of the ladder both the part that fits and the part that answers at a usable rate. Your actual number depends on your host, your memory channels and your context length, so the only figure worth having is one you produced yourself. A repeatable tokens per second benchmark gives the method and the flags.

Is it cheaper to rent a GPU or pay per token?

DeepSeek publishes list prices for its hosted API, and those prices set the bar every self hosted option has to clear. The figures below were read from DeepSeek's pricing page on 17 August 2026 and are the peak rate. Off peak rates are half of these, and a cache hit on input is billed far lower again.

[
  {
    "label": "deepseek-v4-flash",
    "input_usd_per_mtok": 0.44,
    "output_usd_per_mtok": 1.32
  },
  {
    "label": "deepseek-v4-pro",
    "input_usd_per_mtok": 1.32,
    "output_usd_per_mtok": 3.96
  }
]

At 1.32 US dollars per million output tokens for deepseek-v4-flash, do the multiplication for your own monthly volume. If the answer comes out below the monthly price of a server with 110 GB of RAM, then cost is not your reason to self host, and you should say so out loud before you spend a week on it.

Self hosting still wins on other grounds. Data that must not leave your network is the strongest one. A fixed monthly bill instead of a usage bill is the second. If either applies, rent memory rather than fight for it: a GPU instance with enough VRAM runs these builds at a speed a CPU cannot approach, and it bills by the hour, so you can test the model on your real prompts before committing to a month. A CPU box with 128 GB of RAM is the cheaper and much slower option, and it suits batch work where nobody is waiting on the response.

The option most readers should weigh seriously is the smaller model. A 27B or 32B model at a good quantisation, fully resident in RAM on a server you already pay for, answers faster and adds nothing to the bill, and it will serve more people at once. How many concurrent users one self-hosted model can serve is the number that usually decides this.

One last word on figures from comment threads. Smaller sizes circulate than any published build supports, and the repository file listing is the check: the smallest build in the chart above is 82.5 GB on disk. When someone reports a lower number, ask which file they loaded before you plan a server around it.

FAQ

Can I pull DeepSeek V4 Flash with Ollama and run it locally?

No. Read on 17 August 2026, every tag on Ollama's library page for this model ends in -cloud, and Ollama's documentation says cloud models are offloaded to Ollama's cloud service. ollama pull deepseek-v4-flash:0731-cloud registers the model on your machine, then the inference runs on Ollama's servers and your prompt leaves your network. For local inference you download a community GGUF conversion of DeepSeek-V4-Flash-0731 and serve it with llama.cpp.

How much RAM does DeepSeek V4 Flash need?

Between 92 GB and 169 GB, depending on which build you load. UD-IQ1_S is the floor at 82.5 GB on disk and 92 GB of memory. UD-Q8_K_XL is the ceiling at 162 GB on disk and 169 GB of memory. Those memory figures sit above the file sizes because the KV cache and the compute buffers are in RAM as well, and a long context pushes them higher still.

What happens if my VPS has less RAM than the model?

One of two things. With the default memory mapping, llama.cpp starts and then reads weights off disk for every token, so throughput collapses and stays collapsed. vmstat 1 shows the si and so columns holding steady non zero values. With --no-mmap, the allocation fails instead and the kernel's out of memory killer stops the process, leaving a line starting Out of memory: Killed process in the output of sudo dmesg -T. Neither state is fixable with flags, because the box is simply too small for the build you chose.

Is DeepSeek V4 Flash worth running on CPU only?

Only at the smaller quantisations, and only after you measure. Token generation on a CPU is limited by memory bandwidth, because every token reads active expert weights out of RAM, and a general purpose VPS has much less bandwidth than a GPU. Smaller builds move fewer bytes per token, so they are both the ones that fit and the ones that answer at a usable rate. Produce your own figure using a repeatable tokens per second benchmark rather than trusting a published one.