上个月开始我发现自己每天盯得最久的不是代码编辑器而是云平台的计费账单。一个普通的多模态对话任务一天跑下来轻轻松松消耗几十块钱如果再加个批量推理和周末的定时任务账单直接变成心跳。后来我把卡点做一个决定把所有推理负载搬到桌面下的机器上自己组一台真正落地的 openrig。所谓 openrig社区里叫法很多有人叫“开放式 AI 算力主机”有人干脆叫“个人 GPU 机架”核心意思都一样把 GPU、主板、电源、机架和开源软件栈组合成一台完全由自己控制的私有算力机对外跑 Ollama、vLLM、ComfyUI 这类本地模型服务。这篇文章不需要你预先懂很多硬件知识我会把从选型到落地、再到排障和算经济账的整套经验讲透。你可能是被云 GPU 账单吓到的独立开发者也可能只是想在家里拥有一台能跑 70B 模型的工作站又或者单纯在观望 openrig 这个词凭什么成为热词——这几类读者都能从下面的内容里拿到可以直接抄作业的东西。1. OpenRig 热潮背后的硬需求从裸显卡机架到个人 AI 工作站openrig 这词并不是凭空冒出来的新概念。早在显卡算力需求旺盛的几年硬件圈里就把那种没有外壳、显卡直接横插在开放式铝架上的多卡机器叫 rig。后来很多 PC 机箱因为散热和体积问题撑不住多卡才衍生出专门的多卡矿架。这两年大众 AI 应用爆发大家重新翻出这套玩法又把“rig”的定位从矿架提升成了真正的个人 AI 工作站。1.1 openrig 到底指什么术语演变与社区共识如果你现在去硬件社区搜 openrig会看到两类内容一类是展示机器外观的装机帖另一类是比较完整的部署笔记。这两类内容共同构成了一个很明显的共识——openrig 不是单一硬件品牌也不是某个指定系统镜像而是一套全部开放、可自我维护的算力方案。“open”主要体现在三个层面。第一硬件形态开放显卡、 CPU、主板、机箱没有绑定你可以按预算换成任意组合甚至直接把显卡竖插在外置 PCIe 扩展坞上。第二软件栈开放底层用 Linux推理层用开源项目调度和监控也全走开源组件不存在某个商业套件把你锁死。第三接口开放一般都会提供 OpenAI 兼容的 API 或 Stable Diffusion WebUI 入口让现有应用可以用很低的成本迁入。早期大家把这种机器称为矿架原因很直白——显卡密集布局裸露。但现在 openrig 的用途已经完全不同。我见过有人拿它跑私有知识库问答有人拿它做深夜批量出图还有人把整台 rig 挂到公司内网给团队提供统一的推理 API。大家愿意继续沿用“rig”这个名词更多是因为它表达了那种“钢铁架子 一堆卡 风扇嗡嗡转”的硬核气质。1.2 本地 AI 算力为什么突然吃香成本与数据两本账先说成本。云端 GPU 的价值在于弹性今天不用就不算钱。但如果你的工作负载是长期存在的情况就会反过来。一个按需 GPU 实例每小时大致几十块钱一周 7 天、每天 8 小时虽然是慷慨假设但跑一个月下来的费用已经足够买一张中高端显卡。更别提很多 AI 任务并不是固定的 8 小时工作制——模型测试、调参、批量推理经常让机器连续几天满负荷。我给出一个粗略对比一台本地双卡 openrig 一次性硬件投入可能在两万上下日常跑 300 瓦到 600 瓦电按民用电价算满载一天不超过十块钱。换成等算力的云端实例同样的使用强度一天的费用大概率超过一百。你用不上两个月本地机器就开始往回赚差价。云厂商还有一个优势是可扩展性但当任务规模相对稳定时本地机器的性价比压倒性胜出。再说数据。本地推理意味着模型权重、输入数据和中间结果全都留在一台自己掌控的机器上不需要经过任何第三方链路。对文档处理、医疗文本、代码仓库分析这类对隐私比较敏感的任务这是说不清但很重要的一层价值。我实际部署时会把模型放在独立的数据盘上配合访问权限限制整个链路清晰可控。单纯冲着这一点就足以让很多团队认真考虑搭一台 openrig。对比维度云端按需实例本地 openrig一次性投入几乎为零8千到几万不等长期运行成本按小时或按卡计费电费 宽带 折旧数据链路经过云侧完全留在本机扩展性一键提升规格加卡或组集群故障控制依赖服务商自己排查处理2. 攒机规划显存优先的选型路线与三档可抄配置OpenRig 和游戏机的攒机思路有明显区别。游戏机讲究的是帧率openrig 讲究的只有一句话模型能不能放进显存。大部分本地推理程序的瓶颈根本不是显卡算力有多猛而是模型和上下文到底塞不塞得下。2.1 核心选型逻辑显存 算力 PCIe 通道大模型推理时模型权重必须常驻显存。一个 70 亿参数的模型用 FP16 精度存储光权重就大约 14GB用 4bit 量化能压到 4GB 左右但这还没算上下文和 KV Cache。我自己实践下来7B 级别的模型在 8GB 显存上已经很勉强想流畅聊天更建议 12GB 起步33B 或 70B 的量化版模型则至少需要 24GB 到 48GB 的显存空间。因此选卡时显存容量第一优先。英伟达的 RTX 3090、4090 都是 24GB 显存性价比高是当前个人 rig 的主流选择预算更高的可以看 RTX 6000 Ada 或 A6000 这类专业卡48GB 显存一步到位。算力反而不是最敏感指标因为推理大多是显存带宽受限而非算力受限。即便如此买新不买旧依然适用更快的显存带宽在长上下文的解码阶段带来的提升非常直观。PCIe 通道倒是容易被忽略。显卡间的数据传输常见场景是模型并行或张量并行。两张卡走 PCIe 4.0 x16 时数据交换还算顺畅但如果主板通道不足把显卡插到 x4 槽大模型的跨卡通信会把速度拖到不可用。所以选主板时我建议直接看这张板子的 PCIe 拆分能力确认每个插槽在插入多卡后仍然保留 x16 或至少 x8 带宽。2.2 主板、电源和形态三者的配合关系主板不只是承载显卡它决定你能扩展几块卡、怎么供电、怎么联网。单双卡场景一块支持 Resizable BAR 和多个 x16 槽的 ATX 主板就够。四卡以上主板的 PCIe 通道很容易不够用这种情况下通常要看工作站主板或者服务器主板配合 PLX 交换芯片或者 AMD 平台的充足通道设计。电源是 openrig 里最容易低估的部件。它的标称功率是持续输出但显卡满载瞬间的峰值功耗能高出标称不少。以双 RTX 3090 为例两张卡满载可达 700W再算上 CPU、主板、风扇整机瞬时功耗可能逼近 1000W这时 850W 电源会非常危险至少往上留 30% 余量。我见过多次满载瞬间重启的案例最后基本都是换更大电源或者改成双电源才解决。形态选择上我的建议是一到两张卡用普通机箱完全没问题散热和噪音都更容易管理三张卡及以上才需要考虑开放式机架。开放式机架的优点是把显卡横过来裸露在外方便更换和散热缺点是积灰、噪音大、对摆放环境要求高。如果你准备把机器放进小机柜或者家里的边柜开放式架子还会让理线变得很难看这时候服务器机箱反而可能是更好的选择。形态方案显卡数量优点缺点标准 ATX 机箱1-2安静、整洁、搬动方便高功耗卡散热受限开放式铝架3-6散热直接、扩展灵活积灰、噪音、理线难4U 服务器机箱4-8适合机柜、风道友好体积大、需要专门风扇2.3 三套经过验证的配置参考我分别整理过入门、进阶和高配三档机器配置如下价格只是区间参考不同时间段波动非常大。第一套是入门方案适合跑 7B-14B 模型和 Stable Diffusion 出图。显卡选 RTX 4060 Ti 16GB 或二手 RTX 3060 12GB配合 i5 级别 CPU、32GB 内存、700W 电源和普通 ATX 机箱。整套预算大约七千到一万元。这套机器做本地知识库问答、自动化脚本调用模型以及单张出图都够用关键是安静放在工位旁边没有压迫感。第二套是进阶方案适合想体验 70B 量化模型的人。显卡用两张 RTX 3090 24GBCPU 用 Ryzen 7 或者 i7内存 64GB电源建议两台或单台 1300W 以上机箱直接上开放式支架。整套成本大约两万到两万五。两张 24GB 卡组成 48GB 显存跑 Qwen2.5-32B 的 4bit 量化版本非常流畅跑 70B 模型也能做到可用的速度。第三套是高配方案面向要在本地做较多实验或提供团队服务的场景。两张 4090 24GB 或一张 A6000 48GBCPU、主板、散热全面升级。价格区间五万到八万。这套机器能让 70B 模型不再需要激进量化上下文长度也可以拉长同时还能同时跑图像生成和语音识别等多路服务。除非你确实需要否则我不建议新手一上来就上这个级别。3. 系统底层从 BIOS 到监控把这台机器纳入正规管理买了一堆硬件装起来只是 openrig 的第一步。真正决定使用体验的是底层系统是否稳定、能否远程管理、能否随时看到机器状态。很多人的机器买回来用三天就吃灰往往不是硬件不行而是底子没打好。3.1 BIOS 里必须打开的开关装机完成后先进 BIOS 做三件事。第一是打开 Above 4G Decoding这是多张显卡都能被系统正确识别的前提。第二是打开 Resizable BAR它让 CPU 可以访问全部显存而不是受限访问对推理性能有几%到十几%的提升具体幅度取决于卡和驱动。第三是把 PCIe 链路速度设成最高档避免主板自动协商时降到低带宽。如果主板支持 SR-IOV也可以考虑开启为将来做 GPU 虚拟化或容器穿透留一条路。不开也不影响大多数使用场景。这里我有个实际经验改完 BIOS 后务必用手机拍下最终设置截图存到一个专门文档里。机器出问题时很多故障其实来自 BIOS 某个不起眼的选项被重置手里有原始设置能节省大量排查时间。BIOS 层面的另一个重点是把启动盘设置为 Linux 引导。openrig 的主流系统选择是 Ubuntu Server 或 Debian长期稳定性和驱动兼容性都更好。桌面版虽然界面友好但会吃掉不少内存和磁盘 IO。我用 Ubuntu Server 22.04 至今省心程度远高于当初想象中的折腾。3.2 驱动、固件与开机自动运行的坑显卡驱动是软件栈的根基。NVIDIA 驱动建议通过官方驱动源安装装完以后立刻重启确认nvidia-smi能列出所有卡和驱动版本。特别要提醒的是装驱动时需要同时装上nvidia-persistenced并用 systemd 让它开机常驻。没有这一步一些卡会在空闲时进入低功耗状态等模型加载时出现初始化不稳定甚至找不到设备的情况。驱动装好后建议立刻做一个简单的压力测试用nvidia-smi -pl调整功耗上限然后跑一个稍微大一点的推理任务确认每张卡都能独立工作。这样做能提前发现供电、线材或转接线引起的问题而不是等到重要任务跑不起来时再手忙脚乱。单独一张卡的故障通常是线材没插紧或转接卡接触不良这也是 openrig 里最常见的隐性坑。固件方面的建议是更新主板 BIOS 和网卡固件到厂商正式版。很多人不喜欢动固件但我经历过一次网卡在重启后丢 IP 的情况最后发现是旧固件和 Linux 驱动配合不好。更新以后两周内观察稳定性基本不会再犯同类问题。同时建议在系统里关闭不必要的图形桌面服务省下内存给模型权重和 KV Cache。3.3 远程监控与数据存储的落地方案OpenRig 一旦跑起来通常不会每天接显示器。远程管理需要两条路径一是 SSH 登录二是 Web 监控面板。SSH 配置时建议只保留密钥登录关闭密码登录并限制可登录用户这是最基本的安全底线。监控方面Prometheus 加 Grafana 是社区最成熟的一套方案再另外加上 node_exporter 和 nvidia_gpu_exporter就能把 CPU、内存、GPU 温度、显存占用和功耗全部实时图表化。我实际部署时还加了一层告警当 GPU 显存占用超过 95% 或温度超过 85 度时Grafana 会通过 Webhook 推消息到团队群。这个告警曾帮我及时抓到一次因风扇停转导致的异常升温。故障发生在周末如果没有告警那张卡很可能因为持续高温而永久损伤。数据存储方面模型文件通常很大建议单独挂一块 SSD 或一组磁盘作为模型目录用 NFS 或者 SMB 共享到同一局域网的其他机器。目录结构我习惯这样组织/models /llm # 大语言模型权重如 qwen2.5-32b /diffusion # 图像模型权重如 sd-xl /embedding # 向量模型 /cache # 临时下载目录按照这个结构挂载给容器权限用共享用户组管理既能避免重复下载模型也让多台机器共用一套权重成为可能。针对不需要频繁变动的模型权重我会把磁盘阵列从默认模式切到只读挂载既降低误删风险也减少写盘带来的损耗。4. 软件栈组合让 Ollama、vLLM 和 ComfyUI 在一台机器上共存openrig 真正神奇的地方在于软件组合。一台机器能同时提供大语言模型接口、高并发推理和图像生成能力靠的不是某个单体软件而是一套各司其职的开源工具链。4.1 各软件的分工与典型 Docker Compose 组合我当前的软件栈由四个主要组件组成Ollama、vLLM、ComfyUI 和 Docker Compose。Ollama 负责轻量级本地模型服务和简单的 OpenAI 兼容接口适合聊天和日常调试vLLM 负责高并发或长上下文推理吞吐量更大ComfyUI 负责图像生成和视频生成工作流Docker Compose 把这三个服务串起来提供统一的端口和资源限制。为什么不是只装一个 Ollama因为场景不同。Ollama 胜在开箱即用一条命令就能拉模型并跑起来但它不是为高并发 Web 服务设计的。当我把接口接给团队内部使用多用户同时请求时vLLM 的连续批处理和 PagedAttention 机制能带来几倍于 Ollama 的吞吐提升。ComfyUI 则完全不同它更像一个可视化工作流工具侧重精细控制而不是 API 吞吐。下面是一个精简版 compose 配置骨架我把核心部分贴出来services: ollama: image: ollama/ollama:latest container_name: ollama restart: unless-stopped ports: - 11434:11434 environment: - CUDA_VISIBLE_DEVICES0 volumes: - /models/ollama:/root/.ollama - /models/cache:/models/cache deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu] comfyui: image: comfyui/comfyui:latest container_name: comfyui restart: unless-stopped ports: - 8188:8188 environment: - CUDA_VISIBLE_DEVICES1 volumes: - /models/diffusion:/workspace/models deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu]这个配置的思路很简单让 Ollama 只用 0 号卡ComfyUI 只用 1 号卡彼此之间不抢占显存。在两卡机器上这个隔离策略比动态共享更容易预期和维护。4.2 显存争夺战多模型并发时的分配策略显存分配是 openrig 运维里最常遇到的问题。Ollama 默认会尽可能加载更多模型导致显存很快被占满后续加载的模型被挤出去。如果机器上还要同时跑 ComfyUI显存矛盾会更加明显。解决思路首先是给每个服务指定明确的 GPU其次是通过环境变量限制模型的并发加载数量。对于 Ollama核心参数是OLLAMA_MAX_LOADED_MODELS和OLLAMA_KEEP_ALIVE。前者限制同时驻留显存的模型数量我一般设为 1确保同一时间只保留一个模型后者控制模型在请求结束后的驻留时间默认 5 分钟够用除非你高频请求同一个模型可以适当延长。否则切换模型时的显存换入换出会非常频繁反而让响应变慢。vLLM 侧启动时要显式设置显存利用率。--gpu-memory-utilization 0.85表示让 vLLM 使用单卡 85% 的显存剩下给其他系统和临时工具留余地。--max-model-len也要控制如果设置太长KV Cache 会预先占用大量显存可能导致模型启动直接被 OOM 终止。经验法则先设成一个偏小的值比如 8192跑通后再逐步拉长确认对显存的影响。关于多卡并行NVIDIA 机器上常用CUDA_VISIBLE_DEVICES配合tensor-parallel-size实现跨卡加速。两张 24GB 卡组成 48GB 显存池来跑 70B 量化模型时tensor-parallel-size 设为 2模型权重会均匀分布在两张卡上但通信开销也会比较高。我的建议是只有显存容量确实不够时再启用 tensor parallel否则优先考虑单卡推理省掉通信损耗延迟表现更稳定。4.3 调优响应速度从量化到 NVLink 的实测方向调优 openrig 的响应速度第一刀永远是模型量化。同一模型在 FP16 和 4bit 量化下的显存占用差了好几倍。显存够时应优先保证模型精度和上下文长度显存不够时量化反而能换来更快的速度。以我在 3090 上跑 32B 模型为例Q4_K_M 量化版本生成速度大约在每秒二十到四十个 token 之间如果强行跑 FP16绝大多数情况下会直接因显存不足而失败。第二刀是系统层面的参数。检查 BIOS 有没有开启 Resizable BAR确认后验证nvidia-smi里的 BAR1 大小是否正常。对于长上下文任务可以给进程增加内存锁限制必要时调整ulimit -l让 CUDA 缓存不被换出到 swap 区。还有个小习惯是设置vm.swappiness10虽然大模型大多在显存里但这能避免操作系统把冷数据疯狂换出。第三刀是硬件通信。两张卡如果支持 NVLink 或通过 PCIe 直连多卡推理的通信延迟会明显下降。消费级卡大多不支持 NVLink因此两张卡之间的 tensor parallel 通信会走 PCIe性能取决于插槽带宽和驱动里的 P2P 设置。如果跑多卡并行时明显卡顿可以先检查两张卡是否都能看到对方的 P2P 能力同时尝试设置NCCL_P2P_DISABLE1看通信路径是否更稳定。5. 搭建 openrig 最容易翻车的三个真实案例再完美的规划也比不上现场踩坑一次。这一节是我亲身经历过的三个经典故障每一个都会在搜索 openrig 相关经验时被反复提起。把排查链路记录下来比直接给结论更有用。5.1 满载掉电重启供电与瞬时功耗的排查过程现象很典型跑小模型一切正常一旦并发请求上来机器瞬间黑屏重启。查看系统日志能看到类似NVRM: GPU at 0000:01:00.0: GPU has fallen off the bus的记录。第一次遇到时我一直以为是显卡故障换卡、重插都没用最后才意识到问题出在电源的瞬时带载能力。显卡在满载瞬间功耗会突然冲到峰值比持续功耗高出不少。标称 850W 的电源如果余量不足遇到双卡同时峰值就会触发保护机制直接切断输出。我最终的解决方案是改成双电源供电一块电源负责主板和 CPU另一块专门负责两张显卡并用一个 ATX 分线器保证开机时序同步。这个方案实施后再也没出现满载重启。排查这类问题时建议先装一个带功率计的插排观察待机、单卡满载、双卡满载三档功耗。如果整机峰值功耗已经超过电源标称的 80%就不要犹豫要么换更大电源要么拆分供电通道。强行超载运行的代价不只是重启而是可能同时带走主板和多张卡。5.2 90 度高温与降频风道位置比风扇数量重要开放式机架本应散热优异但我第一次装机时却遇到 GPU 温度轻松突破 85 度、性能大幅下降的情况。问题出在显卡的安装方向上开放式铝架允许显卡垂直摆放我便把两张卡贴得很近背靠背让风直接短路。风扇数量再多热风也排不出去整个机架变成热气循环箱。后来我把显卡间距拉开到至少两个槽位在机架侧面加装了两枚 14cm 大风量风扇用支架固定对准显卡进风口温度立刻降了十几度。这里的关键不是堆风扇数量而是确保冷风能送到显卡风扇正面、热风能从反面排走。对于下压式散热器或者无风扇的被动散热卡更要注重整体风道而不是局部加风扇。还有一招是用软件限制功耗。nvidia-smi -pl 300可以把 3090 的功耗上限压到 300W代价是损失少量性能但温度能控制在 70 度附近。对长期 7x24 运行 openrig 来说压低功耗换来的是风扇噪音减小和显卡寿命延长这笔账非常划算。我建议所有多卡机器都做功耗限制。5.3 模型加载失败权限、shm 和 NCCL 的小计算模型加载失败的诡异之处在于错误信息五花八门根因却高度一致。最常见的失败是CUDA error: out of memory明明看显存还有几 GB但模型就是加载不进去。这种情况通常不是显存真满而是容器或进程预分配的 CUDA context 占用了过多显存尤其是多个服务同时盯着一张卡时。解决方案很简单让服务各用各的 GPU并给容器设置明确的显存用量限制。第二类问题是/dev/shm空间不足。大模型加载时部分框架会把临时缓冲区或 tokenizer 数据放进共享内存Docker 默认只有 64MB很快就爆。解决方式是在 compose 文件里给容器加大 shm 限额比如shm_size: 10gb。第三类问题是跨卡通信时单卡超时这类问题多与 NCCL 有关排查时可以先设置NCCL_DEBUGINFO观察通信日志再调整NCCL_P2P_DISABLE或NCCL_SOCKET_IFNAME指向实际网卡。权限问题也不可忽视。当模型目录通过 NFS 挂载进容器容器内用户对文件没有读取权限时框架会只报file not found而不是权限错误。给共享目录设置统一的用户 ID 和组 ID或者把容器用户映射到宿主用户是既省事又安全的做法。6. 半年使用账本与单机走向集群的扩展思路机器稳定运行之后很多朋友会回到同一个问题上到底值不值这个问题没有标准答案却可以用账本和场景来拆解。我这段日子的实际使用情况是一个很好的参考样本。6.1 电费折旧维护一台 openrig 的真实成本以我手头的双 3090 openrig 为例硬件成本大约两万二。平时并不总是满载平均功耗大概 450 瓦每天运行 12 小时左右民用电价按每度六毛算一个月电费大约一百元。一年下来一千二。加上偶尔换风扇、加硬盘、清洁机箱的维护费用每年大概再花三百。按三年折旧算每个月的成本大约是硬件折旧六百一十元、电费一百元、维护二十五元合计约七百四十元。作为对比同等算力在云上按月租或按量使用通常每月至少一千五到三千元。更重要的是本地机器不存在并发超限或者服务商调度问题白天半夜都有稳定的推理能力。这套账在每天使用不超过一两个小时时并不划算但只要长期驻留任务超过三小时本地机器基本都能跑赢云成本。折旧这块有一个容易忽略的细节显卡折旧率远低于服务器硬件二手市场流通性极强。即便过两年想升级把卡挂到二手平台也能回笼不少资金。所以保存好原包装、购买记录和发票信息是变相降低 openrig 总成本的习惯。6.2 哪些工作负载该留在本地哪些该上云我目前的判断标准很简单低频但强算力的任务继续用云高频或隐私敏感的任务留在本地。本地适合夜间批量推理、长期运行的自动化任务、数据不离开内网的个性化模型以及需要频繁调试和试错的原型开发。云适合一次性的大规模模型微调、偶尔需要的多卡并行集群以及峰值波动明显的临时任务。具体的分界线需要结合任务时间。如果一个任务每周只跑一次、一次跑半小时云更划算连本地机器开机都不值得。如果任务每天都要跑且时长超过四五个小时本地几乎是必然选择。对于多模态模型和图像生成这类交互型任务本地还能省掉网络上传下载的延迟体验上比云更跟手。我在实际项目中会混合使用日常聊天模型和批量文档处理交给本地超大参数模型的定期微调按需上云。这样既享受到本地的低成本和高隐私又保留云端的弹性扩展能力是比较务实的搭配。6.3 从单机到多机本地 Ray 集群的起步经验单机 openrig 跑顺之后很容易萌生组集群的念头。我的经验是把目标定得务实一点不要上来就搭建 Kubernetes。Kubernetes 对单机多卡朋友来说维护成本高收益却很有限。更顺滑的路线是用 Ray 做调度它天然支持多台机器共享 GPU 资源也能比较方便地跑分布式推理和数据处理。Ray 集群的搭建只需要在三台机器上安装 Ray 依赖指定一台作为 head 节点其余作为 worker 节点。所有机器共享同一个模型存储目录模型权重只下载一份其他节点直接通过本地网络读取。这样的架构已经能支撑内部比较复杂的任务编排比如用 Ray 并行调用多个模型完成 RAG 流水线或者同时跑几路视频处理脚本。从单机到集群我最深刻的体会是openrig 的魅力并不在于堆出多大显存而在于培养了完整的系统思维。你会开始权衡显存、带宽、电源、散热和成本的每一处取舍会理解模型量化为何是推理优化的第一杠杆也会懂得如何用监控数据驱动决策。这些能力在纯云环境里很难学到但在自己的 openrig 上每踩一个坑就学到一个真本事。