CMMC vs public cloud: when to evaluate an on-prem GPU pod

The first time a serious customer asks “where does the CUI live?”, a lot of otherwise-good cloud architectures end. Not because the model is wrong. Because the data cannot leave a defined boundary. This page is a decision guide for that moment. It is not a clone of every GPU-cloud bake-off. Those pages live on pacific.space/comparisons and we will not host them on trypacific.space.

The two-hour review

A defense-adjacent team had inference on a public cloud and a demo that made customers lean in. Then the security questionnaire arrived. CUI. Maybe ITAR drawings in the fine-tune set. The staff engineer drew the data path on a whiteboard and stopped at the API boundary. There was no honest way to keep that path and sign the questionnaire. They did not need a comparison of neocloud list prices. They needed to know whether an on-prem pod was even the right evaluation — and what “try” would mean if they booked one.

The rule, said plainly

Cybersecurity Maturity Model Certification Level 2 covers 110 NIST 800-171 controls. Work that handles Controlled Unclassified Information or ITAR-controlled data is not allowed to sit on commercial clouds or public AI APIs. That is a residency rule. It is not a TCO slide. If your workload is ordinary commercial training with no CUI, public cloud may still be the right default — and you should use the mothership comparison pages for that kind of evaluate-the-vendor work, not this satellite.

If the workload is in scope, you are no longer shopping a region. You are shopping a physical boundary. Pacific’s public writeup is on-prem GPU infrastructure for CUI and ITAR. Read it before you book. It will tell you the typical entry is 8–16 managed GPU nodes on your site, operated by Pacific, and that buying the pod does not complete your CMMC program.

What you are evaluating when you “try” a pod

• Boundary: can sensitive work stay inside a defined room, rack row, or enclosure your assessor can walk?
• Control map: which of the physical and boundary controls can the architecture satisfy, and which remain your policies, people, and assessment?
• Operations: identity, data transfer, and admin paths — documented, reviewable, not “trust our SRE Slack.”
• Evidence: named factory, site, and integration gates someone can witness. Not a logo slide.

Pacific is explicit that infrastructure can reduce the scope you must assess — they cite the physical and boundary slice of the 110 controls — and that certification stays yours. If a vendor implies the purchase is the certificate, stop the evaluation. If you still need CoreWeave-versus-X or “why not hyperscaler reserved instances,” open the mothership comparisons index and stay there. Do not expect those URLs to be re-hosted on this domain.

When not to evaluate a pod

If you do not have a CUI or isolation driver, an on-prem pod is the wrong experiment. If you need burst tokens next week and the data is unrestricted, you want reserved or on-demand capacity — that conversation is reserved GPU capacity, not a CMMC pod. If you already own the HGX gear and need a high-density envelope, that is colocation. Trying the wrong product wastes a security review.

The handoff

Read pacific.space/cmmc. If you still need a versus-page, use pacific.space/comparisons. Then book 30 minutes with Harper. The calendar is the only booking path. This satellite’s job is to get the decision right before you spend the call.