Buy a used H100 or H200 server against a documented system configuration, an agreed acceptance test and written support terms. Confirm whether the offer covers cards, modules, a baseboard or a complete server. Then verify identity, host compatibility, operating evidence and facility fit before comparing prices or committing to delivery.
The GPU model is only the beginning of a purchase specification. A usable server also depends on its processors, memory, storage, networking, power supplies, cooling arrangement and software environment. Two offers with the same accelerator count can leave substantially different work for the buyer.
Start with SecondWatt's GPU catalogue, then request evidence for the particular hardware being offered. The buying method below is designed for industrial and data-center procurement, including buyers evaluating equipment that has already been deployed elsewhere.
Key Takeaways
- Distinguish PCIe cards, SXM modules, baseboards and complete OEM servers.
- Match the exact accelerator variant to a documented, qualified host configuration.
- Agree test conditions and acceptance evidence before the purchase closes.
- Verify ownership, support entitlement and warranty terms for the actual system.
- Compare complete delivered configurations against your workload and facility limits.
Identify exactly what the seller is offering#
Write down the manufacturer, system model, accelerator variant, quantity and included components before reviewing a price. Request photographs of labels and a machine-readable inventory where practical. Resolve any differences between the offer, photographs and reported hardware identities.
The NVIDIA H100 product specifications distinguish H100 SXM and H100 NVL. The H200 specifications distinguish H200 SXM and H200 NVL. These names identify different implementations; the shared generation name does not make their physical interfaces interchangeable.
Hardware scope to identify in every offer#
| Offered item | What the buyer must establish | What it does not establish alone |
|---|---|---|
| PCIe accelerator card | Exact part, host qualification, power and cooling support | Suitability for any physically available slot |
| SXM module | Exact module and supported baseboard/system configuration | A standalone PCIe installation path |
| GPU baseboard | Included modules, interfaces and required host components | A complete independently usable server |
| Complete OEM server | Full bill of materials, firmware and installed configuration | Transferable support or site readiness |
| Rack of servers | Server count plus rack, networking and power boundaries | An integrated, accepted deployment |
Use the H100 SXM dossier and H200 SXM dossier to organize variant research. If the offer concerns a baseboard, identify it as such; the HGX H100 baseboard dossier represents a different purchase object from a complete OEM server.
Ask the seller to list substitutions explicitly. A different network adapter, reduced host memory or missing storage device can change the deployment effort even when the accelerator description remains unchanged. An equivalent component should be accepted through the project specification, not inferred from a short sales description.
Confirm host compatibility and the complete configuration#
The system manufacturer's documentation should govern which accelerator arrangement the host supports. Check the precise chassis and board revision, firmware requirements, power configuration and cooling implementation. A successful boot is useful evidence, but it is not a substitute for a supported configuration or a sustained workload test.
Manufacturer portfolios show why platform identity matters. Supermicro's NVIDIA accelerator systems include different server architectures and cooling implementations. That variety makes it unsafe to transfer a requirement from one server to another merely because both contain the same GPU family.
Configuration schedule for a complete server#
| Field | Evidence to request | Procurement question |
|---|---|---|
| Chassis and system identity | Model, serial and OEM configuration record | Does the delivered unit match the offer? |
| Accelerators | Variant, quantity and device inventory | Are all promised devices present and recognized? |
| Host processors and memory | Installed parts and configuration | Does the host support the intended workload? |
| Storage | Devices, capacity, health and intended use | Are boot, data and scratch requirements covered? |
| Networking | Adapter models, ports, optics and cables | What remains outside the supplied system? |
| Power and cooling | OEM requirements and installed components | Can the receiving facility support it? |
| Firmware and software | Versions, licenses and support conditions | What work is needed before acceptance? |
Keep the physical inventory separate from licensing and subscriptions. Software installed on a disk does not, by itself, establish the buyer's entitlement to use or receive support for it. Ask which rights transfer, which require a new agreement and which are excluded from the offer.
Also identify the rack installation parts: rails, cable management, power cords and any special adapters. These items may be small relative to the server price, but missing or unsuitable parts can delay installation and complicate acceptance. Give each one an inclusion status instead of leaving it under an undefined accessories heading.
Establish ownership, condition and support terms#
Request a documented transaction chain sufficient for the proposed purchase: seller identity, authority to sell, equipment identity and any applicable release conditions. Review sensitive documents through an appropriate private process. Publicly displaying serial numbers or prior customer information is unnecessary for establishing a buying requirement.
Condition descriptions should lead to evidence. For previously operated systems, ask for available operating history, repair records, storage conditions and known faults. For unused equipment, ask about storage, original configuration and whether any warranty period has already started. Neither label alone establishes readiness or support coverage.
Warranty and ownership transfer are separate questions. Dell's ownership-transfer guidance illustrates a manufacturer-specific process with information and regional conditions. It is not a universal server warranty policy. Obtain written confirmation for the actual OEM system, service identifier, destination and proposed buyer.
Support questions that need written answers#
| Question | Required answer |
|---|---|
| Who provides the warranty? | Named seller, OEM or service provider |
| What equipment is covered? | Identified system and included components |
| What is the coverage period? | Start event, duration and any remaining original term |
| Where is service available? | Receiving location and applicable territorial conditions |
| What is the remedy? | Repair, replacement, return or another defined response |
| What is excluded? | Consumables, freight, labor, modifications and other exclusions |
| How is support activated? | Required registration, transfer or new agreement |
Resolve discrepancies before payment milestones depend on acceptance. A seller warranty may be commercially useful, but it should not be described as an OEM warranty unless the underlying entitlement supports that statement. Keep any destination-specific transaction review separate from the technical acceptance checklist.
Agree a reproducible acceptance test#
A credible test plan identifies the equipment, software versions, settings, workload, duration, environment and acceptance criteria. It also states who witnesses the test and which logs the buyer receives. Agree these details before the seller runs a demonstration so the evidence answers the buying question.
NVIDIA DCGM diagnostics provide checks covering areas such as software, device memory and interconnect operation. NVIDIA also states that these diagnostics do not replace its full field diagnostic process. A successful run is evidence within its scope, not proof of remaining life or a universal warranty qualification.
Start with identity and configuration capture, then move to functional diagnostics and a representative workload. Record existing error history before testing and changes observed during the run. An unexplained counter should prompt investigation against the relevant manufacturer's guidance; this article does not prescribe a universal acceptable error count.
Acceptance evidence to retain#
| Test stage | Evidence package | Decision supported |
|---|---|---|
| Identity | System and device inventory, firmware versions | Correct hardware supplied |
| Configuration | Topology, memory, networking and settings | Intended system arrangement present |
| Diagnostics | Commands, versions, results and error logs | Documented checks completed |
| Sustained workload | Workload definition, duration and telemetry | Operation under agreed conditions |
| Restart and recovery | Agreed procedure and observed result | Required operational behavior demonstrated |
| Final review | Exceptions, remedies and signed acceptance record | Commercial acceptance or corrective work |
Record power limits, thermal conditions and any throttling during the workload. Do not create pass thresholds by taking an arbitrary percentage of theoretical bandwidth or maximum GPU power. The acceptance criterion should come from the agreed workload, supported configuration and relevant technical guidance.
Retain the original logs, not only screenshots of a summary. Match every result to the tested system and date. If a GPU, power supply or network adapter changes after testing, identify the change and decide which tests must be repeated before shipment. The accepted configuration should be the delivered configuration.
Separate acceptance evidence from a sales demonstration by agreeing who controls the test inputs. The buyer should know which workload was selected, whether the seller changed power settings and whether all offered accelerators participated. A demonstration can still be useful when access is limited, but its limitations belong in the purchase record.
For a batch of servers, identify whether every unit receives the same checks or whether some evidence comes from a sample. Record the sampling basis and the response if one unit fails. A successful test on one server should not silently become a statement about every server in the shipment. Match the delivery inventory to the units covered by the agreed acceptance method.
Test the workload you intend to run#
An accelerator can pass hardware diagnostics and still be a poor fit for the intended application. Request a workload evaluation that reflects the model, precision, batch size, context length, concurrency and software stack you expect to use. Include host and network behavior where they affect completion time or service quality.
The MLCommons data-center inference benchmark framework distinguishes benchmark scenarios and quality requirements. That provides a useful discipline for comparing results: the benchmark name alone is insufficient without the workload and measurement conditions. A result from another system is context, not a guaranteed outcome for the offered server.
Define the business acceptance measure before running the test. An inference deployment might require a stated throughput while meeting a latency target and output-quality requirement. A training or engineering workload may care about elapsed completion time, memory headroom and repeatability. The right measure depends on the intended service.
Use a small, controlled trial when the production workload cannot be shared. Document what the trial represents and what it leaves untested. Avoid treating a short synthetic run as proof that the system can sustain every production workload or operate indefinitely without intervention.
If comparing two offers, use the same dataset, software versions and acceptance method wherever practical. Where the architectures require different optimized configurations, disclose those differences and compare the resulting service against the same buyer requirement. Otherwise, the test can measure configuration effort rather than a useful purchasing difference.
Check facility readiness and delivery scope#
Obtain the complete server's electrical input and cooling requirements from the system documentation. A GPU power limit is not the server's input rating. Power-supply nameplate totals are also not automatically the normal operating demand. Record the relevant maximum, expected workload demand and required distribution arrangement separately.
Check rack space, service clearances, weight, power connectors, upstream protection and heat rejection with the receiving facility. SecondWatt's power procurement and interconnection roadmap helps place the server delivery inside the wider site programme.
Receiving-site readiness worksheet#
| Interface | Information the buyer should confirm |
|---|---|
| Rack | Available space, loading and service access |
| Electrical | Voltage, connections, distribution and redundancy design |
| Cooling | Required implementation and available environmental conditions |
| Network | Port types, fabric design, optics and external equipment |
| Operations | Monitoring, access, firmware management and support ownership |
| Delivery | Packaging, unloading, inspection and installation responsibility |
Where additional electrical infrastructure is needed, connect the server schedule to the transformer-sizing review and the UPS procurement guide. Those guides support project planning; they do not establish the input requirements of a particular server.
Ask whether the quoted logistics scope includes suitable packaging, shipment preparation and receiving inspection. Record how damage or a configuration discrepancy will be handled. Acceptance before shipment and acceptance after receipt answer different questions, so state which conditions apply at each milestone.
Compare offers and submit a complete request#
Normalize every offer to the required configuration before comparing totals. Separate hardware, missing parts, support, test work, freight, installation and taxes. Keep original currencies and dated conversion assumptions visible. A price per GPU is only meaningful beside the complete system scope and acceptance obligations.
H100 or H200 sourcing brief#
| Requirement | Buyer input |
|---|---|
| Equipment | Exact variant, quantity and cards/modules/systems boundary |
| Workload | Intended application and measurable acceptance requirement |
| Configuration | Required host, memory, storage and networking |
| Condition | Accepted conditions and supporting evidence |
| Support | Required warranty provider, duration and destination coverage |
| Facility | Available electrical, rack and cooling arrangements |
| Schedule | Inspection, shipment and operating targets |
Ask respondents to identify deviations rather than silently substitute components. Where alternatives are acceptable, state the required outcome and request the configuration supporting it. A comparable offer should include the equipment schedule, evidence package, exclusions and the terms under which availability is being offered.
SecondWatt acts as an independent intermediary. To request H100 or H200 sourcing, specify the variant, quantity, cards or complete systems, acceptable condition, destination and target date. Include your required test and support terms so sourcing can focus on candidates that fit the deployment.
FAQ: Buying used H100 and H200 systems#
Is an SXM module a replacement for a PCIe card?#
No. They use different physical and system arrangements. Identify the exact accelerator and the host configuration documented to support it. An SXM module purchase also needs a compatible system path; a photograph or shared GPU generation name does not establish that the buyer can install it in an existing PCIe server.
Is a baseboard offer equivalent to a server offer?#
No. Establish which accelerators and components accompany the baseboard and which host, power, cooling and networking elements remain necessary. Compare that complete deployment scope with a server offer. The baseboard price alone cannot show which option provides the required working system at the lower total acquisition cost.
Does a successful diagnostic run prove the hardware is good?#
It supports the specific checks performed under the recorded conditions. It does not establish future reliability, remaining life or every aspect of application performance. Combine manufacturer diagnostics with configuration review, operating evidence, a representative workload and written acceptance terms. Investigate exceptions rather than reducing the decision to a single pass screenshot.
Can an OEM warranty transfer with a used server?#
Possibly, subject to the actual manufacturer's terms, equipment entitlement, ownership process and destination. Obtain confirmation for the identified server and proposed transaction. Distinguish an OEM entitlement from a warranty supplied by the seller. Neither an original invoice nor a verbal assurance establishes all the support rights the buyer will receive.
Should I compare offers by price per GPU?#
Use that figure only as a secondary comparison after aligning the exact variant and complete system scope. Host configuration, networking, condition, support and acceptance obligations can materially change the purchase. Keep the total delivered configuration price beside any normalized metric so omitted components remain visible to the decision makers.
What information produces a useful sourcing response?#
Provide the exact variant and quantity, acceptable system configurations, workload, destination and schedule. Add the required condition evidence, test method and support terms. If alternatives are welcome, define the outcome they must achieve. This lets respondents propose a documented fit instead of guessing what a short request for H100 or H200 means.