Reporting methodology

How we estimate energy

Every figure marked est. is accelerator energy during a request’s run time. Facility overhead, such as cooling, is left out.

See the benchmark Jump to the worked example
Reading one figureDispatch-200 · Budgeted

50 Wh est. / 200 requests

  1. 50 The sum of each request’s estimate in the workload.

  2. Wh Watt hours of accelerator energy, nothing upstream.

  3. est. Calculated from a hardware profile, not metered.

  4. / 200 The workload it covers, under one policy.

One line drawn around the accelerator

The estimate covers what a route choice changes: accelerator energy while the request runs. The rest stays outside.

System boundary for one request Inside the estimateOutside
  1. Client devicesoutside
  2. Networkoutside
  3. Joulis gatewayoutside · latency timed here

Data centre facility outside

  • Cooling
  • Power conversion

Server host outside

  • Host CPU and memory
  • Storage

Inside the estimate · Wh est.

Accelerators

During this request’s run time

P × u × t

Why the line sits here. Routes differ at the accelerator: a smaller model holds the hardware for less time, and that is the change a policy makes.

Why it goes no wider. Cooling, networks and devices vary by site and by user, not by route. Adding them would blur the comparison.

From hardware profile to a workload total

Three inputs per request, one product, one sum per workload. Each step pairs the formula with plain words.

  1. 01
    P = rated accelerator powerGannet-L 8 × 600 W = 4,800 W

    Hardware profile

    The rated power of the accelerators that serve a route, taken from the route’s declared hardware profile.

  2. 02
    u = request tokens ÷ batch tokensGannet-L u = 0.25

    Utilization share

    Accelerators serve many requests at once. Each request carries its share of the work in the batch it ran in.

  3. 03
    t = processing time, in secondsGannet-L t = 1.2 s

    Run time

    How long the accelerators worked on the request, as the provider reports it in the response.

  4. E = P × u × t ÷ 3,600Gannet-L 4,800 × 0.25 × 1.2 ÷ 3,600 = 0.40 WhGannet-S 3,200 × 0.25 × 0.9 ÷ 3,600 = 0.20 Wh

    Per request

    Watts times seconds gives joules; dividing by 3,600 gives watt hours. The result is an estimate, so it carries the est. mark.

  5. 04
    E workload = Σ E requestevery request, route by route

    Sum per workload

    Add each request’s estimate across the workload. Routes are summed, never averaged together.

Worked example

Dispatch-200 · 200 requests · ceiling ≤ 60 Wh

Budgeted

Under the ceiling

150 × 0.20 Whest.Gannet-S + 50 × 0.40 Whest.Gannet-L = 50 Whest.

Baseline

Over the ceiling

200 × 0.40 Whest.Gannet-L = 80 Whest.

37.5% lower estimated batch energy for Budgeted on this test. Accelerator energy only; facility overhead left out.

The assumptions behind every estimate

Each rule, why it holds, and which way it moves the figure. A changed rule ships as a new method version.

Assumption Value or rule Why Effect on the estimate
Hardware profile Rated board power of the route’s accelerators, declared per route A stable figure a provider can confirm Leans highRated power sits above typical draw
Utilization share Request tokens ÷ tokens in the same batch steps One accelerator serves many requests at once NeutralBusier batches lower each share
Run time Provider-reported processing time; gateway latency when it is missing Only accelerator time belongs in the figure Leans highGateway latency includes the network
Idle power Not attributed to any request Idle time follows fleet scheduling, not the route Leans lowA metered total would read higher
Facility overhead Left out; no PUE multiplier applied It varies by site, not by route Leans lowCooling and power conversion are not counted
Retries and fallbacks Each attempt counts as its own request Every attempt used accelerator time NeutralA retried request adds a full estimate
Rounding 0.01 Wh per request, 1 Wh per workload, summed before rounding No more precision than the inputs carry NeutralA total can differ from a hand sum by under 1 Wh
Versions Each estimate records its profile and method version Figures stay comparable after a profile changes NeutralCompare only estimates on the same versions

Sample profiles on this page: Gannet-S 3,200 W (8 × 400 W), Gannet-L 4,800 W (8 × 600 W). Declared values, not measurements.

Measured, scored and estimated

Three kinds of figure, three kinds of evidence. Quote each one with its condition attached.

  • Measured

    latency

    1.4s p95

    Timed at the Joulis gateway for every request, from request received to response complete. Reported as the 95th percentile.

    Supports

    • Checking a latency ceiling
    • Comparing routes on the same path

    Cannot support

    • Time your users see past the gateway

  • Scored

    rubric

    90/100

    Each output scored on one fixed rubric, the same for every route and policy. The workload score is the mean.

    Supports

    • Checking a quality floor
    • Comparing policies on the same tasks

    Cannot support

    • Quality on other tasks or rubrics
    • The correctness of any one answer

  • Estimated

    energy

    50Whest.

    Calculated from hardware profile, utilization share and run time. Accelerator energy only, facility overhead left out.

    Supports

    • Checking an energy ceiling
    • A relative change on one test, such as 37.5% lower

    Cannot support

    • Metered or facility energy
    • Carbon or site-wide totals

Quote it with its conditions

50 Wh est. per 200 requests · Dispatch-200, Budgeted · accelerator energy only, facility overhead left out

See the benchmark
Soft rolling hills at first light, layers of mist in the valleys and a faint warm glow on the horizon

Put a budget on your next rollout

Bring one workload. We will run it under your policy and show you what each route delivers and consumes.

Request access See the benchmark