PVU is a core based metric. The cost of a deployment is the number of cores allocated to the IBM software multiplied by the PVU value assigned to each of those cores. The number of cores is one source of error. The per core value is the other, and it is the one buyers underestimate, because the familiar figure of roughly 70 PVU for a typical Intel core gets treated as if it applied everywhere. It does not.
The number everyone remembers, and why it is not universal.
A common Intel server core sits near 70 PVU, and that figure is correct often enough to feel like a rule. The problem is that IBM assigns PVU per core by processor model. Different processor families, generations and architectures carry different per core values, and some are materially higher than the Intel figure. Treating 70 as a default rather than reading the value for the actual chip is the most common way a PVU calculation drifts off before the core count is even in question.
Where the per core value actually comes from.
The authority is IBM's published PVU table, which maps processor vendor, brand, type and model to a PVU per core value. The calculation is only defensible if the per core value comes from that table for the exact processor in the host, not from memory and not from a value that was correct on a previous generation of hardware. The table is the reference both sides use, so a reconciliation that does not start there starts on sand.
The values buyers most often get wrong.
The recurring errors cluster in a few places:
- Assuming a flat 70 everywhere. Non Intel processors, and even some Intel models, do not share the same per core value.
- Using Power or mainframe cores at Intel rates. These architectures generally carry higher per core values, and pricing them as Intel understates the position badly.
- Confusing threads with cores. Simultaneous multithreading presents more logical processors than physical cores. PVU is counted on cores, not threads.
- Pricing on sockets, not cores. A socket can hold many cores. The per core value applies to each core, so socket level shortcuts misread the count.
- Carrying a stale value after a refresh. A hardware refresh can change the processor model, and with it the per core value, even if the core count looks the same.
Why a wrong per core value moves the whole bill.
PVU is multiplicative, so an error in the per core value scales across every core in scope. If a position rests on Power hosts priced at an Intel rate, the understatement compounds across the whole estate, and at audit the correction arrives as a finding with the higher value applied to all of it. The same multiplier works in the buyer's favor when IBM has applied too high a value or counted threads as cores. An independent recalculation against the published table is what surfaces the error in either direction before it is locked into a settlement.