Transit ops moves GPU nodes from staging into production queues. What HPL requirement should gate that move?
Select an answer to reveal the explanation.
Short Explanation
You’re right to require a successful HPL burn-in before moving GPU nodes from staging into production queues. An OS boot is a good start, but it doesn’t prove the node is ready for sustained work.
Full Explanation
Transit ops should require a successful HPL burn-in pass before moving GPU nodes from staging into production queues, so unstable compute capacity does not serve live municipal workloads. Domain 4 treats HPL burn-in as a production promotion control: staging membership is not proof of sustained compute readiness under Linpack-class load. Moving nodes as soon as the OS boots proves only that they can start, not that they can withstand multi-hour dense floating-point work without throttling, ECC storms, or XID faults. Treating burn-in as optional paperwork invites unverified GPUs into transit training and inference pools and weakens change accountability when jobs fail under load. Running HPL only after users report slow jobs reverses the gate, exposing rider-facing or operations workloads to problems that staging verification should catch. Exam caveat: a successful pass meets the written score, stability, and error criteria for the full burn-in window; launching the binary once or capturing a single peak GFLOPS screenshot is not enough. Practical check: block staging-to-production automation or runbooks until each transit GPU node has attached HPL evidence; rerun after significant firmware or thermal changes, and withhold queue membership until the record is green.