AI-enabling hardware - GPU, DPU, SmartNIC

In one line

AI infrastructure is built around accelerators (GPUs) kept busy by intelligent NICs (SmartNIC / DPU) that offload networking and storage so the expensive GPUs never wait.

The components

• GPU - the accelerator: massive parallel compute plus high-bandwidth memory (HBM). GPUs connect intra-server by NVLink/NVSwitch (scale-up) and to the network through NICs (scale-out, Scale-up vs scale-out). The GPU is the costly resource everything else serves. Its parallel cores include Tensor cores specialised for the matrix math that dominates deep learning, programmed through CUDA - and CUDA's mature ecosystem is itself a vendor-lock-in factor, raising the switching cost to AMD (ROCm) or other accelerators (Workload placement, mobility, and vendor lock-in).
• SmartNIC - a NIC with offloads (RDMA/RoCE, overlay encap, crypto) so the data path runs in hardware, not on the host CPU.
• DPU - a SmartNIC plus programmable cores (e.g., Arm) and isolation: it offloads networking, storage (NVMe-oF initiator/target), and security, and runs the infrastructure control plane separately from the host - enabling bare-metal multi-tenancy and a zero-trust boundary at the NIC.

SmartNIC implementations (FPGA, ASIC, SoC/DPU)

SmartNICs come in three circuit types with a clear cost/flexibility trade-off: FPGA-based - reconfigurable in the field for a specific domain, but expensive; ASIC-based - highest performance and lowest unit cost, but fixed to predefined capabilities (limited flexibility); SoC-based (the DPU) - dedicated accelerators plus C-programmable cores, giving the best price/performance and the easiest programmability and most flexibility. All offload data/control-plane work (SDN stack, inline crypto, TLS/IPsec, firewall + secure-boot root-of-trust, RoCEv2 / GPUDirect Storage / NVMe-over-TCP, virtual switching) at 25-400 Gbps, saving CPU cycles for the workload.

Sharing and packaging GPUs

Higher-end GPUs support instance sharing - splitting one physical GPU into several isolated instances (e.g. NVIDIA MIG) so smaller jobs/tenants get a cost-effective slice instead of a whole GPU. Above the hardware, GPU orchestration (e.g. Run:ai) schedules and fractionally allocates GPUs across jobs, and converged / hyperconverged AI stacks (FlashStack, Nutanix GPT-in-a-Box) package compute + storage + network as a turnkey unit. On the NIC side, a SuperNIC (e.g. NVIDIA BlueField) is a SmartNIC tuned for scale-out GPU-to-GPU RoCE at the host edge, complementing the DPU's offload role. DPUs also carry a mode decision: in DPU mode the card's embedded CPU owns the port and runs services (firewalling, storage offload, overlay termination); in NIC mode that CPU is disabled and the card behaves as a plain high-speed NIC. The fork has teeth - Cisco's AI-POD FlexPod design disables the BlueField-3's internal CPU on north-south links so that standard LACP port-channels work reliably: you do not get in-DPU services and plain-NIC bonding on the same port, so decide per link which the design needs. The same fork reappears on the east-west path for raw speed: the AI POD training CVD notes the BlueField-3 backend NIC may need NIC mode purely to maximise GPU performance - a BIOS-level change - so mode selection is a per-link services-vs-throughput trade on the collective path as well, not just a north-south bonding fix. A third sharing path is GPU virtualization: vGPU via SR-IOV or hard partitioning exposes one physical GPU to several VMs at near-native performance (common for VDI and inference consolidation), distinct from MIG (hardware-isolated instances) and from full passthrough (a whole GPU to one VM); licensing varies by vendor (NVIDIA vGPU is licensed, Intel's is not). The MIG-vs-vGPU split is spatial vs temporal partitioning: MIG carves the GPU into hardware-isolated instances (dedicated memory/compute, predictable QoS, strict fault/security isolation, up to ~7) - the choice for hard multi-tenant separation; vGPU time-slices the GPU across VMs (shared, over-committable, NVLink-capable, up to ~10) - the choice for VDI/consolidation where flexibility beats isolation.

Above MIG and vGPU sits the scheduler-fairness layer that makes a shared pool workable: orchestration platforms (Run:ai is the validated example on UCS/OpenShift) organise teams into projects with GPU quotas, let jobs run over quota on idle capacity and automatically reclaim (preempt) the borrowed GPUs the moment the owning project needs them, attach compute guarantees to critical workloads so deliberate oversubscription stays safe, and use node pools to constrain where classes of work may land. Dynamic MIG closes the loop - the scheduler re-partitions MIG instances on demand rather than leaving the carve static. The design point: quotas plus reclaimable over-quota plus guarantees are what convert a finite GPU pool into cloud-like elasticity without starving the jobs that pay for it (Cost, ROI, and scalability of AI infrastructure).

A modular-chassis corollary: GPUs need not live inside the compute node at all - a PCIe expansion node (Cisco's X440p pattern: a sled of GPUs paired to an adjacent compute node through the chassis fabric modules) decouples GPU capacity from server refresh, so accelerators are added, upgraded, or re-paired without touching the server itself.

Sharing in practice: vGPU fine print and MIG-backed vGPUs

The MIG-vs-vGPU fork above hides fine print the validated designs spell out. In vGPU mode only compute is time-sliced - memory is statically partitioned: the scheduler is round-robin and work-conserving (a slice may borrow idle cycles, so performance varies with neighbours), while each vGPU's frame buffer is a fixed carve. A homogeneous-profile rule rides along: every vGPU on one physical card must use the same profile - the first profile assigned locks the card - so capacity planning is in equal slices per GPU (an 80 GB card yields anywhere from 1 full slice to ~20 small ones, never a mix). The plumbing underneath is SR-IOV: the card exposes virtual functions (up to ~20) that bypass the hypervisor per slice, enabled in the server BIOS policy. MIG-backed vGPUs occupy the missing cell of the matrix: hardware-isolated MIG instances underneath, the hypervisor's vGPU operational model on top - predictable QoS with no cross-tenant contention, still managed, licensed, and live-migrated like any vGPU estate. One penalty deserves its own sentence: enabling MIG on an A100-class card disables GPU-to-GPU peer transfers entirely (PCIe and NVLink) - a partitioned card cannot join a tensor-parallel group, so slicing a GPU for tenants trades away its scale-up path (Scale-up vs scale-out).

Three more validated clauses complete the sharing picture. Licensing is an availability dependency: NVAIE vGPUs must reach a license server - an on-prem delegated license server appliance or the vendor cloud service - and unlicensed vGPUs degrade, so the licensing plane joins the failure-domain analysis and an air-gapped estate must host the on-prem variant (AI security design and hosting models - air-gapped, private, public). The attach mode follows model size: vGPU profiles suit many small models or replicas sharing cards, while a 70B-class model takes the whole physical card by passthrough - which also removes the hypervisor GPU-driver layer entirely, one fewer stack to patch. And GPU-attached VMs reserve all of their memory (a PCI-device rule), so the virtualised platform's memory over-commit ceilings simply do not apply to the GPU estate - size those hosts on full reservation plus the hypervisor's own share. The host posture flips with them: GPU servers get a cloned BIOS policy (high-throughput CPU, memory-mapped I/O above 4 GiB enabled) and a high-performance power policy, making the AI tier an explicit, documented exception to the fleet's balanced-power baseline (Sustainability - Green AI, power and cooling) - the energy-policy sibling of the Secure-Boot exception above.

The hyperconverged archetype: the platform is the cluster

The turnkey stacks above split into two shapes worth telling apart. A converged stack (FlexPod / FlashStack class) keeps a discrete storage array behind the fabric; a hyperconverged (HCI) platform (the GPT-in-a-Box class) dissolves the array entirely: a storage controller VM on every node pools the node-local NVMe into one shared-nothing distributed store, so compute, storage, and GPU capacity scale together in single-node increments. The validated envelope is deliberately modest - 4 to 16 nodes, at least 24 cores per node, plain 100GbE unified Ethernet (no lossless RDMA build), each node carrying two PCIe inference GPUs exposed through the vGPU host driver. Two consequences carry design weight. First, the services tax: the controller VM (validated at 16 vCPU + 64 GB per node), the file-service VMs, the object-store workers, Kubernetes control planes, and management all run on the same cluster they serve, so workload capacity is what remains after the platform has eaten - and n+1 failover headroom for compute and storage rebuild must be reserved on top. Second, the partitioning menu shrinks: inference-class cards (L40S class) expose no NVLink and no MIG, so GPU sharing on this archetype is vGPU time-slicing or whole-GPU passthrough - the hardware-isolated-instance option is simply not on the card. The fit follows: HCI wins the inference / RAG scale - a handful of GPUs, one ops team, edge-to-DC span, everything operated as one appliance-like cluster (Service placement - on-prem, cloud, hybrid, distributed); it is the wrong envelope for multi-node training, which needs the lossless fabric and per-GPU bandwidth of the dedicated pod (Validated reference design - Cisco AI-ML lossless fabric (CVD)). Note the opposite scaling grain, too: the AI-POD grows in leaf-pair granules, the HCI cluster in single nodes - the smallest honest unit of growth is itself a selection criterion. Storage mechanics continue in Storage and checkpointing for AI.

Virtualised or bare metal: where the container platform stands

Both stances are Cisco-validated, and the fork is worth arguing explicitly. The bare-metal pole (the FlexPod OpenShift AI design) boots the container OS directly on the servers (local M.2 RAID-1 boot media), runs CSI storage straight to the array, and hands GPUs to the platform natively - the fewest layers between model and metal, the pole to pick when GPU density and the storage fast path dominate. The virtualised pole (the Adaptive Solutions OCP design) runs every cluster node as a VM under the hypervisor, buying placement automation with anti-affinity rules that keep control-plane nodes on distinct hosts, hypervisor-level HA, and one operating model for an estate that is still mostly VMs - but a validated discipline rides along: keep pod CPU over-commitment under ~1.8x physical cores and memory under ~0.9 of physical, treat etcd on the control plane as the latency canary, allow compute-only live migration (one control node at a time, letting etcd re-sync before the next), treat storage vMotion as off-limits for CSI-backed volumes - migrating the datastore invalidates persistent-volume references and can lose data - and hold spare worker capacity for failover. The selection rule: virtualise when consolidation economics and existing hypervisor operations dominate and the AI tier is one tenant among many; go bare metal when the platform is the AI tier. Storage-path consequences continue in Storage and checkpointing for AI; who owns pod networking is a fabric question (Connectivity models and SDN in AI fabrics).

For this fork the CPU-inference case adds a measured data point: the same IPEX/DeepSpeed runs on a hypervisor-hosted worker did not significantly differ from bare metal - both held the sub-100 ms bar - so for memory-bound CPU serving the virtualisation tax is negligible and the fork is decided by the operational and storage constraints above, not raw performance.

The bare-metal pole's node OS deserves one more sentence: the validated systems are immutable and transactional (SLE-Micro / RHCOS class) - a read-only root, updates applied as filesystem snapshots that activate atomically on reboot, and rollback by booting the previous snapshot if the new one misbehaves - plus remote attestation of node integrity. Attestation itself is a triad the NCP reference makes explicit, applied to every processor in the estate - hosts, BMCs, and DPUs alike: secure boot enforces the signed chain of trust; measured boot extends a TPM digest of every stage into an audit trail that catches what secure boot cannot - compromised signing keys - after the fact; and remote attestation has a verifier challenge each TPM (nonce included) against golden values before the node is trusted. Node state becomes declarative and drift-resistant: the platform manages the OS, nobody patches it by hand.

The data-platform archetype: the lake anchors, farms attach

The validated data-intelligence pattern inverts the GPU-first archetypes above: the anchor is the data estate, and compute attaches to it. Three tiers scale independently - a data lake on dense storage servers, a containerised AI/compute farm (Kubernetes - an embedded container service or OpenShift - carrying the GPU workers), and a dense, low-$/TB archive tier the lake retires cold data into. The farm is stateless: it reaches the lake over the fabric through S3 or HDFS semantics rather than owning disks, so GPU capacity and lake capacity become separate purchasing decisions. Governance rides a shared-metadata layer independent of both compute and storage (SDX-class): security and lineage policy is written once and travels with the data, and every containerised application shares one lake instance instead of each cluster keeping its own copy of security and governance state. Validated role anchors: the lake runs 3 admin plus 8+ data nodes, the farm 3 management nodes plus GPU workers - and the minimum starter grows to nine data nodes when erasure coding is intended (Storage and checkpointing for AI). Against the AI-POD's leaf-pair granule and the HCI node granule, this archetype's granule is per tier - buy storage, compute, or archive independently as each pressure grows.

GPU form factors and tiers (SXM vs PCIe)

The same GPU ships in two form factors with a real design consequence: PCIe cards drop into a standard slot (simple, but GPU-to-GPU goes over PCIe), while SXM modules seat on a socketed baseboard with NVLink/NVSwitch between them - much higher GPU-to-GPU bandwidth, the choice for dense scale-up (Scale-up vs scale-out). Vendors also tier by workload: top training/HPC parts (e.g. NVIDIA H100/A100, MIG up to 7 instances) versus cheaper inference parts (e.g. A30, MIG up to 4). On the NIC side, the SuperNIC scales to 400 Gbps to match.

CPU as an inference accelerator

Not all AI needs a GPU. Modern server CPUs ship with built-in matrix accelerators - e.g. Intel AMX (Advanced Matrix Extensions) on Xeon Scalable - that meaningfully speed up deep-learning inference (and lighter training) on the CPU itself, with framework support (e.g. Intel's PyTorch/TensorFlow extensions) so model code runs unchanged. For inference tiers, smaller models, or SLMs (AI-ML workloads and their infrastructure impact), serving on AMX-equipped CPUs can be the cost-, power-, and footprint-efficient choice, avoiding discrete-GPU capital where a GPU would sit underused - a real placement and TCO lever (Cost, ROI, and scalability of AI infrastructure, Sustainability - Green AI, power and cooling).

The doctrine now has a validated envelope and a mechanism worth naming. Precision is the accelerator switch: AMX engages only on INT8/BF16 datatypes, so quantizing a model is not just a memory saver - it is what turns the built-in accelerator on; Weight-Only Quantization (WOQ) (weights to int8, activations kept higher-precision) is the accuracy-preserving default for CPU serving, while AVX-512 carries the non-DL stages (pre/post-processing) of the same pipeline. The envelope from Cisco's Xeon white paper: current server CPUs are positioned for models up to ~20B parameters (inference and light fine-tuning), and validated 7B/13B chat serving stayed under the ~100 ms/token norm (AI-ML workloads and their infrastructure impact) on a single two-socket node at batch sizes 1-16 and 256-1024 input tokens - 2nd-token latency growing linearly with batch size, WOQ-int8 slightly ahead of BF16. What made this viable is memory, not FLOPs: DDR5's ~1.7x bandwidth step and last-level caches up to 320 MB attack the memory-bound decode bottleneck. Two placement mechanics complete the picture: DeepSpeed AutoTP partitions one model across sockets or nodes with oneCCL collectives - the scale-out pattern in miniature, the socket acting as the CPU's NUMA scale-up domain (Scale-up vs scale-out; the white paper validated single-node two-socket only) - and in a mixed-generation fleet, accelerator capability becomes a scheduling constraint: Node Feature Discovery labels AMX-capable nodes so the orchestrator pins AI pods to them rather than assuming a uniform fleet (the medical-imaging validated pattern's mechanism).

One more validated multiplier: the inference runtime is a first-order sizing variable on CPU. At identical hardware and precision - before any weight compression - the optimized runtime (graph-compiled, AMX-aware kernels) delivered ~3x TPOT and ~3.5x TTFT over the stock framework, with INT8/INT4 compression stacking a further ~1.4x/1.8x on top; a "CPU cannot meet the SLA" verdict reached on an unoptimized stack is therefore invalid, and CPU capacity plans must name the runtime they assume.

The validated serving posture for this pole is a NUMA-alignment discipline: pin inference pods to whole physical cores inside a single NUMA node (topology manager single-NUMA placement, static CPU allocation, statically reserved memory, a latency-tuned node profile) - second-token latency on a memory-bound decode is a locality property, and letting the scheduler smear a model across sockets is how the sub-100 ms bar slips. A second validation (hypervisor-hosted OpenShift on 5th-gen Xeon, Llama-2 7B/13B) confirms the white-paper envelope with inputs to 2048 tokens at batch 1-8 still under 100 ms second-token latency, adds SmoothQuant-class activation smoothing as the accuracy keeper when full-int8 (not just weight-only) is wanted, and packages the same pole down to the edge as a single-node cluster - all roles consolidated on one server.

Inside the server: PCIe locality and the E-W / N-S NIC split

NVIDIA's Enterprise RA states the server-internal doctrine the rail design assumes. PCIe locality: GPUs are balanced across CPU sockets and root ports, and the NIC and NVMe devices sit under the same PCIe switch or root complex as the GPUs they serve - so GPUDirect RDMA and GPUDirect Storage traffic never detours through the CPU; each GPU ideally owns a Gen5 x16 link, with direct CPU attach preferred where no fan-out is needed. Sizing anchors per GPU: roughly seven physical CPU cores and 128 GB of host memory (plus about two cores per MIG instance) keep the accelerator fed. And the NIC roles split cleanly: several SuperNICs per server carry east-west collectives (up to 400G each - the server-level face of the rail, Rail-optimized CLOS topology) while a single DPU fronts all north-south traffic - storage ingest, management, security offload - the server-level mirror of the front/back-end fabric split (Connectivity models and SDN in AI fabrics, Validated reference design - Cisco AI-ML lossless fabric (CVD)).

The doctrine has a sharp negative case: GPUDirect is a topology property, not a software toggle. Cisco's FlexPod GPU-scaling CVD validated eight C240 M7 rack servers and could not use GPUDirect RDMA at all - that server class has no PCIe switch between NIC and GPU, so peer DMA is impossible and every transfer bounces through the processor. Server selection therefore carries a checkable prerequisite: confirm the internal PCIe topology (a switch or root complex shared by NIC and GPU) before a design promises GPUDirect - a general-purpose rack server with GPUs fitted is not automatically capable of it.

A second validated-design constraint rides with GPU enablement: UEFI Secure Boot stays off on GPU workers - Cisco's RAG CVDs flag that the GPU Operator's driver fails to initialize under it - so the AI estate becomes an explicit, documented exception to the server-hardening baseline, one the security design must own up front rather than discover in deployment (AI security design and hosting models - air-gapped, private, public).

The RA programme compresses these node patterns into a C-G-N-B notation - CPUs, GPUs, NICs, and east-west bandwidth per GPU - so a node reads as a ratio: 2-8-9-400 is the 1:1 pole (eight E-W NICs, one per GPU, plus one N-S adapter, 400 GbE each), 2-8-5-200 halves it (four E-W NICs shared two GPUs each, 200 GbE per GPU), and 2-2-3-400 is the Grace-superchip pattern (two GPUs, an E-W NIC each). The Grace pattern's rationale is NVLink-C2C memory coherence: the GPU can oversubscribe into the Grace CPU's memory at high bandwidth, which is why the superchip pole fits memory-bound single-node work - LLM inference, RAG, recommenders, GNNs - rather than scale-out training. The notation makes the NIC:GPU ratio an explicit design variable instead of an accident of SKU. The software twin rides along: a Network-Operator-class companion to the GPU Operator provisions the NIC drivers, CNI plumbing, and IP address management inside Kubernetes, so the east-west lanes are as declaratively managed as the GPUs they feed.

Why it matters for design

The NIC, not just the GPU, determines whether GPUs stay fed: GPUDirect RDMA (RDMA, RoCE and RoCEv2) needs NIC support, DPUs provide tenant isolation and offloaded storage, and the NIC's line rate (400/800G) must match the GPU's bandwidth (Fabric transport - Ethernet vs InfiniBand vs UEC). Underpowered NICs/offloads strand GPU capital.

IPv6 / dual-stack note

NIC offloads (RoCE, overlay) operate on v4 and v6; validate offload paths for whichever family the fabric uses.

Related

• Scale-up vs scale-out
• RDMA, RoCE and RoCEv2
• Fabric transport - Ethernet vs InfiniBand vs UEC
• Sustainability - Green AI, power and cooling

Spaced repetition

Sources

• Cisco AI POD for Enterprise Training and Fine-Tuning Design Guide (Jan 2026) - E-W NIC-mode-for-GPU-performance motive (BIOS-level) alongside the N-S LACP case; full 94-page pass 2026-07-26 (user-supplied PDF).
• NVIDIA NCP Software Reference Guide, Workload Isolation (Mar-2026, fetched in full): the boot/attestation triad. NVIDIA ERA Overview, Key Building Blocks (May-2026, fetched in full): Grace C2C oversubscription rationale.
• NVIDIA, ERA Overview Introduction + AI Enterprise Software RA Software-Stack page (both fetched in full 2026-07-25) - C-G-N-B notation, NIC:GPU ratio patterns, Network Operator.
• Cisco/NetApp/SUSE, FlexPod with SUSE Rancher for AI design guide (Dec 2023) - SLE Micro immutable/transactional node OS; Technology Overview passed 2026-07-25.
• Cisco/NetApp, FlexPod Datacenter with Generative AI Inferencing (CVD, Feb 2024) - vGPU licensing plane (DLS/CLS), attach-by-model-size, full memory reservation for PCI/vGPU VMs, GPU-host BIOS/power exception; captured through OCP deployment 2026-07-25.
• Cisco/Intel, GenAI Inferencing on UCS X-Series with 5th Gen Xeon on Red Hat OpenShift AI (CVD, Mar 2024) - NUMA/pinning serving posture, second-source 7B/13B <100 ms confirmation (inputs to 2048, batch 1-8), SmoothQuant, virtualised~=bare-metal finding, single-node edge packaging; captured through the model-demo chapter 2026-07-25.
• Cisco, CDIP with Cloudera Data Platform Private Cloud for GenAI (CVD, May 2024) - three-tier independently-scaling archetype, SDX-class governance layer, role anchors; passed 2026-07-25.
• Cisco/Pure, FlashStack for AI: MLOps using Red Hat OpenShift AI CVD (Feb 2024) - vGPU static-memory/homogeneous-profile rules, SR-IOV VFs, MIG-backed vGPUs, MIG P2P penalty; captured through the Deployment overview 2026-07-25 (Validation chapter not captured).
• Cisco/Hitachi, Adaptive Solutions with Red Hat OCP AI Ready Infrastructure (Oct 2024) + Cisco/NetApp, FlexPod Datacenter with Red Hat OpenShift AI for MLOps (May 2025) - the virtualised-vs-bare-metal fork and its validated limits; design chapters passed 2026-07-25.
• Cisco, Compute Hyperconverged with Nutanix GPT-in-a-Box 2.0 CVD (May 2025) + GPT-in-a-Box 1.0 CVD (Jul 2024) - HCI archetype envelope, services tax, vGPU-only sharing; passed through the full Solution Design chapters 2026-07-25 (Sizing/Validation chapters not captured).
• Cisco, AI Inferencing on UCS X-Series for Intel OpenVINO Based RAG Deployments (CVD, Dec 2024) - runtime-as-multiplier on CPU serving; full prose pass 2026-07-25.
• Cisco, Generative AI Inferencing with UCS X-Series M7 / 5th Gen Xeon white paper (Mar 2024) - CPU serving envelope, AMX precision gate, WOQ, AutoTP; full-text pass 2026-07-25.
• Cisco, AI Inferencing with Intel AMX for Medical Image Analysis (CVD, Nov 2024) - NFD capability-labeled scheduling; partial pass 2026-07-25.
• Cisco, FlexPod for Accelerated RAG Pipeline with NVIDIA NIM and Cisco Webex CVD (Oct 2024) - Secure-Boot/GPU-Operator constraint; passed through the Solution Design chapter 2026-07-25.
• Cisco, Cisco AI PODs with FlexPod Datacenter solution overview (Feb 2026) - BlueField-3 NIC-mode/LACP requirement; fetched in full 2026-07-25.
• Cisco, Scaling FlexPod for GPU Intensive Applications CVD (Dec 2023) - GPUDirect PCIe-switch prerequisite (negative case); passed through the HPC-X setup section 2026-07-25 (SpecHPC test-result chapters not captured).
• Cisco, FlashStack for Enterprise RAG Pipeline with NVIDIA NIM CVD (May 2025) - X440p PCIe-node GPU decoupling; passed through the Solution Design chapter 2026-07-25.
• Cisco, Run:ai on Cisco UCS Converged Infrastructure white paper - quota/over-quota/guarantee scheduling, node pools, Dynamic MIG; full-text pass 2026-07-25.
• NVIDIA, AI Enterprise Software Reference Architecture (H200 NVL) - PCIe locality, per-GPU sizing anchors, E-W SuperNIC / N-S DPU split, scalable units; index + networking + compute pages passed 2026-07-25 (NCP RA tree not fetched).
• Nvidia GPU/BlueField (DPU) docs; Cisco AI/ML data-center blueprint.
• Cisco U. AI-Enabling Hardware (Intel GPU SR-IOV/vGPU) and Compute Resources (Intel Xeon AMX, CPU inference).

domain: AI-Infra · blueprint-ref: AI-Infra 4.1/4.2 Compute resources, AI-enabling hardware (GPU, SmartNIC, DPU) · type: concept · status: complete · tags: [elective/ai-infra, ai/hardware, tradeoff/cost]