企业官网建设流程全解析

最近在整理硬件清单的时候，我发现自己老是要跟人解释同一个问题：openrig 到底是个什么东西？名字里带个 rig，很多人第一反应是矿机架。其实方向完全不同，它是我一直在维护的一套本地大模型推理机架方案，关键词是 open——开放的硬件选型、开放的软件组合、可复制的部署流程。目标也很朴素：让开源大模型真正跑在自己手里，而不是每次调用都交给第三方 API。

这套方案适合三类人：觉得 Token 费用越花越多的个人开发者、数据敏感不想出内网的小团队、想折腾本地推理又不想从零踩坑的工程新人。下面这篇文章我会从需求定位、硬件选型、推理引擎、量化策略、部署调优到故障排查完整过一遍，把我自己在这套机架上反复验证过的东西写出来。内容偏实操，基本照着抄就能搭起来。

1. 需求定位：先搞清楚谁在用，再决定花多少钱买卡

做这套方案之前，我最不建议的事情就是先打开电商页面搜显卡。硬件这东西没有绝对的“好”，只有“匹配不匹配”。你得先想清楚这台机器是给你一个人调试代码用的，还是给整个团队提供服务的，这两个需求的硬件预算差了好几倍。

1.1 三种典型使用场景，对应三种硬件档位

我接触到的本地推理需求大致分三类，场景不同，对硬件的要求就完全不同。

单人研发调试，比如验证 prompt 效果、跑跑 RAG 实验、给某个模型写评测脚本。这类场景并发基本是 1，上下文长度也不会拉满，一个 7B 到 14B 的模型就够用了，16GB 到 24GB 显存的单卡就能玩得很舒服。我的建议是直接 24GB，后面可以少操很多心。

小团队共享服务，比如做内部知识库问答、代码审查辅助、客服工单摘要。这种场景会有多个人同时用，模型规模建议上 14B 到 32B，硬件得按单卡 48GB 或者双卡来规划，软件层面也要用支持高并发调度的推理引擎。

常态化生产服务，比如每天有上千次请求的接口，对响应时间有硬性要求。那就得考虑 32B 以上模型加多卡并行，同时配合 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 拉到 32K，KV cache 会翻四倍。14B 模型在 8K 上下文下大约占 1-2GB，拉到 32K 可能要 6-8GB。第三个是 CUDA 运行时、tokenizer、调度器这些杂项开销，留 1GB 左右比较稳妥。

所以完整公式应该是：总显存需求 = 模型权重 + KV cache + 运行开销。24GB 的卡跑 14B Q4，权重约 8.8GB，8K 上下文 KV cache 约 2GB，剩下 13GB 做余量，非常从容。但如果强行上 32B Q4，光权重就 18GB，KV 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 以上模型，专业卡散热和稳定性更好，缺点是贵。

24GB 目前是性价比甜点，这个结论在多个开源模型社区里也是共识。预算够就直接上，不要纠结。

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_HOST=0.0.0.0:11434 ollama serve

启动之后，它默认提供一个 OpenAI 兼容接口，这意味着你现有的很多代码可以无缝切换。我用 Python 的 openai SDK 测试过，只需要把 base_url 指到本地，就能直接调通：

from openai import OpenAI client = OpenAI( base_url="http://openrig.local:11434/v1", api_key="ollama", ) resp = client.chat.completions.create( model="qwen2.5:14b-instruct", messages=[{"role": "user", "content": "帮我总结这段日志"}], temperature=0.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 接入和工具调用编排的部分，有兴趣的可以持续关注。