AMD is a silicon vendor that has climbed into serving without ever building a data layer. 0A is its authority and the only cell where it stands with the frontier: EPYC on the host and Instinct as the accelerator, both shipping today. Pensando's NICs read moderate at 0B, a fabric component without the switching. Layers 1B, 2A, 2B, and 3 are real but partial, and all of them rest on the same two artifacts, ROCm and the Enterprise AI Suite. Layers 1A, 1C, and 2C are gaps, the same three NVIDIA and Intel carry, for the same structural reason: an ingredient vendor owns no data foundation, and without one there is nothing for a reasoning plane to reason over. Layer 3 is a gap as well, because AMD sells no business application; its open models are read at 2B.
The capture finding inverts the usual one. Nine of thirteen scored components are Delegated and one is Ceded, which makes this the least captive profile on the instrument. That is not generosity in the scoring. It is the mechanical consequence of a competitive strategy. AMD wins by implementing other people's interfaces: hipVS implements NVIDIA's cuVS API, ROCm-DS is a fork of RAPIDS, AIM exposes the OpenAI-compatible endpoint, the GPU Operator implements upstream Kubernetes Dynamic Resource Allocation, Pollara implements Ultra Ethernet, and Helios is built on the OCP Open Rack Wide standard. A challenger cannot ask customers to rebuild, so it adopts the incumbent's surfaces. The authority side effect is that opinions accumulated on AMD lift back out. The buyer gets portability as a byproduct of AMD needing to make switching cheap.
Two documented facts do most of the work in that finding, and both were verified rather than inferred. The Enterprise AI Suite ships under the MIT license, which is why Resource Manager scores Delegated where NVIDIA's Run:ai scores Ceded, and why AI Workbench scores Delegated where NeMo scores Ceded. And fine-tunes produced in AI Workbench emit safetensors in the standard Hugging Face structure, with LoRA runs producing portable adapter files, so the artifact a customer accumulates genuinely leaves. MIT also ships without warranty, and the repository carries no support statement. AMD provides the code; enterprise support arrives through the OEM's validated platform, which is what Dell is selling when it wraps the suite in PowerEdge and PowerScale.
Where the openness stops is worth stating precisely, because the interfaces port and the effort does not. Kernel-level tuning for CDNA, HIP source, and profile selection are accumulated work that does not lift to a competing accelerator any more than CUDA tuning lifts the other way. The instrument's Delegated calls describe interface portability, not effort portability. The one genuine NVIDIA dependency on this row sits in the same place: HIP is deliberately CUDA-shaped and HIPIFY mechanizes the port, which means AMD's software surface is defined by NVIDIA's API decisions, and any code depending on a CUDA library with no HIP equivalent does not move at all. AMD's adoption path presupposes CUDA as the source language.
The buyer's trade is a genuine second source at compute, fabric, and serving, bought largely on standard interfaces, at a price the incumbent has had no reason to match. In exchange the enterprise accepts a thinner ecosystem, no data layer of any kind, no reasoning plane, support that comes from the OEM rather than the silicon vendor, and a performance-tuning investment that is silicon-specific even where the interfaces are not. AMD is the credible alternative to NVIDIA for three layers of the stack and is not competing at all for the other three.
Layer-by-layer status: Layer 0A (The Second Source: EPYC Hosts and Instinct MI350 Accelerators), Layer 0B (Pollara Ultra Ethernet NICs and the Salina DPU; No Switching), Layer 0C (No Storage on AMD's Paper), Layer 1A (No Data Foundation: Blueprint, Not Platform), Layer 1B (Retrieval Acceleration, Someone Else's Everything Else), Layer 1C (Acceleration Primitives Beneath the Pipeline Layer), Layer 2A (MIT-Licensed Orchestration: Governance Without the Licence Line), Layer 2B (Serving Catalogue on a Standard Endpoint, No Distributed Inference Plane), Layer 2C (Structurally Out of Reach Without a Data Layer), Layer 3 (+1) (No Business Applications; Instella Read at 2B).
Assessment framework: 4+1 Layer AI Infrastructure Model. Scoring model: Decision Authority Placement Model (DAPM) — Retained, Delegated, or Ceded. Published by The CTO Advisor LLC (DBA The Advisor Bench). Author: Keith Townsend. Date assessed: October 27, 2026. Version: v1.25 - 4+1 v3: Layer 0 Sub-Layers.
AMD is a silicon vendor that has climbed into serving without ever building a data layer. 0A is its authority and the only cell where it stands with the frontier: EPYC on the host and Instinct as the accelerator, both shipping today. Pensando's NICs read moderate at 0B, a fabric component without the switching. Layers 1B, 2A, 2B, and 3 are real but partial, and all of them rest on the same two artifacts, ROCm and the Enterprise AI Suite. Layers 1A, 1C, and 2C are gaps, the same three NVIDIA and Intel carry, for the same structural reason: an ingredient vendor owns no data foundation, and without one there is nothing for a reasoning plane to reason over. Layer 3 is a gap as well, because AMD sells no business application; its open models are read at 2B.
The capture finding inverts the usual one. Nine of thirteen scored components are Delegated and one is Ceded, which makes this the least captive profile on the instrument. That is not generosity in the scoring. It is the mechanical consequence of a competitive strategy. AMD wins by implementing other people's interfaces: hipVS implements NVIDIA's cuVS API, ROCm-DS is a fork of RAPIDS, AIM exposes the OpenAI-compatible endpoint, the GPU Operator implements upstream Kubernetes Dynamic Resource Allocation, Pollara implements Ultra Ethernet, and Helios is built on the OCP Open Rack Wide standard. A challenger cannot ask customers to rebuild, so it adopts the incumbent's surfaces. The authority side effect is that opinions accumulated on AMD lift back out. The buyer gets portability as a byproduct of AMD needing to make switching cheap.
Two documented facts do most of the work in that finding, and both were verified rather than inferred. The Enterprise AI Suite ships under the MIT license, which is why Resource Manager scores Delegated where NVIDIA's Run:ai scores Ceded, and why AI Workbench scores Delegated where NeMo scores Ceded. And fine-tunes produced in AI Workbench emit safetensors in the standard Hugging Face structure, with LoRA runs producing portable adapter files, so the artifact a customer accumulates genuinely leaves. MIT also ships without warranty, and the repository carries no support statement. AMD provides the code; enterprise support arrives through the OEM's validated platform, which is what Dell is selling when it wraps the suite in PowerEdge and PowerScale.
Where the openness stops is worth stating precisely, because the interfaces port and the effort does not. Kernel-level tuning for CDNA, HIP source, and profile selection are accumulated work that does not lift to a competing accelerator any more than CUDA tuning lifts the other way. The instrument's Delegated calls describe interface portability, not effort portability. The one genuine NVIDIA dependency on this row sits in the same place: HIP is deliberately CUDA-shaped and HIPIFY mechanizes the port, which means AMD's software surface is defined by NVIDIA's API decisions, and any code depending on a CUDA library with no HIP equivalent does not move at all. AMD's adoption path presupposes CUDA as the source language.
The buyer's trade is a genuine second source at compute, fabric, and serving, bought largely on standard interfaces, at a price the incumbent has had no reason to match. In exchange the enterprise accepts a thinner ecosystem, no data layer of any kind, no reasoning plane, support that comes from the OEM rather than the silicon vendor, and a performance-tuning investment that is silicon-specific even where the interfaces are not. AMD is the credible alternative to NVIDIA for three layers of the stack and is not competing at all for the other three.
CPUs, accelerators, servers, integrated systems, OS and hypervisor, physical plant
The host CPU across AMD's own accelerator platforms and a broad OEM channel. Rests on the multi-vendor x86 instruction set architecture, so accumulated binaries and tuning lift across OEMs and to another x86 vendor without rebuilding.
GA since October 2025 for the MI350 series, with 288GB HBM3e on the MI350X and MI355X, 144GB on the MI350P PCIe card, and MXFP4/MXFP6 support on CDNA 4. Deployed by Oracle Cloud Infrastructure at GA, by Vultr as bare metal and cloud VMs, and by Dell on PowerEdge XE9785, XE7745, and R7725. Consumed through PyTorch, vLLM, and SGLang. ROCm is itself open, so there's no proprietary runtime path to record: workloads on PyTorch, vLLM, or SGLang lift to other hardware without a rebuild. Retained under the Layer 0 runtime rule.
AMD's operator, which "simplifies the deployment and management" of Instinct and Radeon GPUs within Kubernetes clusters, open source under Apache-2.0. Retained, the open GPU operator reading, as on NVIDIA's row.
Assessment pending
AMD is the second source at the accelerator frontier. EPYC is the host CPU across AMD's own accelerator platforms and a broad OEM channel. Instinct is the accelerator: the MI350 series reached GA in October 2025, with 288GB HBM3e on the MI350X and MI355X, 144GB on the MI350P PCIe card, and MXFP4 and MXFP6 support on CDNA 4. The open AMD GPU Operator puts it in front of Kubernetes workloads. Oracle Cloud Infrastructure took MI355X to GA the same month, Vultr offers it as bare metal and cloud VMs, and Dell sells it on PowerEdge XE9785, XE7745 and R7725. Partitioning and Infinity Fabric scale-up read with the silicon. The buyer gets frontier silicon that isn't NVIDIA's. The architect's concern is the borrowed roadmap: memory bandwidth, interconnect topology, power, lifecycle and pricing. Every accelerator buyer accepts that. The difference is who owns the roadmap. AMD sells no integrated rack, so the grade rests on silicon alone. Calibration: NVIDIA reads strong on the frontier it sets; Intel moderate on Xeon with a thin Gaudi line.
Retained where the grade rests. EPYC and Instinct are silicon the enterprise buys inside OEM servers or rents as bare metal, and they make no runtime call on AMD's behalf: enterprise decides, visible, overridable, Retained. Portability: EPYC rests on the multi-vendor x86 instruction set architecture, and ROCm and the GPU Operator are open, so workloads on PyTorch, vLLM or SGLang lift to other hardware, Retained.
Watch-list (not scored): Instinct MI455X, 432GB HBM4 on a 2nm process, product-page launch date July 23, 2026, the SKU AMD sells (Keith, October 16, 2026). Watch-list (not scored): EPYC 9006, formerly Venice, on TSMC 2nm, launched July 23, 2026 with no availability statement; first shipments for Meta in the second half of 2026, and HPE dates its first ProLiant Gen13 system to later in 2026. Named, not scored: Helios, which AMD's FAQ calls a reference design, not a product for sale; a Helios-based rack is measured on the row of whoever sells or rents it.
Hands-on builds on real hardware that test where authority actually holds at this layer.
Interconnects, switching and routing, network virtualization
AMD documents it as the industry's first Ultra Ethernet Consortium (UEC) ready, fully programmable AI NIC, with hardware-based congestion control, for scale-out GPU networking and as a front-end host NIC. Opinions configured against RoCEv2 and the UEC specification lift to another implementer, which is the substantive difference from a proprietary AI fabric.
AMD's 800 Gbps AI NIC for scale-out GPU networking and front-end host networking, documented in a product brief and product guide, in PCIe and OCP form factors and as boards for AMD's Helios rack. It's P4 programmable, with UEC-ready RDMA, Multipath Reliable Connection and MetaRoCE among its transports. Delegated, the Pollara reading: opinions configured against standard RDMA transports lift to another implementer. AMD gives no dated GA statement, and the product documentation lifts it.
Third-generation programmable DPU with 232 P4 match-processing units, handling networking, storage, telemetry, SDN, security, congestion management, and RDMA in one pipeline. Fully P4 programmable per AMD's product materials, and P4 is authored against a target-specific architecture model, so pipeline logic does not port. A SAI reference pipeline running SONiC provides a standards-based alternative consumption path.
Assessment pending
AMD sells the host end of the fabric. Pensando Pollara 400 is, in AMD's words, the industry's first Ultra Ethernet Consortium (UEC) ready AI NIC, and Vulcano 800 takes the same design to 800 Gbps. It brings fully programmable RDMA transport and hardware congestion control to scale-out fabrics spanning thousands of accelerators. The Salina 400 DPU runs networking, storage, telemetry, software-defined networking, security and RDMA in one pipeline on 232 P4 match-processing units. The buyer gets an open-standard scale-out path at the host. The architect's concern is what AMD doesn't sell: the switch. NICs and DPUs without the fabric read moderate. Salina is the captive piece. P4 is written against a target-specific architecture model, so its pipeline logic doesn't port. Calibration: Intel reads moderate on the same shape; NVIDIA strong on the whole fabric.
Delegated where the grade rests. Pollara's hardware congestion control makes the runtime call, and its fully programmable RDMA transport lets the enterprise change how that call is made: vendor decides, visible, overridable, Delegated. Portability: opinions configured against RoCEv2 and the UEC specification lift to another implementer, so Pollara and Vulcano read Delegated; Salina's P4 pipeline reads Ceded, with a SAI reference pipeline on SONiC as the standards-based path beside it.
Confidence flag: whether Pollara's programmable transport is a per-decision override (Delegated) or enterprise-written logic the engine executes (code / Retained) is open, and Intel's Gaudi 3 reading moves with it.
Arrays, storage servers and software, front-end protocols: where the data sits
Assessment pending
AMD sells no array, storage server or storage software. Salina's storage offload is a protocol path a storage vendor's software drives, not placement or protection of the bytes. Calibration: NVIDIA and Intel read gap here too.
Absent: nothing offered and nothing inherited at 0C.
Named, not scored: the Salina 400 storage-offload facet, a storage protocol path without placement.
The data itself, organized and governed: the Governance Catalog that Layer 2C queries
Assessment pending
AMD sells no storage, no AI data-governance platform, and no lakehouse or catalog. The data foundation under an AMD deployment is Dell PowerScale and ObjectScale, HPE Alletra, VAST, or a cloud-native service, and AMD neither owns nor operates any of them. The artifact that could be mistaken for capability here is the AMD Data Intelligence Platform, internally Optima, which turns enterprise data into contextual knowledge graphs for agent-driven automation across IT, security, and the business. AMD describes it as a reference architecture rather than a fixed vendor stack, with everything open, modular, and replaceable, and presents it as a blueprint assembled from components the enterprise already runs. AMD built it for its own IT, ran it, then published the architecture. That is dogfooding published as go-to-market, and it is a fair thing to respect without crediting: the instrument asks whether an enterprise can buy this layer from AMD, and it cannot. SEV-SNP confidential-computing primitives sit inside other vendors' governance offerings, the same structural presence Intel's SGX and TDX have. That is security silicon beneath the governance layer, not a procurable Layer 1A platform. One precedent applied explicitly: AMD markets governance and access controls in the Enterprise AI Resource Manager. That is governance of AI infrastructure access and multi-team resource management, scored at Layer 2A where it belongs. Shipping infrastructure-access governance does not fill a data-governance cell, and function fit is judged against the layer's purpose rather than the feature's name. Calibration: NVIDIA is a gap here with zero components, and Intel is a gap as a substrate provider rather than a storage offering. AMD lands in the same place for the same reason. All three silicon vendors are absent from the data foundation.
None at this layer. AMD provides no data platform, so the enterprise owns the governance function by default and inherits no AMD judgment about how data is modeled, catalogued, or classified. The consequence is felt at Layer 2C, where a reasoning plane would need exactly the metadata AMD has no product to supply.
The AMD Data Intelligence Platform (Optima 1.0 for IT, Optima 2.0 as a shared enterprise platform) is narrated above rather than scored. Same treatment Intel's OPEA receives: a reference architecture the enterprise assembles is not a product the enterprise deploys as its data layer.
Low-latency retrieval for RAG — vector/hybrid search, context windows
Approximate and exact nearest-neighbour and clustering algorithms on Instinct: brute-force KNN, IVF-Flat, IVF-PQ, CAGRA. Ships inside ROCm as part of ROCm-DS, which is what puts it in Dell's validated platform. API-compatible with NVIDIA cuVS, with Faiss API compatibility targeted, so workflows migrate in either direction with minimal change.
Assessment pending
AMD ships retrieval acceleration. It does not ship embedding serving as a product, and it does not ship retrieval infrastructure at all. hipVS is a GPU-accelerated vector search library on Instinct, covering brute-force k-nearest-neighbour, IVF-Flat, IVF-PQ, and CAGRA, documented under ROCm 25.10 as part of ROCm-DS. That is the whole of the scored capability. The embedding AIM serves embedding models as a Helm-deployable microservice, but its documented distribution is as a container paired with a ChromaDB chart inside AMD's RAG blueprints, and a blueprint is not a product an enterprise deploys as its retrieval layer. It is not scored. The retrieval layer itself belongs to somebody else. There is no AMD vector database and no AMD retrieval service; the blueprints reach for ChromaDB. An enterprise standardising retrieval on AMD infrastructure is standardising on Chroma, Milvus, or whatever it chooses, with AMD supplying the embedding compute and the search primitives underneath. Calibration is what decides this cell, and the discriminator is OEM deployment rather than open-versus-closed. Intel is a gap here because OPEA is a developer blueprint whose partner count measures ecosystem engagement rather than enterprise deployment. AMD clears that line on hipVS specifically: Dell's AI Platform with AMD states that the platform uses the AMD Enterprise AI Suite, ROCm, and the AMD Inference Server within a validated on-premises environment, and hipVS ships inside ROCm. The world's largest OEM shipping it in a validated platform is enterprise deployment, not engagement. NVIDIA is moderate here on retrieval acceleration and embedding models without retrieval infrastructure, which is structurally the same shape AMD presents, and AMD is missing NVIDIA's productised RAG pipeline equivalent. The authority finding is more interesting than the grade. hipVS is API-compatible with NVIDIA cuVS by design, and targets Faiss API compatibility, so index-construction and search parameters written against that surface now run on two vendors' silicon. AMD's competitive strategy is interface compatibility, and the second-order effect is that it makes the incumbent's interface portable.
The enterprise delegates retrieval acceleration and embedding serving to AMD and keeps the exit, because AMD chose to implement interfaces that other vendors also implement. Opinions at hipVS accumulate against an API with two independent implementations plus Faiss. Opinions at the embedding AIM accumulate as Helm values, model selection, and endpoint configuration against an OpenAI-compatible surface serving open-weight models. The embeddings carve-out does not reach this cell. That rule scores embedding APIs and their stored vectors Ceded because a proprietary embedding service is the only source of its own vector space, and vectors are useless without the same model at query time. AMD serves open-weight models from the Hugging Face catalogue, so the identical model runs on other silicon and produces identical vectors. The corpus does not need re-embedding to leave, and the premise behind the carve-out fails.
No AMD vector store or retrieval service. Solution Blueprints for RAG pair the embedding AIM with ChromaDB; the blueprints themselves are reference applications and are not scored, matching how the instrument treats both NVIDIA Blueprints and Intel OPEA. The embedding AIM is named here rather than scored. It exposes an OpenAI-compatible API and serves open-weight models, so on the authority axis it would read Delegated, but the exposure test comes first and it does not clear: a container distributed inside a reference blueprint is not a purchasable, customer-administered product. That is the same call this cell already makes on the blueprints themselves, and the same one the instrument makes on Intel OPEA. A briefing showing the AIM sold or supported as a standalone product on AMD paper would move it.
Move/transform data — ETL/ELT, lineage, cost-aware movement, KV cache tiering
Assessment pending
AMD has no ETL or ELT platform, no pipeline orchestration product, no lineage offering, and no cost-aware data movement. The enterprise that wants pipelines buys Databricks, Airflow, a Dell or VAST data platform, or a cloud service. ROCm-DS is the artifact that looks closest. It includes hipDF, a GPU-accelerated dataframe library for tabular manipulation, aggregation, feature engineering, and ETL transformation, and hipGRAPH for graph analytics. hipDF is a fork of RAPIDS cuDF, and that fact settles the grade: NVIDIA's Layer 1C is a gap with zero scored components despite shipping RAPIDS, and scoring AMD's fork of RAPIDS differently from NVIDIA's RAPIDS would make the heat map unreadable. The same code, forked, scores the same way. The reason both fail is the layer's function rather than the library's quality. Layer 1C is orchestration, lineage, and cost-aware movement. A dataframe library accelerates transformations inside somebody else's pipeline; it does not orchestrate the pipeline, does not know where the data came from, and makes no decision about what a movement costs. Intel's cell reaches the same conclusion about oneDAL and DPDK: open substrate and developer tooling beneath the pipeline layer. Calibration: all three silicon vendors sit at gap here, each with a credible acceleration library that does not reach the layer's job.
None at this layer. AMD operates no pipeline, so lineage, orchestration logic, and movement policy remain the enterprise's own, built on whichever pipeline platform it selects. Where hipDF is used, the borrowed judgment is narrow and technical: AMD's kernel implementations of dataframe operations, consumed through a Pandas-shaped API with an upstream equivalent.
ROCm-DS (hipDF, hipGRAPH) narrated rather than scored, mirroring how Intel's oneDAL and DPDK are handled. ROCm-DS being a RAPIDS fork is the same interface-compatibility strategy visible at Layer 1B in hipVS: AMD tracks the incumbent's library surface rather than authoring a rival one, which removes the need for customers to translate and is recorded in prose rather than as a dependency.
GPU scheduling, quotas, RBAC, fair-share scheduling, utilization optimization
Deploys and manages Instinct accelerators in Kubernetes: device-plugin discovery, topology-aware best-effort allocation, and a Dynamic Resource Allocation driver publishing GPUs as ResourceSlices with DeviceClass and CEL-based selection and intra-pod GPU sharing. Validated on vanilla Kubernetes on Ubuntu and on Red Hat OpenShift 4.21. Open source under Apache-2.0 and run by the enterprise, so it reads Retained, the October 5, 2026 operator reading.
AMD's infrastructure and governance layer: authentication, access control, cluster coordination, and quota management, with GPU sharing across projects and user groups and utilisation dashboards at project, department, cluster, and enterprise level. Deployable standalone or combined with AI Workbench. MIT licensed in github.com/amd-enterprise-ai/amd-eai-apps.
Assessment pending
AMD has two things at this layer and only one of them lifts the cell. The AMD GPU Operator, at version 1.5.0, provides the device plugin, topology-aware best-effort allocation, and a Dynamic Resource Allocation driver that publishes GPUs as ResourceSlices with fine-grained device selection through DeviceClass and CEL expressions, including GPU sharing between containers in a pod. That is accelerator enablement inside somebody else's scheduler, and it is precisely the category Intel earned no credit for: its cell is explicit that the OpenShift operators enable Red Hat's orchestration and the scheduling authority stays Red Hat's. Resource Manager is what separates AMD from Intel. It is AMD's own orchestration and governance layer, handling authentication, access control, cluster coordination, and quota management, letting projects and user groups share GPUs, and giving administrators utilisation visibility at project, department, cluster, and enterprise level. Combined with AI Workbench it carves per-project namespaces. Intel's cell states there is no Intel equivalent of Run:ai, GreenLake Intelligence, or OpenShift AI. AMD has one. Calibration: NVIDIA is strong because Run:ai is the GPU-scheduling authority three OEMs rebrand, with fractional GPU sharing, now open source. Dell is moderate owning rack orchestration and a CSI operator while rebranding Run:ai. Intel is a gap on device plugins alone. AMD sits at Dell's level and owns more of its own orchestration code than Dell does, but strong is pegged to the best shipping implementation at the layer, and there is no evidence Resource Manager matches Run:ai on fractional sharing or multi-cluster management. The buyer-facing consequence is a pricing one. For an enterprise that has watched a scheduler licence land on top of its accelerator bill, orchestration that arrives under MIT with the platform is a different commercial proposition from the same function sold separately.
The enterprise delegates orchestration to AMD and can take it back. Resource Manager ships in the amd-eai-apps repository under the MIT licence, which grants permission to deal in the software without restriction. The customer can run it, fork it, and keep operating it if AMD loses interest, and real alternatives exist in Kueue, the KAI Scheduler, OpenShift AI, and Run:ai itself. That is the documented difference from the incumbent at this layer. Run:ai, open source under Apache 2.0 since 2026, now reads Retained too; the difference between the two is maturity, not portability. AMD's equivalent is not the same instrument. The GPU Operator points the same direction: its opinions accumulate as upstream Kubernetes Dynamic Resource Allocation objects, and DRA is the interface Azure contributed upstream, so ResourceSlice and DeviceClass definitions lift to any conformant cluster. MIT also ships without warranty, and the repository carries no support statement. Operational authority is genuinely the customer's; commercial support is the OEM's to supply.
Hierarchical quota and time-based fair-share scheduling appear in third-party Kubernetes write-ups rather than AMD's own documentation and are not credited here. If AMD docs confirm them the capability argument strengthens, though multi-cluster management remains the open question against Run:ai. Re-read October 24, 2026: the v2.1.0 docs marked the AMD enterprise AI reference stack Technical Preview, and AMD Enterprise AI 2.5 (released October 9, 2026) ships without that marker and documents Resource Manager unbadged, a dated owner release with the marker removed, which affirms GA under the GA evidence table. Resource Manager is scored again and 2A holds at moderate.
Model serving, agent execution, inference APIs, distributed inference
Containerised model-serving microservices distributed as Docker images, with an orchestration layer that configures the runtime, detects available accelerators, selects a performance profile, and exposes an OpenAI-compatible API. Catalogue spans frontier open-weight models including DeepSeek and Mistral, optimised for MI350X and MI355X, deployed via Helm.
GA through AIM's OpenAI-compatible serving endpoint. The enterprise owns and operates the business logic, APIs, commands and deterministic validators invoked through tool calls: the seam where control passes from instructing the model to executing code outside it. The opinions are the enterprise's and run against a multi-vendor interface, so they lift to another provider with an adapter and re-evaluation, not a rebuild. What the enterprise cedes at this seam is the decision to act: the model chooses whether, when and with which arguments to call, and that judgment is inherited under the serving component above. Added instrument-wide on September 2, 2026 (M4): the seam exists on every runtime that hands control to portable customer code, and a real Retained position is scored, not narrated.
The open runtime, numerical library, and framework-integration foundation under everything AMD ships above Layer 0, currently at ROCm Core SDK 10.1.0 (October 5, 2026). The direct analogue of Intel's oneAPI in the instrument's structure: open, authored by the silicon vendor, and the substrate its own higher layers depend on.
The production serving path for Instinct deployments, contributed to and maintained in upstream open-source projects with implementations across multiple hardware vendors. Serving configuration and model definitions lift to another vendor's backend.
Lifecycle interface for AI workloads: workspaces, the AIM catalogue, dataset management, and low-code fine-tuning against a certified base-model list with batch size, learning rate multiplier, and epoch controls. Fine-tunes emit safetensors in the standard Hugging Face structure, with LoRA runs producing portable adapter files, so tuned weights leave with the customer.
AMD's first-party fully open language models, trained from scratch on Instinct MI300X by the AMD-AGI group and published as amd/Instella-3B. Includes a 128K-context variant and a reasoning model trained with long chain-of-thought reinforcement learning. Weights, training configurations, datasets, and code all released. Open weights, configurations, datasets, and code the enterprise runs on any silicon: Retained. The model still makes the runtime call inside whatever it powers, which this layer's authority reading carries at the model boundary.
The one genuine NVIDIA dependency on this row. HIP is a C++ runtime API and kernel language AMD designed to align closely with CUDA, and HIPIFY (hipify-clang, hipify-perl) mechanises translation of CUDA source to HIP, marketed by AMD as moving from CUDA without starting over. The dependency is structural: AMD's software surface tracks NVIDIA's API decisions, so the incumbent defines the interface the challenger must follow. It is also incomplete. AMD's own documentation states HIP is not a full replacement for CUDA and HIPIFY cannot translate everything; code depending on a CUDA library with no HIP equivalent does not move, and closing that gap is the customer's problem. AMD's adoption path presupposes CUDA as the source language.
This is the layer where AMD has the artifact Intel conspicuously lacks. Intel's cell states there is no Intel equivalent of NVIDIA NIM, AWS Bedrock, or GCP Vertex AI. AMD ships AIMs: containerised inference microservices distributed as Docker images that detect available accelerators, select a performance profile, and expose an OpenAI-compatible API, with a catalogue that has grown to include DeepSeek and Mistral models and optimisation for MI350X and MI355X. The buyer deploys a Helm chart and gets a served model. Around it sit ROCm as the runtime and library foundation, the vLLM and SGLang backends that are the real serving path in production, and AI Workbench for workspaces, dataset management, and fine-tuning through a low-code interface. What AMD does not have is a distributed inference plane. NVIDIA's strong rests on NIM together with Dynamo, an inference operating system for disaggregated multi-node serving at datacenter scale. AMD has the NIM equivalent and no Dynamo equivalent; disaggregated prefill on AMD comes from upstream vLLM rather than from AMD. There is no AMD agent runtime either, though the incumbent's is alpha and excluded from its own score, so that comparison is close to a wash. Calibration: NVIDIA is strong on a complete inference and lifecycle stack. Intel is moderate on open runtime tooling it authored with no managed service. Dell is moderate while owning no runtime IP. AMD is moderate above Intel's line, because it ships the serving catalogue and standard endpoint Intel does not, and below NVIDIA's, because the distributed-inference layer is absent. Instella is AMD's first-party open model family, developed by the AMD-AGI group and trained from scratch on Instinct MI300X. The family covers a base model, a supervised fine-tuned instruct model, Instella-Long at 128K context, and Instella-Math, a reasoning model trained end to end with long chain-of-thought reinforcement learning. AMD releases weights, training configurations, datasets, and code. It is a 3B-parameter family benchmarked against Llama-3.2-3B, Gemma-2-2B, and Qwen-2.5-3B, so the scale of the bet is not the incumbent's frontier-parity play, but the capability is real, deployable, and open in a fuller sense than open weights alone.
The enterprise delegates serving to AMD and keeps the exit, and at this layer the exit is documented rather than inferred. AIM's opinions accumulate as Helm values, model selection, and endpoint configuration against the OpenAI-compatible completions interface, which independent vendors implement, so client code and configuration lift to vLLM or any other implementer. ROCm and the vLLM and SGLang backends are open with real alternatives. AI Workbench matters most because it is where fine-tuning happens and where capture would normally graduate: AMD's documentation shows PEFT LoRA runs producing adapter_config.json and adapter_model.safetensors, and full fine-tunes emitting safetensors in the standard Hugging Face model structure. The artifact the customer accumulates is portable, which is the difference between this cell and a lifecycle platform whose fine-tunes do not export. The residual cost is real and sits outside the interfaces. Kernel-level tuning for CDNA, HIP source, and performance-profile selection are accumulated engineering that does not lift to a competing accelerator. Interface portability is not effort portability, and the CUDA translation dependency recorded in the NVIDIA column is the sharpest instance of it.
ROCm.ai, unveiled at Advancing AI on July 22-23, 2026, shipped with ROCm 10.0 on August 27, 2026: Hyperloom 1.0.0 and GEAK 4.0.0 are documented GA on rocm.docs.amd.com, while the ROCm CLI ships as a tech preview and stays watch-listed. It layers AI-assisted GPU programming, automated deployment, and an agentic optimisation engine (GEAK for kernel generation, Hyperloom for the profile-to-validated-gain loop) on top of the existing ROCm core, with claimed averages of 3.3x inference and 2.4x training over ROCm 7 on identical hardware. Not confirmed shipping as of this assessment. Its function is developer tooling rather than runtime, so GA would deepen the layer's story more than its grade. The Enterprise AI Suite is MIT licensed and ships without warranty; the repository carries no support statement. Enterprise support for this layer arrives through the OEM's validated platform rather than from AMD directly. Instella moved here from Layer 3 because models earn no Layer 3 grade: a first-party open model family is a model, read at 2B as Nemotron and Mistral's open weights are. It is a 3B-parameter family, so it does not move this cell's grade; the grade rests on the serving stack. Hyperloom and GEAK are developer tooling, not runtime, so they deepen this cell's narrative rather than its grade.
Hands-on builds on real hardware that test where authority actually holds at this layer.
Policy-driven placement and resource coordination — the Autonomy Layer
Assessment pending
AMD ships no policy-driven inference placement, no cross-agent governance control plane, and no agentic coordination product, and makes no Layer 2C claim in reviewed product documentation. Three things could be mistaken for capability. Solution Blueprints include agentic workflows, but applying the routing-is-not-reasoning test, chaining pipeline steps in a Helm chart makes no policy-driven decision about where inference runs relative to data, which model serves which request, or how cost, latency, and compliance are arbitrated at request time. Optima describes an agent-first model where humans govern and agents execute, but that is AMD consuming agentic infrastructure rather than providing it, exactly as Intel's internal platform is treated. Resource Manager's access controls are infrastructure-access governance, scored at Layer 2A, and governance of who may use an accelerator does not fill an agent-governance cell. The more useful finding is that this gap is structural rather than a product decision. A reasoning plane needs governance metadata: which data is sensitive, which models are approved, which compliance requirements apply. AMD has no catalogue, no classification, and no lineage to query, because Layer 1A and Layer 1C are gaps on this row. Even if AMD built a placement engine, it would be reasoning over another vendor's metadata. That has a consequence worth naming for a buyer evaluating AMD as a second source: the substitution works at compute, fabric, and serving, and stops at the reasoning plane, because neither silicon vendor is there. Calibration: NVIDIA, Intel, Dell, and AMD are all gaps here. This is the universal Layer 2C absence the instrument documents across every row, not an AMD-specific deficit.
None at this layer. AMD provides no reasoning plane, so placement policy, model-selection logic, and the arbitration of cost against latency against compliance remain entirely the enterprise's own responsibility, as does the deterministic outcome validation that would make agent decisions verifiable. The enterprise inherits no AMD judgment here because AMD makes none.
ROCm.ai's GEAK and Hyperloom are agents that write and tune GPU kernels. That is AMD applying agents inside its own developer tooling, not a reasoning plane for the customer's agents, and it is watch-listed at Layer 2B in any case. The NVIDIA column is empty because the incumbent has nothing at this layer either; the emptiness describes the layer, not the vendor.
Hands-on builds on real hardware that test where authority actually holds at this layer.
AI-powered business capabilities — business logic, workflow automation
Assessment pending
Gap: the Layer 3 grade rests on first-party business applications the buyer runs, and AMD builds none. There is no AMD equivalent of Palantir Foundry, ServiceNow Now Assist, Salesforce Einstein, or Microsoft Copilot. Its first-party open model family, Instella, is a model, and the instrument reads models at 2B (Nemotron on the incumbent's row, Mistral's open weights); Instella sits there. Silo AI is an owned delivery arm rather than a partner programme. AMD acquired Europe's largest private AI lab for approximately $665 million in 2024, and it continues as AMD's European AI centre of excellence, selling AI strategy consulting, custom model development, MLOps implementation, and production integration on a project basis through direct engagement, with post-acquisition customer work published. An architect can engage AMD to build an AI application, which is a real option on the menu, but a services engagement is delivery, not an application on AMD's paper the buyer runs, so it earns no Layer 3 grade (Dell's Accelerator Services are read the same way). Nor is the layer partner: there is no ISV application ecosystem on AMD's paper here, and the Cohere collaboration and the SUSE and Rancher Government blueprint validations sit beside the platform rather than addressing the layer. Calibration: Intel and NVIDIA read gap at this layer, NVIDIA with its open model family read at 2B. The pending World Labs acquisition (agreed September 28, 2026, expected to close by the end of 2026) is the one asset that could change this cell: World Labs ships Marble, a product that generates 3D worlds, which is closer to a first-party application than anything AMD sells today. It is watch-listed and read at close.
None scored, so the reading is Absent: AMD offers nothing at this layer's function. Silo AI delivery, where an enterprise engages it, is a substitutable-partner call: another systems integrator could deliver an equivalent outcome, and custom solutions built on open models and open frameworks lift out of the relationship. The model judgment the enterprise borrows through Instella is read at 2B.
Poro and Viking, the Nordic and European multilingual open models, are Silo AI provenance rather than AMD Layer 3 offerings: both were three-way collaborations between SiloGen, the TurkuNLP group at the University of Turku, and HPLT, trained on the LUMI supercomputer with compute provided by CSC, and published under the LumiOpen organisation. They are evidence of what Silo AI did before the acquisition and a proof point for large-scale training on AMD silicon, not products AMD sells. Open fact question: whether SiloGen is a proprietary model-development platform distinct from the open model weights. If opinions accumulate in a captive SiloGen surface it is a separate Ceded component; only the open models are scored here. Solution Blueprints are reference applications the enterprise builds from rather than on, and are not scored, matching the treatment of NVIDIA Blueprints on the incumbent's row.
Advancing AI 2026 (July 23, 2026, San Francisco), amd.com product pages (Instinct MI300X/MI325X/MI350 series/MI455X, EPYC, Pensando Salina 400 and Pollara 400, Helios rackscale), enterprise-ai.docs.amd.com (AMD Enterprise AI Suite: AI Workbench, Resource Manager, AIM catalog, Solution Blueprints), rocm.docs.amd.com (ROCm, ROCm-DS, hipVS, HIP, HIPIFY), instinct.docs.amd.com (AMD GPU Operator 1.5.0, device plugin, DRA driver), github.com/amd-enterprise-ai/amd-eai-apps (LICENSE.TXT: MIT), Hugging Face amd/Instella-3B and AMD-AGI/Instella, OCP Open Rack Wide announcement (October 14, 2025), Dell AI Platform with AMD (PowerEdge XE9785/XE7745/R7725), Oracle OCI MI355X GA (October 14, 2025), Silo AI acquisition (closed August 2024) and AMD Silo AI / Combient engagement, published 4+1 model. Layer 0 scored on the shipping MI350-generation architecture per assessment ruling; MI455X, Helios, EPYC Venice, Vulcano 800, and ROCm.ai are watch-listed under the GA-gate. /reconcile (September 1, 2026): the embedding AIM moved from a scored component to prose under the exposure test; its documented distribution is inside RAG blueprints, which this row already does not score. 1B holds moderate on hipVS, which ships in ROCm inside Dell's validated platform and is what separates this cell from Intel's gap. /reconcile (October 5, 2026): Layer 3 moderate to gap because Layer 3 credits first-party business applications (no first-party business application; a model is not one, and Silo AI services delivery is not an application on AMD paper); Instella moved to 2B as a Retained component; the calibration to NVIDIA Layer 3, itself moved to gap, removed. World Labs (agreed September 28, 2026) watch-listed for a Layer 3 re-read at close. Summary gap list and component counts corrected for the Layer 3 move (October 5, 2026). /reconcile (October 5, 2026): Layer 0 runtime rule (ruled September 28 and October 4, 2026). Instinct Delegated to Retained: ROCm is open, so the adopted runtime keeps the hardware swappable. Grade unchanged. /reconcile (October 5, 2026, same pass): the Helios watch note corrected; NVL72 reads Ceded on Dell and Supermicro, and Helios reads Ceded at GA on the integrated-system rule. /ga-check (October 5, 2026): Hyperloom 1.0.0 and GEAK 4.0.0 confirmed GA with ROCm 10.0 (rocm.docs.amd.com), added to the 2B narrative; ROCm CLI stays watched as tech preview. MI455X standalone watch item dropped: Helios-only per amd.com. Grades unchanged. v1.9 (Layer 0 sub-layers, October 16, 2026): Layer 0 split into 0A Compute, 0B Network Fabric and 0C Storage Substrate by runtime decision (Keith, October 16, 2026); storage left 1A for 0C, and 1A, now Data Foundation & Governance, is graded on the catalog that classifies the data. 0A strong, 0B moderate, 0C gap; summary edits (summary worksheet, Keith, October 16, 2026). v1.10 (October 19, 2026, /reconcile): plain-language pass: methodology rule numbers in the prose and audit notes replaced with the reasoning they stood for; no grade, chip or authority reading changed. v1.11 (October 19, 2026, /reconcile voice pass): em-dashes in the prose replaced with periods, colons, commas or parentheses; wording, grades, chips and authority readings unchanged. v1.12 (October 22, 2026, /reconcile): 0B Pollara detail corrected to AMD's own wording ("UEC ready," not "compliant"), and the Pensando Vulcano 800 AI NIC added, Delegated on the Pollara reading. AMD's product brief and product guide document it, which lifts it without a dated GA statement. Found by the 0B fabric research. Grade and authority unchanged. v1.13 (October 23, 2026, /reconcile): 0A's Instinct chip and gap give the MI350P PCIe card its own 144GB figure, which the 288GB series figure had covered; the AMD GPU Operator (Apache-2.0) comes in as a Retained accelerator-enablement chip. Found by the 0A compute research. Grade and authority unchanged. v1.14 (October 23, 2026, /reconcile): the 2A AMD GPU Operator chip moves from Delegated to Retained on the possess-and-operate line, the October 5, 2026 operator reading (Apache-2.0), matching the 0A chip added in v1.13. Cell grade and authority unchanged. v1.15 (October 24, 2026, /reconcile): GA evidence recorded on 1 of 1 Layer 1B chips under the GA evidence table. Grade unchanged. v1.16 (October 24, 2026, /reconcile): Layer 1B GA evidence migrated to the GA evidence table version 2. Grade unchanged. v1.17 (October 24, 2026, /reconcile): GA evidence recorded on 3 of 3 Layer 0B chips under the GA evidence table version 2. Grade unchanged. v1.18 (October 24, 2026, /reconcile): GA evidence recorded on 3 of 3 Layer 0A chips under the GA evidence table version 2. Grade unchanged. v1.19 (October 24, 2026, /reconcile): GA evidence recorded on 1 of 2 Layer 2A chips under the GA evidence table version 2. Grade unchanged. v1.20 (October 24, 2026, /reconcile): GA evidence recorded on 6 of 6 Layer 2B chips under the GA evidence table version 2. Grade unchanged. v1.21 (October 24, 2026, /reconcile): GA evidence table version 2.1 applied: 0 chips recorded or narrowed, 1 to notes. Grade unchanged. v1.22 (October 24, 2026, /reconcile): Stale text corrected from the GA backfill: ROCm version current to the release notes. Grade unchanged. v1.23 (October 24, 2026, /reconcile): 2A prose updated: Run:ai is open source and reads Retained, so it no longer stands for the proprietary-scheduler reading. Grade unchanged. v1.24 (October 24, 2026, /reconcile): 2A Resource Manager restored: AMD Enterprise AI 2.5 (October 9, 2026) drops the Technical Preview marker. Grade unchanged. v1.25 (October 27, 2026): each component now carries a durable offering id; nothing else changed.