几个月前我在收拾自己那台用来跑深度学习实验的工作站时突然意识到一个问题每次换机器、重装系统、帮朋友复制一套环境都会重复踩一遍同样的坑。驱动版本对不上、CUDA路径不对、推理框架和模型格式不兼容——这些事论难度都不高但架不住琐碎和耗时。后来我把自己这套折腾经验整理成了一组可复用的配置模板和部署脚本名字就叫openrig——open rig开放装备。它的初衷很简单无论你手里是什么硬件、有多少预算都能快速搭出一个能跑 AI 全栈环境的工作台。这篇文章就是 openrig 的思路拆解和完整实操记录。openrig 能做什么最直接的三件事一是省掉反复配环境的痛苦二是让手头的显卡真正跑起来而不是吃灰三是把本地模型服务做成一个可以被日常应用调用的接口。它适合刚接触本地大模型的新手也适合手里已经有一堆服务器、想系统整理一下的老玩家。我会从硬件选型、软件栈、部署流程、问题排查一路讲下来每个模块都附带我实测过的参数和踩过的坑。1. 重新理解AI装备openrig的核心思路拆解1.1 为什么“成品工作站”和“纯云方案”都不够用市面上主流的AI开发方案掰着手指头数就三类买整机工作站、租云GPU、直接调托管API。每类都有很明显的账算不平。成品工作站主打省心但厂商会为“省心”收很高的溢价。而且硬件捆绑严重过两年想升级显卡经常发现电源、主板、机箱全都得跟着换。云GPU短期跑实验看起来便宜可一旦跑一个7x24小时的推理服务账单会以肉眼可见的速度压过来。更麻烦的是数据出境风险——你总不想每次把企业内部代码片段发给远程API做补全吧。托管API则更“黑盒”模型微调、prompt策略、上下文管理全被厂商锁死可定制空间非常小。openrig 卡在中间档位自己选硬件、自己组系统但把“从零到可用”的路径标准化。它不追求一台机器解决所有问题而是把整套装备拆成算力、存储、推理引擎、服务编排、前端入口这几个清晰模块每个模块都可以独立替换、独立升级。这种“乐高积木”式的思路是它和我以前那种“按电商整机单照搬”做法的最大区别。1.2 软件定义硬件从配置单到需求推导我理解 openrig 最关键的第一性原理是“软件定义硬件”。传统攒机思维关注的是“CPU i9 还是 i7”“显卡 4090 还是 3090”openrig 更关心的是这台机器要跑什么规模的模型推理并发多大数据量级是多少。一旦把这些问题想清楚硬件选型就变成一道可以推导的算术题而不是凭感觉拍脑袋。以最典型的大语言模型为例模型参数量和显存需求之间有一个粗略换算公式显存需求 ≈ 参数量 × 每参数字节数 × 1.2额外开销系数一个 7B 模型FP16 精度每个参数占 2 字节换算下来大约 14GB 显存如果量化到 int8就降到约 7GBint4 量化甚至不到 4GB。这个公式虽然粗但足以指导选卡方向。我在实际规划中会先把目标模型的参数量和量化精度定下来再反推硬件顺序不要搞反。1.3 分层解耦为什么比“一步到位”更实用openrig 把整个软硬件栈分成独立层次每层可以单独升级这是我在实际维护中体会最深的一点。比如主力卡是 RTX 3090显存 24GB可以先跑 13B 的 4bit 量化模型预算够了换 RTX 4090 时软件栈完全不用动只是调整推理框架里的并发参数。分层的另一个好处是故障隔离。服务编排层挂了不会影响模型文件推理引擎崩了不至于把整个系统拖下水。对个人开发者来说这种“出问题只折腾一层”的体验太重要了。以前我把所有环境装在一个系统里一个依赖崩了能牵连一片重装系统的频率高到怀疑人生。现在所有服务都跑在独立容器里出问题直接重建那一层就行。2. 硬件底座怎么配算力、存储与散热的底层逻辑2.1 算力规划显存才是第一指标算力只能排第二如果只让我给一条选卡建议我会说在预算范围内把显存买满。很多人买卡先看“每秒多少万亿次运算”但对大模型推理和微调来说显存直接决定你能跑多大的模型。算力不够顶多慢一点显存不够是直接跑不起来——这不是速度问题是有没有的问题。做一个更具体的推演。假设目标是在本地跑一个 13B 参数的中文模型这个选择在办公和知识库场景非常实用int4 量化后大约需要 8GB 显存int8 需要 13GB 出头。手里是 12GB 显存的卡就只能走激进量化16GB 以上就会舒服很多。想要跑更大的 32B 或 70B 模型显存需求就直接跳到几十甚至上百GB单卡不够就得考虑多卡组合。模型参数量FP16 推理int8 量化int4 量化7B约14GB约7GB约4GB13B约26GB约13GB约8GB32B约64GB约32GB约19GB70B约140GB约70GB约42GB这还只是模型权重本身实际运行还要算 KV Cache 和框架开销通常再乘 1.2 比较稳妥。至于多卡扩展我的建议是能单卡跑就单卡跑。多卡推理的通信开销、负载分配、显存碎片管理每一步都是坑二卡性能和单卡相比往往达不到两倍反而多了成倍的排查成本。2.2 CPU、主板与内存最容易被低估的三个配角显卡是主角但配角选不好主角也发挥不出来。CPU 方面最关键的指标不是核心数而是PCIe 通道数。主流消费级 CPU 提供 20~28 条 PCIe 通道插一张显卡走 x16再插第二张就只能 x8 甚至 x4如果还挂 NVMe 固态和万兆网卡通道就更加捉襟见肘。所以我的建议很直接单卡用户用主流消费级平台完全够多卡用户直接看工作站平台别在消费级主板上硬求双卡后折腾 PCIe 拆分。内存容量以不低于 32GB 为底线跑 70B 级别的量化模型建议 64GB 起步。原因有二一是模型文件加载时CPU 内存是必经中转站二是推理时的 KV Cache 和并发任务缓冲都在内存里。内存带宽同样重要llama.cpp 这类工具支持 CPU 和 GPU 混合推理CPU 部分的分词和 prompt 处理会频繁访问内存频率和通道数上不去token 生成速度会被明显拖住。2.3 存储布局模型文件与数据缓存不要混在一个盘里模型文件体积很大这是很多人第一次接触时没概念的地方。一个 13B 的 int4 量化模型约 8GB70B 的 int8 量化模型直接超过 70GB。如果不做规划随便塞在系统盘里系统盘很快就满了。openrig 的默认布局是把系统、模型库、数据缓存分成三个独立存储区域。系统盘用一块容量适中的 NVMe SSD 就够只装操作系统和容器运行环境。模型库最好是 1TB 或 2TB 的 NVMe SSD模型加载速度快慢直接影响首次访问延迟。数据缓存和日志可以放机械硬盘或大容量 SATA SSD这类数据对随机读写要求不高但容量往往很可观。文件系统我用 ext4 为主简单稳定多块数据盘做 RAID 看实际需求个人场景我觉得没必要为“安全感”牺牲容量。2.4 电源与散热整机稳定性的隐形天坑电源和散热是很多人攒机时最后才考虑、翻车率却最高的两个环节。功耗计算有个经验公式整机峰值功耗 CPU TDP 显卡 TDP 其他外设功耗再留 20%~30% 余量。拿常见的 RTX 4090 搭配 130W 左右的 CPU 来说显卡 450W、CPU 130W、主板内存硬盘风扇网卡大约 60W合计 640W选电源至少要 850W 以上我实际用 1000W 金牌电源。散热问题更隐蔽。显卡功耗一上来如果是普通游戏机箱、前置进风不足很容易触发温度墙降频token 生成速度肉眼可见地掉。我的实操建议是机箱选风道好的塔式服务器箱或大机箱风扇策略调成 CPU/GPU 温度联动如果是放在书房/工位噪声控制也要考虑水冷或大尺寸低转速风扇是值得的投入。另外有条件就上 UPS本地推理服务最怕突然断电导致文件系统损坏这个教训我交过学费。3. 软件栈与部署要点从裸机到可用服务的完整链路3.1 基础系统与驱动Ubuntu Server NVIDIA 驱动的标准姿势硬件装好之后就是系统层。openrig 的默认选择是 Ubuntu Server 24.04 LTS最小化安装不带图形界面。为什么不用桌面版服务器版少掉一堆不必要的系统服务占用资源更少安全面更小而且大多数 AI 工具链对它的兼容性验证最好。NVIDIA 驱动的安装是新手最容易卡住的环节。我的建议是装完系统后先把nvidia-driver-550或你系统源里最新的稳定版装上然后运行nvidia-smi验证驱动版本和 CUDA 版本。这里有一个非常重要的经验宿主机的 CUDA 版本不需要和容器内部完全一致。容器里的 CUDA 由镜像决定宿主机只需要装好与内核匹配的驱动即可。很多人死磕“宿主机 CUDA 必须 12.x”导致重装系统这是完全没必要的。3.2 容器化为什么我坚定选择 Docker 而不是裸机直跑软件栈全容器化是 openrig 的一个基本原则。Docker 就像给每个服务发了一个带独立“墙纸”的隔离房间依赖不打架环境可复现出问题直接推倒重建几分钟恢复。要在容器里使用 GPU光装 Docker 不够还需要 NVIDIA Container Toolkit。安装完它之后用一行命令登录 Dockernvidia-ctk runtime configure --runtimedocker之后启动容器时加上--gpus all或在 Docker Compose 里声明 GPU 资源容器里的nvidia-smi就能看到显卡了。我实测下来容器化之后最大的收益不是隔离而是迁移能力——换一台新机器把配置和模型目录拷过去启动服务就恢复原样这种体验用过就回不去。3.3 推理引擎选型Ollama、llama.cpp 还是 vLLM推理引擎是整个软件栈的灵魂决定你用起来顺不顺手。openrig 目前维护了三条主流路径它们的定位差异很明确。推理引擎优点局限适合场景Ollama开箱即用模型管理简单API 兼容 OpenAI高并发吞吐能力不如 vLLM参数控制偏傻瓜个人、小团队快速体验和内部使用llama.cpp / llama-server极轻量CPU/GPU 混合推理量化支持极其完善配置偏手动并发能力一般资源受限的机器或异构硬件环境vLLM高吞吐PagedAttention 显存利用率高Continuous Batching显存门槛较高配置复杂度上升生产级 API 服务并发访问量大的场景我的选择逻辑很简单默认先用 Ollama 把业务跑通如果日请求量上来、吞吐吃紧再平滑切到 vLLM。不建议一上来就上 vLLM它的参数调优复杂度对新手不太友好也不建议长期用 llama-server 做生产服务它的并发和容错能力相比 vLLM 还是有差距。3.4 服务编排与前端入口让模型从命令行走向日常使用模型跑起来之后还要一层服务编排和前端入口才能真正当成“产品”用。openrig 使用 Docker Compose 统一管理所有服务Open WebUI 作为推荐前端。它是一个功能很完整的聊天界面支持多用户、知识库、模型切换、对话历史持久化直接对接 Ollama 或 vLLM 的 API。对于知识库场景我会加一个 AnythingLLM 或 RAGFlow 做文档检索问答对于工作流编排可以再接 Langflow 或 Dify。这些服务之间通过内部网络互相通信端口只暴露必要的一个入口。整套编排的好处是你在一台机器上同时跑代码补全、文档问答、对话机器人等多个服务互不干扰每个服务都能独立升级重启。4. 实操记录一台单卡机器跑通完整AI服务的全流程4.1 目标拆解与配置设计今天用一个具体例子走一遍完整流程目标非常明确在一台 RTX 3090 24GB 的机器上跑通一个 13B 模型的 int8 推理提供 OpenAI 兼容 API再挂一个 Web 对话界面。这个配置足够应对个人和 5~10 人小团队的内部问答、文档摘要、代码辅助场景。先算显存账13B 模型 int8 量化约 13GBKV Cache 和框架开销留 20%总需求约 16GB。RTX 3090 的 24GB 显存完全hold住。机器配置是主板 单卡 32GB 内存 1TB NVMe 系统盘 2TB 模型盘电源 850W风冷机箱。前两步系统、驱动、容器运行时已经按上节内容完成直接进入容器编排。4.2 Docker Compose 配置与环境变量详解在/srv/openrig目录下创建docker-compose.yml核心内容如下services: ollama: image: ollama/ollama:latest container_name: openrig-ollama restart: unless-stopped ports: - 11434:11434 volumes: - ./models:/root/.ollama - ./logs:/logs environment: - OLLAMA_HOST0.0.0.0 - OLLAMA_KEEP_ALIVE5m - OLLAMA_NUM_PARALLEL2 deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu] open-webui: image: ghcr.io/open-webui/open-webui:main container_name: openrig-webui restart: unless-stopped ports: - 3000:8080 volumes: - ./webui:/app/backend/data environment: - OLLAMA_BASE_URLhttp://ollama:11434几个关键点展开说一下。OLLAMA_KEEP_ALIVE5m表示模型在显存中驻留 5 分钟5 分钟内再次请求则无需重新加载这对响应速度影响非常明显设为 0 是每次请求都卸载模型适合显存吃紧但请求稀疏的场景。OLLAMA_NUM_PARALLEL2控制并发请求处理数24GB 显存跑 13B int8 开 2 并发是实测比较稳的值。Open WebUI 通过容器网络内的服务名ollama直接访问推理引擎不需要暴露到宿主机外部。4.3 模型下载与首次加载配置文件写好后在项目目录下执行docker compose up -d然后拉取目标模型。我建议从国内镜像站拉模型速度有保障。以夸克、智谱等机构都支持 GGUF 格式最通用的渠道是 Hugging Face 或 ModelScope。具体操作用 Ollama 自带的拉取命令docker exec -it openrig-ollama ollama pull qwen2.5:13b-instruct-q8_0这里q8_0就是 int8 量化的一种 GGUF 量化标记。拉取完成后在 Open WebUI 的管理页面里就能看到模型出现直接对话测试。如果从 ModelScope 下载 GGUF 文件手动导入需要把文件挂载进容器的/root/.ollama/models目录并用ollama create命令生成模型配置这个流程稍微复杂一点但模型选择范围更大。4.4 性能验证与调优参数服务跑通之后的验证步骤容易被跳过但它非常关键。我用 curl 直接压测 OpenAI 兼容接口的延迟和吞吐curl http://localhost:11434/api/generate \ -d {model:qwen2.5:13b-instruct-q8_0,prompt:用三句话介绍大语言模型的基本原理,stream:false}返回结果里有eval_count和eval_duration两个字段用eval_count 除以 eval_duration就能得到实际推理速度。我的实测结果是 13B int8 在 RTX 3090 上上下文 2048 tokens 内稳定在 30~40 tokens/s日常问答完全够用。如果追求更高速度降到 int4 量化可以跑到 50~60 tokens/s但回答质量会有轻微下降我通常保留 int8。上下文长度也值得单独说。默认 4096 对大多数人够用但做文档知识库时长文本分析需要 8192 甚至 16384。上下文越长KV Cache 占的显存越多跑 13B 长上下文时注意用OLLAMA_CTX_LENGTH8192调整并随时观察显存占用。5. 常见问题与排查技巧实录5.1 显存溢出OOM最常见也最好排查OOM 的现象很直接调用 API 时返回“内存不足”或推理进程直接被杀。最常用的排查命令是nvidia-smi看显存占用是否一直居高不下。我的经验是三步走先看当前模型占用和上下文长度是否超标再查是否有多个容器同时占用显存最后检查OLLAMA_KEEP_ALIVE是否为 0 导致模型反复加载、瞬间双倍占用。解决方案通常是缩小上下文长度、关闭并行数、或者切换到低比特量化版本。千万不要在显存满了之后反复重启先找出占用大户治标也要治本。5.2 推理速度慢到不能忍先分清“慢在哪一段”同样的模型和显卡不同人的实测速度可能差出两三倍问题几乎都出在配置上。我用nvidia-smi dmon -s puc实时看 GPU 利用率再用htop看 CPU 内存状态能快速定位瓶颈。如果 GPU 利用率高但速度低说明模型太大计算已经吃满只能换更小的量化或模型。如果是 GPU 利用率低但速度低那就诡异了——多半是 CPU 端的分词、prompt 处理或磁盘加载拖后腿。这时候检查模型是否真的加载进了显存而不是部分层跑在 CPU 上再检查盘的型号机械盘加载 13B 模型的时间能比 NVMe 慢出半分钟。5.3 容器里看不到 GPU驱动、运行时、镜像三层排查这是新手最常遇到的坑宿主机里nvidia-smi正常进容器却提示找不到 GPU。排查顺序从底层到上层依次检查宿主机驱动是否正常、nvidia-ctk runtime configure是否执行成功、docker info里能看到 nvidia runtime、镜像本身是否带 CUDA 环境。其中最容易忽略的是第一步——很多人在宿主机上用的是开源驱动 nouveau它不支持容器 GPU 透传。装好正式 NVIDIA 驱动并重启后这个问题的 80% 都能解决。另外容器启动时忘了加--gpus all或 Compose 里没有声明 GPU 资源也会导致这种情况属于低级错误但极容易发生。5.4 温度、功耗与长期稳定性跑一周不崩才是真本事短时间测试谁都能过真正的考验是 7x24 小时稳定运行。我遇到过的典型问题包括设备温度一高就自动降频、电源负载超过额定导致保护重启、内存 ECC 报错等。我的处理思路是养成立刻查看三个数据的习惯——nvidia-smi的温度和功耗、CPU 核心温度、系统日志dmesg里的硬件报错。散热改进的建议是确保机箱风道顺畅显卡风扇策略调到满载或者在 BIOS 里设置温度墙。稳定性验证我更推荐系统性压测连续跑一个小时的高负载推理观察温度曲线和 token 速度曲线如果速度随时间下降明显先怀疑降频再怀疑显存过热。常见现象可能原因排查命令解决方案返回“显存不足”模型上下文超显存nvidia-smi减上下文、降量化、减并发速度越来越慢温度墙降频nvidia-smi看温度清灰、调风扇、加散热容器看不到 GPU驱动/runtime/镜像问题docker info、nvidia-smi重装驱动、重配 runtime服务偶尔无响应电源负载不足dmesg看断电记录换大功率电源、加 UPS模型加载极慢机械盘 IO 瓶颈iostat模型放 NVMe SSD6. 应用场景与影响范围openrig 能落到哪些地方6.1 个人知识库与本地 Agent 工作台对个人开发者来说openrig 最实用的落点是本地知识库和 Agent 工作台。我私人的用法是把所有技术笔记、论文 PDF、代码仓库文档丢进 RAG 系统用本地 13B 模型做检索问答。这个方案的直接好处是数据不出本机笔记内容再私密也不用担心被第三方API拿去。Agent 场景也有很大空间。本地模型接入 Langflow 或 Dify 之后可以编排多步任务读取邮件草稿、归纳待办、生成周报整个过程自动完成。延迟略高于云端 GPT-4但胜在隐私和成本。一台 3090 的机器跑 13B 量化模型日常任务完全够用每月的电费和云 GPU 包月账单比起来可以忽略不计。6.2 小团队的私有化 AI 服务5~10 人规模的小团队openrig 可以撑起一整层内部 AI 服务代码补全、内部文档问答、会议纪要生成、客服话术整理。一套 24GB 显存的工作站就能承载这种并发量数据完全留在内网合规压力小很多。我在帮两个技术团队搭建时最终架构都是 openrig 标准三层推理层 API 层 Web 入口团队里非技术成员直接用浏览器访问不需要懂任何命令行。如果要扩张到 20 人以上或者并发请求量显著加大方案也可以横向扩展加一台机器vLLM 做推理服务前端负载均衡分发。这正好体现了 openrig 的分层优势——每一层可以单独扩容成本可控且过程平滑。6.3 教育与实验场景低门槛学习大模型开发教育场景是 openrig 非常被低估的价值所在。我带过几个实习生和一个入门班最痛苦的就是他们花三个小时在配环境上。用了 openrig 之后每个人基于同一套容器模板启动半小时内就能开始跑模型推理和调 prompt学习重点从“装环境”转回“理解模型行为”。课程实验也能跑起来让每个学员在同一台服务器上开一个独立容器挂载不同的模型和端口互不干扰。桌面级 24GB 显存的机器可以同时支撑 3~4 个轻量实验实例这对学校或培训机构来说是性价比很高的硬件利用方式。6.4 演进方向从跑通到微调从单机到集群openrig 目前的第一版聚焦“部署推理”但我已经在内部测试微调模块了。个人工作站跑 LoRA 微调其实可行13B 模型用 LoRA显存消耗相比全参微调低一个数量级。下一步我会把微调流程也纳入模块化模板让“部署—推理—微调—再部署”形成一个闭环。多机扩展则是更远期的方向。单机算力有限但通过分布式推理框架把多个节点的显卡池化可以让本地跑更大的模型成为可能。这个领域目前成熟的开源方案还不多坑也比较深单机先用好多机慢慢来。openrig 的定位始终是“开放和模块化”不绑定某个厂商、不绑定某种硬件能持续跟着生态演进。最后分享一个我踩过几次坑之后养成的习惯每次调完一个服务一定把当时的配置文件和踩坑记录一并提交到模板仓库里。openrig 走到今天最大的价值反而不是那些跑通的大模型而是这一份份“当时为什么这么配、出了什么问题、怎么解决的”的工程日志。文档和配置一样重要这句老话在折腾 AI 装备这件事上体现得淋漓尽致。