去年下半年我把工作重心从纯算法转向了基础设施，一直在折腾一件事：把手头几块散装的GPU拼成一台能稳定跑推理服务的机器。前前后后换了三版方案，踩了无数坑之后，算是整理出了一套可以完整复现的搭建思路。这套思路我给它起了个名字叫openrig，核心其实就是围绕开源硬件参考设计和软件部署栈，把“从裸机到模型服务”的整条链路打通。如果你也想自建一台AI推理服务器，或者公司小团队想搞一套私有化的推理环境，这篇文章应该能帮你省下不少弯路。

先说清楚一件事：openrig不是某个现成的商业产品，而是一种工程化的参考方案。它解决的核心问题有三个——GPU硬件怎么选型才不会互相拖后腿、系统软件栈怎么装才能一次跑通、模型服务框架怎么配才能把GPU算力吃满。下面我按照实际搭建的顺序，把从硬件计算到软件部署再到故障排查的完整过程拆开讲。

1. 自组推理服务器，先想清楚要解决什么

1.1 为什么自己攒而不是买整机

大部分团队一开始都会纠结这个问题。整机服务器的优势是省心，开箱即用，但价格里通常含了相当高的品牌溢价。自己攒的优势不在省钱，而在可控性——你可以精确卡在“够用”和“贵”的临界点上，把预算花在真正影响推理性能的部件上。

我实测下来的感受是，自组方案更适合两类人：

• 手头已经有1到4块闲置GPU，想快速把它们变成能对外提供服务的推理节点；
• 团队需要私有化部署大模型，但预算有限，买不起整机柜，又不想用云上按秒计费的GPU实例来跑长期负载。

只要GPU数量不超过8卡，自组和使用整机在稳定性和性能上的差距其实已经很小了。反过来，超过8卡之后，PCIe拓扑、供电冗余、散热设计都会变得非常敏感，那时候再考虑上架式整机也不迟。

1.2 openrig思路的三个关键边界

我把这套方案拆成三层来看，你会发现每一层的边界都很清晰。

硬件层：重点是PCIe通道分配、电源余量、散热风道和机架结构。这一层决定了你的GPU能不能被系统完整识别、满载时会不会降频或者重启。

系统层：包括操作系统选型、驱动版本、容器运行时和GPU虚拟化支持。这一层的核心目标是让上层框架无感地使用所有显存。

服务层：模型推理引擎的选型与调度参数优化。这一层直接决定你的请求吞吐量、首token延迟和显存利用率。

三层各管各的，排查问题的时候才能快速定位。我见过太多人一遇到推理慢就跑去调模型参数，结果查了半天发现是PCIe链路只跑了一半带宽，这种系统性思维上的坑，最好一开始就避开。

1.3 这套方案不适合谁

直说，openrig这套思路不是万能的。如果你的场景是千万级日活的在线推理，那直接用云厂商的托管推理服务会更合理，因为弹性伸缩和可用性保障自建方案很难追平。再比如，如果团队里没有人愿意折腾Linux和容器化，那自建只会变成长期运维负担。我在下面的分享默认你已经有基本的Linux操作能力和Docker使用经验，如果没有，建议先补基础再看实战部分。

2. 硬件选型里那些容易算错的账

2.1 PCIe通道是第一约束，不是CPU核数

很多人组GPU服务器时第一反应是“CPU要够强”，但实际上对于推理场景，CPU更多是辅助角色。真正决定多卡能否同时满速运转的，是CPU的PCIe通道数、主板的PCIe插槽拆分方式和GPU之间的通信拓扑。

先看一个具体数字。目前主流工作站CPU的PCIe通道数一般在64到128条之间，消费级CPU通常在20到28条之间。一张RTX 4090或者A6000要占PCIe 5.0 x16，也就是16条通道；四张卡就是64条通道，加上NVMe SSD要占PCIe x4，万兆网卡要占PCIe x8，你会发现通道数很容易就吃光了。

所以选型时第一件事不是看GPU天梯图，而是数清楚你手头主板的PCIe插槽布局。我踩过的一个典型问题是：四卡插满后发现两两分不到同一条PCIe Root Port上，导致两张卡实际只能跑在x8速率。所以主板要选支持PCIe分叉的型号，也就是能在BIOS里把x16拆成x8+x8或者x4x4x8的板子。

2.2 电源余量计算实例

电源是另一个容易想当然的部分。GPU的TDP只是“热设计功耗”，实际瞬时功耗能冲到1.3倍以上。以四卡方案为例，我按下面的公式粗略计算过：

• GPU满载合计功耗：4 × 350W = 1400W
• CPU平台功耗（含主板、内存、风扇）：200W到300W
• NVMe/网卡等外设：50W
• 总负载：1400W + 250W + 50W = 1700W
• 预留20%到30%的余量：1700W × 1.25 ≈ 2125W

所以电源至少选额定2200W以上，并且要有两路独立12V输出，避免所有GPU挤在一路供电上。如果你只上两张卡，功率需求会低很多，但也不能随便拿一个1200W消费级电源糊弄。GPU的瞬时负载会让电源进入保护状态直接断电重启，这种故障极其隐蔽，后面我会专门讲排查。

2.3 机箱与散热风道

推理服务器的散热压力比训练小，因为推理通常是间歇性高负载，但它有一个特殊问题：多卡密集安装时，GPU之间的间距决定散热效果。

以4卡为例，我强烈建议选择支持前后风道的高塔式机箱或4U机架机箱，并且保证每一个PCIe槽位之间至少留一个空槽位用于进风。开机架式方案时，前置风扇的静压值比最大风量更重要——因为PCIe区是密集阻碍物，需要的是“穿透力”而不是“大而不强”的气流。

另外，GPU下吹式散热在机箱内容易形成热回流，我实测过同样的负载下，开放式散热卡和涡轮式散热卡在塔式机箱里能差出8到12度的核心温度差。如果你预算够，优先选涡轮散热版本的GPU，或者直接上水冷改造套件。

2.4 一个反直觉的选型建议

很多人会为了“性能”去追最新旗舰卡，但如果目标是跑长驻推理服务，我反而建议关注显存带宽和互联能力。推理的瓶颈往往不在算力峰值，而在显存带宽和KV Cache容量。

举个例子，同样跑7B参数的模型，显存带宽高的卡在连续并发请求下的token生成速度可以比带宽低的卡快近一倍，而单看FP16算力两者可能只差20%。所以选卡之前，先去把你计划的模型参数量乘上1.2左右的冗余系数，得出最小显存需求，再在候选卡里比较显存带宽，这个顺序基本不会走偏。

3. 从裸机到模型服务的完整部署链路

3.1 系统安装的隐藏要点

Ubuntu Server版本我选22.04 LTS，理由是对新GPU内核驱动的支持比较齐全，加上社区资料多，遇到问题容易搜到。安装时有两个细节容易忽略：

• 分区时建议把 /var/lib/docker 单独挂一块大容量数据盘，因为模型权重文件、容器镜像和日志会以惊人的速度占空间；
• swap分区建议保留，不要因为“内存大就不需要”直接关掉。推理服务在请求尖峰时偶尔需要一点swap做缓冲，完全没有swap的话OOM Killer会直接干掉你最不该杀的进程。

3.2 驱动与CUDA的版本匹配问题

这一步最容易踩坑。NVIDIA驱动的版本本身不直接决定CUDA版本，但驱动必须等于或高于运行时的CUDA最低要求版本。我建议直接把驱动刷到当前主线版本，也就是在NVIDIA官网按照你的GPU型号和操作系统选出来的推荐版本，不要用古老驱动硬配新CUDA。

装完驱动后，用nvidia-smi先确认所有GPU都能被识别。如果发现GPU数量不对，优先检查PCIe插槽接触和电源供电，不要急着重装驱动。这个问题我遇到过太多次，而且每次原因都不同，后面单独讲。

3.3 容器化部署而不是裸机装库

模型服务的依赖链太复杂了。不同框架对CUDA、cuDNN、PyTorch的版本要求各不相同，一旦在裸机上装了一套，再想升级或者跑另一个框架，就很容易冲突。这个问题的标准解法是Docker加NVIDIA Container Toolkit。

我没有系统安装CUDA工具包或PyTorch的GPU版本，就通过如下步骤让容器能访问GPU：

1. 安装 Docker Engine，配置国内镜像源（具体源地址以自己网络环境为准）；
2. 安装 nvidia-container-toolkit，然后重启 Docker 服务；
3. 用以下命令验证容器内显卡是否可见：

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

能正常输出显卡信息，说明容器运行时已经打通了。这一步完成之后，上层模型框架就都是容器内的私有依赖了，主系统的环境可以干净到只需驱动和Docker就能跑全年不崩。

3.4 推理框架选型：vLLM还是SGLang

目前主流选择是vLLM，它对显存管理做了特别好的优化——通过PagedAttention把KV Cache按页管理，显存利用率比传统方案高得多。它自带OpenAI兼容的API服务，很多应用可以直接把base_url改到本地端口就能切换。

我建议新项目直接从vLLM起步，因为它的社区最活跃，模型兼容性也最好。SGLang在多轮对话和结构化输出方面有亮点，但它的配置复杂度更高，适合你已经跑通了vLLM之后再做尝试。另一个思路是使用TGI作为备选，但实测在同样的加载环境下，vLLM的吞吐和首token延迟通常指标更好看。

4. 部署中高频故障的完整排查链路

4.1 GPU识别不全，从硬件链路到软件层的排查顺序

如果nvidia-smi只显示6张卡而你明明插了8张，不要慌，按下面的顺序排查，每步都有明确的检查点。

第一步：检查PCIe链路状态。

用lspci | grep -i nvidia看所有卡是否都被系统枚举到。如果某张卡在lspci里缺失，问题100%在硬件层：要么没插到底，要么供电不足导致该卡没有上电。如果lspci能看到但nvidia-smi看不到，说明驱动加载阶段被卡住了，看dmesg | grep -i nvidia会有关键报错。

第二步：检查供电完整性。

这个坑我遇到过，一条8pin供电线接了四张卡，平时低负载没事，一跑推理负载就随机掉卡。PCIe的插槽供电只提供75W，剩余功率必须走外接供电线。可靠的做法是一张卡接一条独立的外部供电线，不要用一分二转接线共享同一路输出。

第三步：检查驱动与固件。

如果设备和供电都没问题，可以试着重装驱动，但重装前先用nvidia-smi --gpu-reset确认不是运行中驱动出现了错误状态。还有一个容易被忽略的点是主板BIOS版本太旧，有些主板要更新BIOS才能正确识别新GPU的PCIe ID。我有一块平台升级BIOS之后才识别出第二张卡，这个经验值得记住。

4.2 推理吞吐上不去的常见根因

硬件全部识别正常，但压测时吞吐远远低于预期，这种情况我在多个配置上都遇到过。定位思路是把自己的期望值先量化，不要凭感觉判断“快不快”。

先看理论边界：一张RTX 4090在FP16下推理7B模型，配合vLLM的连续批处理，每秒能生成的token数大约在120到180之间。如果你的并发请求很少，吞吐跑不进这个区间，优先查两个配置。

一是张量并行（Tensor Parallel）配置。模型并行切分之后，每张卡之间要做同步通信。如果通信走的是PCIe而不是NVLink，通信开销会吃掉很多性能。实测下来，4卡以内如果卡间带宽是PCIe 5.0 x16，张量并行还算是划算的；但如果是PCIe 4.0或者x8通道，可能还不如单卡管单模型。

二是并发请求数设置。vLLM默认的--max-num-seqs值是256，但实际显存如果不够，系统会主动降低并发。可以先用--gpu-memory-utilization把显存利用上限调高到0.95再测试，很多时候“吞吐上不去”只是默认参数太保守。

4.3 显存OOM的正确应对姿势

推理服务最常见的问题是“CUDA out of memory”。大部分人会立刻想到降低批次大小，但正确的思考顺序应该是先确认显存被谁吃掉了。

推理时显存主要消耗在两个地方：模型权重和KV Cache。用nvidia-smi看显存占用只能看到总量，想要细分得看vLLM的日志。vLLM启动时会打印每一层的KV Cache分配情况，如果KV Cache占用已经偏小，说明模型权重加输入序列的预留空间出了问题。

我的调法是这样的：先用--max-model-len控制输入输出的最大token长度，模型按4096上下文启动，然后观察KV Cache占用率。如果还有剩余显存，可以放宽上下文长度或者增大并发。如果直接OOM，优先调低--max-model-len，而不是调低batch size。因为在PagedAttention的机制下，KV Cache是按页分配的，长度限制会直接影响可分配的cache页数量。

4.4 服务器无故重启或掉卡

这可能是最难排查的硬件故障，因为它没有日志，或者日志里只有 “temperature above threshold” 之类的记录。我总结下来，掉卡和重启的概率分布如下表：

尤其要注意第三条，我用两个机箱、四条供电线来回试了两周才发现是最靠内的那条供电端子松了，看起来插紧实了但内部触点已经氧化。用万用表量一下12V引脚电压是最可靠的确认方式。

5. 把GPU算力真正吃满的性能调优

5.1 张量并行：什么时候该用，什么时候不该用

很多人在模型大过单卡显存后，第一反应就是开张量并行。但张量并行的代价是每层计算都要做跨卡通信，通信比例会随着显卡数量增加而上升。实测数据来看：

• 2卡张量并行时，通信开销约占10%到15%；
• 4卡张量并行时，通信开销可能占到25%到30%；
• 如果设备之间只是PCIe连接而没有NVLink，开销还要再高。

所以我的经验是：如果单卡能把模型装下，优先用数据并行加请求分发的模式，每张卡各管一份请求副本；只有在单卡装不下的场景才启用张量并行。数据并行在vLLM里可以通过--tensor-parallel-size 1加--pipeline-parallel-size 1配合多实例启动来实现，配合前置负载均衡，效果有时比张量并行更稳定。

5.2 量化策略：显存、速度与质量的三方平衡

量化是把模型从FP16降到INT8或者INT4，从而减少显存占用、提升推理速度的关键手段。但量化也分三六九等，直接粗暴的PTQ（后训练量化）在低比特位时会有明显质量损失，而AWQ和GPTQ这类感知量化方法会好很多。

我实测的配置是这样的：

我的建议是把INT8作为默认选项，尤其是服务场景，先保证质量绝对无感知，再去求速度和容量。vLLM启动时加--quantization awq就可以加载AWQ预量化模型，前提是你先把模型用AWQ工具转换好，或者直接下载现成的AWQ版本。

5.3 连续批处理的参数调整

vLLM的连续批处理机制是它吞吐量的核心武器，但默认参数不一定适合你的硬件。几个关键参数我都在实操中调过：

• --max-num-seqs：控制一个batch里最多同时处理的请求数，上限同时受显存和算力约束。值太小吞吐低，值太大单请求延迟变高；
• --max-paddings：在prefill和decode阶段之间的切换频率，太高会浪费算力在padding上；
• --gpu-memory-utilization：默认0.9，我通常调成0.95到0.97，因为容器运行时和框架本身预留的显存并不需要太多；
• --enable-prefix-caching：如果你有大量共享系统提示词的请求，开启前缀缓存后吞吐能翻倍，这个参数对RAG类应用特别重要。

实际测试的一个案例：两个用户并发问同一个系统提示词下的不同问题，关闭前缀缓存时两个请求都要从头计算上下文，开启之后第二个请求直接复用了第一个的前缀计算结果，计算量少了一大截。

5.4 调优前后的实测数据对比

贴一组我自己的实测数据供参考。配置是四卡运行7B模型，用vLLM作为推理后端，压测工具发50路并发请求。

主要改动是三处：把--gpu-memory-utilization从0.9提到0.95，开启--enable-prefix-caching，以及把量化精度从FP16切到INT8。没有改任何模型结构，也没有超频硬件。这说明推理优化的空间很多时候不在模型端，而在服务配置和显存管理端。

6. 一些关于长期稳定运行的额外心得

到现在，机器已经连续跑了一个多月，中间只因为一次机柜断电重启过。我发现稳定运行的关键其实不是某一次调优，而是把整个环境的“可变因素”降到最低。

我把整套搭建过程固化成了脚本，包括PCIe链路检查、供电验证、驱动安装、Docker配置和vLLM启动命令。这样每次重装系统或者加卡扩容，都能在一个小时内恢复到同一状态。这种“可复现性”是我觉得openrig这套思路最值钱的地方——毕竟一次性把机器调好不算本事，真正有价值的是你再也没被环境问题折腾过。

最后分享一个小技巧：建议把nvidia-smi的输出定时写入日志文件，通过 cron 每个小时记录一次温度、功耗和显存占用。这样出了问题之后，你能直接翻看故障发生前几小时的曲线，很多时候掉卡、降频这类问题的原因一眼就能看出来。我之前排查随机重启问题就是靠一条温度异常抬升的日志锁定了散热风道堵灰的位置。

如果你也打算自组推理服务器，我建议根据我上面的思路从一张最小配置开始试：先确认全部硬件能稳定识别并跑通一个小模型的推理，再做多卡扩展。这样每次只引入一个变量，出了问题就知道怪谁。希望这次的分享能帮你少绕几个弯子。