1. openrig 到底要解决什么问题1.1 我为什么攒这台机器先说一个背景。我工作里常年要跑开发环境、容器、本地模型推理还要偶尔做内容渲染。以前我用的是公司配的笔记本性能捉襟见肘跑一个稍大的模型就得依赖远程服务器。但远程服务器有配额、有排队、有网络波动每次调试都很折腾。后来家里添了一台旧台式机配置是五年前的内存只有16G跑什么都不顺手。于是我萌生了一个念头自己从零搭一套“完全听我指挥”的本地工作站并且把整套方案开源出去叫它openrig。其实“rig”这个词在英文里就是“装备、机器”的意思游戏圈常说 gaming rig硬件圈也用它指代一台攒好的主机。我起名 openrig就是想强调两件事第一整个方案是开放的硬件选型、系统配置、部署脚本全部公开第二这套东西不是一次性作品它是一套可以复刻、可以扩展、可以长期维护的“基底装备”。如果你也需要一台能干活、能折腾、能跑AI实验的个人工作站这篇文章就是给你参考的。这篇文章不是装机评测也不是硬件广告。它是一个完整项目的复盘从需求拆解、硬件选型到系统初始化、应用部署再到持续几个月的稳定性验证和踩坑修复。我会把每一步的关键判断和原因写清楚包括那些“抄作业时最容易翻车”的细节。无论你是想照着一模一样攒一台还是想借鉴其中的思路去搭自己的装备都能从中拿到可以直接用的东西。1.2 设计目标开源、模块化、可复制动手之前我给自己定了三条硬性原则这三条原则也是 openrig 这个项目的核心约束。第一条硬件可替换、接口不绑定。我不会为了追求某一家的生态去买封闭配件所有核心部件尽量选标准接口PCIe、M.2、DDR5、ATX电源。这样未来升级某个部件时不用把整台机器推翻重来。比如显卡可以换、存储可以加、内存可以扩而主板、电源、机箱这些“骨架”不用动。第二条系统配置代码化、可复现。我不希望花三天手工配好一台机器然后换块硬盘就得重来一遍。所以从驱动的安装、基础软件的部署到内核参数的调整全部写成了初始化脚本。脚本放在公开仓库里任何人在一台新机器上跑一遍就能得到一个和 openrig 标准环境一致的系统。这也是“open”的另一种含义配置开放过程可复刻。第三条兼顾“日常干活”和“实验折腾”。这台机器不仅是玩具它要承担真实的生产任务比如编译代码、跑 Docker 容器、做本地推理、偶尔剪视频。所以稳定性优先级很高我不会为了跑分好看去超频也不会装一堆随时可能冲突的“实验性软件”。整个环境以稳定为主实验类的东西全部放进容器或虚拟环境里隔离。这三条原则也决定了后面所有选型和部署的走向。接下来我先说硬件选型因为这是整套东西的地基也是很多人最容易上头的地方。2. 硬件选型不堆顶配堆扩展性和稳定2.1 关于 CPU 和主板的选择我选择的平台是 AMD 的 AM5 平台CPU 用的是锐龙 7 77008核16线程。为什么不选更贵的 7950X 或者 Intel 的 i9原因很简单这台机器的瓶颈不太可能在 CPU 上而 CPU 省下来的预算可以花在存储和显卡上。我的日常负载大致分三类编译代码多核吃紧、容器运行内存和IO吃紧、AI推理显卡和显存吃紧。8核16线程对付这些任务已经绰绰有余。另外AM5 平台有一个我非常看重的点插槽生命周期长将来想升级到下一代 Zen 架构 CPU大概率不用换主板。这是模块化原则的体现——我宁可现在用一个“够用”的 CPU也要给自己留一条便宜的升级路径。主板我选的是 B650 芯片组的中端型号带三个 M.2 插槽和两条 PCIe x16 插槽。B650 和更高端的 X670 相比主要区别在扩展通道和 USB 接口数量但对我这种“一台主机若干外设”的场景B650 完全够用。这里有一个很容易被忽略的点主板上的 M.2 插槽数量直接决定了后续扩容成本因为很多机箱内部走线很麻烦能多一个插槽比换主板省事得多。我实际用下来三个 M.2 插槽分别装了系统盘、数据盘和模型缓存盘非常从容。2.2 存储、电源和机箱散热存储这块我踩过很大的坑后来形成了一套固定搭配系统盘500G PCIe 4.0 NVMe专门放操作系统和常用软件。容量不需要太大但随机读写性能要好因为系统响应速度和它直接相关。数据盘2T PCIe 4.0 NVMe放代码仓库、数据集、容器镜像。这个盘容量要够因为 Docker 镜像和模型文件都是吃空间大户。模型缓存盘1T 的 PCIe 3.0 盘。这个是我后来加的专门放 Hugging Face 的模型缓存。为什么单独分一块因为模型文件动辄几个 G频繁读写会磨损系统盘而且一旦缓存出问题也不会影响主系统。内存方面我直接上了 64G DDR5。这个决定后来被证明非常明智跑容器集群时内存一紧张系统就会疯狂交换性能断崖式下跌。本地推理时如果模型比较大内存也是缓解显存不足的重要缓冲。所以我的建议是如果预算有限优先保内存容量而不是 CPU 核心数。电源选的 750W 金牌全模组。为什么是 750W我算了一下整机峰值功率CPU 约 100W显卡约 250W主板、风扇、硬盘约 50W加上 20% 的余量750W 是一个合理值。全模组的好处是走线干净机箱风道更通畅日后续加硬盘、换设备也不用换电源。机箱选的是中塔 ATX 机箱前部能装三个 12cm 风扇顶部和尾部各一个排气风扇。散热压力主要来自显卡正压风道对显卡散热更友好。2.3 最终配置清单与预算部件型号关键考虑CPUAMD Ryzen 7 77008核16线程功耗低AM5升级路径好主板B650 中端 ATX3个M.2插槽2条PCIe x16内存64G DDR5 5600大容量优先容器和推理都需要系统盘500G PCIe 4.0 NVMe系统响应快不装大文件数据盘2T PCIe 4.0 NVMe代码、数据集、容器镜像模型缓存盘1T PCIe 3.0 NVMe单独隔离避免核心系统被干扰显卡RTX 4070 12GCUDA 生态成熟12G显存够做中小模型推理电源750W 金牌全模组余量充足全模组走线便利机箱中塔ATX风扇位够多正压风道整套硬件落地大概花了不到一万。这个预算的逻辑是把“顶配CPU”的钱省下来给“显存和内存”实际干活时的体感提升更大。3. 系统初始化openrig 的一键部署脚本3.1 为什么不用现成镜像而是自己写初始化脚本有的朋友可能会问现在 AI 行业那么多现成镜像Ubuntu 装好、装上驱动、拉个容器不就行了确实可以但我不这么干原因有三点第一现成镜像往往为了兼容大量用户装了太多我用不到的服务启动慢、占用资源、还有安全隐患。第二很多镜像的配置是“黑盒”一旦出问题很难排查你根本不知道它动了哪些系统文件。第三openrig 讲究可复现配置过程必须透明、可审计我自己写的脚本能保证每一行改动都有记录。所以我走的是“最小化系统 全量脚本化配置”的路线安装一个纯净的 Ubuntu Server LTS然后用一份初始化脚本把所有事情做完。这样系统干净而且任何人拿到这份脚本都能复现出相同的环境。3.2 驱动、基础工具与内核参数的自动化处理初始化脚本的第一步是装驱动、配基础环境。我用 bash 写了一个多阶段的部署脚本大概伪代码如下#!/usr/bin/env bash set -euo pipefail # 阶段1基础依赖 apt update apt upgrade -y apt install -y build-essential git curl wget \ ca-certificates gnupg lsb-release # 阶段2NVIDIA驱动与CUDA运行库 # 这里不使用发行版自带的旧驱动改用NVIDIA官方仓库 curl -fsSL https://nvidia.github.io/nvidia-driver/gpgkey | gpg --dearmor -o /usr/share/keyrings/nvidia-driver.gpg apt install -y nvidia-driver-535 nvidia-utils-535 # 阶段3Docker与NVIDIA Container Toolkit curl -fsSL https://download.docker.com/linux/ubuntu/gpg | gpg --dearmor -o /usr/share/keyrings/docker.gpg apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin apt install -y nvidia-container-toolkit nvidia-ctk runtime configure --runtimedocker systemctl restart docker # 阶段4常用开发工具 apt install -y python3-pip python3-venv \ tmux htop nvtop tree jq pip3 install --upgrade pip这里面有几个细节值得单独说明。首先是 NVIDIA 驱动。Ubuntu 的默认源里虽然有驱动但版本通常比较旧而深度学习相关的容器经常要求驱动版本不低于某个阈值。所以我用 NVIDIA 官方仓库安装确保驱动版本可控。装完驱动后建议用nvidia-smi验证一下确认 GPU 被系统识别。如果没有正常显示大概率是内核模块没加载需要检查 secure boot 状态或者黑名单配置。然后是 Docker 和 NVIDIA Container Toolkit 的组合。这个组合的意义在于容器里可以直接使用 GPU 资源不需要在容器里再装一遍驱动。nvidia-ctk runtime configure --runtimedocker这一行是把 NVIDIA 运行时注册为 Docker 的默认 runtime这样以后docker run时只要加--gpus all就能把 GPU 映射进容器。再说内核参数。我在脚本最后加了一组/etc/sysctl.d/90-openrig.conf内容大致如下# 打开防火墙相关参数 net.core.default_qdiscfq net.ipv4.tcp_congestion_controlbbr # 关闭IPv6在某些场景的干扰按需开 net.ipv6.conf.all.disable_ipv60 # 增加inotify监听上限容器和编辑器高频使用 fs.inotify.max_user_watches524288 fs.inotify.max_user_instances1024 # 虚拟内存优化减少swap频繁抖动 vm.swappiness10这里面最实用的是fs.inotify.max_user_watches。如果你跑代码编辑器、容器文件同步经常会遇到“inotify watch 耗尽”的报错把这个值调大之后这类问题基本消失。vm.swappiness调低到 10 的意思是只有当内存严重不足时才使用 swap让系统优先把内存用满这对大内存机器很友好。3.3 部署脚本的容错设计断点续跑与日志审计自己写初始化脚本最容易翻车的不是脚本本身而是“跑到一半失败你不知道从哪里继续”。所以我给 openrig 的部署脚本加了两个很笨但很管用的机制分阶段标记和完整日志。每个阶段结束时都会往/var/log/openrig-state里写入一个标记文件比如.stage2-complete。脚本开头会检查这些标记已经完成的阶段直接跳过。这样即使第3阶段失败修复问题后重新跑脚本它不会把前两个阶段推到重来节省大量时间。同时所有输出都tee到/var/log/openrig-deploy.log出问题时直接翻日志不用靠猜。我建议你如果自己改这套脚本也保留这两个机制。一次完整的系统初始化大概要 20-30 分钟失败重新跑一遍的时间成本很高。有状态标记和日志排查问题的体验会完全不一样。4. 应用层落地开发、容器和 AI 实验环境4.1 开发环境和 Docker 的安装匹配系统装好后下一步是搭“干活”的环境。我主要关注三条线Python 开发、容器化部署、AI 实验。Python 环境我一直坚持用venv或conda隔离不直接往系统 Python 里装包。原因很简单系统 Python 被污染之后操作系统级的工具比如 apt 依赖的 Python 脚本很容易被牵连排查起来非常痛苦。所以我创建了一个固定的虚拟环境目录/opt/venvs每个项目用自己的 venvpython3 -m venv /opt/venvs/base source /opt/venvs/base/bin/activate pip install --upgrade pip setuptools wheel pip install numpy pandas scikit-learn jupyterlabAI 实验环境用了两种方式一种是原生的 Python 虚拟环境适合快速写脚本跑实验另一种是 Docker 容器适合跑别人给的、依赖比较复杂的项目。这里有一个配合技巧将本地的 Hugging Face 缓存目录挂载进容器。在docker run时加上-v ~/.cache/huggingface:/root/.cache/huggingface这样模型权重只下载一次不同容器之间可以共享省流量也省时间。一开始我没做这个挂载结果每个容器都把几十个 G 的模型重新下载一遍相当浪费。4.2 本地 AI 推理与模型缓存的经验openrig 定位里有一条重要场景是本地 AI 实验。我的显卡是 RTX 4070 12G这个量级的显存能跑什么实测下来7B 参数的量化模型比如 Q4 量化后的模型完全没问题速度体感很好。13B 参数的低比特量化模型可以跑但上下文稍微长一点就会接近显存上限需要配合 CPU offload。30B 以上模型基本不现实除非做比较狠的量化但推理速度会很不讨喜。这里我积累了两个实操经验。第一个经验是本地推理不要只盯着显存要关注“显存内存”的协同。超过显存的部分会走 CPU offload如果内存带宽不够速度会断崖式下降。所以我自己配了 64G 内存并且把 swap 设置得很保守就是为了让 offload 时内存能顶住。第二个经验是模型缓存的目录规划。我单独分了一块 1T 的盘给 Hugging Face 缓存。这个决策后来帮了大忙有几次我测试各种量化版本缓存膨胀到 200 多 G系统盘和数据盘完全没受影响。如果你打算长期玩本地模型一定一定要给模型缓存单独留空间。5. 实测表现性能、功耗和长期稳定性5.1 压测时最容易暴露的问题系统全部装好之后我做了两轮压测CPU 满载编译和 GPU 满载推理。两轮压测都发现了一些问题下面这几个点非常典型大家在复刻时一定会遇到。第一散热硅脂和风扇曲线是两回事。第一次跑编译任务CPU 温度冲到 90 度风扇声音很大但温度下不来。后来我才发现主板默认的风扇曲线太保守温度升到 80 度时风扇转速还没拉满。我进 BIOS 把风扇策略改成“激进”模式同时重新涂了导热硅脂温度立竿见影。第二GPU 满载时的供电稳定性。显卡满载时如果电源供电不稳轻则掉驱动重则直接黑屏重启。我的 750W 电源在一次长时推理测试中出了一次黑屏排查半天发现是电源的 12V 输出波动偏大。后来换了一条更粗的 CPU/GPU 供电线问题没有再出现过。这就是为什么我在选型时坚持要留 20% 以上余量电源真的不能贪便宜。第三NVMe 高温降速。满载跑数据集训练时系统盘偶尔出现响应变慢。用nvme smart-log一看温度到了 75 度触发了降速保护。后来在主板的 M.2 散热片和机箱风道配合下温度稳定在 60 度左右。对于长时间跑负载的场景关注 NVMe 散热别忽略它。我也整理了压测的主要数据供参考测试项测试方法结果CPU 满载stress-ng --cpu 16跑 30 分钟全核 4.5G 稳定最高温约 85°CGPU 推理本地跑 7B 模型连续推理 30 分钟温度稳定在 70°C功耗 220W 左右内存稳定性memtest86过 4 轮无错误整机功耗日常开发负载平均 120W满载约 380W5.2 远程维护与监控的配置因为是长期运行的机器我不可能每次都坐在它面前操作。openrig 的远程维护方案我选了 SSH 端口转发的思路没有依赖额外的内网穿透服务。日常监控我用了两个工具nvtop看 GPU 状态htop看 CPU 内存。但这两个工具需要人主动去看后来我用了一段简单的 bash 脚本配合 systemd timer每 10 分钟把关键指标写入一个本地文件出问题时直接拉历史数据排查。关键如下# /usr/local/bin/openrig-stats.sh echo $(date) CPU$(top -bn1 | grep Cpu(s) | awk {print $2}) MEM$(free -g | awk /Mem/{print $3}) GPU$(nvidia-smi --query-gpuutilization.gpu,temperature.gpu --formatcsv,noheader) /var/log/openrig-stats.log这个脚本配合 systemd timer 非常简单也非常可靠。我没用那些重量级监控平台因为单机场景用不上反而增加维护成本。还有一件值得做的事配置 SSH 密钥登录关闭密码登录。这一步对任何长期运行的线上机器来说都是基本操作。我在这台机器上只留了一个普通用户作为日常入口不在 root 下跑任何服务。openrig 的所有部署脚本也是用一个专用用户执行的避免误操作把系统搞坏。6. 踩坑记录与 openrig 的扩展方向6.1 三件最容易被忽略的事从项目启动到现在我踩过的坑不算少但有三件如果重新来一遍我会在第一天就做好。第一硬件到手先完整点验再装机。我第一次直接装机结果发现内存不兼容开机点不亮排查了很久。后来才意识到内存和主板的兼容性问题在装机前就能通过官网 QVL 列表避掉。主板厂商官网会列出经过验证的内存型号买之前先查一遍能省大量时间。第二BIOS 版本和默认设置值得先看一眼。很多主板的默认设置其实并不适合你的硬件组合。比如内存默认跑在 DDR5-4800而没有启用 EXPO 内存超频配置实际带宽会差不少。我在 BIOS 里开启 EXPO 之后内存跑到了标称频率编译速度都有可感知的提升。另外如果你要装 Linux建议把 Secure Boot 关闭或处理好签名问题否则 NVIDIA 驱动模块加载会非常麻烦。第三日志和状态目录要尽早规划。我一开始没认真规划日志目录后来发现系统日志、Docker 日志、脚本日志散落在各个地方排查问题时经常要到处找。后来我统一把自定义日志都放在/var/log下并给 Docker daemon 配置了日志轮转控制单个容器日志文件大小。这个习惯让后续排错轻松很多。6.2 后续可以继续做的方向openrig 在我这里已经稳定运行了几个月日常开发、容器、推理都正常。但我也在思考它的扩展方向这里分享几个我觉得值得做的思路第一加入自动化备份。我现在是手动把数据盘的关键目录同步到另一块移动硬盘未来可以写一个定时备份脚本结合 restic 或 rsync 实现增量备份。对于长期运行的机器备份是必须补上的一环。第二做训练节点的编排试验。既然已经有了稳定的本地工作站下一步我计划测试多机协作。openrig 可以作为其中的一个节点通过分布式训练框架把推理或训练任务分散到多台机器上。这个方向对了解生产环境的工作机制很有帮助。第三把 openrig 的配置文档化、模板化。目前初始化脚本是 bash 写死的未来可以整理成通用的配置模板甚至可以支持不同的硬件组合。目标是让“openrig”不仅仅是一台机器而是一套可适配多种硬件环境的开源基线方案。6.3 给想复刻这套方案的人一点建议如果你决定照着 openrig 的思路去搭自己的工作站我的建议是先搞清楚自己最常跑的任务是什么再回头选硬件。如果主要是跑大模型推理预算重心应该放在显卡和显存如果是编译和开发工具链CPU 多核和内存带宽更重要如果只是简单容器体验其实普通主机就能搞定没必要花这个钱。动手操作时别一次性追求“完全体”。我建议分三步走第一步把系统装好、驱动打通、跑通基础的容器第二步把日常开发环境弄舒服比如虚拟环境、常用软件、远程登录第三步再根据自己的高频任务加入 AI 推理、渲染之类的专项能力。每走一步都验证一下稳定性再进入下一步。这样出现问题时定位范围很小不会像一次性装完那样无从下手。我个人在实际操作中最强烈的体会是一台真正好用的机器不是跑分最高的机器而是你随时能控制、出问题能定位、环境能复现的机器。openrig 这个项目对我的价值就是把这些看起来琐碎但很关键的工程细节用一套公开的方式固定了下来。你不需要完全照搬它的配置但如果你能把“可复现、可维护、可扩展”这三个词落实到自己的装备上我觉得这个项目就算起作用了。 
长河君 · 2026/10/15 13:12:36 · 阅读 1.2k openrig：从零搭建可复现的本地AI工作站与容器开发环境
1. openrig 到底要解决什么问题1.1 我为什么攒这台机器先说一个背景。我工作里常年要跑开发环境、容器、本地模型推理还要偶尔做内容渲染。以前我用的是公司配的笔记本性能捉襟见肘跑一个稍大的模型就得依赖远程服务器。但远程服务器有配额、有排队、有网络波动每次调试都很折腾。后来家里添了一台旧台式机配置是五年前的内存只有16G跑什么都不顺手。于是我萌生了一个念头自己从零搭一套“完全听我指挥”的本地工作站并且把整套方案开源出去叫它openrig。其实“rig”这个词在英文里就是“装备、机器”的意思游戏圈常说 gaming rig硬件圈也用它指代一台攒好的主机。我起名 openrig就是想强调两件事第一整个方案是开放的硬件选型、系统配置、部署脚本全部公开第二这套东西不是一次性作品它是一套可以复刻、可以扩展、可以长期维护的“基底装备”。如果你也需要一台能干活、能折腾、能跑AI实验的个人工作站这篇文章就是给你参考的。这篇文章不是装机评测也不是硬件广告。它是一个完整项目的复盘从需求拆解、硬件选型到系统初始化、应用部署再到持续几个月的稳定性验证和踩坑修复。我会把每一步的关键判断和原因写清楚包括那些“抄作业时最容易翻车”的细节。无论你是想照着一模一样攒一台还是想借鉴其中的思路去搭自己的装备都能从中拿到可以直接用的东西。1.2 设计目标开源、模块化、可复制动手之前我给自己定了三条硬性原则这三条原则也是 openrig 这个项目的核心约束。第一条硬件可替换、接口不绑定。我不会为了追求某一家的生态去买封闭配件所有核心部件尽量选标准接口PCIe、M.2、DDR5、ATX电源。这样未来升级某个部件时不用把整台机器推翻重来。比如显卡可以换、存储可以加、内存可以扩而主板、电源、机箱这些“骨架”不用动。第二条系统配置代码化、可复现。我不希望花三天手工配好一台机器然后换块硬盘就得重来一遍。所以从驱动的安装、基础软件的部署到内核参数的调整全部写成了初始化脚本。脚本放在公开仓库里任何人在一台新机器上跑一遍就能得到一个和 openrig 标准环境一致的系统。这也是“open”的另一种含义配置开放过程可复刻。第三条兼顾“日常干活”和“实验折腾”。这台机器不仅是玩具它要承担真实的生产任务比如编译代码、跑 Docker 容器、做本地推理、偶尔剪视频。所以稳定性优先级很高我不会为了跑分好看去超频也不会装一堆随时可能冲突的“实验性软件”。整个环境以稳定为主实验类的东西全部放进容器或虚拟环境里隔离。这三条原则也决定了后面所有选型和部署的走向。接下来我先说硬件选型因为这是整套东西的地基也是很多人最容易上头的地方。2. 硬件选型不堆顶配堆扩展性和稳定2.1 关于 CPU 和主板的选择我选择的平台是 AMD 的 AM5 平台CPU 用的是锐龙 7 77008核16线程。为什么不选更贵的 7950X 或者 Intel 的 i9原因很简单这台机器的瓶颈不太可能在 CPU 上而 CPU 省下来的预算可以花在存储和显卡上。我的日常负载大致分三类编译代码多核吃紧、容器运行内存和IO吃紧、AI推理显卡和显存吃紧。8核16线程对付这些任务已经绰绰有余。另外AM5 平台有一个我非常看重的点插槽生命周期长将来想升级到下一代 Zen 架构 CPU大概率不用换主板。这是模块化原则的体现——我宁可现在用一个“够用”的 CPU也要给自己留一条便宜的升级路径。主板我选的是 B650 芯片组的中端型号带三个 M.2 插槽和两条 PCIe x16 插槽。B650 和更高端的 X670 相比主要区别在扩展通道和 USB 接口数量但对我这种“一台主机若干外设”的场景B650 完全够用。这里有一个很容易被忽略的点主板上的 M.2 插槽数量直接决定了后续扩容成本因为很多机箱内部走线很麻烦能多一个插槽比换主板省事得多。我实际用下来三个 M.2 插槽分别装了系统盘、数据盘和模型缓存盘非常从容。2.2 存储、电源和机箱散热存储这块我踩过很大的坑后来形成了一套固定搭配系统盘500G PCIe 4.0 NVMe专门放操作系统和常用软件。容量不需要太大但随机读写性能要好因为系统响应速度和它直接相关。数据盘2T PCIe 4.0 NVMe放代码仓库、数据集、容器镜像。这个盘容量要够因为 Docker 镜像和模型文件都是吃空间大户。模型缓存盘1T 的 PCIe 3.0 盘。这个是我后来加的专门放 Hugging Face 的模型缓存。为什么单独分一块因为模型文件动辄几个 G频繁读写会磨损系统盘而且一旦缓存出问题也不会影响主系统。内存方面我直接上了 64G DDR5。这个决定后来被证明非常明智跑容器集群时内存一紧张系统就会疯狂交换性能断崖式下跌。本地推理时如果模型比较大内存也是缓解显存不足的重要缓冲。所以我的建议是如果预算有限优先保内存容量而不是 CPU 核心数。电源选的 750W 金牌全模组。为什么是 750W我算了一下整机峰值功率CPU 约 100W显卡约 250W主板、风扇、硬盘约 50W加上 20% 的余量750W 是一个合理值。全模组的好处是走线干净机箱风道更通畅日后续加硬盘、换设备也不用换电源。机箱选的是中塔 ATX 机箱前部能装三个 12cm 风扇顶部和尾部各一个排气风扇。散热压力主要来自显卡正压风道对显卡散热更友好。2.3 最终配置清单与预算部件型号关键考虑CPUAMD Ryzen 7 77008核16线程功耗低AM5升级路径好主板B650 中端 ATX3个M.2插槽2条PCIe x16内存64G DDR5 5600大容量优先容器和推理都需要系统盘500G PCIe 4.0 NVMe系统响应快不装大文件数据盘2T PCIe 4.0 NVMe代码、数据集、容器镜像模型缓存盘1T PCIe 3.0 NVMe单独隔离避免核心系统被干扰显卡RTX 4070 12GCUDA 生态成熟12G显存够做中小模型推理电源750W 金牌全模组余量充足全模组走线便利机箱中塔ATX风扇位够多正压风道整套硬件落地大概花了不到一万。这个预算的逻辑是把“顶配CPU”的钱省下来给“显存和内存”实际干活时的体感提升更大。3. 系统初始化openrig 的一键部署脚本3.1 为什么不用现成镜像而是自己写初始化脚本有的朋友可能会问现在 AI 行业那么多现成镜像Ubuntu 装好、装上驱动、拉个容器不就行了确实可以但我不这么干原因有三点第一现成镜像往往为了兼容大量用户装了太多我用不到的服务启动慢、占用资源、还有安全隐患。第二很多镜像的配置是“黑盒”一旦出问题很难排查你根本不知道它动了哪些系统文件。第三openrig 讲究可复现配置过程必须透明、可审计我自己写的脚本能保证每一行改动都有记录。所以我走的是“最小化系统 全量脚本化配置”的路线安装一个纯净的 Ubuntu Server LTS然后用一份初始化脚本把所有事情做完。这样系统干净而且任何人拿到这份脚本都能复现出相同的环境。3.2 驱动、基础工具与内核参数的自动化处理初始化脚本的第一步是装驱动、配基础环境。我用 bash 写了一个多阶段的部署脚本大概伪代码如下#!/usr/bin/env bash set -euo pipefail # 阶段1基础依赖 apt update apt upgrade -y apt install -y build-essential git curl wget \ ca-certificates gnupg lsb-release # 阶段2NVIDIA驱动与CUDA运行库 # 这里不使用发行版自带的旧驱动改用NVIDIA官方仓库 curl -fsSL https://nvidia.github.io/nvidia-driver/gpgkey | gpg --dearmor -o /usr/share/keyrings/nvidia-driver.gpg apt install -y nvidia-driver-535 nvidia-utils-535 # 阶段3Docker与NVIDIA Container Toolkit curl -fsSL https://download.docker.com/linux/ubuntu/gpg | gpg --dearmor -o /usr/share/keyrings/docker.gpg apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin apt install -y nvidia-container-toolkit nvidia-ctk runtime configure --runtimedocker systemctl restart docker # 阶段4常用开发工具 apt install -y python3-pip python3-venv \ tmux htop nvtop tree jq pip3 install --upgrade pip这里面有几个细节值得单独说明。首先是 NVIDIA 驱动。Ubuntu 的默认源里虽然有驱动但版本通常比较旧而深度学习相关的容器经常要求驱动版本不低于某个阈值。所以我用 NVIDIA 官方仓库安装确保驱动版本可控。装完驱动后建议用nvidia-smi验证一下确认 GPU 被系统识别。如果没有正常显示大概率是内核模块没加载需要检查 secure boot 状态或者黑名单配置。然后是 Docker 和 NVIDIA Container Toolkit 的组合。这个组合的意义在于容器里可以直接使用 GPU 资源不需要在容器里再装一遍驱动。nvidia-ctk runtime configure --runtimedocker这一行是把 NVIDIA 运行时注册为 Docker 的默认 runtime这样以后docker run时只要加--gpus all就能把 GPU 映射进容器。再说内核参数。我在脚本最后加了一组/etc/sysctl.d/90-openrig.conf内容大致如下# 打开防火墙相关参数 net.core.default_qdiscfq net.ipv4.tcp_congestion_controlbbr # 关闭IPv6在某些场景的干扰按需开 net.ipv6.conf.all.disable_ipv60 # 增加inotify监听上限容器和编辑器高频使用 fs.inotify.max_user_watches524288 fs.inotify.max_user_instances1024 # 虚拟内存优化减少swap频繁抖动 vm.swappiness10这里面最实用的是fs.inotify.max_user_watches。如果你跑代码编辑器、容器文件同步经常会遇到“inotify watch 耗尽”的报错把这个值调大之后这类问题基本消失。vm.swappiness调低到 10 的意思是只有当内存严重不足时才使用 swap让系统优先把内存用满这对大内存机器很友好。3.3 部署脚本的容错设计断点续跑与日志审计自己写初始化脚本最容易翻车的不是脚本本身而是“跑到一半失败你不知道从哪里继续”。所以我给 openrig 的部署脚本加了两个很笨但很管用的机制分阶段标记和完整日志。每个阶段结束时都会往/var/log/openrig-state里写入一个标记文件比如.stage2-complete。脚本开头会检查这些标记已经完成的阶段直接跳过。这样即使第3阶段失败修复问题后重新跑脚本它不会把前两个阶段推到重来节省大量时间。同时所有输出都tee到/var/log/openrig-deploy.log出问题时直接翻日志不用靠猜。我建议你如果自己改这套脚本也保留这两个机制。一次完整的系统初始化大概要 20-30 分钟失败重新跑一遍的时间成本很高。有状态标记和日志排查问题的体验会完全不一样。4. 应用层落地开发、容器和 AI 实验环境4.1 开发环境和 Docker 的安装匹配系统装好后下一步是搭“干活”的环境。我主要关注三条线Python 开发、容器化部署、AI 实验。Python 环境我一直坚持用venv或conda隔离不直接往系统 Python 里装包。原因很简单系统 Python 被污染之后操作系统级的工具比如 apt 依赖的 Python 脚本很容易被牵连排查起来非常痛苦。所以我创建了一个固定的虚拟环境目录/opt/venvs每个项目用自己的 venvpython3 -m venv /opt/venvs/base source /opt/venvs/base/bin/activate pip install --upgrade pip setuptools wheel pip install numpy pandas scikit-learn jupyterlabAI 实验环境用了两种方式一种是原生的 Python 虚拟环境适合快速写脚本跑实验另一种是 Docker 容器适合跑别人给的、依赖比较复杂的项目。这里有一个配合技巧将本地的 Hugging Face 缓存目录挂载进容器。在docker run时加上-v ~/.cache/huggingface:/root/.cache/huggingface这样模型权重只下载一次不同容器之间可以共享省流量也省时间。一开始我没做这个挂载结果每个容器都把几十个 G 的模型重新下载一遍相当浪费。4.2 本地 AI 推理与模型缓存的经验openrig 定位里有一条重要场景是本地 AI 实验。我的显卡是 RTX 4070 12G这个量级的显存能跑什么实测下来7B 参数的量化模型比如 Q4 量化后的模型完全没问题速度体感很好。13B 参数的低比特量化模型可以跑但上下文稍微长一点就会接近显存上限需要配合 CPU offload。30B 以上模型基本不现实除非做比较狠的量化但推理速度会很不讨喜。这里我积累了两个实操经验。第一个经验是本地推理不要只盯着显存要关注“显存内存”的协同。超过显存的部分会走 CPU offload如果内存带宽不够速度会断崖式下降。所以我自己配了 64G 内存并且把 swap 设置得很保守就是为了让 offload 时内存能顶住。第二个经验是模型缓存的目录规划。我单独分了一块 1T 的盘给 Hugging Face 缓存。这个决策后来帮了大忙有几次我测试各种量化版本缓存膨胀到 200 多 G系统盘和数据盘完全没受影响。如果你打算长期玩本地模型一定一定要给模型缓存单独留空间。5. 实测表现性能、功耗和长期稳定性5.1 压测时最容易暴露的问题系统全部装好之后我做了两轮压测CPU 满载编译和 GPU 满载推理。两轮压测都发现了一些问题下面这几个点非常典型大家在复刻时一定会遇到。第一散热硅脂和风扇曲线是两回事。第一次跑编译任务CPU 温度冲到 90 度风扇声音很大但温度下不来。后来我才发现主板默认的风扇曲线太保守温度升到 80 度时风扇转速还没拉满。我进 BIOS 把风扇策略改成“激进”模式同时重新涂了导热硅脂温度立竿见影。第二GPU 满载时的供电稳定性。显卡满载时如果电源供电不稳轻则掉驱动重则直接黑屏重启。我的 750W 电源在一次长时推理测试中出了一次黑屏排查半天发现是电源的 12V 输出波动偏大。后来换了一条更粗的 CPU/GPU 供电线问题没有再出现过。这就是为什么我在选型时坚持要留 20% 以上余量电源真的不能贪便宜。第三NVMe 高温降速。满载跑数据集训练时系统盘偶尔出现响应变慢。用nvme smart-log一看温度到了 75 度触发了降速保护。后来在主板的 M.2 散热片和机箱风道配合下温度稳定在 60 度左右。对于长时间跑负载的场景关注 NVMe 散热别忽略它。我也整理了压测的主要数据供参考测试项测试方法结果CPU 满载stress-ng --cpu 16跑 30 分钟全核 4.5G 稳定最高温约 85°CGPU 推理本地跑 7B 模型连续推理 30 分钟温度稳定在 70°C功耗 220W 左右内存稳定性memtest86过 4 轮无错误整机功耗日常开发负载平均 120W满载约 380W5.2 远程维护与监控的配置因为是长期运行的机器我不可能每次都坐在它面前操作。openrig 的远程维护方案我选了 SSH 端口转发的思路没有依赖额外的内网穿透服务。日常监控我用了两个工具nvtop看 GPU 状态htop看 CPU 内存。但这两个工具需要人主动去看后来我用了一段简单的 bash 脚本配合 systemd timer每 10 分钟把关键指标写入一个本地文件出问题时直接拉历史数据排查。关键如下# /usr/local/bin/openrig-stats.sh echo $(date) CPU$(top -bn1 | grep Cpu(s) | awk {print $2}) MEM$(free -g | awk /Mem/{print $3}) GPU$(nvidia-smi --query-gpuutilization.gpu,temperature.gpu --formatcsv,noheader) /var/log/openrig-stats.log这个脚本配合 systemd timer 非常简单也非常可靠。我没用那些重量级监控平台因为单机场景用不上反而增加维护成本。还有一件值得做的事配置 SSH 密钥登录关闭密码登录。这一步对任何长期运行的线上机器来说都是基本操作。我在这台机器上只留了一个普通用户作为日常入口不在 root 下跑任何服务。openrig 的所有部署脚本也是用一个专用用户执行的避免误操作把系统搞坏。6. 踩坑记录与 openrig 的扩展方向6.1 三件最容易被忽略的事从项目启动到现在我踩过的坑不算少但有三件如果重新来一遍我会在第一天就做好。第一硬件到手先完整点验再装机。我第一次直接装机结果发现内存不兼容开机点不亮排查了很久。后来才意识到内存和主板的兼容性问题在装机前就能通过官网 QVL 列表避掉。主板厂商官网会列出经过验证的内存型号买之前先查一遍能省大量时间。第二BIOS 版本和默认设置值得先看一眼。很多主板的默认设置其实并不适合你的硬件组合。比如内存默认跑在 DDR5-4800而没有启用 EXPO 内存超频配置实际带宽会差不少。我在 BIOS 里开启 EXPO 之后内存跑到了标称频率编译速度都有可感知的提升。另外如果你要装 Linux建议把 Secure Boot 关闭或处理好签名问题否则 NVIDIA 驱动模块加载会非常麻烦。第三日志和状态目录要尽早规划。我一开始没认真规划日志目录后来发现系统日志、Docker 日志、脚本日志散落在各个地方排查问题时经常要到处找。后来我统一把自定义日志都放在/var/log下并给 Docker daemon 配置了日志轮转控制单个容器日志文件大小。这个习惯让后续排错轻松很多。6.2 后续可以继续做的方向openrig 在我这里已经稳定运行了几个月日常开发、容器、推理都正常。但我也在思考它的扩展方向这里分享几个我觉得值得做的思路第一加入自动化备份。我现在是手动把数据盘的关键目录同步到另一块移动硬盘未来可以写一个定时备份脚本结合 restic 或 rsync 实现增量备份。对于长期运行的机器备份是必须补上的一环。第二做训练节点的编排试验。既然已经有了稳定的本地工作站下一步我计划测试多机协作。openrig 可以作为其中的一个节点通过分布式训练框架把推理或训练任务分散到多台机器上。这个方向对了解生产环境的工作机制很有帮助。第三把 openrig 的配置文档化、模板化。目前初始化脚本是 bash 写死的未来可以整理成通用的配置模板甚至可以支持不同的硬件组合。目标是让“openrig”不仅仅是一台机器而是一套可适配多种硬件环境的开源基线方案。6.3 给想复刻这套方案的人一点建议如果你决定照着 openrig 的思路去搭自己的工作站我的建议是先搞清楚自己最常跑的任务是什么再回头选硬件。如果主要是跑大模型推理预算重心应该放在显卡和显存如果是编译和开发工具链CPU 多核和内存带宽更重要如果只是简单容器体验其实普通主机就能搞定没必要花这个钱。动手操作时别一次性追求“完全体”。我建议分三步走第一步把系统装好、驱动打通、跑通基础的容器第二步把日常开发环境弄舒服比如虚拟环境、常用软件、远程登录第三步再根据自己的高频任务加入 AI 推理、渲染之类的专项能力。每走一步都验证一下稳定性再进入下一步。这样出现问题时定位范围很小不会像一次性装完那样无从下手。我个人在实际操作中最强烈的体会是一台真正好用的机器不是跑分最高的机器而是你随时能控制、出问题能定位、环境能复现的机器。openrig 这个项目对我的价值就是把这些看起来琐碎但很关键的工程细节用一套公开的方式固定了下来。你不需要完全照搬它的配置但如果你能把“可复现、可维护、可扩展”这三个词落实到自己的装备上我觉得这个项目就算起作用了。