BlogProcurement playbook
B300 Lead Times: How to Plan a Reserved Order
Buyers keep asking for a single B300 lead time. The useful answer is a schedule built from stages, confirmed per project, that you plan backwards from the date you need capacity.
Picture a head of infrastructure at a growing AI lab. The training roadmap says a new model run starts next quarter, finance has approved a reserved B300 cluster, and every vendor call opens with the same question from her side: “What’s the B300 lead time?” One provider gives a date. Another gives a range. A third says it depends. She ends up with three answers that can’t be compared, because each one measures something different.
This guide is for founders, infrastructure leads and procurement owners planning a reserved B300 order who need a date they can put in a board deck. In practice, lead time is a set of stages, each with its own owner, and it gets confirmed per project. Once you see the parts, you can plan backwards from the day you need capacity and ask providers questions that produce comparable answers.
1. What “lead time” actually covers for a reserved cluster
For a reserved, single-tenant cluster, the time between signing and running jobs passes through several distinct stages. A quote that names one date usually refers to only one of them.
- Allocation: the provider commits specific hardware to your project.
- Configuration freeze: node spec, fabric design, storage and software image are locked.
- Build: systems are assembled and integrated into racks or modules.
- Factory acceptance: the build is tested against agreed criteria before it ships, ideally with witnessed evidence.
- Freight: transport, customs and delivery to the site.
- Site readiness: power, cooling, space and network handoff are prepared and verified.
- Installation: equipment is placed, cabled and connected.
- Commissioning: the site systems and the cluster are brought up together.
- Site and integration acceptance: the cluster passes agreed tests in place and is handed over for your workloads.
The date that matters to you is the last one: when the cluster passes integration acceptance and your team can schedule work on it. Everything else is an input to that date.
2. Why a single quoted date is incomplete
When a provider says “we can deliver by a given date,” ask what “deliver” means. It might mean hardware leaves the factory, arrives at a dock, or is racked and powered. Each of those leaves a different amount of work between that date and productive use.
A quoted lead time without stage definitions is incomplete in two ways. You can’t compare it with other offers, and you can’t tell which parts depend on you. If site readiness is your responsibility and the quote assumes it’s finished, the real schedule is longer than the number on paper.
A useful habit: rewrite every quote you receive into the same stage list from section 1, and mark which stages the quote covers and which it leaves blank. The blanks are where schedules slip.
3. What moves a B300 lead time
Lead times vary between projects, and they vary for reasons you can often influence. The main drivers:
- Configuration choices and late changes. Nonstandard node specs, storage tiers or software images add design and test work. Changes after the freeze can restart parts of the build.
- Quantity and cluster size. A handful of nodes and a full pod involve different allocation, integration and testing effort.
- Fabric and networking. A dedicated, configurable fabric needs its own design, cabling plan and validation, and its components have their own availability.
- Site power and readiness. Confirmed power at the right connection point, cooling capacity and physical access often decide the critical path.
- Export and logistics paperwork. Licensing, end-use documentation, customs and freight booking each need lead time and correct information from the buyer.
- Acceptance testing. Clear criteria let tests run once. Vague criteria lead to retests and disputes.
Notice how many of these sit partly with the buyer. That’s good news, because it means you can shorten your own schedule by deciding early.
4. Plan backwards from your need-by date
Start with the date your team needs a cluster accepted and ready for workloads. Then work backwards through each stage, putting a buffer between stages that have external dependencies.
- Write down the need-by date and the reason for it, such as a training run, a customer commitment or a funding milestone.
- Subtract time for your own onboarding after acceptance: access, job scheduler setup, data staging and smoke tests.
- Ask the provider for the stage durations that apply to your configuration and site, and record which are confirmed and which are targets.
- Add buffers after the stages with the most uncertainty, usually site readiness, freight and acceptance.
- Find the date you must freeze configuration and sign. If that date has already passed, you need a bridge plan (see section 8).
Planning backwards turns “what is the B300 lead time?” into a sharper question: “Given this date, what must happen by when, and who owns each step?” Providers can answer that one specifically.
5. Questions to ask a provider
Use the same questions with every provider so the answers line up side by side. If you’re running a formal process, our guide on how to score reserved GPU delivery dates shows how to weight these answers.
- Which stage does your date refer to: ship, arrival, installation, or integration acceptance?
- Which parts of the schedule are confirmed and which are targeted?
- What do you need from us, and by when, for the schedule to hold?
- What site conditions does the schedule assume?
- How will you report progress, and how quickly will you tell us about a slip?
- What acceptance evidence will we receive at factory, site and integration stages?
- What happens to the schedule if we change the configuration after the freeze?
As a reference point, Pacific confirms configuration and the delivery window through a project review and a written offer, provides witnessed factory, site and integration acceptance evidence, and confirms the targeted deployment timeline site by site. It is a target, never a guaranteed date. You can see how that offer is structured on the reserved B300 capacity page for single-tenant bare-metal clusters, which uses a Pod 32 reference of 32 HGX B300 nodes with a dedicated, configurable fabric.
6. What to lock early
Three decisions shape most of the schedule. The earlier they are fixed, the fewer surprises later.
- Configuration. Node count, GPU type, memory and storage per node, fabric topology, management network and base software image. Agree a freeze date in writing.
- Site requirements. Available power feed, connection point and timing, cooling approach, floor or pad space, access route, and network handoff. Keep verified facts separate from assumptions that still need utility, landlord or engineering confirmation. A power letter, an access route and a drawing answer different questions.
- Acceptance criteria. Define the tests for factory, site and integration acceptance, the pass thresholds, who witnesses them and what evidence you receive.
If you’re still collecting requirements, write them into a single capacity brief for a reserved B300 RFP before you approach providers. A clear brief helps providers return schedules you can compare.
7. Contract items that protect the schedule
The contract is where a schedule becomes enforceable. Read it with the stage list beside you.
- Target versus committed dates. Know which dates are targets and which, if any, carry obligations. Don’t build your roadmap on a target as if it were a commitment.
- Milestones. Tie each stage to a named milestone with clear completion evidence, such as a signed factory acceptance report.
- Buyer dependencies. List what you owe and by when, and what happens to the schedule if you miss it.
- Change-order freeze. Define the freeze date and how post-freeze changes are priced and scheduled.
- Slip reporting. Set a notice period and a format for schedule changes, including the revised date and the cause.
- Remedies. Agree what happens if a committed milestone is missed, from service credits to exit rights.
Remedies for late delivery deserve their own careful negotiation. Our post on liquidated damages for late delivery on reserved B300 orders walks through how to structure them without poisoning the relationship.
8. Bridge options while you wait
Planning backwards sometimes shows that the need-by date lands before a reserved cluster can realistically be accepted. The project can still start on time if you plan capacity for the gap.
- Rent dedicated nodes on demand or on short reserved terms to start development, data pipelines and smaller runs. Our guide on how to rent B300 GPUs covers the rental route.
- Use an earlier GPU generation for work that doesn’t need B300 memory, then move to B300 when the cluster is accepted.
- Plan the migration: matching software images, storage layout and job scripts make the cutover simpler.
Pacific’s GPU compute catalog of dedicated bare-metal nodes lists H100, H200 and B200 SXM nodes with on-demand preview rates, while B300 SXM, GB200 NVL72 and GB300 NVL72 are by request. Preview rates are indicative until Pacific confirms the allocation, and review revalidates capacity, the current quote and terms before you commit. Keep in mind that a paid order is not yet a ready resource, so put bridge capacity on your backward plan too.
If you want to build your schedule against a real configuration and site, book a project review call with Pacific Intelligent Technologies, Inc.. We’ll walk through the stages, confirm what applies to your project, and set out the targeted timeline in a written offer.
FAQ
What is the typical B300 lead time?
There isn’t a single figure that applies across projects. Lead time depends on configuration, cluster size, fabric, site readiness, paperwork and acceptance testing, so it varies and must be confirmed for your specific project. Ask each provider which stage their date refers to and what it assumes.
Which stage of the schedule usually causes slips?
It varies by project, but stages with outside dependencies carry the most risk: site power and readiness, export and freight paperwork, and acceptance testing with unclear criteria. Locking configuration, site requirements and acceptance criteria early reduces that risk.
Can a provider guarantee a B300 delivery date?
Treat any date as a target unless the contract explicitly commits to it and attaches remedies. Pacific confirms a targeted deployment timeline site by site through a project review and written offer, and it is never presented as a guaranteed date. Plan buffers and a bridge option accordingly.
Continue on the mothership
This satellite stops at the playbook. Transactions, specs, and comparisons live on pacificmachines.com. If the next step is a human, book 30 minutes with Harper.