Who Holds the Switch? Utilization Is an Argument, Control Is a Decision

Three things landed in the same week. A model vendor told the SEC it no longer wants to rent its compute only from the clouds that compete with it. The head of another model vendor reportedly called running AI locally a terrible use of scarce memory. And a third one put the weights of a trillion-parameter model on Hugging Face and said AI is going to be like electricity. If you run IT for a living, you could read these as three opinions about hardware. I read them as three answers to one question: who gets to decide when your AI runs, and for whom?

What actually happened this week?

Let's start with the facts, because the headlines around all three were louder than the documents.

On October 26 Anthropic filed its S-1 with the SEC. Most of the coverage went to revenue and losses, which is fair, it is an IPO filing. But the sentence I keep coming back to sits in the risk factors: the company describes "our ongoing transition from a cloud-only, fixed-time arrangement compute model to a hybrid model", with directly leased chips "hosted in dedicated data center facilities leased and operated on our behalf". And a few lines further it says it plainly: "Certain CSPs from which we obtain substantial compute also develop and offer their own AI models and related services." The consequence, in their own words, is that these relationships "may not always be fully aligned with our long-term interests".

On October 29 a clip of Sam Altman circulated in which he reportedly called local inference a "quite terrible" use of the world's scarce DRAM. The argument behind it, as it was reported, is a utilization argument: a personal computer is busy only around five percent of the time, a data center keeps its memory busy around the clock, so put the memory where it works and rent the intelligence back. I have not seen the full original recording, so I will treat this as what it is, a reported position, not a quote I can hold anybody to.

And on the same day Mistral released the weights of Mistral Large 4, one trillion parameters, 52 billion active, with a quantised version running on four B200 or B300 GPUs, trained on infrastructure in Europe. Pierre Stock, Mistral's VP of Science, put it like this: "AI is going to be like electricity", and no company should depend on someone who can cut off its access "from one day to another".

Three vendors, three positions. And honestly, none of them is wrong.

Is the utilization argument wrong?

No. And I think it is important to say that before arguing with it.

A laptop that sleeps most of the day is not efficient compute, and a GPU that waits for a request is expensive furniture. Anybody who has looked at an enterprise GPU estate knows the pattern. Broadcom's performance team wrote in September that GPU utilization in enterprise and data center environments is often "at or below 50%", citing published research (Gao et al., 2024). In their own tests, consolidating four inference workloads onto one host and sharing its GPUs moved utilization from roughly a third to almost 80 percent, and a batched offline run reached 94 percent. Those are vendor tests, so read them as an indication, not a promise. But the direction is clear.

Here is the point, though. That is not an argument about where AI should run. It is an argument about whether somebody operates it properly. Low utilization is what you get when every team buys its own box and nobody decides who shares and who has priority. A hyperscaler solves that by running a giant shared platform with a scheduler and a business model. You can solve the same problem in your own data center with a shared platform, a scheduler and somebody who is allowed to say no. Yes I know, that last part is the hard one.

So the utilization argument tells you that idle hardware is waste. It does not tell you that renting is the only cure.

Why would a model vendor not want to rent from its competitors?

This is where it gets interesting. The company whose model many of us book as a cloud service is telling investors that it is moving part of its compute into dedicated facilities, leased but built to its own specification, because some of its landlords are also its competitors.

That is not an efficiency decision. If it were only about utilization, renting from the biggest pools would win almost every time. It is a control decision. It is about who decides on capacity, on priority, on the roadmap of the hardware, and what happens when the interests of the landlord and the tenant drift apart.

I do not want to read more into an S-1 than it says. It is a risk disclosure, written by lawyers, and every large company lists its dependencies. But it is a remarkably honest description of something I have seen in IT for more than 30 years: ownership of infrastructure was never really a utilization question. It was a question of who holds the switch.

What does "AI like electricity" really mean for you?

If AI is going to be like electricity, then let's take the analogy seriously.

Nobody runs a diesel generator in the basement because it is efficient. It is not. It sits idle 99 percent of the year, it needs maintenance, it needs fuel that ages, and it needs somebody who tests it regularly. You have it because the grid does not belong to you, and because some processes simply cannot stop when the grid does.

That is exactly the question for AI in the enterprise. Not "local or cloud", but which of your processes will depend on AI in a way that they cannot stop when the provider does. A text summary for the marketing team can wait a day. An agent in the order process, in the support queue or in the security operations team probably cannot.

And the open weights part matters here. For a long time the honest answer for many companies was that there was no open model at the frontier worth running yourself. When a trillion-parameter model runs quantised on four GPUs, the option exists. It is not free, it is not trivial, and it comes with a full operating responsibility. But it exists, and an option you have is a different starting position in every negotiation than an option you do not have.

So where should your AI run?

My answer is: wherever you can answer four questions. I look at them as four separate bills, and every placement decision pays all four, just to different people.

1. Utilization: who pays for idle? In the cloud, the provider pays for idle and charges you a margin for it. On your own platform, you pay for idle directly, unless you share, schedule and measure. If you cannot show your GPU utilization per month, you do not have a placement strategy, you have a purchasing history.

2. Dependency: who can cut you off? Access can end through pricing, through a policy change, through capacity allocation or through a contract. For every AI-dependent process you should know who can stop it "from one day to another", and what your fallback is. A fallback that only exists in a slide deck is not a fallback.

3. Control: who decides what runs, when and for whom? Priority is the quiet part of every AI platform. When capacity is short, somebody decides whose workload waits. If that somebody is your provider's scheduler, you have outsourced a business decision without noticing.

4. Operation: who carries the operating promise? Running models yourself means patching, access control, logging, outbound traffic rules and an on-call rotation. Self-hosted is not a security feature, it is a signature under the operating responsibility. If you are not ready to sign it, renting is the honest choice.

Where should your AI run? Four bills: utilization, dependency, control, operation

Most companies will end up hybrid, and that is fine. What is not fine is ending up hybrid by accident, because one team bought GPUs, another booked an API and a third connected an agent to a SaaS tool, and nobody ever made the decision for the company as a whole.

What should IT leadership ask on Monday?

Five questions. None of them needs a new tool, all of them need an owner.

  1. Which of our business processes would stop, or degrade noticeably, if our main AI provider were unavailable for a week?
  2. Do we know the actual utilization of the GPUs we already own, and who decides which workload gets priority when capacity is short?
  3. For each external AI service we depend on, what are the exit terms, where do our data and fine-tuned artifacts live, and how fast could we move them?
  4. Have we tested at least one open-weight model against one of our real workloads, so that "we could run it ourselves" is a measured statement and not a hope?
  5. Who in our organization is allowed to make the placement decision for AI workloads, and has that person actually made it, in writing?

Final thoughts...

The utilization argument is correct, and it is incomplete. Efficiency tells you where compute is cheapest. It does not tell you who decides when it runs, who can switch it off, and who you call when it stops. This week one model vendor argued for efficiency, another for independence, and a third quietly told its investors it wants a bit of both. That is not confusion. That is the decision every IT leadership team has to make for itself, and the worst version is the one where the decision gets made by whoever bought first.

Rent what you can afford to lose. Own what you cannot. And decide which is which before somebody else does. #DecideOrGoHome

At comdivision we spend most of our time in exactly this space, helping IT teams decide where workloads, including AI, should run and then operating that decision. If you want to discuss where your AI belongs, reach out to me.

Sources

  • Anthropic, PBC, Form S-1 Registration Statement, SEC, filed October 26, 2026: sec.gov
  • The Next Web, "Mistral releases open weights for its 1 trillion-parameter Large 4 model", Ana-Maria Stanciuc, October 29, 2026: thenextweb.com
  • The Singularity Project, "The 95% Problem: Sam Altman's Case Against Your Computer", Steven Vincent, October 30, 2026 (secondary report of the Altman clip): thesingularityproject.ai
  • VMware Cloud Foundation Blog, "Optimizing AI Deployments with VMware Cloud Foundation (Part 2)", Lan Vu, Hari Sivaraman, Uday Kurkure, September 28, 2026 (vendor tests): blogs.vmware.com

Related News

Whose Clock Are You Patching On?
This week a PHP patch shipped a day early because the embargo leaked, kernel bug reports...
The Week Agents Ran Out of Benefit of the Doubt
Five headlines in one week, and all of them say the same thing: the question is not...
VMware Cloud Foundation im Mittelstand: Ein praktischer Guide
VMware Cloud Foundation (VCF) ist die Antwort auf eine der drängendsten Fragen...
VCF 9.1 Management Domain Deployment and VCF Installer walkthrough
In this blog post, we will go through the initial preparation and deployment of VCF 9.1...
VMware Cloud Foundation 9.1: Cost Efficiency Meets Operational Simplicity
With the official launch of VMware Cloud Foundation (VCF) 9.1, Broadcom delivers a...
Start into the VCF9 era - my new homelab
Introduction Sooner or later everyone has to and now I started into the whole VCF9 era...
Why Our Customers Are Obsessed with VMware Cloud Foundation 9
At comdivision, we’ve helped hundreds of organisations navigate the shift from...
dummy_contact-banner_get-in-touch

Questions? Get in touch!

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus.