Skip to main content

Why LUMI AI Factory is shifting supercomputing to a software-defined platform

Pekka Manninen

"Supercomputers used to work the same way for decades, and now there's a complete paradigm shift in how people want to use them" - Pekka Manninen

Credit: CSC

Pekka Manninen, Director of Science and Technology at CSC – IT Center for Science and Director of the LUMI AI Factory, explains how the organisation is evolving its flagship LUMI supercomputer into a software-defined platform capable of serving simulation, AI training, and the rapidly growing demand for inference from a single, flexible infrastructure.

Manninen discusses why double-precision performance still matters to a legacy-minded scientific user base, and how the convergence of HPC and AI communities is reshaping everything from system architecture to user support, including the shift toward AI assistants that complement existing support experts and troubleshoot with researchers in real time. 
Can you tell me about your roles at CSC?

Pekka Manninen: I have the title of Director of Science and Technology. I lead a unit that is in charge of our scientific computing, basically research services that support our activities in AI and high-performance computing, but also technology development like quantum computing, digital twin technologies, chip technologies, and so on. I also lead the LUMI AI Factory and the current LUMI supercomputer.

The AI Factory is a service centre, but it also comes with its own infrastructure. We started off the AI Factory using the current LUMI supercomputer as the infrastructure. But we are meanwhile also building new infrastructure; there will be a LUMI AI Factory supercomputer, a kind of LUMI 2 or LUMI AI, and a connected quantum computer, LUMI-Q. These are part of the AI Factory initiative. But while building it, we've been building the services on top of the existing LUMI supercomputer.

Does that give you a chance to better understand the users?

PM: That's one aspect. It gives us valuable feedback on what's important and what isn't for building the new infrastructure. But at the same time, using the old HPC infrastructure as the platform for the AI Factory at the outset enabled us to launch it as quickly as possible. There was a lot of political pressure in the European Union to deploy these hubs for AI and industry AI adoption, and that was our way of responding. We already had this supercomputer, so why not start with that? No matter how fast you want to be, it always takes time to build computing infrastructure. It's impossible to deploy that the following week, no matter how much money you have. So that's why we decided to start delivering as quickly as possible and let the new infrastructure come up behind it.

How do you go about provisioning an AI supercomputer today? Do you have to make compromises on the infrastructure you want to provide?

PM: We just finalised the LUMI AI contract, and of course we're not immune; we did get hit by the memory and SSD price surges. We got the system we wanted in terms of functionality, architecture, and vision, but we ended up with fewer nodes than we originally planned when the budget was set. So yes, it's there, and HPC procurements are by no means immune to it.

How are the computational demands of your user group changing over time?

PM: I don't think there's a certain base of workloads and demand that's always there. If we want to be a versatile innovation platform where different fields of science can come together, and academia can meet industry, we need a highly versatile infrastructure and a wide range of capabilities. I try to identify where different needs of the modelling and simulation community and of artificial intelligence can be met on the same platform. That's the platform's basic remit; the workloads demanding these capabilities remain.

We need capabilities for simulation science and exascale computing. There is still a big need for AI training, but the emerging thing that now needs to be addressed is inference. There's an increasing scientific inference load, and we should have a good answer for how we cater for it on an HPC platform, rather than just deploying it on some cloud platform. From an R&D perspective, it's becoming part of the development cycle of how researchers work; there will be more and more inference loads, more automation, and scientific or AI agents. AI has penetrated R&D completely. Those are the main differences from building a supercomputer two, four, or five years ago.

Does that change the technology or how you build your infrastructure?

PM: There are multiple takes on this across the HPC provider community, and we'll see which one is the right, most optimal one. Our take is to choose a cheap, "take all comers," jack-of-all-trades-style GPU so we can support simulation, training, and inference on the same GPU. It's not necessarily optimal for any one of them, but it can do them all. The main thing on the software and user environment side is: how do we cater for a batch-queue supercomputer and interactive inference on the same platform? Our answer is a software-defined platform that lets us run different tenants on the same HPC system, dynamically hosting inference capabilities, the batch supercomputer, or even software-defined clusters for users on the same platform.

The main difference I see is a shift away from a monolithic, highly homogeneous system toward a more platform-oriented way of thinking, converging and bringing ideas from the cloud world into HPC system design. We have different hardware modalities in the platform, but on a software level we can carve out tenants, where one tenant can consist of multiple hardware capabilities, and at that tenant level we design what they're meant for: whether it's a batch-job supercomputer that looks and feels like an HPC system, or something where the user group defines their own stack, or a place to run inference workloads.

With this approach, I don't need to predict each user's needs in advance; I just have different hardware modalities, and with software definitions, I can mix and match these capabilities to create a valid use case.

What lessons have you learned from designing and operating LUMI?

PM: There are two things in particular that the AI community, and industry or enterprise users, need us to serve better since the AI Factories have a mandate to do that. We've understood the importance of elevated security and confidential computing support, built into the system from the ground up. The world has changed over the past few years, and IT security is even more important than it used to be. Then there are the different ways of working with very complex, orchestrated workflows, and how to support them.

It's no longer just one researcher submitting jobs and analysing results; that's going to be a minority use case in reality, even within the modelling community. Ways of working have become very complex, and agentic AI is increasingly important in research, too. More people are orchestrating complex sets of different codes, different analyses, and incoming dynamic data.

There's a lot more going on in workloads today than there used to be, and building a platform for that reality is something we needed to do. Also, moving on from compiling a binary and running it, people are increasingly using frameworks and high-level libraries, which puts different demands on the computing environment and different kinds of API access to the system – so you can execute things without just the use of SSH.

Supercomputers used to work the same way for decades, and now there's a complete paradigm shift in how people want to use them, so new generations of systems need to respond to that to stay relevant and fulfil our mandate of catalysing new discoveries.

That's one thing supporting new usage patterns: confidential computing. The value of data, large input datasets, is another thing; it's not only about output data, as it used to be in HPC; having good, well-curated, well-maintained datasets is a third big difference in what we're doing differently now. And then there's user support.

For decades it worked like this: if there was a problem, the user logged in, worked, and if something didn't work and they couldn't figure it out themselves, they'd send an email, someone would read it and start investigating, and after some exchange the problem was solved and the researcher could continue.

We want to build a new system that can help the user right away by running different AI assistants for productivity, troubleshooting, programming, orchestration, and even generating ideas for the research problem itself. Having a specialist sitting next to the user all the time, but as an AI. Building and leveraging AI capabilities for user support is a major differentiator between the LUMI generation and LUMI AI.

Pekka Manninen is the Director of Science and Technology at CSC and the Director of the LUMI AI Factory.

Topics

Media Partners