NVIDIA DGX Station GB300 for a team: how many concurrent users, and how to estimate them

How many users a DGX Station GB300 serves, by the published documents

How many users one NVIDIA DGX Station GB300 serves has not been measured in any public document we read. NVIDIA's blog of 21 October 2026 says the system can "serve 30+ users at speeds comparable to those provided by cloud models" and names no model variant, engine, context length or token rate. Documented are the seven MIG instances of the GPU and its memory: by our sizing rule 208.2 GiB of the 252 GB of HBM3e hold weights and KV cache, which gives a count of concurrent conversations that fit and no statement about their speed.

This page is about sharing one Station. Which models fit is covered in our article on which open models run on the DGX Station GB300, and the specifications are in DGX Station GB300 specs and alternatives.

What NVIDIA and the makers say about teams and users

NVIDIA positions the Station in two ways, as "an individual desktop for one user" or as "a centralized compute node for multiple team members". The statements that carry a number are these.

NVIDIA's DGX Station product page (page metadata of 4 November 2026) and NVIDIA's blog "Bringing the Spark to Europe: Local Intelligence Powers Next Wave of Agents" of 21 October 2026; the pages of Dell, Supermicro and HP for their versions; all read 12 November 2026.

The blog sentence names "advanced models like GLM 5.3" and nothing else. A second sentence there, "On DGX Station, GLM 5.3 Flash gets up to 1.2x higher throughput", gives no baseline. For that model our published memory table says: NVIDIA's NVFP4 checkpoint of GLM-5.3-Flash takes 190.5 GiB and leaves 17.7 GiB of the HBM3e for the cache by our rule. Whether the blog means this checkpoint, another one or a cache held in processor memory is not stated, so the figure of 30 cannot be checked against published data.

No public multi-user measurement of this system exists in the documents read on 12 November 2026. NVIDIA publishes no token rates and no concurrent-user test for the Station on its product page, in the datasheet, the development guide, the playbooks or the blog. MLCommons' supplemental discussion document for MLPerf® Inference v6.1 names no DGX Station; the results table itself was not readable for us. Our pages hold no measurement either.

Three ways a team shares one DGX Station

• One model service for everyone. A serving engine such as vLLM or SGLang loads one or several models on the whole GPU and batches the requests of all users. NVIDIA's development guide lists the "NVIDIA Container Runtime for Docker" as included and marks vLLM 26.03 and SGLang 26.03 as tested. In this mode a user is a request in flight, and the limits are the memory for the KV cache and the throughput of the GPU.
• MIG instances. The GPU is divided into up to seven isolated instances, each with its own share of memory and compute, for developers or for several small services side by side.
• Accounts and remote access. The operating system is an Ubuntu 24.04 image, and accounts on it are ordinary Linux administration. NVIDIA publishes no user-management chapter for this system; the "DGX Station User Guide" on its documentation site describes the 2017 system with four Tesla V100 and does not apply.

NVIDIA's blog of 21 October 2026 announces a further way: "NVIDIA Cloud Functions is coming in early access to Linux-based DGX Station." Teams register local model endpoints in a shared catalogue, so that "teammates can use shared models without direct machine access". This is an announcement of early access. NVIDIA's Brev playbook of 21 September 2026 registers the Station as a managed GPU environment for a Brev organisation and does not address isolation between users.

MIG on the DGX Station with up to seven instances

NVIDIA's product page says the GPU can be partitioned "into as many as seven instances" for "local development with multiple users", each isolated with its own memory, cache and compute cores. NVIDIA's MIG User Guide lists these profiles for the GB300 with 252 GB.

NVIDIA MIG User Guide, table "GPU Instance Profiles on GB300" (page dated 13 October 2026), read 12 November 2026; "compute share" is NVIDIA's fraction of SMs. The guide also lists 1g.31gb+me, one instance with media extensions.

Seven instances of 1g.31gb take seven eighths of the GPU memory, by our estimate from NVIDIA's fractions, and each has a seventh of the compute. By nominal size such an instance is close to a 32 GB card, and a 63 GB instance holds about twice that. NVIDIA publishes no figure for the memory the driver reports per instance, so we print no budget for them. Dell turns the limit into the statement that its version "serves up to seven developers"; NVIDIA itself gives no developer count for MIG.

MIG on the Station needs Linux, CUDA 13 and a driver of the R595 branch from 595.58.03, by the guide's page of 4 November 2026. Graphics APIs are not supported in MIG mode except with the "+gfx" profiles, and CUDA IPC does not work across instances. NVIDIA's MIG playbook for the Station switches the mode on with nvidia-smi -mig 1 and notes that enabling or disabling it affects all workloads on the GPU. Its example profile names (1g.34gb, 2g.67gb, 7g.269gb) do not match the user guide's table for the 252 GB GPU, so list the profiles of the delivered system with nvidia-smi mig -lgip. No document says whether a MIG instance can use the 496 GB of LPDDR5X on the processor.

MIG mode is a decision for the whole GPU. A model that needs the full 252 GB uses the whole GPU, and then there are no instances for anyone else. We supply manufacturers' versions of the Station per project and can deliver it with the instances set up; tell us how many developers need an isolated instance and how large their models are, and we reply within one business day.

Estimating concurrent users from memory and throughput

Our method is the one of our article on how many users one RTX PRO 6000 serves, applied to the Station.

1. Count the requests in flight. A GPU serves the requests that are generating tokens at that moment, so log them at your gateway and take the busy-hour peak.
2. Take the usable memory: 0.9 times the memory the driver reports, less 3 GiB. NVIDIA has not published the reported figure for the Station, so we plan with 252 GB, which is 234.7 GiB, and get 208.2 GiB.
3. Subtract the weights of the checkpoint you will load.
4. Divide the rest by the KV cache of one conversation at the context you declare. For Llama 3.3 70B that is 2.5 GiB per 8,192 tokens with a 16-bit cache and 1.25 GiB with an FP8 cache.
5. Start the engine and read its log: vLLM prints "GPU KV cache size" and "Maximum concurrency" at start-up. Then measure the time to the first token and the rate per user under that load.

our estimates by the rule above with 208.2 GiB usable, from our article on which models run on the DGX Station GB300 (file sizes from Hugging Face, read 24 October 2026; NVIDIA's NVFP4 checkpoints for the last two rows). "Not computed here": the cache per conversation of these hybrid-attention models is worked out in the model guides linked from that article.

These are conversations that fit in memory at full context, by our estimate. The counts are a floor, because conversations that never fill their context use less, and they say nothing about speed. The bandwidth of the HBM3e sets an upper bound for one request, about 100 tokens per second for Llama 3.3 70B in FP8 by our estimate. How that rate divides when many conversations run at once, up to the 112 of the table, no public test of the Station shows. Two reference speeds help to judge a measurement of your own: silent reading at 238 words per minute is about 5.3 tokens per second, and the interactive scenario of MLPerf Inference v6.0 for Llama 2 70B allows 40 ms per token, which is 25 tokens per second per user.

The MLPerf name and logo are registered and unregistered trademarks of MLCommons Association in the United States and other countries. All rights reserved. Unauthorized use strictly prohibited. See www.mlcommons.org for more information.

Employees and requests in flight are different figures. By the example values of our guide to sizing a private ChatGPT server by company size, 100 employees produce about four requests in flight at the busy-hour peak: 40 per cent of staff active in that hour, six requests an hour each, 30 seconds per request and a peak factor of two. These are example values, and a pilot replaces them with the figures of its own gateway logs. We print no user number for the Station beyond this method. We size Stations and GPU servers from these inputs; send us the checkpoint, the context length and your peak of requests in flight, and we reply with the memory arithmetic for it.

Workloads that suit a shared Station

• Development for a few people. Containers per developer on the whole GPU, or MIG instances where developers must not disturb each other. Each 1g.31gb instance has a seventh of the compute.
• Fine-tuning runs in a queue. NVIDIA positions the Station for team members who "fine-tune and run IP-specific models on-demand". A fine-tuning run and a model service share the same GPU unless MIG separates them, so runs are planned one after another or outside working hours.
• An internal assistant for a department. One model service on the whole GPU, sized by the method above from the peak of requests in flight. With gpt-oss-120b the memory holds about 131 conversations of 32K.

Two limits belong in the plan. The Station has one GPU and, in the versions of Gigabyte and Supermicro, a single power supply, so a driver update, a fault or a tripped circuit stops every user at once. And the processor is Arm, so each tool the team installs needs an Arm64 build, as our comparison DGX Station GB300 vs RTX PRO 6000 workstation sets out. Power, heat and noise of a Station next to desks are covered in DGX Station GB300 power and cooling in an office.

When a server is the right system

A rack server fits better in three cases.

• The service must stay up. Two nodes, each sized for the peak, let one be updated while the other serves; see high-availability LLM inference on two nodes.
• Many concurrent users of a mid-size model. Copies of the model on separate cards scale with the card count. By the same rule, a 2U server with four NVIDIA RTX PRO 4500 Blackwell Server Edition cards (32 GB and a budget of 25.7 GiB each) holds four copies of Qwen3-14B in FP8 for 64 conversations of 8K with an FP8 cache, and eight cards hold 128. The card is on our buy page for the RTX PRO 4500 Server Edition and in its specs; the server is described in four RTX PRO 4500 Server Edition in 2U.
• A model above 208 GiB that must stay in GPU memory. Eight RTX PRO 6000 Server Edition cards hold 664.3 GiB by our rule (specs).

The four-card inference node on our AI servers page is built for "Production inference for several teams, multi-model serving", and the way from one system to several is the subject of our article on scaling private AI hardware from pilot to production. You can order the Station or the server alone, the setup of the serving engine, the accounts and the MIG layout alone, or both together: the system delivered with everything installed and configured; write to us and we suggest the best solution for your tasks and budget.

What to send us for a sizing

• the model and the checkpoint (precision), and the context length you will declare;
• the peak of requests in flight, or the number of staff and how they will use the assistant if no logs exist yet;
• how the team shares the system: one model service, MIG instances for developers, fine-tuning runs;
• software that exists only for x86;
• the company, the project and the intended use, which the distribution asks for before we can quote a Station.

The form below reaches us, as does an e-mail to request@eurokommerz.at. The first call is free of charge. Our article on the ten facts of a private AI sizing request explains each point, and the makers and the order are in buying a DGX Station GB300 in the EU. A smaller shared system is described in one DGX Spark for a team.

FAQ