1. 项目概述：为什么需要一份AMD与Hygon平台FAQ

在服务器、工作站乃至高性能计算领域，除了我们熟知的英特尔平台，以AMD EPYC和海光（Hygon）为代表的x86处理器阵营正扮演着越来越重要的角色。无论是数据中心运维工程师、系统管理员，还是进行深度学习模型训练的开发者，在日常工作中都会频繁与这些平台打交道。然而，与更为“大众”的英特尔生态相比，围绕AMD及Hygon平台的特有技术、驱动安装、BIOS设置乃至故障排查，常常存在一些独特的“坑”和模糊地带。

网络上零散的提问和解答，往往不成体系，且随着硬件和软件版本的快速迭代，很多信息已经过时。我整理这份FAQ的初衷，正是源于自己在部署和维护数十台基于AMD EPYC和海光处理器的服务器集群时，踩过的无数个坑。从驱动安装报错、虚拟化功能异常，到性能调优瓶颈，每一个问题都耗费了大量时间摸索。因此，我希望将这些问题、解决方案以及背后的原理梳理成一份结构化的文档，帮助后来者快速定位问题，理解平台特性，从而更高效地发挥硬件潜力。

这份总结不仅是一份问题排查手册，更是一份理解平台差异的技术指南。它适用于所有需要接触AMD及Hygon硬件的IT从业者，无论你是刚接手新设备的运维新手，还是正在为特定应用优化环境的技术专家，都能从中找到有价值的参考。

2. 核心平台特性与架构差异解析

要有效解决问题，首先必须理解平台间的根本差异。AMD（尤其是EPYC系列）和海光处理器虽然都基于x86指令集，但在核心架构、互联方式和外围芯片组设计上，与英特尔平台有着显著不同，这些差异直接导致了使用体验和问题形态的迥异。

2.1 AMD EPYC与海光处理器的核心架构特点

AMD EPYC处理器采用“小芯片”（Chiplet）设计，通过高带宽的Infinity Fabric互联技术将多个核心复合体（CCD）和I/O芯片（cIOD）连接在一起。这种设计带来了极高的核心密度和内存通道数（例如，单路EPYC 9004系列最高支持12通道DDR5），但同时也引入了NUMA（非统一内存访问）拓扑的复杂性。一个物理CPU内部可能包含多个NUMA节点，这对操作系统调度、内存分配和应用程序性能有巨大影响。

海光处理器是基于AMD Zen架构的授权设计，因此在核心架构、指令集和内部互联（Infinity Fabric）上与同期AMD EPYC处理器高度相似。这意味着许多针对AMD平台的优化策略和问题排查思路，同样适用于海光平台。然而，由于供应链和固件开发独立，在BIOS界面、管理功能（如BMC）、特定设备驱动（如网卡、RAID卡）等方面，两者可能存在差异，需要特别注意厂商提供的专属文档和驱动。

2.2 芯片组与平台管理接口差异

与英特尔平台高度整合的PCH（平台控制器中枢）不同，AMD EPYC的绝大部分I/O功能都集成在CPU内部的cIOD中。因此，“芯片组驱动”的概念在AMD平台上相对弱化。我们常说的“AMD Chipset Driver”实际上主要包含一些电源管理、PCIe设备管理、USB控制器和SATA控制器的基础驱动与配套软件。它的缺失通常不会导致系统无法启动，但可能影响设备性能、电源效率和一些高级功能（如PCIe ASPM）的正常工作。

海光平台同样继承了这一特点。在安装操作系统后，首要任务往往是安装海光官方提供的“平台驱动包”，其中就包含了适配其I/O芯片的驱动程序。忽略这一步，可能会在设备管理器中看到未知设备，或者遇到USB接口性能不稳定等问题。

注意：无论是AMD还是海光，从官方网站下载芯片组或平台驱动时，务必确认其与你的CPU型号（如EPYC 7003/9004系列）和操作系统版本严格匹配。用错版本是导致“安装程序无法继续”的常见原因。

2.3 虚拟化技术实现的异同

AMD和英特尔都提供了硬件辅助虚拟化技术（AMD-V / Intel VT-x），但在具体实现和功能上存在差异。例如，AMD的嵌套页表（NPT）与英特尔的扩展页表（EPT）功能类似，但底层实现不同。这导致了一些虚拟化软件在高级功能支持上可能存在平台特异性。

一个典型问题是：在AMD平台上安装VMware ESXi或使用KVM/QEMU创建虚拟机时，某些特定的设备直通（PCIe Passthrough）或嵌套虚拟化配置可能需要不同的BIOS设置或内核参数。海光平台在此方面与AMD基本一致，但同样需要查阅海光提供的虚拟化技术白皮书，确认其BIOS中相关选项（通常名为SVM Mode，即安全虚拟机模式）已启用，并且IOMMU（在AMD平台上通常指AMD-Vi）功能也必须打开，才能支持设备直通。

3. 驱动安装与系统部署常见问题实战

这是新手接触AMD/海光平台时最容易“卡壳”的环节。以下是我从实际运维中总结出的高频问题及其解决方案。

3.1 “AMD芯片组软件安装程序无法继续”深度排查

这个报错信息非常普遍，其根本原因通常是安装环境不满足前置条件。安装程序本质上是一个解包和安装脚本的组合，它会对当前系统状态进行一系列检查。根据我的经验，可以从以下几个层面进行排查，顺序由简到繁：

1. 系统完整性检查：

   • Windows系统：首先以管理员身份运行命令提示符，执行sfc /scannow和DISM /Online /Cleanup-Image /RestoreHealth命令，修复可能损坏的系统文件。许多安装失败是由于系统关键运行时库（如Visual C++ Redistributable）缺失或损坏引起的。
   • 临时文件清理：使用磁盘清理工具或手动删除C:\AMD文件夹（如果存在）以及%temp%目录下的临时文件，然后重启再试。旧的、不完整的安装文件会干扰新安装进程。

2. 安装包与系统匹配性验证：

   • 位数匹配：确认你下载的安装包是64位（64-bit）版本。AMD芯片组驱动已不再提供32位支持。
   • 版本匹配：这是最关键的一步。例如，为EPYC 7003系列（Milan）设计的芯片组驱动，可能不完全兼容EPYC 9004系列（Genoa），反之亦然。务必在AMD官网支持页面，通过CPU型号或主板型号进行精确筛选。
   • 安装方式尝试：不要总是运行Setup.exe。尝试在设备管理器中，对未知设备或有感叹号的设备（如“PCI设备”、“SM总线控制器”）手动更新驱动，并指向驱动解压后的文件夹（通常安装包可解压）。这种方式往往能绕过安装程序本身的检测逻辑。

3. 冲突软件与安全软件干预：

   • 暂时禁用或卸载第三方系统优化工具、旧的芯片组工具或监控软件。
   • 临时关闭Windows Defender实时保护或第三方杀毒软件，有时它们会误拦截安装程序对系统底层的修改。

3.2 显卡驱动与计算生态适配问题

“AMD显卡能用CUDA吗？”这是一个经典问题。答案是：不能直接使用。CUDA是英伟达（NVIDIA）的专属并行计算平台和编程模型。AMD显卡对应的是ROCm（Radeon Open Compute）平台。对于深度学习等GPU计算任务，你需要将框架（如PyTorch、TensorFlow）从CUDA后端切换到ROCm后端。

• ROCm安装：ROCm的安装比CUDA更依赖特定的Linux内核版本和显卡型号。以Ubuntu系统为例，你需要先确认你的AMD显卡（如Instinct MI系列、Radeon Pro系列或消费级的RDNA2/3架构显卡）在ROCm官方支持列表内。然后，按照官方指南添加仓库、安装特定版本的ROCm套件。安装后，通过rocminfo命令验证是否识别到GPU。
• 框架适配：PyTorch和TensorFlow都提供了预编译的ROCm版本。例如，安装PyTorch时，应使用pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm5.7（版本号随ROCm更新）这样的命令。直接安装默认的CUDA版本是无法调用AMD显卡的。

“AMD Software: Adrenalin Edition打不开”通常出现在消费级显卡上。对于数据中心和专业卡，我们使用AMDGPU-PRO驱动或开源amdgpu驱动，并通过命令行或系统服务进行管理。打不开桌面控制面板的问题，多与Windows系统服务异常、用户权限或驱动损坏有关。可以尝试在“服务”中重启“AMD External Events Utility”服务，或使用AMD官方提供的清理工具（AMD Cleanup Utility）彻底卸载后重装驱动。

3.3 操作系统安装与驱动注入

在安装Windows Server或桌面版Windows时，如果安装介质未集成AMD/海光平台的存储控制器（SATA/NVMe RAID）驱动，可能会在分区选择界面看不到任何磁盘。此时需要提前准备驱动。

• 准备工作：从服务器主板或海光厂商官网下载对应的“RAID驱动”或“SATA Preinstall Driver”（通常是一个包含.inf,.sys,.cat文件的文件夹）。
• 注入方法：在Windows安装界面，当提示“找不到驱动器”时，点击“加载驱动程序”，然后浏览到驱动文件夹所在位置（通常需要放在U盘根目录）。加载成功后，磁盘即可被识别。
• Linux系统：主流Linux发行版（如Ubuntu 20.04 LTS之后、RHEL/CentOS 8之后）的内核通常已包含对AMD EPYC和海光平台的基本驱动支持，安装过程一般顺利。但对于最新的硬件，可能需要使用较新的内核版本或从厂商获取DKMS模块。

4. BIOS/UEFI设置关键项与性能调优

平台的许多高级功能和性能表现都隐藏在BIOS设置中。错误的设置可能导致性能损失、功能异常或系统不稳定。

4.1 虚拟化与IOMMU相关设置

为了顺利运行虚拟机或进行GPU直通，以下BIOS选项必须正确配置（不同主板厂商的选项名称可能略有不同）：

启用IOMMU后，在Linux系统中，你还需要在GRUB内核引导参数中添加amd_iommu=on（对于AMD）或iommu=pt（对于海光及通用情况）。之后可以通过dmesg | grep -i iommu或lspci -vvv命令验证IOMMU分组情况，这是成功进行PCIe设备直通的前提。

4.2 内存与Infinity Fabric调优

AMD EPYC和海光处理器的内存性能与Infinity Fabric（IF）时钟频率紧密耦合。BIOS中相关设置对性能影响巨大。

• 内存频率与分频：EPYC处理器支持内存分频模式（如1:1同步模式和1:2异步模式）。1:1同步模式下，内存控制器时钟（UCLK）和内存时钟（MEMCLK）同步，延迟最低，是性能首选。但达到高频（如DDR5-4800以上）时，可能必须切换到1:2异步模式，此时UCLK减半，会带来延迟增加。在BIOS中，这个选项可能叫“UMC/DF Clock Mode”或“Memory Clock Speed”，设置为“Sync”即为1:1模式。
• Infinity Fabric时钟（FCLK）：FCLK是连接CPU内部各个小芯片的时钟。在1:1模式下，理想状态是FCLK:UCLK:MEMCLK = 1:1:1。BIOS中通常有“Fabric Clock”或“Infinity Fabric Frequency”选项，可以设置为“Auto”或手动指定一个与内存频率匹配的值（例如，DDR5-4800对应2400 MHz的FCLK）。保持三者同步能获得最佳性能。
• NUMA感知：在BIOS中开启“NUMA Nodes Per Socket”或类似选项，让操作系统正确识别CPU内部的多个NUMA节点。对于数据库、虚拟化等应用，在系统层面（如Linux的numactl命令）或应用内部进行NUMA绑定，可以显著减少跨节点内存访问带来的延迟。

4.3 电源与性能模式选择

服务器BIOS中通常提供多种电源策略：

• Performance：最大化性能，CPU持续运行在高频，功耗和发热也最高。
• Power Saving：以节能为首要目标，可能会限制CPU频率。
• OS Control或Balanced：将电源管理交给操作系统（如Windows的电源计划、Linux的cpufreq调节器）。这是最常用且灵活的选项。

对于计算密集型负载，建议在BIOS中设置为Performance，并在操作系统中也选择高性能模式。同时，检查并禁用可能影响性能的选项，如C-States（深度节能状态）和Global C-State Control，在追求极致低延迟的应用场景下，禁用它们可以避免CPU从睡眠状态唤醒带来的延迟抖动。

5. 典型故障场景与排查命令实录

理论结合实践，下面是我在运维中遇到的几个典型案例及其排查流程。

5.1 案例：PCIe设备识别异常或性能低下

现象：新安装的NVMe SSD或高速网卡，在系统中识别到的链路速度（如PCIe 4.0 x4）低于预期（如PCIe 4.0 x8），或设备完全无法识别。

排查思路：

1. 确认硬件连接：首先检查设备是否牢固插入正确的PCIe插槽。AMD EPYC平台的不同PCIe通道可能由不同的CPU CCD或cIOD提供，查阅主板手册，确认你使用的插槽是由CPU直连的，并且支持所需的通道数（x8, x16）。
2. 检查BIOS设置：
   • 进入BIOS，找到PCIe子系统设置，确认该插槽的“链路速度”和“链路宽度”没有被人为限制在低档位（如Gen3或x4模式）。
   • 确认“Above 4G Decoding”和“SR-IOV”（如果设备支持）已启用。
3. 操作系统内验证：
   • Linux：使用lspci -vvv命令查看设备详情。重点关注LnkSta字段，它会显示当前协商的速度（Speed）和宽度（Width）。例如Speed 16GT/s, Width x8表示PCIe 4.0 x8。如果显示Speed 2.5GT/s或Width x1，则说明降级了。
   • Windows：使用设备管理器查看设备属性，在“详细信息”标签页中选择“总线关系”或“位置路径”，也可以使用第三方工具如HWiNFO64查看PCIe链路信息。
4. 更新固件与驱动：更新主板BIOS、设备固件（如NVMe SSD固件）和设备驱动到最新版本。旧版本固件可能存在链路协商的bug。

5.2 案例：系统随机卡顿或特定应用崩溃

现象：系统运行不稳定，偶尔出现卡顿，或运行某些内存敏感型应用（如大型编译、科学计算）时发生崩溃。

排查思路：

1. 内存诊断：这是首要怀疑对象。使用像memtest86+这样的工具从U盘启动，进行至少4个完整通道的内存测试。AMD平台对内存稳定性非常敏感，特别是当使用高密度内存条或插满所有插槽时。
2. 检查内存配置：进入BIOS，确认内存是否运行在正确的频率和时序下。如果你开启了XMP/EXPO或手动超频，尝试先恢复默认的JEDEC标准设置（如DDR5-4800），看问题是否消失。不稳定往往是内存超频导致的。
3. Infinity Fabric稳定性：如果你手动设置了FCLK频率，过高的FCLK可能导致系统不稳定。尝试将FCLK设置为“Auto”或降低一档。
4. CPU压力测试：使用Prime95（混合模式）或AIDA64的系统稳定性测试，对CPU和内存进行综合压力测试。观察是否会出现错误或核心停止工作（WHEA错误）。在Windows事件查看器中，检查“系统”日志，筛选来源为“WHEA-Logger”的错误事件，这些硬件错误日志能提供宝贵线索。
5. 电源与散热：检查CPU散热是否良好，是否存在过热降频。检查服务器电源功率是否足够，特别是在满载所有PCIe设备时。

5.3 案例：虚拟机性能异常或设备直通失败

现象：在AMD/海光平台上使用KVM或ESXi，虚拟机内部性能远低于预期，或者尝试将GPU直通给虚拟机时失败。

排查思路：

1. 验证虚拟化支持：在宿主机的Linux系统中，运行egrep -c '(svm|vmx)' /proc/cpuinfo，输出大于0则表示CPU支持虚拟化。运行dmesg | grep -i iommu，确认IOMMU已正确启用并分组。
2. 检查IOMMU分组：使用脚本或命令查看PCIe设备的IOMMU分组情况。理想情况下，需要直通的设备（如GPU）应独占一个IOMMU组。如果它与其它设备（如USB控制器）在同一组，则无法单独直通。这时可能需要尝试在BIOS中启用ACS（Access Control Services）支持（如果主板提供该选项），或者使用PCIe插槽隔离。
3. 虚拟机配置检查：
   • CPU模式：在虚拟机的XML配置（libvirt）或.vmx文件（VMware）中，检查CPU模式是否设置为host-passthrough（KVM）或“向客户机公开硬件辅助的虚拟化”（VMware）。这能让虚拟机直接使用宿主CPU的所有特性，获得最佳性能。
   • NUMA绑定：对于多NUMA节点的大内存虚拟机，为其分配完整的NUMA节点（包括对应的CPU核心和内存），并在配置中做好绑定，可以避免跨节点访问。
   • 海光平台特定驱动：在海光平台上运行Windows虚拟机，可能需要额外安装海光提供的虚拟化设备驱动（如磁盘、网卡驱动），以获得更好的性能。

6. 开源软件与开发环境适配指南

在AMD/海光平台上进行软件开发，尤其是涉及GPU计算时，需要特别注意工具链的适配。

6.1 编译工具链与数学库优化

对于高性能计算（HPC）应用，使用针对AMD Zen架构优化的编译器和数学库至关重要。

• 编译器：推荐使用AMD Optimizing C/C++ Compiler (AOCC) 或支持-march=znver3(对应Zen 3) /-march=znver4(对应Zen 4) 架构标志的GCC/Clang编译器。这些编译器能生成针对AMD处理器流水线特点优化的代码。
• 数学库：使用AMD提供的AOCL（AMD Optimizing CPU Libraries），它包含了BLAS、FFT、Sparse等库的优化版本，相比通用版本在AMD CPU上性能提升显著。在编译你的应用时，链接这些优化库。

6.2 ROCm生态下的深度学习环境搭建

如前所述，AMD GPU依赖ROCm。搭建环境时，请严格遵循以下顺序：

1. 确认硬件与内核支持：核对GPU型号和ROCm版本支持的Linux内核列表。例如，ROCm 5.7可能要求内核版本 >= 5.15。
2. 安装ROCm：按照AMD官方文档，通过包管理器安装。在Ubuntu上，命令类似：

   sudo apt update sudo apt install rocm-hip-sdk rocm-opencl-sdk sudo usermod -a -G video,render $LOGNAME # 将用户加入必要组

   安装后重启，运行rocminfo和clinfo验证安装。
3. 安装ROCm版本的PyTorch：前往PyTorch官网，选择ROCm版本的安装命令。例如：

   pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm5.7

4. 验证：在Python中运行import torch; print(torch.cuda.is_available())，如果ROCm配置正确，这里会返回True（尽管名字叫cuda，但后端已是ROCm）。运行torch.rand(10).to(‘hip’)测试GPU计算。

6.3 特定工具的使用问题

• Hashcat on AMD：Hashcat完美支持AMD GPU。你需要安装ROCm的HIP运行时，并在运行Hashcat时使用-D 2参数来指定使用AMD GPU设备。确保ROCm驱动安装正确，Hashcat就能调用GPU进行破解计算。
• VMware安装macOS：在AMD平台上通过VMware Workstation安装macOS作为虚拟机，需要打特定的补丁（如“AMD OSX Patcher”），因为macOS系统内核默认包含对英特尔CPU的检查和一些特定指令的依赖。这是一个非官方支持的“黑苹果”场景，稳定性无法保证，且可能违反macOS的最终用户许可协议（EULA），仅适用于学习和测试环境。
• Arch Linux AMD显卡驱动：对于较新的AMD显卡，Arch Linux用户应安装mesa（开源3D驱动）、vulkan-radeon（Vulkan驱动）和lib32-mesa（32位支持）包。对于专业计算，可能需要从AUR安装rocm-opencl-runtime。开源驱动amdgpu已内置于内核中，通常无需额外安装。