You buy GPU capacity on price per GPU-hour. Everything else you find out after you've signed.
Sellers don't give access before a contract, so the only number you can compare is the rate. After delivery, your own tests turn up things, and the seller's answer is that your benchmark isn't their benchmark. So you pay the invoice, plan the next delivery on the same terms, and never quite know what you got.
That's a hard position to be in, and it isn't a failure of diligence. A cluster you rent gives you no way to see it the way its operator does, and there has been no independent way to measure what was delivered against what was promised.
11MAC is that measurement, and the first one is free.
Before your next delivery, establish what your current cluster delivers and which issues are worth taking to the seller. 11MAC runs on an agreed set of your existing nodes and returns guidance: observed GPU health, interconnect performance and reference-workload results, with the evidence and a recommendation for each finding.
Where your agreement specifies a measurable commitment, the guidance compares against it. Otherwise it uses clearly labelled reference targets. The examples below are from real rented hardware; yours will come from your hardware and the checks we agree to run.
What the guidance covers
- What you're getting for what you pay.At the GPU-hour price you supply, the guidance prices the capacity you're paying for, the part of it that failed a check, and, once the measurement covers a window with your jobs on it, the part that sat idle or waited on the network. Why it matters: it turns "is this cluster good" into "this is what $5 per GPU-hour is buying, and this is where it leaks", which is the sentence procurement can act on. Every figure is labelled with the price and window behind it.
Illustration, not a measured fleet: the layout and labels are the real ones, the numbers are invented to show how the money is accounted for and why every figure carries its reason. On the sample fleets the working/idle split is withheld because a short diagnostic window is not a record of how the capacity was used. - Every GPU's health, per node.Memory-error and repair history (ECC counters and row remapping), throttling, clocks, PCIe width, temperature, and the driver's fault codes in the readable kernel log. Why it matters: a GPU with unrepaired memory damage or an active throttle is a full-price GPU doing less than the one beside it, and the counters say which.
32× A100, four servers, from the checks table: one node with a fatal NVSwitch message in its kernel log, one GPU with repaired memory damage on record, and a check that passed. - What the interconnect delivers.Link rates against what you contracted, RDMA write bandwidth between servers, and all-reduce bandwidth inside and across servers at a range of message sizes. Why it matters: every job that spans GPUs waits on these paths; one misconfigured setting can leave a 400 Gb/s link delivering a fraction of that, and nothing on the invoice says so.
32× A100: an RDMA path at 0.39 of 50 Gb/s, with the suspected cause and how to confirm it. 16× H100, two servers over InfiniBand: all-reduce bus bandwidth by message size, inside one server and across both. - Reference compute and memory performance.A fixed, repeatable workload on every GPU: dense compute against the datasheet peak, memory bandwidth against the datasheet figure, and how much of a step waits on communication. These probes identify constraints relevant to training and inference; they do not measure your application's throughput or latency.
16× H100: 68.6–71.2% of the datasheet peak on the reference step. 8× B300: 74.6–78.5% of datasheet memory bandwidth and 14.5% of the step waiting on communication. Each target names its source. - The recommendation: what to do about each miss, who to take it to, and what it costs you.Every check that fails becomes a row: the issue, where, the observed facts, the suspected cause and how to confirm it, the proposed first contact (usually the seller for rented infrastructure), and an estimated cost per day until fixed, at the GPU-hour price you supply. The money is an estimate for deciding what to chase first, labelled as such; it is not an invoice claim. Where the cause is not yet established, the guidance says so rather than guessing.
32× A100: the two misses as rows, each with the observed number, the recommended step, who to take it to, and the cost per day once a price is supplied.
Every check returns one of three verdicts: meets, does not meet, could not judge. Commands, test conditions and the supporting raw outputs are kept with the guidance, so a finding can be reproduced and investigated with the seller rather than argued about.
Three complete examples
32× A100, four servers. One tested RDMA path achieved 0.39 Gb/s on a 50 Gb/s port, with the path MTU as the suspected cause and the confirming step named; the archived example covers the diagnosis, not a re-measurement after a fix. It also records a historical, repaired GPU memory fault and an NVSwitch fault message. Collectives and the reference step were not run in this sample. Open.
16× H100, two servers over InfiniBand. RDMA, intra-node and cross-node all-reduce, and the reference step. No check failed; collection gaps (no ethtool on the image) are disclosed. Open.
8× B300, one server. Intra-node all-reduce and reference compute and memory measurements on Blackwell Ultra. Inter-server RDMA was not testable with one node; there is no MFU verdict (NVIDIA publishes no dense BF16 figure for this SKU) and no kernel-log access. Open.
How it runs
From a host you designate inside your network, over SSH or a kubeconfig, using only the tools already on the nodes. No software is installed on your nodes and no configuration is changed; the guidance and its evidence are written on that host and stay in your environment. Every command it can run is on a 52-line list your security team can review in an afternoon. Active measurements are opt-in and run only on idle nodes inside the window you set, within a GPU-time budget you set.
Why free
11MAC is being validated across GPU types and operating environments. You receive useful guidance on your cluster; we learn which checks work, where evidence is missing, and whether the findings help resolve real issues. Guidance with no actionable fault is a valid outcome. The tool sends no data outside your network; any separate sharing for product improvement is your choice.
Where this can go
For a buyer who finds the first report useful, the same checks extend in three directions: an agreed acceptance protocol for a coming delivery, so nodes are verified against the contract before billing starts; a periodic delivered-capacity statement against the invoice; and, where a fleet is rented for long enough to warrant it, continuous verification with triage, so a check that flips between runs reaches you with the evidence and the seller's name on it. None of this is needed for the first run.