尧图网页设计 
这些年做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 权重就要 14GBINT8 大约 7GBINT4 大约 4GB。这还没有算 KV Cache 和运行开销。KV Cache 的占用和上下文长度、并发数直接相关。为了不把简单问题复杂化你可以先用一个经验倍数估算对于一个 7B 模型开启 8K 上下文并保持 4 到 8 路并发时KV Cache 大概会多占 2 到 4GB。如果是 70B 模型多占 8 到 16GB 也很常见。所以最稳妥的做法是先用权重大小 KV Cache 2 到 3GB 的余量来定显存需求再去挑卡。下面这张表是我常用来做需求判断的粗略参考目标场景典型模型推荐显存可参考的显卡入门推理和对话7B~8B 量化6~8GBRTX 3060 12G / RTX 4060 Ti 16G主力推理14B~32B 量化16~24GBRTX 3090 24G / RTX 4090 24G长上下文或微调32B~70B 量化48GB 以上双卡 3090/4090 或单卡 48G 专业卡生产级多路服务70B 以上量化64GB 以上多卡集群配合 vLLM 张量并行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 的量化模型为主配件选择备注CPUAMD Ryzen 7 77008 核足够PCIe 通道够用主板B650 或 X670E为后续双卡留余地内存DDR5 32GB两个 16G 组双通道显卡RTX 4060 Ti 16G16G 显存是这条预算线的核心存储1TB NVMe 2TB 机械系统与模型分离电源650W 金牌单卡绰绰有余整机预算约 1.2~1.6 万元不含显示器与键鼠进阶方案以跑 32B 量化模型、多路服务和 LoRA 微调为主配件选择备注CPUAMD Ryzen 9 9950X16 核多任务处理从容主板X670E双 PCIe x16 物理插槽内存DDR5 64GB长上下文和数据集缓存更稳显卡RTX 4090 24G 或双卡组合单卡 24G 入门双卡 48G 深入存储2TB NVMe 4TB SATA SSD模型加载速度明显更快电源1200W 金牌以上双卡必须留足余量整机预算约 4 万到 6 万元主要差价在显卡有一点我要特别提醒不要为了看起来“专业”去盲目买品牌工作站整机。整机溢价高而且很多时候散热设计和扩展槽位反而没有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-sminvidia-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 上跑熟了再折腾不迟。做个简单的对比表格引擎优势短板适合场景llama.cpp跨平台、支持CPU混合推理并发批处理弱调试、低资源设备Ollama封装修得极好一条命令启动精细控制有限原型验证、个人体验vLLM高并发、显存利用率高、OpenAI兼容对显存管理要求理解在线服务、评测批量跑SGLang多轮场景优化好社区和生态相对年轻进阶服务TensorRT-LLM特定硬件性能极限配置复杂上线前的最终压榨我目前的 openrig 实践是双轨并行日常做实验、跟模型聊天用 Ollama正式对外提供 API 服务用 vLLM。如果你只想学一个优先学 vLLM因为你的代码最终是要同时服务多个使用者的。3.3 量化质量与显存之间的平衡理解量化是本地玩模型绕不过去的一关。简单说量化就是减少表示每个权重所需的比特数。FP16 精度高、占显存多INT8 和 INT4 占显存少、但理论上会有精度损失。这里有个常见的偏见认为量化一定导致效果明显变差。实际测下来7B 模型在 INT8 下和 FP16 几乎看不出质量差异到 INT4 才会在复杂推理任务上出现退化。所以如果你是做代码生成、数学推理推荐至少用 INT8 或 FP8如果只是普通聊天、摘要、分类INT4 的 GGUF 也能胜任。不同格式之间也有讲究。ollama 和 llama.cpp 原生偏好 GGUFAWQ 和 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_ENDPOINThttps://hf-mirror.com然后再执行同样的命令。下载完成后一定要检查目录里是否包含config.json、tokenizer.json、*.safetensors这些关键文件缺了任何一样 vLLM 都起不来。如果你用的是 Ollama那就更简单了直接ollama run qwen2.5:7bOllama 会自动处理下载和量化。但它拉到本地的是自己管理的 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 \ --ipchost \ 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_urlhttp://127.0.0.1:8000/v1, api_keylocal) resp client.chat.completions.create( modelqwen2.5, messages[{role: user, content: 解释一下张量并行}], max_tokens500, ) 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 排查速查表现象常见原因解决办法容器内找不到 GPU未装 nvidia-container-toolkit 或没重启 Docker安装 toolkit 后systemctl restart dockervLLM 启动时报模型不存在权重目录结构不对检查是否包含 config.json 和 safetensors生成内容突然乱码或中断量化位太低或 KV Cache 溢出换高精度格式或调低并发/上下文双卡只有一张工作主板 PCIe 通道不足换主板或直接指定 CUDA_VISIBLE_DEVICES长时间运行后变慢温度墙降频或显存碎片限制功耗、清扫灰尘、重启容器请求响应偶尔特别慢并发队列堆积调高 max-num-seqs 或增加多副本这张表是我实际服务中反复遇到的你可以先存下来等出了问题再回头对照。最后再分享一点个人体会。最开始我把 openrig 跑起来时总是想一步到位上最大的模型、开最长的上下文、堆最多的并发结果三天两头 OOM。后来我学会了反过来设计先定显存上限再反推能服务的模型规模、并发数和上下文长度反而一切都顺畅了。然后把整套配置写进 git 仓库后哪怕换了一块显卡我半天就能把环境恢复到和之前一模一样。如果你也准备搭一台开放推理机我的建议是用一半预算买好的电源和散热先跑通一个小模型再逐步往上加。这个项目的意义不在于机器本身有多贵而在于你对这套系统有完全的掌控力每一步都知道为什么这么做。 开放推理机 OpenRig 搭建指南：硬件选型、量化与 vLLM 实践
这些年做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 权重就要 14GBINT8 大约 7GBINT4 大约 4GB。这还没有算 KV Cache 和运行开销。KV Cache 的占用和上下文长度、并发数直接相关。为了不把简单问题复杂化你可以先用一个经验倍数估算对于一个 7B 模型开启 8K 上下文并保持 4 到 8 路并发时KV Cache 大概会多占 2 到 4GB。如果是 70B 模型多占 8 到 16GB 也很常见。所以最稳妥的做法是先用权重大小 KV Cache 2 到 3GB 的余量来定显存需求再去挑卡。下面这张表是我常用来做需求判断的粗略参考目标场景典型模型推荐显存可参考的显卡入门推理和对话7B~8B 量化6~8GBRTX 3060 12G / RTX 4060 Ti 16G主力推理14B~32B 量化16~24GBRTX 3090 24G / RTX 4090 24G长上下文或微调32B~70B 量化48GB 以上双卡 3090/4090 或单卡 48G 专业卡生产级多路服务70B 以上量化64GB 以上多卡集群配合 vLLM 张量并行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 的量化模型为主配件选择备注CPUAMD Ryzen 7 77008 核足够PCIe 通道够用主板B650 或 X670E为后续双卡留余地内存DDR5 32GB两个 16G 组双通道显卡RTX 4060 Ti 16G16G 显存是这条预算线的核心存储1TB NVMe 2TB 机械系统与模型分离电源650W 金牌单卡绰绰有余整机预算约 1.2~1.6 万元不含显示器与键鼠进阶方案以跑 32B 量化模型、多路服务和 LoRA 微调为主配件选择备注CPUAMD Ryzen 9 9950X16 核多任务处理从容主板X670E双 PCIe x16 物理插槽内存DDR5 64GB长上下文和数据集缓存更稳显卡RTX 4090 24G 或双卡组合单卡 24G 入门双卡 48G 深入存储2TB NVMe 4TB SATA SSD模型加载速度明显更快电源1200W 金牌以上双卡必须留足余量整机预算约 4 万到 6 万元主要差价在显卡有一点我要特别提醒不要为了看起来“专业”去盲目买品牌工作站整机。整机溢价高而且很多时候散热设计和扩展槽位反而没有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-sminvidia-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 上跑熟了再折腾不迟。做个简单的对比表格引擎优势短板适合场景llama.cpp跨平台、支持CPU混合推理并发批处理弱调试、低资源设备Ollama封装修得极好一条命令启动精细控制有限原型验证、个人体验vLLM高并发、显存利用率高、OpenAI兼容对显存管理要求理解在线服务、评测批量跑SGLang多轮场景优化好社区和生态相对年轻进阶服务TensorRT-LLM特定硬件性能极限配置复杂上线前的最终压榨我目前的 openrig 实践是双轨并行日常做实验、跟模型聊天用 Ollama正式对外提供 API 服务用 vLLM。如果你只想学一个优先学 vLLM因为你的代码最终是要同时服务多个使用者的。3.3 量化质量与显存之间的平衡理解量化是本地玩模型绕不过去的一关。简单说量化就是减少表示每个权重所需的比特数。FP16 精度高、占显存多INT8 和 INT4 占显存少、但理论上会有精度损失。这里有个常见的偏见认为量化一定导致效果明显变差。实际测下来7B 模型在 INT8 下和 FP16 几乎看不出质量差异到 INT4 才会在复杂推理任务上出现退化。所以如果你是做代码生成、数学推理推荐至少用 INT8 或 FP8如果只是普通聊天、摘要、分类INT4 的 GGUF 也能胜任。不同格式之间也有讲究。ollama 和 llama.cpp 原生偏好 GGUFAWQ 和 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_ENDPOINThttps://hf-mirror.com然后再执行同样的命令。下载完成后一定要检查目录里是否包含config.json、tokenizer.json、*.safetensors这些关键文件缺了任何一样 vLLM 都起不来。如果你用的是 Ollama那就更简单了直接ollama run qwen2.5:7bOllama 会自动处理下载和量化。但它拉到本地的是自己管理的 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 \ --ipchost \ 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_urlhttp://127.0.0.1:8000/v1, api_keylocal) resp client.chat.completions.create( modelqwen2.5, messages[{role: user, content: 解释一下张量并行}], max_tokens500, ) 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 排查速查表现象常见原因解决办法容器内找不到 GPU未装 nvidia-container-toolkit 或没重启 Docker安装 toolkit 后systemctl restart dockervLLM 启动时报模型不存在权重目录结构不对检查是否包含 config.json 和 safetensors生成内容突然乱码或中断量化位太低或 KV Cache 溢出换高精度格式或调低并发/上下文双卡只有一张工作主板 PCIe 通道不足换主板或直接指定 CUDA_VISIBLE_DEVICES长时间运行后变慢温度墙降频或显存碎片限制功耗、清扫灰尘、重启容器请求响应偶尔特别慢并发队列堆积调高 max-num-seqs 或增加多副本这张表是我实际服务中反复遇到的你可以先存下来等出了问题再回头对照。最后再分享一点个人体会。最开始我把 openrig 跑起来时总是想一步到位上最大的模型、开最长的上下文、堆最多的并发结果三天两头 OOM。后来我学会了反过来设计先定显存上限再反推能服务的模型规模、并发数和上下文长度反而一切都顺畅了。然后把整套配置写进 git 仓库后哪怕换了一块显卡我半天就能把环境恢复到和之前一模一样。如果你也准备搭一台开放推理机我的建议是用一半预算买好的电源和散热先跑通一个小模型再逐步往上加。这个项目的意义不在于机器本身有多贵而在于你对这套系统有完全的掌控力每一步都知道为什么这么做。