# Not All GPU's Are Deployed The Same — Oliver Kennon — session 2026-10-14T15:05:00.000Z → 2026-10-14T15:23:00.000Z

_43 transcript lines · 52 slides · source: full recording_

## Transcript

**[00:00:36 · 0]** Not all GPUs are deployed the same. Thank you, everyone, for taking the time to be here today. My name is Oliver Kenan. I'm a research analyst at Semianalysis. Time and attention are the most valuable things any of us have, unless, of course, you're an early stage investor in OpenAI or Entropic.

**[00:00:55 · 0]** With that, let's get into it. Not all GPUs are deployed the same. A GPU falls to the level of the operator. Buying hardware gives you potential. Operating capability is what determines how much useful work you actually are able to deliver.

**[00:01:11 · 0]** That leads us to the question I will attempt to answer with all of you today, who can produce the intelligence you need at the lowest cost? Cost matters. Who... In today's presentation, I want to show you guys why and how operating capability changes that cost and why it matters in the commodity market that is compute. What matters in a commodity market?

**[00:01:35 · 0]** A lot of tech investors or technologists may not be familiar with this framework, so little crash course. In a commodity market, producers compete to deliver comparable output. A lower production cost gives more room to compete when prices fall. That's what a cost curve shows, producers lined up by what they spend to deliver the same usable work. If two producers earn the same price, the one spending less to deliver the work gets to keep more of it.

**[00:02:03 · 0]** Pretty simple. Right? For us, intelligence is the economic output we care about. Eventually, our North Star metric will be price per successfully completed task at the required quality. Unfortunately, we're not quite there yet.

**[00:02:18 · 0]** That's a pretty hard thing to standardize. Today, price per token is a useful practical proxy, especially for comparable workloads and quality requirements and gets us closer to delivered output, much closer than the often quoted, all you finance bros out here will have heard this, GPU, dollar per hour price, or as we view it, a cost. We view GPU hours as a measure of input, not output, the cost versus price distinction. Customer prices are different from the producer's cost of doing the work. GPU hours are the input.

**[00:03:00 · 0]** Intelligence is the output. On this slide, we can visualize the inputs needed to create useful intelligence. We start with hardware and electricity, GPUs, for the the... This presentation. Software and operations can be thought of as a multiplier on those first two inputs with the end product being useful intelligence.

**[00:03:23 · 0]** The operator is who chooses and implements the software that serves the model and keeps requests moving through the system. The machines might be available, but you still need someone to make them deliver responses customers can actually use. What matters is how much useful work you get and whether it meets your requirements for the specified task. The conversion can differ with the same kind of chip. Let's look at that in the measured example.

**[00:03:51 · 0]** Here's a concrete example from our InferenceX, public InferenceX calculator. You guys can all check it out, seminalysis.com. Both estimates use B200 GPUs serving the same model with roughly 8,000 input tokens and 1,000 output tokens, a pretty standard ratio. The p 50 target is 100 output tokens per second for each user. The serving stack is the software handling the model's responses.

**[00:04:17 · 0]** In the p 90 scenario, one of these stacks gives about 200 generated output tokens per second while the other one gives about 300. That's a big difference and comes down to software, settings, and number of requests running, all choices made by the operator. Same chip, same target interactivity, about 50% more output. That's a lot. So what does that mean for the buyer's bill?

**[00:04:50 · 0]** What does that intelligence actually cost the customer? For this example, let's assume the hourly bill is the same for both deployments and both meet your requirements. At roughly one and a half times the output, your rental spend per acceptable token is proportionally lower. That is to say the hour buys you more usable and useful output. What counts as useful intelligence?

**[00:05:15 · 0]** Useful intelligence has to do the job you hired it to do. Pretty simple, right? The answer needs to be good enough for the task, arrive quickly enough, and be available when you need it. Your information also needs to stay within the access boundaries you've agreed upon, a. K.

**[00:05:31 · 0]** A. It needs to be secure. This is an overlooked requirement that is not captured in the chip's performance metrics, but it is essential for a chip to be usable and useful. In our published security work, we found monitoring access that exposed another customer's logs and metrics. This is a case, and an unfortunately common one at that, where the GPUs were fast, in the case I'm referencing, really, really fast, which makes the whole thing sadder, and the service still failed horrifically.

**[00:06:02 · 0]** Ensuring cluster security takes ongoing work just as delivering the promised performance does. In most cases, it is the operator that owns that responsibility. Someone has to make the system work in production. Suppose a faster serving update becomes available. Someone has to test it on the customer's workload, check whether the output still meets the requirements, and then decide when, where, and how to deploy it.

**[00:06:31 · 0]** That means checking the actual responses, testing it under load, and keeping a way to return to previous version if the update causes problems once it's deployed. Once it is deployed, someone has to maintain it and respond when issues come up. That work may sit with your provider, your own team, or both. Irregardless, you need to know who's responsible and whether they can actually do it. So how do we assess the operator?

**[00:07:03 · 0]** Seminalysis ClusterMax, we're on version three point o at this point, assesses operating capability on managed GPU clusters, couple 100 growing. Please reach out if you want to be on ClusterMax 4.0. We look at provisioning, reliability, monitoring, and security. Hands on testing, documentation, and customer feedback help us understand how the service runs, not just on a good day, but also when a machine fails. I wanna take the chance to reiterate that ClusterMax ratings apply to managed clusters, different from bare metal, very different.

**[00:07:41 · 0]** With bare metal, more operating work usually sits with the customer. Applying a managed service rating there does not automatically cover every product a provider sells. The tiers are relative to peers. A Little bit of a tongue twister. I nailed it.

**[00:07:57 · 0]** Pretty happy with that. And pricing and availability are also important factors in this assessment. These are metrics that do not directly measure token output but are incredibly important. Obviously, very important. Assessment helps us understand who can deliver.

**[00:08:13 · 0]** Now we can move on to the next question. What does it actually cost to produce useful intelligence? Let's start with a compute bill and other costs that producer still has to cover. Rental price and production cost are different. In our example, GPU provider...

**[00:08:29 · 0]** The GPU provider rents out hours. The inference producer buys those hours and sells responses. The rental bill is revenue to the provider and an input cost to the inference producer. The GPU owner pays for the equipment, power, space, and support. The inference producer's full cost includes rent plus whatever software, staff, and other services it pays for beyond that rental.

**[00:08:52 · 0]** If the inference producer owns its own equipment instead, we spread the equipment investment over its working life and add running costs. What the producer charges and what it spends are separate numbers. To understand the cost of useful intelligence, we need to know how much useful work the spending actually produces. Better operations lowers that cost of useful intelligence. The B200 comparison showed why the amount of output matters.

**[00:09:17 · 0]** More acceptable responses from the same paid hours can spread the Inference producer's rental expense over more useful work. For a producer that owns its GPUs, the same logic spreads the equipment investment and running costs over more output. Count all the spending needed to deliver the service over the same period, then divide by the output customers can actually use. That gives us cost per acceptable token for a comparable workload. Better operations also require investment.

**[00:09:50 · 0]** Testing an update, deploying it safely, and keeping it working take people and money. The extra output has to justify the extra spending. This advantage can persist when a team repeats that work as software and workloads change, but one good benchmark doesn't establish it. You have to earn it every single day. Each new workload still needs checking, but a repeatable operating process, from what we've observed, can support a lasting cost advantage and a price advantage too.

**[00:10:23 · 0]** Even if you do keep improving, though, your competitors are not sitting still. Your position on the cost curve is relative. This is this slide, out of all the slides, should make clear the importance of the commodity framework in all of this. Your position on the cost curve depends on what your competitors can deliver, not just yourself. It's a relative measure.

**[00:10:44 · 0]** Here's a simple hypothetical. We're comparing the same task, the same required quality using made up cost units. I like to imagine bars of gold. Your full cost per successful task falls from 10 to eight. In the same period, your competitors falls from six to 12.

**[00:11:04 · 0]** You improved. That's awesome. But both of you did. And in this example, you started as the cheaper producer and ended as the more expensive one. That gives the competitor more room to lower its selling price, provide...

**[00:11:16 · 0]** Provided customers find the two services equally acceptable. Getting better does not automatically move you ahead. Applying the commodity framework makes you realize that you have to compare your cost per useful work on a relative basis, comparing your own product with what your competitors can deliver. That comparison can be easy to overlook in moments like today where demand far outstrips supply and will for the foreseeable future. Two to three years.

**[00:11:45 · 0]** Visibility, good. Scarcity can obscure those differences. When demand is strong and supply is constrained, producers with very different costs can can find customers. Strong revenue can make those differences feel less urgent. If you're a CEO, why would you focus on your precious time and energy and money shoring up your spot on the cost curve when you can be building a massive new data center?

**[00:12:10 · 0]** In moments like this, it's important to step back and have a little perspective, take a little historical perspective. Every commodity in the history of humanity has had swings in supply and demand. Just because we don't see when that will be yet does not mean that this cycle will be any different, unless you're a total AI maxi, which some of us are, so I'm very open to being wrong. I'm wrong every day. But I would say if you're a business with leverage, you need to be especially conscientious of this.

**[00:12:38 · 0]** Being proactive with your... With building your cost advantage, might be... Not be as sexy as making your top line bigger, but it matters deeply if you wanna survive through a business cycle. That's why you wanna build your operating capability and cost advantage while you have the opportunity, when the sun is shining, when you can raise capital. They matter even more when customers have more choices to make and prices come under pressure.

**[00:13:03 · 0]** So how do we make clear what, the buyer actually gets? Comparable compute needs clear grades. Now let's look at the compute, that an intelligence producer is buying. We've already seen that the same chip can deliver different results depending on how it's operated. And two offers for b 200 GPU hours can include different services and leave different operating jobs with the customer.

**[00:13:29 · 0]** A commodity framework needs a way to describe these differences so buyers know which services they can treat as comparable. That's the job of a grade. The grade describes a particular compute service and what its buyers can expect. It doesn't make intelligence interchangeable across every task. Once we've defined that service, we can ask what its rental price tells us.

**[00:13:54 · 0]** What does a rental price benchmark measure? A rental price benchmark summarizes the price of GPU hours within its defined market. It isn't the producer's production cost or a measure of intelligence delivered. We need to know where those prices come from. An advertised offer and a completed trade are not the same thing.

**[00:14:14 · 0]** Service scope, contract terms, whose prices are sampled, and how they're combined all shape that reference point. Operating quality can influence those prices without the index measuring it separately. Running a rental reference doesn't tell you how much useful work your deployment will produce. To use it as a hedge, you need to understand how it tracks the rent you actually pay or earn. What can Compute Futures hedge?

**[00:14:43 · 0]** There's been a lot of excitement lately about compute futures. For all of you that don't know, a futures contract sets a standardized term for future delivery or cash settlement. Cash settlement depends on a price reference. Buyers and sellers both face uncertainty about rental prices. Think back to the serving stacks and the monitoring failure.

**[00:15:03 · 0]** Assessing who runs the system helps describe the service buyers get. That helps us define grades so buyers know which compute services are comparable. The benchmark then needs to track the rent they actually pay or earn. That's why I make this argument. Rating the operator is an essential building block for building a credible compute futures market.

**[00:15:24 · 0]** A rating informs that work. It doesn't by itself define a futures grade, establish a sound benchmark, or create enough trading to buy and sell easily. It also doesn't necessarily make a hedge effective. A rental price hedge can help offset rental price changes. It does not fix a failed deployment or ensure that your customer pays.

**[00:15:46 · 0]** Charging more than the index does not by itself make it a bad hedge. What matters is whether changes in the reference track changes in your rent. Unexpected changes in that relationship leave real price risk. Those tool... Those tools can help you understand what you're buying and manage the rental price risk.

**[00:16:04 · 0]** For an intelligence producer, rent is one part of the cost. The operator still has to turn that compute into work that the customer can actually use. This brings us full circle. So a GPU falls to the level of the operator. So who can produce the intelligence you need at the lower cost...

**[00:16:28 · 0]** At the lowest cost? The producer who can repeatedly meet your requirements at the lowest full cost per successfully completed task. Count everything spent to deliver the service, then divide by the output that the customer can actually use. Operating capability affects both sides of that equation, what you spend and how much more useful work you can deliver. Also, your position depends on that of your competitors.

**[00:16:52 · 0]** You can improve and still fall behind if your competitors improve faster than you. That's why understanding the operator matters through the cycle, not just at one point in time, especially when customers have more choices and prices come under more pressure. In conclusion, if you just walked in and want the TLDR, this is it. A GPU falls to the level of the operator. Help build a better informed compute market.

**[00:17:19 · 0]** Ladies and gentlemen, thank you so much for your time today. At Semiannalysis, we know that markets do not become informed and efficient on their own. We seek to be an active, engaged partner in that work. It takes two to tango, though, ideally more than two, actually. If you'd like to partner with us, contribute, or join the team, we would love to hear from you.

**[00:17:39 · 0]** We are always hiring great people. Please reach out. If this resonated, please go ahead and email sales@semiaanalysis.com for partnership opportunities. And if you're interested in potentially joining the team, my email is kennon@semiannonalysis.com, k e n n o n.

## Slides

### 00:00:00–00:00:20

# AI Engineer
## The Highest-Signal Technical AI Conferences

AI Engineer hosts AI developer conferences around the world for engineers, breakout startup founders, and AI architects advancing AI engineering at the world's leading technology companies.

### Find Out What's Next

Scan the QR code or visit [https://ai.engineer](https://ai.engineer) to subscribe to our newsletter and stay up to date with the latest news and events.

[QR code linking to https://ai.engineer]

### 00:00:20–00:00:40

# AI Engineer
## NEW YORK

### 00:00:40–00:01:40

# Not All GPUs Are Deployed the Same

A GPU falls to the level of the **operator**
Who can produce the intelligence you need at the lowest cost?

Oliver Kennon | SemiAnalysis
AI Engineer New York | October 14, 2026

### 00:01:40–00:02:00

# Why that matters in a commodity market

## Full cost per unit of comparable acceptable work

## What we count
- **Successful tasks at required quality**
    - North star metric
- **Tokens**
    - Practical proxy today
    - Best for comparable workloads and quality
- **GPU-hours**
    - Compute input

Not All GPU's Are Deployed The Same

Oliver Kennon / Research Analyst, Core Research semianalysis

[Bar chart showing full cost per unit for producers, ordered from lowest to highest cost, with a horizontal "Selling price" line. The lowest cost producer bar is highlighted in yellow and brown, indicating "Keeps more". A higher cost producer bar is highlighted in blue, indicating "Keeps less" as its cost is closer to the selling price.]

### 00:02:00–00:02:20

# Why that matters in a commodity market

## Full cost per unit of comparable acceptable work
ILLUSTRATIVE

### What we count
Closer to delivered output
- **Successful tasks at required quality

### 00:02:20–00:02:40

# Why that matters in a commodity market

Full cost per unit of comparable acceptable work
ILLUSTRATIVE

### What we count
Closer to delivered output
- **Successful tasks at required quality**

### 00:02:40–00:03:00

# Why that matters in a commodity market

## Full cost per unit of comparable acceptable work

ILLUSTRATIVE

- Lower-cost producer
- Higher-cost producer
- Producers, ordered from lowest to highest cost

Illustrative cost curve; values are hypothetical.

### What we count

Closer to delivered output

- **Successful tasks at required quality**
    - North star metric
- **Tokens**
    - Practical proxy today
    - Best for comparable workloads and quality
- **GPU-hours**
    - Compute input

### Not All GPU's Are Deployed The Same

Oliver Kennon / Research Analyst, Core Research

[Bar chart illustrating full cost per unit for producers, ordered from lowest to highest cost, with a horizontal line representing the selling price. It highlights that lower-cost producers "keep more" and higher-cost producers "keep less" above their costs relative to the selling price.]

### 00:03:00–00:03:20

# GPU-hours are the input. Intelligence is the output.

- **Input: GPU-hours**
  - Hardware
  - Electricity
- **Multiplier: the operator**
  - Software and operations
  - Chooses and implements the serving software
  - Keeps requests moving
- **Output**
  - Useful intelligence
  - Responses that meet the requirements of the specified task

## Not All GPU's Are Deployed The Same

Oliver Kennon / Research Analyst, Core Research semianalysis

[Flow diagram showing "Hardware Electricity" as input, multiplied by "Software and operations" to produce "Useful intelligence"]

### 00:03:20–00:03:40

# GPU-hours are the input. Intelligence is the output.

-   **Input: GPU-hours**
    -   Hardware Electricity
-   **Multiplier: the operator**

### 00:03:40–00:04:00

# GPU-hours are the input. Intelligence is the output.

Input: GPU-hours
- Hardware Electricity

Multiplier: the operator
- Software and operations
  - Chooses and implements the serving software
  - Keeps requests moving

Output:
- Useful intelligence
  - Responses that meet the requirements of the specified task

Not All GPU's Are Deployed The Same

Oliver Kennon / Research Analyst, Core Research semianalysis

[Flow diagram showing "Hardware Electricity" multiplied by "Software and operations" resulting in "Useful intelligence"]

### 00:04:00–00:04:20

# Same chip. Different output.
B200 GPUs, same model, same workload, same speed target per user

Generated output tokens per second, per GPU

- **TensorRT-LL

### 00:04:20–00:04:40

# Same chip. Different output.
B200 GPUs, same model, same workload, same speed target per user

Generated output tokens per second, per GPU

- About 50

### 00:04:40–00:05:00

# Same chip. Different output.
B200 GPUs, same model, same workload, same speed target per user

## Generated output tokens per second, per GPU
- **TensorRT-LLM (no MTP):** 199
- **SGLang + MTP:** 298
  - About 50% more output

The operator chooses how the chip is run.
Serving software, settings, requests running at once

### 00:05:00–00:05:20

# What does that intelligence actually cost the customer?
A buyer's rental spend, not either provider's production cost

**HYPOTHETICAL CUSTOMER EXAMPLE**

- **TensorRT-LLM deployment**
- **SGLang + MTP deployment**

### Hourly rental bill
- TensorRT-LLM deployment: 1.00
- SGLang + MTP deployment: 1.00
Assumes equal hourly rental bills

### Acceptable output per hour
- TensorRT-LLM deployment: 1.00
- SGLang + MTP deployment: 1.50
Assumes both deployments meet the customer's requirements

### Rental spend per acceptable token
- TensorRT-LLM deployment: 1.00
- SGLang + MTP deployment: 0.67
About two-thirds

Normalized: TensorRT-LLM deployment = 1.00. Output ratio from the B200 comparison: 298 ÷ 199 = 1.50.

Source: SemiAnalysis InferenceX calculator, B200 comparison on slide 4 (data through Sep 16, 2026). Equal hourly bills and acceptability are hypothetical assumptions.

## Not All GPU's Are Deployed The Same
Oliver Kennon / Research Analyst, Core Research semianalysis

[Three bar charts comparing "TensorRT-LLM deployment" and "SGLang + MTP deployment" for hourly rental bill, acceptable output per hour, and rental spend per acceptable token]

### 00:05:20–00:05:40

# What counts as useful intelligence?
Output counts when it meets the customer's requirements

-   **Quality**
    Good enough for the task
-   **Response speed**
    Arrives quickly enough
-   **Reliability**
    Available when you need it
-   **Security** (OFTEN OVERLOOKED)
    Your information stays within agreed access boundaries

A chip's performance metrics don't capture security, but it's essential.

### SECURITY EXAMPLE
-   Fast GPUs can still fail the customer
    Our security work found cross-tenant exposure of monitoring logs and metrics.

Source: SemiAnalysis, "Most Neoclouds Suck At Security" (Aug 30, 2026): multi-tenant Grafana/Prometheus monitoring finding. Provider not named; historical finding, not current status.

## Not All GPU's Are Deployed The Same
Oliver Kennon / Research Analyst, Core Research

[Diagram showing "Customer A's monitoring access" with an arrow labeled "could read" pointing to "Customer B's logs and metrics", separated by a dashed "Customer boundary" line.]

### 00:05:40–00:06:00

# What counts as useful intelligence?
Output counts when it meets the customer's requirements

### Quality
Good enough for the task

### Response speed
Arrives quickly enough

### Reliability

### 00:06:00–00:06:20

# What counts as useful intelligence?
Output counts when it meets the customer's requirements

**Quality**
Good enough for the task

**Response speed**
Arrives quickly enough

**Reliability**
Available when you need it

**Security** (OFTEN OVERLOOKED)
Your information stays within agreed access boundaries

A chip's performance metrics don't capture security, but it's essential.

### SECURITY EXAMPLE
Fast GPUs can still fail the customer
Our security work found cross-tenant exposure of monitoring logs and metrics.

Source: SemiAnalysis, "Most Neoclouds Suck At Security" (Aug 30, 202X): multi-tenant Grafana/Prometheus monitoring finding. Provider not named; historical finding, not current status.

Not All GPU's Are Deployed The Same
Oliver Kennon / Research Analyst, Core Research

[Diagram showing "Customer A's monitoring access" with an arrow labeled "could read" pointing across a "Customer boundary" to "Customer B's logs and metrics"]

### 00:06:20–00:06:40

# Someone has to make the system work in production
Example: a faster serving update becomes available

1.  **Test**
    Under load, on the customer's workload
2.  **Check**
    Actual responses still meet requirements
3.  **Decide**
    Whether, when and how to deploy
4.  **Deploy**
    With a way back
5.  **Maintain**
    Respond when issues come up

## Know who owns the work—and whether they can deliver.
Your provider | Your team | Both

# Not All GPU's Are Deployed The Same

Oliver Kennon / Research Analyst, Core Research semianalysis

[Flowchart illustrating a 5-step deployment and maintenance process with a rollback to a previous version]
[Three rectangular buttons labeled "Your provider", "Your team", and "Both"]

### 00:06:40–00:07:00

# Someone has to make the system work in production
Example: a faster serving update becomes available

1.  **Test**
    Under load, on the customer's workload
2.  **Check**
    Actual responses still meet requirements
3.  **Decide**
    Whether, when and how to deploy
4.  **Deploy**
    With a way back
5.  **Maintain**
    Respond when issues come up
    - Roll back if problems (to Previous version)

## Know who owns the work—and whether they can deliver.
- Your provider
- Your team
- Both

### Not All GPU's Are Deployed The Same

Oliver Kennon / Research Analyst, Core Research semianalysis

[Flowchart showing a 5-step process: Test, Check, Decide, Deploy, Maintain, with a rollback option from Deploy to a Previous version.]

### 00:07:00–00:07:20

# How do we assess the operator?
ClusterMAX assesses operating capability on managed GPU clusters

## Evidence
- Hands-on testing
- Documentation
- Customer feedback

## Managed GPU

### 00:07:20–00:07:40

# How do we assess the operator?
ClusterMAX assesses operating capability on managed GPU clusters

## Evidence
- Hands-on testing
- Documentation
- Customer feedback

## Managed GPU cluster service

### 00:07:40–00:08:00

# How do we assess the operator?
ClusterMAX assesses operating capability on managed GPU clusters

## Evidence
- Hands-on testing
- Documentation
- Customer feedback

## **Managed GPU cluster

### 00:08:00–00:08:20

# How do we assess the operator?
ClusterMAX assesses operating capability on managed GPU clusters

- **Evidence**
    - Hands-on testing
    - Documentation
    - Customer feedback
-

### 00:08:20–00:08:40

# How do we assess the operator?
ClusterMAX assesses operating capability on managed GPU clusters

- **Evidence**
    - Hands-on testing
    - Documentation
    - Customer

### 00:08:40–00:09:00

# Rental price and production cost are different

-   **GPU provider**
    -   Rents out GPU-hours
-   **Inference producer**
    -   Rents

### 00:09:00–00:09:20

# Rental price and production cost are different

[Flow diagram showing the relationship between GPU provider, Inference producer, and Customer]

- **GPU provider**
  Rents out GPU-hours
- **Inference producer**
  Rents GPU-hours, sells responses
- **Customer**
  Buys responses

**Flow:**
- GPU provider provides GPU-hours to Inference producer.
- Inference producer pays Rent to GPU provider (Provider's revenue, Producer's input cost).
- Inference producer provides Responses to Customer.
- Customer makes Payment for responses to Inference producer (Producer's revenue).

**Pays for**
Equipment, power, space, support

**Full cost**
Rent + software, staff, other services

> If it owns the GPUs: equipment investment spread over its working life + running costs

What the producer charges and what it spends are separate numbers.

---

### Not All GPU's Are Deployed The Same
Oliver Kennon / Research Analyst, Core Research semianalysis

[Flow diagram illustrating the economic relationship between a GPU provider, an inference producer, and a customer]

### 00:09:20–00:09:40

# Better operations lower the cost of useful intelligence

- Better operations also cost: testing, safe deployment, upkeep

$$
\frac{\text{Full spending to deliver the service}}{\text{Acceptable output}} \quad \text{Same period} = \text{Cost per acceptable output}
$$

Per acceptable token for a comparable workload, or per successfully completed task at the required quality

- Better operations: more acceptable output from the same paid hours

The extra output has to justify the extra spending.

- One good benchmark
- A repeatable process as software and workloads change -> Can support a lasting cost advantage

## Not All GPU's Are Deployed The Same

Oliver Kennon / Research Analyst, Core Research

[Diagram showing a progression from a single benchmark to a repeatable process over time, leading to a lasting cost advantage]

### 00:09:40–00:10:00

# Better operations lower the cost of useful intelligence

Better operations also cost: testing, safe deployment, upkeep

(Full spending to deliver the service / Acceptable output) = Cost per acceptable

### 00:10:00–00:10:20

# Better operations lower the cost of useful intelligence

- **Full spending to deliver the service**
  - *Better operations also cost: testing, safe deployment, upkeep*
- **Acceptable

### 00:10:20–00:10:40

# Better operations lower the cost of useful intelligence

**Full spending to deliver the service**
--- = **Cost per acceptable output**
**Acceptable output**

*   _Better operations also cost

### 00:10:40–00:11:00

# Your position on the cost curve is relative

Made-up cost units: same task, same required quality

## Before
Full cost per successful task

## After
Full cost per successful task

### 00:11:00–00:11:20

# Your position on the cost curve is relative
Made-up cost units: same task, same required quality

### Before
Full cost per successful task

### After
Full cost per successful task

HYPOTHETICAL

- You: 10 to 8
- Competitor: 12 to 6
- Both improved.
- The order reversed.

## Not All GPU's Are Deployed The Same

[Bar chart comparing "You" and "Competitor" costs before and after, showing "You" going from 10 to 8 and "Competitor" going from 12 to 6]

### 00:11:20–00:11:40

# Your position on the cost curve is relative
Made-up cost units: same task, same required quality

### Before
Full cost per successful task

### After (HYPOTHETICAL)
Full cost per successful task

You: 10 to 8
Competitor: 12 to 6
Both improved.
The order reversed.

## Not All GPU's Are Deployed The Same

Oliver Kennon / Research Analyst, Core Research

[Two bar charts showing "You" and "Competitor" costs. The "Before" chart shows You at 10 and Competitor at 12. An arrow points to the "After" chart, which shows You at 8 and Competitor at 6.]

### 00:11:40–00:12:00

# Your position on the cost curve is relative
Made-up cost units: same task, same required quality

## Before
Full cost per successful task

## After
Full cost per successful task

### 00:12:00–00:12:20

# Scarcity can obscure those differences

## Strong demand, constrained supply
- Producers with very different costs can still find customers
- Full cost per unit of comparable acceptable work

## More choice

### 00:12:20–00:12:40

# Scarcity can obscure those differences

## Strong demand, constrained supply
Producers with very different costs can still find customers

Full cost per unit of comparable acceptable work

## More choice, price pressure
Higher costs leave less room to compete

Same cost curve

**CONCEPTUAL**

Commodity cycles turn, and leverage raises the stakes: build your cost advantage while you can.

Conceptual: slide 2's hypothetical cost curve under two selling-price levels. Market conditions, not a forecast.

### Not All GPU's Are Deployed The Same
Oliver Kennon / Research Analyst, Core Research

[Two bar charts comparing producer costs and selling price. The left chart shows all producers' costs below the selling price. The right chart shows some producers' costs exceeding the selling price, highlighted with red borders.]

### 00:12:40–00:13:00

# Scarcity can obscure those differences

## Strong demand, constrained supply
Producers with very different costs can still find customers

Full cost per unit of comparable acceptable work

## More choice, price pressure
Higher costs leave less room to compete

Same cost curve

CONCEPTUAL

Commodity cycles turn, and leverage raises the stakes: build your cost advantage while you can.

Conceptual: slide 2's hypothetical cost curve under two selling-price levels. Market conditions, not a forecast.

[Two bar charts side-by-side. The left chart shows bars of increasing height, all below a "Selling price" line. The right chart shows the same bars, but with a lower "Selling price" line, and the bars exceeding this line are highlighted.]

### 00:13:00–00:13:20

# Scarcity can obscure those differences

## Strong demand, constrained supply
Producers with very different costs can still find customers
- Full cost per unit of comparable acceptable work

## More choice, price pressure
Higher costs leave less room to compete
- Same cost curve

Commodity cycles turn, and leverage raises the stakes: build your cost advantage while you can.

Conceptual: slide 2's hypothetical cost curve under two selling-price levels.

### 00:13:20–00:13:40

# Comparable compute needs clear grades

### Two offers for B200 GPU-hours
- B200
  - Provider manages the software
- B200

### 00:13:40–00:14:00

# Comparable compute needs clear grades

### Two offers for B200 GPU-hours
- B200
  - Provider manages the software
- B200
  - You manage the software
Same chip, different jobs left with you

### A grade describes the service
- Configuration
- Delivery conditions
- Who makes the service work

### Buyers know what's comparable
- Within one grade

A grade doesn't make intelligence interchangeable across every task.

Grading concept: Julius B. Baer and Olin G. Saxon, Commodity Exchanges and Futures Trading (New York: Harper, 1949), ch. VI, pp. 110-111. Applying grades to compute services is our application.

## Not All GPU's Are Deployed The Same

Oliver Kennon / Research Analyst, Core Research semianalysis

[Flow diagram showing two offers for B200 GPU-hours (one managed by provider, one by user) leading to a description of service grades (configuration, delivery, who makes it work), which then leads to buyers knowing what's comparable within one grade, illustrated by a 2x3 grid of squares.]

### 00:14:00–00:14:20

# What does a rental-price benchmark measure?

## Observations
- Advertised offers
- Completed trades

## Method choices
- Service scope
- Contract terms
- Whose prices are

### 00:14:20–00:14:40

# What does a rental-price benchmark measure?

**Observations**
- Advertised offers
- Completed trades

**Method choices**
- Service scope
- Contract terms
-

### 00:14:40–00:15:00

# What can compute futures hedge?

### MY ARGUMENT
Rating the operator is an **essential building block** for building a credible compute futures market.

- Operator assessment
  - informs -> Comparable

### 00:15:00–00:15:20

# What can compute futures hedge?

### MY ARGUMENT
Rating the operator is an **essential building block** for building a credible compute futures market.

A rental-price hedge doesn'

### 00:15:20–00:15:40

# What can compute futures hedge?

## MY ARGUMENT
Rating the operator is an **essential building block** for building a credible compute futures market.

A rental-price hedge doesn'

### 00:15:40–00:16:00

# What can compute futures hedge?

MY ARGUMENT

Rating the operator is an **essential building block** for building a credible compute futures market.

A rental-price hedge doesn't fix a

### 00:16:00–00:16:20

# What can compute futures hedge?

### MY ARGUMENT
Rating the operator is an **essential building block** for building a credible compute futures market.

A rental-price hedge doesn't fix a failed deployment or ensure your customer pays.
Rent is one part of the cost. The **operator** still has to turn compute into usable work.

Sources: CFTC, Economic Purpose of Futures Markets; CFTC Glossary (cash settlement, basis risk). Context: CFTC request for comment on compute derivatives, Aug 19, 2026 (9286-26); not a product approval.

## Not All GPU's Are Deployed The Same

Oliver Kennon / Research Analyst, Core Research semianalysis

[Flowchart showing a process: Operator assessment informs Comparable service grade, which informs Relevant rental-price reference, which informs Futures contract (Standardized terms, cash-settled against the reference), which informs Hedge (Helps offset rental-price changes).]

### 00:16:20–00:16:40

# A GPU falls to the level of the **operator**

Who can produce the intelligence you need at the lowest cost?
The producer who can repeatedly meet your requirements at the lowest full cost per successfully completed task.

## Not All GPU's Are Deployed The Same

Oliver Kennon / Research Analyst, Core Research semianalysis

[Diagram showing "Full spending" and "Acceptable output" linked by "Operating capability affects both"]
[Bar chart illustrating performance relative to competitors, with one bar highlighted]

### 00:16:40–00:17:00

# A GPU falls to the level of the **operator**

Who can produce the intelligence you need at the lowest cost?
The producer who can repeatedly meet your requirements at the lowest full cost per successfully

### 00:17:00–00:17:20

# A GPU falls to the level of the **operator**

Who can produce the intelligence you need at the lowest cost?
The producer who can repeatedly meet your requirements at the lowest full

### 00:17:20–00:17:40

# Help build a better-informed compute market
Markets don't become informed and efficient on their own.

Partner with us. Contribute. Join the team.
**sales@semianalysis.com**
We're always hiring great people.

### Not All GPU's Are Deployed The Same
Oliver Kennon / Research Analyst, Core Research

### 00:17:40–00:18:00

# Help build a better-informed compute market
Markets don't become informed and efficient on their own.

Partner with us. Contribute. Join the team.
**sales@semianalysis.com**
We're always hiring great people.

## Not All GPU's Are Deployed The Same
Oliver Kennon / Research Analyst, Core Research