When you sell GPU capacity to a marketplace for the first time, every onboarding page says roughly the same thing: apply, get vetted, start listing, usually inside one to two weeks. Spheron's own Supplier Program page quotes that exact range, and it isn't wrong. What the page doesn't break down is where those days actually go. A provider walking into this usually braces for the wrong bottleneck, expecting the slow part to be paperwork, KYC forms, entity verification, a sanctions screen, while treating hardware checks as a formality an already-running cluster will sail through. It runs the other way. Cluster validation eats the calendar; export compliance is what blindsides providers who assumed it didn't apply to them at all.
TL;DR: What Slows a Provider Down When They Sell GPU Capacity to a Marketplace
- Hardware, not paperwork: SF Compute's cluster acceptance spec (Nov 2026) requires 16-24 hours of per-node burn-in, a 24-hour GPU soak, and 24 hours to 5 days of cluster-wide testing.
- Compliance surprises, not delays: a September 2026 Greenberg Traurig advisory warns hosting-only operators may have assumed export controls didn't apply.
- Spheron: vets uptime, networking, and reference deployments in under a week, inside a 1-2 week onboarding (Nov 2026), across H100, H200, B200, and B300. See the Supplier Program.
- Utilization gap: Cast AI's 2026 report puts average GPU utilization at just 5%, the gap onboarding closes.
- Network bar: SF Compute requires non-blocking InfiniBand or RoCE v2 with at least 400 Gbps of back-end RDMA per node, 800 Gbps for B300 (Nov 2026).
What Actually Takes the Longest When You Sell GPU Capacity to a Marketplace: Hardware Validation, Not Paperwork
If you're deciding whether to run your capacity as a neocloud or GPU-as-a-Service business and sell it through a marketplace instead of chasing your own sales leads, the onboarding step is where that decision gets tested against reality. A fleet that's been running fine for your own internal workloads isn't automatically a fleet that passes marketplace validation, because validation checks something different: sustained performance under load, not uptime for whatever you've already been running on it.
SF Compute publishes its cluster acceptance spec, and it's the most detailed public version of what this stage actually checks. Per-host burn-in runs 16-24 hours per node, with at least 24 hours of GPU soak, before cluster-wide testing even starts. That cluster-wide pass runs 24 hours to 5 days, 48 hours by default, and has to clear a specific bar:
| Check | Threshold | Failure class |
|---|---|---|
| Per-node burn-in | 16-24 hours per node, 24+ hour GPU soak | Blocks cluster-wide testing |
| Cluster-wide test window | 24 hours to 5 days (48 hours default) | Must restart on failure |
| Uncorrectable ECC errors | Zero tolerated | Sev-1, blocking |
| Gating XID events | Zero tolerated | Sev-1, blocking |
| NCCL all-reduce bandwidth | Within 0.93 of theoretical peak | Sev-1, blocking |
Every row in that table is rated Sev-1, meaning a single miss blocks acceptance rather than just getting logged as a warning. That's the mechanism behind why this stage eats the calendar: a cluster that fails one NCCL bandwidth check or throws a gating XID event on hour 40 of a 48-hour run doesn't get a partial pass. It goes back to the start of that sequence, on hardware you can't swap out mid-test the way you'd swap out a flagged document in a compliance review.
It also doesn't start until the facility underneath it is actually built for the density these thresholds assume. NVIDIA's DGX-Ready data center certification, created in 2019, checks only the specific technical specifications needed for NVIDIA's own DGX-class equipment to function, and it explicitly does not address broader facility design, resiliency, or commissioning. As of Uptime Intelligence's report, only 38 colocation organizations hold that certification at all, and just 10 of those also hold the newer Liquid Cooled Ready add-on introduced in late 2024. If the power, cooling, and networking underneath your fleet were never built to GPU density in the first place, that's a gap colocation economics covers in detail, and it's a gap no amount of KYC paperwork will fix.
KYC and Export Compliance: What Providers Get Wrong the First Time
The mistake here isn't sloppiness, it's a wrong assumption made early and never revisited: "I just host the boxes, I'm not exporting anything, so export controls aren't my problem." A September 2026 legal advisory from Greenberg Traurig addresses that assumption directly, warning that data center operators who only host tenants' GPU servers, rather than exporting them, may have wrongly assumed export controls were not a material compliance concern, because regulators are now focused on downstream use and custody of the hardware, not just the original export transaction.
The advisory is blunt about what a gap in that chain looks like to a regulator: "Any gaps in a transaction or intermediaries who refuse to provide information may be viewed as a potential red flag." It's equally blunt about the downside of skipping the step: "Failure to perform due diligence or to manage restricted tenants might create liability exposure and reputational risk."
This isn't only a private-marketplace question, either. A proposed BIS rule implementing Executive Orders 13984 and 14110 would require U.S. Infrastructure-as-a-Service providers, including GPU-as-a-service providers and foreign resellers of U.S. cloud capacity, to build a Customer Identification Program collecting identity, payment source, and access-IP data on foreign customers, verify beneficial ownership, and report transactions that could train a large AI model with malicious cyber capability. As of that reporting, the rule hadn't been finalized, and a final version would carry a one-year implementation window. Whether or not that specific rule lands as written, the direction is consistent with what the marketplaces themselves are already building toward. Nodestream, a GPU over-the-counter marketplace, made the same case when it launched: CEO Megan Brooks-Anderson said, "By vetting every supplier and buyer upfront, we de-risk these complex transactions for everyone involved."
Here's where it's worth being specific about what a marketplace's own intake form does and doesn't cover. Spheron's partner page publishes clear vetting criteria for uptime history, networking, and reference deployments, but it doesn't publish a specific KYC or export-control checklist the way it does for the hardware side. If your fleet has any genuine export-control exposure, foreign tenants, cross-border ownership, or a counterparty you can't fully trace, that's diligence you still need to run yourself, with your own legal counsel, before you list. A marketplace's vetting step is not a substitute for it.
Network and Storage Checks a Marketplace Runs Before It Lists You
By the time a reviewer is checking your network, they're assuming the facility prerequisites already passed: real GPU-density power and cooling, not a standard colocation allotment stretched past its rating. What they're checking on top of that is whether the fabric can actually move data at the rate the GPUs can produce it.
SF Compute's spec puts real numbers on that bar: an aggregate external uplink of at least the greater of 2x100 Gbps or 125 Mbps per GPU, at least two route-diverse ISP connections, and non-blocking, rail-optimized InfiniBand or RoCE v2 fabric delivering at least 400 Gbps of back-end RDMA per node for H100, H200, and B200, rising to 800 Gbps per node for B300. Two of those checks, NVLink/NVSwitch intra-node all-reduce within 5% of SKU reference and per-port InfiniBand bandwidth at or above 95% of line rate, are rated Sev-1 failures in the same spec, meaning a fabric that's merely "pretty good" doesn't clear the bar. It either hits the number or the cluster doesn't pass.
This is also where a fleet that was fine for internal workloads most often trips. A node that's been quietly running at 80% of its rated InfiniBand bandwidth for a year because nobody profiled it closely enough passes as "working" right up until it hits a validation suite built to catch exactly that gap, at which point it's a Sev-1 and the clock on that section resets.
What We'd Tell a Provider Selling GPU Capacity to a Marketplace Today
Run your own burn-in before you ever submit to a marketplace, using a public spec like SF Compute's as the benchmark rather than waiting for a reviewer to find the gap for you. Every hour spent catching a bad NVLink bridge or an under-provisioned uplink internally is an hour that doesn't restart a multi-day cluster-wide test on someone else's clock.
Start export and KYC diligence in parallel with hardware remediation, not after it. The two don't share a bottleneck, so there's no reason to let one wait on the other, and compliance is the side most providers underestimate precisely because they didn't expect it to apply to them.
Know your fleet's actual reference-deployment and uptime history before you apply anywhere, because that's the evidence a reviewer checks, not the pitch deck. Spheron's GPU Supplier Program runs this way in practice: apply with fleet details (SKUs, regions, data center tier), get vetted on uptime history, networking, and reference deployments typically in under a week, then list inventory and set your own on-demand and reserved pricing. Matched demand comes with the SKU, region, contract length, budget, and use case shown up front, and the supplier approves and provisions whatever it accepts, with payment on a monthly settlement cycle. It covers H100, H200, B200, and B300 today, there's no reverse auction forcing your price down, and you set and keep your own price floors. It's worth knowing the matching itself is a human-reviewed response rather than an instant automated pass/fail: Spheron's own demand-board writeup is explicit that a supplier's response gets reviewed and matched by Spheron's team, not an instant algorithmic match, trading a few hours of latency for a human check on fit. A provider that wants real-time algorithmic acceptance, closer to how SF Compute's own validation suite works, is better served by that model instead.
Once onboarding actually closes, the work shifts from proving your fleet works to keeping it filled. Cast AI's 2026 State of Kubernetes Optimization report puts average GPU utilization across production clusters at just 5%, and even a well-tuned 136-node H200 inference fleet only reaches 49% utilization, so an idle, fully-validated rack is still a cost center until demand finds it. That's the problem a live GPU demand board is built to solve: real buyer requests by model, term, and region, instead of a rate card and a hope. Spheron's own marketplace refresh and reserved GPU request flow is the mechanism that routes those requests to suppliers once they're listed.
If your fleet already clears burn-in and you're ready to find out what's actually slowing your onboarding down, Spheron's GPU Supplier Program vets uptime history, networking, and reference deployments in under a week and routes demand by SKU, region, and contract length once you're listed.
Frequently Asked Questions
Most marketplaces quote one to two weeks end to end. Spheron's GPU Supplier Program advertises that same 1-2 week average, with vetting on uptime history, networking, and reference deployments typically closing in under a week. The variable that actually stretches the timeline is hardware validation: SF Compute's published cluster acceptance spec alone calls for 16-24 hours of per-node burn-in plus a 24-hour GPU soak, then 24 hours to 5 days of cluster-wide testing before a cluster passes.
Cluster validation is a burn-in and stress-test sequence that checks whether a GPU fleet actually performs at spec under sustained load, not just whether the hardware is present. SF Compute's v1 requirements set zero tolerance for uncorrectable ECC errors and gating XID events, require NCCL all-reduce bandwidth within 0.93 of theoretical peak, and treat NVLink/NVSwitch intra-node all-reduce outside 5% of SKU reference or InfiniBand per-port bandwidth under 95% of line rate as blocking Sev-1 failures. A single failed node or an under-provisioned fabric sends the whole cluster back to the start of that sequence, which is what stretches days into the bulk of the onboarding window.
Yes, according to a September 2026 legal advisory from Greenberg Traurig: operators who only host tenants' GPU servers, rather than exporting them, may have wrongly assumed export controls were not a material compliance concern, while regulators are now focused on downstream use and custody of the hardware. The advisory recommends diligencing every party in the chain of custody, verifying export licenses and the GPUs' ECCN, screening counterparties against the Entity List, and identifying ultimate beneficial owners under the 50% ownership rule.
SF Compute's published spec requires an aggregate external uplink of at least the greater of 2x100 Gbps or 125 Mbps per GPU, at least two route-diverse ISP connections, and non-blocking, rail-optimized InfiniBand or RoCE v2 delivering at least 400 Gbps of back-end RDMA per node for H100, H200, and B200 (800 Gbps for B300). Those thresholds assume the facility side, power, cooling, and physical networking, is already built for GPU density; a rack that still runs on standard colocation power and cooling won't clear this stage regardless of what the GPUs themselves can do.
