Can Seven AI Teams Share One DGX Station Without Fighting for GPU Resources?

Yes, but each team gets a small slice. The DGX Station GB300 supports Multi-Instance GPU (MIG), which splits its Blackwell Ultra GPU into as many as seven isolated instances. Each instance has its own memory, cache and compute, so one team's runaway job cannot crash or slow another's. The catch is the size of each slice: at seven-way, NVIDIA's current MIG guide gives every instance roughly 31 GB of the GPU's 252 GB of HBM3e and one-seventh of its compute. That is plenty for notebooks, small-model fine-tuning and serving 7B–8B models. It is not enough for a team that needs a 70B model. The real question is how you size the slices and who decides when to change them.

What do the MIG profiles look like on GB300?

From NVIDIA's MIG User Guide (supported GPUs and profiles pages, updated 13 Oct 2026) and the Hugging Face Llama 3.1 model sizes (23 Jul 2024). NVIDIA's earlier DGX Station MIG playbook (March 2026) uses the names 1g.34gb, 2g.67gb and 7g.269gb, so names vary by driver and document; run nvidia-smi mig -lgip on your own unit to see the exact list. The "practical fit" column is our guidance, not NVIDIA's, and model memory needs grow with context length and batch size.

What does MIG isolate, and what does it not?

NVIDIA's MIG guide says each instance gets "separate and isolated paths through the entire memory system": its own L2 cache banks, memory controllers and DRAM address buses, with "a defined quality of service (QoS) with fault isolation". In plain terms, Team A's out-of-memory crash stays inside Team A's slice. That is the key difference from simple time-slicing, where NVIDIA says "there is no memory or fault-isolation between replicas".

MIG partitions the GPU only. The 72 Grace CPU cores and the 496 GB of LPDDR5X CPU memory are still one shared pool, so a team running heavy data preprocessing can still crowd out the others on the CPU side. You need operating-system controls (separate user accounts, container limits or a scheduler) for that part. Storage bandwidth and the network ports are shared too.

MIG stops seven teams crashing into each other on the GPU. It does not stop them arguing over who gets the big slice, or over the CPU, disk and network they still share.

What are the limitations?

• Driver requirement. MIG on the DGX Station GB300 needs driver R595 (595.58.03) or later and CUDA 13, per NVIDIA's deployment notes.
• Changing the layout disrupts everyone. Turning MIG on or off "affects all workloads on that GPU", instances must be destroyed before disabling, and services holding the GPU (DCGM, monitoring agents, a desktop session) must be stopped first. Plan repartitioning like a maintenance window.
• No graphics inside MIG. NVIDIA says "no graphics APIs are supported" in MIG instances, so OpenGL or Vulkan visualisation needs the optional RTX PRO display card or another machine.
• Limited cross-talk. Peer-to-peer between MIG instances on the same GPU works with recent drivers, but CUDA IPC does not cross GPU instances, and profiling of shared GPU resources is not supported.
• Schedulers expect a fixed layout. Slurm "expects MIG devices to already be partitioned, and does not support dynamic MIG partitioning".
• No vGPU route. NVIDIA's current vGPU validated platforms list neither GB300 nor Arm hosts, so treat vGPU as unavailable on the Station.

How should seven teams actually share it?

Start with demand, not with seven. A layout of one 3g.126gb slice for the team running a 70B model, plus four 1g.31gb slices for development, would use all seven compute slices (3 + 4 = 7) and all eight memory slices (4 + 4 = 8) on paper. Which combinations are actually allowed depends on NVIDIA's placement rules, so confirm with nvidia-smi mig -lgipp before promising slices to teams. Review the layout monthly and change it in an agreed window.

Then add a scheduler so the GPU is not handed out by email. NVIDIA's preliminary DGX Station software diagram includes Kubernetes and Run:ai; Run:ai's KAI Scheduler was open-sourced in April 2025 with GPU sharing and team quotas. Kubernetes uses NVIDIA's GPU Operator, which can also combine MIG with time-slicing. For smaller groups, NVIDIA's Brev playbook registers the Station as "a shared GPU workspace your team can access from anywhere". NVIDIA MPS is a third option for cooperative processes, and CUDA 13.4 added memory limits to it, but it does not give MIG's fault isolation.

Finally, keep a written policy: who owns the large slice, how long jobs may run, and who can change the MIG layout, since that needs sudo and affects every user. For the remote-access side, read The Most Expensive Computer Your Employees Might Never Touch; for the admin workload, Now Who's Going to Manage It?.

When is one DGX Station not enough?

If several teams each need a 70B-class model at the same time, or if one team's training run would monopolise the full GPU for days, MIG only rearranges the queue. The alternatives are a second Station (NVIDIA documents a switchless two-node link over ConnectX-8), smaller GB10 systems for individual developers, or moving production inference elsewhere. Our post Can One GB10 Support 20 Employees Using AI at the Same Time? covers the per-user maths at the smaller end, and Your DGX Station Could Be a Single Point of Failure covers what happens to seven teams when the one shared box goes down.

Buying in Singapore

All five DGX Station GB300 systems SourceIT supplies support MIG with up to seven instances: the HP ZGX Fury G1n, MSI XpertStation WS300, ASUS ExpertCenter Pro ET900N G3, GIGABYTE W775-V10-L01 and Supermicro ARS-511GD-NB-LCC, all price on request. For individual developers who do not need a slice of the big GPU, the HP ZGX Nano G1n GB10 128GB/4TB is S$11,499.00 and the NVIDIA DGX Spark GB10 128GB/4TB is S$9,300.00 (both listed 4 Nov 2026). Browse the NVIDIA DGX Spark and DGX Station collection. For a quotation, use Request for Quotation on the product page, call (65) 6978 3502, email Sales@sourceit.com.sg or use our contact page.

Frequently asked questions

How many MIG instances does the DGX Station GB300 support? Up to seven, according to NVIDIA's MIG User Guide, which lists the GB300 (DGX Station) with 252 GB and a maximum of seven instances.

How much GPU memory does each of seven instances get? About 31 GB each in the 1g.31gb profile, one-eighth of the 252 GB HBM3e. Seven of those use seven-eighths of the GPU memory and all seven compute slices.

Can a MIG instance run a 70B model? A 70B model at FP8 needs about 70 GB for its weights, so it needs at least a 3g.126gb instance. It will not fit a 1g.31gb or 1g.63gb slice, before even counting the memory for context.

Does MIG split the CPU and system memory too? No. MIG partitions the GPU. The 72 Grace cores and 496 GB of CPU memory remain shared, so use operating-system or container limits for those.

Can I change the MIG layout while people are working? Not without disruption. NVIDIA says enabling or disabling MIG affects all workloads on the GPU and instances must be destroyed first, so schedule layout changes in a maintenance window.