Can I run Ollama or a small LLM on a dedicated vCPU VPS without a GPU?

Which models fit the RAM of each plan?

On a CPU, RAM decides which model runs and the vCPU decide how fast it runs. The whole model lives in system memory, and the download size Ollama shows is a good first estimate of the memory it takes. Context, the system and anything else on the VPS come on top: Ollama's documentation says the RAM required grows with OLLAMA_NUM_PARALLEL times OLLAMA_CONTEXT_LENGTH, and the default context is 4,096 tokens.

How fast is LLM inference on a CPU?

CPU inference is slower than a GPU by a margin set by threads, memory bandwidth and quantization. Cobaltfell publishes no tokens-per-second figure of its own: Our own YABS and Geekbench 6 results, together with the steal time we measure, will be published with their date once our first test machine is delivered. Until then we quote no performance figure of our own.

The most useful public figure is a test Leaseweb published on 5 April 2026 (page updated 20 August 2026). On a server with two AMD EPYC 9334 processors (Zen 4) running 24 threads, the test generated 27.8 tokens per second with an 8B model at 4-bit quantization (DeepSeek-R1-0528-Qwen3-8B, Q4_K_M), and 8.1 tokens per second with the same model at FP16. An NVIDIA L4 GPU reached 16.7 tokens per second on that model at FP16. Time to first token at Q4 ranged from 3.6 to 4.8 seconds across the models tested.

How do I run Ollama on a CPU-only VPS?

Install Ollama with the official script, pull a model that fits the plan, and confirm it runs entirely on the CPU. ollama ps shows where a loaded model lives: its PROCESSOR column reads 100% CPU on a VPS. Ollama listens on 127.0.0.1, port 11434, by default; reach it through an SSH tunnel, or put an authenticating reverse proxy in front before changing OLLAMA_HOST.

# official install script for Linux
curl -fsSL https://ollama.com/install.sh | sh

# pull and run a model that fits the plan (here about 2.5 GB)
ollama run qwen3:4b "Summarize what a dedicated vCPU is in one sentence."

# where the model is loaded: expect 100% CPU
ollama ps

# service settings: add these two lines under [Service]
sudo systemctl edit ollama
#   Environment="OLLAMA_CONTEXT_LENGTH=4096"
#   Environment="OLLAMA_NUM_PARALLEL=1"
sudo systemctl daemon-reload
sudo systemctl restart ollama

Should I use llama.cpp directly?

llama.cpp is the choice when the quantization, the thread count and the server flags matter. Its README lists AVX, AVX2, AVX512 and AMX support on x86, and integer quantization from 1.5-bit to 8-bit to cut memory use and speed up inference. It ships llama-bench, a performance testing tool whose defaults process a 512-token prompt and generate 128 tokens, and which tries several thread counts in one run.

Two checks take a minute on any VPS: which vector instructions the processor exposes, and whether the model runs faster on as many threads as vCPU or on one thread per physical core. At Cobaltfell, A vCPU is one hardware thread of the host processor. Yours are pinned one to one to your VPS and never lent to another customer, and the two threads of a physical core stay together, so every 2 vCPU make one whole core that no neighbour shares, so Fell 16 gives 16 threads on 8 cores to compare; the rule is explained in is a dedicated vCPU a core or a thread.

# vector instructions the VPS can use
grep -o -w -E 'avx2|avx512f|avx512_bf16|amx_tile' /proc/cpuinfo | sort -u

# prompt 512 tokens, generate 128, on 8 and then 16 threads
llama-bench -m qwen3-8b-q4_k_m.gguf -p 512 -n 128 -t 8,16

What do dedicated vCPU change for inference?

Generation keeps every thread busy for the whole length of an answer, so lost CPU time turns directly into slower tokens. On a shared vCPU, a neighbour's burst stretches each reply as steal time, explained in what CPU steal time is and how to check it on a VPS, and fair-use caps on long full-load periods throttle inference first.

At Cobaltfell: Full load is allowed for as long as your work needs it: no CPU credits, no burst window and no throttling after some minutes at 100%. The RAM of your plan is set aside for your VPS and is not overcommitted, so a loaded model is never pushed out of RAM by the host. The processor family is AMD EPYC 9004/9005 (Zen 4 / Zen 5). Running a model at 100% is allowed; the line is drawn elsewhere: Mining any cryptocurrency is not allowed, on any plan and with any software. Your own heavy CPU work, such as builds, encoding, inference or databases, may run at full load, and a node that only validates a blockchain is not mining.

Hosts that sell dedicated vCPU, and the price of one core, are compared in what a dedicated CPU VPS costs per core in November 2026.

When is a GPU the right answer for an LLM?

A GPU is the right answer when speed per user, the number of users or the size of the model matters more than cost. The Leaseweb test draws the same line: CPU suits batch, asynchronous and light workloads, while GPUs stay ahead for latency-critical work, high concurrency and models above 20B parameters without quantization. Three more cases point to a GPU:

• Models larger than the RAM. Fell 16 has 32 GB; a 70B model at 43 GB fits no plan.
• Long prompts. Retrieval and document chat feed thousands of tokens before the first word, and that prompt stage is where a CPU waits longest.
• Training and fine-tuning. These are GPU jobs in practice.

Cobaltfell sells no GPU. For those cases a GPU server is the right rental, with a CPU VPS kept for the API, the queue and the vector database around the model. Video encoding raises the same question, answered in can a VPS transcode video with FFmpeg without a GPU.