Dedicated CPU vs shared vCPU for Minecraft: Cores, threads, and steal time
A vCPU is a schedulable unit, not a universal performance guarantee. Ask what physical hardware it maps to, who else can run there, and what happens at peak time.
A shared vCPU and a dedicated physical core are not interchangeable units. A vCPU tells the guest how many processors it can schedule work onto. It does not, by itself, tell you whether another customer can use the same underlying core.
For Minecraft, that distinction appears when the main tick must finish within 50 ms during the busiest hour.
The terms in plain language
Physical core
A physical core is an execution core on the processor. Modern Ryzen cores normally expose two hardware threads through simultaneous multithreading.
Hardware thread or logical core
A hardware thread is one schedulable side of a physical core. Operating systems often label each thread as a CPU. Two logical CPUs can therefore belong to one physical core and share parts of its execution resources.
vCPU
A vCPU is a virtual processor presented to a VM. A hypervisor may pin it to a particular hardware thread, allow it to move, cap it, prioritize it, or schedule several guests against the same capacity.
The count alone does not disclose that policy.
Shared CPU
Shared hosting places several workloads against a common pool. When capacity is idle, a server may burst and benchmark well. When several neighbors become runnable together, the hypervisor decides who runs next.
Shared CPU is not inherently dishonest. It enables low prices and is often appropriate for small private servers. The problem is vague language that presents a best-case burst as a guaranteed allocation.
Dedicated logical thread
A provider can reserve one hardware thread for one customer while another customer uses its sibling on the same physical core. This is a bounded sharing model: fewer neighbors and a clear floor, but not the same isolation as reserving both threads.
gummies.cloud uses this model on the expected 4 and 6 GB tiers. One thread is reserved, and the server may use the sibling when it is idle. We call it “a dedicated thread plus burst,” not a dedicated core.
Dedicated physical core
Reserving a physical core means both of its hardware threads stay with the same customer. Another tenant cannot land on the sibling thread. This removes cross-customer contention on that core, though the workload still shares the rest of the physical machine, such as memory channels, storage, and network.
Our expected 8 GB and larger plans use this definition. A one-core allocation means both threads of one physical core.
CPU pinning
Pinning constrains virtual CPUs to selected host CPUs. It can improve consistency and cache locality, but pinning does not prove exclusivity. Two guests can be pinned to overlapping CPU sets. Ask whether the pinned set is sold to anyone else.
CPU steal time
Inside many virtual machines, Linux reports st in vmstat. Steal is time when the guest was ready to run but the hypervisor ran something else. Sustained steal during a slow period is direct evidence of host scheduling contention.
It is not the only cause of lag. A server can have zero steal and still overload its assigned core with plugins, entities, or chunk generation. Use the TPS and spark guide to separate your work from host delay.
Questions every host should answer
- Does core mean physical core, logical thread, or vCPU?
- Are the underlying hardware threads exclusive?
- Is the allocation pinned, capped, or prioritized?
- Can another customer use the sibling hardware thread?
- Is the advertised CPU model guaranteed at the selected location?
- Can the customer measure steal and sustained performance?
If the answer is “enterprise CPU” or “high priority,” the allocation remains undefined.
Sources and review
Reviewed July 15, 2026 against the current gummies.cloud allocation code, pricing language, and verification procedure. Competitor terminology examples were checked against Bloom's logical-core wording and DedicatedMC's plan classes. No claim is made that those providers use the same allocation model as gummies.cloud.