Build Your Request

Start with a line item that another buyer can identify without guessing. “AI server GPU” is an application category, not an orderable product. A bare IC request needs the manufacturer and complete ordering code, including package and relevant suffixes. A module request needs the vendor SKU, form factor and configuration. A complete server request needs the OEM model and the specified hardware configuration or approved bill of materials.

The distinction changes what a supplier is pricing. NVIDIA publishes separate H100 SXM and H100 NVL specifications and server options. AMD lists MI300X as an OAM module. These examples show why a family name alone is insufficient; they do not establish compatibility with your target server. Confirm that configuration with the system owner or engineering team before accepting a different variant. Do not treat an internal silicon die or HBM assembly as a directly interchangeable board-level part. Define the actual supply item and require engineering qualification for a proposed change.

  • Record the exact MPN or OEM SKU and the manufacturer’s reference page or datasheet.
  • State bare component, module, board assembly or complete system, and identify the required revision.
  • For modules and systems, list included accessories, power/cooling configuration and required software or support scope.
  • Give the delivery destination and name the person who can approve specification changes.

Define Quantity and Schedule

Separate the quantity needed for the immediate build from later demand. A supplier quoting one evaluation unit is not answering the same requirement as a supplier quoting a production release. State quantities by line and shipment, the unit of measure and whether split deliveries are acceptable. Keep a forecast clearly separate from an order quantity so it is not mistaken for a firm commitment.

Specify required arrival dates rather than writing only “urgent.” Explain whether a partial delivery can support the build and the minimum quantity that makes it useful. Ask each supplier to identify its proposed dispatch and delivery assumptions, quote validity and the event from which its lead time is measured. Availability, allocation and lead time must be confirmed for this RFQ rather than assumed from an article or an old listing.

  • Provide immediate quantity, later scheduled releases and any evaluation quantity as separate fields.
  • Record the required delivery date, destination and whether partial shipments are allowed.
  • Distinguish a stock indication, a written offer and a confirmed order allocation.
  • Ask for any quantity or schedule exception to appear explicitly in the quote.

Set Verification Requirements

Write the required evidence into the RFQ before quotes arrive. For components, identify the acceptable condition, packing, date-code limits and provenance documents required by your quality process. For modules or complete systems, request the offered SKU/configuration and the available serial-number, condition and service-history records relevant to acceptance. Keep required documents separate from desirable information; a supplier should state which items it can actually provide.

Channel and warranty scope also need clarification. TI recommends its direct and authorized channels and states limits on its support and warranty coverage outside those sources. Apply the actual manufacturer’s policy to the offered product rather than assuming one OEM’s terms cover every component. Neither a photo nor a seller’s authenticity statement replaces the evidence and acceptance decision required for your purchase.

  • State any inspection or functional-test requirement, who will perform it and the requested report scope.
  • For a system, identify the intended configuration and the customer-approved acceptance procedure.
  • Ask which provenance, warranty and support documents are available; record outstanding evidence.
  • Require approval for a substitute, changed revision or altered configuration before commitment.

Compare Quotes Like-for-Like

Build a comparison row for each offer using the same ordering code, quantity, condition and delivery requirement. Record unit price and currency, included freight or other stated charges, payment conditions and quote validity. A lower displayed price is not a like-for-like comparison if it covers a different module, excludes required documents or assumes a delivery schedule your build cannot use.

Also compare the proposed trade rule, its version and named location. ICC describes Incoterms rules as allocating costs, risk and obligations between buyer and seller. Capture the supplier’s stated allocation rather than treating a shipping abbreviation as a complete description of the offer. Leave unpriced or unresolved items visible and ask for clarification before presenting a combined cost as confirmed.

Use a written exception list for missing evidence, unapproved substitutions and schedule differences. Send the exact requirement, quantities, dates and verification checklist through the ICULTRA contact page to request a sourcing review; a submitted inquiry is not a stock reservation or purchase order.

  • Compare identical product/configuration, quantity, condition, date-code limits and packing.
  • Compare price/currency, delivery assumptions and the documents or tests included.
  • Record freight responsibilities, quote expiry and any conditions that change the offer.

Sources and further reading

Manufacturer documents support the technical guidance above. They do not confirm our stock, authorisation or the condition of any offered lot.