The methodology

How the Index is built.

The Sorso View Compute Index measures public on-demand H100 SXM 80GB pricing across the twenty-seven-provider panel, then converts included observations into tier medians, weighted coverage, opacity, and a base-100 weekly composite.

The Sorso View Compute Index is a constructed weekly benchmark. It starts with public provider pricing, applies a fixed inclusion gate, normalizes included observations to USD per GPU-hour, calculates tier medians, and combines those medians into a base-100 index. This page states the method used across Issues 001 through 004 and the secondary metrics that appear in the issue pages.

Version note. This methodology page was clarified after Issue 004 to make the formulas explicit. The clarification does not change any published SVCI level, tier median, Coverage Score, Compute Opacity Index, or provider ruling. It closes two wording ambiguities: issue capture windows are recorded in each issue's data layer, and secondary readings are defined separately from the headline SVCI.

Every benchmark of consequence does the same thing. It takes raw inputs the world produces in disorder and constructs from them a single number the world can cite. The S&P 500 is not a list of five hundred stock prices. The Consumer Price Index is not a survey of grocery receipts. Case-Shiller is not the average sale price of homes. Each is a method, a particular way of weighting, normalizing, and combining inputs, that turns noise into signal. The method is the asset. The number is the output.

The Sorso View Compute Index applies that principle to public AI compute pricing. Twenty-seven providers. Three tiers. A fixed launch baseline. A public evidence trail. The result is not a quote and not a procurement recommendation. It is a weekly public-price benchmark.

What the Index measures.

The Index measures public, on-demand rental pricing for the NVIDIA H100 SXM 80GB anchor configuration, normalized to USD per GPU-hour, across the twenty-seven-provider panel. When a provider only publishes a multi-GPU instance price, the instance price is divided by the number of GPUs to produce a per-GPU equivalent. That equivalent is a comparison unit, not a claim that the provider sells a single GPU from that node.

The measured layer is the public leverage layer: the visible rate card, public price page, or public pricing table that buyers can point to before negotiation. Private contract prices, reserved-capacity prices, spot markets, inference-token prices, and alternative-silicon prices are not blended into the headline SVCI.

The provider panel.

The headline panel contains twenty-seven providers in three fixed tiers. Tier 1 contains four hyperscalers. Tier 2 contains eighteen NVIDIA GPU clouds and neoclouds. Tier 3 contains five marketplace, aggregator, or market-clearing surfaces. The tier assignment controls the denominator for coverage and the tier median used in SVCI.

The capture window.

Each issue has a fixed pre-publication capture window, and the exact run dates are recorded in that issue's data layer. Issue 001 used its launch capture window. Issue 004 used a June 28 to July 1 capture window. Once the analytical layer is locked, later provider-page movement is handled in the next issue or through a formal correction trigger.

Source pages are captured directly from provider surfaces when possible. Public logged-out pages are preferred. Signed-in pages, API payloads, and supplemental context may support a ruling, but they do not override a public-source inclusion gate unless the issue explicitly says so.

The inclusion gate.

A provider enters a tier median only when it publishes a comparable public H100 SXM 80GB on-demand rate, or a fixed public instance-hour rate that can be normalized to a per-GPU-hour equivalent. The rate must be attributable to the provider's own public surface, be current during the capture window, and be clear enough to reproduce.

The following are captured but excluded from medians: quote-only prices, contact-sales gates, reserved or committed-use prices, spot or interruptible prices, starting-from floors, host-variable marketplace prices, auction prices, aggregator pass-through prices, incompatible product modes, private-console-only observations, and public pages that do not identify the anchor configuration clearly.

A public promotional on-demand price may enter only if it is presented as the current public on-demand rate and is not conditional on a commitment term. Paperspace in Issue 004 is the controlling example: the visible 3-year commitment rate was rejected, while the provider's footnote-attested public on-demand H100 rate was included.

Tier 3 and marketplace observations.

Tier 3 exists because marketplaces and aggregators are economically important, but Tier 3 status does not automatically make marketplace prices comparable. A Tier 3 observation still has to clear the inclusion gate. Fixed public rates from a provider-controlled surface can enter. Host-set floors, live marketplace offers, percentile distributions, provider-pass-through cards, and rates that vary by host are evidence, not median inputs.

The issue may explicitly admit a Tier 3 marketplace observation only by naming the observation, the statistic used, and the reason it is comparable. No such exception was invoked for Vast.ai, TensorDock, or Shadeform in Issue 004. RunPod and Paperspace entered because the issue record treated their captured rates as fixed public on-demand rates; Vast.ai, TensorDock, and Shadeform were captured-excluded because their surfaces were marketplace, host-variable, or aggregator pass-through.

The SVCI formula.

Each tier median is calculated from included observations in that tier. The median is used because public AI compute pricing has outliers, gaps, and mixed product surfaces. Averages would overreact to extremes and to temporary availability artifacts.

Issue 001 base medians: T1 10.5306, T2 3.55, T3 4.62.

Locked tier weights: T1 0.45, T2 0.45, T3 0.10.

Tier index: current tier median divided by the Issue 001 base tier median, times 100.

SVCI: 0.45 times the T1 index, plus 0.45 times the T2 index, plus 0.10 times the T3 index.

The weights are not renormalized when coverage changes. If a provider is captured-excluded, it does not enter the median, but it still affects the Coverage Score and Compute Opacity Index through the fixed tier denominator. That is why a loss of comparable public coverage can move the index even when matched-provider prices are unchanged.

Coverage and opacity metrics.

Coverage is tier-weighted. It is not priced providers divided by twenty-seven. The denominators are fixed at T1 4, T2 18, and T3 5. The formula is: 0.45 times T1 included over 4, plus 0.45 times T2 included over 18, plus 0.10 times T3 included over 5.

The Compute Opacity Index is 100 times one minus Coverage. In Issues 001 and 002, ten of eighteen Tier 2 providers and two of five Tier 3 providers cleared the gate, producing Coverage 0.7400 and COI 26.0. In Issues 003 and 004, nine of eighteen Tier 2 providers and two of five Tier 3 providers cleared the gate, producing Coverage 0.7150 and COI 28.5. The flat excluded share, such as 12 out of 27 in Issue 004, is audit-only and is not the COI.

Secondary readings.

The issue pages publish secondary readings that help readers interpret the market. They are not the SVCI and do not change the headline composite.

What the Index does not measure.

The Index does not measure private contract pricing. Negotiated rates between named providers and named customers are confidential and often materially different from public list. Hyperscale committed-use customers commonly pay below list, sometimes materially so for multi-year capacity agreements. The Index does not infer those numbers.

The Index does not blend reserved pricing, committed-use pricing, bundled enterprise agreements, spot markets, per-token inference prices, or alternative-silicon pricing into the headline composite. Those markets are covered editorially or in companion work only when their source basis is clear and separately labeled.

Corrections and version control.

A correction changes a published record only when a source, rate, inclusion ruling, derivation, or package artifact is proven wrong. Corrections are public and dated. Clarifications that make formulas more explicit without changing issue outputs are marked as methodology clarifications. Issue 004 v1.2.7, for example, did not change any rate or index value; it only clarified methodology wording and site consistency.

Every issue links to its data layer, calculation report, capture ledger, and evidence manifest where those artifacts are public. The data layer is the source of truth for rows and numeric calculations. The issue page is the public reading layer. The methodology page explains the rules that connect them.

How the publication is funded.

Sorso View takes no affiliate, referral, or transaction fees from the providers it measures. No provider can pay to be included, ranked differently, or reviewed. The publication is funded by readers, data products, research products, licensing, and buyer-side tools. That separation is structural, and it is why the benchmark can be cited.

How to read an issue.

Start with the SVCI level and the change from the prior issue. Then read the tier medians to see where the movement came from. Then read Coverage and COI to see how much of the public market resolved to a comparable rate. Finally, read the issue notes, because the movement can come from a price change, a coverage change, a product-surface change, or a panel governance event.

The Index is built to be cited for years. The standard is simple: every number should be defensible on the page, in the data, and in the evidence record behind it.