AMD’s EPYC 7000-Series Processors

As announced back at the official launch, AMD is planning to hit both the dual socket and single socket markets. With up to 32 cores, 64 threads, 2TB/socket support and 128 PCIe lanes per CPU, they believe that by offering a range of core counts and frequencies, they have the nous to attack Intel, even if it comes at a slight IPC disadvantage.

AMD’s main focus will be on the 2P parts, where each CPU will use 64 PCIe lanes (using the Infinity Fabric protocol) to connect to each other, meaning that in a 2P system there will still be 128 PCIe 3.0 lanes to go around for add-in devices. There will be the top four SKUs available initially, and the other parts should be in the hands of OEMs by the end of July. All the CPUs will have access to all 64MB of the L3 cache, except the 7200-series which will have access to half.

The new processors from AMD are called the EPYC 7000 series, with names such as EPYC 7301 and EPYC 7551P. The naming of the CPUs is as follows:

EPYC 7551P

  • EPYC = Brand
  • = 7000 Series
  • 30/55 = Dual Digit Number indicative of stack positioning / performance (non-linear)
  • 1 = Generation
  • P = Single Socket, not present in Dual Socket

So in the future, we will see second generation ‘EPYC 7302’ processors, or if AMD scales out the design there may be EPYC 5000 processors with fewer silicon dies inside, or EPYC 3000 with a single die but for the EPYC platform socket (obviously, those last two are speculation).

But starting with the 2P processors:

AMD EPYC Processors (2P)
  Cores
Threads
Frequency (GHz) L3 DRAM PCIe TDP Price
Base All Max
EPYC 7601 32 / 64 2.20 2.70 3.2 64 MB 8-Ch
DDR4
2666
MT/s
8 x16
128
PCIe
180W $4200
EPYC 7551 32 / 64 2.00 2.55 3.0 180W >$3400
EPYC 7501 32 / 64 2.00 2.60 3.0 155W/170W $3400
EPYC 7451 24 / 48 2.30 2.90 3.2 180W >$2400
EPYC 7401 24 / 48 2.00 2.80 3.0 155W/170W $1850
EPYC 7351 16 / 32 2.40 2.9 155W/170W >$1100
EPYC 7301 16 / 32 2.20 2.7 155W/170W >$800
EPYC 7281 16 / 32 2.10 2.7 32 MB 155W/170W $650
EPYC 7251 8 / 16 2.10 2.9 120W $475

The top part is the EPYC 7601, which is the CPU we were provided for in this comparison. This is a 32-core part with simultaneous multithreading, a TDP of 180W and a tray price of $4200. As the halo part, it also gets the good choice on frequencies: 2.20 GHz base, 3.2 GHz at max turbo (up to 12 cores active) and 2.70 GHz when all cores are active.

Moving down the stack, AMD will offer 24, 16 and 8-core parts. These will disable 1, 2 and 3 cores per CCX respectively, as we saw with the consumer Ryzen processors, and is done in order to keep core-to-core latencies more predictable (as well as keeping access to all the L3 cache). What is interesting to note is that AMD will offer a 32-core part at 155W (when using DDR4-2400) for $3400, which is expected to be very competitive compared to Intel (and support 2.66x more DRAM per CPU). 

The 16-core EPYC 7281, while having half the L3, will be available for $650, making an interesting 2P option. Even the bottom processor at the stack, the 8-core EPYC 7251, will support the full 2TB of DRAM per socket as well as 128 PCIe lanes, making it a more memory focused SKU and having almost zero competition on these sorts of builds from Intel. For software that requires a lot of memory but pays license fees per core/socket, this is a nice part.

For single socket systems, AMD will offer the following three processors:

AMD EPYC Processors (1P)
  Cores
Threads
Frequency (GHz) L3 DRAM PCIe TDP Price
Base All Max
EPYC 7551P 32 / 64 2.0 2.6 3.0 64 MB 8-Ch
DDR4
2666
MT/s
8 x16
128
PCIe
180W $2100
EPYC 7401P 24 / 48 2.0 2.8 3.0 155W/170W $1075
EPYC 7351P 16 / 32 2.4 2.9 155W/170W $750

These processors mirror the specifications of the 2P counterparts, but have a P in the name and slightly different pricing.

AMD's EPYC Server CPU Introducing Skylake-SP
Comments Locked

219 Comments

View All Comments

  • JKflipflop98 - Wednesday, July 12, 2017 - link

    For years I thought you were just really committed to playing the "dumb AMD fanbot" schtick for laughs. It's infinitely more funny now that I know you've actually been *serious* this entire time.
  • ddriver - Wednesday, July 12, 2017 - link

    Whatever helps you feel better about yourself ;) I bet it is funny now, that AT have to carefully devise intel biased benches and lie in its reviews in hopes intel at least saves face. BTW I don't have a single amd CPU running ATM.
  • WinterCharm - Thursday, July 13, 2017 - link

    Uh, what are you smoking? this is a pretty even piece.
  • boozed - Tuesday, July 11, 2017 - link

    You haven't done your job properly unless you've annoyed the fanboys (and perhaps even fangirls) for both sides!
  • JohanAnandtech - Wednesday, July 12, 2017 - link

    Wise words. Indeed :-)
  • Ranger1065 - Wednesday, July 12, 2017 - link

    If you are referring to ddriver, I agree, wise words indeed.
  • ddriver - Wednesday, July 12, 2017 - link

    Well, that assumption rests on the presumption that the point of reviews is to upsed fanboys.

    I'd say that a "review done right" would include different workload scenarios, there is nothing wrong with having one that will show the benefits of intel's approach to doing server chips, but that should be properly denoted, and should be just one of several database tests and should be accompanied by gigabytes of databases which is what we use in real world scenarios.
  • CoachAub - Wednesday, July 12, 2017 - link

    It was mentioned more than once that this review was rushed to make a deadline and that the suite of benchmarks were not everything they wanted to run and without optimizations or even the usual tweaks an end-user would make to their system. So, keep that in mind as you argue over the tests and different scenarios, etc.
  • ddriver - Thursday, July 13, 2017 - link

    It doesn't take a lot of time to populate a larger database so that you can make a benchmark that involves an actual real world usage scenario. It wasn't the "rushing" that prompted the choice of database size...
  • mpbello - Friday, July 14, 2017 - link

    If you are rushing, you reduce scope and deliver fewer pieces with high quality instead of insisting on delivering a full set of benchmarks that you are not sure about its quality.
    The article came to a very strong conclusion: Intel is better for database scenarios. Whatever you do, whether you are rushing or not, you cannot state something like that if the benchmarks supporting your conclusion are not well designed.
    So I agree that the design of the DB benchmark was incredibly weak to sustain such an important conclusion that Intel is the best choice for DB applications.

Log in

Don't have an account? Sign up now