Beyond AI: Other Workloads on the Stack#

concept

The stack on this site is built for AI, but nothing in it is specific to AI. GPU compute, RDMA fabrics, collective communication, parallel storage and topology-aware scheduling serve any workload that is large, parallel and data-hungry. Many of these workloads came first: HPC built RDMA and MPI long before deep learning borrowed them.

Domains that use the same stack#

Domain	Example applications	What it uses from the stack
Scientific simulation (HPC)	Weather and climate, fluid dynamics, molecular dynamics, seismic imaging	MPI/NCCL, RDMA fabric, domain decomposition (the HPC form of parallelism), parallel storage
Financial computing	Monte Carlo risk, options pricing, backtesting, real-time fraud scoring	GPU compute, data parallelism, low-latency networking
Data analytics	GPU-accelerated Spark and SQL (RAPIDS, cuDF), large joins, ETL	GPU memory, RDMA shuffle between nodes, fast storage
Vector and graph	Vector search at scale, graph analytics, recommendation engines	HBM capacity, sharding across GPUs, all-to-all traffic
Media and rendering	Video transcoding, 3D rendering, digital twins, synthetic media	GPU compute, GPU sharing, high-throughput storage
Robotics and simulation	Physics simulation and synthetic data for robot training	GPU clusters, parallel environments, scheduling
Cryptography and blockchain	Zero-knowledge proof generation, large-scale signature verification	GPU compute, batch parallelism
Genomics	Sequence alignment, variant calling (e.g. NVIDIA Parabricks)	GPU compute, parallel storage
Telecom and signal processing	5G radio processing, radar, real-time sensor fusion	GPU compute, low-latency networking, NUMA placement

The pattern is the same as for AI. Work that splits across many GPUs or nodes stresses the communication and fabric layers. Work that runs as many independent jobs stresses GPU compute, sharing and the scheduler. Work that reads or writes large datasets stresses the storage path.

Front end and back end: where a classic application meets the stack#

Most real products are not a training job or a simulation on their own. They are an ordinary application, a website or an API, with heavy computation behind it. The two halves have very different needs, and the stack only has to serve one of them.

flowchart LR
    U([Users]) --> FE

    subgraph GEN["General node pool: standard Kubernetes"]
        FE[Web front end<br/>stateless, autoscaled]
        API[API service]
        Q[[Job queue<br/>Kueue / Volcano]]
    end

    subgraph GPU["GPU node pool: the nine-layer stack"]
        INF[Inference service<br/>L1-L2, L4, L9]
        JOB[Batch and HPC jobs<br/>L3, L5-L9, storage]
    end

    FE --> API
    API <-- "interactive request / answer" --> INF
    API -- "long-running job" --> Q
    Q --> JOB
    JOB -- "results" --> ST[(Storage)]
    ST --> API

A classic web front end and API run on ordinary nodes; interactive requests go to an inference service on GPU nodes, and long-running work goes through a job queue to batch and HPC jobs that write results to storage.

	Front end (classic web application)	Back end (the stack)
What it does	Pages, user accounts, business logic, the API	Inference, training, simulation, analytics
Nodes	Ordinary CPU nodes	GPU nodes with RDMA NICs
Network	The default pod network (Calico)	Calico for control traffic, plus RDMA networks via Multus
Scaling	Horizontal autoscaling on requests	Scheduled by quota and gang admission
Failure	Restart a pod; users barely notice	A job may need to resume from a checkpoint
Cost	Cheap and generic	Where the investment goes

Requests cross the boundary in one of two ways:

Interactive: the API calls an inference service and waits for the answer, for example a chat reply or a fraud score within a payment. Latency matters, so the serving layers and GPU memory dominate.
Asynchronous: the API submits a job to a queue and returns immediately, for example a risk run, a render or a simulation. The job runs when the scheduler admits it, writes its results to storage, and the application picks them up later.

Both halves can run in the same Kubernetes cluster, separated by node pools, namespaces and quotas (see multi-tenancy). The web tier never needs GPUs or RDMA, and the GPU tier never has to serve web traffic. Keeping that boundary clean is what lets each half be sized, scaled and paid for on its own terms.