算力大宗商品化与运营商能力分化：同等GPU如何产生50%的产出差距

Thank you everyone for taking the time to be here today. My name is Oliver Cannon. 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 Anthropic. 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. 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. 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? A lot of tech investors or technologists may not be familiar with this framework, so a little crash course. In a commodity market, a product is a product. Buyers treat different units as interchangeable. Copper is copper, wheat is wheat. In our case, the product is useful intelligence. That is to say, customers do not care what chip you run on. Cost matters. Production cost sets a floor on how low a price a producer can sustain. If prices fall, high-cost producers lose money and are forced to exit. Low-cost producers can stay profitable even at lower prices and take market share.

Over time, this dynamic pushes high-cost producers out of the market. And as market intelligence improves, buyers learn what products are actually available and what they should cost. That reduces the ability of high-cost producers to charge more for the same product. The winners are not the producers that shout the loudest. The winners are the producers that can deliver the product at the lowest cost over time.

Now, that brings us to this diagram. How does compute turn into useful intelligence? We start with hardware and electricity, GPUs for 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 the intelligence you actually produce, not just what's theoretically possible.

Now, this transition isn't frictionless. A whole list of things can happen between buying hardware and producing useful intelligence. GPUs may go unused or idle. Models may fail to run on particular instances. Network issues may slow training or drop inference requests. Software errors can waste compute hours. Security vulnerabilities can expose data or systems. Capacity may sit empty when demand drops. Workloads may need to be moved when instances fail. These are practical, everyday problems that operators have to deal with.

Let me give you a real-world example. It's easy to say, "Hey, secure endpoints and enforce authentication." But in practice, especially across multi-tenant environments, it's very easy to mess this up. In this incident, a provider left an endpoint unauthenticated, exposing not only customer data but internal 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—and the service still failed horrifically.

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 framework comes out that could increase throughput by 50%. An operator with the expertise to test, optimize, and deploy it can deliver more intelligence from the same hardware. An operator that struggles to keep the cluster stable won't be able to capture that gain. In this example, the difference in operating capability is the difference between capturing a 50% performance improvement and leaving it on the table. Over time, that compounding advantage adds up.

Now let's translate this into economics. Here's a basic model that shows how compute costs flow through to the customer. We're going to compare two entities: the GPU provider and the inference producer. Now, sometimes these are the same entity, but for the sake of clarity in this presentation, we'll keep them separate.

The GPU provider buys hardware, power, space, and networking, and they rent it out on an hourly basis. The inference producer rents those GPUs, applies its software and operations, and sells finished intelligence to customers. The inference producer's goal is to minimize the cost per successful response or task.

That brings us to the difference between rental price and production cost. This is the single biggest misconception I see people make in this market, so let's make sure we cover it. Rental price and production cost are different. In our example, 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.

If the inference producer spends $100 on GPU hours and delivers 10 successful tasks, the cost per task is $10. If better operations allow the inference producer to deliver 20 successful tasks from that same $100 of compute, the cost per task falls to $5. The rental price was the same in both cases. The production cost was cut in half. The operator made the difference.

Now let's add competitive dynamics to the picture. When multiple producers compete in the same market, relative capability determines who can price more aggressively and who earns a better margin. Consider this dynamic cost comparison. Both producers improve over time. Producer A cuts their full cost per successful task from $10 to $8. In the same period, your competitor's falls from $6 to $4 (or $12 down to lower). 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, provided customers find the two services equally acceptable. Getting better does not automatically move you ahead.

Applying the commodity framework doesn't stop at understanding costs. In commodity markets, standardized contracts and grades help buyers and sellers transact with confidence. As compute matures as a commodity, we should expect similar mechanisms to emerge.

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. 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 set of services and terms that a buyer can expect to receive. It gives the market a shared reference point for what is being bought and sold. A buyer who wants to run their own software stack might prefer a bare-metal grade that leaves operations to them. Another buyer might want a fully managed service that handles operations and guarantees a certain level of performance. Grades let both buyers find what they need and understand what they're paying for.

Now let's turn to hedging. Financial tools like futures and swaps help participants manage the risk of price changes in commodity markets. In compute, an inference producer might want to lock in the rental price of GPUs to protect against future price spikes. But it's important to understand the limits of what a hedge can do. A hedge can manage price risk. It cannot manage operational risk. A financial contract won't fix a failed deployment or ensure 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 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 useful output. That's what determines your final cost per task, and that's what determines whether you survive in a competitive market.

SemiAnalysis helps buyers and investors understand these dynamics. We evaluate compute providers not just on the hardware they have, but on how effectively they operate it. We look at the full stack: the hardware, the software, the operations, and the economics. That gives our clients a clearer picture of who can deliver intelligence at the lowest cost over the full life 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.

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—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. We are always hiring great people. Please reach out.

If this resonated, please go ahead and email sales@semianalysis.com for partnership opportunities. And if you're interested in potentially joining the team, my email is kennon@semianalysis.com, k-e-n-n-o-n. Thank you all for listening, and have a fantastic rest of your day.