A used GPU purchase should identify the exact hardware, explain its documented condition and define what you will accept on arrival. Compare complete offers against that brief. A low unit price alone cannot show whether the purchase will work.
Describe the job before the part
Start with the workload and the existing environment. State whether you need a replacement for a known server or a new configuration. This distinction determines how much flexibility the seller has.
If your software team has already validated a variant, include its part number and required quantity. If the configuration is open, describe the model, precision, context length and expected concurrency. Include the intended framework and any deployment deadline.
Separate requirements from preferences. A specific server compatibility requirement may be mandatory. A preferred manufacturer may be flexible. Labeling them clearly avoids offers that meet the easy preferences while missing the critical constraint.
For a first purchase, ask your integrator to review the brief before you send it. A short review can reveal a missing baseboard, unsupported module or unsuitable cooling arrangement. The GPU specification guide explains how to build the technical shortlist.
Make the unit of sale explicit
Specify whether you are buying individual cards, accelerator modules, a populated baseboard or complete servers. List included bridges, heatsinks, cables, rails and power supplies. Ask the seller to identify exclusions in writing.
A photograph of a complete system does not establish what the price includes. Match the itemized offer to the configuration you intend to install. If parts come from several suppliers, assign responsibility for integration before placing orders.
Separate product facts from unit condition
A manufacturer datasheet explains the design. It does not establish the condition of a particular used unit. For that, request seller records tied to the actual hardware being offered.
| Evidence | Useful for | Does not establish |
|---|---|---|
| Manufacturer datasheet | Published variant specifications | Condition or ownership of the offered unit |
| Label and connector photographs | Matching part numbers and visible condition | Successful operation under load |
| Inventory with serial identifiers | Identifying the units in the offer | Accuracy without corroborating records |
| Dated diagnostic logs | Results under a stated test setup | Every possible fault or future reliability |
| Itemized commercial offer | Included hardware and agreed responsibilities | Technical suitability by itself |
Ask for clear label photographs and an inventory that connects each unit to its records. For a larger lot, agree whether evidence covers every unit or a sample. Sampling leaves uncertainty about units that were not examined.
Keep the original files alongside any summary. Record when the seller produced them and which hardware they describe. If logs and photographs use different identifiers, ask the seller to explain the mapping.
Ask what “refurbished” means in this offer. The word alone does not describe a procedure. Request the work performed, replaced parts, responsible party and supporting records. Record unknown history as unknown rather than turning an absence of evidence into a positive claim.
Read a diagnostic result in context
For NVIDIA hardware, a seller can provide an nvidia-smi -q report to help document the installed GPU and exposed status fields. The available fields depend on the product and driver. A missing or unsupported field is not automatically a failure. Source: NVIDIA System Management Interface documentation
# Read-only information query for the seller's NVIDIA system
nvidia-smi -q
Ask for the report date, driver version and host configuration with the output. Treat the command as an information query, not a complete health test. Keep identifiers visible so the report can be matched to the offer.
NVIDIA distinguishes GPU UUIDs from board serial numbers. A GPU index can change between reboots, and a board serial can be shared by multiple GPUs on one board. Do not use “GPU 0” alone as a lasting unit identifier. Source: NVIDIA device identification fields
A diagnostic suite adds evidence, but its scope matters. NVIDIA states that DCGM diagnostics are not comprehensive and do not replace field diagnostics used for RMA. A passing result therefore needs to be interpreted within the tests performed. Source: DCGM diagnostic limitations
Request the tool version, selected tests, duration and complete output. Ask whether the system was otherwise idle and which power limits applied. An unexplained screenshot of “pass” gives less context than the underlying log.
Have a qualified operator choose and run any load tests. Some diagnostics require access to an idle system and can interfere with other work. This guide does not prescribe running a stress test on an active production server.
Use the manufacturer's equivalent tooling for AMD or Intel hardware. Do not treat a NVIDIA command as a universal accelerator check. Agree which evidence is relevant to the exact product and installation.
Confirm the complete installation
Send the part number and proposed configuration to the server manufacturer or integrator. Request confirmation for the exact chassis and system revision. Similar-looking models can have different supported configurations.
Check physical space, power connectors, airflow direction and the cooling design. A passively cooled datacenter card depends on the surrounding system's airflow. A bare accelerator module needs the intended baseboard and associated cooling assembly.
Check the software environment with the team that will operate it. Record the operating system, driver, firmware and framework requirements. If the workload needs a specific feature, verify that feature on the offered configuration.
For multiple accelerators, include the communication topology in the review. List any required bridges or switching components. Ask who will confirm that the installed system exposes the expected links.
For a new server deployment, ask the hosting provider to review the complete system's power and cooling requirements. Accelerator power alone is not the rack requirement. Include practical details such as rail compatibility and delivery access in the installation plan.
Compare the delivered configuration
Normalize each offer to the same scope and currency. Include the hardware needed to make it usable, integration charges and delivery. Track tax treatment separately with the responsible adviser; this example does not calculate taxes or duties.
The following offers are fictional. They illustrate scope differences and do not represent GPU market prices. Both assume eight units and the same required final configuration.
Scroll across the diagram to read every label
Download diagram| Cost item | Offer A | Offer B |
|---|---|---|
| Eight units | 80,000 | 92,000 |
| Required integration | 18,000 | Included |
| Delivery | 2,000 | 3,000 |
| Total before tax and duties | 100,000 | 95,000 |
Offer A has the lower hardware price. Offer B has the lower total in this example. Neither becomes the preferred purchase until you compare documented condition, compatibility and the commercial terms.
Keep uncertain costs visible. If a bridge price or integration quote is missing, mark the total incomplete. Avoid giving a precise total that silently assumes missing components are free.
Agree what happens on arrival
Before payment, document the expected hardware identifiers and included items. Agree the receiving checks, reporting window and process for a mismatch. Identify who handles transport damage and how the parties will exchange evidence.
Distinguish a seller's stated warranty from a manufacturer warranty. Ask who provides support, what the written coverage includes and whether it applies to this transaction. Do not assume an original entitlement transfers with used hardware.
Verify the supplier's identity and payment instructions through an independently established contact route. If instructions change, confirm the change before acting. Keep the agreed offer and supporting correspondence together.
On receipt, record packaging condition and compare the inventory with the shipment. Have the intended operator complete the agreed checks. Report discrepancies through the agreed process with the matching identifiers and records.
Copy this quote request brief
Fill in what you know. Leave unknowns explicit so the seller can address them. Attach a technical requirement document if your deployment needs more detail.
Model and exact variant:
Manufacturer part number, if known:
Quantity:
Cards, modules or complete servers:
Required accessories and included components:
Existing server or proposed installation:
Workload and software environment:
Required condition and seller evidence:
Delivery destination and target date:
Preferred quote currency:
Acceptance requirements:
Open questions:
What does Cardinal check?
Cardinal sources to a buyer's request and reviews the documents a seller supplies. Manufacturer specifications describe the product. Seller records describe the offered hardware. Cardinal does not claim to perform hardware tests.
Can I request a quote without choosing a variant?
Yes. Share the workload and constraints you know. An incomplete part number is workable when the missing decision is explicit. A hidden compatibility assumption is much harder to resolve.