A useful HPC or AI specification begins with the working set and execution path, not a favourite processor or an assumed GPU count. Hyperion systems deliberately span CPU-led, single-GPU, multi-GPU and multi-node designs, so the same family can be sized against measured workload constraints.
This guide shows how to turn a representative run into an architecture decision and how to avoid the common error of buying one fast component while starving it elsewhere.
Start with a workload envelope
Record the largest realistic input, peak resident memory, read/write volume, desired concurrency, wall-clock target and acceptable queue time. Separate latency-sensitive online work from throughput-oriented batch work. For AI, record model parameter count, numerical precision, context length, batch size, activation memory and whether training, fine-tuning or inference is required. For simulation, capture mesh or matrix size, solver type, MPI ranks, OpenMP threads and checkpoint pattern.
Run a baseline if any suitable machine exists. CPU utilisation, memory high-water mark, storage throughput, GPU utilisation and transfer time reveal the real bottleneck. Treat vendor peak figures as component capabilities, not application performance guarantees.
CPU and memory are a coupled decision
Core count is valuable only while memory bandwidth, cache locality and software licensing allow scaling. AxiKeystone and AxiVector favour large memory and CPU density for sparse solvers, compilation, genomics, Monte Carlo and data preparation. NUMA-aware placement matters: bind ranks and threads to the memory local to their CPU domain, and test one socket or NUMA region before increasing parallelism.
Capacity headroom should include the operating system, page cache, workflow engine, temporary decompression, multiple concurrent users and failure recovery. When datasets must remain in memory, 1.15TB per node can remove repeated storage passes; when the algorithm streams predictably, bandwidth and layout can matter more than raw capacity.
GPU fit, topology and utilisation
VRAM is a hard fit constraint; aggregate VRAM is not automatically one address space. A single 96GB GPU in AxiAnvil simplifies large-model serving. Four 24GB GPUs in AxiRelay favour replicas and independent services. AxiForge, AxiForge Max and the cluster platforms support distributed training, but the framework must partition data or model state and use NCCL correctly.
Profile host-to-device copies, kernel occupancy, launch overhead and input-pipeline stalls. NVIDIA recommends representative profiling, coalesced memory access and minimising unnecessary transfers. A faster accelerator will remain idle if CPU decoding, data augmentation or storage cannot feed it.
Storage tiers and data lifecycle
Use local NVMe for the active working set, shuffle, checkpoints and temporary data; protected NAS or object storage for source datasets, shared artefacts and retention; and a separate backup target for recovery. Estimate sustained rather than headline throughput, including small-file metadata behaviour. Genomics and computer vision frequently benefit from staging many small files into larger archives or indexed formats.
Capacity planning must include replicas, snapshots, model versions, experiment artefacts and growth. Define which data is authoritative and which is reproducible scratch so backup cost follows business value.
When a fabric becomes necessary
Multi-node applications need communication that justifies the additional operational layer. AxiVector uses direct 100GbE RoCEv2 for two-node MPI; AxiLattice, AxiBastion and AxiTitan use switched fabrics for more flexible scheduling. GPUDirect RDMA can allow compatible devices to exchange data without staging through ordinary host copies, but drivers, topology, RDMA configuration and application libraries all need validation.
Measure strong scaling for a fixed problem and weak scaling as the problem grows. If communication consumes the saved compute time, a larger single node is the better engineering choice.
A repeatable selection gate
- Benchmark one representative workload and capture resource traces.
- Identify hard fit constraints: RAM, VRAM, local scratch, network or software licences.
- Select the smallest baseline that clears those constraints with operational headroom.
- Test the target software stack in containers or controlled environments.
- Validate performance, failure recovery, power, cooling and export-compliance assumptions before formal quotation.
Hyperion configurations are baselines, not substitutes for workload validation. Axiotech can use benchmark evidence to adjust CPU, memory, accelerator, storage and fabric together.
Primary technical references
- NVIDIA CUDA C++ Best Practices Guide
- NVIDIA GPUDirect RDMA documentation
- NVIDIA NCCL documentation
- Slurm MPI Users Guide
References are provided for software architecture and implementation planning. Validate the versions, licences, support matrix and regulated-use requirements applicable to the final deployment.