QVikhr-3-4B on a 1.5K ₽ GPU-less VPS correctly tagged 20 of 20 requests

Many everyday text tasks don't need an expensive frontier model: triaging a support request, pulling a phone number and budget out of an email, judging whether a reviewer is satisfied. Using a frontier model for them is like hammering nails with a microscope. But running a large open model in-house is hard.

You need GPUs, which are hard to find, and not everyone wants to send customer data to a cloud API. Personal data laws also push toward local deployment. The author of a Habr article tested the cheapest option: a VPS from Justhost.

ru with an Ollama template for 1.5K ₽ a month (4 vCPU Intel Xeon Gold 6148, 4 GB RAM, no graphics card). On it he ran nine lightweight models through seven business tasks and a load test.

The result: the best of them, QVikhr-3-4B, assigned the correct category to all 20 of 20 requests (100%), spending 3.5 sec on each. The practical takeaway: a server like this can handle short text routine, but you should verify the model's answers in code and leave long texts for background processing.

What the server is and which models took part

The test covered llama3.2:1b (preinstalled in the template), gemma3:1b and gemma3:4b from Google, qwen3.5:2b and qwen3.5:4b from Alibaba, the granite4:micro-h hybrid from IBM, two Liquid AI models (LFM2.5-1.2B-Instruct and LFM2.5-2.6B), and QVikhr-3-4B-Instruction, which is fine-tuned on Russian. For knowledge-base search (RAG), the author added bge-m3 embeddings. The Russian GigaChat 3.1 Lightning, T-lite and YandexGPT-5-Lite did not fit into 4 GB.

The template turned out to be built for a single small model and a chat. Open WebUI takes about a gigabyte, a quarter of all memory, so the author had to stop it to run the 4B models. He also needed a 4 GB swap: without it, the kernel killed models on long texts. The preinstalled llama3.2:1b proved the worst of the nine. It got 7 of 20 requests wrong, and for three questions whose answers are not in the knowledge base, it invented its own.

What works

Request classification: QVikhr-3-4B, both qwen3.5 models and gemma3:4b made no errors. QVikhr is also three times faster than qwen3.5:4b (about 1000 requests per hour versus 312). It reuses the system prompt it has already read, while the qwen3.5, granite and gemma3 hybrids re-read it every time. On a CPU, this is the main factor in speed.

Review sentiment: QVikhr and qwen3.5:4b correctly rated 22 of 24, and QVikhr was twice as fast. Almost no model recognized sarcasm, so reviews with positive text but a low star rating are better sent to a human.

Data extraction from tickets: qwen3.5:4b returned 59 fields out of 60 and invented nothing. But no model converted "by Friday" in an email sent on Tuesday, 20.10, into 23.10, so dates should be calculated in code. Prompt tweaks helped qwen, but gemma3:4b got worse (from 57 to 54 fields), so rules need to be tested on each model separately.

RAG: QVikhr, both qwen3.5 models and granite answered 14 of 15 questions correctly and honestly replied "there is no information in the knowledge base." An answer takes 40–95 seconds. That is fine for an internal assistant but not for a customer-facing chat. Yandex Direct ads: only qwen3.5:4b stayed within the length limits in all 30 ads, but about half needed fact corrections, so it is a draft generator. CRM normalization: for 4 of the 9 models, answers shifted by one row and the data went to the wrong customers. The answer therefore needs a row id, and the code must check it. Only qwen3.5:4b summarized long documents without distortion, and it did so with swap active.

Load and conclusions

The server processes requests one at a time. At 1, 2 and 4 threads, throughput is almost the same (qwen3.5:4b: 272, 279 and 274 requests per hour); only the waiting time grows. Ollama's parallel slots did not help, and flash attention on this CPU slowed prompt reading from 27 to 12 tokens per second. The default settings worked best.

Bottom line: models from 2B up are fit for routine work, 1B models are not. Short tasks with code-based verification can go to a VPS costing 1.5K ₽, while long ones should be left for background processing. Memory is the bottleneck, so the author advises getting at least 8 GB of RAM. Limitations: the data is synthetic, the samples are small, and large Russian models were not tested on such a server.