Some maybe-interesting observations about my experiences over the last few years, as someone who uses both cloud-provisioned (GCP N2D) and dedicated-server (e.g. OVH HGR-HCI-class) AMD EPYC-based machines at $work.

• GCP N2D instances always had a strict per-AZ allocation quota. This allocation quota has not increased over time. And when we asked to have it bumped up, it was the only time a quota-increase request of ours has ever been denied.

• When OVH was offering their HGR-HCI-6 machine type (2x EPYC 7532), we provisioned a few of them. The first few, leased ~2 years back, each took a few days to provision — presumably, OVH doesn't buy these expensive CPUs until a customer asks for a machine to be stood up with one in them. More recently, though (~6mo ago), for the same machine type, they gave us a provisioning lead time of more than a month, due to supply difficulties for the CPU.

• These chips were buggy! Again on OVH, when allocating these HGR-HCI-6 machines, we were allocated two separate machines that ended up having CPU faults. (Symptoms: random reboots after an hour or two of heavily utilizing the native AES-NI instructions; and spurious "PCI-e link training errors" in talking to the network card and/or NVMe drives.) They were replaced quickly, but I've never seen this kind of CPU fault on a hardware-managed system before or since.

• Just a month ago, the high-end dedicated-server hosters (OVH, but also Hetzner and so forth) seem to have removed all their SKUs that use 2nd- and 3rd-gen EPYC 7xxx CPUs. (Except for one baseline SKU on OVH, which is probably there because they have a big pile of them.) Everything suddenly switched over to 4th-gen 9xxx EPYCs just a month or two ago. It might just be that availability of these 9xxx EPYCs is finally reaching levels where these providers think they can meet demand with them — but everyone switching over simultaneously, and dropping their old SKUs at the same time?

• GCP recently launched the storage-optimized Z3 instance type. They chose to build this instance type on an Intel platform (Sapphire Rapids.) That's even though AMD EPYCs have had enough PCIe lanes to deliver equivalent performance to this Z3 platform — ignoring the "Titanium offload" part, which isn't CPU-platform-specific — for years. (In fact, the need for a huge pool of fast NVMe is in part why we switched some of our base load from GCP over to those OVH HGR-HCI-6 instances — which satisfied our needs quite well.) GCP could in theory have launched something akin to this instance type, with the same 36TiB storage pool size (but PCIe 4.0 speeds rather than 5.0) three years ago, using EPYC 7xxxs. Cusomers have been asking for something like that for years now — wondering why GCP instances are all limited to 8.8TiB of local NVMe. (We actually asked them ourselves, back then, where "the instance type with more local NVMe" was. They gave a very handwave-y response, which in retrospect, may have been a "we're trying, but it's not looking good for delivering this at scale right now" response.)

These points all lead me to believe that something weird happened with the EPYC 7xxx rollout. Supply didn't grow to meet demand over time.

And then, suddenly, after the seeming EOL of these chips — but long before cloud providers would normally cycle them out — we're seeing 7xxxs ending up on the open market, in enough bulk to make them affordable? Bizarre.

---

My own vague hypothesis at this point, is that at some point during the generation, AMD discovered a fatal flaw in the silicon of the entire EPYC 7xxx platform. Maybe it was the hardware crypto instructions, like I saw. Or maybe it was some capability more specific to cloud-computing customers (SEV-SNP?) that turned out to not work right (which would make more sense given that Threadrippers didn't see the same problems.) So the big cloud customers immediately halted their purchase orders (keeping only what they had already installed so as to not disturb existing customer workloads); and AMD responded by scaling down production.

This resulted in two things: a supply shock of AMD EPYC-based machines/VMs that lasted for a while; but also, negotiated settlements with the cloud vendors, where AMD was now obligated to fulfill existing POs for 7xxx parts with 9xxxs, as they ramped up production of those. Which is why 9xxxs have taken so long (2 years!) to make it onto the open market: the lines have been dedicated to fulfilling not just 9xxx bulk purchase-orders, but also 7xxx purchase-orders.

(And which is why the switchover to 9xxx among smaller players is so immediate: such a switchover has been on every hosting company's roadmap for a long time now, having been repeatedly delayed by supply issues due to the huge volume of 9xxx parts required to satisfy the clouds' backlogged demand. They've had a stock of 9xxx-compatible motherboards + memory + PSUs + chassis just sitting there for months/years now, waiting for 9xxx CPUs to slot into them.)

Perhaps we're seeing these cloud-customer 7Cxx parts on the open market now, because the clouds have finally received enough 9xxxs to satisfy their actual demand for 9xxxs, and their backlogged demand for 7xxxs; and the clouds are now finally at the point where they can replace their initial actual (faulty / feature-disabled) 7xxx parts they were sent with 9xxxs, selling off the 7xxx parts.

My guess is that, now that they have "fixed" AMD chips in place, we'll soon see the cloud providers heavily hyping up some particular AMD-silicon-enabled feature that they had been starting to market four years ago, but then went radio-silent on. ("Confidential computing", maybe.)

---

I'd love to hear what someone with more insider knowledge thinks is happening here.