Table of Contents
1. What a vCPU is
A vCPU is a share of a physical core's thread, handed to your virtual machine by the host's scheduler. Vultr states it for its own plans: every plan in its API carries a vcpu_type field whose value is "thread". The other hosts on this site describe the same arrangement in prose rather than in a field, and none of them sells a shared plan on the promise of dedicated cores.
Three consequences follow, and they explain most of what this page can and cannot tell you.
- Your speed depends on the host's load, not only on the processor's specification. Two servers on the same plan, on different hosts, are not the same machine to measure.
- Dedicated-CPU plans exist and cost more. Azure's D-series, Contabo's dedicated lines, Linode's Dedicated plans and Hetzner's CCX line are sold on the promise that the threads are not shared.
- Single-thread speed is what most applications feel. Web servers, databases with small working sets, game servers and scripting languages run on one or two threads each; a big plan with slow cores can lose to a small plan with fast ones on exactly those workloads.
2. What each provider publishes about its CPUs
Read from each provider's own API or page in September 2026. A blank means the provider states nothing about that field on the source read.
| Provider | Vendor | Model | Allocation | Where it comes from |
|---|---|---|---|---|
| Vultr | Yes: Intel or AMD per plan family | No | vcpu_type "thread" | plans API: all 12 vc2 and all 10 vhf plans list Intel, all 51 voc list AMD, the 16 vhp split 8 AMD and 8 Intel |
| Linode | No | No | Plan class: nanode, standard, highmem, dedicated, premium, gpu, accelerated | types API |
| OVHcloud | Field exists, blank | Field exists, blank | Core count per model | public catalog, cpu object: type vCore, cores 2, brand and model blank |
| DigitalOcean | Yes, as a product option | No | Basic Droplets are sold as burstable: "ideal for bursty applications that can handle variable levels of CPU" | pricing page: columns for Regular, Premium Intel and Premium AMD |
| Hetzner | Yes, by line | No | Shared by default; CCX line is dedicated | Cost-optimized page: "our Cost-Optimized plan uses older but reliable processor generations from Ampere, Intel, and AMD" |
| Contabo | Yes, by line | No | Shared by default | Plan page: the Performance VPS line offers "the latest generations of AMD EPYC CPUs" |
| Azure | Yes, per series | Named parts per series | Baselines and burst credits published per B-series size | Bsv2 size series: "virtual machines run on Intel Xeon Platinum 8573C (Emerald Rapids), Intel Xeon Platinum 8473C (Sapphire Rapids), or Intel Xeon Platinum 8370C (Ice Lake) processor" |
| InterServer | No | No | "every two slices has access to one CPU core" | VPS FAQ |
3. Why the data is thin
Two Vultr plans differ by a field in an API; two Hetzner plans differ by a sentence on a marketing page. That is the whole range of what the plan-priced hosts publish, and the reason is structural.
A shared fleet is built over years. When a host needs capacity it buys a batch of servers, and the batch comes with whatever processor generation was on the market that quarter. A plan is therefore a specification of cores, memory, disk and transfer, and an implicit promise that the CPU meets some floor, not a promise of a model. Hetzner is unusually explicit about the floor: its cost-optimized line is described as using "older but reliable processor generations from Ampere, Intel and AMD".
What the shared-fleet hosts publish is a family, and a family is not a model. "The latest generations of AMD EPYC CPUs" for Contabo's Performance line, or Hetzner's "older but reliable processor generations from Ampere, Intel, and AMD", tell a buyer what class of hardware to expect without promising a specific part, which is what a fleet built in batches can offer. Azure is the outlier: its Bsv2 page names the individual Xeon parts a series may run on, because a cloud that publishes per-series specifications can list the alternatives it deploys. On everything else, the processor your server got is a matter of what the scheduler picked.
4. Identifying the CPU you were given
This is the only CPU specification that describes your server rather than a product line.
lscpu: model name, base and boost clock in MHz, cache sizes, flags, and the hypervisor line that confirms you are on a virtual machine.cat /proc/cpuinfo: the same information; read themodel name,cpu MHzandflagslines. On a virtual machine the model name is often a sanitised string the host chose to present.sudo dmidecode -t processor, where the host exposes DMI through the hypervisor; many do not.- Run it at purchase, and again after any migration or resize: a plan change can move the server to a different host generation.
Two things to look for beyond the model: the cpu MHz figure under load, read against the clock the plan page states (a wide gap between the two, held over minutes rather than seconds, means sharing or throttling), and whether the flags include the instruction sets your workload wants (AVX-512 for some numerical work, for example).
5. Measuring it: sysbench, single thread
sysbench's CPU test computes prime numbers in a loop, which makes it a clock-speed and instruction-throughput test rather than a workload simulation. That is exactly what is wanted here: a stable, comparable number for one thread.
- Install:
apt install sysbenchon Debian or Ubuntu,dnf install sysbenchon AlmaLinux or Rocky (sysbench lives in EPEL there). - Single thread:
sysbench cpu --threads=1 --time=60 run. Keep the events-per-second figure, not the total. - All threads: the same command with
--threadsequal to the vCPU count, which shows how the allocation scales and whether the host has spare capacity for your machine. - Repeat at three different hours, keep the median, and note the spread. On a shared plan the spread is the more interesting number: it is the neighbours.
- Compare like with like. A number from a different sysbench version, a different kernel or a different plan is not a comparison; the benchmarks hub has the same warning about third-party score tables.
6. Steal time, and what it tells you
Steal is the CPU time your machine asked for and did not get, because the host gave it to another tenant. The Linux manual page for /proc/stat defines it in one line: "Stolen time, which is the time spent in other operating systems when running in a virtualized environment."
- Where to read it: the eighth field of the
cpuline in/proc/stat, thestcolumn intop, and thestcolumn invmstat. - What it means: steal that keeps showing during your own busy hours is CPU your plan was sold but did not deliver. On a dedicated-CPU plan it should sit at or near zero.
- What to do about it: measure it during your own busy hours. If steal is the problem, the fix is a different host or a dedicated plan rather than a bigger shared plan, because a bigger shared plan on the same busy host inherits the same contention.
7. What the numbers mean for a workload
- CPU-bound (compiles, video encoding, game servers, databases doing scans, heavy PHP or Python): single-thread speed and steal decide it. Measure first, and consider a dedicated-CPU plan if steal is non-zero during your peaks.
- Not CPU-bound (cached websites, static files, most API servers under moderate load): memory and disk latency matter more, and the processor is mostly idle. A faster CPU will not shorten a page load that is waiting on round trips.
- Bursty (a site with occasional spikes): the shared plans are built for this, and DigitalOcean says so of its own Basic Droplets, "ideal for bursty applications that can handle variable levels of CPU". Azure goes further and publishes how much burst a B-series size may accumulate before it is throttled.
The practical order is: identify the CPU with lscpu, measure with sysbench at your own busy hours, watch steal, and only then decide whether the fix is a bigger plan, a dedicated one, or a different provider. The storage specifications page covers the disk half of the same question, and the network page the network half.