Heterogeneous computing has quickly come to mean packing a couple of CPUs and one-or-many accelerators, mostly GPUs, onto the same node. Today, a one-such-node system has become the standard AI server offered by dozens of vendors. This is not to diminish the many advances (interconnect, memory, software, packaging, etc.) critical to delivering these powerful systems. Assemble a great many heterogeneous nodes together and, voila, you have a modern supercomputer. Think Summit and a host of other recent systems.
Now, the rise of new AI chips is prompting a re-think of that formula, at least in large-scale environments. Lawrence Livermore National Laboratory (LLNL) is a good example of early efforts to explore what’s being called System Level Heterogeneity. In his opening keynote at the AI Systems Summit this week, Bronis de Supinski, CTO of LLNL’s Livermore Computing Center, described how the lab has integrated two AI-specific systems – one from Cerebras and one from SambaNova – into two existing LLNL systems (Lassen (~23 petaflops) and Corona (~10 petaflops)) to achieve system level heterogeneity.

The early results are impressive said de Supinski, citing a ~5x performance improvement per transistor over GPUs[i] for both the Cerebras and SambaNova solutions. For one application run on Cerebras he reported a 37x improvement per Volta GPU and 15x improvement per compute node. Importantly, he said LLNL is just getting started in its system level heterogeneity exploration and added the forthcoming El Capitan exascale system being built at LLNL will have elements of system level heterogeneity though he did not go into great detail.
Leaving aside the richness of resources the national labs possess, de Supinski came across as a believer in the new direction and set stage nicely in his early remarks:
“[W]e build a lot of supercomputers at Livermore Computing and many of those systems are heterogeneous, but they’re only heterogeneous at the node level. However, we are seeing a large number of very interesting devices being developed today, specifically things to accelerate AI portions of our workload. Frankly, it would not be cost effective for us to deploy these resources on every compute node,” he said. “Partly, that’s because our workloads are primarily physics-based simulations and many of our jobs would make no use of those resources. They would sit idle much of the time. In addition, many of these accelerators are, frankly, not designed to be deployed one per compute node; they are more expensive than we want to put on every compute node [and] more importantly, they’re would not be most effective [deployed] that way.
“[This has] led us to evolving our system design for these new workloads that we see, in particular one that we call cognitive simulation [which] we’re focused on today. We’re also looking at ways to develop [capabilities] for in situ or in transit data analysis. What this ends up leading us to is something that we call system level heterogeneity, which involves a system with diverse node types or even diverse resource types by design,” said de Supinski.
De Supinski didn’t downplay the challenges.
“Systems level heterogeneity raises many questions that we haven’t dealt with in our previous design system architecture designs. So how do we partition the work and handle the interactions across these diverse types of resources? What is the right mix of these different resource types? A particularly important question is as we disaggregate these resources, will the network bandwidth be sufficient and the network latency be sufficient for us to bring them together to serve the overall needs of individual jobs? Right?
“Can we have a job that uses these resources that are spread across the network? And this leads us to looking at how do we need to adapt our applications to use heterogeneity at the system level. Likely, this requires significantly more asynchrony, the ability to have one aspect of a simulation going on, concurrently to another, and then having them come together at perhaps even individual time step basis to then mix the results of those different pieces of that of the application. We are actively pursuing these directions at Livermore,” he said.
Much of the Cerebras material presented was familiar, reflecting de Supinski’s fall presentation at the AI Hardware Summit. (See HPCwire coverage, LLNL, ANL and GSK Provide Early Glimpse into Cerebras AI System Performance). Both the CS1-Lassen and SN10-Corona ‘systems’ use an abundance of InfiniBand pipes to connect to each other. The CS-1 system is hot – perhaps not a surprise given the giant size of its wafer-scale ‘chip’. “It’s got 400,000 AI optimized cores. It’s actually a 20-kilowatt device. So in fact, it’s one of the hottest compute devices on the planet,” said de Supinski.
On the issue of whether even with advanced connectivity at all levels the systems can talk to each other quickly enough, de Supinski was encouraged thus far but these are early days.
Both projects relied heavily on help from “What we call an Artificial Intelligence Center of Excellence (AI CoE). This is where we closely work with experts at Cerebras or SambaNova so that our applications can make use of these unique resources as part of our simulation workloads,” said de Supinski.
He said LLNL hasn’t had sufficient time to finely characterize the differences in strengths and weaknesses between the CS-1 and SN10-8R. “We know that they have some different capabilities in terms of the hardware and software. Some of the hardware we’re seeing is a little more maybe advanced with the Cerebras stuff, some of the software aspects or maybe further along with SambaNova, but they’re fairly similar,” said de Supinski; he estimates by SC21 they should have clearer sense of how the systems compare.
De Supinski is impressed with SambaNova’s multi-tenancy capabilities.
“An interesting aspect of the SN10-8R is that it’s got good support for doing multi tenancy, which is an aspect in the long-term we absolutely have to have support for in order to use this system level heterogeneity today. So now, we can run different jobs on that same resource, and just as importantly, we can run different models or different copies of the same model, and be able to actually send inference requests from different compute nodes to those different models and have it quickly process them and send them back,” he said.
De Supinski dug a little deeper into how the two systems handle a inertial confinement fusion simulation run at LLNL. A persistent challenge is adequately simulating at the needed time-steps and being able to modify model parameters. For this exercise, the AI portion of the model calculation is done on the specialized AI resource.
“On the CS-1, we’re doing approximately 18 million samples per second. (See slide below) Those samples take input from multiple zones running on individual compute nodes, [and] each of those zones involves 42 single-precision numbers, requiring about 3.2 gigabytes per second per zone. We’re then able to get those answers to come back, and those result in three interpolated scalars per zone. So less data, but still a fairly significant amount of data per time-step. Running over the overall simulation, what we see is we get roughly 37x higher performance than we get running on a single Volta and more than 15 times higher performance [that] running on individual compute nodes – a fairly significant performance boost.
Running a similar job on the SN10-8R, he said, “Here (slide below) we’re looking at the effect of batch size. So when you look at what we’re doing, we’re actually sending fairly small batches. And a key aspect of these AI accelerators is that they provide significantly higher performance on small batch sizes. So we’re, we’re really looking at running in this kind of region of the batch sizes (steep curve section) and we can get significant throughput, even on these small numbers of samples. Since we’re able to support multiple models on the SN10-8r, we can actually go about getting enough performance to justify sending the data across the network, running the AI model, and getting the neural network getting the results of that neural network back in time to continue with that within each time-step.”
Looking ahead, de Supinski offered a few thoughts on both El Capitan and LLNL’s forthcoming CTS-2 system procurement.
“El Capitan will be a little bit later than then the Frontier system. There’ll be a slightly different architecture as well. One of the differences I’ve spoken about recently is that we’ll be deploying something we call Rabbit modules, which allow us to essentially deploy data nodes that can work to speed up file system performance, but also to allow us to do some data analysis before we actually push things all the way back to our parallel file system,” said de Supinski. (see HPCwire coverage, Livermore’s El Capitan Supercomputer to Debut HPE ‘Rabbit’ Near Node Local Storage)
“We are also in the process of running our CTS-2 RFPs – the ASC CTS 2 procurement. The responses have been back for a while now, and expect the announcement of what exactly we’re getting under CTS-2 in general to come in about two months from now. We expect under that contract to continue exploring system level heterogeneity. We will be deploying similar systems under that [which] allow us to look at cognitive simulation and the benefits of system level heterogeneity as well as other systems that will support vastly improved data analysis as part of the overall workload,” he said.
“In order to support the system level heterogeneity, you need some advanced advances in the system software. A very important aspect of that is that we’re developing the next generation resource manager that we call Flux. So rather than running Slurm or [what we currently] run on, Lassen and Sierra that I won’t mentioned by name, we will be running Flux on the CTS-2 systems and on El Capitan. This resource manager allows us to treat different resources in different ways and to easily allocate these diverse resources and recognizing locality between them.”
De Supinski’s keynote was quick-moving but substantive and worth watching. Link to video: https://vimeo.com/531218771/b7d9b279a2
Editor’s Note:
AI Systems Summit organizer, Kiasco Research, has made the video of de Supinski’s keynote freely available. Free on demand passes to recordings of the other sessions “are available to members of research institutions, government agencies, and national labs, whilst corporate entities can purchase a pass for a small fee.”
[i] de Supinski said the performance improvement per transistor metric is preferred because it bakes in several items and provides a better measure of “performance per dollar we’re achieving.”