192 cores/node
Imagery in production
Compute nodes
Where the work runs
Servers & compute
Compute cluster
A room full of identical CPU nodes wired together with low-latency InfiniBand, one parallel filesystem, and a scheduler that keeps them busy. It runs the simulation and batch work that will not fit, or will not finish, on a single machine.
The problem
Waiting
A workstation runs one job at a time and a cloud VM charges by the hour whether the core is working or idle. When a fluid model, a crash simulation or a genomics pipeline outgrows a single box, the honest options run out fast. Engineers queue behind each other for the one fast machine, runs that should take an afternoon spill into the next week, and nobody can tell whether the bottleneck is the code, the memory or the network. Renting the same capacity by the hour looks flexible until the finance team sees a year of it. What most teams actually need is a fixed pool of cores they own, wired so a job can spread across many nodes at once, with a queue that shares them fairly. That is a cluster, not a bigger desktop.
192 cores
Per compute node, dual EPYC
400 Gb/s
NDR InfiniBand per node
< 1.2 us
MPI message latency, node to node
40 GB/s
Parallel filesystem read, sustained
Three layers, one machine.
Compute, fabric and storage. Each layer is sized against the others so no part sits idle waiting on another. Open a layer for what it does and how far it scales.
NDR InfiniBand
Imagery in production
Interconnect fabric
How nodes talk
Lustre on NVMe
Imagery in production
Parallel filesystem
Where data lives
Stateless boot
Imagery in production
Management and provisioning
How it stays identical
Configured hardware.
The parts we rack for a general CPU cluster, sized as a starting point and tuned to the workload.
Imagery in production
Compute
Calyraen Serve Compute node
2x EPYC 9654, 192 cores, 768 GBDual-socket 1U server, 96 cores per socket, one NDR InfiniBand port. The unit the pool is built from.
Imagery in production
Compute
Calyraen Serve head node pair
Redundant, Slurm + provisioningA redundant pair running the scheduler, provisioning and user logins, so the loss of one does not stop the queue.
Imagery in production
Fabric
Quantum-2 NDR switch
64 ports, 400 Gb/s eachThe leaf and spine of the fat-tree. Non-blocking, with adaptive routing across the fabric.
Imagery in production
Storage
Lustre NVMe storage shelf
40 GB/s+ read, one namespaceMetadata and NVMe object targets on the InfiniBand fabric, presented as a single parallel filesystem.
Imagery in production
Facility
Direct-to-chip liquid cooling rack
Up to 60 kW per rackCold plates on each CPU and a rear manifold carry heat to facility water, so a dense rack stays quiet and within thermal limits.
Turnkey, not a pallet.
Installed and benchmarked
Running
We rack, cable, cool and burn in the whole cluster, then hand it over having proven the numbers. Before sign-off it passes a Linpack run, an MPI latency and bandwidth sweep, and a filesystem throughput test, with the results written into the acceptance report. You get a machine that already works, not a room of boxes.
Imagery in production
Compute pool
Identical dual-EPYC nodes, stateless-booted from one image so the pool grows without drift.
Low-latency fabric
Non-blocking NDR InfiniBand fat-tree wired and verified end to end, storage on its own partition.
Parallel storage
A Lustre filesystem sized to the node count so checkpoints do not become the bottleneck.
Scheduler
Slurm configured with your partitions, fair-share and limits, so the queue reflects how your teams actually share time.
“We stopped renting cores by the hour and bought the pool outright. The crash-safety runs that used to spill across a week now finish overnight, and the queue is finally something the whole team trusts.”