Back to blog

The Best VPS for AI and LLM Inference in 2026

July 28, 2026Mario Marin

Last updated: July 2026

Most guides claiming to rank the best VPS for LLM inference quietly assume a GPU sits behind the plan. That assumption is wrong for the overwhelming majority of affordable cloud VPS instances, including every tier X-Zone Servers offers. A KVM VPS runs inference on its CPU cores and system RAM, which changes what is realistic: quantized 7B-13B GGUF models are the sweet spot, larger models are painful, and streaming a chatbot to real users at scale belongs on dedicated GPU hardware. This is an honest look at what actually works on a CPU-only box, how to size it, and when to walk away.

Why a CPU-only VPS is the honest answer for LLM inference

Inference is fundamentally memory-bandwidth bound. On a GPU, weights sit in fast VRAM and thousands of cores stream through them. On a general-purpose VPS there is no GPU and no VRAM — the model lives in ordinary system RAM and is processed by a handful of vCPUs. That is not a defect; it is simply a different tool. A CPU VPS is excellent for low-volume, private, always-on inference: a personal assistant, a document-summarisation endpoint, a Retrieval-Augmented Generation backend answering a few queries a minute, or a development sandbox where you iterate on prompts without paying per token. It is a poor choice for serving hundreds of concurrent users or generating long completions at conversational speed. Knowing which side of that line you sit on is the whole decision.

Which quantized models actually run without a GPU

The practical universe for CPU inference is quantized GGUF models in the 7B-13B parameter range. Quantization shrinks each weight from 16-bit floats down to roughly 4-5 bits, cutting the memory footprint by three-quarters with only a modest quality loss. The commonly used formats are Q4_K_M (the default balance most people should start with), Q5_K_M (slightly better output, more RAM), and Q8_0 (near-lossless but roughly double the Q4 size). A 7B model at Q4_K_M lands around 4-5 GB on disk and needs a similar amount of RAM in use; a 13B at Q4_K_M sits closer to 8 GB. Anything at 30B or above is technically loadable on a large-RAM box but generates so slowly that it stops being interesting for interactive work.

  • 7B (Q4_K_M): the reliable workhorse — general chat, summarisation, classification, code hints. Comfortable on 8-16 GB.
  • 13B (Q4_K_M): noticeably better reasoning and instruction-following, but slower and hungrier for RAM. Wants 16 GB or more.
  • 3B and smaller: genuinely fast on CPU, useful for embeddings, routing, and simple structured extraction.
  • 30B and up: avoid on CPU unless latency is irrelevant and you are batch-processing overnight.

What makes the best VPS for LLM inference in 2026

RAM, not vCPU count, is the first constraint. The rule of thumb is to budget the quantized model size plus a few gigabytes of headroom for the operating system, the key-value cache that grows with context length, and the inference runtime itself. Long context windows inflate that cache quickly, so a model that loads in 5 GB can consume noticeably more once you feed it a large prompt. The table below maps X-Zone's KVM VPS tiers to what fits comfortably.

X-Zone tierRAM / vCPUPriceRealistic model fit
Micro4 GB / 2EUR 6/mo3B, or a tight 7B Q4 with short context
Starter8 GB / 2EUR 10/mo7B Q4_K_M comfortably
Basic16 GB / 4EUR 16/mo7B at higher quant, or 13B Q4_K_M
Pro24 GB / 6EUR 30/mo13B with generous context, or two smaller models
Business32 GB / 8EUR 58/mo13B Q5/Q8, or a 7B plus embeddings model side by side

For most people self-hosting a single assistant, the Starter or Basic tier is the entry point. The eight vCPUs on the Business tier also matter: llama.cpp scales token throughput with core count up to a point, so more cores buy speed as well as the ability to run models and application code together.

Realistic tokens per second — set expectations honestly

This is where CPU inference demands humility. On a modern multi-core VPS, a 7B model at Q4_K_M typically produces output in the single-digit to low-double-digit tokens-per-second range, with more vCPUs pushing the higher end. A 13B model runs roughly half that. Prompt processing — the initial pass over your input before the first token appears — is faster than generation but still adds latency on long prompts. In practical terms that means a short answer arrives in a few seconds and a long one streams out over tens of seconds. That is perfectly acceptable for a personal tool, a background summariser, or an internal endpoint. It is not acceptable as a public chatbot where users expect instant, GPU-speed replies. If your product needs that, this is the moment to stop reading and budget for GPU hardware.

Setting up Ollama and llama.cpp on the VPS

Because every X-Zone plan ships with full root access and clean Ubuntu, Debian, or Rocky images, the setup is straightforward and identical to a bare-metal server. Ollama is the fastest path: a single install script, then ollama pull a quantized model and it exposes a local HTTP API you can point an application at. Under the hood Ollama uses llama.cpp, which you can also compile directly for finer control over threads, context size, and quantization. The 1 Gbps unmetered bandwidth matters more than it sounds here — model weights are multi-gigabyte files, and pulling a fresh 13B downloads in about a minute rather than a slow crawl. Because inference lives entirely on your own instance, the same box happily runs your runtime and your application together, all deployed in under 60 seconds from a fresh KVM VPS.

  • Storage speed: NVMe SSD means weights load into RAM fast on boot and restart, so a runtime restart is not a coffee break.
  • Full root on KVM: real kernel-level isolation lets you tune threads and hugepages exactly as you would on your own hardware.
  • EU data residency: pick from twelve datacentre cities across Europe and the US, so inference runs on your machine in your chosen Frankfurt or Amsterdam location and private documents never leave your control.

When NOT to use a VPS for inference

The honest counsel: skip a CPU VPS if you need real-time responses for many concurrent users, if you plan to serve 30B+ models interactively, if you require vision or high-throughput embedding pipelines, or if latency is a product feature rather than a convenience. Those workloads want GPUs and, at volume, dedicated hardware. For heavier private inference where you control the whole machine, X-Zone's dedicated servers — high-core Xeon and EPYC builds with large DDR4/DDR5 memory — give far more RAM and cores than any shared tier, though still without a GPU. The point of this article is to help you choose the right tool the first time, not to sell you a VPS for a job it cannot do well.

Verdict

The best VPS for LLM inference in 2026 is one that is honest about being CPU-only, gives you enough RAM for a quantized 7B-13B GGUF model, and hands you full root to run Ollama or llama.cpp exactly how you like. X-Zone Servers fits that brief cleanly: high-RAM KVM tiers up to 32 GB and 8 vCPU, NVMe storage for fast weight loading, 1 Gbps unmetered bandwidth, EU data residency for private inference, and deployment in under 60 seconds. It will not turn into a GPU, and it will not pretend to — but for private, low-volume, always-on inference it is a genuinely strong and inexpensive home.

Explore X-Zone KVM VPS plans for AI and LLM inference →