DGX Spark is the right choice for local development, prototyping and experiments by a single specialist; DGX Station is appropriate when substantially more memory, larger models or a shared computing resource for a small team are required; a rack-mounted DGX system is needed when artificial intelligence becomes an always-on service with concurrent users and requirements for availability, fault tolerance, monitoring and scalability. The boundary between desktop AI and the data center is defined not by the model’s parameter count or peak petaflops, but by accountability for the result: if the failure of one device disrupts customer operations or a business process, a single workstation is no longer sufficient.
In this article, the term DGX Server is used as a general designation for rack-mounted NVIDIA DGX systems and the infrastructure built around them. It is not the name of a separate model. DGX B300 is used as a current example of the server class. Specifications are current as of July 2026.
NVIDIA DGX servers
Three system classes — three operating models
DGX Spark usually belongs to one developer, who uses it to test models, build prototypes and evaluate a future architecture. Its failure interrupts personal work but does not stop an external service.
DGX Station can be used as a powerful personal machine or as a shared node for a small team. Server-grade management features allow it to be placed in a separate room, but physically it remains a single system and a single point of failure.
A rack-mounted DGX is designed from the outset for a data center and for connection to shared networks, storage, monitoring and schedulers. High availability only emerges when multiple nodes and the surrounding infrastructure are in place.
DGX Spark, DGX Station and rack-mounted DGX: key differences
| Criterion | DGX Spark | DGX Station | Rack-mounted DGX |
|---|---|---|---|
| Primary role | Personal development | Demanding local workloads and a shared team resource | Production AI platform |
| Users | One primary specialist | One specialist or a small team | Multiple teams and services |
| Typical workloads | Prototypes, local execution, parameter-efficient fine-tuning | Large models, long contexts, research | Inference under load, training, shared services |
| Deployment | Desktop | Office, laboratory or separate room | Purpose-built data center |
| Management | Primarily local | BMC, Redfish and GPU monitoring | Centralized node and cluster management |
| Scaling | One or two systems | Up to two connected stations | Multiple servers and racks |
| Fault tolerance | Not provided | One failure domain | Designed across multiple nodes |
| Selection criterion | Speed of personal iteration | Model capacity and shared access | SLA, workload and growth |
The peak performance of these systems cannot be translated directly into tokens per second. Actual speed depends on model architecture and precision, context length, request batch size, parallelism and the software environment.
DGX Spark: a personal system, not a miniature data center
Official image of DGX Spark.
Image source: NVIDIA
DGX Spark is built around the GB10 Grace Blackwell Superchip with a 20-core Arm processor. The system includes 128 GB of coherent LPDDR5X memory, a 4 TB NVMe drive, a ConnectX-7 adapter, 10 Gbit/s networking and a 240 W power supply. NVIDIA states that it delivers up to 1 petaflop of FP4 compute, supports models with up to 200 billion parameters and can fine-tune models with up to 70 billion parameters. Two systems can be linked for experiments with models containing up to 405 billion parameters.
These limits do not imply the same speed for every model. The ability to load the weights does not guarantee comfortable generation with a long context or multiple users.
What Spark is suitable for
- local development of applications and AI agents;
- inference for personal use;
- prototyping document search;
- experiments with quantization and LoRA;
- testing containers and libraries;
- processing confidential data;
- preparing a project for migration to the cloud or a data center.
Spark accelerates personal iteration, but its 128 GB of LPDDR5X should not be treated as equivalent to server-grade HBM. In addition to weights, memory is consumed by the context cache, working buffers, activations and the operating system. A model may therefore load successfully but respond too slowly with a long context or multiple users.
Spark uses Arm. NVIDIA tools support this architecture, but custom extensions and older containers may have been built only for x86, which must be considered before migration.
What linking two Spark systems provides
Two systems are useful for experiments with larger models and distributed execution. However, communication takes place over an external network, introducing latency, dependence on the parallelism strategy and more complex diagnostics.
This remains a research configuration rather than a direct equivalent of a multi-GPU server. In a rack-mounted system, accelerators are connected through a specialized internal fabric, whereas two Spark units remain independent computers.
DGX Station: workstation and personal cloud
DGX Station based on GB300 Grace Blackwell Ultra provides 252 GB of HBM3e on the GPU side and 496 GB of LPDDR5X on the CPU side, for a total of 748 GB of coherent memory. NVIDIA specifies up to 20 petaflops of FP4 compute, support for models with up to one trillion parameters, a ConnectX-8 adapter at up to 800 Gbit/s, seven MIG instances, BMC, Redfish and NVIDIA Data Center GPU Manager. Total system power reaches 1,600 W.
The 748 GB figure also requires clarification. The system offers a unified coherent address space, but the 252 GB of HBM3e and 496 GB of CPU memory have different bandwidth. This is not 748 GB of equally fast GPU memory.
When Station is significantly better than Spark
Station is needed when the model and context do not fit within 128 GB, fine-tuning requires more working memory, large datasets are processed or a small team shares one system.
Up to seven MIG instances allow the accelerator to be divided among workloads, with each instance receiving a share of compute resources, cache and HBM. For example, one specialist can run a model, another can analyze data and a third can test an updated software environment.
MIG does not combine resources into a larger accelerator. The technology divides one physical GPU into isolated partitions; it does not accelerate a single workload by pooling all independent instances.
Why Station is called a personal cloud
Station can be installed in a separate room and used as a shared server node. BMC, Redfish and DCGM provide remote management and metrics, while the team gains resource partitioning, a shared model collection and a job queue.
In terms of access, it is a small internal cloud resource. The system can run without a connected monitor, while users launch computations remotely.
Why it is still not a data center
MIG isolates users within one accelerator, but every partition depends on the same chassis, power system and software node. An update or hardware failure stops all workloads.
One Station does not automatically provide:
- routing requests to a standby node;
- updates without service-wide downtime;
- maintaining performance during peak demand;
- fault-tolerant shared storage;
- independent scaling of multiple services;
- redundancy for models and application state.
DGX Station can act as a server, but it does not replace a cluster or create high availability on its own.
Even two connected Station systems remain two nodes. Using them for an always-on application requires an external load balancer, shared storage, configuration synchronization and application logic capable of surviving the loss of one system.
What changes when moving to a rack-mounted DGX
Official front view of NVIDIA DGX B300 with the bezel installed.
Image source: NVIDIA DOCS
DGX B300 illustrates the scale of the difference. Its 10U chassis contains eight Blackwell Ultra SXM accelerators with a total of 2.1 TB of GPU memory. Two NVLink switches provide up to 14.4 TB/s of aggregate bandwidth between the accelerators. External connectivity includes ConnectX-8 at up to 800 Gbit/s and a BlueField-3 DPU. The estimated power consumption of one system is approximately 14 kW.
This is not merely a faster Station. A rack-mounted DGX is designed for:
- centralized use by multiple teams;
- large-scale and distributed training;
- full or resource-intensive fine-tuning;
- large-scale batch processing;
- serving multiple models;
- production inference with concurrent requests;
- always-on agents and enterprise AI services;
- connection to shared storage and management networks.
Inside DGX B300, the accelerators are connected by the NVLink fabric. For models distributed across multiple GPUs, this is fundamentally different from communication between separate desktop systems over an external network.
High-speed interconnects are needed not only for training. A large model can also be split across several accelerators during inference. If model partitions continuously exchange activations, interconnect latency and bandwidth directly affect overall performance.
Server class is defined by more than the GPU
A rack-mounted system adds hardware management, diagnostics, enterprise monitoring, schedulers, quotas, centralized updates and connections to separate management, storage and compute networks.
However, a single DGX B300 remains a point of failure if all requests are directed to it. Eight GPUs in one chassis increase performance but do not protect the application from a server outage, an operating-system failure or maintenance downtime.
One DGX server is not yet a data center
Beyond the chassis, a server requires power, cooling, networking, storage and an operating model. This surrounding infrastructure is what turns a compute node into a production platform.
For DGX B300, NVIDIA describes a rack with two systems consuming approximately 30 kW on average and up to 39.4 kW at peak. A dense configuration with four systems requires approximately 58 kW on average and up to 76 kW at peak. The documentation also covers three-phase power, redundancy, floor loading, service aisles, cabling, leak detection and cooling.
The project also requires redundant power and cooling, management and compute networks, shared storage, a model registry, a GPU scheduler, load balancers, centralized metrics and logs, access control, backups and automated deployment.
An alternative infrastructure does not have to be limited to a pre-integrated DGX. Companies can consider general-purpose 17th-generation Dell PowerEdge servers, with accelerators, processors, storage and networking configured for the workload.
For systems using PCIe GPUs, AMD EPYC servers are also popular because of their large number of PCIe lanes, as are Intel Xeon servers when the infrastructure is already standardized on that platform.
A pre-integrated DGX simplifies component and software-stack compatibility. An OEM server provides more freedom when selecting a configuration. In both cases, fault tolerance comes from a multi-node architecture rather than the hardware brand.
DGX System, BasePOD and SuperPOD are not the same
An individual DGX System is a compute node. DGX BasePOD is a reference architecture for combining multiple systems with networking, storage and management.
DGX SuperPOD is a scalable data-center platform in which compute nodes, InfiniBand and Ethernet, management servers, software and storage are designed as a unified system. NVIDIA documentation describes SuperPOD specifically as a combination of DGX systems, network fabrics, management nodes and storage, not simply racks filled with GPUs.
After the first server, the design target is no longer an individual machine. Data paths, the number of network ports, storage bandwidth, redundancy of management services and application behavior when a node is lost must all be calculated.
SuperPOD is not required for every project. Between one workstation and a large-scale installation lie many intermediate options: several GPU servers, a small cluster, equipment hosted in a data center or a combination of local resources and cloud services.
It is natural to aim for the minimum necessary investment. A Station with BMC is effectively a server and is sufficient in some cases, but not in all of them.
Where Station stops being sufficient
| Change in the project | Limitation of one Station | What server infrastructure adds |
|---|---|---|
| Customers use the model continuously | Downtime of one node stops the service | Multiple instances and load balancing |
| The number of concurrent requests grows | Queues and latency increase | Horizontal scaling |
| Multiple teams are working | Users compete for one GPU | Resource pools, quotas and priorities |
| Different models are needed simultaneously | Memory and compute become fragmented | Routing and independent scaling |
| Updates cannot involve downtime | The entire Station has to be stopped | Rolling node updates |
| SLA requirements appear | One chassis remains a single point of failure | Redundancy and automatic failover |
| The volume of data and artifacts grows | Local drives are insufficient | Shared storage and a model registry |
| Continuous observability is required | Telemetry from one node cannot show the entire service | Unified metrics, logs and alerts |
Desktop AI ends when the model’s output becomes a commitment to other people or business systems. A small model may require a server cluster if thousands of users call it around the clock. Conversely, a model with hundreds of billions of parameters may remain a research workload on Station if it is used by one specialist and downtime is acceptable.
The transition is usually driven by five changes:
- Downtime acquires a cost. A system outage affects sales, customer support, production or internal operations.
- The workload becomes unpredictable. One node handles the average flow but cannot withstand peaks.
- Resource ownership becomes distributed. Teams need quotas, priorities and isolation.
- Updates can no longer be performed for everyone at once. Traffic must be shifted between versions.
- The model becomes part of an application. The complete request path must be observed, not just GPU utilization.
Which class suits different workloads
Local development and RAG
Spark is convenient for frequent experiments with code, prompts, quantization and a limited document index.
Station is needed when the model, context or dataset does not fit within 128 GB, or when an entire department shares the resource. For local enterprise search, it can serve as a convenient intermediate system.
A server pool becomes necessary when search serves many users, enforces different document permissions and must operate without a shared downtime window. In this case, the vector database, source-document retrieval and application interface must be scaled alongside the model.
Fine-tuning
LoRA and other parameter-efficient methods are suitable for Spark or Station with moderately sized models. They modify a relatively small proportion of parameters and do not require storage for a full set of trainable weights and optimizer states.
Full fine-tuning requires memory for weights, gradients, optimizer states, activations and data. The working footprint can be many times larger than the file size of the finished model.
When a workload is distributed across multiple GPUs, NVLink, the external network and storage speed become decisive. If accelerators sit idle while waiting for data or synchronization, their peak performance is not being used.
Inference and AI agents
For one user, model capacity and response time matter. A production service must additionally control concurrent requests, latency, queues, multiple model versions and recovery after a failure.
A personal agent can run on Spark, while a departmental agent can run on Station. A multi-agent system connected to enterprise applications requires server-grade operations: state storage, access control, retries for failed operations and observability across the whole process.
The language model itself may still be moderate in size. Infrastructure becomes more complex not only because of compute requirements, but also because of the number of tools, task duration, retained history and the cost of an incorrect action.
Why memory capacity is only part of the calculation
During inference, memory is consumed not only by weights but also by the context cache, which grows with the number of conversations and the length of their history. Fine-tuning adds activations, gradients and optimizer states. Quantization reduces weight size but does not eliminate the other overheads and may affect quality and speed.
Local NVMe is convenient for the active model, but a team needs a shared catalogue, versioning, access rights, backups and fast data movement between nodes. Production environments typically separate working storage, object archives, the model registry and backups.
The network also consists of several planes:
- user access to the application;
- hardware management;
- communication between compute nodes;
- retrieval of models and datasets;
- transmission of metrics and logs.
The presence of ConnectX in the chassis does not create a cluster fabric without suitable switches, cables, topology and software.
Economics: the system price is not the only cost
For development, important factors include accelerator wait time, experiment speed, data storage and specialist labour costs. For a production service, they include cost per request, GPU utilization, latency, spare capacity, electricity, cooling, networking, support and losses caused by downtime.
Spark becomes a false economy when several specialists wait every day for the resource to become available. A cluster is uneconomical when it remains idle. Station is often the intermediate tier: it removes the memory constraint and enables shared access without requiring a full data-center project.
The workload profile must also be considered. Interactive development usually creates irregular peaks: a specialist runs an experiment, evaluates the result and changes the code. Production inference may run continuously, but its load depends on the time of day and user activity.
The cloud is convenient for occasional large training runs and demand peaks, while continuous and predictable workloads can be assigned to owned hardware. A hybrid model requires portable containers and storage that is independent of the compute environment.
How a project moves from Spark to Station and a server platform
Personal prototype
The developer tests the model and application architecture. Even at this stage, containerization, a reproducible environment and measurements of memory use and latency are required. Data and state should not be tightly coupled to Spark’s local drive.
Shared team resource
Once several users appear, the workload is moved to Station or another powerful node. Remote access, a job queue, GPU partitioning, a shared model collection and operational metrics are added.
At this stage, it becomes clear how often users interfere with one another, whether MIG isolation is sufficient and whether the entire system can be stopped for updates.
Production service
In the data center, the application is deployed across multiple nodes, compute is separated from storage, and load balancing, version management and automatic recovery are added.
Spark and Station use Arm processors, while DGX B300 uses Intel Xeon. Containers must therefore be built for multiple architectures, and binary extensions must be tested separately. NVIDIA’s unified stack makes model migration easier but does not guarantee compatibility for all custom code.
The complete request path should be measured: data retrieval, search, context preparation, model execution and result storage. Faster generation will not help if the main delay occurs in storage.
Common mistakes when comparing DGX systems
- Assuming that a loaded model already runs acceptably. It may fit in memory yet respond too slowly or fail to handle concurrent requests.
- Treating 128, 748 and 2,100 GB as the same kind of memory. Spark uses LPDDR5X, Station combines HBM3e with CPU-side LPDDR5X, and the DGX B300 figure refers to the memory of eight GPUs.
- Equating MIG with fault tolerance. MIG isolates user resources, but every partition stops if the physical node fails.
- Treating two desktop systems as a direct equivalent of one multi-GPU server. A distributed workload depends on the network and incurs additional latency.
- Selecting a system by peak FP4 figures. They do not show the speed of a specific model at the required precision, context length and workload.
- Assuming that local deployment is automatically secure. Without updates, access controls, encryption and logging, a local system also creates risks.
- Buying a server without calculating the surrounding infrastructure. A rack-mounted DGX may require upgrades to power, cooling, networking and storage.
What to choose
DGX Spark suits one specialist or a small research workload when local operation, rapid iteration and the ability to run large models without continuous reliance on the cloud are important.
DGX Station is needed when models, context or data no longer fit on Spark and the compute resource is used by one expert or a small team. It provides server-grade management and resource partitioning, but remains a single node.
A rack-mounted DGX or a cluster of GPU servers becomes necessary when the model turns into a service: concurrent users, SLAs, multiple teams, independent scaling, centralized storage and monitoring appear, and a single point of failure becomes unacceptable.
A data center does not begin with the eighth GPU or a particular parameter count. It begins when providing compute power is no longer enough — that capacity must be operated reliably, securely and predictably.
Content:
