GCC 17 加入 ACEv1：统一 x86 AI 加速指令集
x86 生态正在朝着指令集统一迈出不同寻常的一步。
GCC 17 已经合并对 ACEv1（AI Compute Extensions）的初步支持。 ACEv1 是由 Intel 与 AMD 联合开发的矩阵加速指令集，开发者可以通过 -macev1 编译器选项生成面向这一新 ISA 的代码。
更值得注意的是，目前市面上还没有任何能够执行 ACE 指令的 x86 处理器。
这并不意味着 GCC 的支持来得太早。事实上，在新指令集生态的开发过程中，编译器、操作系统、库以及工具链提前支持未来硬件是一种非常常见的做法。
更重要的是，ACEv1 并不仅仅是又一个 AI 指令扩展。
过去几十年里，Intel 与 AMD 经常分别推出不同的 ISA 扩展，使软件开发者不得不维护针对不同厂商的优化路径。
而 ACEv1 尝试建立一种不同的模式：
为 x86 平台提供一个由 Intel 与 AMD 共同支持的 AI 矩阵加速目标。
如果未来硬件能够按照规范落地，开发者就有机会围绕 ACEv1 构建更加统一的 x86 AI 软件栈。
🧭 GCC 17 在硬件到来之前铺路 #
ACEv1 的初步支持已经进入 GCC 17 开发分支。
开发者可以使用：
-macev1
启用 ACEv1 目标。
启用该选项后，GCC 会同时启用 ACEv1 所依赖的基础指令集，包括：
- SSE/SSE4
- AVX
- AVX2
- AVX10.1
- ACEv1
这意味着编译器开发者可以在 ACEv1 硬件正式上市之前，提前开始生成和测试相关代码。
与此同时，LLVM/Clang 的 ACEv1 支持也正在推进。
按照目前的 GCC 发布计划，GCC 17.1 预计将在 2027 年 3 月至 4 月之间发布，届时有望成为首个包含 ACEv1 支持的稳定版 GCC。
整体开发路径大致如下：
ACEv1 规范
│
▼
编译器支持
│
┌──┴────┐
▼ ▼
GCC LLVM/Clang
│ │
└──┬────┘
▼
AI 库 / AI 框架
│
▼
ACEv1 硬件
│
▼
真实性能验证
目前缺少的，正是最后一步。
现阶段还没有可以实际执行 ACEv1 指令的量产 x86 处理器。
🤝 ACEv1 背后是 Intel 与 AMD 的共同设计 #
ACEv1 源自 x86 Ecosystem Advisory Group（x86 生态系统咨询组织）。
该组织于 2024 年底成立，由 Intel 与 AMD 共同推动，成员还包括 Broadcom、Dell、Google、HPE、HP、Lenovo、Meta、Microsoft、Oracle 和 Red Hat 等企业。
其核心目标是推动 x86 生态在架构和软件层面的协调。
这件事之所以重要，是因为指令集碎片化一直是 x86 软件优化中的一个现实问题。
过去，一家厂商推出新的矩阵或向量扩展后，另一家厂商可能采用完全不同的方案，或者在后续处理器世代才提供对应能力。
最终的软件结构往往变成：
厂商 A CPU
│
└── 厂商 A 专用优化
厂商 B CPU
│
└── 厂商 B 专用优化
应用程序
│
├── 路径 A
└── 路径 B
ACEv1 希望把这种模式变成：
ACEv1
│
┌───────┴───────┐
▼ ▼
Intel AMD
│ │
└───────┬───────┘
▼
统一 AI ISA
│
▼
共享软件路径
ACEv1 官方规范已于 2026 年 6 月公开。
这使编译器、操作系统和 AI 软件开发者能够在兼容硬件正式上市前开始准备。
🧮 ACEv1 专注矩阵运算与 AI 推理 #
ACEv1 的主要目标是矩阵乘法和低精度 AI 工作负载。
其架构包括：
- 8 个 512-bit Tile 寄存器
- 每个 Tile 寄存器包含 16 行
- Block Scaling 寄存器
- 基于二维 Tile 的结果累加
- 面向 AI 的低精度数据格式
目前支持的主要数据格式包括：
| 数据格式 | 主要用途 |
|---|---|
| INT8 | 量化推理 |
| BF16 | AI 训练与推理 |
| MXFP8 | 低精度 AI 计算 |
| MXINT8 | 量化矩阵运算 |
这体现了 CPU 架构的一个重要趋势。
随着大语言模型和其他 AI 工作负载越来越依赖矩阵运算，仅依靠传统向量指令处理这些计算已经越来越低效。
矩阵加速器则采用不同思路：
传统向量计算
向量 A ──┐
├── MAC ── 结果
向量 B ──┘
矩阵计算
矩阵 A ─────────┐
├── 矩阵引擎
矩阵 B ─────────┘
│
▼
Tile 结果
核心目标是让每条指令处理更多矩阵运算，同时提高计算密度和数据利用率。
📐 Tile 架构提升 ACEv1 的计算密度 #
ACEv1 没有简单地把矩阵运算当作普通的一维向量操作，而是引入了面向二维 Tile 的编程模型。
其外积操作可以直接将计算结果累加到二维 Tile 寄存器中。
根据公开架构资料，在输入向量数量相同的情况下，ACE 外积操作的理论吞吐量最高可以达到等效 AVX10 MAC 操作的约 16 倍。
但这个数字需要正确理解。
它是架构层面的理论吞吐量比较，而不是实际应用性能测试。
真正的应用性能还会受到多种因素影响，例如：
- CPU 主频
- ACE 执行单元数量
- 内存带宽
- Cache 行为
- 矩阵尺寸
- 数据布局
- 量化方式
- 编译器优化
- 软件实现
在 ACEv1 硬件真正上市之前，没有办法验证完整应用中的实际性能。
因此，16 倍应该被理解为指令架构潜力，而不是意味着所有 AI 工作负载都能获得 16 倍加速。
🔧 ACEv1 并不兼容 Intel AMX 二进制代码 #
ACEv1 在设计理念上与 Intel 的 Advanced Matrix Extensions（AMX） 存在一定联系，但它并不是简单地把 AMX 换成 AMD 版本。
两者并不具备二进制兼容性。
现有 AMX 二进制程序无法直接在 ACEv1 硬件上运行。
不过，ACEv1 保留了类似的 Tile/Matrix 编程抽象，因此已经熟悉 AMX 的开发者在迁移代码时，不一定需要彻底重写整个矩阵计算框架。
可以简单理解为：
Intel AMX
│
├── 现有 AMX 二进制
└── AMX 专用实现
ACEv1
│
├── 全新 ISA
├── 需要重新编译
└── Intel + AMD 共同目标
因此，AMX 软件仍然需要进行移植。
但对于已经采用 Tile-based Matrix 编程模型的开发者来说，ACEv1 的迁移思路会更加接近于调整指令参数、寄存器和接口，而不是完全推倒重来。
🧠 为什么 ACEv1 强调低精度 AI #
ACEv1 支持的多种数据格式直接说明了它的主要目标之一：
现代 AI 推理。
大型语言模型和其他神经网络越来越多地使用量化技术，以降低内存占用并提高推理吞吐量。
当数据从较高精度格式转向 INT8、FP8 家族以及其他低精度表示时，每个元素需要传输的数据量会减少。
这可以降低内存系统压力，并提高矩阵计算单元的数据利用率。
简单来说：
更高精度
│
▼
每个元素占用更多字节
│
▼
更高内存流量
│
▼
计算效率受限
更低精度
│
▼
每个元素占用更少字节
│
▼
Cache / 带宽利用率提高
│
▼
更高 AI 吞吐量
因此，ACEv1 与 GPU、NPU 以及其他 AI 加速器的发展方向是一致的：
将高度重复的矩阵计算交给专用硬件，同时尽可能使用低精度数据格式提高计算效率。
🖥️ Diamond Rapids 与未来 Zen 是关键硬件目标 #
编译器支持只是第一步。
真正决定 ACEv1 是否成功的，是硬件落地。
目前已知的 ACEv1 硬件目标包括 Intel 下一代 Diamond Rapids 处理器，以及未来采用 Zen 架构的 AMD 处理器。
不过，两家公司目前都没有公布明确的 ACEv1 产品上市时间。
因此整个开发过程很可能呈现出这样的顺序：
2026
ACEv1 规范
│
▼
GCC / LLVM 支持
│
▼
AI 软件栈适配
│
▼
2027+
ACEv1 硬件
│
▼
性能测试与优化
让软件先于硬件准备好，可以避免第一代 ACEv1 CPU 上市时整个生态仍然从零开始。
这一点对于 AI 尤其重要。
新的 ISA 不只是需要编译器支持，还需要：
- 操作系统
- Runtime
- 数学库
- 推理引擎
- AI 框架
- 开发工具
- 性能分析工具
共同完成适配。
🧱 真正决定 ACEv1 成败的是软件生态 #
一个编译器选项本身并不能创造成功的 AI 指令集。
ACEv1 最终需要进入大量真实的软件栈，例如：
- BLAS 类数学库
- 矩阵乘法 Kernel
- 量化推理引擎
- Transformer Runtime
- LLM 推理服务
- 计算机视觉框架
- 科学计算库
理想状态下，开发路径应该是：
AI 框架
│
▼
推理 Runtime
│
▼
优化矩阵库
│
▼
ACEv1 Backend
│
┌─┴──┐
▼ ▼
Intel AMD
CPU CPU
这正是 ACEv1 跨厂商特性的价值所在。
如果同一个 ISA 可以同时覆盖 Intel 与 AMD CPU，软件厂商就拥有更强的动力投入统一优化。
🔄 ACEv1 有望降低 x86 优化碎片化 #
ACEv1 的战略价值不仅在于矩阵乘法。
x86 软件已经积累了几十年的厂商特定扩展。
为了获得最大性能，开发者通常需要检测 CPU 能力，然后选择不同的优化路径。
应用程序
│
▼
CPU 能力检测
│
├── AVX2
├── AVX-512
├── AMX
├── 厂商扩展 A
├── 厂商扩展 B
└── 通用路径
每增加一种专用路径，就意味着更多开发、测试和维护成本。
如果 ACEv1 能够成为统一的 AI 加速目标，则软件结构可能变成：
应用程序
│
▼
统一 AI Backend
│
▼
ACEv1
│
┌──┴──┐
▼ ▼
Intel AMD
这并不意味着所有厂商优化都会消失。
不同 CPU 仍然可能拥有不同的：
- 执行资源
- 主频
- Cache 层级
- 内存带宽
- ACE 单元数量
- 功耗策略
因此，高性能软件依然可能需要针对具体 CPU 做进一步优化。
但至少在 ISA 层面，共同标准可以降低 AI 软件的基础适配成本。
🌍 真正重要的是 x86 生态开始合作 #
GCC 17 加入 ACEv1 支持，并不意味着今天的 AI 程序已经可以获得 ACE 加速。
因为目前根本没有可执行 ACEv1 指令的量产 CPU。
真正值得关注的是合作方式和时间点。
过去的 x86 生态中，指令集扩展经常同时承担竞争壁垒的角色。
一家厂商推出新的扩展，另一家厂商可能采用不同方案，最终软件开发者需要维护多套优化路径。
ACEv1 则代表了一种不同的方向。
Intel 与 AMD 联合设计 AI 指令集，然后在兼容硬件上市之前，就让它进入 GCC、LLVM 等开源工具链。
这本身就是一个具有象征意义的生态里程碑。
🚀 从编译器选项走向 x86 AI 标准 #
GCC 17 的 -macev1 看起来只是一个普通的编译器选项，但它实际上可能成为 x86 统一 AI 加速生态的重要起点。
未来的完整路线可以概括为：
ACEv1 规范
│
▼
GCC / LLVM 支持
│
▼
AI 数学库与 Runtime
│
▼
Intel + AMD 硬件
│
▼
性能验证
│
▼
生产级 AI 软件
真正的关键将在硬件上市之后。
如果 Diamond Rapids 与未来 Zen 处理器能够以有竞争力的性能实现 ACEv1，同时主流 AI 框架和推理引擎积极采用这一 ISA，那么开发者将获得更加统一的 x86 AI 矩阵加速路径。
反过来，如果硬件上市时间过晚，或者软件生态没有形成规模，ACEv1 也可能最终只停留在一个有趣的架构规范层面。
但至少目前，方向已经非常明确。
GCC 17 正在为一个新的 x86 时代提前铺路：AI 加速不再只是某一家 CPU 厂商的专属能力，而有机会成为 Intel 与 AMD 共同支持的标准化架构目标。
真正值得关注的时刻，将是 -macev1 不再只是面向未来硬件生成代码，而是能够在 Intel 与 AMD 的实际 CPU 上带来可验证、可重复的 AI 性能提升。