Key Takeaways

  • SF Compute partners directly with power owners and regional data centers to turn raw megawatts into institutional GPU clouds without owning real estate.
  • Traditional clouds lock customers into rigid network topologies; redrawing an InfiniBand fabric requires filing support tickets and waiting for manual administrator intervention.
  • SF Compute built programmable subdivision for InfiniBand fabrics, letting platform-as-a-service operators repartition network boundaries on demand through software.
  • Sovereign AI operators outside the United States provide land and energy, while SF Compute supplies cluster architecture and off-take demand from San Francisco startups.

The Flaw in Static InfiniBand Fabrics

Training modern machine learning models requires tight communication between accelerators. When you rent a cluster of GPUs, they connect across high-speed InfiniBand switches to exchange gradients during distributed training runs. On standard public clouds, that network topology is rigid. If you rent a multi-node cluster, you receive a single fixed fabric. If you want to split that capacity between multiple internal teams, or run a platform-as-a-service business on top of the bare metal, you are constrained by whatever initial boundary the cloud provider established.

Conrad identified this friction as a primary barrier to flexible cloud operations. Changing a network boundary typically involves opening a support ticket and waiting for human operators to reconfigure the hardware. SF Compute removed that human layer by writing software that divides network boundaries on demand. As Conrad explains:

“An example is, we allow customers to subdivide their InfiniBand fabric without having to ask us. So, many clouds when you go to buy them, they will give you one InfiniBand fabric. And then if you want to redraw the lines of that InfiniBand fabric, you need to contact them and they will then do something for you.”

Automating that process turns fixed physical wiring into flexible infrastructure. “We're virtualizing data center and making it programmable,” Conrad says. “So, all the stuff that you would have gotten if you had owned the hardware, we're trying to virtualize that.”

How San Francisco Off-Take Solves Sovereign AI

Power companies and regional data center operators around the world sit on gigawatts of electrical capacity, but they lack the expertise to architect high-performance clusters. At the same time, foreign governments want sovereign AI infrastructure operating on domestic soil. The economic problem is utilization. Local developer markets outside major tech centers rarely consume enough compute immediately to justify spending tens of millions of dollars on high-end silicon that depreciates within three to four years.

SF Compute addresses this gap through an operating model Conrad calls supercomputing as a service. Regional operators supply the power and the real estate, while SF Compute handles the cluster design and off-take contracts. Conrad outlines the core interaction:

“Folks come to us and say, you know, I've got X, where X is I've got X megawatts here, and maybe sometimes they mean, I've got a data center that I would like to turn into a GPU cluster.”

To make those remote clusters economically viable, SF Compute pairs foreign capacity with buyers in the Bay Area. Conrad explains:

“Our pitch to sovereign compute is amazing. Let's help you set up a cloud in your own country and we will bring the San Francisco off-take. We'll bring the San Francisco expertise. We'll set up the clusters. That's our whole business.”

Supplying immediate off-take demand changes the financial profile of the buildout. When a regional operator can show guaranteed revenue from San Francisco AI companies, equipment lenders can underwrite GPU hardware purchases at substantially lower interest rates, reducing capital costs across the entire operation.

What to Do With This

Audit your compute vendor's networking flexibility before signing any multi-month reservation. If your engineering team plans to split nodes between distributed training and inference, ask your provider whether InfiniBand repartitioning can be triggered via API or requires a support ticket. If reconfiguring fabrics requires human cloud administrators, demand that the expected maintenance downtime and ticket response windows be written into your service-level agreement.