最近在整理硬件清单的时候我发现自己老是要跟人解释同一个问题openrig 到底是个什么东西名字里带个 rig很多人第一反应是矿机架。其实方向完全不同它是我一直在维护的一套本地大模型推理机架方案关键词是 open——开放的硬件选型、开放的软件组合、可复制的部署流程。目标也很朴素让开源大模型真正跑在自己手里而不是每次调用都交给第三方 API。这套方案适合三类人觉得 Token 费用越花越多的个人开发者、数据敏感不想出内网的小团队、想折腾本地推理又不想从零踩坑的工程新人。下面这篇文章我会从需求定位、硬件选型、推理引擎、量化策略、部署调优到故障排查完整过一遍把我自己在这套机架上反复验证过的东西写出来。内容偏实操基本照着抄就能搭起来。1. 需求定位先搞清楚谁在用再决定花多少钱买卡做这套方案之前我最不建议的事情就是先打开电商页面搜显卡。硬件这东西没有绝对的“好”只有“匹配不匹配”。你得先想清楚这台机器是给你一个人调试代码用的还是给整个团队提供服务的这两个需求的硬件预算差了好几倍。1.1 三种典型使用场景对应三种硬件档位我接触到的本地推理需求大致分三类场景不同对硬件的要求就完全不同。单人研发调试比如验证 prompt 效果、跑跑 RAG 实验、给某个模型写评测脚本。这类场景并发基本是 1上下文长度也不会拉满一个 7B 到 14B 的模型就够用了16GB 到 24GB 显存的单卡就能玩得很舒服。我的建议是直接 24GB后面可以少操很多心。小团队共享服务比如做内部知识库问答、代码审查辅助、客服工单摘要。这种场景会有多个人同时用模型规模建议上 14B 到 32B硬件得按单卡 48GB 或者双卡来规划软件层面也要用支持高并发调度的推理引擎。常态化生产服务比如每天有上千次请求的接口对响应时间有硬性要求。那就得考虑 32B 以上模型加多卡并行同时配合 vLLM 这类吞吐优化引擎做流量承接。使用场景推荐模型规模硬件档位预算参考单人调试7B-14B Q416GB-24GB 单卡中低小团队共享14B-32B Q4/Q824GB-48GB 单卡或双卡中高生产服务32B-72B Q4双卡及以上配合 vLLM高这套划分不一定绝对但方向是对的。如果你想兼顾前两种场景直接按“单卡 24GB 起步”去选不会错太多。1.2 显存需求可以算出来权重、KV cache、运行开销很多人以为显存需求就是模型文件大小这是最常见的误解。实际上显存里要装三样东西模型权重、KV cache、CUDA 运行时开销。我一般先用一个简化公式估算权重占用模型权重占用GB≈ 参数量B× 每参数比特数 ÷ 8举个例子一个 7B 模型用 FP16 加载每参数 16 比特那就是 7 × 16 / 8 14GB这在 16GB 卡上已经很紧张了。如果换 INT4 量化4 比特每参数理论上 3.5GB但考虑到嵌入层、归一化层保留高精度以及量化分组开销实际权重文件会在 4.4GB 左右。KV cache 是第二个变量。它的占用和上下文长度线性相关你把 context 从 8K 拉到 32KKV cache 会翻四倍。14B 模型在 8K 上下文下大约占 1-2GB拉到 32K 可能要 6-8GB。第三个是 CUDA 运行时、tokenizer、调度器这些杂项开销留 1GB 左右比较稳妥。所以完整公式应该是总显存需求 模型权重 KV cache 运行开销。24GB 的卡跑 14B Q4权重约 8.8GB8K 上下文 KV cache 约 2GB剩下 13GB 做余量非常从容。但如果强行上 32B Q4光权重就 18GBKV cache 稍长一点就可能爆。1.3 为什么我坚持把模型放在本地有些人觉得调用大厂 API 更省事这个我承认但 openrig 一直坚持本地化有三个非常现实的原因。第一是数据边界。很多公司的数据管理制度比你想的严格代码库、客服记录、内部文档这些内容根本不适合发送到外部服务。本地推理让数据从生成到处理的全生命周期都在自己的网络里。第二是成本结构。API 费用是按 token 计的日调用量上去以后账单数字相当可观。本地硬件是一次性投入只要有持续的工作负载回本周期往往比预期短尤其你用的是开源模型而不是收费 API 的时候。第三是可控性。本地模型可以自定义 system prompt、可以接自己的工具函数、可以随时做 LoRA 微调甚至能为了某个具体场景把温度、采样参数调到比较激进的状态。这些都是封闭 API 很难给到的自由度。2. 硬件选型显存带宽比算力更值得花钱很多第一次装机器的人有个误区以为大模型推理就是拼算力于是盯着 TFLOPS 买卡。实际跑起来你就会发现大语言模型推理的瓶颈很多时候根本不是算力而是显存带宽。2.1 GPU 三档与核心参数速查我按自己的经验把主流选择分成了三档每一档对应的核心参数可以直接对照着看。入门档以 RTX 4060 Ti 16GB 为代表显存带宽约 288GB/s优势是便宜、功耗低适合跑 7B 到 14B 的 4bit 量化模型但生成速度会慢一些大概每秒 40-60 token。主力档是 RTX 3090 或 4090 24GB这是目前性价比最均衡的一档。3090 经过二手市场沉淀后价格合理显存带宽 936GB/s解码速度相当可观。4090 带宽更高达到 1008GB/s但价格也贵不少。进阶档是 RTX 6000 Ada 或 A6000 48GB面向 32B 以上模型专业卡散热和稳定性更好缺点是贵。档位显卡显存带宽参考适合模型入门RTX 4060 Ti 16GB16GB288GB/s7B-14B Q4主力RTX 3090 / 409024GB936-1008GB/s14B Q4/Q832B Q4 极限进阶RTX 6000 Ada / A600048GB768GB/s32B Q870B Q424GB 目前是性价比甜点这个结论在多个开源模型社区里也是共识。预算够就直接上不要纠结。2.2 prefill 和 decode两个阶段的瓶颈完全不同Transformer 模型的推理过程分两个阶段很多人不区分它们导致调优时摸不着头脑。prefill 阶段也就是用户输入提示词后模型第一次计算的那一下是计算密集型。它要并行处理所有输入 token这时候 GPU 的算力起主要作用TFLOPS 越高首 token 延迟越低。decode 阶段则是逐 token 生成的阶段每个新 token 都要把整个模型的权重重新读一遍这个阶段变成显存带宽密集型。显存带宽越高每秒吐的 token 就越多。可以做个简单估算7B Q4 的权重约 4.4GB在带宽 936GB/s 的 3090 上理论上每秒最多生成 936 / 4.4 ≈ 213 个 token实际因为有缓存、碎片和计算重叠的损耗大概只能跑到一半也就是 100-130 token/s。这就解释了一个现象为什么两张显卡算力差不多但显存带宽高的那张推理速度明显更快。所以买卡的第一眼看显存容量第二眼看显存带宽TFLOPS 反而是最次要的指标。2.3 双卡平台的配套工程PCIe、电源和散热如果模型规模到了 32B 以上单卡 24GB 就不太够了这时候需要双卡方案。但双卡不是简单插两张卡就行配套工程才是大头。PCIe 通道分配是最容易翻车的点。两张 GPU 要跑的顺至少需要各 x8 通道。很多消费级主板的第二个 PCIe 插槽只有 x4甚至会被 M.2 硬盘抢占通道。选主板时一定要看清楚 PCIe 拆分能力BIOS 里要有 Bifurcation 选项能设成 x8/x8 或 x16/x16。专业工作站主板通常没这个烦恼但消费级平台就得认真查。电源余量也直接决定系统稳不稳定。按双 3090 估算单卡满载约 350W两卡 700W加上 CPU 150-200W、主板内存硬盘风扇等 100W稳态负载就到 1000W 左右而 GPU 瞬间功耗还可能冲到峰值所以电源建议直接上 1300W-1600W 白金或者以上别在这种地方省预算。散热方面这就是 openrig 的形态优势了。开放式机架设计最大的好处就是风道短、通风量大GPU 的热量不会被闷在机箱里反复循环。我用下来整机温度比普通塔式机箱低 10 度左右满载运行也不会因为热降频。如果接受不了开放机架的噪音退一步也要选前进后出的塔式大机箱加高风压风扇。3. 推理引擎Ollama、vLLM 和 llama.cpp 怎么排兵布阵同样的硬件不同推理引擎跑出来的效果差很多。这个部分往往被低估很多人装好 CUDA 直接就跑根本没考虑过引擎选型的问题。3.1 Ollama五分钟跑起来适合原型验证Ollama 是目前最不容易出错的选择一条命令装好一条命令拉模型一条命令起服务。对新手来说它是绝佳的切入点。# 安装 Ollama curl -fsSL https://ollama.com/install.sh | sh # 下载一个 14B 模型 ollama pull qwen2.5:14b-instruct # 让服务监听所有网卡方便局域网内调用 export OLLAMA_HOST0.0.0.0:11434 ollama serve启动之后它默认提供一个 OpenAI 兼容接口这意味着你现有的很多代码可以无缝切换。我用 Python 的 openai SDK 测试过只需要把 base_url 指到本地就能直接调通from openai import OpenAI client OpenAI( base_urlhttp://openrig.local:11434/v1, api_keyollama, ) resp client.chat.completions.create( modelqwen2.5:14b-instruct, messages[{role: user, content: 帮我总结这段日志}], temperature0.2, ) print(resp.choices[0].message.content)但 Ollama 也有短板它对单用户场景优化得不错却不太擅长高并发。多个请求同时进来时它默认是排队串行处理吞吐量上不去所以适合原型验证和轻量使用。3.2 vLLM并发吞吐才是生产环境的胜负手等 openrig 要正式接团队需求的时候我换成了 vLLM。这个引擎有两大核心优化PagedAttention 和 Continuous Batching。前者把 KV cache 按页管理让显存利用率大幅提升后者则允许请求动态插队新请求不用等前面所有请求结束就能开始处理。治本的办法是启动时留出足够的 KV cache 空间或者调低--max-model-len。根据我的经验24GB 单卡上跑 14B 模型max-model-len设 8192 比较稳如果非要 32K 上下文就得把量化精度降到 Q4 或者换更大显存的卡。6.5 模型加载像蜗牛磁盘速度与 mmap 机制现象是每次启动服务模型加载要等好几分钟第一次请求迟迟不来。排查发现瓶颈根本不在 GPU而在磁盘。vLLM 默认使用 mmap 方式映射模型文件如果你把模型放在机械硬盘上读取 10 多 GB 文件的耗时非常可观。llama.cpp 也有类似逻辑它会通过 mmap 按需加载页面。解决办法很简单模型文件必须放 NVMe SSD 上机械硬盘完全不合格。另外启动后可以先发一个最简单的请求做预热让权重真正进入显存后续请求的响应速度会明显提升。7. 写在最后一套机架换来的可控性把 openrig 从一张零散清单变成稳定运行的推理服务之后我最大的体会是本地推理的价值不在跑分而在于它把模型变成了自己的基础设施。API 再怎么便捷数据始终在别人手里而这套机架一旦转起来你随时可以在上面做 RAG、跑 Agent、微调模型想怎么折腾都行。如果你也准备搭这么一套我的建议是先拿 Ollama 把 14B 模型跑通再决定要不要上 vLLM 和双卡。先用最小成本确认需求再逐步扩建这条路最稳妥。后面我还会继续开放 openrig 的配置模板和调参记录包括 RAG 接入和工具调用编排的部分有兴趣的可以持续关注。