AMD 的 Mike Clark 深度解读 Zen 6 与 Zen 6c 架构演进

各位互联网朋友，你们好，

我与 AMD 的 Mike Clark 坐下来聊了聊 Zen 6、从 Zen 5 的演进，以及 Zen 6 与 Zen 6c 之间的一些差异，还有是什么推动了这些变化。

希望大家喜欢！

以下文字记录为便于阅读和简洁而经过编辑。

George Cozma： 各位互联网朋友，你们好。我们正在 AMD In-Depth 节目中，讨论 Venice。和我一起的是再次做客的 Mike Clark。你愿意向观众介绍一下你是谁吗？

Mike Clark： 嗨，我是 Mike Clark，Zen 的初代架构师。有些人称我为“Zen 之父”。我在 AMD 从事核心工作已经 33 年了，我们又将推出一款出色的产品，所以我为我今天能代表的设计团队感到非常自豪。

George Cozma： 我曾亲手体验过 Zen 6c。我们来谈谈 Zen 6 和 Zen 6c 发生的变化，我在文章里称之为 Zen 6 家族。为什么它和之前几代不同？

Mike Clark： 对。从 Zen 4 开始，我们就一直在经历拥有两个核心家族的演进过程。以前，我们真的只是把更密集的技术当作面积上的手段。在这一代，我们学到了很多，在充实核心的更密集版本时，我们想利用它来在核心内增加一些额外的 IPC。所以如果你更深入地看我们所拥有的东西，我们过去经典的设计，现在我们认为它是我们的高频设计。而我们的密集技术现在是我们顶级的、毫无疑问的性能核心，因为我们还在那个实现中启用了完整的 L3，每核心 4MB。所以我们有 32 个这样的核心，128MB 的 L3，以及该核心中你能获得的最高 IPC。

George Cozma： 太棒了。到目前为止，我注意到的一点是 Zen 6c 上的向量调度器稍微大了一些。在 Zen 6c 上增加它的理由是什么？

Mike Clark： 嗯，那不是我们唯一增加的东西。我们遵循的一个原则是，我们不想在两种架构之间制造出软件必须针对其进行优化的差异。我们希望它们具有相同的适配和感觉，这样相同的优化就能适用于两者。但由于其频率目标降低，Zen 6c 可以在队列中拥有稍多一些的容量，因为它不必达到高频核心必须达到的最高频率。浮点调度器只是一个例子。Zen 6c 中整个核心还有其他更大的队列，以榨取一点额外的 IPC，并在 SMT 环境中也获得一点额外的优势。

George Cozma： 有意思。Zen 6 和 Zen 6c 都建立在你在 Zen 5 中的设计之上，而 Zen 5 有趣的一点是双解码设置。前端是否发生了很大变化，以便让单个线程更好地利用两个解码集群？

Mike Clark：是的。正如你所说，Zen 5 是一个新的基础，能够取两个基本块并将它们送入后续流水线。但当单线程运行较大占用空间的工作负载时，情况会变得相当复杂——其中一部分可能命中指令缓存，另一部分可能命中操作缓存，而你需要让所有内容保持同步。因此我们花了大量时间优化这一点，从交付和功耗两个角度提升效率：减少功耗浪费，并让新前端更高效地交付。

George Cozma：太棒了。深入到执行引擎部分，我还注意到整数乘法单元的数量从三个减少到了两个。你能谈谈是什么驱动了这一选择吗？

Mike Clark：这实际上源于 Zen 5 的设计，当时我们采用了更统一的调度器。为了让调度器更简单，你希望它调度到的单元非常统一，而在我们设置这些调度器的方式下，向其所调度的组中添加第三个乘法器很容易，且不会增加复杂性。在 Zen 6 中，我们意识到要真正扩展架构，需要回到更分布式的调度器，现在它们直接调度到 ALU。我们在 Zen 5 上并未看到那个额外乘法器带来多少提升，因此为了优化面积和调度器，我们回到了两个乘法器。

George Cozma：说到整数乘法，在向量方面你们又增加了两个 VNNI 单元。增加它们的动力是什么，又是在设计的哪个阶段加入的？

Mike Clark：正如我在演讲中所说，这些是长周期的设计项目。我们设计 Zen 6 时并不是要把它做成一个智能体核心。当我们开始时，甚至没人真正使用那个术语。但 Zen 5 是面向 AI 工作负载的全新基础，我们一直相信核心在 AI 中有其一席之地：编排、数据类型操作、较小模型。因此我们始终专注于让核心擅长 AI。它不会击败 GPU，这不是重点。考虑到我们看到的推理发展趋势，我们意识到可能应该增加一些 VNNI，团队也围绕这一点团结起来。这有点晚，因为这些都是长周期项目且平面图已经确定，但团队齐心协力，我们成功挤进了几条额外的 VNNI 流水线，取得了巨大成功。

George Cozma：再次回到向量方面，Zen 5 的一个奇怪之处在于，尽管线路都已具备，加载单元一次只能执行两个向量加载。Zen 6 核心内部发生了什么变化，使其能够支持四个向量加载（假设它们是 128 位或 256 位）？

Mike Clark：我们可以做 256 位加载。既然我们能够做两个 512 位加载，我们就已经有 1,024 根线通到那里。显然，零散使用它们与作为一个连续集合使用会使设计复杂化。我认为这是我们在 Zen 5 上一直想做的事情，但伴随着所有变更并让它正常工作，我们把这件事留给了 Zen 6 团队，他们非常出色。无论如何，在 AMD 我们实际上是一个团队，有时事情会在路线图的不同节点交汇。这次正是做这件事的时机。

George Cozma：说到缓存带宽，Zen 5 的 L2 有一些奇怪之处，读取时并不总能达到每周期 64 字节。Zen 6 改了什么才实现这一点？因为我实测过，它确实能达到。

Mike Clark：说实话，有些问题你平时就是注意不到。很大一部分原因是我们会过度预取，而命中 L2 的预取会抢占 L2 带宽。所以我们确保预取能与需求请求并行维持，减少冲突，并交付我们想要的完整每周期 64 字节。

George Cozma：太棒了。绕回前端：最重要的分支预测器。分支预测错误延迟似乎有所降低，也就是说当分支预测失败时，恢复所需的周期数减少了。我还注意到一点非常妙，就是准确率并没有下降。那么你是如何做到不仅分支预测器更快，而且比 Zen 5 本已非常准确的预测器还略更准确？

Mike Clark：如你所知，分支预测团队非常算法化。设计空间很大，探索也很多，甚至 AI 也参与进来帮我们找出优化方法。这是一个很棒的优化问题：TAGE 表的数量、它们容纳多少信息、准确率。所以我们着手做一个更高效的版本。这是我们不太想扩大规模的领域；我们认为可以在预测表的布局方式上更高效。而且我们始终关注流水线长度。无论分支预测器做得多好，总会有难以预测的分支，你总会预测错误。所以每一代，我们都执拗地专注于在预测错误时尽快恢复。我们用了很多独特的技巧，把重定向送回前端并让它尽可能快地流动起来。而你观察到了这一点，这很好。

George Cozma：是的。我还没时间测 Zen 6，但我测过 Zen 6c，在 SPECint 2026 中它与你最快的 Zen 5 服务器 CPU 相当。这非常令人印象深刻，尤其考虑到频率上的劣势。总结一下并走出核心来到 L3，12 核和 32 核 CCD 之间显然存在拓扑差异。你在核心内部能在多大程度上缓解这些差异，构建结构来容忍延迟，以补偿略微增加的 L3 延迟？

Mike Clark：正如我一直说的，设计必须平衡。当我们增大某个结构的容量时，新技术帮助它缩小，所以物理距离不会线性增长，但不幸的是距离确实会增长。在 L3 内部，有很多技巧我不能透露……

George Cozma：秘密配方！

Mike Clark：[为了]维持 L3 网状网络内的带宽，以便我们能持续向核心交付。而在核心内部，我们确实增大了队列来处理这些更高的延迟。

George Cozma：太棒了。我倒数第二个问题：Verano 正在将 LPDDR5X 加入 EPYC 生态系统。在设计核心时，LPDDR5X 和 DDR5 之间有没有什么设计考量是你必须考虑的？

Mike Clark：在 CCX 层面，我们非常关注每核心带宽。我想 Mahesh 谈了很多关于 SDP 端口的内容，每个端口 32 字节读取，所以我们努力确保 CCD 和 IOD 之间有足够的带宽。但我们在 MRDIMM 上已经为带宽做好了充分准备，所以那种构造、winglets 以及选择不同的内存技术，并没有真正对我们构建核心的方式产生重大影响。

George Cozma：太棒了。通常这时候我会问你最喜欢哪种奶酪，但既然我们已经知道了：你最近尝试过什么新奶酪吗？

Mike Clark：试过。我现在的新宠是 Cotija 奶酪。

George Cozma：哦！

Mike Clark：我最近吃了很多墨西哥卷饼。

George Cozma：你一定会爱上墨西哥卷饼上的 Cotija。那绝对美味。好了，非常感谢你接受我的采访。如果你喜欢这样的视频，请点赞并订阅；这对算法有帮助。描述里有 PayPal 和 Patreon 链接，以及 Chips and Cheese 网站上的文字记录。非常感谢。

Mike Clark：谢谢你邀请我，George。我一直很期待来和你聊聊这个出色的 AMD CPU 设计团队创造了什么，而你总是有那么多好问题。我希望我能回答更多，因为我们确实必须保护我们的秘方，但我真的很喜欢帮助你理解我们的一些思路、我们面临的挑战，以及我们如何克服它们。

George Cozma：嗯，和你坐下来聊聊总是很有趣，不仅是聊你在做什么，还有团队在做什么，以及你对未来的期待。所以非常感谢。

Mike Clark：谢谢。

George Cozma：我们下期见。大家保重！