Skip to content
KTI
Talk to us
Technical perspectiveInfrastructureAI and GPU cloud

Installed is not operational: what acceptance testing misses in a GPU cluster.

Every vendor tests its own scope. Here is what fails at the interfaces, and how to test the whole.

Signed off is not the same as ready

A cluster can be racked, cabled and powered, with every vendor reporting that its scope passed, and still not run the workload it was bought for.

Vendor acceptance tests answer a narrow question: does this component do what the contract says? They are worth doing. But each one stops at the edge of its own scope, and a GPU cluster fails at the edges.

The owner has spent the capital and still cannot answer a basic question: is this ready to operate?

Where the interfaces fail

Fabric links that pass a port check can show errors under sustained load, which then look like a storage or application problem. Firmware that is correct for each device can be inconsistent across nodes. Storage that meets its benchmark alone can fall short when every node reads at once. Cooling that holds at idle may not hold when the whole cluster runs at full power.

None of these appears on a single vendor’s test sheet, because none belongs to a single vendor. Documentation adds a further gap: drawings describe the design, and the live environment has moved on since.

Test the system, not the parts

Whole-system validation starts by establishing what is actually there: the real topology, the real firmware, the real connectivity. Then it runs the environment under the conditions it will run in, including failure, and records what happens.

Readiness then becomes something you can measure. Agree the criteria before testing starts, test against them, fix what fails or name who will, and document the result so that the team running the environment can rely on it.