In this article
MI300A combines CPU and GPU in an APU platform with 128 GB shared HBM3. The shared budget is not dedicated GPU VRAM plus a separate 128 GB CPU pool.
Identify an APU, not a removable graphics card
AMD’s CDNA 3 white paper distinguishes MI300A from MI300X. MI300A integrates CPU and GPU resources with 128 GB unified HBM3; MI300X is a GPU accelerator with a different dedicated-memory specification. The shared MI300A capacity must not be counted twice in a server inventory. CPU allocations and GPU work use the same physical budget. Its platform mechanics, firmware and cooling are part of the product, so it should not be described as a generic PCIe graphics card that can be installed in any workstation.
| Variant | Local memory, GB | Memory type | Published board power, W |
|---|---|---|---|
| MI300A APU | 128 | HBM3 shared CPU/GPU | Not verified |
The product or OEM specification establishes the configuration: manufacturer source.
Check the exact ROCm and framework combination
The ROCm hardware reference identifies MI300A in the CDNA 3 gfx942 family, but architecture identity alone is not an engine certificate. Use the compatibility matrix for the selected operating system, driver and runtime, then check the framework’s MI300A deployment route. Do not substitute an MI300X example without reviewing platform assumptions. Validate the selected model and precision for correctness, including memory placement and any required data movement. A device appearing in inventory does not prove a particular attention or quantization implementation.
The software boundary is documented in the inference compatibility reference.
Account for competing CPU and GPU allocations
Unified memory can change data movement, but it does not remove capacity accounting. The operating environment, CPU-side preprocessing, model weights, runtime workspaces and caches need room within the same physical budget. Measure the process working set and allocator behaviour under real request lengths. Avoid adding host-visible and GPU-visible reports as if they were disjoint pools. A useful comparison explains where tensors reside and how concurrent CPU work affects headroom. Shared addressing is not itself proof of zero copies or a measured speedup for every framework.
Separate CDNA compute from Cycles HIP graphics
MI300A is a CDNA compute platform. The current Blender Cycles HIP documentation uses RDNA 1 or later as its AMD hardware-generation baseline; a CDNA device is not made eligible simply because ROCm can execute compute kernels on it. This guide therefore does not recommend MI300A as a documented current Cycles HIP render node. A different renderer or custom compute renderer would need its own explicit support evidence and test. LLM acceptance cannot be reused as proof of materials, ray tracing or image output.
Renderer requirements are separate in the Cycles GPU manual.
Report the whole platform boundary
For an installed MI300A system, retain OEM identity, CPU/GPU topology, memory placement policy, firmware and cooling configuration. Compare service latency and failure recovery under simultaneous CPU and GPU demand rather than only an isolated kernel. Keep the shared-memory interpretation in every exported result so it is not later transformed into a dedicated-VRAM claim. The profile describes a public architecture and an evaluation method. It does not announce that Retrivium operates MI300A, supplies a particular checkpoint or has completed a marketplace integration for this platform.
Related reading: RAM and VRAM and a reproducible inference benchmark. GPU catalogue records the scope, model variants and unresolved specifications.
Additional primary references: 1.