Compare GPUs without comparing the wrong things

1. Match the exact hardware variant

A family name is not a complete configuration. Check memory capacity, form factor, interconnect and whether the offer is a full GPU, a partition or a multi-GPU instance. Do not apply one variant's specifications to another variant's price.

Source: NVIDIA H100 product specifications. NVIDIA also describes an NVL configuration with 188 GB across two linked GPUs; that is not 188 GB on one GPU. These are vendor specifications, not GPUvec workload measurements.

The same care applies to A100 40 GB versus 80 GB, workstation versus server editions, and partitioned GPU offers. Runpod's pricing page lists distinct H100 PCIe, SXM and NVL options and cloud tiers; Lambda's instance page distinguishes A100 SXM memory capacities. Confirm those details on the specific offer, not just its family heading.

Memory is a fit constraint, not a speed score. Check the source's GB/GiB units, model weights, KV cache or activations, batch size and runtime overhead. Memory across multiple GPUs does not automatically behave like one contiguous allocation; the software must support the chosen topology.

2. Keep GPU-hour and instance-hour prices separate

GPUvec normalizes a recorded rate only when its unit is documented. An explicit USD/GPU-hour rate can be compared directly. An explicit USD/instance-hour rate can be divided only by a known, positive integer GPU count. An hourly number with an unknown unit or count is not a comparable per-GPU price.

• A public GPU-hour quote alone does not establish the purchasable instance size, included CPU/RAM, region or stock.
• Separate on-demand, spot/interruptible, reserved and cloud-tier rates. Check billing increments and minimum charges.
• Include storage, data transfer, tax and other provider-specific charges before choosing a budget.
• Missing, zero, negative or non-finite catalogue prices are treated as unknown—not free rental offers. Recorded unavailable offers do not contribute to comparable starting prices.

For a concrete source example, Lambda's public pricing table labels prices PRICE/GPU/HR and lists applicable tax separately, while the page describes multiple instance sizes. Read the table's unit and the selected instance's configuration together.

3. Read evidence and timestamps literally

• Source-backed price: a source URL and verification timestamp identify a recorded quote. They are not a promise that the price is unchanged.
• Source review: a public page may have been reviewed without validating the old offer's exact variant, unit or rate. A review timestamp is not a replacement verification date.
• Historical catalogue entry: when verification is missing, treat the price or specification as unverified. Do not interpret a missing field as zero or a missing feature as unsupported.
• Availability: unknown means confirm with the provider. A source price, GPU release date or catalogue entry does not establish that a matching instance is available in your region now.

Compare source dates and configuration scope before acting. A provider's page update, GPUvec's source review and an offer's verification are different events. Hardware provenance also applies only to the fields and exact variants the linked source supports; it does not validate every legacy field in the catalogue.

No automatic 'today' badge can remove this uncertainty. Open the cited source and confirm the final configuration, rate and capacity in the provider's console before provisioning.

4. Choose the tool that answers your actual question

1. Shortlist hardware with GPU Comparison

   Compare memory, bandwidth, power, recorded throughput and offers side by side. Catalogue FP16/FP32 claims are not reproducible application benchmarks. Compare precision, dense versus sparse operation and board configuration before drawing any performance conclusion.

2. Check NVIDIA hardware in the CUDA Compute Capability reference

   Compute capability identifies hardware features—not a CUDA Toolkit version, a speed ranking or a guarantee that a framework build runs. Check the exact device, driver, toolkit and package. CUDA CC does not apply to AMD or Intel accelerators; evaluate their own supported software stacks instead.

   Reference: NVIDIA's compute capability table.

3. Budget vector-search infrastructure with the Qdrant Cluster Calculator

   Enter vector counts, dimensions, datatype, indexes, payloads, quantization, storage residency and replication. Review RAM, disk and per-node estimates separately. This estimates database capacity—not embedding-generation GPU memory, search latency or a provider deployment guarantee. Quantization retains original vectors; moving data to disk does not eliminate storage or all RAM use.

   Reference: Qdrant capacity planning. Test a representative sample before committing capacity.

4. Use the same data from an agent or application

   The developer guide documents read-only MCP and JSON access. Keep source URLs, units, timestamps and unknown fields with any result you pass to an AI workflow. Agent access is not a reservation, live-stock feed or independent verification of the source data.

5. Decide with a representative run

After the workload fits and the software runs, measure the exact instance with your model, precision, sequence lengths, batch size and latency target. Record software versions, GPU count, elapsed time and useful output. Peak FLOPS alone cannot supply this result.

For a fixed job, compare total billed cost to completion. For serving, compare cost per useful output at the required latency and quality, including idle capacity. A lower hourly rate can still cost more if it takes longer or requires more instances.