AMD is a silicon vendor that has climbed into serving without ever building a data layer. Layer 0 is its authority and the only cell where it stands with the frontier: EPYC on the host, Instinct as the accelerator, and Pensando as the fabric, all shipping today. 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, and they are the same three gaps 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.
The capture finding inverts the usual one. Eleven of fourteen 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 0 (The Second Source — Silicon Across All Three Sub-Layers), Layer 1A (No Data Foundation — Blueprint, Not Platform), Layer 1B (Acceleration and Embedding Serving, Someone Else's Vector Store), 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) (First-Party Open Models Plus an Owned Delivery Arm).
Assessment framework: 4+1 Layer AI Infrastructure Model. Scoring model: Decision Authority Placement Model (DAPM) — Retained, Delegated, or Ceded. Published by The Advisor Bench LLC. Author: Keith Townsend. Date assessed: August 10, 2026. Version: v1.0 - Initial Assessment.
Raw compute, networking, and acceleration fabric
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 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.
The first NIC compliant with the Ultra Ethernet Consortium standard, with fully programmable RDMA transport and hardware-based congestion control for scale-out fabrics spanning thousands of accelerators. Opinions configured against UEC lift to another consortium implementer, which is the substantive difference from a proprietary AI fabric.
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 is the only vendor besides NVIDIA shipping silicon across all three Layer 0 sub-layers today. EPYC is the host CPU, Instinct is the accelerator, and Pensando is the fabric. That completeness, not any single part, is what earns the grade. The accelerator is generally available and deployed at scale rather than sampling. The MI350 series reached GA in October 2025, Oracle Cloud Infrastructure took MI355X to GA the same month, Vultr offers it as both bare metal and cloud VMs, and Oracle is standing up 50,000 AMD GPUs beginning this quarter. Dell sells it on PowerEdge XE9785 with MI355X and on XE7745 and R7725 with MI350P. The fabric is what separates AMD from Intel. Intel's Layer 0 is capped at moderate specifically because it has no GPU-to-GPU scale-out fabric and no competitor to Spectrum-X, and its own cell calls that absence the most consequential Layer 0 gap for large-scale AI clusters. AMD ships Pollara 400, the first Ultra Ethernet Consortium compliant NIC, with programmable RDMA transport and hardware congestion control, plus the Salina 400 DPU with 232 P4 match-processing units. The exact gap that holds Intel down is the gap AMD fills. The grade arrives by a different route than its peers, and the distinction matters for reading the heat map. Dell and Supermicro both reach strong at Layer 0 partly through rack-scale integration. AMD reaches it through silicon breadth: it has no shipping integrated rack, and Helios first customer shipments are dated late Q3 2026. Scored on the shipping architecture only. Calibration: NVIDIA is strong and owns the accelerator silicon most of the instrument depends on. Dell and Supermicro are strong on rack, thermal, and system integration over other vendors' silicon. Intel is moderate because it is dominant on CPU, thin on accelerator, and absent on fabric. AMD is strong on the strength of a complete, shipping, three-sub-layer silicon position.
The enterprise consuming AMD silicon inherits AMD's architecture decisions on memory bandwidth, interconnect topology, and power and thermal profile, and AMD's product lifecycle and pricing decisions. This is the same structural borrowing every accelerator buyer accepts; the difference is whose roadmap it is. What makes the authority profile here unusual is the substrate under each piece. EPYC rests on the multi-vendor x86 instruction set architecture, so binaries lift across OEMs and to another x86 vendor, exactly as Intel Xeon does. Instinct is consumed through PyTorch, vLLM, and SGLang, open stacks with real alternatives, so the workload lifts to other hardware. Pollara implements a consortium standard with independent implementers, so network configuration and congestion policy lift to another Ultra Ethernet vendor. Only Salina accumulates opinions with nowhere to take them: it is fully P4 programmable, and P4 is written against a target-specific architecture model. A SAI reference pipeline running SONiC offers a standards-based consumption path alongside the captive one, and SONiC scores Delegated elsewhere on the instrument. The NVIDIA column is empty here by construction. This is the one Layer 0 cell on the instrument where the accelerator dependency every other on-prem row carries is structurally absent.
Watch-list (announced or pre-GA, not scored): Instinct MI455X, 432GB HBM4 on a 2nm process, product-page launch date July 23, 2026, with rack shipments dated late Q3 2026 — standalone orderability outside a Helios rack is an open fact question. Helios rackscale, 72 MI455X plus 18 sixth-generation EPYC 'Venice' with Pensando front-end and scale-out networking, declared in full production with first customer racks late Q3 2026 ramping through Q4; SemiAnalysis reports engineering samples and low volume in H2 2026 with mass production slipping to Q2 2027, which AMD disputes. EPYC 'Venice' and the Pensando Vulcano 800 AI NIC both ride the Helios date. On Helios and authority, for when it GAs: Helios is built on OCP Open Rack Wide, the standard Meta contributed to the Open Compute Project, and integrates OCP DC-MHS, UALink, and Ultra Ethernet, presented explicitly as a reference design for OEMs, ODMs, and hyperscalers to adopt and customize. That is the same shape as NVL72, which scores Retained on both the Dell and Supermicro rows, and it is more standards-based than NVL72 given that UALink and UEC are consortium standards where NVLink and Spectrum-X are not. The Ceded risk at Helios GA is not the rack; it is whatever proprietary management and software layer AMD wraps around it.
Durable, governed data foundation — 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.
Serves embedding models as a Helm-deployable microservice exposing an OpenAI-compatible API, distributed as a container and paired with a vector-store chart in AMD's RAG blueprints. Serves open-weight models, so the vector space is reproducible on other hardware.
Assessment pending
AMD ships retrieval acceleration and embedding serving. It does not ship retrieval infrastructure. 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. The embedding AIM, paired with a ChromaDB chart in AMD's RAG blueprints, serves embedding models as a Helm-deployable microservice. 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: 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.
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
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.
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.
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 no open-source alternative matches. 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 is Ceded because it is proprietary with no open exit and the enterprise reaches its own accelerators through NVIDIA's scheduling plane. 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.
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.
The open runtime, numerical library, and framework-integration foundation under everything AMD ships above Layer 0, currently at the 7.x series. 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.
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.
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.
Watch-list (announced, not scored): ROCm.ai, unveiled at Advancing AI on July 22-23, 2026 and described as available beginning August 2026 as part of the release following ROCm 7.14. 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.
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.
AI-powered business capabilities — business logic, workflow automation
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.
AMD's European AI centre of excellence, acquired in 2024, selling AI strategy consulting, custom model development, MLOps implementation, and production integration on a project basis through direct engagement. Enterprise delivery history includes Allianz, Philips, Rolls-Royce, and Unilever, with post-acquisition engagements published.
Assessment pending
AMD builds no enterprise applications. There is no AMD equivalent of Palantir Foundry, ServiceNow Now Assist, Salesforce Einstein, or Microsoft Copilot. Two real things sit at this layer nonetheless. 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. 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 deliver an AI application, which is a real option on the menu. This is not a gap: Intel is a gap here because it has neither a model nor an application, with its startup programme correctly read as developer relations. Nor is it partner, a status reserved for a layer addressed entirely through an ISV ecosystem; AMD's strongest assets at this layer are its own, with the Cohere collaboration and the SUSE and Rancher Government blueprint validation sitting alongside rather than substituting for them. Calibration: NVIDIA is moderate on a first-party open model family, and AMD reaches the same grade on the same basis plus a delivery capability the incumbent has no equivalent of.
Little, and unusually little for a value-plane cell. Instella ships with open weights, open training configurations, open datasets, and open code, so an enterprise that builds on it inherits AMD's model decisions in a form it can inspect, retrain, and run on any silicon. That is the same reading the instrument gives the incumbent's open model family. Silo AI delivery 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 judgment being borrowed is delivery expertise rather than a captive platform.
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.
AMD is a silicon vendor that has climbed into serving without ever building a data layer. Layer 0 is its authority and the only cell where it stands with the frontier: EPYC on the host, Instinct as the accelerator, and Pensando as the fabric, all shipping today. 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, and they are the same three gaps 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.
The capture finding inverts the usual one. Eleven of fourteen 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.