What if the computer you needed did not have to fit inside the server you bought? What if you could assemble it from a rack of resources, joining the right GPUs, xPUs, SSDs, and FPGAs to CPU hosts, then change that configuration as the work changed?
That is the idea behind Corespan's Mercury Rack. Its defining feature is not simply accelerator density. It is the ability to turn pooled hardware into larger, right-sized computing blocks through the DynamicXcelerator architecture, native PCIe connectivity over optical, and Corespan Composer.
Move the Boundary Beyond the Server
A conventional server fixes an important decision at purchase: which resources belong to which CPUs. Accelerators and storage occupy particular slots, inside particular chassis, attached to particular hosts. Software can schedule work across those servers, but scheduling alone does not change their physical resource boundaries.
Mercury Rack is designed to move that boundary into the fabric. CPU hosts connect through an optical interconnect to resources housed in Photonic Resource Units, rather than relying only on devices installed inside their own chassis. Composer controls which resources are assigned to each host, assembling the hardware configuration that the workload needs.
The distinction is fundamental: instead of asking which existing server can accommodate a job, ask what computer should be assembled to run it.
Bigger Computing Blocks Change the Possibilities
Consider 32 GPUs. Four fixed eight-GPU servers and one host-addressable 32-GPU domain contain the same number of accelerators, but they are not the same computing building block.
The first arrangement divides capacity across four host boundaries. The second makes a larger set of accelerators addressable by one host, creating the opportunity to keep more of a workload inside a composed system rather than requiring it to span separate servers.
Mercury Rack's composition model uses GPU groups of 2, 4, 8, 16, and 32. A shared 32-GPU pool could be configured as one 32-GPU domain, two 16-GPU domains, or four eight-GPU domains, subject to the supported configuration. Bigger blocks become available when needed, without making every workload consume the biggest block.
That flexibility can reduce stranded capacity and, for suitable workloads, duplicated host infrastructure. It does not imply unlimited bandwidth or automatically combine GPU memories into one coherent memory pool. The advantage is a different system boundary, with performance determined by the workload and its communication requirements.
Native PCIe, Extended Through Optical
Our PCIe Fabric over Optical story starts with a simple principle: extend native device connectivity beyond the box rather than make every resource interaction a network transaction between servers.
Corespan's optical layer joins distributed PCIe switches and resource units at the physical layer, reducing the need for intermediate electronic switching stages. The architecture preserves native PCIe transactions while providing the paths and address translation needed to communicate across the configured fabric.
This matters for more than CPU-to-GPU attachment. Supported peer-to-peer paths let resources exchange data directly, rather than making host memory a mandatory intermediate stop. GPUs need to communicate with other GPUs, but they also need access to the data that keeps them productive.
The Mercury Rack brings those relationships into the same architectural conversation: how resources connect, how data moves, and how the system is assembled.
More Than a GPU Rack
The broader opportunity is to compose different kinds of resources around CPUs. GPUs provide parallel compute; other xPUs bring specialized acceleration; FPGAs support programmable processing; and NVMe SSDs supply storage capacity and data access.
Imagine an inference configuration that needs a larger GPU group and SSD capacity for model data or supported KV-cache offload. Another workload might need fewer GPUs and an FPGA for a specialized processing stage. The architectural goal is to draw from qualified resource pools rather than purchase a separate, permanently configured server design for each combination.
Composer makes this more than a cabling exercise. It controls the physical resource assignments beneath the software that schedules workloads. Reconfiguration follows the supported device and software lifecycle; it is not a promise that every running application can gain or surrender hardware without interruption.
Build Around the Work
What makes Mercury Rack special is the combination: pooled resources, native PCIe-over-optical connectivity, larger host-addressable domains, and software-controlled composition. Together, they replace a fixed resource ratio with a configurable system.
The roadmap extends that approach to 64-GPU domains and PCIe Gen 6 in 2027, with Gen 7 to follow. But the central idea is already clear: the rack should provide the ingredients, and the workload should determine the computer.
Do not just build a bigger cluster of fixed machines. Build the computing blocks your applications actually need.