Oliver Kennon (SemiAnalysis) examines GPU compute as a commodity market: serving-stack choices alone can yield roughly 50% more output on the same B200 chip, and cluster security factors into whether intelligence output is truly useful. He covers SemiAnalysis's ClusterMAX operator ratings, the distinction between rental price and production cost, how cost position is relative to competitors, and what it takes to build credible compute grades and futures. # Video Identity Observations — "Same GPU, 50% More Output: Why the Operator Matters" ## Self-Description Evidence (Explicit Claims) - **Speaker identity and affiliation**: The speaker introduces himself directly: > "My name is Oliver Cannon. I'm a research analyst at SemiAnalysis." *(Note: the video title says "Oliver Kennon," while the transcript renders "Oliver Cannon" — a naming discrepancy between title and transcript.)* - **Product/self-promotional claims**: The speaker references SemiAnalysis's public tools and rating product: > "Here's a concrete example from our InferenceX public InferenceX calculator. You guys can all check it out, semi-analysis.com." > "SemiAnalysis ClusterMax, we're in version 3.0 at this point… couple hundred, uh, growing. Please reach out if you want to be on ClusterMax 4.0." > "In our published security work, we found monitoring access that exposed another customer's logs and metrics." ## Claimed Scope - **Analytical positioning**: The channel presents itself as a research organization producing frameworks for evaluating compute markets — cost curves, commodity-market economics, compute futures, and operator ratings (ClusterMax covering "provisioning, reliability, monitoring, and security"). - ** Intellectual output beyond analysis**: The talk argues for the speaker's own thesis — that operator capability is a "building block for building a credible compute futures market" — demonstrating a research/advocacy scope, not just reporting. ## Intended Audience (Observable) - **Finance-adjacent tech audience**: The speaker repeatedly addresses investors and business decision-makers: > "all you finance bros out here will have heard this uh GPU uh dollar per hour price" > "A lot of tech investors or technologists may not be familiar with this framework. Um so a little crash course." > "if you're a business with leverage, you need to be especially conscientious of this." > "If you're a CEO, why would you focus on… shoring up your spot on the cost curve when you can be building a massive new data center?" - **Live professional event context**: Opening ("Thank you everyone for taking the time to be here today") and audience laughter cues indicate a conference-style presentation to an engaged industry audience. ## Demonstrated Presentation Style (Observable, Not Claimed) - **Accessible framing of technical content**: Analogies and humor ("I like to imagine bars of gold"; "Little bit of a tongue twister… I nailed it, pretty happy with that"). - **Epistemic hedging**: > "I'm very open to being wrong. I'm wrong every day." > "from what we've observed, can support a lasting cost advantage" - **Business funnel behavior**: Direct calls to action (visit the calculator, reach out for ClusterMax 4.0) suggest the talk doubles as business development for SemiAnalysis's research products. ## Distinguishing Notes - Creator claims (SemiAnalysis affiliation, product names, published security findings) are stated by the speaker but not independently verified within the material. - Channel-wide conclusions (e.g., that all SemiAnalysis content targets investors) are **not** supported by this single video; only this talk's audience framing is evidenced. # Delivery Observations — Oliver Kennon, SemiAnalysis ## Speaker self-identification and naming discrepancy - The video title names **Oliver Kennon**, but the speaker opens with: *"My name is Oliver Cannon."* The transcript later includes an email spelling *"k e n n o n"*. This inconsistency is directly observable in the source material and is flagged here without resolving it. ## Tone - **Conversational-analytical blend**: dense economic framing delivered with frequent informal asides — *"Pretty simple, right?"*, *"That's awesome."*, *"Good."* - **Self-deprecating humor** appears at recurring moments: *"I nailed it, pretty happy with that."*, *"I'm wrong every day."*, *"It takes two to tango though. Uh ideally more than two actually."* - **Occasional pointed jokes aimed at the audience's identity**: *"all you finance bros out here will have heard this"*, *"unless of course you're an early stage investor in OpenAI or Anthropic"*, *"unless you're a total AI maxi, which some of us are."* ## Recurring vocabulary and framing - **Cost vs. price distinction** is restated multiple times as a central teaching axis: > *"We view GPU hours as a measure of input, not output, the cost versus price distinction."* > *"What the producer charges and what it spends are separate numbers."* - **"Useful" as a modifier**: *"useful intelligence"* (repeated at least five times), *"useful work"*, *"acceptable token"*, *"output that the customer can actually use."* - **Input/output dichotomy** structures the whole talk: *"GPU hours are the input, intelligence is the output."* - **Signature thesis line**, repeated near-verbatim at open, middle pivot, and close: *"A GPU falls to the level of the operator."* - **"Someone has to"** as an operator-responsibility motif: *"Someone has to make the system work in production."*, *"someone has to test it on the customer's workload"*, *"Once it is deployed, someone has to maintain it."* ## Teaching habits - **Framing the talk as a question and answering it**: opens with *"Who can produce the intelligence you need at the lowest cost?"* and closes by restating and answering it. - **Mini crash-course preamble before technical concepts**: *"a little crash course"* before commodity-market economics; *"for all of you that don't know"* before futures contracts. - **Concrete worked example held up as anchor**: the B200 / InferenceX comparison (200 vs. 300 tokens/sec, ~"50% more output") is revisited multiple times as evidence. - **Rule-of-thumb summations after explanations**: *"Count all the spending needed to deliver the service over the same period, then divide by the output customers can actually use."* - **Explicit scope caveats**, e.g., distinguishing ClusterMax from bare metal: *"applying a managed service rating there does not automatically cover every product a provider sells."* - **Anticipating objections**: *"Getting better does not automatically move you ahead."*, *"A rating informs that work. It doesn't by itself define a futures grade."* ## Communication patterns - **Direct reader service**: plugs the public calculator (*"semi-analysis.com"*), invites ClusterMax participation (*"Please reach out if you want to be on ClusterMax 4.0"*), and gives a direct sales email plus his own email with letter-by-letter spelling at the close. - **Structured signposting**: frequent transitional questions move slides along — *"So, what does that mean for the buyer's bill?"*, *"So, how do we assess the operator?"*, *"What does a rental price benchmark measure?"* - **Verbal stumbles and restarts** are common and unpolished: *"Irregardless"*, *"couple couple hundred"*, *"This is This slide"*, *"built with building your cost advantage"*, *"The producer who can repeatedly meet your requirements at the lowest full cost per successfully completed task"* following a self-correction from "lower cost." - **TLDR convention**: explicitly flags the summary — *"if you just walked in and want the TLDR, this is it."* ## Isolated moments (insufficient repetition to call patterns) - A single emphatic emotional beat about the security failure: *"the GPUs were fast, and in the case I'm referencing, really, really fast, which makes the whole thing sadder... and the service still failed horrifically."* This register appears only once. - One audience-laughter moment ("tiers are relative to peers" tongue-twister) — the only observed live crowd interaction besides the closing applause. - One hypothetical aside with a personal image: *"I like to imagine bars of gold."* Appears once; not enough evidence for a recurring analogy habit. ## Uncertainty notes - Repetition counts above are based only on this single transcript; the "50% more output" example may recur in other talks, but that cannot be confirmed here. - Whether the "Oliver Cannon" opening is a transcript artifact or the speaker's actual words cannot be determined from the source. # Same GPU, 50% More Output: Why the Operator Matters **Speaker:** Oliver Kennon (introduces himself as "Oliver Cannon" in the transcript), Research Analyst at SemiAnalysis *Note: Speaker identification relies solely on the title metadata and the speaker's self-introduction; the transcript contains no other voices.* --- ## Core Thesis > "A GPU falls to the level of the operator." - **Not all GPUs are deployed the same.** Buying hardware gives only *potential*; operating capability determines how much useful work is actually delivered. - Central question of the talk: **Who can produce the intelligence you need at the lowest cost?** --- ## Commodity Market Framework - Producers in commodity markets compete to deliver comparable output; **lower production cost gives more room to compete when prices fall**. - A **cost curve** lines producers up by what they spend to deliver the same usable work. At equal prices, the cheaper producer keeps more. - **Intelligence is the economic output** in question. ### Metrics and Proxies - **North Star metric (aspirational):** price per *successfully completed task* at required quality — "we're not quite there yet," hard to standardize. - **Practical proxy today:** price per token, for comparable workloads and quality requirements. - Explicitly rejected: **GPU dollar-per-hour price** — Kennon views GPU hours as a measure of *input*, not output. He distinguishes customer **price** from producer **cost**. --- ## The Inputs → Output Model - **Inputs:** hardware and electricity (GPUs for this presentation). - **Software and operations:** a **multiplier** on those inputs. - **Output:** useful intelligence. - The **operator** chooses and implements the serving software and keeps requests moving: "The machines might be available, but you still need someone to make them deliver responses customers can actually use." --- ## Measured Example: B200 Comparison (InferenceX Calculator) - Public calculator at semi-analysis.com; both estimates use **B200 GPUs**, same model, ~8,000 input / 1,000 output tokens, **P50 target of 100 output tokens/sec** per user. - In the P90 scenario, one serving stack delivers ~**200 tokens/sec**, another ~**300 tokens/sec** — a difference attributed entirely to **software, settings, and request concurrency — all operator choices**. - Same chip, same interactivity target: **~50% more output**. - Assuming equal hourly bills, rental spend **per acceptable token is proportionally lower** in the better deployment. --- ## What Counts as "Useful Intelligence" - Must be **good enough for the task, arrive quickly enough, and be available when needed**. - Must stay within agreed access boundaries — **security**. - Security is described as an "overlooked requirement" not captured in chip performance metrics. > "In our published security work, we found monitoring access that exposed another customer's logs and metrics… the GPUs were fast… really, really fast, which makes the whole thing sadder. And the service still failed horrifically." ### Operational Responsibility - Faster serving updates require someone to **test on the customer's workload, check output quality, test under load, deploy with rollback capability, and maintain** post-deployment. - That work may sit with the provider, the customer's own team, or both — "you need to know who's responsible and whether they can actually do it." --- ## ClusterMax (SemiAnalysis Product) - **Version 3.0**; assesses operating capability on **managed GPU clusters** (a couple hundred, growing; invites for 4.0). - Dimensions: **provisioning, reliability, monitoring, security**; based on hands-on testing, documentation, and customer feedback — including behavior "when a machine fails." - **Qualifications stated:** - Ratings apply to **managed clusters, not bare metal** ("very different" — more operating work sits with the customer under bare metal). - Ratings don't automatically cover every product a provider sells. - Tiers are **relative to peers**; pricing and availability are also assessed factors, though they don't directly measure token output. --- ## Cost of Useful Intelligence - **Rental price ≠ production cost.** GPU rental is revenue for the provider and an input cost for the inference producer; the producer's full cost also includes software, staff, and other services. - For owner-operators: spread equipment investment over working life plus running costs. - Formula offered: **total spending to deliver the service ÷ output customers can actually use** = cost per acceptable token for a comparable workload. - Better operations spread the same costs over more output — but **better operations also require investment**: "The extra output has to justify the extra spending." - A repeatable operating process *can* (per "what we've observed") support a **lasting cost and price advantage** — but "one good benchmark doesn't establish it. You have to earn it every single day." --- ## Relative Positioning on the Cost Curve - Cost curve position is **relative to competitors**, not absolute. - **Hypothetical (made-up "gold bar" units):** your cost per successful task falls 10 → 8; competitor's falls 6 → 12. You improved but went from cheapest to most expensive producer, giving the competitor more room to lower prices — *provided customers find both services equally acceptable*. > "Getting better does not automatically move you ahead." ### Scarcity Warning - Current demand far outstrips supply, with **"two to three years visibility"** per Kennon — but "every commodity in the history of humanity has had swings in supply and demand." - Scarcity **obscures cost differences**; strong revenue makes them feel less urgent. - He frames his own view with humility: "I'm very open to being wrong. I'm wrong every day," while noting "some of us" are "total AI maxis." - Advice for leveraged businesses: build cost advantage **proactively, while capital is available** ("when the sun is shining") — "it matters deeply if you want to survive through a business cycle." --- ## Grades and Rental Price Benchmarks - Two B200 GPU-hour offers can bundle **different services** and leave different operating jobs with the customer. - A **grade** describes a compute service and what buyers can expect; it does *not* make intelligence interchangeable across every task. - A **rental price benchmark** summarizes GPU-hour prices within a defined market — it is **not** production cost or a measure of intelligence delivered. - An **advertised offer is not a completed trade**; service scope, contract terms, sampling, and aggregation shape the reference point. Operating quality can influence prices without being measured separately. --- ## Compute Futures - A futures contract sets standardized terms for future delivery or **cash settlement**, which depends on a price reference. - **Argument:** "Rating the operator is an essential building block for building a credible compute futures market" — because grading requires assessing who runs the system, and the benchmark must track rents actually paid or earned. - **Explicit limitations he states:** a rating does not by itself define a futures grade, establish a sound benchmark, create trading liquidity, or guarantee an effective hedge. - A rental hedge offsets **rental price changes only** — "It does not fix a failed deployment or ensure that your customer pays." - Charging more than the index doesn't make it a bad hedge; what matters is whether **reference changes track your actual rent** — deviations leave real price risk. --- ## Closing Frame - For an intelligence producer, **rent is only one part of cost**; the operator must still convert compute into usable work — "This brings us full circle." --- ## Unresolved Tensions Preserved - Kennon acknowledges uncertainty about cycle timing ("Just because we don't see when that will be yet does not mean this cycle will be any different") while still urging proactive cost-advantage building. - He concedes the lasting-advantage claim rests on observation, not proof ("from what we've observed… can support a lasting cost advantage"). - The proxy metric (price per token) is explicitly a stopgap, not the ideal measure (price per completed task). # Video Attribution & Provenance Record ## Video Identification - **Title:** "Same GPU, 50% More Output: Why the Operator Matters — Oliver Kennon, SemiAnalysis" - **Video ID:** 01a15ca6-61a6-798b-baa6-dccc45604fa5 ## Speaker Identification & Roles ### Primary Speaker (sole identified speaker) - **Name:** Self-introduced in transcript as **Oliver Cannon** — note: the video title metadata says "Oliver Kennon." This **discrepancy between the title metadata and the self-introduction is unresolved**; the transcript is the closer source but the correct spelling cannot be confirmed. - **Stated role:** "I'm a research analyst at SemiAnalysis" — **creator/presenter** (conference-style talk by a SemiAnalysis analyst). - **No guests, narrators, or other speakers appear.** Audience reactions (brief laughter, timestamp ~440s) are audible but not attributable. ## Referenced Sources & Company Assets (self-cited / promotional) - **SemiAnalysis InferenceX calculator** — "public InferenceX calculator... semi-analysis.com" (promotional mention). - **SemiAnalysis ClusterMax** — described as "version 3.0" assessing managed GPU clusters ("couple hundred, growing"); explicit call to action: *"Please reach out if you want to be on ClusterMax 4.0"* (**promotional segment**). - **"Our published security work"** — cited claim: found "monitoring access that exposed another customer's logs and metrics." Specific publication not named. - **B200 comparison example** — concrete figures (same model, ~8,000 input / 1,000 output tokens; ~200 vs ~300 output tokens/sec) attributed to the InferenceX calculator example. - **Hypothetical cost-curve example** — speaker explicitly labels it hypothetical ("made-up cost units"). ## Third-Party Claims - References to OpenAI and Anthropic only in a joking aside about early-stage investors — no substantive claims. - General market claims ("two to three years visibility" of demand outstripping supply) are the speaker's own assertions, not sourced. - Compute futures discussion is conceptual framing; no specific exchange, index, or benchmark named. ## Audience & Context - Presentation addressed to an audience including "tech investors or technologists" and "finance bros" — appears to be a live industry talk; audience laughter noted. ## Availability Limits - **Comment section:** No information available. - **Cited publications:** InferenceX calculator, ClusterMax methodology, and the security work are referenced but their contents are not reproduced in the transcript; transcript viewers cannot verify them from this material. ## Self-Check Notes - All roles and figures above are explicit in the transcript; no quality judgments recorded; promotion (InferenceX, ClusterMax 4.0 outreach) flagged; speaker-name discrepancy explicitly marked rather than resolved. \>\> Thank you everyone for taking the time to be here today. My name is Oliver Cannon. I'm a research analyst at SemiAnalysis. Um time and attention are the most valuable things any of us have. Uh unless of course you're an early stage investor in OpenAI or Anthropic. Um with that, uh let's get into it. Uh not all GPUs are deployed the same. A GPU falls to the level of the operator. Um buying hardware gives you potential. Uh operating capability is what determines how much useful work you actually are able to deliver. Uh 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. Uh who uh 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? Um a lot of tech investors or technologists may not be familiar with this framework. Um so a little crash course. Uh in a commodity market producers compete to deliver comparable output. Uh a lower production cost gives more room to compete when prices fall. Uh 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. 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. Uh unfortunately, we're not quite there yet. That's a pretty hard thing to standardize. Um today price per token is a useful practical proxy, especially for comparable workloads and quality requirements, and gets us closer to delivered output. Uh much closer than the often quoted uh all you finance bros out here will have heard this uh GPU uh dollar per hour price. Um or as we view it, a cost. Um 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, intelligence is the output. Uh on this slide, we can visualize the inputs needed to create useful intelligence. Uh we start with hardware and electricity, GPUs uh 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. 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. Here's a concrete example from our InferenceX public InferenceX calculator. You guys can all check it out, semi-analysis.com. Uh 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 P50 target is 100 output tokens per second for each user. Uh the serving stack is the software handling the model's responses. In the P90 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 the 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? What does that intelligence actually cost the customer? For this this example, let's assume the hourly bill is the same for both deployments and both meet your requirements. At roughly 1 and 1/2 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? 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 you've agreed upon. AKA, 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, and in the case I'm referencing, really, really fast, which makes the whole thing sadder. Uh and the service still failed horrifically. Um 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. 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? Uh SemiAnalysis ClusterMax, we're in version 3.0 at this point, uh assesses operating cap- capability on managed GPU clusters, couple couple hundred, uh growing. Please reach out if you want to be on ClusterMax 4.0. Um we look at provisioning, reliability, monitoring, and security. Uh hands-on testing, documentation, and customer's feedback help us understand how the service runs, not just on a good day, but also when a machine fails. I want to take the chance to reiterate that ClusterMax ratings apply to managed clusters, uh different from bare metal, very different. Um with bare metal, more operating work usually sits with the customer. Uh applying a managed service rating there does not automatically cover every product a provider sells. The tiers are relative to peers. Little bit of a tongue twister. Uh I nailed it, pretty happy with that. Uh \>\> \[laughter\] \>\> and pricing and availability are also important factors in this assessment. Uh these are metrics that do not directly measure uh token output, uh but are incredibly important. Obviously, very important. Uh assessment helps us understand who can deliver. 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 producers still has to cover. Rental price and production cost are different. In our example, GPU provider the GPU provider rents out hours, the inference a 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. If the inference producer owns its own it 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. Uh better operations lowers that cost of useful intelligence. The B200 comparison showed why the amount of output matters. 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 for acceptable token for a comparable workload. Better operations also require investment. Testing an update, deploying it safely, uh and keeping it working take people and money. The extra output has to justify the extra spending. Uh 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. Uh 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. Uh even if you do keep improving, though, your competitors are not sitting still. Uh 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. Um your position on the cost curve depends on what your competitors can deliver, not just yourself. It's a relative measure. Here's a simple hypothetical. We're comparing the same task, the same required quality, using made-up cost units. Uh I like to imagine bars of gold. Uh your full cost per successful task falls from 10 to 8. Uh in the same period, your competitor's falls from 6 to 12. 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 provided customers find the two services equally acceptable. Uh getting better does not automatically move you ahead. Applying the commodity framework makes you realize that you have to compare your 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. Uh two to three years 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? Uh in moments like this, it's important to step back and have a little perspective. Uh take a little historical perspective. Uh 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. Uh 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. Um but I would say if you're a business with leverage, you need to be especially conscientious of this. Being proactive with your built with building your cost advantage uh might be not be as sexy as making your top line bigger, but it matters deeply if you want to survive through a business cycle. Uh that's why you want to build your operating capability and cost advantage while you have the opportunity uh when the sun is shining, when you can raise capital. Uh they matter even more when customers have more choices to make and prices come under pressure. So, how do we make clear what uh the buyer actually gets? Comparable compute needs clear grades. Now, let's look at the compute uh that an intelligence producer is buying. We've already seen that the same chip can deliver different results depending on how it's operated. Uh in two offers for B200 GPU hours can include different services and leave different operating jobs with the customer. 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. What does a rental price benchmark measure? Uh 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. Service scope, contract terms, uh whose prices are sampled and how they're combined all shape that reference point. Uh 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. Uh what can compute futures hedge? 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 monitor in the monitoring failure. Assessing who runs the system helps describe the service buyers get. That helps us define grade 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. 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 you that your customer pays. 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. 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? 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. 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. Uh 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. Ladies and gentlemen, thank you so much for your time today. At SemiAnalysis, 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. Uh ideally more than two actually. Um If you'd like to partner with us, uh contribute, or join the team, we would love to hear from you. We are always hiring great people. Please reach out. Um If this resonated, uh please go ahead and email sales@semianalysis.com uh for partnership opportunities. Uh and if you're interested in potentially joining the team, my email is kennon@semianalysis.com, k e n n o n. Um thank you all for listening and have a fantastic rest of your day. \>\> \[applause\]