Three metrics that get collapsed into one phrase A procurement comparison frames itself as “cost efficiency analysis” and produces a number — performance per dollar, often. That number ranks the candidate options, and the ranking is then taken as the answer to the question of which option is the best value for the deployment. The conflation hides three different metrics that each measure something legitimate but describe different things, and a procurement decision built on the conflation can be defensible against a different question than the one it claims to answer. The three metrics: Performance per dollar of acquisition. What the candidate can do, normalized by what it costs to buy. Total cost of ownership per unit of work. What it actually costs to deliver a unit of output over the deployment lifetime. Business value per unit of work. What the unit of output is worth to the organization that consumes it. These are not synonyms. They are not interchangeable. A candidate that ranks first on the first metric can rank third on the second and second on the third. A procurement decision benefits from clarity about which of the three it is optimizing — and treating the other two as measured inputs rather than as quietly equivalent. Is performance per dollar a deployment metric or a benchmarking artifact? Performance per dollar — usually expressed as throughput-per-acquisition-cost or similar — is the easiest of the three to calculate because both inputs are immediately available. The vendor publishes a price; the benchmark publishes a throughput; the ratio is the headline. Both come out of standard procurement workflows without additional measurement. The metric’s limitations show up quickly under scrutiny. Performance is workload-dependent — the throughput producing the ratio is measured on a specific workload at a specific configuration, and the same accelerator can be cost-leading on workload A and cost-trailing on workload B because performance is set by the AI Executor (hardware × software stack) and the workload, not by the silicon alone. PyTorch with TensorRT compilation produces a different throughput on the same GPU than PyTorch with default CUDA execution; the ratio inherits the choice. Acquisition cost is one component of cost — the denominator is the purchase price, but the cost of running the device (power, cooling, software licensing, operations staff, replacement cycle) is not in the calculation. The throughput is often a peak number — performance-per-dollar at peak conditions diverges from performance-per-dollar at deployment conditions, because deployment conditions are bounded by latency budgets, thermal envelopes, and realistic load profiles that peak benchmarks often don’t replicate. The metric is useful for a constrained question: at acquisition time, with no operating-cost considerations, which candidate produces the most throughput-per-purchase-dollar on this benchmark workload? When the procurement question is broader than that — and procurement questions usually are — the metric is a starting point, not the answer. Total cost of ownership measures what it costs to deliver work over time Total cost of ownership (TCO) per unit of work expands the denominator of the cost calculation to include the costs that accumulate over the deployment lifetime: Acquisition cost of the hardware. Power consumption at the deployment workload’s profile, integrated over the deployment lifetime. Cooling cost to dissipate that power. Software cost — runtime licenses, framework support contracts, any per-instance costs. Operations cost — staff time to maintain the deployment, replace failed units, handle upgrades. Replacement cost at end of useful life; this can be amortized into the per-unit cost. The numerator stays the same shape — units of work delivered — but the denominator becomes a much larger and more accurate accounting of what those units actually cost. The cost-leading option on TCO is often not the cost-leading option on acquisition price, particularly for high-utilization deployments where energy cost can match or exceed acquisition cost over the deployment lifetime. This is an observed pattern across high-utilization inference fleets, not a benchmarked rate — actual ratios depend on power pricing, utilization profile, and the specific accelerator. A cheaper accelerator with worse performance-per-watt can lose its cost advantage within months under continuous load: the cumulative energy bill exceeds the acquisition saving. A more expensive accelerator with better software-ecosystem support (mature TensorRT or Triton paths, robust cuDNN coverage, fewer custom kernels needed) can be cheaper on TCO because operational overhead is lower. These patterns do not appear in performance-per-dollar comparisons. The methodological consequence is that a procurement decision oriented to TCO needs measured per-workload power draw on the candidate hardware, not nameplate TDP, and needs the operating-cost components projected over the planning horizon under realistic utilization assumptions. We see the nameplate substitution often — it is the easy number to grab, and it consistently overstates the cost of efficient accelerators and understates the cost of inefficient ones at the workload profiles deployments actually run. (Our AI data-center power capacity planning article walks through why nameplate doesn’t work for capacity sizing — the same logic applies to TCO.) Business value measures what the work is worth, not what it costs The third metric is the one most often underweighted because it’s the hardest to measure. Business value per unit of work is what the inference output is worth to the organization that consumes it — revenue per inference, cost-per-incident-prevented, latency-sensitivity premium, user-engagement improvement, downstream conversion impact. Value matters because the cost-side metrics are only half of the trade-off calculation. A 30% cost reduction is uninteresting if it produces a 40% reduction in business value (because the cheaper option is slower, less accurate, or less reliable in ways that hurt the user-facing product). A 20% cost increase can be a clear win if it produces a 50% increase in business value. The numbers here are illustrative — the structural point is that cost and value move independently and have to be measured separately. The components that distinguish business value from cost: Latency premium. A faster system delivers better user experience, which can correlate directly with business outcomes (conversion, engagement, retention). Cost-per-inference at a 200ms p99 is not equivalent to cost-per-inference at a 50ms p99. Accuracy premium. A more accurate inference reduces downstream cost — fewer escalations, fewer reviews, fewer wrong actions. The cost saved downstream may exceed the cost differential of the more accurate option. Reliability premium. A system that fails less often has higher effective availability, and the cost of failures (reputation, lost transactions, recovery overhead) can be substantial. Capability premium. A platform that can run larger models, newer models, or more sophisticated inference patterns has option value that a more constrained platform doesn’t. Business value is harder to measure than cost but is often the metric that determines whether the cost-efficient choice was the right choice. A procurement decision that optimizes only the cost side is asserting that the business-value side is constant across candidates — an assertion that frequently doesn’t hold and that the procurement record should defend explicitly when it is being made. When each metric is the right one to optimize The three metrics support three different procurement framings: Question being asked Metric to optimize Evidence class What’s the lowest-acquisition-cost option that meets the requirement? Performance per dollar of acquisition benchmark (workload-scoped) What’s the lowest total-cost option over the deployment lifetime? TCO per unit of work observed-pattern + measured power What option produces the most business value per unit of cost? Business value per cost (with cost = TCO) observed-pattern, deployment-specific Procurement decisions in practice are usually some weighting of all three. The error to avoid is the implicit weighting — using performance-per-dollar as if it were TCO, or using TCO as if it were value. Each substitution embeds an assumption about the other dimensions, and the assumption is often wrong. The framing that produces durable choice is to compute all three explicitly, weight them according to the deployment’s actual priorities (high-volume cost-driven workloads weight TCO; user-facing latency-sensitive workloads weight value; capacity-constrained scenarios weight acquisition), and document the weighting as part of the procurement rationale. The weighting is itself part of the decision and benefits from being made visible. The operational expression here is that collapsing the three into one phrase obscures which question is being optimized, and a procurement decision that optimizes the wrong one produces hardware that scores well on the metric and poorly on the deployment. ## The framing that helps “Cost efficiency” collapses three different metrics — performance per dollar of acquisition, TCO per unit of work, business value per cost — that measure different things and rank candidates differently. Procurement decisions benefit from explicit clarity about which of the three is being optimized, with the others measured rather than assumed constant. Performance per dollar is useful at acquisition; TCO is useful for lifetime cost; value is useful for business-outcome optimization; the right weighting is deployment-specific and should be documented. LynxBench AI is built around treating throughput, energy, and accuracy as joint required disclosures on the production AI Executor under sustained workload — because cost efficiency in the procurement-relevant sense is computed from these inputs, not from a single performance-per-dollar number that hides which question it answers. The diagnostic question for the procurement is which of the three meanings of cost efficiency the decision is actually optimizing — and whether the other two are being measured or quietly assumed away. On the procurement file in front of you, which of the three meanings does the audit trail actually document — performance per acquisition dollar, TCO per unit of work, or business value per cost — and on what measured throughput, energy, and accuracy figures from the production AI Executor do the other two rest, rather than on assumptions that survive only until contact with deployment?
