By the HostingDive Team
VPS sizing can focus on RAM first. Buyers ask how much RAM the model needs, because RAM is the spec everyone quotes when the topic comes up. For the workload we tested, RAM was not what ran out first. CPU was. We ran a small open-weight language model plus an n8n workflow and a minimal MCP server on Hostinger's KVM 2 and measured both vCPUs at 99.8 to 100 percent while peak model RSS was about 2.3 GB.
That points to a specific buying decision. A one-vCPU plan is below the shape this workload needs, whatever RAM comes with it. Hostinger's KVM 2, at two vCPUs, is the smallest plan in its lineup that actually matches what we measured. KVM 4 is real headroom, worth paying for if you plan to grow into it, and more than this particular workload required.
What we ran
The test instance was a Hostinger KVM 2: two vCPU cores (AMD EPYC), 8 GB of RAM, 100 GB of NVMe storage, and 8 TB of bandwidth, in Hostinger's Boston, US data center. We ran three workloads on it, one at a time, with a process-level sampler logging CPU and memory once per second throughout:
- Model inference. Qwen2.5-1.5B-Instruct at Q4_K_M quantization, served through llama.cpp on CPU only. Forty fixed prompts at temperature 0, three timed runs.
- Workflow automation. A three-node n8n workflow (webhook in, transform, response out), hit with 400 HTTP requests: 200 one at a time, 200 in bursts of 20.
- Tool calling. A minimal MCP server we wrote ourselves, since pulling the official reference server would have meant running unreviewed code at test time. We drove it with 1,000 calls, split between sequential and five-worker concurrent load.
We also scripted a 20-step tool-use conversation against the same running model, to see what a real multi-turn agent loop costs. That is a different measurement from raw generation speed, and we kept it separate rather than blending the two.
What happened
The model generated at approximately 31.7 tokens per second, decode only, with a 95th-percentile time to first token of 0.64 seconds. That clears the 5.0 tokens-per-second bar we set as acceptable before testing started by more than six times over. The figure held up under an independent re-measurement on the same instance.
While it generated, the model kept both vCPUs at 99.8 to 100 percent busy across all three runs and peaked at about 2.3 GB of memory. CPU steal time, the share of a shared host's processor time claimed by other tenants, stayed under a quarter of one percent across the runs, negligible for this workload.
The n8n workflow handled all 400 requests without a single failure. One at a time, requests came back in a median of 29.7 milliseconds; pushed to 20 at once, the median rose to 348.5 milliseconds. The n8n's own process peaked at about 356 MB of memory and added roughly 8 percent to overall CPU load, a small add-on next to the model's own footprint. The MCP server was smaller still: 1,000 calls with zero errors, sub-millisecond response times, and a sampled single-process memory footprint around 14 MB; a true five-worker concurrent memory peak was not measured.
The agent loop told a different story than raw generation speed. Rereading a growing conversation on every turn, the way a real coding or research agent works, brought throughput to 17.78 tokens per second round-trip, averaged across five runs. That number does not compare to the 31.7 tokens-per-second decode figure above; they measure different things. Memory during the agent loop stayed close to the plain-generation run, at about 2.35 GB peak.
What it means for buying
The generation workload pinned both vCPUs near 100 percent and peaked at about 2.3 GB of memory. Using the preregistered 60 percent memory-headroom rule puts the floor for this workload at about 3.8 GB. Storage was not close to a constraint; the model, container, and OS together used about 4 GB against the KVM 2's 100 GB.
Run that against Hostinger's own KVM lineup. KVM 1 (one vCPU, 4 GB RAM) has enough memory on paper, but only a single core, and this workload used two cores at close to full load. We did not test a KVM 1 directly, so this is an inference from the CPU shape we measured rather than a result from running it: one vCPU falls short of what this workload used at peak. KVM 2 (two vCPU, 8 GB RAM) is the plan we tested on, and the smallest plan in Hostinger's lineup with two cores, which is what this workload needs. KVM 4 (four vCPU, 16 GB RAM) goes past what this workload required. It provides more CPU and RAM headroom than this particular workload required. KVM 8 (8 vCPU, 32 GB RAM) was not tested.
Running the model, the automation workflow, and the tool-calling server on the same box at once, rather than one at a time, puts combined peak memory at roughly 2.7 GB by arithmetic, about a third of the KVM 2's 8 GB. That is real headroom, though we have not verified the combined figure by running the three workloads together.
Who this fits
This shape resembles single-user private AI experimentation with a small local model, short sequential tool-calling workflows like the measured 20-step loop, or lightweight n8n/webhook automation running alongside the model. It also fits experimenting with small open-weight models before committing to larger hardware. Our tests measured execution speed and resource behavior, not model quality, multi-user concurrency, or production-serving capacity.
Who should size higher
Everything above describes one 1.5B-parameter model at one quantization level. Larger models, more concurrent users, or heavier automation may require more CPU or memory; they were not measured here. Read this as a floor for a workload this size. It says nothing about a larger model, more concurrent users, or heavier automation on top.
What this test did not cover
One model and one quantization were tested; nothing here extrapolates to a larger model or a different one. KVM 1 was not run, only inferred from the CPU shape the generation workload used. Running the model, n8n, and the MCP server at the same time, rather than sequentially, was not tested directly. No retrieval-augmented workload was run. No automation ran for a sustained multi-hour window. Network bandwidth was not measured; the sampler tracked CPU and memory, not network traffic.
Which plan to pick
For the workload we tested, a single small model with light automation on top, the KVM 2 is the plan that fits: two vCPUs to match what generation actually used, and RAM well past the measured floor. See current KVM plans and pricing on Hostinger: https://hostingdive.com/go/hostinger-vps/