Two servers. Both spec’d at “2 vCPUs.” One runs 4-5x faster than the other.
Dimitrios Kechagias benchmarked 44 VM types across 7 providers in early 2026. At the 2-vCPU tier: Intel Broadwell shared instances at the bottom, AMD Turin non-SMT at the top — all listed as “2 vCPU.”
Five things called “vCPU”
The label maps to five different hardware realities:
| # | What you actually get | Example | Your share of a physical core | Relative performance |
|---|---|---|---|---|
| 1 | Full physical core, dedicated hardware | AWS dedicated hosts, bare metal | 100% | Baseline |
| 2 | Full core, SMT disabled on shared hardware | AWS C8a/C7a, GCP t2d | 100% | ~95-100% of baseline |
| 3 | One hyperthread, dedicated thread, shared core | Most AWS/GCP/Azure standard instances | ~50% (two threads share one core) | Varies by workload |
| 4 | Time-sliced share, overcommitted | Contabo, shared Hetzner/DO tiers | Depends on neighbor load | 20-80%, varies by hour |
| 5 | Burstable credit, fractional baseline | AWS T-series, GCP e2-micro | 5-50% sustained | 5-50%, then hard throttle |
On most x86 instances, 1 vCPU = 1 hyperthread = half a physical core. The providers say so themselves. Google Cloud: “each vCPU is implemented as a single hardware multithread, and two vCPUs share each physical CPU core by default.” DigitalOcean: “a unit of processing power corresponding to a single hyper-thread on a processor core.”
ARM instances (Graviton, Ampere) are the exception — 1 full core per vCPU because these chips don’t use SMT. A few x86 types (AWS C8a/C7a, GCP t2d) also disable SMT. The pricing page doesn’t flag which is which.
The trap between rows
The gap between row 2 and row 3 is where money disappears.
GCP’s t2d (row 2) and n2d (row 3) are priced comparably. T2D gives you a full core with SMT disabled — always AMD Milan. N2D gives you a hyperthread — half a core. When a user benchmarked both in late 2022: “N2D: 2247 multithreaded. T2D: 4424 multithreaded.” Almost 2x performance. Similar price. (GCP has since migrated N2D to Milan, but the full-core vs hyperthread gap remains.)
The invisible difference: full core vs hyperthread. It doesn’t show up on the pricing page.
An HN commenter compiled Azure’s CoreMark scores across VM types and found 60% variance: “They’re not even necessarily comparable within a vendor.”
The obvious response: just check the CPU model. Necessary, but not sufficient — it won’t tell you whether you’re getting a full core or a hyperthread.
What happens at $5/month
At this price, overcommit is how the math works. HN commenter: “In the VPS market it’s nothing unusual to oversell CPU. You can’t only have 24 VMs on a single server, that doesn’t work financially.”
Two flavors.
Burstable instances give you a fraction of a core as your baseline, plus credits that accumulate when idle. Spend them to burst above baseline. When they run out, hard throttle. AWS t3.nano: 5% baseline. t3.micro: 10%. t3.small: 20%. Full table in AWS docs. GCP e2-micro: 2 vCPUs at 12.5% each, 25% combined. A Reddit user after a year on e2-micro: “I notice it will be randomly slow to a crawl after a minute of 100% cpu usage.”
One Reddit user on the economics: “Basically, it allows AWS to oversell the everloving shit out of their server hardware while still maintaining performance.”
Overcommitted shared instances are the other flavor. No credit system, no documented baseline. You get a “vCPU” and hope your neighbors are quiet. The metric that reveals overcommit is CPU steal: the percentage of time your VM wanted to run but the hypervisor gave the CPU to someone else. Look for %st in top. But even without visible steal, CPU metrics lie on hyperthreaded hardware. Brendan Gregg, who wrote the book on systems performance: “With hyperthreads, however, those stalled cycles can now be used by another thread, so %CPU may count cycles as utilized that are in fact available. That’s wrong.”
A 4-vCPU Contabo box can be slower than a 2-vCPU Hetzner box. A user who compared them: Contabo “was so wildly oversold, that the 4 thread load at idle was often at 4.5 to 5.” Hetzner was “about 3-4x faster on page load times” despite half the vCPUs on paper.
The track record
Oracle’s OCPU shell game. Oracle invented “OCPU.” On A1 Altra instances: 1 OCPU = 1 core. On the next-generation A2 AmpereOne: 1 OCPU = 2 cores. Same unit, different meaning, consecutive generations. Kechagias: “I can’t think of a reason for this other than to confuse their customers.” Phoronix confirmed that Oracle treats each A2 “OCPU” as two AmpereOne cores. Oracle eventually acknowledged this in January 2026, switching to vCPU pricing display.
AWS Lightsail’s invisible credits. Built on T2 burstable instances, marketed as a DigitalOcean competitor. No CPU credit metrics in the console. A user after 38 minutes of sustained load: “My performance was cut to about 5% of the starting speed.” No way to see remaining credits. HN commenter: “I feel like they did this on purpose.”
AWS T3 unlimited billing. T3 launched with unlimited burst mode on by default. A free-tier user set up the smallest instance using a free-tier AMI. Two months later, a $10 bill from burst overages nobody told him to expect.
Contabo’s CPU steal cycle. A LowEndTalk user: “CPU steal reached 70-80% sometimes and everything was slow like a sloth.” 20-30% steal on a 6-core VPS, spiking to 50% under load. Another user compared Contabo 6-core to Vultr 2-core: “No idea how the Vultr 2CPU was outperforming Contabo’s 6CPU.” The predictable cycle: server runs slowly, htop shows nothing wrong, Contabo says nothing is wrong, it resolves in a few days, then repeats.
Hetzner’s undisclosed limits. Shared plans have an undocumented CPU cap. A private support email shared on Reddit: “If you are using a shared plan, you can have the CPU at a maximum of 80% for a long time.” Not in any public doc. Their Cloud FAQ says shared plans are automatically allocated Intel or AMD based on availability. No model number. No baseline. “Unlimited” bandwidth had a similar gap — a user at 250 TB/month received a termination warning: “Although these servers include unlimited traffic, this is far above what we consider fair use.”
Why it stays this way
Not hidden. Not exactly.
AWS documents that each vCPU is a thread, publishes CPU models per instance family, and gives burstable baseline percentages. DigitalOcean’s plan page explains shared vs dedicated in plain language, one click from pricing. The information exists. It’s separated from where you compare and decide.
This isn’t a conspiracy. It’s information architecture. The pricing page is a sales document. The technical docs are reference material. Different documents, different jobs. The pricing page wins the buyer’s attention.
Marilyn Strathern popularized Goodhart’s Law in 1997: “When a measure becomes a target, it ceases to be a good measure.” The vCPU started as an internal scheduling abstraction for hypervisors. Then it migrated to pricing pages and became the number buyers compare across providers. Once “vCPU count” became the target, providers optimized the count while the hardware it described fragmented into five different realities.
What to actually measure
| Metric | Why it matters | How to check |
|---|---|---|
| CPU model and generation | Older generations cost more for less performance — Broadwell sits at the bottom of the 2-vCPU chart, Turin non-SMT at the top | cat /proc/cpuinfo |
| Full core vs hyperthread | t2d vs n2d: ~2x gap on Geekbench multithreaded | Check if instance type disables SMT |
| Steal time | Reveals overcommitment | vmstat 1, look for st |
| Benchmark at peak hours | Shared performance swings with neighbor load | YABS, run at 2 PM |
| Baseline % (burstable) | Your sustained performance floor | Provider docs, always documented |
| Price per benchmark score | The only fair cross-provider comparison | Kechagias publishes this annually |
Three commands tell you what you’re actually running on:
vmstat 1 10 # watch the 'st' column for steal time
cat /proc/cpuinfo | grep "model name" | head -1
curl -sL yabs.sh | bash # real benchmarkIf your steal time regularly exceeds 5%, your host is overcommitted. Compare your YABS scores against the Geekbench browser for your CPU model. If your “4 vCPU” instance benches like someone else’s 1 vCPU, you know.
And pay attention to CPU generation. Kechagias: “A general tip is that you should avoid old CPU generations, as due to their lower efficiency (higher running costs) the cloud providers will actually charge you more for less performance.”
Benchmarking works, but only after you’ve committed. To compare across providers before buying, you’d provision on each one, run YABS at peak hours, and tear down the losers. Hourly billing makes this cheap in dollars. It’s expensive in time, and most buyers don’t know they should.
Even then, shared instances are moving targets. A Hetzner user: “And to be honest it’s worth nothing. Sorry. You can get half, double or the same speed based on the main machine’s current load.”
One provider, Infuze Cloud, built its entire pitch on “1 vCPU = 1 physical thread. No overcommit.” That this is a marketing differentiator tells you what the rest of the industry considers normal.
Scope and shelf life
This covers VPS and cloud VM pricing. Container CPU limits use a different mechanism — Linux’s CFS bandwidth controller, which gives you a mathematically defined time quota regardless of hardware. The abstraction itself isn’t stupid. The problem with VM vCPUs is that they aren’t even a consistent abstraction.
The benchmark data is from early 2026. Instance types change quarterly. The specific numbers will drift. The structural problem won’t.
You’re not comparing servers. You’re comparing the same word applied to five different things.