Is a dedicated vCPU a core or a thread on a VPS?

Is a dedicated vCPU a physical core or a thread?

A vCPU is one hardware thread of the host processor; a physical core runs two of them. Server and desktop processors run two threads per core through simultaneous multithreading (SMT). AMD's specification pages show it: a Ryzen 9 9950X has 16 cores and 32 threads, an EPYC 9554 has 64 cores and 128 threads. A host that sells by the vCPU sells those threads.

Cobaltfell's written rule: 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.

A Fell 4 is therefore two complete cores, not four halves taken from four different cores. Counted the way a processor vendor counts, every plan holds half as many physical cores as it has vCPU.

Why should both threads of a core belong to the same VPS?

Two threads of one core share that core's execution units and private caches, so a busy neighbour on the sibling thread slows you down without any steal time being recorded. Nothing is taken by the hypervisor in that case; the core is simply full.

Giving both siblings to one VPS removes that coupling. The two threads still compete, but only with your own work, which you can see and schedule. It also explains why 2 vCPU deliver less than 2 whole cores: the pair shares one core's resources, and the gain from the second thread depends on the code it runs. libvirt's vcpupin setting, which ties each virtual CPU to a chosen host CPU, keeps the rule in place over time.

What do other hosts mean by a vCPU?

According to Cobaltfell's survey of 2 November 2026, 22 of the 51 hosts that take crypto without an ID check call a plan's CPU dedicated, and only 2 of those 22 say how their cores map to threads: Cherry Servers and LiteServer. The others write "core", "vCore" or "vCPU" without a definition. Where a host says nothing, read one vCPU as one thread, possibly paired with another customer's thread on the same core. The table quotes what each source wrote; the wider comparison is in what is the difference between a shared and a dedicated vCPU.

How do I see cores and threads from inside my VPS?

nproc gives the vCPU count; lscpu gives the topology the hypervisor chooses to present, which is a label and not proof. libvirt describes its topology element as the requested topology of the virtual CPU provided to the guest. The host decides what a VPS is shown, and it does not have to mirror the real pairing underneath: a VPS can report one thread per core while its threads are sibling pairs, or the reverse.

The evidence of a dedicated vCPU is behavioural: steal time that stays near zero under load, and the same benchmark score at noon and at midnight. The commands are explained in what is CPU steal time and how do I check it on my VPS.

# vCPU available to you
nproc

# topology as presented to the VPS, plus the processor model
lscpu | grep -E '^CPU\(s\)|Thread\(s\) per core|Core\(s\) per socket|Socket\(s\)|Model name'

# which vCPU the guest kernel treats as siblings of one core
grep . /sys/devices/system/cpu/cpu*/topology/thread_siblings_list

# 1, 5 and 15-minute load averages, to compare with nproc
uptime

How many vCPU do I need?

Size a VPS by the tasks that run at the same instant, not by the tasks that exist. On a server you already run, compare the load average from uptime with the count from nproc during your busiest hour. A load that stays above the vCPU count means tasks are queuing for a turn.

Most tools pick their parallelism from the vCPU count on their own, so each workload has its own counter:

When do more vCPU stop helping?

More vCPU speed up only work that can be split. A single-threaded program, such as one Node.js process, runs on one thread on every plan; its speed comes from the clock and the core architecture. The other ceiling is memory: every parallel job carries its own RAM, and Cobaltfell plans keep 2 GB per vCPU. A workload that needs more memory per thread runs better with fewer jobs than with cores it cannot feed.