Pretraining a foundation model, or running continued pretraining on domain-specific data at meaningful scale, is not a job you provision on-demand and monitor casually. It is a multi-week or multi-month compute campaign where the infrastructure needs to behave predictably on day 90 the same way it did on day one. That requirement narrows the infrastructure options considerably.
What sustained training actually demands
The conversation about training infrastructure often starts with peak throughput, tokens per second, GPU utilization, MFU (model FLOPs utilization). Those numbers matter, but they are not what determines whether a sustained training campaign succeeds operationally.
What matters over a 12-month training campaign is a different set of properties: consistency of throughput over weeks, not benchmarks; stability of the software environment across the full job duration; predictable storage I/O for continuous checkpoint writes; and a fixed cost structure that does not shift with spot market availability or egress volume.
Shared cloud infrastructure is optimized for flexibility, the ability to provision and deprovision resources quickly, scale up and down with demand, and pay only for what you use. Those properties are useful for workloads that need them. They are actively counterproductive for sustained pretraining, where the operational requirement is the opposite: predictable, dedicated capacity over a fixed term, with no competing workload on the same fabric and no metered cost that accumulates with usage.
What the B300 delivers for labs running at scale
The B300's memory architecture changes the practical model size ceiling for single-node and small-cluster configurations in ways that matter directly to model labs.
At 270 GB of HBM3e per GPU, a single 8-GPU B300 node holds approximately 2.1 TB of total GPU memory. The weights of a 70B parameter model in BF16, about 140 GB, fit on a single GPU. Training needs more: mixed-precision training with Adam takes about 16 bytes per parameter, so one node holds the training state of a model of about 135B parameters, before activations. For continued pretraining runs on models in the 70B to 135B range, a single B300 node eliminates the inter-node tensor parallelism overhead that currently limits throughput on H100 configurations, where those same models require two to four nodes.
The compute picture follows the same logic. NVIDIA lists the 8-GPU HGX B300 at 108 petaFLOPS of dense FP4, 13.5 petaFLOPS per GPU, almost 7 times the H100's dense FP8 throughput of about 2 petaFLOPS. For labs running long training campaigns where the total token budget is fixed and time-to-completion directly affects the research roadmap, that throughput advantage translates to faster iteration cycles, more training runs completed per quarter, shorter feedback loops between data experiments and model evaluation.
The fifth-generation Tensor Cores also support automatic mixed precision across FP4, FP8, and BF16 within a single training job, managed by the NVIDIA Transformer Engine. For labs training on heterogeneous data mixtures, where different data types benefit from different precision levels, this reduces the manual precision management overhead that has historically required specialized tooling.
Cluster configuration for sustained campaigns
For model labs planning a 12-month training campaign, cluster configuration is not a provisioning decision, it is an architectural one. The configuration you start with determines the communication topology, the checkpoint strategy, and the parallelism approach for the full duration of the campaign.
A single 8-GPU HGX B300 node, with 2.1 TB of GPU memory and 14.4 TB/s of total NVLink bandwidth through NVSwitch, handles training for models up to about 135B parameters, before activations, without requiring inter-node tensor parallelism. Data parallelism across multiple nodes scales cleanly for training runs where the model fits within a single node but the data volume requires parallel processing across multiple GPUs.
For models above about 135B parameters, or for labs running pipeline-parallel configurations across multiple nodes, the model has to span more than one node. The practical rule is to keep tensor-parallel communication inside each node's NVSwitch domain, where NVLink runs at 1.8 TB/s per GPU, and to carry pipeline and data parallelism across nodes. That distinction matters for training efficiency: NVSwitch communication operates at a different latency profile than InfiniBand, and keeping tensor-parallel communication within the NVSwitch domain reduces the communication overhead that limits MFU on multi-node tensor-parallel configurations. For workloads that need a larger NVLink domain than eight GPUs, the GB300 NVL72 joins 72 Blackwell Ultra GPUs in one NVLink domain, and 1Legion offers it by reservation.
Between nodes, ConnectX-8 SuperNICs at 800 Gb/s per GPU handle the inter-node fabric for pipeline and data parallelism, and in 1Legion's GPU clusters that fabric is rail optimized, fully non-blocking and dedicated to one customer. For a lab running continued pretraining with data parallelism across four to eight B300 nodes, the inter-node bandwidth is not typically the binding constraint, but for large-scale pipeline-parallel configurations, it is.
Why dedicated bare metal is the operational foundation
The technical properties of the B300 are fully realized only on dedicated infrastructure. On shared cloud, the variables that degrade sustained training, network contention from neighboring tenants, inconsistent storage I/O during checkpoint writes, driver updates applied mid-job, egress costs accumulating on every checkpoint write, interact with the hardware in ways that no software-level optimization fully compensates for.
On dedicated bare metal on a fixed term, those variables do not exist. The cluster is yours. The east-west fabric is yours. The storage throughput is consistent and uncontested. And on bare metal you control the driver and CUDA versions, along with the NCCL configuration.
The fixed-term commitment is not a constraint, it is the operational model that sustained training campaigns require. A lab running a multi-month pretraining campaign needs to know its compute capacity twelve weeks in advance, not provision reactively based on spot availability. The training schedule, the checkpoint strategy, the data pipeline throughput, and the team's research roadmap are all built on the assumption of consistent, predictable infrastructure. Dedicated bare metal on a fixed term provides that foundation. Shared cloud, by design, does not.
Checkpoint economics also change materially on dedicated infrastructure. A 70B parameter model checkpoint in BF16 is approximately 140 GB. A sustained training campaign writing checkpoints every 500 steps over six months generates checkpoint volume that, on metered cloud infrastructure, accumulates into a significant unplanned cost. On dedicated bare metal with no egress fees, checkpoint writes have no marginal cost regardless of frequency.
1Legion rents dedicated HGX B300 clusters for AI model labs running sustained training campaigns: full-server allocation, no shared tenancy, no egress fees, on 36, 48 or 60 month dedicated terms. Every cluster passes burn-in before handover, with the results in an acceptance report.
If you are planning a pretraining campaign or evaluating dedicated infrastructure for a long-duration training commitment, talk to an engineer about your cluster requirements.