2026-07-07上周在公司收到一台 AMD Ryzen AI Halo Dev Kit。箱子不大白色包装打开之后是一块 ITX 大小的主板上面焊着那颗传说中的 APU——CPU 加 AI 加速单元官方标称 INT8 算力 96 TOPS。价格四千美元对比 NVIDIA 同等规格的 DGX Spark 差不多便宜了一半。硬件参数确实亮眼。128GB 统一内存和 Apple Silicon 一样的思路——CPU 和 GPU 共享内存池不用手动搬数据。我把它接上显示器、插好电源开机进 Ubuntu 24.04。系统正常启动硬件识别没问题。然后我打开了 AMD 官方文档准备安装 ROCm。接下来三个小时这台机器再也没跑起来一个训练脚本。AMD 官方的 ROCm 安装说明写得还算清楚——三步走添加 AMD 仓库、安装 rocm-hip-libraries、装 PyTorch ROCm 版。第一步就出了问题。apt update 的时候报 GPG key 过期手动更新 keyring 之后依赖解析花了四分钟——系统提示 libc-dev 版本冲突需要从 18 降级到 15。降级意味着 clang 工具链要跟着降而系统自带的 llvm 是 17和 libc-dev 15 的 ABI 不完全兼容。我当时的判断很直接——肯定是系统版本不匹配。官方文档基于 Ubuntu 22.04 LTS我用的是 24.04包版本差了两年。换系统。重装 Ubuntu 22.04 LTS从头来一遍。但是同样的错误又出现了。22.04 自带的 libc-dev 是 14ROCm 需要的还是 15——一个不大不小的版本差官方仓库没有这个精确匹配的包。我查了下 GitHub Issues发现这个冲突早在 ROCm 5.6 时就有人报过到 ROCm 6.1 仍然存在。不是系统问题是 AMD 的依赖锁定策略和主流 Ubuntu LTS 的包管理节奏没对齐。当时我在显示器前坐了一会儿。机器风扇很安静——因为没有负载驱动还没装好。四千美元的盒子开机一小时了连个矩阵乘法都跑不起来。接下来我试了三条路。第一条Docker 隔离。AMD 官方提供了 ROCm Docker 镜像理论上里面预装了所有依赖直接 pull 就能用。我拉下来跑 rocm-smi——正常。跑 python3 -c import torch; print(torch.cuda.is_available())——False。排查了半天发现是容器缺少 /dev/kfd 和 /dev/dri 的设备映射权限。即使加了 --device/dev/kfd --device/dev/dri --group-addvideo容器内的用户组 ID 和主机的 render 组 ID 对不上。这不是文档没写的问题而是不同发行版之间 group ID 分配策略本来就不统一Docker 层没法自动处理。第二条社区版 ROCm。有个叫 rocm-sdk-lite 的第三方构建脚本把 AMD 的闭源组件替换成开源替代。编译花了一个小时跑通了基础测试。但心理上不太踏实——生产环境用社区分支跑 AI 训练出了问题找谁第三条退回官方推荐的路线但逐个手动安装每个依赖包跳过 apt 的自动依赖解析。成功装上了 ROCm 6.1 base runtimePyTorch ROCm 版也能跑 tensor.cuda() 了。代价是这台机器的包管理状态完全不可复现——如果同样的步骤在另一台机器上做一遍依赖版本一不同就很可能失败。折腾了一圈我选了混合方案。日常快速验证用 ROCm 加上社区驱动的修补生产训练仍然接回 NVIDIA 集群。AMD Dev Kit 不是不能用但谈不上替代。跑了一周之后发现了另一个问题。PyTorch ROCm 的发布节奏比 CUDA 版慢两到三个月。七月初 CUDA 版已经到 2.5.0ROCm 版的 nightly build 还在 2.4.x。这意味着社区贡献的最新模型、最新的 attention 优化ROCm 用户总是要等一个多季度才能用上。同时 MIOpenAMD 的卷积优化库在某些 kernel size 为 3x3 且 stride 为 2 的配置下性能只有同等 CUDA 配置的 60%。官方文档里没有提到这个退化——实测发现的。现在回头看AMD 的硬件进步是看得见的。96 TOPS 的 AI 算力、128GB 统一内存、四千美元的定价在纸面上确实够到了平替的门槛。但驱动安装和软件生态的差距不是靠硬件迭代就能追上的。CUDA 积累的十几年社区贡献、Docker 镜像、框架集成、调试工具——这些才是 NVIDIA 真正的护城河而不止是 GPU 跑得快一点。关于维基框架维基框架Wiki Framework是一套面向复杂业务场景的轻量级开发框架支持多语言、多协议、多部署形态。适用于企业级应用开发、微服务架构、云原生部署等场景。官网framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版
2026-07-07上周在公司收到一台 AMD Ryzen AI Halo Dev Kit。箱子不大白色包装打开之后是一块 ITX 大小的主板上面焊着那颗传说中的 APU——CPU 加 AI 加速单元官方标称 INT8 算力 96 TOPS。价格四千美元对比 NVIDIA 同等规格的 DGX Spark 差不多便宜了一半。硬件参数确实亮眼。128GB 统一内存和 Apple Silicon 一样的思路——CPU 和 GPU 共享内存池不用手动搬数据。我把它接上显示器、插好电源开机进 Ubuntu 24.04。系统正常启动硬件识别没问题。然后我打开了 AMD 官方文档准备安装 ROCm。接下来三个小时这台机器再也没跑起来一个训练脚本。AMD 官方的 ROCm 安装说明写得还算清楚——三步走添加 AMD 仓库、安装 rocm-hip-libraries、装 PyTorch ROCm 版。第一步就出了问题。apt update 的时候报 GPG key 过期手动更新 keyring 之后依赖解析花了四分钟——系统提示 libc-dev 版本冲突需要从 18 降级到 15。降级意味着 clang 工具链要跟着降而系统自带的 llvm 是 17和 libc-dev 15 的 ABI 不完全兼容。我当时的判断很直接——肯定是系统版本不匹配。官方文档基于 Ubuntu 22.04 LTS我用的是 24.04包版本差了两年。换系统。重装 Ubuntu 22.04 LTS从头来一遍。但是同样的错误又出现了。22.04 自带的 libc-dev 是 14ROCm 需要的还是 15——一个不大不小的版本差官方仓库没有这个精确匹配的包。我查了下 GitHub Issues发现这个冲突早在 ROCm 5.6 时就有人报过到 ROCm 6.1 仍然存在。不是系统问题是 AMD 的依赖锁定策略和主流 Ubuntu LTS 的包管理节奏没对齐。当时我在显示器前坐了一会儿。机器风扇很安静——因为没有负载驱动还没装好。四千美元的盒子开机一小时了连个矩阵乘法都跑不起来。接下来我试了三条路。第一条Docker 隔离。AMD 官方提供了 ROCm Docker 镜像理论上里面预装了所有依赖直接 pull 就能用。我拉下来跑 rocm-smi——正常。跑 python3 -c import torch; print(torch.cuda.is_available())——False。排查了半天发现是容器缺少 /dev/kfd 和 /dev/dri 的设备映射权限。即使加了 --device/dev/kfd --device/dev/dri --group-addvideo容器内的用户组 ID 和主机的 render 组 ID 对不上。这不是文档没写的问题而是不同发行版之间 group ID 分配策略本来就不统一Docker 层没法自动处理。第二条社区版 ROCm。有个叫 rocm-sdk-lite 的第三方构建脚本把 AMD 的闭源组件替换成开源替代。编译花了一个小时跑通了基础测试。但心理上不太踏实——生产环境用社区分支跑 AI 训练出了问题找谁第三条退回官方推荐的路线但逐个手动安装每个依赖包跳过 apt 的自动依赖解析。成功装上了 ROCm 6.1 base runtimePyTorch ROCm 版也能跑 tensor.cuda() 了。代价是这台机器的包管理状态完全不可复现——如果同样的步骤在另一台机器上做一遍依赖版本一不同就很可能失败。折腾了一圈我选了混合方案。日常快速验证用 ROCm 加上社区驱动的修补生产训练仍然接回 NVIDIA 集群。AMD Dev Kit 不是不能用但谈不上替代。跑了一周之后发现了另一个问题。PyTorch ROCm 的发布节奏比 CUDA 版慢两到三个月。七月初 CUDA 版已经到 2.5.0ROCm 版的 nightly build 还在 2.4.x。这意味着社区贡献的最新模型、最新的 attention 优化ROCm 用户总是要等一个多季度才能用上。同时 MIOpenAMD 的卷积优化库在某些 kernel size 为 3x3 且 stride 为 2 的配置下性能只有同等 CUDA 配置的 60%。官方文档里没有提到这个退化——实测发现的。现在回头看AMD 的硬件进步是看得见的。96 TOPS 的 AI 算力、128GB 统一内存、四千美元的定价在纸面上确实够到了平替的门槛。但驱动安装和软件生态的差距不是靠硬件迭代就能追上的。CUDA 积累的十几年社区贡献、Docker 镜像、框架集成、调试工具——这些才是 NVIDIA 真正的护城河而不止是 GPU 跑得快一点。关于维基框架维基框架Wiki Framework是一套面向复杂业务场景的轻量级开发框架支持多语言、多协议、多部署形态。适用于企业级应用开发、微服务架构、云原生部署等场景。官网framewiki.comGiteegitee.com/wiki-frameworkGitHubgithub.com/wiki-framework示例项目gitee.com/cdkjframework/framewiki-example 许可证MulanPSL-2.0木兰宽松许可证第2版
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
