AMD Advancing AI 2026

The roadmap became a shipping rack

AMD held its third annual Advancing AI event July 22–23 at Moscone Center in San Francisco — 2023 introduced Instinct MI300, 2024 was MI325X, 2025 previewed the MI350 series and the "Helios" rack-scale concept. This year, the thing 2025 previewed actually shipped. CEO Lisa Su's keynote was less "here's where we're headed" and more "here's the invoice" — hardware in production, a software push aimed squarely at ROCm's reputation, and a TAM number big enough to make headlines on its own.

The rack-scale story isn't actually the part I'm tracking closest, though. What I keep coming back to is the layer underneath it: the inference-hosting platforms actually serving these models day to day — Fireworks.ai's own optimized inference stack, Featherless.ai's flat-rate access to the open-weight catalog instead of per-token billing — and the enthusiast/prosumer hardware ecosystem that makes hosting something yourself realistic in the first place: boards like ASRock's high-lane-count AM5 and Threadripper (sTR5) lineup, and RDNA 4's move to PCIe 5.0, which roughly doubles PCIe 4.0's per-slot bandwidth to about 64GB/s aggregate over an x16 link. Chiplet design keeps compounding that story specifically on the cache side: stacking a second die of pure SRAM on top of a compute chiplet lets far more of a workload's working set stay on-package instead of round-tripping to system memory on every cache miss, which is the actual mechanism behind the "3D V-Cache" gains AMD advertises — more L3 sitting physically closer to the cores, not more RAM. Robotics and local AI generally are where this event's messaging lands hardest for me, more on both further down.

That local-first instinct is also why I still lean on Replit's small-dev-node-before-prod-deployment model as the right default shape for this kind of work: build and iterate against a small, cheap environment, then explicitly deploy to a separate, purpose-sized production target instead of promoting the dev box in place — see Replit's own writeups on Deployments and Storage. The home lab is the dev node in that model; Helios-class hardware is what the deployment step looks like at a scale I'm not operating at. This is the companion piece to the Hardware Landscape and Kernel Landscape sections on the AI Systems channel page — the R9700 and Strix Halo already sitting in my home lab are exactly the products this event's messaging is aimed at.

The gap this actually opens up between AMD and Intel, and between their datacenter and consumer lines, is worth putting in one table rather than describing in prose:

The L3 row is the one worth staring at: AMD's datacenter and Intel's datacenter chip land within 2% of each other at roughly half a gigabyte of shared cache, while neither company's current flagship EPYC or Xeon actually ships 3D-stacked cache — that's still a consumer-tier Ryzen X3D feature today. AMD has said 3D V-Cache is coming to EPYC with the next "Venice" generation (reportedly north of 1GB of L3), which would be the first time the stacking trick that makes a $700 desktop chip punch above its weight shows up on a server part at all.

ROCm.AI: trying to close the software gap

The software announcement is ROCm.AI, a new unified developer-experience layer rather than a numbered ROCm version bump: a ROCm CLI for install/validate/serve/manage, "AMD Skills" (AMD-authored expertise plugged directly into Claude, Cursor, and Codex), and Hyperloom, an open-source agentic inference-optimization tool. AMD's claimed gains are 3.3x inference and 2.4x training improvement, with general availability slated for August 2026. This is the piece that actually matters against the Kernel Landscape section's ROCm bullet on the channel page — the R9700's conflicting version-support guides and the "confusing ROCm support for gfx1151" GitHub issue on Strix Halo are exactly the kind of fragmentation a unified CLI and packaged "skills" layer are pitched as fixing. Whether ROCm.AI actually reaches workstation-tier gfx1151/gfx1201 the way it's aimed at datacenter-tier Instinct, or whether it's a datacenter-first rollout that trickles down later the way ROCm version support historically has, isn't something this event's keynote settled — it's a real open question, not a resolved one.

Hyperloom is worth a closer look on its own, since it's the part of ROCm.AI actually aimed at closing a performance gap rather than a version-management one. It's an agentic pipeline, not a single tool: workload inference feeds a profiling stage (Intellikit for low-level GPU profiling, Magpie for trace collection, TraceLens for trace analysis, then gap analysis and bridge planning), which hands off to a kernel-optimization stage — Arbor, a self-evolving optimization search running a Think → Decide → Implement → Benchmark agent loop backed by a dynamic specialist agent and knowledge base, with Claude Code, OpenAI Codex, and other model APIs doing the actual kernel-optimization work as pluggable agents. The output isn't a report, it's a pull request with the optimized code already written.

What actually trickles down to a home lab

The consumer/workstation crossover announcement was the Ryzen AI Max PRO 400 series ("Gorgon Halo"), flagship Max+ PRO 495: 16 Zen 5 cores, a Radeon 8065S iGPU (40 CUs), an XDNA2 NPU rated around 55 TOPS, and up to 192GB of unified LPDDR5x with up to 160GB addressable by the GPU — plus a "Ryzen AI Halo" developer platform pitched as a local agentic-AI workstation capable of running models up to roughly 200B parameters. This is a different chip from the Ryzen AI Max+ 395 already covered in the Hardware Landscape section — a newer, higher-spec sibling, not a rename — and AMD's messaging tied it explicitly to the same ROCm.AI stack as Instinct and Helios: "one stack, top to bottom." Given that the existing Max+ 395 in that section already has genuinely unsettled ROCm support per AMD's own documentation, that claim is worth watching rather than taking at face value the moment Gorgon Halo hardware actually ships to reviewers.

Local AI and robotics

Two announcements from this event push in the opposite direction from Helios's rack-scale story — toward the desk and the factory floor instead of the data center. AMD and Cisco announced a client partnership pairing Ryzen AI Halo client systems with Cisco's enterprise networking, observability, and security stack — bringing AI compute out to individual desks and devices without IT losing centralized visibility or control. (More detail on that one in the DevSecOps channel.)

Separately, AMD announced the Kria™ AI Robotics Developer Platform, pairing a Kria AI SOM with an UltraScale+ FPGA carrier board for deterministic real-time control (AMD claims 8,000+ control decisions/sec) alongside sub-100ms vision-language-action (VLA) reasoning — aimed at factory robots, AMRs, mobile manipulators, and humanoids. Worth calling out specifically: the carrier board includes an OCuLink PCIe Gen5 connector for I/O expansion, per AMD's own announcement — the same external-GPU-class connector that shows up in home-lab eGPU builds, here repurposed for expanding a robotics controller board rather than a desktop. It's sampling with early-access customers now, with general availability targeted for Q4 2026.

AMD wasn't just talking about robotics on a slide, either — Generative Bionics had a full humanoid on the show floor, rigged up on a support gantry so it could move safely at the booth.

On the developer-ecosystem side, AMD also pointed to its ROCm Certified Developer Program — a free credential, run through the AMD AI Academy, validating skills building and deploying AI workloads on ROCm — and the AMD University Program's AI & HPC Cluster, which awards faculty and researchers node-hour allocations on AMD compute for open-source AI/HPC research and educational work. Both are the kind of unglamorous ecosystem investment that actually determines whether "one stack, top to bottom" becomes real developer muscle memory or stays a keynote slide.

And back in the home lab specifically: the 32GB AMD Radeon AI PRO R9700 already sitting on my bench (RDNA 4 "Navi 48," 64 CUs, 640GB/s of GDDR6 bandwidth, 300W, PCIe 5.0 x16) is worth a direct callout for anyone sizing a local training box. One nuance worth being precise about: this is not hardware-level ECC the way AMD's own W7900 workstation card has it — R9700's error correction is software/driver-managed, and Linux-only. For training small custom models locally, that's still a meaningfully more honest memory story than a card with no error correction at all, but it's a driver-stack feature to verify yourself before relying on it, not a hardware guarantee baked into the silicon.

Why this matters

Strip away the keynote framing and three things actually happened: a real rack-scale product shipped on schedule instead of slipping again, AMD put a name and a release date on the software effort meant to close the ROCm/CUDA gap, and the company's own market-size claims got dramatically larger. None of that resolves the fragmentation already documented elsewhere on this site — the R9700's conflicting ROCm version guides, the open GitHub issue on Strix Halo's support tier — but the dated commitment is no longer hypothetical: AMD shipped ROCm 10 on August 31, 2026, right on the schedule it announced at the keynote, making ROCm.AI (the CLI, AMD Skills, and Hyperloom) generally available. ROCm is now also moving to a six-week release cadence going forward, so "GA" is less a single finish line than the start of a much faster iteration loop.

The part worth putting real weight on is how much of that software push has actually landed inside the two inference engines that matter most right now, vLLM and SGLang, rather than staying AMD's own tooling. ROCm is described as first-class support in vLLM today, including distributed inference through AMD's own MoRI framework, and AMD is running its roadmap for both engines in the open — see AMD's Q2 and Q3 2026 vLLM roadmap issues (closing the decode-parity gap against SGLang at high concurrency on MoE/MLA architectures, finishing the V1 engine migration on ROCm, a day-0 enablement template for new model drops), and the equivalent SGLang roadmap issue (MXFP4 attention kernels, context-parallelism work on ROCm). AMD also ran a dedicated "vLLM in 2026: Challenges and Optimizations" session at the event itself — this wasn't background GitHub activity, it was an explicit conference topic. That's a more convincing signal than a keynote slide: public, dated, adversarially-checkable commitments filed in the same repos the rest of the inference-serving world already lives in.

Then vs. now: a 2017 supercomputer vs. a home lab

One way to close this out: before UC San Diego's own San Diego Supercomputer Center doubled the GPU partition on its NSF-funded Comet system in July 2017, the original configuration was 144 NVIDIA K80 GPUs (36 nodes × 4 K80 boards each) sitting on top of nearly 2,000 Xeon "Haswell" CPU nodes — a machine real enough to place in the TOP500. Today, four AMD Radeon AI PRO R9700 cards fit in one workstation, wired up over OCuLink through a single bifurcated PCIe x16 slot split x4/x4/x4/x4 — no rack, no dedicated machine room. Comparing the two on matching precision, not marketing-slide precision, is the actual point — and it's worth walking the whole precision ladder, not just FP32, because two of the rows below didn't exist as accelerated hardware paths in 2017 at all.

Comet's original, pre-upgrade K80-only GPU partition (the fair comparison point for a GPU-vs-GPU table, not the CPU-only nodes or the P100s added later) vs. four R9700s. Every row uses matching precision on both sides. SDSC/TOP500 stated this partition's peak as 419 teraflops, which lines up almost exactly with 144 K80 boards × NVIDIA's published 2.91 TFLOPS FP64 boost-clock rate per board (419.04 TFLOPS) — strong evidence that figure is FP64, the standard HPC metric, not FP32. FP32 below is derived from that same figure using the K80's fixed 3:1 FP32:FP64 ratio, not independently re-verified from SDSC. K80 memory bandwidth (480GB/s aggregate, 240GB/s per die) is from NVIDIA's own board spec via Microway's K80 writeup; the $5,000/board launch price behind the build-cost row is from The Next Platform (other sources cite a $6,999 list price for a related SKU; $5,000 is the more specifically-sourced figure, and either way it's what a buyer would have paid at retail, not SDSC's actual bulk/NSF-negotiated cost). One more caveat: AMD's official R9700 MSRP is $1,299, not $1,400 — street price has ranged $1,024–$1,722 through 2026, so $1,400/card is a reasonable mid-range estimate, not the list price. And the AOOSTAR AG01 is a single-GPU OCuLink dock with its own built-in PSU, priced $149–$199 depending on the revision, so enclosing all four R9700s takes four of them, not one.

Metric	UCSD/SDSC Comet GPU partition, pre-upgrade (2017)	Quad AMD Radeon AI PRO R9700 (today)
GPU count	144 (36 nodes × 4 NVIDIA K80 boards)	4 (256 total RDNA4 compute units)
Peak FP64	~419 TFLOPS aggregate (SDSC/TOP500's own stated figure)	~6 TFLOPS aggregate (RDNA4 runs FP64 at a small fraction of FP32 — this class of card isn't built for it)
Peak FP32	~1,259 TFLOPS aggregate (derived: K80's fixed 3:1 FP32:FP64 ratio)	~191 TFLOPS aggregate
Peak FP16 (vector)	N/A — no accelerated FP16 path on Kepler	~383 TFLOPS aggregate
Peak BF16 (matrix)	N/A — Tensor Cores didn't exist until Volta (2017); BF16 specifically arrived with Ampere (2020)	~765 TFLOPS dense / ~1,531 TFLOPS with structured sparsity
Peak INT4 (matrix)	N/A — INT8/INT4 tensor acceleration arrived with Turing (2018)	~3,064 TOPS dense / ~6,124 TOPS with structured sparsity
GPU memory	~3.5TB aggregate (24GB × 144 boards)	128GB GDDR6 aggregate (32GB × 4)
Memory bandwidth (single board/card)	~480GB/s per K80 board (2× GK210 dies, each ~240GB/s on its own 12GB GDDR5 pool)	640GB/s per R9700 (32GB GDDR6, single unified pool)
PCIe link (per GPU)	PCIe 3.0 x16 — ~15.75GB/s per direction (~31.5GB/s duplex)	PCIe 4.0 x4 in this actual bifurcated build — the bifurcation card itself is Gen3/Gen4-rated (see the photo below), capping each card at ~7.88GB/s per direction (~15.75GB/s duplex), about half of Comet's per-GPU host link, not the same. The R9700 itself is rated for full PCIe 5.0 x16 (~63GB/s) when given a whole slot — x4 at Gen4 is what this specific bifurcated setup gives up, not a card limitation. In practice that's still enough for decoupled training and serving of large models with tensor parallelism across the four cards, since the host link isn't the bottleneck for that workload shape the way it would be for, say, constant full-dataset streaming.
GPU board power	~43.2kW (300W × 144 boards; GPU boards only, excludes hosts/cooling/networking)	~1.2kW (300W × 4)
Physical footprint	36 GPU-accelerated nodes, within Comet's larger 27-rack system	One workstation, one PCIe slot, one bifurcation card
Approximate build cost	~$720,000 to buy new at commercial list price (144 × NVIDIA Tesla K80 boards at roughly $5,000/board launch MSRP) — not what SDSC actually paid, which would have been a bulk/NSF-negotiated price well under retail	~$9,420 ($3,000 desktop base — Core Ultra 9 285K, 96GB RAM — + $60 OCuLink bifurcation card + 4× R9700 at $1,400 each + 4× $190 AOOSTAR AG01 eGPU docks)

The BF16 and INT4 rows are the ones that actually explain why this comparison is lopsided in a way FP32 alone doesn't capture. BF16 is arguably the single format that made modern ML training practical: it keeps FP32's full 8-bit exponent range (so training doesn't overflow or underflow the way plain FP16 can), while cutting the format to half the size and memory bandwidth — which is exactly why virtually every large model trained today runs in BF16 in place of FP32, not as a lossy shortcut but as the default. YOLO-family computer-vision models are a good concrete example of where the industry actually sits: FP32 is still the default data type, but modern training pipelines routinely switch to mixed precision (FP16 or BF16) for faster throughput and lower memory use. FP64 doesn't enter the picture anywhere in that stack — it's simply too slow and unnecessary for neural network training or inference, which is a separate reason from "the hardware can't do it" that applies even to GPUs that can. Comet's K80s, for their part, can't run a single BF16 operation in accelerated hardware at any speed, because the tensor-core-style matrix units BF16 depends on didn't exist yet — Volta introduced Tensor Cores in 2017, the same year as this upgrade, and BF16 support specifically didn't arrive until Ampere in 2020. INT4 is the same story one step further: dedicated low-precision tensor paths arrived with Turing in 2018. The honest reading, not the flattering one: Comet's original partition still wins decisively on FP64 and total memory — it was built for classical HPC simulation workloads that actually need double precision and a lot of it, a requirement neural networks never really had in the first place. What changed is everything to the right of FP32: an entire tier of precision that today's training and inference actually runs on simply hadn't been invented in accelerated form when this machine was current.

The bar chart above is honest about scale, but it hides something a line chart shows immediately: if you treat "N/A" as zero — not because the number was small, but because the hardware to run it didn't exist — Comet's line collapses to the floor right as the quad-R9700's line is still climbing, and the two actually cross.

That's the actual headline, not a rounding trick: four consumer cards, running BF16, land at 765 TFLOPS — not equal to Comet's 1,259 TFLOPS FP32 peak, but the same order of magnitude, on a format that didn't exist in accelerated hardware anywhere in 2017. By INT4, the quad-R9700 setup has passed it entirely. I want to be clear about what I take from that, because it's easy to read a post like this as only being about catching AMD's marketing in a stretch: the actual story is how much genuine engineering it took to get here, and it's worth celebrating on its own terms, not just fact-checking. This is still early. If four cards in a home lab are already in reach of an NSF-supercomputer's peak from eight years ago, the honest expectation is that this gap keeps closing over the next decade, not that it holds steady. The part that actually matters is making sure we learn to use tools at this scale correctly as that keeps happening, not just accumulate more TFLOPS for their own sake.

Placeholder — content pending

Now that ROCm.AI has actually shipped (ROCm 10, August 31, 2026), a follow-up checking its claims — and the vLLM/SGLang roadmap items above — directly against the R9700 and Strix Halo hardware already in the home lab is a natural next post — not written yet.