Sub-system
An accelerator cluster is the most expensive idle asset an organisation can own. Orchestration is the layer that decides which job runs where, holds a large job's resources together, and recovers when hardware fails — and utilisation is the number it is judged on.
In one sentence
Cluster orchestration is the scheduling and management layer that allocates accelerators to jobs, enforces the all-or-nothing placement that distributed training requires, handles failures, and shares a fleet between competing workloads.
Ordinary schedulers assume tasks are independent and can start whenever a slot appears. Distributed training breaks that: a job needing five hundred accelerators cannot start with four hundred, and if it is given them anyway they sit idle waiting. Gang scheduling — allocate all, or none — is the basic requirement.
Topology makes it harder. Not all placements are equal; a job spread across distant racks runs measurably slower than the same job packed into adjacent ones. A scheduler that treats accelerators as interchangeable units delivers worse performance than one that understands the network's shape.
Because jobs need their whole allocation at once, a fleet gradually fragments into unusable gaps — enough free accelerators in total, never enough adjacent. Schedulers counter this with reservations, backfilling small jobs into gaps, and preemption of lower-priority work, all of which trade fairness against utilisation.
At thousands of accelerators, something fails during any long run. Orchestration has to detect the failure quickly, distinguish a dead node from a slow one, replace it, and restart the job from its last checkpoint. Detection speed matters directly: every minute of undetected failure is a full cluster doing nothing.
Training is batch work that tolerates preemption; serving is latency-sensitive and does not. Operators run both on one fleet by giving serving priority and letting training absorb the leftovers — which raises utilisation and requires training jobs that can be interrupted and resumed cleanly.
Technology dependencies are solved by engineering; supply dependencies are solved by building something, which takes years.
Almost all of this is built on general-purpose cluster management extended with accelerator-aware scheduling.
Container platformsThe scheduler must know the network layout, or it will scatter a job across the fabric and lose performance nobody can find later.
Cluster fabricsRestarting a failed job means every replacement node reads the last checkpoint at once. If that storage cannot serve the burst, recovery time is dominated by the read rather than by the scheduling.
AI storageOther pages in this map that name Cluster orchestration as something they cannot do without.
What each company supplies at this step, and — where a public figure exists — its share of this specific market — with what that share measures, the period it covers and who published it. Some rows also show the company’s own reported revenue for the segment covering this step, which is a different thing: it says how much this business matters to that company, not how much of the market it holds. Not a ranking and not a recommendation.
Created Kubernetes, the scheduler layer most AI clusters are now built on.
Supplies Run:ai and Base Command for scheduling accelerators specifically.
Supplies the supported Kubernetes distribution through Red Hat that most enterprises run.
Maintains Slurm, still the scheduler for most large training runs.
Operates managed accelerator clusters, selling the orchestration rather than the hardware.
Operates the largest single fleet of scheduled accelerators for external customers.
Operates the managed cluster and training services most large runs outside the labs are scheduled on.
Sells managed accelerator clusters with the scheduler included, rather than the machines alone.
Supplies the job layer used where training, serving and data work share one cluster.
Supplies the scheduling and cluster management from its supercomputing side, which is where gang scheduling came from.
Operates managed accelerator clusters and the scheduling in front of them.
Whether utilisation across large fleets improves enough to change the effective cost of compute.
Whether training jobs become routinely elastic, resizing rather than restarting when capacity changes.
Whether accelerator scheduling features move into standard platforms or stay in specialised systems.
Each page explains one technology in plain language, states what it depends on, and names companies by what they supply at that step. Company roles are described qualitatively and deliberately carry no market shares, revenue figures or rankings — those change faster than an explainer can, and a stale number is worse than none. Ticker links point at company pages on this site and are provided for reference only.
Nothing here is investment advice, a recommendation, or a forecast. A company named on a page about a technology is not thereby a good investment, and the chokepoints described are structural facts about supply chains rather than predictions about prices. Technology moves; where a page describes something as unresolved or in development, that was true when it was written.