企业官网建设流程全解析

这些年做AI项目的过程中，我一直有个执念：凡是真正要反复跑的东西，尽量自己掌握硬件和软件栈。云上的服务确实方便，但按量计费跑起来心里没底，数据要交到外部接口也不踏实，更别提测试高峰时的延迟和限流了。后来我终于攒了一台完全属于自己的机器，给它起了个名字叫 openrig。这个名字没什么高深的，说白了就是一件事：用开放的硬件、开源的软件、公开的模型，把一台能跑大模型推理和微调的平台正正经经搭出来，并且把整套配置变成文档和脚本，别人拿到手也能复现。如果你是个算法工程师、独立开发者，或者正在纠结要不要上本地推理机的学生，这篇文章大概能帮你省下不少弯路。

openrig 不是某个公司发布的成品设备，它更像一套可以照抄的作业。换上的每一块显卡、每一行驱动命令、每一个推理引擎参数，都是可以公开讨论和替换的。我踩过的坑、调过的参数、总结的性能数据和问题排查方法，下面都会摊开讲。我会把每个关键环节的“为什么这样做”和“不这样做会怎样”都解释清楚，尽量让不同基础的人都能看懂。

1. 为什么要搭一台开放推理机：OpenRig 想解决的问题

1.1 云端 API 的三个现实代价

先聊点实际的。很多人觉得调用云端大模型 API 很便宜，算下来每千 token 也就几分钱。但真到了开发和测试阶段，这个账完全不是这么算的。你先要写 Prompt 调参，一次不对就多跑几轮；然后要做评测，同一批 case 往往要来回跑好几遍；再往后想微调，一个 epoch 的损失曲线就要反复验证。几个月下来，调用次数轻轻松松几十万次，账单上的数字就不那么可爱了。

还有更麻烦的延迟问题。当你把推理能力嵌进内部工具或者自动化流水线时，每一次请求都要经过公网。网络一抖动，你的程序就卡住；服务商一限流，超时重试的逻辑就得写一堆。而且生产环境里往往需要指定模型版本，但云端模型经常悄悄更新，行为变了你都不一定知道。这些痛点让我越来越觉得，关键任务应该放在自己能控制的机器上。

数据安全也是绕不开的问题。企业内部的代码片段、业务文档、客户隐私，这些内容如果拿去调用外部服务，合规审查这一关就很难过。哪怕你自己做个人项目，把所有聊天记录和代码片段交给某个外部接口，心里多少也会犯嘀咕。本地推理最大的好处就是数据不出实验室，跑完就留在自己的硬盘上，安全边界完全由你自己定义。

1.2 可复现的“开放设备”而不是玄学攒机

自己攒一台跑模型的机器，很多人第一反应是“不就是买显卡插上吗”。其实远没这么简单。显卡买到手以后，你会发现驱动、容器运行时、推理引擎、量化格式、并发参数之间全是耦合。今天照着某篇博客跑通了，过两天换个环境又不行了。

openrig 要解决的就是这种不可复现。它把硬件选型、系统设置、驱动安装、软件版本、模型下载、服务启动这几层全部拆开，每一层都写清楚选了什么、为什么这么选、出了问题怎么排查。整个项目像一个开放菜谱，你照着做能得到一盘稳定的菜，想调整口味也能从配方里看出来该改哪一步。

“开放”这两个字，我理解成三层含义：硬件选择遵循公开规格，不绑定私有的扩展接口；软件栈全部采用开源或开放协议，许可证清晰；配置文件和启动脚本放进代码仓库，团队里任何一个人都能用相同的步骤构建出一模一样的环境。这样的一套东西，才算得上真正的“基础设施”。

1.3 什么人适合，什么场景不适合

如果你符合下面任意一条，openrig 这套思路都值得参考：

• 你经常要跑 7B 到 70B 量级的开源模型，希望不依赖外部接口；
• 你在相对私密的环境里做开发，数据出内网不方便；
• 你想长期做模型评测、Prompt 实验、数据清洗，需要稳定可控的执行环境；
• 你想学推理引擎的工作原理，想在本地调 vLLM、量化、并发这些参数。

但我也得说清楚它的边界。如果你不是命令行爱好者，连 BIOS 都不想碰，那还是老老实实用云服务或者买品牌工作站更省心。如果你需要的是几百路并发的高可用服务，也不是一台机器能解决的，应该去规划多机集群。openrig 的定位从来不是替代数据中心，而是给团队和个人一个可复现、可掌控的本地推理基座。

2. 硬件选型：先算显存，再谈显卡

2.1 模型显存到底怎么算

我见过不少人买显卡的时候只盯着“多少 G 显存”，买回来才发现跑不动想要的长上下文，或者并发一高就 OOM。显存不是拍脑袋定的，它是可以算出来的。

模型推理时的显存占用主要由三块组成：模型权重、KV Cache、框架自身开销。权重的计算公式很直观：参数量乘以每个参数的字节数。FP16 下每个参数占 2 字节，INT8 占 1 字节，INT4 大概占 0.5 字节。举个例子，一个 70 亿参数的模型，FP16 权重就要 14GB，INT8 大约 7GB，INT4 大约 4GB。这还没有算 KV Cache 和运行开销。

KV Cache 的占用和上下文长度、并发数直接相关。为了不把简单问题复杂化，你可以先用一个经验倍数估算：对于一个 7B 模型，开启 8K 上下文并保持 4 到 8 路并发时，KV Cache 大概会多占 2 到 4GB。如果是 70B 模型，多占 8 到 16GB 也很常见。所以最稳妥的做法是：先用权重大小 + KV Cache + 2 到 3GB 的余量来定显存需求，再去挑卡。

下面这张表是我常用来做需求判断的粗略参考：

2.2 核心部件选择思路

显卡是整台机器的心脏，但 CPU、主板、内存和电源同样不能乱来。很多人攒机有个误区：GPU 越贵越好，其他配件能省就省。真到用的时候才发现主板 PCIe 通道不够，第二张卡只能跑 x4 速度，或者电源功率不够导致高负载直接重启。

我的选型原则是：先定 CPU 和主板，再定显卡，最后按峰值功耗选电源。CPU 不用追求顶级的核心数，但要关注 PCIe 通道数量。单卡还好，双卡的话至少需要 CPU 提供两组 PCIe x8 以上的通道。如果预算允许，AMD 的消费级平台 X670E 或者 Intel 的 Z790 都能满足大多数双卡需求，但更加严肃的场合最好考虑工作站平台，比如 Threadripper 或 Xeon W。

内存方面，我会直接上 32GB 起步，跑 14B 以上模型时 64GB 会更从容。虽然推理主要吃显存，但系统内存负责加载模型、缓存数据集、跑 CPU 侧的 pre-processing。内存不够的话，加载一个大权重文件都可能卡半天。服务器平台支持 ECC 内存，稳定性更好，但消费级平台也不强求。

存储建议至少一块 1TB 级别的 NVMe 固态，专门放模型权重和一个 4TB 左右的机械盘或大容量 SATA SSD 放数据集和检查点。模型文件动辄几十 GB，冷加载从机械盘读和从 NVMe 读完全是两种体验。电源则要留足余量，计算方式是“CPU 功耗 + 显卡 TGP + 其他设备功耗”，再乘以 1.3 作为冗余。比如 4090 的 450W 加上 CPU 的 150W 加上其他 100W，总共 700W，那么 900W 到 1000W 的金牌电源比较合理。

散热我始终推荐风冷加良好的风道，不建议盲目上水冷。开放式设备可以放在机架或者桌面上，只要前后风道通畅、环境温度别太高即可。很多人买了水冷，结果整机温度没降多少，还多了一堆潜在的漏液风险。

2.3 两套预算方案

我整理了两种我实测可行的配置思路，价格按照 2025 年的市场行情估算，会随行情浮动。

入门方案，以跑 7B 到 14B 的量化模型为主：

进阶方案，以跑 32B 量化模型、多路服务和 LoRA 微调为主：

有一点我要特别提醒：不要为了看起来“专业”去盲目买品牌工作站整机。整机溢价高，而且很多时候散热设计和扩展槽位反而没有DIY平台灵活。真正值得投钱的是显存、电源和散热。外观、机箱、RGB 这些，都属于最后有闲钱再考虑的项。

3. 软件栈与推理引擎怎么选

3.1 驱动与系统的基线

硬件到齐以后，软件环境就是决定体验的关键。我自己习惯用 Ubuntu Server 24.04 LTS，不用带桌面环境的版本，能省下几百 MB 内存和很大一部分驱动冲突的麻烦。如果你对 Linux 命令不熟悉，Ubuntu 桌面版也可以，只是后面做服务化的时候还是要学会用 systemd。

系统装好以后，最重要的就是 NVIDIA 驱动和 CUDA 的匹配。我的建议是先用系统自动识别驱动的工具安装，再手动确认版本。命令大致是这样：

sudo apt update sudo apt install ubuntu-drivers ubuntu-drivers-common sudo ubuntu-drivers devices sudo apt install nvidia-driver-550 sudo reboot nvidia-smi

nvidia-smi能正确输出显卡信息，说明驱动已经工作了。这里注意别自作聪明装一堆独立 CUDA toolkit 的旧版本，除非你明确知道哪个框架需要。现在主流的推理引擎在容器里都自带 CUDA 运行时，宿主机的 CUDA 版本反而不是最关键的。

BIOS 层面有一个值得开的选项叫 Resizable BAR（也叫做 Above 4G Decoding），在部分显卡上能提升一点 PCIe 传输效率。另外如果主板支持，开启 PCIe 的 Native ASPM 和最大功率设置，对长时间稳定运行也有帮助。

3.2 推理引擎分工

很多人第一次接触本地推理，都是被各种名字绕晕：llama.cpp、Ollama、vLLM、SGLang、TensorRT-LLM，到底该用哪个？其实它们各有分工，没有必要互相替代。

llama.cpp 是最底层的纯 C++ 实现，对 CPU 和 GPU 混合推理支持很好，几乎所有模型量化格式 GGUF 都跟它强绑定。它灵活，但使用门槛偏高，适合想研究底层原理的人。

Ollama 本质上就是把 llama.cpp 封装成一条命令的服务。对新手极其友好，一条ollama run就能把模型拉下来跑。它的短板在于动态批处理和并发控制不如 vLLM 精细，真到了高并发在线服务，经常会有第一个 token 延迟不稳定的问题。

vLLM 是目前最值得当主力用的推理服务引擎。它用 PagedAttention 做 KV Cache 管理，显存利用率大幅提高，连续批处理可以同时服务多路请求，而且自带 OpenAI 兼容的 API 接口。你写代码时只需要把 base_url 指向本地服务，原来用 OpenAI SDK 的代码几乎不用改。

SGLang 和 TensorRT-LLM 则属于进阶选项。SGLang 在多轮推理和结构化输出场景下有优化，TensorRT-LLM 能针对具体硬件做极致优化，但它俩对操作水平和模型适配的要求更高。我这里不多展开，等你在 vLLM 上跑熟了再折腾不迟。

做个简单的对比表格：

我目前的 openrig 实践是双轨并行：日常做实验、跟模型聊天用 Ollama，正式对外提供 API 服务用 vLLM。如果你只想学一个，优先学 vLLM，因为你的代码最终是要同时服务多个使用者的。

3.3 量化：质量与显存之间的平衡

理解量化，是本地玩模型绕不过去的一关。简单说，量化就是减少表示每个权重所需的比特数。FP16 精度高、占显存多，INT8 和 INT4 占显存少、但理论上会有精度损失。

这里有个常见的偏见：认为量化一定导致效果明显变差。实际测下来，7B 模型在 INT8 下和 FP16 几乎看不出质量差异，到 INT4 才会在复杂推理任务上出现退化。所以如果你是做代码生成、数学推理，推荐至少用 INT8 或 FP8；如果只是普通聊天、摘要、分类，INT4 的 GGUF 也能胜任。

不同格式之间也有讲究。ollama 和 llama.cpp 原生偏好 GGUF；AWQ 和 GPTQ 是两常见显卡上使用的 4-bit 方案；FP8 则是新一代数据中心显卡支持的格式。我的建议是，前期不要同时装一堆格式。先用一个量化等级，跑通整个流程，再逐步对比效果。你可以从 HF 模型仓库下载已经量化好的权重，也可以本地用工具转换，但转换过程有额外的验证成本。

4. 实操：从装机到跑通 API 的完整记录

4.1 BIOS、系统与驱动

我把完整的实操过程记录在这里，包括我当时踩的坑和调整过的命令。先从 BIOS 开始。开机按 Del 或 F2 进入 BIOS，找到 Advanced 或 PCIe 相关选项，开启 Above 4G Decoding 和 Resizable BAR。如果你确定只用 Linux 不用 Windows，可以先关掉 CSM，避免后面磁盘格式化的兼容问题。

系统安装阶段，我强烈建议在安装 Ubuntu Server 时就把磁盘分区规划好。我会把系统盘单独分出来，模型权重和数据集统一放在/data目录下，并用另一个独立分区挂载。这样以后系统崩溃重装，模型文件不会跟着遭殃。

驱动安装的过程，我实际用的是：

sudo apt update sudo apt install ubuntu-drivers sudo ubuntu-drivers devices sudo apt install nvidia-driver-550 sudo reboot nvidia-smi

这里有一个容易踩坑的地方：Ubuntu 的 apt 源里可能有多个驱动版本，默认推荐的可能不是你想要的。如果你要跑最新的 CUDA 容器，建议选择-open分支或者官方runfile安装方式。只要 nvidia-smi 能显示出当前驱动和 CUDA 版本，宿主机这一层就算过了。

4.2 容器化 GPU 运行环境

宿主机搞定了，下一步就是把推理引擎装进容器。容器化最大的好处是隔离和可移植：你在笔记本上调试好的镜像，推到服务器上跑起来效果一样，不会因为系统库版本不同而翻车。

安装 Docker 和 NVIDIA Container Toolkit 的命令如下：

curl -fsSL https://get.docker.com | sh sudo apt-get install -y nvidia-container-toolkit sudo systemctl restart docker docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi

最后一条命令如果能在容器里看到显卡信息，就说明 GPU 被正确传递进了容器。这一步经常有人翻车，因为 nvidia-container-toolkit 的版本太旧或者没重启 Docker，导致容器里找不到显卡。

4.3 模型下载与量化格式转换

模型权重是整台机器的“燃料”。以 Qwen2.5-7B-Instruct 为例，我会用 Hugging Face CLI 直接下载完整权重：

pip install -U huggingface_hub huggingface-cli download Qwen/Qwen2.5-7B-Instruct --local-dir /data/models/qwen2.5-7b

如果你的网络条件不理想，可以把下载端点切到国内镜像环境变量：export HF_ENDPOINT=https://hf-mirror.com，然后再执行同样的命令。下载完成后，一定要检查目录里是否包含config.json、tokenizer.json、*.safetensors这些关键文件，缺了任何一样 vLLM 都起不来。

如果你用的是 Ollama，那就更简单了，直接：

ollama run qwen2.5:7b

Ollama 会自动处理下载和量化。但它拉到本地的是自己管理的 GGUF 格式，和 vLLM 需要的原始 huggingface 格式不完全一致，所以我才建议正式服务用 vLLM 时，走 huggingface-cli 下载原始权重。

4.4 vLLM 服务启动与验证

模型权重放到本地以后，启动 vLLM 服务只需要一条 docker run 命令：

docker run -d --name openrig-vllm \ --gpus all \ -v /data/models:/models \ -p 8000:8000 \ --ipc=host \ vllm/vllm-openai:latest \ --model /models/Qwen/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9

几个参数我解释一下。--max-model-len决定模型最多支持多长的上下文，我刚上手时把它设得很高，结果显存直接爆掉。后来老老实实按模型的建议长度设，反而稳定很多。--gpu-memory-utilization 0.9表示 vLLM 最多可用显存的 90%，剩下的留给驱动和并发运行时的开销。如果你显存比较紧张，可以下调到 0.8。

启动之后，用 curl 做一个最简单的接口测试：

curl -X POST http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"qwen2.5","messages":[{"role":"user","content":"你好，介绍一下你自己"}],"max_tokens":200}'

看到返回了一段choices内容，就说明服务跑通了。这时候你可以在 Python 里用 OpenAI SDK 调用本地服务：

from openai import OpenAI client = OpenAI(base_url="http://127.0.0.1:8000/v1", api_key="local") resp = client.chat.completions.create( model="qwen2.5", messages=[{"role": "user", "content": "解释一下张量并行"}], max_tokens=500, ) print(resp.choices[0].message.content)

这种写法我特别喜欢，因为代码里只改一个 base_url，就可以在云端 API 和本地 openrig 之间切换，测试的时候完全不受限流影响。

4.5 开机自启动和日常管理

服务能跑起来只是第一步，机器重启以后能不能自动恢复，才真正决定这个东西能不能用。Docker 本身支持重启策略，在创建容器时加上--restart unless-stopped就能让容器在 Docker 启动后自动拉起。如果你之前没加这个参数，可以用docker update --restart unless-stopped openrig-vllm补上。

如果你希望更精细地控制，比如先等数据盘挂载、再启动容器、再检查端口健康，就可以用 systemd 写服务单元。但我的实际经验是，只要磁盘挂载放在/etc/fstab里并且能正常开机自动挂载，Docker 的 restart policy 已经能满足九成需求。

日常管理方面，我习惯定期看这几个指标：

nvidia-smi # 显存占用、温度、功耗 nvtop # 实时查看 GPU 利用率 docker logs openrig-vllm # 查看推理服务日志 df -h /data # 确认模型磁盘空间

养成定期看日志的习惯，很多问题在你肉眼发现之前就已经写在日志里了。

5. 常见问题与性能排查实录

5.1 为什么 GPU 利用率上不去

我见过很多朋友开心地启动服务以后，发现 GPU 利用率只有 20%，就觉得硬件被人坑了。其实推理场景和训练不一样，训练是持续计算，GPU 能一直吃满；推理则是“预填充 + 解码”两段式，预填充阶段会把用户的 Prompt 一次性算完，解码阶段是逐个 token 生成，期间 GPU 有大量等待。

如果你的并发请求很少，模型生成速度快，那么 GPU 利用率低是正常的。想提高利用率，最简单的方法就是用 vLLM 这类支持连续批处理的引擎，把并发数拉高，让多个请求挤在同一个 batch 里算。你可以观察--max-num-seqs这个参数，默认值不够时可以调高，比如 8 或 16。但注意每提高一个并发，KV Cache 的占用也会上涨，要重新核算显存压力。

还有一个容易忽略的点：如果你的模型用了 CPU offload，哪怕只 offload 了一部分层，推理速度也会被 PCIe 带宽拖后腿。这时 GPU 利用率也许正常，但总吞吐就是上不去。

5.2 显存溢出怎么办

显存溢出的错误信息五花八门，但原因基本就那几种：上下文设得太长，并发设置太高，模型权重加 KV Cache 已经超出显存。

我最常用的排查命令是：

nvidia-smi -l 1

实时刷新观察显存和 GPU 利用率。如果是 vLLM 报 OOM，通常需要降低--max-model-len、降低--gpu-memory-utilization、减少最大并发--max-num-seqs。如果是 Ollama，停掉服务后修改OLLAMA_KV_CACHE_SIZE或者换一个更低位数的量化模型。总而言之，显存是有限的，你要么降低总模型工作量，要么给缓存释放更多空间。

5.3 双卡不被识别或速度减半

插了两张卡，但系统只识别一张，或者第二张卡跑起来速度明显不对劲，大概率是 PCIe 通道分配问题。你可以用：

nvidia-smi topo -m lspci -vvv | grep -i "LnkCap\|LnkSta"

去看每张卡实际跑在 PCIe 什么速率上。如果本来应该是 x16 的插槽只跑出 x4，先在 BIOS 里检查 PCIe 插槽拆分方式，再检查是不是第二张卡插错了槽位。很多消费级主板只有第一个 x16 槽能跑满速，第二根槽実際是 x4，这个没法靠软件解决，只能换主板或换插法。

双卡做推理时，如果不是特别大的模型需要张量并行，我更推荐把两个不同模型分别放在两张卡上，然后用CUDA_VISIBLE_DEVICES来控制进程各自用哪张卡，这样可以避免卡间通信的额外开销。

5.4 温度、功耗与降频

显卡长时间高负载会发热，温度超过阈值就会降频，推理速度直线下降。我的实测经验是，415W 的旗舰卡在密闭机箱里如果风道不好，跑三分钟就能摸到温度墙。

最简单的解决办法是限制功耗上限，牺牲一丁点峰值性能换稳定输出：

nvidia-smi -pl 350 # 将显卡功耗限制在 350W nvidia-smi -lgc 200,2000 # 锁定 GPU 频率范围

这在实际部署中很有用。尤其是多卡机器，限制功耗能明显降低机箱内温度，让所有卡都维持在一个更健康的工作频率，整体吞吐反而比单卡顶着温度墙跑还高。

5.5 排查速查表

这张表是我实际服务中反复遇到的，你可以先存下来，等出了问题再回头对照。

最后再分享一点个人体会。最开始我把 openrig 跑起来时，总是想一步到位：上最大的模型、开最长的上下文、堆最多的并发，结果三天两头 OOM。后来我学会了反过来设计：先定显存上限，再反推能服务的模型规模、并发数和上下文长度，反而一切都顺畅了。然后把整套配置写进 git 仓库后，哪怕换了一块显卡，我半天就能把环境恢复到和之前一模一样。如果你也准备搭一台开放推理机，我的建议是用一半预算买好的电源和散热，先跑通一个小模型，再逐步往上加。这个项目的意义不在于机器本身有多贵，而在于你对这套系统有完全的掌控力，每一步都知道为什么这么做。