[toast0]

As I recall, from the Zen 4c articles, the big concessions are slower L1/L2, which allows fewer transistors per byte and so smaller area; lower clock targets, which allows less buffering to make the clock domains work and so smaller area. The L3 is about the same as a Zen 4 chiplet, which means half the size per core. They also dropped support for v-cache, which saves a little bit of area too.

Prior to Zen4c, server and desktop chiplets were the same, and desktop chips need to clock to the moon for competitive reasons, but server chips aren't going to go to really high clocks anyway; the thermals are too challenging, so if there's enough demand to justify a separate spin for servers, it makes a lot of sense to tweak the design for reasonable clock rates that will be seen there.

[touisteur]

I have had great success with the 'low-core / high-frequency' line-up in every step of the Zen+EPYC architectures.

They always have these (thanks to CCX and chiplets) SKUs and for latency-sensitive applications (or single-core non-parrallelized workloads), the high-frequency ones are amazing. You don't get the actual frequency/perf ratio, but they're relatively cheap (compared to the Intel SKUs with similar cores/freq) and damned reliable.

[redroyal]

Frequency optimized parts were created to sidestep software licensing based on core count. Often w/ higher cache. Like Milan-X