把“openrig”这个标题拆开看，open是开源，rig在玩硬件的圈子里通常指一套完整的机器，尤其是那种为了特定任务拼起来的工作站或矿机。放到现在这个语境下，我理解的openrig就是一整套“本地AI推理工作站”的搭建方案：自己选硬件、自己装系统、自己跑大模型，整条链路都握在自己手里。它能解决什么问题？最直接的就是数据不出内网，隐私有保障；其次是一次性投入之后，跑推理不再按token计费，长期用下来成本可控；再有就是延迟稳定，不管网络环境怎么变，本地服务一直在线。

这篇文章我会按照自己在实际搭建中走过的完整流程来写：从需求拆解、硬件选型、参数计算，到软件部署、模型选择、踩坑排查。适合想搭一台本地AI工作站的技术爱好者、独立开发者，以及团队里负责内部工具建设的人参考。我不写那种纯理论的东西，所有内容都以能落地、能复现为目标。如果你正打算搞一台属于自己的“openrig”，这篇文章基本能帮你把坑提前踩一遍。

1. 项目定位与整体设计思路

1.1 为什么是本地推理，而不是全部走云上API

前两年大家做AI应用，习惯性就是调云端接口，省事、上手快，不用管硬件。但用久了你会发现几个很现实的问题：一是数据隐私，业务数据、文档内容发到外部服务，很多团队过不了合规这关；二是成本，API按token计费，高频调用一个月下来账单相当可观，长期跑批量任务更是一笔持续支出；三是稳定性，外部服务的可用性、限流策略你控制不了，关键时候掉链子很被动。

“本地推理”就是把这些问题一次性买断。你花一笔硬件钱，换来的是无限的本地推理次数、私有化部署的自由度、以及完全可控的响应速度。openrig这套方案的定位不是要替代云端GPU集群，而是补足“个人开发者、小团队、边缘节点”这个中间地带：性能要求不是极端高，但不能把数据送出内网，预算也有限。这是它最合适的应用场景。

1.2 先拆需求，再定配置，别上来就买显卡

我见过太多人一上来就问“4090能不能跑”，然后买回来发现大部分时间在跑7B小模型，浪费算力也浪费电。正确做法是先问自己三个问题：

第一，你主要跑什么任务？如果是文本对话、代码补全、文档总结这类LLM任务，显存是核心瓶颈，显卡的绝对算力反而没那么重要；如果你还要跑Stable Diffusion出图，那对显卡的算力、显存带宽都提出了更高要求；如果你要做长文档RAG，那么大内存和CPU性能也不能忽视。

第二，你的并发量有多大？自己一个人用，和团队10个人同时用，配置需求是两回事。并发上来之后，除了显存容量，还得多关注显卡的计算吞吐。

第三，预算范围多少？这决定了你是在“入门档”还是“性能档”里选。

基于这三个问题，我给出一套参考配置分层：

有人可能会问，为什么不上专业卡比如A5000、A6000？预算充足当然可以，但消费卡性价比高得多。3090二手价格现在很合适，24G显存能吃下大多数开源模型，缺点是功耗高、散热要吃紧。40系能效更好，但显存给得比较抠，除了4090之外大显存型号选择不多。这一点后面会展开说。

2. 硬件选型与核心参数解析

2.1 显存是第一决策变量，先学会算模型大小

深入讲之前先把这个核心概念聊透。本地跑Transformer模型，显存容量基本决定了你“能不能跑”。为什么？因为推理的时候模型权重必须驻留在显存里，每生成一个token都要把所有参数过一遍。显存不够，模型权重就会被换到内存里，速度断崖式下跌，甚至直接跑不起来。

怎么估算模型需要多少显存？有一个很简单的公式：模型文件大小约等于“参数量 × 每个权重占用的字节数”。比如一个70亿参数的模型，如果权重是FP16精度，就是7B × 2字节，约14GB；如果是INT4量化，就是7B × 0.5字节，约3.5GB。加上推理时的KV Cache和CUDA上下文开销，实际至少要在模型文件基础上留30%-50%的余量。所以16G显存的卡，跑7B模型的FP16版本差不多刚好卡线，而跑4bit量化就可以舒舒服服地留出不少余量。

这个行业里最常用的量化格式是GGUF，后缀名字带有Q4_K_M、Q5_K_M、Q8_0这一类的，就是不同压缩等级。Q4就是把每个权重压缩到4bit，体积小、速度相对快，牺牲一点精度；Q8保留的精度更多，体量自然也更大。单纯聊天用Q4就够，做代码生成或者需要更严谨输出的时候，建议上Q5或者Q8。我的个人习惯是优先选Q5_K_M，在体积和效果之间相对平衡。

给一张不同显存能跑的模型规模参考表：

注意这里说的是“能跑”，实际速度还要看算力。显存一样大，旧卡和新卡的推理速度可能差一倍以上。

2.2 CPU、内存、主板、供电这些“配角”怎么搭不拖后腿

显卡是主角，但其他部件选不好，体验会很糟。我按优先级排序来说。

内存。32GB起步，最好是64GB。为什么内存要这么大？因为如果你以后想直接加载超过显存容量的模型，推理引擎会把部分层放在内存里跑，内存小了直接报错，或者被系统kill掉。另一个原因是RAG场景下，你需要把文档向量化之后放进内存，几十个PDF下来内存占用就很可观了。频率方面DDR4 3200或DDR5 4800都可以，容量优先于频率。

CPU。很多人误以为跑AI要用顶级CPU，实际上推理的算力大头在显卡上。CPU的职责是把数据喂给GPU，再处理一些tokenizer、采样逻辑。选一颗6核12线程以上、单核性能强一点的CPU就够了，比如Intel的i5-13400/14400或AMD的R5 7600系列。但有一种情况CPU确实会成瓶颈：当你在跑小模型、且显存带宽又很高的时候，CPU负责的prefill阶段可能拖慢整体速度。

主板。核心看PCIe通道和供电。单卡其实不太挑主板，但你要为未来加第二张卡留余地。B760和B650级别的板子，一般能支持双卡x8+x8拆分，前提是CPU本身提供足够多的PCIe通道。预算稍微宽裕一点，建议上一张Z790或X670，供电和扩展性更稳。

电源。这是最容易省错钱的地方。给你一个靠谱的计算公式：整机峰值功耗 = 显卡TDP + 150W系统余量，然后在这个基础上加20%-30%冗余。一张3090的TDP是350W，加上CPU等，算下来650W打不住，建议直接上850W金牌。电源千万别省，劣质电源在GPU瞬时功耗冲击下可能直接黑屏重启，那排查起来才叫绝望。

散热。很多人把散热当小事，但一台满载400W以上的机器放在你身边，风扇噪音是可以让你怀疑人生的。机箱选风道好的中塔机箱，前面板能装三个120mm风扇的优先；CPU散热器至少双塔风冷；显卡就不用说了，公版和非公版的散热差异也很大。如果你打算把openrig放在卧室，建议做好“书房部署”或者用长线把机器挪到阳台/弱电井的心理准备。

3. 软件栈部署与核心环节实现

3.1 系统与驱动：从零到能跑的最小路径

系统选择要尽量避免纠结：Windows和Linux都行，我的建议是——如果你只是自己用、之后不折腾别的，Windows省心；如果你打算长期跑服务、做自动化和远程管理，请直接上Linux。我自己用的是Ubuntu 24.04 LTS，用起来最顺，驱动生态和容器支持都跟得上。

装系统这一步我给新手一个忠告：不要为了“精简”去装各种优化版、精简版系统，很多AI推理的玄学问题，最后查下来都是系统组件缺失导致的。老老实实用官方镜像，选“最小安装”就够了，桌面要不要都行，纯命令行版的Ubuntu Server反而更省心。

驱动这一步，最容易出问题的是Windows用户把显卡驱动装成了“Game Ready”，NVIDIA和AMD的GPU驱动其实都有专门的稳定分支，建议优先选择“Studio Driver”分支。在Linux上相对简单，用apt装nvidia-driver-545或560版本，然后重启，用nvidia-smi验证一下，能看到显卡型号和驱动版本就说明驱动正常了。

有个坑必须提：Linux桌面版Ubuntu在安装过程中可能会自动装上开源的nouveau驱动，这会导致后面装NVIDIA官方驱动时冲突。装完系统先把nouveau禁用掉再装官方驱动，顺序不能反。怎么检测？运行nvidia-smi如果提示“command not found”，大概率就是还没装对。

3.2 本地推理工具：Ollama和LM Studio怎么选

现在跑本地模型，绕不开两个工具：Ollama和LM Studio。两者定位完全不同。

Ollama本质是一个开源的模型运行引擎，设计思路很极客——一条命令下载模型，一条命令起服务，暴露标准OpenAI兼容API，方便外部程序调用。它非常适合做成后台服务，让局域网内多台机器共享。缺点是图形界面基本没有，对非技术用户不友好。源码在GitHub上有17万+的star，模型库覆盖了主流开源模型。

LM Studio更像是“带着图形界面的Ollama”，你可以在界面里搜索模型、下载、加载、开聊天窗口，还带一个本地API Server。对于想快速体验、不愿碰命令行的用户很友好。它的缺点是图形界面占用一些系统资源，服务化运维能力也比较弱。

我的建议是：生产环境用Ollama，探索阶段用LM Studio。你可以先装LM Studio玩玩，等确定要长跑了，配置好Ollama的服务和模型，让它常驻后台。

Ollama的部署过程很简单，一条命令：

curl -fsSL https://ollama.com/install.sh | sh

装完后默认监听127.0.0.1:11434，只能本机访问。要让整个局域网都能用，需要改环境变量：

sudo systemctl edit ollama

在打开的编辑窗口里写：

[Service] Environment="OLLAMA_HOST=0.0.0.0:11434"

保存后重启服务：

sudo systemctl restart ollama

从这以后，局域网里任何一台机器都可以用http://你的主机IP:11434访问这个推理服务。再配合Open WebUI或者NextChat这样的前端，一个团队私有的AI对话平台就算建起来了。

3.3 模型选择策略：从3B到70B，各取所需

模型怎么选，这是一个“看饭下菜”的问题。给一个实用的策略：

3B-4B级别模型适合干什么？轻量任务、移动设备、或者你只需要极快响应且精度要求不高的场景。比如日志分类、简单的意图识别。7B-8B是性价比之王，比如Qwen2.5-7B-Instruct、Llama-3.1-8B，知识量对于日常对话和文档处理足够，16G显存跑4bit量化速度快、体验好。14B-32B是进阶档，比如Qwen2.5-14B/32B、GLM-4-9B，能力上了一个台阶，能处理更复杂的逻辑推理和长文本生成，代价是显存需求翻倍。70B级别以上的模型，说实话个人工作站跑起来性价比不高，除非你有双卡或专业卡，否则不推荐。

实际操作上，用Ollama拉模型就这么简单：

ollama pull qwen2.5:7b-instruct-q4_K_M

这条命令会从模型仓库下载一个约4.7GB的量化模型文件，下载完成后就可以跑了：

ollama run qwen2.5:7b-instruct-q4_K_M

进了交互界面直接打字就能对话。退出用/bye。

如果你要写代码来调用，Ollama已经兼容OpenAI的API格式，用Python很顺手：

from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama", # 本地服务不用校验，但格式上要填 ) resp = client.chat.completions.create( model="qwen2.5:7b-instruct-q4_K_M", messages=[{"role": "user", "content": "用三句话解释什么是RAG"}], temperature=0.7, ) print(resp.choices[0].message.content)

写到这里要提醒一句：参数里的temperature对输出影响很大。写代码、做结构化输出时建议调到0.1-0.3；聊天、头脑风暴可以调到0.7-0.9；再高就很容易胡编了。

4. 常见问题与排查技巧实录

4.1 模型加载失败的排查思路

这是我被问得最多的一类问题，症状通常是：ollama run之后，一直转圈，然后报错或者进程被“killed”。很多人第一时间怀疑是模型下载坏了，实际上绝大多数情况是“资源不够，被操作系统杀了”。

排查用三个命令就够了：

free -h nvidia-smi dmesg | tail -50

先看内存。如果内存本身不足32GB，加载大模型很容易被OOM killer干掉，dmesg里会有“Out of memory”字样。再看显存占用，确认是不是有其他进程占着显存。如果这两个都正常，再考虑重下模型文件。

特别要强调“推理没走GPU”这个坑。驱动装得不干净、或者环境变量有问题时，Ollama会静默地退回CPU推理，表现就是输出速度极慢。我在实测中，纯CPU跑7B模型大概每秒生成5-8个token，而一张中端卡能到40-60 token/s，差距非常明显。所以在调试阶段，务必看一下ollama ps确认模型是加载在GPU上的。

4.2 温度和功耗的实测心得

跑起来之后，你的openrig会变成一个持续发热的“暖炉”。我拿3090实测过：待机功耗大概在15-20W，风扇不转；但满载跑32B模型时，整机功耗飙升到500W+，显卡核心温度85℃左右，显存温度甚至能到95℃以上。这个温度对显存来说已经偏高，长期跑会影响寿命。解决办法是微调风扇曲线，让显卡风扇在70℃时就拉到60%转速，虽然吵一点，但温度能压回75℃上下。

另一个容易被忽略的细节是“24小时常驻推理服务”的功耗账。按上面500W的满载算，一天跑4小时，一个月大概60度电。对个人来说还好，但如果整个团队都把它当默认服务用，一个月电费也不是小数目。在部署前建议先想清楚：这台机器是我个人专用，还是团队共享？这决定了你要不要给它做功耗控制。

4.3 硬盘和数据备份的容易踩的坑

模型文件动不动几个GB，下载多了之后，系统盘会被填满。我见过有人把Ollama的模型目录放在默认路径下，跑一段时间磁盘告警，查了半天才发现全是模型文件。解决办法是在装完Ollama之后立刻改模型存储位置：

sudo systemctl edit ollama

写入：

[Service] Environment="OLLAMA_MODELS=/data/ollama/models"

然后把模型搬过去，重启服务。尽早规划数据盘空间，别指望系统盘那几百GB能扛多久。

还有一点是关于配置备份。openrig跑稳定了之后，建议把关键配置（系统安装步骤、模型清单、环境变量、启动脚本）整理成一份文档或脚本存到Git仓库里。本地工作站这东西有个特点：一旦出问题重装系统，反推恢复的力气比第一次搭建还要大。提前把配置管理好，等于是给自己留了一条后路。

4.4 扩展性：从单卡到双卡需要考虑什么

openrig这个名字本身就带着折腾的基因。很多人用一段时间就会想：要不要加第二张显卡、跑更大的模型？这里要提前说明白，双卡并不是简单插上就能用。首先主板要有足够的PCIe通道，至少x8+x8；其次电源要重新核算，两张3090的峰值功耗要上千瓦；再一个，模型并行推理对软件栈要求更高，Ollama目前对多卡支持还算可以，但跨卡通信会有一定的性能损耗。最佳实践是：双卡方案尽量选同型号同显存的两张卡，否则显存小的那张会拖累整体。如果只是想要更大的显存总容量来跑超大模型，优先考虑买一张24G以上的大显存卡，不一定非要双卡。

写在最后的一些体会

我把openrig跑通前前后后折腾了小半年，最大的感受是“本地推理的精髓不是跑出一个惊人的大模型，而是拥有一台完全属于自己、随时可以实验的机器”。在这台机器上，你可以随便改采样参数、试各种量化方案、做模型间的对比评测，不用看API账单脸色，也不用担心数据传到外部。这种掌控感，是调API给不了的。

最后再分享一个小技巧：刚把模型跑起来的时候，不要急着追求“大模型”，先在7B-8B级别把整套链路走通，熟悉Ollama的配置、API调用、前端接入这些环节。链路畅通之后再去换更大的模型，你会发现自己已经会判断哪个参数影响速度、哪个参数影响效果，而不是一头雾水地到处问人。openrig的真正价值，不只是那台机器，而是你在这个过程里积累下来的判断力和经验。