企业官网建设流程全解析

“openrig”这个词，乍一听像是某个开源硬件项目，又有点像桌面工作站改装圈的代号。实际上，我在组装本地大模型训练和推理机器时，也一直在琢磨这个概念——把一台可以自由拆装、灵活配置、完全由自己控制软硬件栈的机器，作为私有化 AI 工作台。今天不聊云厂商，不聊算力租赁，就说说我基于 openrig 思路组装、调试一台本地 AI 工作站的全过程，从硬件选型到软件环境，再到那些文档里不写但实际必踩的坑。

1. 先搞清楚 openrig 到底解决什么问题

1.1 “rig”不是矿机，是工作节点的代称

在英文技术社区里，“rig”通常指一套为特定任务组装出来的设备，可能是渲染农场里的一个渲染节点，也可能是游戏装机圈里的“电竞主机”。而 openrig 这个概念，我更愿意把它理解为：一套面向 AI 开发场景、硬件规格和软件栈都保持透明开放的工作节点。它强调的不是某个品牌整机，而是“自己选型、自己组装、自己维护”的原则。

我之所以对 openrig 感兴趣，是因为日常做模型微调、推理部署和数据处理时，经常遇到几个痛点：云端 GPU 实例虽然方便，但按小时计费，长时间跑实验成本很高；公司或学校的内网服务器排队严重，一次实验往往等半天；机器配置是别人定好的，想加一张显卡或者换大内存，根本没法操作。自己组装一套 openrig 风格的机器，就可以完全按需配置——今天只需要跑 7B 模型，就上一张 24G 显存的卡；明天要并发服务多个模型，就再加一张卡并联调多机。

1.2 为什么现在适合折腾 openrig

其实硬件平台一直都有，但以前自己攒一台 AI 工作站的门槛很高。早年 CUDA 生态对硬件兼容性挑得厉害，非专业计算卡跑深度学习经常出各种玄学问题；大容量显存显卡价格也居高不下。到了现在，情况完全不同：消费级显卡的显存做到 24G 甚至更大，开源推理框架对普通硬件的适配程度很高，而且 Linux 下的驱动安装也比以前省心很多。这意味着一个普通开发者完全可以用相对合理的预算，组装一台能跑本地大模型、能微调开源模型、还能顺手做视频处理和科学计算的工作站。

我把这种组装思路统称为 openrig，核心价值就是三点：可复现（硬件清单和软件环境全部记录在案）、可扩展（预留 PCIe 插槽、电源余量和散热空间）、可维护（任何部件坏了都能自己换，不依赖厂商售后）。这三点听起来简单，但在实际搭建过程中，每个环节都有不少需要仔细斟酌的细节。

1.3 谁适合参考这套方案

如果你属于以下几类人，这篇文章应该能帮上忙：

• 想跑本地大模型，但不知道选什么显卡、配多少内存；
• 买了显卡但装好驱动后系统频繁崩溃，不知道问题出在哪；
• 需要微调开源模型，却总在远程服务器上排队，想搞一台自己的训练机；
• 厌倦了厂商整机“不可拆解”的设计，想找回 DIY 硬件的掌控感。

如果你只是偶尔调个 API 玩一下，其实没必要看这篇，云服务的按量付费可能更划算。但如果你想认真做 AI 实验、本地部署服务，或者深度参与开源模型的二次开发，那么 openrig 这套思路确实值得花时间了解一下。

2. 硬件选型：每项配置背后的取舍逻辑

2.1 显卡是第一优先级，显存大小直接决定能跑什么

在 AI 工作节点里，GPU 是一切的起点。很多人问买什么显卡，我的回答很直接：先定显存预算，再定具体型号。当前开源模型的参数规模和量化方案，基本上决定了显存的需求量：

如果你想跑 7B 或 8B 模型的量化版本，一张 24G 显存的卡基本够用；如果还想微调，最好预留足够显存来放优化器状态和梯度，这时 24G 也可能吃紧。我实际测试下来，单卡 24G 做 7B 模型的 LoRA 微调刚刚好，全量微调就别想了，那是多卡和高端卡的活儿。

2.2 CPU、内存、主板：别在边缘配置上拖后腿

很多人组装 AI 工作站时一门心思砸显卡，却在 CPU、内存这些“配角”上过于省事，结果后续跑数据预处理、模型加载、分布式通信时瓶颈不断。我的建议是：

• CPU：尽量选择核心数多一些的型号。虽然训练主体在 GPU 上，但数据加载、tokenize、评估都在 CPU 上跑，核心数太少会拉长每个 epoch 的耗时。
• 内存：至少 64G 起步，推荐 128G。这个经验来自实际场景——加载大模型权重到内存做格式转换时，32G 内存会捉襟见肘；同时处理多份数据集的预处理时，内存越大越从容。
• 主板和电源：主板需要确认有足够多的 PCIe 插槽，而且要留意插槽间距。很多全尺寸主板虽然看起来有很多插槽，但装上一张厚显卡后，相邻插槽就被挡住了。电源建议至少选择 1000W 以上的金牌或铂金牌，多卡配置直接上 1600W 也比较稳妥。

2.3 散热和机箱：最容易低估的两件事

我以前在组装 AI 工作站时犯过一个典型错误：机箱选了一个非常节省桌面空间的“小钢炮”款式，装进去后发现两张显卡的间距很小。跑推理任务时，上方那张卡的温度能冲到 85 摄氏度以上，GPU 核心为了自我保护会自动降频，结果性能反而比单卡还差。后来换成了全塔机箱，前部加装了三枚 14cm 进风扇，顶部两枚 14cm 出风扇，后部一枚 12cm 排风扇，温度才稳定在 65~70 摄氏度之间。

一个重要的建议是：不要只看显卡的“标称功耗”，要按实际峰值功耗规划散热。有一些显卡瞬时功耗可以冲到标称值的 1.5 倍左右（早期某些型号尤其明显），如果电源余量不足，轻则系统重启，重则损坏硬件。

2.4 硬盘与数据存储：不只是装系统这么简单

模型权重文件动辄几十 GB，数据集有时候能达到几 TB，所以存储也值得认真规划。我的分工方式是：

• 用一块 1TB 的 NVMe SSD 作为系统盘，专门安装操作系统和日常工具；
• 用一块 2TB 或更大的 NVMe SSD 存放模型权重、数据集和虚拟环境；
• 有长时间归档需求的话，可以再挂一块机械硬盘用于冷数据备份。

数据盘的性能会影响模型加载速度和数据处理效率。我测过从 SATA SSD 和 PCIe 4.0 NVMe SSD 加载同一份 20GB 权重文件，耗时有明显差距，前者要等半天，后者一两分钟就完事。训练任务虽然主要靠 GPU，但每个 epoch 之间的数据读取时间会被存储速率直接放大。

3. 系统与 AI 环境搭建：把软件栈打磨顺手

3.1 操作系统与 Ubuntu 版本选择

AI 开发环境的选择，绕不开 Linux。我选的是 Ubuntu 22.04 LTS 或 24.04 LTS，主要原因在于兼容性和社区资料最丰富。Windows 上用 WSL 虽然也能跑，但在 GPU 直通和原生驱动方面多少有些小麻烦，排障时也会遇到“Windows 特有”的奇怪问题。

系统安装这里不再赘述，只提醒两点：

• 安装时选择“最小安装”模式，避免装一堆用不到的桌面软件；
• 磁盘分区时留意根目录空间分配，不要把整个系统挤在一个小分区里，以后装完依赖库、Docker 镜像后很容易爆盘。

3.2 显卡驱动与 CUDA 版本：组合比单版本更重要

如果问我整个搭建过程最容易出问题的环节，驱动和 CUDA 的搭配绝对排第一。我见过不少朋友在驱动这里栽跟头，反复黑屏、循环登录、启动后分辨率不对。实际上，只要按以下顺序操作，成功率很高：

先更新系统基础软件包，再安装驱动。我推荐使用官方提供的runfile方式装驱动，或者用系统自带的ubuntu-drivers工具自动推荐版本。这里最关键的一点：不要装完驱动后不管，要确认nvidia-smi输出正确。

接着说 CUDA 的安装。我个人的习惯是使用 Conda 安装特定版本的 CUDA 工具链，而不是把 CUDA 全家桶都装到系统目录。这样项目之间可以灵活切换不同的 CUDA 版本，不会出现“一个项目要用 CUDA 11，另一个要用 CUDA 12，俩互相打架”的情况。

3.3 Docker 与容器化部署：让环境“随用随建，不用即扔”

在模型部署阶段，我特别推荐用 Docker。原因是模型服务往往对依赖版本极其敏感：一个库升级了，另一个库就罢工。容器化之后，每个推理服务都拥有独立环境，互不干扰，清理由来也极其方便。

使用 GPU 容器的基础准备：

# 安装 NVIDIA 容器工具 distribution=$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit # 重启 Docker 服务 sudo systemctl restart docker

然后可以用一条命令快速验证 GPU 容器是否可用：

docker run --rm --gpus all nvidia/cuda:11.8.0-base-ubuntu22.04 nvidia-smi

如果能看到显卡列表，说明 GPU 容器环境已经打通。之后跑 vLLM 或 Ollama 的容器版就非常顺滑，只要把模型目录挂载进容器，一条命令就能起一个 OpenAI 兼容的本地推理服务。

3.4 Python 虚拟环境与深度学习框架安装

AI 开发离不开 Python 环境。我强烈建议日常实验用 Conda 管理虚拟环境，而不要直接往系统 Python 里乱装包。每个项目单独建一个环境，版本冲突概率会明显下降。

基础环境的准备大致是这样：

# 创建虚拟环境，指定 Python 版本 conda create -n llm python=3.10 conda activate llm # 安装 PyTorch（根据 CUDA 版本选择对应命令） pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 # 安装常用依赖 pip install transformers accelerate datasets peft

这里有个小细节——PyTorch 版本和 CUDA 版本要匹配。如果不匹配，虽然模型也能加载，但训练时你可能根本用不上 GPU 加速，还以为是显卡坏了。装完一定要验一下：

import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0)) print(torch.cuda.get_device_capability(0))

输出为True才是真正打通的。

4. 实操过程：从裸机到跑起一个 7B 模型的完整记录

4.1 整机装机过程的关键控制点

装机过程本身不复杂，但有几个控制点要特别注意。

显卡的安装是第一步，注意 PCIe 卡扣要对准，不要用蛮力；要确认供电接口完全插入。很多“开机点不亮”或“进系统后显卡不识别”的故障，根源就是供电线没插紧。

电源线的走线虽然不影响性能，但会影响机箱风道。如果电源线交叉挡在显卡风扇前面，风量损失其实挺大的。我习惯先把主板、CPU、电源装好，再装显卡和数据盘，这样留给走线的空间更开阔。

第一次开机进 BIOS，要确认 PCIe 链路速率正确。有些主板默认开启了“EZ OC”或“自动超频”选项，对稳定性有负面影响；建议把主板 BIOS 更新到最新版本，然后关闭不必要的自动超频，把所有 PCIe 插槽设置为 Gen4 模式。

4.2 系统安装后的驱动验证

进入 Ubuntu 后，先别急着跑模型，一步一步做验证。我按以下步骤做：

# 查看系统信息 lscpu free -h lsblk # 查看显卡驱动是否加载 nvidia-smi

如果nvidia-smi正常显示显存、驱动版本、CUDA 版本，说明基本驱动到位。接下来测试 CUDA 算力是否正常：

# 运行 PyTorch 的 GPU 矩阵运算，验证 CUDA 链路 python -c "import torch; a=torch.randn(1000,1000).cuda(); print((a@a).sum().item())"

这一步如果报错，需要检查是不是 PyTorch 版本带错了 CUDA 工具包，或者驱动版本过低。总之，这一层验证通过，后面几乎不会有大问题。

4.3 安装 Ollama 并运行开源大模型

Ollama 是目前本地运行开源大模型最省心的方案。它把模型下载、量化、推理服务全部统一管理起来，对新手非常友好，对老手来说也足够可靠。

# 安装 Ollama curl -fsSL https://ollama.com/install.sh | sh # 拉取并运行 7B 模型 ollama run llama3.1 # 查看模型参数 ollama ps

首次运行会下载模型，速度取决于网络状况和模型大小。我们在 openrig 机器上，模型下载到本地 SSD 之后，之后每次启动都是秒级加载。

如果要把 Ollama 作为一个完整的本地服务供其他机器访问，可以修改服务监听参数，让它监听局域网，然后客户端就能远程调用。这个能力很适合团队内共享一个 GPU 节点。

4.4 进阶环节：用 vLLM 跑高并发推理

如果只是一个人玩玩，Ollama 足够；但如果要提供一个对外的 API 服务，vLLM 是更理想的选择。vLLM 在批处理推理方面做了极致优化，能在高并发下保持较高的吞吐量。典型的使用方式：

pip install vllm python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --port 8000

--tensor-parallel-size用于配置多卡并行，单卡就填 1；--gpu-memory-utilization指 GPU 显存利用率，太满容易 OOM，一般 0.85~0.92 之间比较安全。服务启动后，可以用 OpenAI SDK 直接调用兼容接口，整个流程跟在云上调用 API 几乎没有差别。

4.5 微调实践：用 LoRA 做一个垂直领域小模型

除了推理，openrig 的另一个高频场景就是微调。我用 PEFT 库对一个 7B 模型做 LoRA 微调，整个流程经过多轮迭代后非常稳定。核心代码如下：

from transformers import AutoTokenizer, AutoModelForCausalLM from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training from transformers import TrainingArguments, Trainer model_id = "your-base-model-path" tokenizer = AutoTokenizer.from_pretrained(model_id) model = AutoModelForCausalLM.from_pretrained( model_id, device_map="auto", load_in_4bit=True, torch_dtype=torch.float16, ) model = prepare_model_for_kbit_training(model) lora_config = LoraConfig( r=8, lora_alpha=16, target_modules=["q_proj", "v_proj"], lora_dropout=0.05, bias="none", task_type="CAUSAL_LM", ) model = get_peft_model(model, lora_config) training_args = TrainingArguments( output_dir="./lora-output", per_device_train_batch_size=2, gradient_accumulation_steps=8, learning_rate=2e-4, num_train_epochs=3, logging_steps=10, save_steps=200, fp16=True, ) trainer = Trainer(model=model, args=training_args, train_dataset=dataset) trainer.train()

微调的几个关键点：数据质量决定模型表现；target_modules的选择会直接影响微调效果；梯度累积可以变相扩大批次大小，又不会爆显存。我建议新手先用小数据量（比如几千条）跑通全流程，再正式投入大训练。

5. 折腾 openrig 期间遇到的典型问题与排错方法

5.1 GPU 显存显示不足但任务很小

经常有朋友问“为什么我的 24G 显存跑个 7B 模型还是 OOM？”这大概率不是显存真不够，而是环境没清理干净。PyTorch 里显存不会自动释放，之前测试模型占用的显存一直驻留着，再跑新任务自然就会 OOM。

解决办法：

# 查看哪些进程占用 GPU nvidia-smi # 直接清理所有残留的 Python 进程 pkill -9 python

更彻底的做法是在代码里显式清理缓存：

import torch torch.cuda.empty_cache()

记住一个原则：换模型前先清进程，别让上一个实验的记忆拖累你。

5.2 驱动装好后系统频繁重启或自动断电

这种情况通常与电源功率余量不足有关。一些显卡的瞬时功耗峰值远高于稳定功耗，触发电源过流保护后系统直接断电，看起来像是硬件故障，实际上是电源不够。排查方法是更换更大功率的电源，或者把显卡的功耗上限调低。这里有一个小工具可以用：

# 使用 nvidia-smi 设置功耗上限（以瓦特为单位） sudo nvidia-smi -pl 250

5.3 多卡并行时 PCIe 带宽瓶颈

双卡跑训练，显存是叠加了，但卡之间的数据传输通过 PCIe 总线。如果主板只支持 x8 链路甚至 x4，通信带宽就会受限，导致双卡反而比单卡慢。解决思路：

• 确认卡插在正确的 PCIe 插槽上；
• 在 BIOS 里把 PCIe 链路速率手动设置为最高值；
• 设置NCCL_P2P_DISABLE=1看看是否因 P2P 问题导致卡死。

我发现很多“双卡跑不起来”的故障根因，其实是 NCCL 通信库在特定硬件组合下和驱动版本冲突导致的 P2P 挂死。设一个环境变量就能绕过去，虽然通信效率略微下降，但比完全卡死强得多。

5.4 显卡灯亮但不被系统识别

有位朋友遇到过这样的故障：显卡风扇在转、灯光在闪，但nvidia-smi就是不显示这张卡。排查下来，问题出在他把显卡插在了只有物理接口、没有足够 PCIe 通道的插槽上（某些主板的第二根显卡插槽实际是运行在 x1 或 x4 通道）。这种情况不是硬件坏了，而是主板设计限制，需要看主板说明书确认插槽的通道分配。

5.5 常见问题速查表

6. 从单机到多机：openrig 玩法还能延伸到多机集群

当你在 openrig 上成功跑通单机推理和微调之后，很自然会产生一个念头：既然一台机器这么顺手，能不能把多台机器连起来，组成一个小型 GPU 集群？这个问题在实际场景中相当现实——比如手里有一台 24G 的机器，另一台 32G 的机器，想把它俩拼起来跑一个大模型，就需要引入分布式推理/训练的技术栈。

在这个层面，用的比较多的是 DeepSpeed 的 ZeRO 阶段或 FSDP 这类解决方案。以 DeepSpeed 为例，它在 CPU 和 GPU 之间做梯度分区和通信优化，可以把多台设备近似当成一台大显存机器来用。不过我需要先说明：多机通信的网络条件会直接影响效率，建议至少使用万兆网卡或 RDMA 等低延迟方案。家用千兆网在数据量大的训练场景下，通信开销可能会抵消多机的算力收益，这也是我实测下来的教训。

6.1 搭建前的基础检查

如果你的目标是把多台 openrig 节点组网，建议先确认三件事：

• 所有节点的网络可以互相直连；
• SSH 免密登录已配置好，分布式框架需要节点间通过 SSH 拉起进程；
• 所有节点的软件环境一致（CUDA、PyTorch 版本、Python 版本），不一致时模型并行会报各种“玄学”错误。

这三件事里，第三件最容易踩坑。我习惯在每个节点上用同样的 Conda 环境文件构建虚拟环境：

# 在主节点导出环境 conda env export > environment.yml # 在从节点重建环境 conda env create -f environment.yml

这样能避免至少八成的分布式环境兼容性问题。

6.2 组网训练时额外要注意的细节

不同机器的显卡型号和显存不一样，会导致负载分布不均匀。比如一张 3090 和一张 4090 组合训练，显存小的卡可能在反向传播阶段先撑不住，整个训练任务直接崩溃。这种场景下，建议使用按显存比例来切分的并行策略，或者干脆让老型号显卡只跑推理、新型号跑训练，各司其职。

还要注意温度对长期训练的稳定性影响。我在跑一次持续 20 小时的微调任务时，中途机房空调出风口被东西挡住，气温一升高，GPU 温度超过 85 度后触发保护降频，训练速度肉眼可见地慢下来。后来我只能给机房设了温度阈值告警，桌面端也装了温度监控脚本，温度一超过阈值就自动给工作机发送通知。如果你的 openrig 也会经常跑长任务，这套监控方案值得提前安排上。

6.3 模型部署层面，多机多卡和单机多卡差别在哪里

推理和训练不一样。训练要的是吞吐量，推理要的是延迟。多机推理时，模型并行通信发生在每层计算之后，网络延迟会被放大，导致请求响应变慢。所以我个人的经验是：推理场景能单机多卡就别搞多机；只有单机显存放不下完整模型时，再考虑拆到多机。也就是说，openrig 的单机扩展能力已经能覆盖大多数团队的真实需求，多机一定程度的“锦上添花”并不总是正收益。

如果真的要搞多机推理，建议优先用 vLLM 配合 Tensor Parallel 和 Pipeline Parallel。配置时要注意--tensor-parallel-size的值跟节点数、GPU 数保持对应关系，不然服务启动时会报“通信初始化失败”之类的错误。

7. 最终体验：openrig 的价值在于掌控感

组装一台 openrig 风格的工作站，对我来说最大收获不是“省了多少钱”，而是重新拿回了对开发环境的主导权。云端环境虽好，但总会有一种“借来的工具”的疏离感。而自己选硬件、装驱动、配环境、跑服务，每一步都是独立的决策和调整，最终得到的工具完全贴合自己的工作流。

基于个人使用体验，有一些建议可以给想入坑的朋友：

• 预算有限时，优先保证显卡、电源、内存这三样。CPU 可以适当降级，硬盘也可以用普通 SSD，但电源不能省，内存不建议低于 64G；
• 第一次搭建时，软件环境一定要做文档记录。我用的就是一个简单的 Markdown 文件，记录系统版本、驱动版本、CUDA 版本、关键 pip 包版本。这样重装系统时就不必重新踩一遍坑；
• 开机跑正式任务前，先用小模型做一轮全链路测试。我的做法是跑一个精简版的数据集微调任务，确认 GPU 利用率、显存分配、数据加载速度都正常后，再上正式实验，避免中途才发现环境有问题，白白浪费几个小时。

最后再分享一个小技巧：每次改完驱动或更新 CUDA 后，先跑一个pytorch的矩阵运算和nvidia-smi的对照检查，确认显卡能正常计算，再继续后面的工作。这一分钟左右的检查能避掉许多后面可能出现的“软件环境混乱”问题。安装相关依赖时，尽量只装小版本号的“确定能用的配置”，不要总是追最新版本，稳定比版本数字更有价值。

如果你也正在折腾 openrig 的高性能主机，建议做好面对小问题的准备——无非就是驱动不兼容、显存不够、插槽带宽不足这一类的琐碎问题。但只要把环境打磨顺手了，这台机器能给你带来的自由度和成就感，绝不是云服务能替代的。