From the CEO: Our $30M Round and the Next Chapter of Hyperbolic

Today, we’re announcing the close of our oversubscribed $30M Series A1, led by Walden Catalyst. This funding will help us build a global compute grid and a multi-cloud orchestration platform: a flexible way to access GPUs, orchestrate workloads across providers, and sell unused capacity to the market.

As probably the only mathematician building an AI infrastructure + fintech company, I want to share what I’ve learned along the way and how I see Hyperbolic’s future through the lens of math.

Where the name came from

I finished my math PhD at Berkeley in two years. Getting the papers published has taken a little longer.

I wrote three papers during my PhD, but once I started building Hyperbolic, finding time for submissions and revisions became harder. One of them, Guts in Sutured Decompositions and the Thurston Norm, was finally published this month in Geometry & Topology, one of the leading journals in my field. It’s a satisfying way to finally close that chapter.

My research focused on 3-manifolds, topology and hyperbolic geometry. 3-manifolds are spaces that look like ordinary three-dimensional space locally, but can have much more complicated shapes globally. The famous geometrization theorem gives us a way to understand them by decomposing them into pieces with only 8 standard geometric structures, with hyperbolic geometry being one of those structures. Going in the other direction, you can glue pieces together to form a larger 3-manifold (just like we do at Hyperbolic when we glue heterogeneous compute together!).

Inside Seifert–Weber space. A view from within Seifert–Weber space, a hyperbolic 3-manifold. Image: 3-Dimensional Space, by Rémi Coulon, Sabetta Matsumoto, Henry Segerman and Steve Trettel. CC BY-NC-SA 4.0.

My research explored how to cut manifolds along surfaces. A second homology class gives an algebraic way to group surfaces. Within a second homology class, we can choose different maximal collections of disjoint, norm-minimizing surfaces and cut along them.

Those choices can be different. But, under the conditions of our theorem, the essential pieces left after removing certain trivial product regions, called the “guts,” are invariant up to an appropriate equivalence.

The Whitehead link complement. A view inside a model of the space around a two-component link, another example of a 3-manifold. Visualization by Steve Trettel.

What I liked about this result was that different ways of cutting the manifold could still leave something consistent underneath. Studying that kind of structure was a large part of my life for two years.

It also influenced how I approach problems and think about the world. When a system looks very heterogeneous, I tend to ask whether there is a common structure that would make it easier to understand and work with - just like how we think about the compute market.

That’s where the name Hyperbolic came from.

What market making at Citadel Securities taught me

During my second year at Berkeley, I applied to Citadel Securities for an internship. They offered me a full-time role instead. I decided to take it, and finished my PhD before joining in 2020.

I worked as a quantitative researcher on market making. When you buy a stock through a brokerage app, you expect it to happen quickly at a competitive price. Behind that simple experience are systems for pricing, execution, inventory, and risk. I learned how much work goes into making a market feel easy to use.

At Citadel Securities, small improvements in speed and pricing mattered. Later, seeing expensive GPUs sit idle while researchers struggled to get compute was hard to ignore.

As we built Hyperbolic, the connection became clearer. A supplier might want a three-year commitment while a customer needs GPUs for a few weeks. Someone has to bridge that gap and manage the risk. For us, that means making compute reliable while providing liquidity (aka on-demand, spot, and short-term rentals) to make life easier for both sides.

Why I started the company

I started Hyperbolic because I thought access to compute was going to be a major constraint on who could build AI.

For many AI founders, this is the first time building a technology company has meant thinking about compute procurement, infrastructure, capital, the balance sheet, risk, and cash flow all at once. We want these talented people to focus on where they can have the greatest impact, without having to figure all of this out themselves.

Compute is fragmented across different owners and locations, with some teams struggling to get access while others have capacity sitting idle. Differences in hardware and infrastructure make it even harder to connect the two.

The financial decisions are just as difficult. You might need GPUs today but have little certainty about what you’ll need a year from now. Long-term commitments can leave you paying for idle capacity, and paying for compute before customers pay you puts pressure on cash flow.

So we decided to bring fragmented, heterogeneous compute together on one unified platform and make compute flow like electricity.

Investors and advisors

We’re thankful for having investors and advisors to support us. This round is led by Walden Catalyst, with participation from Dell Technologies Capital, General Catalyst, Vista Equity Partners, Cambium Capital, Salience Capital, and other investors.

I’m deeply grateful to Shankar at Walden Catalyst, our lead investor. He has spent countless hours discussing company strategy, partnerships, fundraising, and hiring with me, introduced us to many people, and personally participated in several executive interviews. Whenever I reach out, he always responds quickly.

A special thank you to Lip-Bu Tan! He is incredibly down to earth. When he heard we were announcing our funding, he invited us to his home to take photos and record videos. He has also given me a lot of valuable advice on how to be a good CEO.

Thank you also to Andrew Tan at Salience Capital for the introductions and for helping us build relationships with potential partners.

To our earlier investors, thank you for continuing to support us through the changes in the business.

And thank you to our advisors, including Reynold Xin, Lin Chen, Yangqing Jia, Jon Lin, Ciamac Moallemi, and Yi Ma. I’ve benefited from being able to talk through engineering, infrastructure, finance, and company decisions with people who have done this before.

The team

We’re now around 30 people, and the team is growing quickly.

Behind today’s announcement are years of solving difficult problems, navigating unexpected challenges, and showing up for each other when things get hard. When we started, we didn’t know exactly how this would take shape. This team helped turn our ideas into something real.

Thank you for believing in Hyperbolic, trusting each other, and putting so much of yourselves into what we’re building, even as our plans changed. I feel lucky to be building this with you.

Thank you to Matthew, Peggy, Viktor, Daehan, Ammon, Bikram, Ryan, Austin, Jared, Garrett, Konstantin, Karyna, Chris, Tony, Sally, Nadya, Claire, Karoline, Hong Chan, Zach, Luke, Wen, Cody, Justin, Jerry, Linda, Betty, Mike, Cristian, Kaya, Zach, Trevor, Blu, and many others who helped us along the way.

The product journey

We started building serverless inference in early 2024.

Our team spent a lot of time on inference optimization and achieved strong performance. We wrote about some of the engineering in our deep dive into Hyperbolic inference.

I remember asking ChatGPT for the top three inference providers and seeing Hyperbolic in the answer. That was fun to see.

Andrej Karpathy also called Hyperbolic his favorite place to interact with base models and walked through our platform in his LLM video. I was very happy to see that. We had spent a lot of time building the product, and someone I respected was using it to teach people.

We were early partners with OpenRouter, Artificial Analysis, and Hugging Face. Our relationship with OpenRouter goes back to when it was a small startup at HF0.

In February 2025, Hugging Face added Hyperbolic to its Inference Providers. Since our early 2024 launch, more than 250,000 developers have used Hyperbolic.

But the inference business had a problem: we were losing money.

Open model adoption was still early. Our compute was too expensive. And we didn’t have a good way to reallocate GPUs to other users when inference demand was low. Utilization wasn’t high enough to make the economics work.

We had built something people wanted to use. To make it sustainable, we needed to measure revenue across every GPU-hour we paid for, including the idle ones. The basic economics look like this:

$$\begin{aligned} r_{\mathrm{inference}} &= \frac{\sum_k p_k T_k}{10^6 H} = u\,r_{\mathrm{busy}}\\[4pt] \mathrm{Gross\ margin} &= \frac{r_{\mathrm{inference}}-c}{r_{\mathrm{inference}}} \end{aligned}$$

H is all the GPU-hours paid for by the inference service over a given period. Tₖ is the number of billed tokens in each category, such as input, output, or cached tokens, and pₖ is the actual price received per million of those tokens. Together, they give us revenue per paid GPU-hour.

We can also express that revenue as utilization, u, multiplied by revenue per busy GPU-hour, both measured over the same period. Here, utilization means the share of paid GPU time serving requests. The cost, c, includes compute and other direct delivery costs, averaged over the same paid hours.

Faster inference can increase revenue while the GPUs are busy. But if they spend too much time idle, that may still fail to cover the cost of keeping them available. We needed throughput, utilization, pricing, and supply costs to work together. This measures the economics of delivering the service, before the rest of the company’s expenses.

We needed cheaper and more varied supply. We also needed orchestration and virtualization so that capacity could serve different workloads as demand changed.

Moving into on-demand compute

In early 2025, open models were getting more adoption, and customers started asking us for raw compute. They wanted to run their own models and experiments, with more control than an API gave them.

That fit with a view I’d been developing: open source and agents will make more software easier to replicate, including some of the optimization work that used to require specialized teams. We’re already seeing agents take on CUDA kernel optimization.

My view is that aggregating physical compute around the world and making it easy to access will remain a difficult problem. There are suppliers to integrate, networks to manage, workloads to support, and commercial commitments to make.

We tried different approaches, including Hyper-dOS. Eventually, we decided to go back to first principles and focus on the simplest thing we could deliver to customers: a reliable way to provision GPUs.

Providers such as Gcore and Voltage Park had started offering provisioning APIs. We integrated those APIs and built an on-demand GPU cluster service on top.

We launched our on-demand offering in June 2025 and described the shift in A New Era for Hyperbolic Begins.

We started seeing meaningful revenue traction. By the end of 2025, we had scaled to around $15M ARR. Early customers included Voio, Induction Lab, FlowGPT, Hiddenweight, Bespoke Labs, ARI and Eigen AI.

The demand was much clearer. Customers wanted GPUs, we could provide them, and the revenue grew quickly. That gave us a better direction for the business.

Why orchestration became essential

As supply tightened in 2026, much of the available compute came as bare-metal clusters. Each supplier had a different setup. To keep adding capacity, we needed to handle more of the infrastructure ourselves.

We built Forge, our unified control plane, and our own hypervisor to virtualize compute and support multiple tenants. Forge gives us a common way to onboard and operate heterogeneous clusters, and gives customers a more consistent way to use them.

This was one of the problems we had run into with inference. If capacity was tied to a workload that wasn’t keeping it busy, we needed a way to put it to another use. That required control over the infrastructure underneath the API.

For a pool of GPUs that can support several uses, the revenue side can be written simply:

$$r_{\mathrm{fleet}}=\sum_w u_w r_w, \qquad \sum_w u_w\leq 1$$

Here, $u_w$ is the fraction of the fleet’s GPU-hours allocated to a use, such as inference, on-demand rentals, or reserved capacity, and $r_w$ is the revenue per allocated GPU-hour for that use. Each GPU-hour is counted only once. Unallocated time earns nothing, while reserved capacity can earn revenue even when the customer leaves it idle.

Orchestration gives us more options for allocating that capacity. It can help us fill otherwise idle hours and support services that earn more per hour. The allocation still has to respect hardware compatibility, customer commitments, latency, and the time it takes to move a workload. Higher revenue also has to cover any extra cost.

We now offer managed Kubernetes and have launched Flux, our new inference service built on Forge. Our customers include Modal, Higgsfield, Daytona, HeyGen, Voio, RadixArk, Chai Discovery, and Pika.

We’re now on track to achieve $150M ARR by the end of 2026. To get there, we need to keep adding supply, make it easier to bring clusters online, and help customers get more useful work out of the capacity they buy.

What we’re building next

Our strategy comes down to three things: make more compute accessible, make every GPU-hour more useful, and make it easier for capacity to reach the people who need it. We call these making global compute unified, productive, and liquid.

$$\text{Total useful value} =\sum_{g\in\mathcal{G}} H_g\,u_g\,v_g$$

Here, $H_g$ is the available hours for GPU g over a given period, $u_g$ is the fraction of those hours doing useful work, and $v_g$ is the value created per utilized GPU-hour.

Unified: make more compute accessible. Expand $\mathcal{G}$, the pool of accessible compute, by connecting fragmented suppliers through one platform. That is the idea behind a Global Compute Grid: a place where teams of any size can find, buy, and use compute, with transparent prices for equivalent capacity and terms.

Productive: get more value from every GPU-hour. Increase $v_g$ through better inference, optimization, and services that help customers accomplish more. Managed Kubernetes and inference are available today. Workload as a service and a unified storage offering are on our roadmap. Forge provides the common control plane underneath, so customers can run workloads across providers with less infrastructure work of their own.

Liquid: put unused capacity to work. Increase $u_g$ by making it easier for unused capacity to reach someone who needs it. Customers should be able to resell eligible capacity, and suitable workloads should be able to move between providers as cost, performance, and availability change. Like electricity, compute should be something you can draw on when you need it and make available to others when you don’t.

This matters when customers are making commitments worth hundreds of millions of dollars over three to five years, while their needs can change in months. To bridge that gap, we created the concept of compute market making, which we introduced in our white paper. We’re working with partners to connect these needs and help customers and suppliers manage their commitments and price risk. Planned spot instances and dynamic pricing will also help match supply with demand.

These goals depend on reliable orchestration. A market for compute only works if we can deliver the capacity and run the workload.

Our business goal is to maximize revenue per available GPU-hour through better utilization and services that make the hardware more useful to customers. Ultimately, I care about intelligence per watt: how much useful AI output we can deliver from a given power budget.

What liquidity means in practice

The simplest way to see why liquidity matters is to look at what happens to the compute a customer pays for but doesn’t use.

Consider an AI company that needs 1,000 B300 GPUs at peak demand but only 200 during quieter periods. To secure that capacity, suppose it has to reserve all 1,000 for three years at $4.50 per GPU-hour. If its average utilization is 50%, half of its committed GPU-hours sit idle.

Now suppose it can resell 80% of those idle hours through Hyperbolic, earning a net $4 per GPU-hour. Its effective cost falls from $4.50 to $2.90 per committed GPU-hour, a reduction of roughly 36%. Across 1,000 GPUs, that recovers about $14 million a year.

The hardware hasn’t changed. More of its time is doing useful work, and the original customer recovers part of the cost of capacity it would otherwise leave idle.

Illustrative assumptions. Effective cost is net spending divided by all committed GPU-hours. Net resale proceeds are after fees and incremental costs. Resale depends on contract eligibility, demand, and the ability to reclaim capacity when needed.

Compute for people and agents

Longer term, I want a customer to bring us a model or a workload, tell us their budget and when it needs to finish, and let Hyperbolic handle the infrastructure. The platform would find suitable capacity, provision it, run the workload, and adjust resource allocation as conditions change.

I believe agents will eventually become the largest consumers of compute. They will need a programmable way to discover capacity, acquire it, and run workloads within defined budgets and policies. We want to build that experience for both people and agents.

There is also a financial side to this. GPUs require a lot of capital. If capacity becomes easier to use and trade, and its utilization and revenue become more transparent, it should become easier to value and finance. That could help suppliers and investors manage risk and bring more capacity to market.

The optimization problem

I see our ultimate goal at Hyperbolic as solving this large orchestration and optimization problem: deciding which workloads should run on which GPUs, with which services, and at what time. The broader goal is to maximize total social welfare, meaning the value created by useful AI work after accounting for the resources it consumes. A simplified way to express it is:

$$\max_{x \in \mathcal{F}}\; \underbrace{\left(\sum_{i=1}^{n} V_i(x) - C(x)\right)}_{\text{total social welfare}}$$

Here, x is an allocation of workloads across GPUs, providers, and time. $V_i(x)$ is the value created for customer i, and C(x) is the total resource cost of serving those workloads over the same period. The feasible set, $\mathcal{F}$, respects limits on hardware, power, and networking, along with requirements such as latency and reliability.

Payments between customers and suppliers distribute value. Better allocation and more efficient infrastructure can increase the total value there is to share. That is what I want us to keep optimizing.

Thank you

Building Hyperbolic has taken us in directions I couldn’t have predicted. I’m grateful to everyone who has helped us find our way.

To our team, thank you for putting so much of yourselves into this. To our customers, thank you for trying the product, telling us what wasn’t working, and giving us the chance to improve it. To our investors, advisors, partners, and suppliers, thank you for your trust and support.

I’m happy that I get to work on this with all of you. I can’t wait to see what we build together next.