When Google launched its Hypercomputer earlier this month (December 2023), the first reaction was, “Say what?” It turns out that the Hypercomputer is Google’s take on a modular supercomputer with a healthy dose of its homegrown TPU v5p AI accelerators, which were also announced this month.
The modular design also allows workloads to be sliced up between TPUs and GPUs, with Google’s software tools doing the provisioning and orchestration in the background. Theoretically, if Google were to add a quantum computer to the Google Cloud, it could also be plugged into the Hypercomputer.
While the Hypercomputer was advertised as an AI supercomputer, the good news is that the system also runs scientific computing applications.
We had more questions, so HPCwire chatted with Mark Lohmeyer, vice president and general manager of compute and machine-learning infrastructure at Google Cloud. He talked about the Hypercomputer’s design, the TPU v5p, how customers can consume AI on the supercomputer, and the system’s relevance in HPC.
Why is it called a Hypercomputer?
If you look back at the growth in the size of models – it’s been growing on average by 10x per year for the last five years. That is astonishing exponential growth in the size of models, enabling them with incredibly powerful and astounding capabilities. However, looking at what that means for the infrastructure needed to train, tune, and serve them, it’s pretty clear that piecemeal approaches won’t scale for what we need to do now or in the future.
The AI Hypercomputer architecture is an AI-optimized supercomputing architecture specifically optimized for the needs of those workloads now and in the future. The core idea was that we need to do something different than the past. Fundamentally, we need to design this Hypercomputer at a systems level – not just the computer, not just the chips, not just any one component, but end-to-end as a coherent system to meet needs now and in the future. This design means looking across hardware – compute, network, and storage – the software on top that tunes, optimizes, and orchestrates workloads, and also the consumption models, which are evolving in AI in ways different than for general-purpose workloads.
We think all three layers are important, and the way they work together as an integrated system to deliver performance, efficiency, cost-effectiveness, and scale for the next generation of AI workloads.
TPUv5 feels like the first TPU that is actually available to everyone. TPUv4 seemed limited in availability or was targeted at a specific audience.
We looked at how our customers want to use this computer infrastructure for their AI workloads. First, there’s experimentation – typically short periods of time, but you need guaranteed capacity. Then there’s training – you need large capacity for long periods, weeks, or months. From there, you go to tuning or fine-tuning – shorter duration, typically less capacity needed, and sometimes flexibility in timing. And then there’s serving – an ongoing operation that scales with users, more predictable over time.
We needed to enable consumption models fitting those use cases. The starting point was supporting existing cloud models – committed use discounts, on-demand, spot – so we support all of those. But we recently announced Dynamic Workload Scheduler, which adds to those models and fits some shorter duration use cases with timing flexibility.
Within Scheduler, we have two modes. Flex Start tells the system through an API – I need this capacity for this time period in this location. We start that workload as soon as we can based on availability. Once it starts, we guarantee completion. This is great for experimentation – flexibility on start time but guaranteed completion. It can also be good for things like offline inference with some delay tolerance.
The second mode is Calendar mode, where you specify a start/end time and capacity. This mode works well for contained training jobs and fine-tuning fitting that window.
Importantly, the entire stack must be orchestrated coherently against the consumption model – not just providing the capacity. For a seven-day training job, you want those GPUs co-located on a high bandwidth network, able to place that workload on the right topology to get the right outcome. You wouldn’t want them to be distributed across one GPU here and one GPU somewhere completely different.
We’ve really designed that system end-to-end to be able to accommodate those specific needs to be able to meet each of those use case needs in a very performant and efficient and, frankly, cost-effective way.
The nice thing about this model from a cost-effectiveness perspective is you’re only paying for that job when you’re actually using those resources. If half the time you don’t need the resources, you’re not paying for it. It can help reduce the cost of some of these use cases in a meaningful way.
How do TPUs and GPUs fit within the Hypercomputer concept?
When we announced the Hypercomputer, there were two new pieces we talked about. First, TPU v5p is part of this integrated architecture. Second is the Dynamic Workload Scheduler, which provides flexible consumption models optimized for AI. You can think about the architecture as composable.
Customers can combine elements based on workload needs. It supports Nvidia GPUs, for example — still with the consistent experience and architectural principles, but composable. So, we give customers choice and flexibility whether they want TPUs or Nvidia GPUs.
Is there a physical representation of the Hypercomputer? What does it look like?
A single TPU v5p physical pod consists of 8960 TPU chips connected over an OCS (optical circuit switch) fabric in a 3D torus topology. The chips are deployed over multiple racks of servers – multiple racks per row, with multiple rows per TPU v5p pod. The physical footprint is the size of a football field. It’s a significant physical deployment, with multiple customers leveraging individual slices within that broader infrastructure.
Does the optical switching tech work with the Nvidia GPUs?
OCS is specific to the TPU deployment, this gives us the ability to dynamically reconfigure slices of TPU capacity.
A customer can request one amount, and others can request other amounts. We can carve out those capacity slices, with the TPUs within still connected in a high bandwidth, low latency way for their jobs. We continue to innovate at the networking level for AI in the Hypercomputer. That’s a key part of designing coherent system-level architectures.
In the case of GPUs, we use GPU-optimized interconnect technologies like our Titanium offload system and technology, which is based on the Nvidia H100 GPUs.
While specific technologies and implementations might differ between CPUs and GPUs, from the customer’s perspective accessing the integrated system, the design principles are consistent.
Customers get the same consumption surface and have support for the same frameworks. It scales in the same way through GKE’s (Google Kubernetes Engine) Dynamic Workload Scheduler for shorter-term jobs. So they get a consistent consumption experience— consistency even though there may be different optimizations underlying technologies.
The Hypercomputer is being mentioned for AI. But does it work with scientific computing, like in HPC?
Because we enable GPUs and the Hypercomputer architecture with GKE orchestration, Anthos container orchestration, GCP (Google Cloud Platform), and frameworks, the consumption models are available for any customer and use case. These capabilities can also be relevant for general-purpose supercomputing, like simulations since the same concepts apply.
Is the Hypercomputer a fundamental redesign of a supercomputer? Or is it a different kind of system designed for the cloud consumption model?
We see the AI Hypercomputer architecture as a model for the future. We see the size of models and workloads growing exponentially and end-user consumption growing exponentially. We architected the AI Hypercomputer to scale to meet future needs based on that core principle.
Going forward, we will continue expanding its capabilities at every level – hardware for compute, network, and storage; software for frameworks, compilers and orchestration with Kubernetes. We will continue expanding ways for customers to consume. Think of that not as a fundamental redesign but an expansion of the existing architecture since we built it with the future in mind.
How can HPC customers stand up models for TPU v5p and Hypercomputer?
We’ve tuned this out of the box. We’ve taken our Gemini model, which will be available through Vertex AI, but also third-party models, open-source models, and our ecosystem partners that are building models. We’ve tuned this architecture with each of those different models and actually with the different use cases. The core idea is out of the box; it’s designed to work well: great performance, great efficiency, and very cost-effective for the most common deployment scenarios that we see out there.
When a customer is taking one of those things and further tuning, tuning the model — maybe to their specific use cases, specific use cases — we’ll work with them to make sure it’s performing optimally as they further tune it to their unique needs.
Is the Hypercomputer modular system? For example, can you add a quantum computer to this, like you add H100 GPUs to work alongside TPUs?
It’s modular both at the hardware level as well as the software level. For example, at the software level, we announced something called Multislice, which allows you to basically aggregate, by leveraging software, individual discrete hardware slices and make them look like a single larger virtual hardware slice from the perspective of the model being trained on top of it.
There will be innovations that happen in individual hardware elements and software elements. You want to be able to quickly integrate those into the architecture and enable customers to take advantage of them.
Do you see what software needs you have and then scale the hardware?
I think it is really through co-design that we can create this coherent system. That is what helps us design this to scale over time. We’ve been in this space for over a decade now with our fifth generation of TPU technologies with v5, and throughout that lifecycle, it’s been this co-design, coherent architecture approach.
To a certain degree, Google is uniquely able to do that because of our depth in research, our in-house models, our ecosystem of partner models, our experience scaling those, and applications that serve multiple billions of consumers on top of this infrastructure. That depth of experience has enabled us to scale from TPU v1 to v5 and has led to the tremendous increase in capabilities that we’ve been able to deliver.