The useful question after AMD’s latest data-centre results is not whether Instinct is credible. The question is whether excluding it from a 2026 AI infrastructure tender can still be defended.
AMD reported second-quarter 2026 revenue of $11.5 billion, with Data Centre revenue of $6.7 billion, up 107 per cent year on year. The company attributed growth in part to Instinct accelerator demand and said its Helios rack-scale platform was moving towards production. Those figures show commercial momentum. They do not tell a buyer whether an AMD platform will run a particular model, scale across the intended cluster or receive suitable support.
That is why “AMD or NVIDIA?” is the wrong first tender question. A better question is: what evidence must each bidder provide before its accelerator platform can be accepted for this workload and operating model?
For many procurements, AMD should now be allowed to answer that question. It should not receive a lower technical bar because competition is desirable, and it should not be rejected by habit. This guide explains how to write a fair qualification process.
The short answer for procurement teams
Include AMD Instinct as an eligible accelerator platform when the buyer can run a representative proof of concept and is willing to score the whole system. That assessment should cover:
- Exact model and framework support under the proposed ROCm release.
- Memory fit at the required precision and sequence length.
- Single-node and multi-node completion time.
- Network collective behaviour at the proposed scale.
- Checkpoint, storage and restart performance.
- Monitoring, debugging and operational support.
- Supply, warranty, firmware and lifecycle commitments.
- Total cost per accepted unit of work.
Do not make AMD mandatory merely to create the appearance of competition. If the organisation has device-specific software that cannot be ported within the project, the tender should state that constraint and price the consequence. Equally, a blanket CUDA-only clause should have a technical justification rather than being inherited from an old specification.
GPUMachines can help buyers turn these requirements into a testable GPU cluster configuration before a preferred bill of materials is selected.
What AMD’s results do and do not prove
Financial growth matters because accelerator platforms require sustained investment. Buyers depend on compiler teams, framework integrations, firmware maintenance, reference systems, networking partnerships and support organisations long after the initial shipment. Strong Data Centre revenue is one indicator that AMD can fund and prioritise that work.
The results also indicate that customers are deploying Instinct at meaningful scale. That reduces the risk that a buyer is adopting a laboratory-only product. AMD’s comments about Helios suggest a move towards more integrated rack-scale delivery rather than selling accelerators in isolation.
None of this is workload validation. Revenue does not measure training throughput, inference latency or operator coverage. A roadmap statement does not guarantee a delivery date for a particular customer. An integrated rack design does not prove that the buyer’s storage and network will keep it busy.
Procurement should use the announcement as a reason to test, not as a substitute for testing. The same rule applies to competitor earnings, benchmark claims and launch events.
Write the tender around outcomes
An accelerator-neutral specification starts with completed work. For training, that might be time to reach an agreed model-quality threshold, including evaluation and checkpoint overhead. For inference, it may be sustained tokens per second while meeting latency percentiles and accuracy requirements at several concurrency levels.
The tender should disclose the workload sufficiently for bidders to propose a valid system. Include model families, parameter ranges, sequence lengths, precision policy, dataset shape, expected concurrency and the number of simultaneous teams. State whether custom kernels, sparse operations, mixture-of-experts routing or unusual data types are material.
Avoid converting a current implementation into a hidden product requirement. If a workload uses a CUDA-specific extension, ask whether the extension is essential, replaceable or portable. The answer may still favour a CUDA platform, but it will be an evidence-based result.
Use pass/fail gates for correctness, security and support. Score performance, price, energy and operational fit only after a platform passes those gates. This prevents a fast but incomplete demonstration from winning on a narrow benchmark.
Software readiness is workload-specific
ROCm is AMD’s open software platform for GPU computing. Its documentation covers installation, supported hardware, compilers, libraries and framework integration. That public material is the starting point, not the acceptance certificate.
A bidder should provide a software bill of materials for the proposed platform. Record the operating system, kernel, ROCm version, firmware, container runtime, orchestration components, framework and communication libraries. Pin the versions used during acceptance so the result can be reproduced.
Model repositories often include assumptions that are not visible in a framework compatibility table. Fused attention, quantisation, custom collective code, specialised inference engines and third-party extensions can determine whether the application works well. Test the actual repository and model revision the organisation intends to operate.
Compilation and debugging deserve measured tasks. How long does a new model take to reach a correct first run? Can engineers profile device activity, network stalls and memory pressure? Are useful error messages available when an operation is unsupported? These factors affect delivery schedules even when steady-state throughput is strong.
Support quality must be tested before purchase. Give the bidder a realistic technical incident during the trial and measure diagnosis, ownership and response. A support contract is more credible after the team has used it.
Memory capacity can change the system shape
Accelerator memory is not merely a specification row. It affects how a model is partitioned, which parallelism strategy is required and how much communication the cluster performs.
The buyer should calculate memory for weights, optimiser state, gradients, activations, KV cache and temporary workspace. Precision and checkpointing strategy alter the result. Framework overhead and fragmentation need allowance. A configuration that fits only in a spreadsheet may fail at runtime.
More memory per accelerator can reduce the number of devices needed for a model or allow larger batches and contexts. It can also reduce communication by changing the parallelism plan. The benefit depends on software support and memory bandwidth, so capacity should not be assessed alone.
Ask bidders to show memory telemetry during the real workload. Record headroom and behaviour when sequence length, batch size or concurrency rises. A stable system should not require operating permanently at the edge of out-of-memory failure.
For inference, compare the service shape. One large-memory accelerator may host a model that would otherwise be split. Multiple smaller replicas may deliver better availability or concurrency. The correct answer comes from the service-level target, not the largest memory number.
The server is part of the accelerator
An Instinct tender must specify the surrounding platform. Host CPUs, system memory, PCIe topology, local NVMe, management interfaces and power design affect the result. Accelerators installed behind congested PCIe paths or paired with insufficient host memory will not behave like the reference benchmark.
For standard PCIe devices, inspect lane allocation and switches. Confirm that network interfaces and storage do not contend with accelerator traffic at critical points. Check physical spacing, cooling direction, supported power limits and service access. The PCIe GPU server range illustrates why chassis selection is an architecture decision rather than a packaging detail.
For integrated baseboard or rack-scale systems, examine the high-bandwidth scale-up fabric and host relationship. Ask how failures are isolated, how firmware is coordinated and which components can be replaced in the field. Dense systems may need direct liquid cooling and facility work beyond the server purchase.
The tender should request a topology diagram for every proposed node. Marketing names are not enough. Bidders should identify CPU sockets, NUMA domains, accelerator links, NIC placement and storage paths.
Multi-node networking is a qualification gate
Large training jobs make the scale-out fabric part of the compute platform. An accelerator result obtained within one node cannot predict performance across dozens or hundreds of nodes.
Specify the intended distributed strategy and collective operations. Ask for results at several node counts, including the largest scale available during acceptance. Record useful scaling efficiency and job completion, not only link throughput.
AMD’s platform may be proposed with Ethernet or InfiniBand, depending on the system and integration. The buyer should assess endpoint capabilities, RDMA stack, collective library, topology, congestion control and operational expertise. RoCE and InfiniBand require different operating assumptions; neither should be chosen from nominal port speed.
Failure tests are essential. Remove a link or worker during a long run. Measure detection, checkpoint recovery and scheduler behaviour. A platform that is fast only when every component is healthy may produce poor annual output.
Separate compute, storage and management traffic unless a converged design has been tested under simultaneous load. The tender should state the oversubscription ratio and failure domains rather than using “non-blocking” as an unexplained adjective.
Storage can erase accelerator gains
Accelerator selection receives attention because it is expensive. Storage often receives a peak GB/s target and is left until later. That sequence can create a cluster whose processors wait for data or checkpoints.
Test dataset reads with the real file or object distribution. Include cold-cache starts, concurrent users and data preparation. Measure checkpoint write time and restart time. If the workflow repeatedly loads large model artefacts for inference, test deployment bursts rather than one warm instance.
The storage path includes client software, network interfaces, switches and mount or object settings. The array result alone is not sufficient. A scale-out storage architecture should be evaluated from the accelerator worker’s point of view.
Local NVMe can support caches, scratch data and checkpoint staging. It introduces data-management questions: what is authoritative, what survives a node loss and how is space reclaimed? Require an operating policy rather than a list of drives in the bill of materials.
Build a proof of concept that can fail honestly
A useful proof of concept is designed to expose mismatch. Give each platform the same success criteria and enough tuning support to reach a credible result.
The test sequence should include installation, model enablement, single-node performance, multi-node scaling, storage interaction, failure recovery and an upgrade. Record engineering hours as well as machine time. Require all configuration files and commands as deliverables.
Use at least two workloads if the cluster will serve more than one team. One should represent the largest tightly coupled job. The other should reflect common throughput work such as fine-tuning or inference. A platform can be excellent for one and less suitable for the other.
Check numerical acceptance after performance tuning. Changing precision, kernels or batching can alter model output. Define tolerances and evaluation data before bidders run tests.
Do not let either vendor choose only the comparison it wins. If a feature is unavailable, record it as unavailable rather than replacing the test with a different claim. Honest gaps make the final design safer.
Commercial and supply questions
Competition can improve commercial terms, but the purchase price is one line in the model. Include support, software work, networking, power, cooling, migration and likely utilisation. Compare cost per completed workload over the planned service life.
Ask for delivery terms by component, not one estimated system date. Accelerators, hosts, memory, switches, optics and cooling equipment can have different constraints. Define what happens when a component revision changes before delivery.
Warranty and lifecycle terms need operational detail. Who owns diagnosis when the issue may involve accelerator firmware, server BIOS, a network library and the framework? What logs can be shared? Where are spares held? What is the replacement target?
Avoid assuming that a growing vendor automatically has unlimited supply. AMD’s revenue growth is evidence of demand as well as capacity. Obtain written allocation and delivery commitments for the proposed programme.
When AMD should not win
An AMD platform should not win if the required application cannot meet correctness or support gates within the project schedule. It should not win when the buyer would need to maintain a costly private port with no credible upstream path. It should not win if the proposed supply, support or network design cannot meet the service target.
Some teams have years of CUDA-specific software and operators. Replacing that investment may cost more than the hardware difference. The tender should quantify the port rather than pretending it is free.
A small deployment may also be a poor place to introduce a second accelerator stack. If a team operates only a few nodes and has no AMD experience, the training and maintenance overhead may outweigh negotiating benefits. A hosted pilot can test the platform before an owned purchase.
When excluding AMD is difficult to justify
Exclusion is hard to defend when the tender covers standard frameworks and models that can be tested, the buyer wants supply and price competition, and no mandatory dependency requires another platform.
It is also difficult when memory requirements or system design make an Instinct proposal technically interesting. Rejecting the option before measuring it can force a more complex parallelism plan or prevent a useful commercial comparison.
Public and research buyers often need transparent evaluation. An outcome-based test with published criteria is easier to defend than a brand-specific specification. That does not guarantee an AMD award. It produces a record of why the selected platform fit the work.
Frequently asked questions
Does AMD’s 2026 Data Centre growth prove Instinct performance?
No. It shows commercial adoption and business momentum. Performance and compatibility must be measured on the buyer’s workload, software versions and proposed system.
Is ROCm compatible with every CUDA workload?
No. Framework support is broadening, but custom kernels, extensions and model repositories vary. Buyers should test the exact code and record any porting work.
Should a tender name specific accelerator models?
It can define reference models or minimum requirements, but outcome-based acceptance preserves competition. Where a specific model is mandatory, the technical reason should be explicit.
Which network should an Instinct cluster use?
The answer depends on scale, endpoint support, distributed workload and operator skills. Validate the complete fabric with multi-node collectives and failures. Port speed alone is not a selection method.
Can GPUMachines source AMD accelerator systems?
GPUMachines can review and source suitable AMD accelerator platforms subject to manufacturer availability, regional terms and configuration compatibility. A quote should follow workload and infrastructure qualification rather than precede it.
Is a mixed AMD and NVIDIA cluster sensible?
It can be, particularly for separate workload pools. A single tightly coupled job normally needs a consistent accelerator and software environment. Mixed estates require clear scheduling, images, monitoring and support ownership.
Verdict
AMD has earned a place in serious 2026 AI infrastructure evaluations. Its financial and platform momentum makes automatic exclusion harder to defend, but it does not remove the need for workload proof.
The best tender does not reward a logo. It defines correct completed work, support, failure recovery and lifetime cost, then gives qualified platforms a fair chance to meet those terms. AMD Instinct should win where the evidence is stronger and lose where software, operations or supply do not fit.
To prepare that comparison, ask GPUMachines to review an AMD Instinct or alternative GPU configuration, including the host platform, network, storage, power and proof-of-concept plan.
Sources and Further Reading
- AMD reports second-quarter 2026 financial results - official financial and platform update.
- AMD Instinct accelerators - official product-family overview.
- ROCm documentation - official software support and installation documentation.
- AMD Helios infrastructure guide - related GPUMachines analysis of the rack-scale platform.