An AI company needs enormous accelerator capacity that no single provider can supply on the timeline required. Is this a valid reason for multi-cloud, and what does it cost compared with the usual multi-cloud justifications?

Why this justification is different from the usual ones

The standard multi-cloud arguments are weak on inspection:

• "Avoiding lock-in" usually produces a lowest-common-denominator architecture that forgoes the managed services that made cloud worthwhile, paying a permanent tax against a risk that rarely materialises.
• "Resilience against provider outage" is largely a fiction unless the workload genuinely runs active-active across providers, which almost nobody does — and if it does, the complexity introduces more failure modes than the provider outage it protects against.
• "Negotiating leverage" is real but modest, and is usually available through commitment structures without operating on two providers.

Capacity availability is different in kind. If the binding constraint is physical — a scarce hardware generation with allocations decided quarters in advance — then no architectural cleverness produces capacity. Multi-cloud is not a hedge against a hypothetical; it is the only way to obtain the resource.

What makes it tractable in this case

The workload's shape happens to be unusually friendly to multi-cloud, which is why it works here and not elsewhere:

• Training jobs are largely self-contained. A job runs within one provider on one cluster; it does not need low-latency access to services in another provider.
• The interface is narrow. Containers, object storage, a scheduler, high-speed interconnect. It does not depend on a deep stack of provider-specific managed services.
• Data movement is bounded and plannable. Datasets are staged before a run rather than accessed continuously across providers.
• The scarce resource dominates cost, so provider-specific optimisation elsewhere matters less.

What it costs

• Duplicated operational surface. Two identity models, two networking models, two monitoring integrations, two sets of quirks, two on-call knowledge bases.
• Cross-provider data transfer, expensive and slow enough to shape scheduling decisions.
• An abstraction layer that must not become a lowest common denominator, which is a continuous design tension rather than a one-time decision.
• Fragmented capacity. Two pools of accelerators cannot serve one job that needs more than either holds, so scheduling must be provider-aware and jobs must be placeable.
• Slower feature adoption, because anything provider-specific either gets abstracted or creates asymmetry.

The general principle

Multi-cloud is justified when a specific, present constraint cannot be satisfied by one provider — capacity, data residency in a jurisdiction where only one provider operates, a contractual requirement, or a genuinely irreplaceable service. It is not justified by architectural anxiety about lock-in.

The useful test: name the constraint, name the date it binds, and name what you cannot do without the second provider. If those three answers are concrete, multi-cloud is engineering. If they are hypothetical, it is expensive insurance against a risk you have not quantified.