HomeEngineering

QUANTITATIVE ENGINEERING

More healthy hours.
More useful work.

The technical model has two independent levers: productive GPU-hours and inference throughput. Explore how they compound before applying them to your own fleet.

INTERACTIVE PLANNING MODEL

Performance gains scale
with productive capacity.

Adapted from the technical deck’s two-axis model. Output is normalized so hardware count and token pricing do not obscure the relationship.

Output index: 100 represents all installed GPU-hours doing productive work at baseline throughput. Faster inference can produce an index above 100.

Baseline inference1.30× performance assumption
Productive capacity and normalized inference outputAt 80 percent productive capacity and a 1.3 times performance assumption, normalized output increases from 80 to 104. These are calculated scenarios, not benchmark results.Productive GPU-hours / installed GPU-hoursNormalized output index
BASELINE INDEX80
→
MODELED INDEX104
INDEX GAIN+24
30%100%
1.00×1.50×
THE RELATIONSHIP

Productive hours
× tokens per productive hour
= inference output

Assumptions: Same workload, quality and latency. Sufficient demand to use the output. The 1.3× factor is a planning assumption. The 1.5× endpoint is exploratory upside, not a validated result.

View calculation and source notes

Output index = productive capacity (%) × performance multiplier. Baseline performance = 1.0×. At 40% capacity, 1.3× performance yields 52 versus 40. At 80%, it yields 104 versus 80. Index 100 means 100% productive capacity at baseline throughput, so faster inference can exceed 100.

Adapted from Xid0’s “From Racks to Tokens” technical architecture deck, October 23, 2026, slides 24–25 and 34–35. The original chart includes revenue and exploratory kernel scenarios. This version shows normalized output, without a token-price assumption. No values on this chart are Xid0 customer measurements.

Reference cases at 1.3× performance
CapacityBaselineScenarioGain
40%4052+12
80%80104+24

KEEP THE DENOMINATOR VISIBLE

Availability and productivity
answer different questions.

DELIVERED CAPACITY

Healthy, at-spec GPU-hours
÷ GPU-hours sold

Are customers receiving the capacity they bought?
PRODUCTIVE CAPACITY

GPU-hours doing paid work
÷ installed GPU-hours

How much of the installed fleet is earning?

ENGINEERING TARGETS

Designed to be tested.

Reference targets from the architecture plan.
Actual pilot thresholds are agreed after baseline measurement.

Swipe the table to see evaluation methods.

Xid0 engineering targets and validation methods
MetricDesign targetEvaluation method
Fault detection<60 sTime from an agreed fault event to an actionable detection.
Capacity restoration≤15 minApproved scenario with spare capacity and a verified recovery path.
Slow-GPU detection<1 dayKnown degradation scenarios compared with operator findings.
False-positive rate<1%Shadow-mode review against agreed labels and denominator.

Targets, not achieved performance or contractual SLAs. Source: Xid0 technical architecture deck, slides 10, 12 and 17. Xid0 customer validation is pending.

TAKE IT TO YOUR FLEET

Turn assumptions
into an evaluation.

Agree on the workload, quality, latency and operational boundaries before comparing results.

See the evaluation approach