From the SLO to the number of GPUs: how to size and justify the investment in inference hardware
Contents
Notation: amounts in N € or N USD (source denominated in dollars); decimal point; comma as thousands separator (
1{,}234). Generic example hardware: 4×H100 SXM5 80 GB nodes. The dollar sign is not used (it is the formula delimiter).
TL;DR
- With an SLO of TTFT P99 ≤ 300 ms and ITL P99 ≤ 50 ms for a production chat, peak GPU utilisation must stay at ≤ 63 %.
- A service receiving 5M requests/day with 512 input tokens and 256 output tokens on average generates an hourly peak of ~11,600 tok/s (with a peak factor of 1.8×). With vLLM on H100 SXM5 (Llama-3.3 70B FP8, ~1,850 tok/s at 50 concurrent requests), ≥ 10 GPUs are needed at peak to meet the SLO, which translates into 3 4×H100 nodes (with headroom).
- The all-in cost of those 3 nodes is ~83,300 € per year per node (3-year capex + base opex); the €/1M tokens in the base scenario at 63 % utilisation is ~0.37 €.
- Against AWS p5 on-demand (~3.90 USD/GPU-hour after the 44 % cut of Jun. 2025), the utilisation break-even sits at ~55 %; against neocloud on-demand (~2.01 USD/GPU-hour), there is no feasible break-even at medium utilisation.
- Capex payback happens between 13 and 24 months if sustained utilisation exceeds 70 %.
1. The sizing chain: from demand to the number of GPUs
Sizing an inference platform follows a causal chain of five steps. Each step has a formula; none can be skipped.
1.1 Step 1 — Characterise the demand
| Parameter | Symbol | Example |
|---|---|---|
| Requests per day (average) | \(D\) | 5,000,000 |
| Input tokens per request (average) | \(L_{\text{in}}\) | 512 |
| Output tokens per request (average) | \(L_{\text{out}}\) | 256 |
| Peak factor (peak hour vs average ratio) | \(k_{\text{peak}}\) | 1.8 |
| Hours per day with significant traffic | \(H\) | 16 |
The average output throughput:
$$\dot{T}_{\text{avg}} = \frac{D \times L_{\text{out}}}{86{,}400\,\text{s}} = \frac{5{,}000{,}000 \times 256}{86{,}400} \approx 14{,}815\;\text{tok/s}$$The peak throughput (busy hour):
$$\dot{T}_{\text{peak}} = k_{\text{peak}} \times \frac{D \times L_{\text{out}}}{H \times 3{,}600} = 1.8 \times \frac{5{,}000{,}000 \times 256}{16 \times 3{,}600} \approx 40{,}000\;\text{tok/s}$$Note: if the traffic profile has very pronounced peaks (peak/average ratio > 3), sizing is done for the peak and average utilisation falls; the sensitivity analysis in §5 quantifies the effect.
1.2 Step 2 — Set the SLO and derive the maximum utilisation
The latency SLO imposes a ceiling on GPU utilisation. Using queueing theory (M/G/1 model):
$$\rho_{\max} \approx 1 - \frac{1}{\sqrt{1 + C_{s}^{2}}} \cdot \frac{W_{\text{queue}}^{*}}{\bar{s}}$$where \(\rho\) is the utilisation, \(W_{\text{queue}}^{*}\) the maximum admissible queueing time and \(\bar{s}\) the average service time per request. For the simplified M/M/1 case with prefill time dominant:
$$\rho_{\max} = 1 - \frac{W_{\text{queue}}^{*}}{\bar{s} \cdot (1 + W_{\text{queue}}^{*}/\bar{s})}$$The practical reference table (derived from the Spheron/Little’s Law formula, 2026):
| SLO TTFT P99 | Maximum utilisation \(\rho_{\max}\) |
|---|---|
| 200 ms | 55 % |
| 300 ms | 63 % |
| 400 ms | 70 % |
| 500 ms | 75 % |
For our example (SLO 300 ms P99): \(\rho_{\max} = 0.63\).
The ITL SLO imposes an additional constraint: the inference engine must be able to generate the next token in ≤ 50 ms. On H100 SXM5 with vLLM and Llama-3.3 70B FP8, the ITL P50 at 50 concurrent requests is ~20 ms, with P99 ~45 ms. ITL is the dominant constraint only when the batch size is very high (>64 sequences) or VRAM is nearly full.
1.3 Step 3 — Required throughput and throughput per GPU
The throughput the cluster must serve at peak, while respecting \(\rho_{\max}\):
$$\dot{T}_{\text{required}} = \frac{\dot{T}_{\text{peak}}}{\rho_{\max}} = \frac{40{,}000}{0.63} \approx 63{,}500\;\text{tok/s (installed capacity)}$$The throughput per GPU (reference benchmark, vLLM v0.18.0, Llama-3.3 70B FP8, H100 SXM5 80 GB, 50 concurrent requests):
| Engine | Throughput (tok/s per GPU) | TTFT P50 / P95 (50 req) | Source |
|---|---|---|---|
| vLLM 0.18.0 | 1,850 | 380 ms / 720 ms | Spheron benchmarks, Mar. 2026 |
| SGLang 0.5.9 | 1,920 | 360 ms / 680 ms | Spheron benchmarks, Mar. 2026 |
| TensorRT-LLM 1.2.0 | 2,100 | 340 ms / 620 ms | Spheron benchmarks, Mar. 2026 |
The throughput data correspond to the test with Llama 3.3 70B Instruct FP8, 512 input / 256 output tokens, 50 concurrent requests, on bare-metal H100 SXM5. See the engine analysis in serving engines Pareto comparison.
We use vLLM as the general-purpose production reference: \(\dot{T}_{\text{GPU}} = 1{,}850\) tok/s.
1.4 Step 4 — Number of GPUs and number of nodes
$$N_{\text{GPU}} = \left\lceil \frac{\dot{T}_{\text{required}}}{\dot{T}_{\text{GPU}}} \right\rceil = \left\lceil \frac{63{,}500}{1{,}850} \right\rceil = \lceil 34.3 \rceil = 35\;\text{GPUs}$$With 4×H100 SXM5 nodes:
$$N_{\text{nodes}} = \left\lceil \frac{N_{\text{GPU}}}{4} \right\rceil = \left\lceil \frac{35}{4} \right\rceil = 9\;\text{nodes}$$We add 15 % headroom for hardware failures (~5 % annual rate in small clusters), upgrades and unforeseen peaks:
$$N_{\text{nodes, final}} = \lceil 9 \times 1.15 \rceil = 11\;\text{nodes} \approx 44\;\text{GPUs}$$For the TL;DR example (5M requests/day with a 16 h active profile, k 1.8 and an SLO of 300 ms) the number of nodes is 11. The simplified TL;DR case with k=1 and H=24 gives 3 nodes; the difference illustrates the impact of the hourly profile.
1.5 Summary of the chain
2. From sizing to cost: the TCO model
With \(N_{\text{nodes}} = 11\) 4×H100 SXM5 nodes, the TCO follows the model detailed in TCO of an on-premise GPU cluster. Here the compact formula is reproduced and applied to the sized cluster.
2.1 Annual cost per node (base scenario)
$$C_{\text{node/year}} = \frac{\text{node capex}}{\text{years}} + \text{node opex/year}$$| Line item | Value (USD / €) | Note |
|---|---|---|
| 4×H100 node capex (midpoint) | 178,500 USD | GPUs + server + network + storage + rack |
| 3-year amortisation | 59,500 USD/year ≈ 55,300 €/year | Straight line |
| Opex/year (base scenario, 8–16 node cluster) | ~28,000 €/year | Energy + staff + maintenance + colocation |
| Total per node per year | ~83,300 €/year | — |
For 11 nodes: 915,300 €/year of total fixed cost.
2.2 From €/node-year to €/GPU-hour
$$\text{EUR/GPU-hour} = \frac{C_{\text{node/year}}}{4\;\text{GPUs} \times 8{,}760\;\text{h} \times \rho}$$| Utilisation \(\rho\) | EUR/GPU-hour |
|---|---|
| 40 % | 5.93 |
| 55 % | 4.31 |
| 63 % (SLO 300 ms) | 3.76 |
| 70 % | 3.39 |
| 80 % | 2.97 |
| 100 % | 2.38 |
2.3 From €/GPU-hour to €/1M tokens
$$\text{EUR/1M tokens} = \frac{\text{EUR/GPU-hour} \times 10^{6}}{\dot{T}_{\text{GPU}} \times 3{,}600}$$With \(\dot{T}_{\text{GPU}} = 1{,}850\) tok/s (vLLM, Llama-3.3 70B FP8):
| Utilisation | EUR/GPU-hour | EUR/1M tokens |
|---|---|---|
| 40 % | 5.93 | 0.891 |
| 55 % | 4.31 | 0.647 |
| 63 % (SLO 300 ms) | 3.76 | 0.564 |
| 70 % | 3.39 | 0.509 |
| 80 % | 2.97 | 0.446 |
| 100 % | 2.38 | 0.357 |
The complete cost/token identity as a function of throughput and utilisation is developed in cost per token and per request.
2.4 Comparison with cloud (equivalent €/1M tokens)
To compare, the cloud price is converted to the €/1M tokens equivalent using the same reference throughput (\(\dot{T}_{\text{GPU}} = 1{,}850\) tok/s):
$$\text{EUR/1M tokens (cloud)} = \frac{P_{\text{cloud}} \times 10^{6}}{1{,}850 \times 3{,}600}$$| Provider / Mode | GPU-hour price (USD) | EUR/GPU-hour (\(1\,\text{USD} \approx 0.93\,\text{EUR}\)) | EUR/1M tokens equiv. |
|---|---|---|---|
| AWS p5 on-demand (post Jun. 2025) | 3.90 | 3.63 | 0.545 |
| AWS p5 1-year reserved | ~2.50 | 2.33 | 0.350 |
| CoreWeave on-demand | ~2.01 | 1.87 | 0.281 |
| CoreWeave 3-year reserved | ~1.49 | 1.39 | 0.209 |
| GCP A3 on-demand | ~3.67 | 3.41 | 0.512 |
| Azure ND H100 v5 on-demand | ~6.98 | 6.49 | 0.975 |
Sources: IntuitionLabs (Jun. 2026), CloudZero (Jun. 2026), Spheron GPU pricing (May 2026).
3. Break-even and payback of your own investment
3.1 The utilisation break-even formula
The utilisation break-even \(u^{*}\) is the utilisation at which the annual on-prem cost per GPU-hour equals the cloud price:
$$u^{*} = \frac{\text{capex/year} + \text{opex/year}}{4 \times 8{,}760 \times P_{\text{cloud}}}$$where \(P_{\text{cloud}}\) is the cloud price in the same currency as the on-prem costs.
With the base scenario (capex/year 55,300 €, opex/year 28,000 €, total 83,300 €/node/year):
| Cloud reference | Cloud price (EUR/GPU-hour) | \(u^{*}\) break-even |
|---|---|---|
| Azure on-demand (~6.49 EUR) | 6.49 | 23 % |
| AWS on-demand post-cut (~3.63 EUR) | 3.63 | 41 % |
| GCP on-demand (~3.41 EUR) | 3.41 | 44 % |
| CoreWeave on-demand (~1.87 EUR) | 1.87 | 80 % |
| CoreWeave 3-yr reserved (~1.39 EUR) | 1.39 | >100 % (impossible) |
| AWS 1-yr reserved (~2.33 EUR) | 2.33 | 64 % |
3.2 Capex payback
Payback is the time \(T_{\text{pay}}\) in which the cumulative saving against cloud equals the initial capex:
$$T_{\text{pay}} = \frac{\text{total cluster capex}}{(\text{cloud cost/year}) - (\text{on-prem opex/year})}$$where the cloud cost/year is computed at the same sustained utilisation.
For the 11-node cluster (total capex 11 × 178,500 USD ≈ 1,825,000 USD ≈ 1,697,000 €):
| Cloud reference | Sustained utilisation | Annual saving vs cloud | Payback |
|---|---|---|---|
| AWS on-demand (3.63 EUR/h) | 70 % | (3.63 − 3.39 EUR) × 4 × 8760 × 0.70 × 11 nodes ≈ 63,900 €/year | ~27 months |
| AWS on-demand (3.63 EUR/h) | 80 % | (3.63 − 2.97) × 4 × 8760 × 0.80 × 11 ≈ 203,600 €/year | ~10 months |
| GCP on-demand (3.41 EUR/h) | 70 % | (3.41 − 3.39) × 4 × 8760 × 0.70 × 11 ≈ 5,400 €/year | ~315 months (not viable) |
| Azure on-demand (6.49 EUR/h) | 70 % | (6.49 − 3.39) × 4 × 8760 × 0.70 × 11 ≈ 830,000 €/year | ~2 months |
The 13-month payback quoted in studies such as Lenovo TCO 2026 corresponds to ~80 % utilisation against high-priced hyperscalers (Azure/AWS before the cut). With current prices (post June 2025, AWS at 3.90 USD), the window widens.
3.3 Simple payback (capex only vs equivalent cloud)
If on-prem opex is omitted and only capex is compared with the gross saving:
$$T_{\text{pay,simple}} = \frac{\text{capex}}{P_{\text{cloud}} \times 4 \times 8{,}760 \times \rho \times N_{\text{nodes}}}$$| Utilisation | AWS (3.63 EUR) | Azure (6.49 EUR) |
|---|---|---|
| 50 % | 54 months | 30 months |
| 70 % | 39 months | 22 months |
| 80 % | 34 months | 19 months |
4. Decision table: when to buy, rent or go hybrid
The table below is a five-dimension Pareto. There is no implicit order between columns; the reading depends on the organisation’s constraints.
| Option | EUR/GPU-hour (util. 70 %) | Initial capex | Required utilisation | Data sovereignty | Peak elasticity |
|---|---|---|---|---|---|
| On-prem purchase, util. ≥ 70 % | 3.39 | high (178k USD/node) | ≥ 70 % sustained | total | none |
| On-prem purchase, util. < 50 % | > 4.75 | high | < 50 % → loses vs cloud | total | none |
| Sovereign EU cloud OD (Scaleway/Nebius EU) | 2.00–3.59 | none | any | yes (EU) | total |
| AWS p5 on-demand (post Jun. 2025) | 3.63 | none | any | no (CLOUD Act) | total |
| CoreWeave on-demand | 1.87 | none | any | partial (US) | total |
| CoreWeave 3-year reserved | 1.29–1.39 | financial commitment | rigid contract | partial (US) | none |
| AWS 1-year reserved | ~2.17 | 1-year commitment | contract | no (CLOUD Act) | none |
| Hybrid on-prem base + EU cloud peak | 2.50–3.39 (weighted) | medium | base ≥ 70 %, elastic peak | yes (EU) | elastic peak |
Cut-off criteria that come before the table:
- GDPR sovereignty: if the data is personal or the system is high-risk under the EU AI Act, CoreWeave/AWS are ruled out before any price comparison.
- Minimum volume to amortise capex: below ~2M tokens/day sustained over 3 years, on-prem capex does not amortise against AWS on-demand.
- Traffic elasticity: peaks >3× the base favour a hybrid or pure cloud; a stable base favours on-prem.
The cost/sovereignty Pareto frontier for GDPR data leaves three options: on-prem, sovereign EU cloud and hybrid. Sustained utilisation and traffic predictability decide between them. See the cross-analysis of the four axes in sovereign on-premise vs hyperscalers.
5. Sensitivity analysis
5.1 Sizing vs hourly profile and peak factor
The number of GPUs grows linearly with \(k_{\text{peak}}\) and inversely with \(\rho_{\max}\):
$$N_{\text{GPU}} = \left\lceil \frac{D \times L_{\text{out}} \times k_{\text{peak}}}{H \times 3{,}600 \times \rho_{\max} \times \dot{T}_{\text{GPU}}} \right\rceil$$| Peak factor \(k\) | SLO 300 ms (\(\rho_{\max}=0.63\)) | SLO 500 ms (\(\rho_{\max}=0.75\)) |
|---|---|---|
| 1.2 | 8 GPUs (2 nodes) | 6 GPUs (2 nodes) |
| 1.8 | 12 GPUs (3 nodes) | 10 GPUs (3 nodes) |
| 2.5 | 16 GPUs (4 nodes) | 13 GPUs (4 nodes) |
| 3.5 | 22 GPUs (6 nodes) | 18 GPUs (5 nodes) |
(Example simplified to 5M req/day with H=24 to illustrate the sensitivity to the peak factor)
A peak factor of 3.5× triples the number of nodes compared with k=1.2 at the same SLO. Sizing hardware for \(k > 2.5\) leaves GPUs idle more than 70 % of the time; peak cloud is more efficient beyond that threshold.
5.2 Break-even vs sustained utilisation
$$u^{*} = \frac{83{,}300}{4 \times 8{,}760 \times P_{\text{cloud}}}$$| Cloud price (EUR/GPU-hour) | \(u^{*}\) break-even | Scenario |
|---|---|---|
| 6.49 (Azure OD) | 23 % | On-prem wins almost always |
| 3.63 (AWS OD) | 41 % | On-prem wins if util. > 41 % |
| 3.41 (GCP OD) | 44 % | — |
| 2.33 (AWS 1-yr reserved) | 64 % | On-prem wins if util. > 64 % |
| 1.87 (CoreWeave OD) | 80 % | Hard to reach in production |
| 1.39 (CoreWeave 3-yr reserved) | >100 % | On-prem never closes the gap |
5.3 Break-even vs energy price
Energy accounts for 6–11 % of total TCO. Its impact on the break-even is moderate:
| Energy price (EUR/kWh) | Energy opex/year per node | EUR/GPU-hour (70 % util.) | \(u^{*}\) vs AWS OD |
|---|---|---|---|
| 0.034 (solar PPA) | 1,604 € | 3.22 | 38 % |
| 0.116 (industrial ES, base) | 5,475 € | 3.39 | 41 % |
| 0.200 (high tariff) | 9,437 € | 3.57 | 43 % |
The difference between the cheapest and the most expensive scenario is only 5 percentage points of break-even. The variable that moves the needle is utilisation, not energy.
5.4 Break-even vs demand growth
If demand grows at an annual rate \(g\), the average utilisation of the cluster (sized for year 1) rises over time until it saturates and has to be expanded:
$$\rho(t) = \rho_{0} \times (1 + g)^{t}$$| Annual growth \(g\) | Time to saturation (\(\rho \to 100\,\%\)) | Decision |
|---|---|---|
| 10 % | ~11 years | Comfortable purchase |
| 30 % | ~4 years | Purchase with a review at 3 years |
| 60 % | ~2 years | Hybrid: base + elastic cloud |
| >100 % | <1 year | Pure cloud until it stabilises |
For growth above 30 % per year, a buy-only strategy means oversizing for the future peak or re-buying hardware in short cycles. The hybrid (on-prem base + cloud for growth) minimises the capex at risk.
5.5 Headroom: the cost of the safety margin
The 15 % headroom in \(N_{\text{nodes}}\) amounts to having ~1.6 extra nodes on average. Its annual cost is:
$$C_{\text{headroom}} = 0.15 \times 83{,}300\;\text{EUR/node/year} \times N_{\text{nodes,base}} \approx 12{,}500 \times 9 = 112{,}500\;\text{EUR/year}$$That cost is justified by:
- GPU failure rate ~5 % per year (in small clusters, documented by Introl, Apr. 2026)
- Replacement time of 2–8 weeks (depending on market availability)
- Unforeseen peaks of up to 20 % above the estimate
If the service can degrade gracefully (relaxing the TTFT SLO from 300 ms to 500 ms at extreme peak), headroom can be cut to 10 %, saving ~37,500 EUR/year.
6. Sensitivity map: €/GPU-hour and break-even on two axes
The table below crosses utilisation with the opex scenario, showing the all-in EUR/GPU-hour (base scenario, capex/year 55,300 €):
| Low opex (13,000 €/year) | Base opex (28,000 €/year) | High opex (75,000 €/year) | |
|---|---|---|---|
| Util. 40 % | 4.74 | 5.93 | 9.06 |
| Util. 55 % | 3.45 | 4.31 | 6.59 |
| Util. 63 % | 3.01 | 3.76 | 5.75 |
| Util. 70 % | 2.71 | 3.39 | 5.18 |
| Util. 80 % | 2.37 | 2.97 | 4.54 |
| Util. 100 % | 1.90 | 2.38 | 3.63 |
The crossing point with the cloud price (AWS OD: 3.63 EUR):
- Low-opex scenario: break-even at ~38 % utilisation
- Base-opex scenario: break-even at ~41 % utilisation
- High-opex scenario: break-even at ~53 % utilisation
The biggest lever for lowering the break-even is not hardware capex but opex (staff and colocation above all). See the analysis of utilisation as a FinOps lever in GPU utilisation as FinOps.
7. Integration with the rest of the FinOps chain
The sizing of §1 determines the number of nodes; the TCO of §2 gives the cost per hour; the comparison of §3 gives the break-even. Those three numbers feed directly into the other instruments of the series:
| Instrument | Input from this article | Output |
|---|---|---|
| GuideLLM — SLO validation under load | TTFT/ITL P99 SLO from step 2 | Experimental confirmation of the real throughput per GPU |
| Capacity planning for on-premise inference | Demand profile and N GPUs from step 4 | Scaling policy and autoscaling triggers |
| Cost per token and per request | EUR/GPU-hour from step §2.2 | EUR/1M tokens per model and batching |
| Cloud GPU commitment and spot | Cloud prices from table §2.4 | Optimisation of the complementary cloud tier |
| Sovereign on-premise vs hyperscalers | Break-even from §3 | Final buy/rent decision including the sovereignty axis |
| TCO of an on-premise GPU cluster | Capex and opex from §2.1 | Detailed TCO model with every line item |
| GPU utilisation as FinOps | Target utilisation from step 2 | Scheduling levers to raise real utilisation |
Sources
- Spheron · LLM Inference SLO Engineering: TTFT, ITL, and P99 Latency Budgets for Production AI (2026) — https://www.spheron.network/blog/llm-inference-slo-ttft-itl-latency-budget-guide-2026/
- Spheron · vLLM vs TensorRT-LLM vs SGLang: H100 Benchmarks (2026) — https://www.spheron.network/blog/vllm-vs-tensorrt-llm-vs-sglang-benchmarks/
- Spheron · GPU Cloud Pricing 2026: H100 from 1.03 USD/hr, B200 from 2.12 USD/hr — https://www.spheron.network/blog/gpu-cloud-pricing-comparison-2026/
- Spheron · LLM Inference On-Premise vs GPU Cloud: 2026 Cost and Break-Even Analysis — https://www.spheron.network/blog/llm-inference-on-premise-vs-cloud/
- MLPerf Inference v5.1 — Red Hat: 5 777 tok/s (offline) en Llama 3.1-8B FP8 en H100 — https://www.redhat.com/en/blog/efficient-and-reproducible-llm-inference-red-hat-mlperf-inference-v51-results
- MLPerf Inference v6.0 Results Explained: GPU Performance Rankings for AI Workloads (2026) — https://www.spheron.network/blog/mlperf-inference-v6-benchmark-results-2026/
- IntuitionLabs · H100 Rental Prices Compared: 1.49–6.98 USD/hr Across 15+ Cloud Providers (2026) — https://intuitionlabs.ai/articles/h100-rental-prices-cloud-comparison
- CloudZero · Cloud GPU Pricing Comparison: AWS vs Azure vs GCP For AI Workloads (2026) — https://www.cloudzero.com/blog/cloud-gpu-pricing-comparison/
- Lenovo Press · On-Premise vs Cloud: Generative AI Total Cost of Ownership (2026 Edition) — https://lenovopress.lenovo.com/lp2368-on-premise-vs-cloud-generative-ai-total-cost-of-ownership-2026-edition
- Introl · GPU Infrastructure TCO Model: 5-Year Cost Analysis for Enterprise AI (abr. 2026) — https://introl.com/blog/gpu-infrastructure-tco-5-year-cost-model
- GMI Cloud · NVIDIA H100 GPU Pricing 2026: Rent vs Buy Cost Analysis — https://www.gmicloud.ai/en/blog/nvidia-h100-gpu-pricing-2026-rent-vs-buy-cost-analysis
- Red Hat · 233 % 3-year ROI and 13 months to payback with Red Hat AI (feb. 2026) — https://www.redhat.com/en/blog/233-3-year-return-investment-and-13-months-payback-red-hat-ai
- VentureBeat · 5 % GPU utilization: the 401 billion USD AI infrastructure problem — https://venturebeat.com/infrastructure/5-gpu-utilization-the-401-billion-ai-infrastructure-problem-enterprises-cant-keep-ignoring/
- DZone · Queueing Theory for LLM Inference — https://dzone.com/articles/queueing-theory-for-llm-inference
- GuideLLM · Evaluate LLM deployments for real-world inference (Red Hat Developer, jun. 2025) — https://developers.redhat.com/articles/2025/06/20/guidellm-evaluate-llm-deployments-real-world-inference