企业官网建设流程全解析

如果你手里只有 AMD 显卡或者 Intel 核显，想跑 KataGo 分析棋谱，估计已经体会过那种尴尬：官方预编译包基本围绕 N 卡 CUDA 设计，你用 CPU 版硬扛，每手棋访问量稍微开大一点，等分析等到怀疑人生。其实 KataGo 早就不是 N 卡专属，AMD 显卡可以走 ROCm 后端，Intel 核显和 Arc 独显可以走 OpenVINO 后端，两条路都能把推理速度拉起来。这篇文章就是我在这两套硬件上实际折腾 KataGo 提速的完整记录，包括编译细节、兼容参数、运行配置和踩坑经验，适合手里有 A 卡或核显、想在不换硬件的前提下让分析速度上一个台阶的人。

1. 为什么 KataGo 在 A 卡/Intel 核显上提速值得折腾

1.1 KataGo 的计算特点：神经网络推理才是主要瓶颈

KataGo 这种现代围棋 AI 的算力消耗集中在两部分：神经网络的策略/价值推理，以及蒙特卡洛树搜索（MCTS）。每一步棋的评估都要把当前盘面丢进神经网络算一次，访问量一高，推理次数呈线性上涨。用 CPU 版 eigen 后端跑的时候，CPU 既要负责神经网络矩阵运算，又要兼顾搜索展开，两边抢资源，单局分析自然慢。

这也是为什么把神经网络推理挪到 GPU 上收益最大。ROCm 和 OpenVINO 本质上都是在做这件事：前者是 AMD 显卡的通用计算栈，后者是 Intel 面向自家硬件的推理运行时。KataGo 通过这两个后端，把原来的 CPU 矩阵计算搬到 GPU 执行单元上，CPU 核心就能腾出来专心跑 MCTS 搜索，整体吞吐提升非常明显。

1.2 ROCm 与 OpenVINO 各解决什么问题

ROCm 对应的是 AMD 独显用户。很多 A 卡用户一开始只会下载 eigen 版 KataGo，以为 AMD 显卡没法用，实际上 ROCm 后端在 RDNA 架构卡上的推理速度已经非常接近同价位 N 卡的 CUDA 表现，只是配置链路比 CUDA 多绕几步，而且驱动版本和老卡兼容问题需要留意。

OpenVINO 对应的是 Intel 核显和 Arc 独显用户。核显虽然没有独立显存，但胜在不用额外买硬件，办公机、旧笔记本、迷你主机都能用。OpenVINO 后端能把推理调度到核显的 EU 单元，顺便把 CPU 解放出来给搜索线程，双通道内存下提升特别明显。

我个人的建议是：别一上来就追求 b40 级别的大权重，先把手头硬件的后端跑通，用 benchmark 看实际数据，再决定上什么档位的模型。很多人在第一步编译环节就卡住了，然后误以为 A 卡和核显“没法用”，其实只是没找对路。

2. 动手前先认清硬件：路线选择与可行性判断

2.1 先确认显卡架构和驱动状态

AMD 这边主要看架构代号。ROCm 对 RDNA 架构和 CDNA 计算卡的支持最稳，GCN 时代的 RX 400/500 系和 Vega 系列属于“能试但不保证”，新版 ROCm 基本放弃了对老 GCN 的官方匹配。Linux 下可以用lspci看设备：

lspci | grep -i vga

输出里的 Radeon RX 系列再配合rocminfo查看 ROCm 是否识别到 Agent 以及对应的 gfx 代号。Windows 下建议用 WSL2 或者 Linux 环境折腾，ROCm on Windows 目前只支持少数专业卡，普通游戏卡在 Windows 下直接搞 ROCm 容易撞墙。

Intel 这边相对省心，核显 UHD 630/730、Iris Xe、Arc 独显都能走 OpenVINO。Windows 下直接看设备管理器里的显示适配器即可，重点是把显卡驱动装到最新版，旧驱动对 OpenVINO 的 GPU 插件支持差别非常大。

2.2 两条路线的取舍参考

这个表格里的倍数是趋势参考，不是绝对值。同样一颗 8 核 CPU，配 Iris Xe 核显的笔记本和配高端 RDNA 卡的游戏主机，提升幅度肯定不是一个量级。建议跑通后端之后用 KataGo 自带的 benchmark 子命令实测本机数据，再决定要不要上更高强度的权重。

2.3 一个容易被忽略的前提：显存和内存带宽

A 卡独显看显存容量，核显则看共享内存带宽。神经网络推理需要把权重加载进显存，还要给 batch 推理预留中间张量空间。b18 这类权重一般 2GB 以内能装下，b28 以上就开始吃显存了。核显那边没有独立显存，所有数据都走系统内存，双通道内存比单通道的吞吐高不少，我见过不少笔记本用户抱怨 OpenVINO 核显提升不大，最后发现是单通道内存加低功耗模式在拖后腿。

3. AMD 显卡提速：ROCm 后端的编译、兼容参数与实跑调优

3.1 安装 ROCm 环境并确认设备可见

Ubuntu 等 Linux 发行版上，先添加官方源的 repo，再安装基础开发包。不同发行版添加方式不同，大致命令类似：

sudo apt update sudo apt install rocm-dkms rocm-dev

装完以后用rocminfo验证，能看到一块或多块 AMD GPU 的 Agent 列表就算成功。重点是看输出里的 gfx 代号，比如 RDNA2 架构常见的 gfx1030，RDNA3 是 gfx1100 系列，Vega 系列是 gfx900。这个代号决定后面需不需要做兼容设置。

如果你在rocminfo里根本看不到 GPU，先别急着编译 KataGo，检查驱动和权限。ROCm 设备通常需要把用户加入 render 和 video 组，否则运行时可能报权限错误。很多人在这一步就误以为是 KataGo 的问题，其实是系统环境没到位。

3.2 编译 KataGo 的 ROCm 后端

KataGo 源码在 GitHub 上，clone 下来以后切到当前稳定发布版。编译用的是 CMake，后端选择开关在不同版本里命名略有差异，建议先看一眼cpp/CMakeLists.txt里的选项。以常见写法为例：

git clone https://github.com/lightvector/KataGo.git cd KataGo git checkout <你选择的稳定版本tag> cmake -B build-rocm -DUSE_BACKEND=ROCM -DROCM_PATH=/opt/rocm cmake --build build-rocm -j$(nproc)

编译完成后，产物在build-rocm/katago。这里提醒一句：KataGo 的一个二进制只绑定一个后端，编译 ROCm 版的同时，最好保留一份 CPU eigen 版本作备用，方便后续对比数据或者处理 GPU 临时不可用的情况。

如果编译过程中报找不到 ROCm 库，多半是ROCM_PATH没指对。默认安装在/opt/rocm，如果改了路径，CMake 参数也要跟着改。

3.3 老卡兼容：HSA_OVERRIDE_GFX_VERSION 的使用场景

这是 A 卡用户最容易踩坑的地方。ROCm 运行时对新显卡会匹配对应的 gfx 代号，但老架构卡经常没有匹配条目，明明rocminfo能识别，KataGo 一跑就报 unsupported gfx 之类的错误。

解决办法是通过环境变量把显卡“伪装”成邻近的受支持架构：

export HSA_OVERRIDE_GFX_VERSION=9.0.0 # Vega 56/64 等 gfx900 系 export HSA_OVERRIDE_GFX_VERSION=10.3.0 # RDNA1 邻近代次按需调整

这个变量的作用就是告诉 ROCm 运行时，把实际 gfx 代号替换为你指定的值。注意不是随便填，最好根据报错信息选一个架构相近的代号。我实测下来，Vega 系临时用 9.0.0 能跑，但性能并不理想；RDNA1 和 RDNA2 用户如果报错，优先找 10.x.x 系列里对应的代号再试。这属于兼容层操作，不是所有卡都能靠它救回来，老 GCN 架构如果跑起来比 CPU 版还慢，果断放弃 ROCm 路线。

3.4 跑起来之后：benchmark 数值和显存观察

编译完成先跑一次官方 benchmark，用 b18 权重：

./build-rocm/katago benchmark -model <b18权重文件路径>

输出里重点看每秒模拟次数（n/s）和平均单次搜索耗时。对比 CPU 版本跑同一个权重的数据，能直观看到 ROCm 后端带来的提升。

正式对局或分析时，通过analysis.cfg控制参数。我常用的一组起点配置如下：

numSearchThreads = 8 maxVisits = 600 nnBatchSize = 4 nnMaxSearchThreads = 2

nnBatchSize是推理批大小，ROCm 后端对 batch 推理的支持不错，调大能提升吞吐，但显存占用也跟着涨。我实际测试中，某 8GB 显存的 RDNA 中端卡，b18 权重 batch 4 非常稳，batch 8 能跑但是整机峰值功耗和显存波动明显；b28 权重 batch 4 已经接近显存边缘，建议降到 2。显存不够的表现通常是推理线程报 OOM 或者整机画面卡顿，这时候优先降 batch 而不是降权重。

4. Intel 显卡提速：OpenVINO 后端的编译、核显调用与模型缓存

4.1 先理解 OpenVINO 的调度逻辑

OpenVINO 不是简单地把所有计算都丢给 GPU。它是一套面向 Intel 硬件的推理运行时，CPU、核显、Arc 独显、NPU 都能作为执行设备。KataGo 的 OpenVINO 后端会让插件在可用设备里选择合适的执行单元，大部分情况下会自动挑核显或独显。

这里有个很多人没想明白的点：核显参与推理后，CPU 核心并没有闲着，而是继续跑 MCTS 搜索。换句话说，OpenVINO 后端把原来 CPU 要同时干的两种活拆开了，神经网络归 GPU，搜索归 CPU，两条流水线并行。这就是为什么哪怕核显本身算力一般，整体速度也能比纯 CPU 版快出一个量级。

4.2 编译 OpenVINO 版 KataGo

先装 OpenVINO 运行时。Linux 下最简单的方式是 pip 安装，KataGo 编译需要 OpenVINO 的 C++ 头文件和 CMake 配置，pip 安装的包如果带 dev 组件一般够用，也可以从 Intel 官网下载完整 runtime 包并设置OpenVINO_DIR环境变量。

Windows 下同样建议下载官方预编译包，把OpenVINO_DIR指向安装目录，然后用 CMake 编译：

cmake -B build-ov -DUSE_BACKEND=OPENVINO -DOpenVINO_DIR=<你的OpenVINO安装路径> cmake --build build-ov -j$(nproc)

编译参数在不同 KataGo 版本里可能略有变化，如果碰到不认识的后端开关名，去看cpp/CMakeLists.txt里的说明。编译成功后会生成build-ov/katago，这个二进制就是 OpenVINO 后端专用版本。

4.3 首次运行和模型缓存

第一次用 OpenVINO 后端加载权重会比较慢，少则几十秒，多则几分钟，原因是需要把 KataGo 的权重转换成 OpenVINO 的中间表示（IR），并写入缓存目录。之后再启动同一个权重，加载速度会明显变快。

缓存目录一般在用户主目录下，具体位置取决于 KataGo 编译时用的 OpenVINO 版本。如果换了 OpenVINO 版本或者权重文件有变化，缓存可能失效并重新生成，属于正常现象，不是出 Bug 了。

遇到缓存写入失败的情况，优先检查缓存目录的读写权限。我用系统权限受限的用户跑过一次，首轮加载一直报错，切换到有写权限的目录或者用管理员权限运行就正常了。另外，把缓存放在 SSD 上比机械硬盘快很多，这个细节在开局加载阶段体感特别明显。

4.4 核显调优：内存带宽、驱动和 BIOS

核显的性能上限很大程度由内存带宽决定。单通道内存下，OpenVINO 核显后端的提升幅度会缩水；双通道内存和开启 XMP 之类的高频内存配置能让核显推理吞吐明显改善。我建议在 BIOS 里确认核显没被禁用，再检查系统电源计划是不是被设成了节能模式，笔记本尤其容易踩这个坑。

Arc 独显用户还有额外一步：进入 BIOS 确认 Resizable BAR 是否开启。这个选项影响 GPU 与 CPU 之间的数据交换效率，关着的话 OpenVINO 的 GPU 插件可能无法发挥全部性能。驱动方面务必更新到最新版，Arc 早期驱动对 OpenVINO 的支持发生过明显变化，旧驱动容易出现选不到 GPU 设备的问题。

如果启动日志显示推理仍然跑在 CPU 上，优先检查驱动识别和 OpenVINO 版本，再根据当前 KataGo 源码里 OpenVINO 插件的实现确认设备选择方式。不同版本的设备控制入口差别较大，以你 clone 的代码里的 README 或者启动日志输出为准，不要盲目照搬网上旧教程里的命令行参数。

5. 让提速更稳：权重档位、批处理线程与 GUI 联动参数

5.1 权重模型怎么选：看显存，不只看棋力

KataGo 权重文件命名里包含了结构信息，比如 b18c384nbt 表示 18 个 block、384 个 channel，b28c512nbt 就是更深更宽的模型。权重越强，单次推理耗时越长，对显存和算力的要求也越高。很多人的误区是直接上最新最强权重，结果在核显或者显存有限的 A 卡上每一步都要等很久，体验反而更差。

按我自己的实操经验，大致可以参考这个档位：

这只是一个起点，具体以你机器上的 benchmark 数据为准。我见过有人在 8GB A 卡上强行跑 b40，虽然能启动，但搜索速度掉到没法看，还不如把 b18 的访问量调高一点来得划算。

5.2 analysis.cfg 参数拆解：每个参数都在控制什么

analysis.cfg是 KataGo 分析模式下最核心的配置文件。几个关键参数我分开说明：

numSearchThreads控制搜索并行线程数，一般不超过 CPU 物理核心数，设多了反而因为上下文切换掉性能。maxVisits是每步棋的最大模拟次数，值越大棋力越强但耗时线性增长，日常棋谱分析 600 到 1200 之间比较常用。nnBatchSize是每次神经网络推理的批大小，ROCm 和 OpenVINO 后端都吃 batch，但 batch 太大会拖累单局响应速度。nnMaxSearchThreads决定同时向推理后端发起请求的线程数，和 batch 配合不好时要么 GPU 吃不满，要么显存暴涨。nnCacheSize是历史推理结果缓存，可以降低重复局面的计算量，但对内存有开销。

我常用的一套起点配置：

numSearchThreads = 8 maxVisits = 800 nnBatchSize = 4 nnMaxSearchThreads = 2 nnCacheSize = 209715200

如果你主要跑 CPU 后端，numSearchThreads可以适当调低，给神经网络计算留资源；如果已经切到 ROCm 或 OpenVINO 后端，numSearchThreads反而可以拉满，因为神经网络推理已经不在 CPU 上跑了。

5.3 接入 Lizzie / Sabaki：多引擎和线程分配

Lizzie 和 Sabaki 这类图形界面本质上是在启动一个 KataGo analysis 进程，然后持续发送局面查询。GUI 里有自己的分析线程上限设置，KataGo 侧则受analysis.cfg控制。建议让两侧的线程数量保持一致，避免出现 GUI 等 KataGo 或者 KataGo 空转的情况。

如果你的机器上既有 Intel 核显又有一颗不错的 CPU，可以考虑同时启动两个 KataGo 进程，一个走 OpenVINO 后端，另一个走 eigen CPU 后端，在 GUI 里加载两个引擎。这样核显和 CPU 都在工作，分析多个候选点时速度加倍。操作上就是把 GUI 的引擎配置里加两条启动命令，分别指向两个不同后端的 katago 可执行文件和对应配置。类似的做法也适用于同时有 A 卡和核显的机器，不过进程多了以后显存和内存要提前算好余量。

6. 实测数据与排坑记录：别人不会告诉你的细节

6.1 三套环境的简单对比

我在自己的几台机器上跑过同一份 b18 权重、同一份配置，跨环境对比趋势大概是这样（相对速度倍数，以 CPU eigen 版为 1）：

这些数字受驱动版本、内存频率、功耗策略影响很大，参考趋势即可。真正判断提升是否到位，一定以你自己机器上的 benchmark 输出为准。我见过有人在核显上只提升了一倍还不到，最后发现是 BIOS 里核显被降频了，不是 OpenVINO 的锅。

6.2 典型报错排查表

6.3 我的实操心得：先把参数跑顺，再谈权重升级

ROCm 和 OpenVINO 后端提速逻辑并不复杂，真正磨人的是环境差异。驱动版本换一个，可能同样的配置跑出来的数据就完全不同。所以我的习惯是固定一套主机的驱动组合，跑通 b18 权重后先把 benchmark 数据记下来，之后再调 batch 和线程数。

最后再分享一个小套路：如果你一次要分析大量棋谱，不要把所有任务都丢给一个 KataGo 进程。在硬件资源允许的情况下，用 CPU 后端加 GPU 后端并行处理不同棋谱，比单进程排队硬等要快得多。类似地，命令行模式下可以写个简单脚本把棋谱分批派给多个 katago 实例，GPU 占满的同时 CPU 搜索线程也不浪费。先把 b18 跑稳，再根据实测数据决定是否上更高强度的权重，这是我在 A 卡和核显上完成 KataGo 提速的最实在的经验。