CARDINALEvaluate a used GPU through evidence tied to the offered unit. A diagnostic result needs a hardware identity, date, software environment and explanation of what ran. Agree how the buyer will evaluate delivery before ordering. A passing screenshot alone cannot establish future reliability.
Connect every record to the offered unit
Begin with the inventory. Ask for the manufacturer, model, variant, part number and quantity. Request the identifiers available for each unit. Then ask how those identifiers connect the offer, photographs and diagnostic files.
A model name is not enough. Two accelerators can share a marketing family while differing in memory, form factor or integration requirements. The inventory should identify the configuration you intend to buy, rather than rely on a photograph's caption.
For NVIDIA hardware, the management documentation distinguishes serial numbers, GPU UUIDs and enumeration indices. Indices can change between reboots. Use stable identifiers where supported, and preserve the seller's mapping to physical labels. Source: NVIDIA System Management Interface documentation
For a lot containing several units, build one row per accelerator. Link that row to its evidence files. If the seller provides only sample records, list which units the sample covers. Do not silently treat a sample as evidence for every item.
Ask the seller to explain any unreadable label, missing identifier or contradictory record. A discrepancy is a question to resolve, not automatic proof of fraud. Keep it open in the comparison worksheet until there is a documented answer.
Request the original record and its context
A useful evidence package contains the original output and a short description of the environment. Screenshots can help someone review it, but they should not be the only available record. Cropping can remove the date, selected devices or skipped checks.
Ask who produced the result, when it was produced and which units were installed. Record the server model and configuration. Include operating-system, driver and diagnostic-tool versions. Ask whether other workloads were running during the evaluation.
The purpose is reproducibility. Another qualified operator should be able to understand the seller's setup without guessing. You are not asking the seller to reveal unrelated customer data, credentials or private workloads. Redaction should preserve the facts needed to interpret the result.
NVIDIA's debugging guidance requests system configuration and relevant application information when investigating GPU problems. That supports a practical purchasing rule: keep the environment with the symptom or result. A detached error number is a weak diagnostic record. Source: NVIDIA GPU debugging guidelines
Scroll across the diagram to read every label
Download diagram| Evidence link | What to record | Question if missing |
|---|---|---|
| Unit identity | Part number, stable identifier and label mapping | Does this result describe the offered unit? |
| Environment | Host configuration, software versions and date | Under what conditions was the result produced? |
| Coverage | Selected devices, checks, duration and exclusions | What was actually evaluated? |
| Result | Original output, warnings and seller explanation | Which observations remain unresolved? |
Understand what the diagnostic can establish
A diagnostic checks particular behaviors under particular conditions. Its name alone does not describe the coverage. Request the selected suite or checks, configuration and duration. Ask for the complete result, including warnings, unavailable checks and tests that did not run.
NVIDIA states that DCGM Diagnostics does not repair faults, replace offline field diagnostics or determine RMA eligibility. Failures can originate in the surrounding environment as well as the processor. Tool and plugin availability also affect the available checks. Source: DCGM Diagnostics scope
That does not make diagnostics unhelpful. It means a pass should be described precisely: the stated checks passed on the identified units in the recorded environment. Avoid expanding that statement into a guarantee about every component or future workload.
Likewise, a failed check should remain visible until the responsible party explains it. Request the original failure, the proposed explanation and any later result. Replacing the first report with a clean screenshot removes information a buyer may need.
Monitoring and active evaluation answer different questions
Monitoring can show observed operating conditions over time. An active diagnostic evaluates selected behavior through a defined procedure. Request the evidence relevant to your acceptance plan rather than assuming one replaces the other.
Do not ask a seller to disrupt an operating customer's system simply to satisfy a generic checklist. Agree a suitable evaluation window and responsible operator. This article concerns interpretation of records, not instructions to run stress workloads or change hardware settings.
For AMD equipment, request the corresponding AMD tool output and its version. AMD SMI documents inventory, metric and reliability-related interfaces. The supported fields depend on the hardware and software environment. Do not translate NVIDIA field names into assumed AMD results. Source: AMD SMI command-line documentation
Interpret counters and events carefully
A counter needs a definition and observation period. Ask whether a reported value is cumulative, limited to the current driver session or tied to a particular evaluation. Record any reset or software change that affects interpretation.
NVIDIA distinguishes volatile ECC counters from aggregate counters. Its documentation explains that volatile counts track the period since driver loading, with operating-system behavior affecting that period. A zero volatile counter therefore does not describe the unit's entire history. Source: NVIDIA ECC counter definitions
Do not invent a universal acceptance threshold for every GPU generation. Ask the seller or qualified integrator to interpret the relevant records against manufacturer guidance. Separate an unsupported field from a measured zero, and separate a cleared history from an absence of reported errors.
NVIDIA Xid messages can reflect hardware, software or application problems. The numeric identifier alone may not establish the root cause. Preserve the surrounding event context and any investigation outcome. Source: NVIDIA introduction to Xid errors
A practical review log can use three states: explained, unresolved and not applicable. State the reason beside each entry. Avoid a simple green tick when the reviewer cannot explain what the original value means.
Keep performance evidence comparable
A throughput result is useful only when the workload is specified. Request the model or application, precision, relevant batch or concurrency settings and software versions. Ask whether the result describes one accelerator or the complete system.
Record the configured power limit and relevant system conditions. If two offers use different workloads, keep the results separate. Do not create a percentage advantage from numbers that measure different tasks.
For your own acceptance workload, define the input and desired outcome before delivery. A reproducible functional task can establish whether the delivered configuration supports that task. It still does not establish lifetime reliability or suitability for every future application.
Write a clear acceptance plan before ordering
The plan should name the items being delivered, the evidence expected and the person responsible for each review. Distinguish document review, physical receipt and functional evaluation. These are separate milestones with different information available.
Start with objective questions. Do the delivered identifiers match the offer? Are the listed accessories included? Can the agreed configuration be evaluated using the specified environment? Which results need a seller response before the buyer completes the review?
Use the GPU acceptance checklist as a working template. It deliberately leaves commercial remedies and deadlines blank. Those belong in the actual agreement between the parties, not an assumed universal warranty.
Assign a review owner and record the evidence location. For a multi-unit purchase, state whether functional evaluation covers all units or a defined sample. If sampling is agreed, preserve that limitation in the final record.
Ask what happens when the delivered configuration differs from the evaluated one. A changed server, substituted part or different firmware can affect comparability. Record the difference and obtain the responsible integrator's assessment.
Define the handoff between commercial and technical review
Technical acceptance should not silently decide commercial terms. Keep the agreed process for reporting discrepancies, the responsible contact and any negotiated deadline accessible to the receiving team. If those terms are missing, resolve them before shipment.
The buyer's technical reviewer should record observations clearly enough for the commercial contact to act on them. “Does not work” is less useful than the identified unit, expected behavior, observed result and attached evidence.
Similarly, a commercial promise should not replace missing technical evidence. When a seller offers a remedy, keep both the promise and the unresolved finding in the record. This helps everyone distinguish a proposed resolution from completed verification.
Preserve the evidence at receipt
When the shipment arrives, record the package identifiers and visible condition before the receiving team changes the packaging. Match the delivered inventory to the offer. Follow the agreed receiving process and the manufacturer's handling instructions.
If there is visible damage or a mismatch, preserve the relevant photographs and notify the named contact through the agreed channel. Avoid dismantling equipment to investigate beyond the receiving team's role. Let the responsible technical staff determine the next step.
Keep the seller's original records beside the buyer's receipt and evaluation records. Use separate dates and clear authorship. A buyer's observation should not overwrite the seller's earlier statement, even when the two disagree.
Cardinal checks the documents sellers supply and coordinates sourcing questions. Cardinal does not claim to test the hardware. Ask us to include required seller evidence in the sourcing brief so offers can be compared against the same request.
Common questions
Does a passed diagnostic mean a used GPU is reliable?
It means the reported checks passed under the recorded conditions, assuming the evidence matches the unit. It does not establish every possible failure mode or future reliability. Review identity, coverage and unresolved findings together.
Should I reject every GPU with a reported error?
A reported event needs interpretation in context. Ask the responsible technical party to explain the event using manufacturer guidance and supporting records. Do not ignore it, but do not infer a root cause from an isolated number.
Is a screenshot enough for acceptance?
A screenshot can support review, but request original output and its context. A cropped image may omit selected devices, skipped checks or software versions. The acceptance plan should specify the evidence the parties expect.
Can I reuse another buyer's acceptance checklist?
Use it as a starting point, then adapt it to your exact hardware and workload. Remove checks that do not apply and explain any exclusions. Have the relevant parties agree the final process before ordering.