Skip to content

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.