Research institutions have long faced a frustrating technical problem: their traditional supercomputers and newer AI systems operate as completely separate worlds, forcing scientists to manually shuffle data between incompatible environments. Red Hat's latest approach to AI infrastructure shows how organizations can finally unify these two computing paradigms, allowing researchers to access AI capabilities without abandoning the tools they've relied on for decades .

What's the Problem With Keeping HPC and AI Separate?

Most research institutions operate two distinct computing environments. The first is the traditional high-performance computing (HPC) cluster, which runs on Slurm, a workload manager that powers many of the world's top supercomputers. The second is the newer Kubernetes-based cloud-native AI ecosystem, which handles machine learning workloads and generative AI applications. The challenge is that these two systems don't talk to each other .

In practice, this separation creates real operational headaches. Data artifacts must be moved manually between environments. GPU capacity often sits idle in the HPC cluster during low-utilization windows while the Kubernetes environment is queuing jobs waiting for resources. Researchers who submit jobs through Slurm cannot easily access AI models running on Kubernetes, and vice versa. Platform engineers must maintain two separate schedulers, two resource accounting systems, and two operational teams .

How Are Research Platforms Solving This Convergence Challenge?

Red Hat's solution centers on a reference architecture that brings together several key components. The foundation is Red Hat OpenShift, a Kubernetes distribution that provides container orchestration, namespace governance, role-based access control, persistent storage integration, and operational tooling needed to run shared AI infrastructure at institutional scale .

On top of OpenShift sits Red Hat OpenShift AI, which adds AI-specific capabilities including model serving, model customization, pipeline orchestration, notebook environments for data scientists, and observability for AI workloads. This transforms the base Kubernetes platform into an environment where researchers can train, fine-tune, evaluate, deploy, and monitor models through a governed, self-service interface without each team needing to manage their own machine learning infrastructure .

The critical innovation is the Slinky operator, a Kubernetes tool that deploys and manages Slurm components as containerized workloads inside OpenShift. This allows Slurm batch jobs and Kubernetes-native AI workloads to share the same GPU pool, with idle capacity between large simulation jobs automatically allocated to inference or fine-tuning workloads without manual intervention .

Steps to Implement a Unified Research AI Platform

• Deploy OpenShift as the foundation: Establish Red Hat OpenShift as your container orchestration layer, which provides the governance, access control, and operational tooling needed for institutional-scale AI infrastructure.
• Add OpenShift AI capabilities: Layer Red Hat OpenShift AI on top to enable model serving, customization, pipeline orchestration, and notebook environments that researchers can access through self-service interfaces.
• Implement Slinky for HPC convergence: Deploy the Slinky operator to run Slurm components as containerized workloads inside OpenShift, allowing traditional HPC jobs and AI workloads to share the same GPU resources.
• Establish Models-as-a-Service: Create a shared AI platform model where platform engineers deploy and manage AI models as shared services, exposing them to researchers via APIs rather than requiring each team to manage their own infrastructure.

What Practical Benefits Does This Convergence Deliver?

The unified platform architecture delivers several concrete advantages for research institutions. First, researchers who submit jobs via Slurm don't have to change their workflow. The Slurm interface they know remains available, but it now runs inside OpenShift with all the observability, lifecycle management, and governance that Kubernetes provides .

Second, Slurm jobs run as containers, which means the environment is defined by the container image rather than whatever happens to be installed on the compute node. This dramatically improves reproducibility and simplifies collaboration between institutions that want to share pipelines. A clinical informatics team building a health equity chatbot, a genomics lab needing a fine-tuned model for variant annotation, or a computational social science department running LLM-based document analysis can all benefit from this standardization .

Third, platform engineers maintain one cluster, one observability stack, and one role-based access control model. Slinky doesn't require or create a second infrastructure; it folds HPC scheduling into the platform that's already in use. For a research university operating both an HPC cluster for computational science and an OpenShift environment for AI research, this approach helps make these two investments work as one .

The inference engine powering this architecture is vLLM, served through OpenShift AI's model serving layer. vLLM's continuous batching and memory-efficient attention mechanisms make it the right choice for shared inference environments where multiple research teams are consuming model endpoints concurrently. In a resource-constrained environment, which describes most research institutions, the difference between efficient and inefficient inference represents a meaningful share of the GPU budget .

Why Does the Industry Care About This Convergence?

NVIDIA's acquisition of SchedMD, the primary developer behind Slurm, signals where this convergence is heading at the industry level. The boundaries between HPC scheduling, Kubernetes orchestration, and AI infrastructure are being intentionally erased. Slinky represents Red Hat's contribution to that convergence, and it's available now to run in production .

The broader implication is that research institutions no longer have to choose between maintaining legacy HPC systems and adopting modern AI platforms. Instead, they can integrate both into a single, unified infrastructure that respects existing researcher workflows while enabling new AI-driven discovery. This matters because most research teams do not include infrastructure engineers. A clinical informatics team doesn't want to manage Kubernetes namespaces. A genomics lab doesn't want to configure model serving deployments. A computational social science department doesn't want to write infrastructure-as-code configuration files. The Models-as-a-Service approach solves this by having platform engineers operate the GPU cluster and expose AI models as shared services via APIs, allowing researchers to focus on their science rather than infrastructure management .