企业官网建设流程全解析

我花了大半个月时间，从零搭起一套完全开源的本地AI工作站，取名OpenRIG。这套方案不买成品整机，不依赖云API，从硬件选型、系统安装到模型部署全部自己动手，目标是让大模型稳定地跑在自己的硬件上：数据不出门、参数随便调、坏哪个件换哪个件。这篇文章会把OpenRIG的完整折腾过程写清楚，包括部件选型背后的取舍逻辑、软件环境的搭建细节、模型量化与显存的计算方法，以及实际上手时最容易踩的坑。不管你是做开发的技术人、搞创作的内容用户，还是对大模型本地化好奇的硬件玩家，这套方案里都有可以直接抄作业的部分。

1. OpenRIG是什么：为什么不直接买整机

1.1 名字拆解与项目定位

“OpenRIG”拆开看就是Open加RIG。“RIG”在硬件圈子里通常指一套完整装备：摄影圈里是相机稳定器，模拟器圈里是驾驶舱框架，AI圈子里就是把CPU、显卡、内存、存储、散热整体组装起来的那台机器。OpenRIG的意思很直接：一套开放、可完整复刻的AI工作站方案，每一个硬件选择、每一条安装命令、每一种模型选型规则，都整理成公开文档分享，别人拿到这份文档可以直接照着拼一台出来。

强调“开放”是有原因的。市面上的整机AI工作站虽然省事，但存在几个让人头疼的问题。BIOS功能经常被锁死，想调整内存和功耗策略没有入口；散热方案按照公版设计，长期跑高负载任务容易降频；驱动和固件绑定厂商，出了问题只能找售后。自己拼的OpenRIG则没有这些限制，每个部件都是标准件，升级、维修、替换都自由，这也是我最终放弃整机方案的核心原因。

1.2 这套方案解决了我什么实际问题

搭这套机器之前，我长期依赖云端的各种大模型接口做文本处理。用得多了，逐渐发现几个绕不开的痛点，才决定自己动手。第一个痛点是数据隐私，有些文档内容不适合上传到公共云端，本地推理是更稳妥的处理方式。第二个痛点是成本，高频调用云端接口，一个月累计费用足以抵得上硬件投入，额度用完还得等着，自己搭机器则是一次性投入，用多少都不心疼。第三个痛点在于调试自由度，云端服务能调的参数有限，提示词优化、采样温度、上下文窗口都受到限制，本地部署之后每个环节都可以自己控制。

这三个痛点叠加在一起，就非常值得去折腾一套OpenRIG了。实际用下来，本地推理的响应速度虽然不能和顶级云端接口比肩，但稳定性和可控性带来的安全感，是任何外部服务都给不了的。

1.3 什么人适合搭OpenRIG，什么人不适合

先说适合的人。第一类是技术开发者和AI研究者，需要频繁调试模型推理与微调参数；第二类是内容创作者，经常处理含隐私内容的大量文本，需要本地化推理；第三类是硬件玩家和技术爱好者，享受自己动手配置、调优、复测的过程。

不适合的人也很明确。如果你只是想快速体验一下大模型对话，直接用现成工具效率高得多；如果你完全不想接触命令行、显卡驱动和量化格式，把这套方案当作知识了解即可，没有必要硬上。OpenRIG有学习成本，但它换来的自由度和可控性是成品方案给不了的。我建议新手先从7B模型跑通流程，再按需升级，一步到位反而容易在各种配置问题里失去耐心。

2. 硬件选型：每一分钱都花在刀刃上

2.1 先定一个目标：你要跑多大的模型

选硬件之前不要急着看参数，先确认一个关键数字：你打算本地运行多大参数量的模型。这个数字是整个硬件方案的锚点，显卡、内存、电源、散热全都跟着它走。

以常见开源模型为例，7B参数量级别的模型，量化后权重约4到6GB，12GB显存可以流畅运行；13B级别量化后约8GB，16GB显存是起步；33B级别量化后约20GB，需要24GB显存；70B级别量化后约40GB，单卡非常吃力，通常需要双卡方案。我的目标是流畅运行13B到34B区间，兼顾中文和代码能力，所以把显卡显存定在24GB。这个目标定位让整个装机方案清晰了很多，后面每一项选择都有了判断标准。

这些数字背后有固定算法，不是拍脑袋。模型权重占用可以用公式计算：参数量乘以量化位宽再除以8。比如13B模型做4bit量化，就是13乘以4除以8，约6.5GB权重。再叠加推理时的KV Cache和计算开销，总显存需求大约在权重的1.3到1.5倍。这个计算逻辑我会在第4章详细展开，这里先记住结论即可。

2.2 显卡是灵魂：显存、带宽与算力三个参数怎么权衡

本地AI推理的瓶颈几乎总是显存，所以显卡是第一优先级的投入方向。显卡有三个参数要重点看：显存容量决定能装多大的模型，显存带宽决定生成token的速度，FP16或INT8算力决定首字延迟，也就是Prompt处理速度。

我最终选的是24GB显存档位的卡，这个档位非常微妙：它可以跑量化后的33B模型，也能开接近满血的长上下文，价格相比更高显存容量的专业卡低很多。在具体型号上，重点是找一张散热和功耗可控、显存带宽足够的产品。实测下来，24GB卡跑13B模型非常舒服，量化后的33B模型也能稳定运行，生成速度保持在可接受范围。

为什么不是更便宜的16GB卡？虽然16GB也能跑13B模型，但一旦开启较长的上下文或者做并发请求，KV Cache立刻把显存撑满，剩余空间太少会导致频繁切换或直接溢出。预算允许的情况下，显存尽量买大一档，这是本地AI工作站最值得追加投入的地方。很多人在选卡时纠结算力，实际上本地推理场景里，显存不够的机器连模型都加载不进去，算力再高也发挥不出来。

2.3 CPU、内存、硬盘：别让短板拖垮整体体验

很多人把预算全部砸在显卡上，结果发现跑大模型时CPU或者内存成了瓶颈，这个教训我自己深有体会。先说CPU，本地推理过程中Prompt分词、Python调度、部分算子运算都依赖CPU，8核以上是比较稳妥的起点。我用的是中端多核处理器，跑模型时的CPU占用率并不低，尤其是处理长文档时明显感觉到CPU在参与大量计算。

内存方面，32GB是比较舒适的容量。如果显存紧张，部分层会退到CPU运算，内存太小会直接触发交换分区，整个推理速度断崖式下降。另外，模型文件加载进内存缓存时也需要空间，容量太紧就会出现反复换页的问题。硬盘的要求其实更苛刻：一个13B量化模型文件超过8GB，加载到内存或显存的时间受硬盘读取速度影响很大，我实测NVMe固态和SATA固态加载同一个模型，等待时间差了大约三倍，因此系统盘和模型目录都建议使用NVMe固态。

整机功耗也要提前估算。我采用的方案，CPU峰值功耗大约100W，显卡峰值功耗在400W到450W之间，主板、内存和硬盘加起来大约80W，总功耗接近600W。电源建议预留1.4倍余量，所以选了1000W的电源，以免高负载时电源过热或者风扇噪音过大，这块容不得省。电源看着不起眼，但它是整个系统稳定运行的底座，劣质电源在高负载下可能导致重启甚至损坏硬件。

2.4 散热方案：稳定性往往输在温度上

本地跑模型时，GPU在长上下文的Prefill阶段会接近满载，温度飙升非常快。如果散热不到位，显卡自动降频，推理速度肉眼可见地变慢，这是很多新手容易忽略的问题。

我的散热思路是三条。第一条，选择三风扇设计的显卡，这比双风扇版本在高负载下能低上好几度。第二条，机箱风道走前进后出、下进上出的经典方案，前面板两个进风扇，顶部两个出风扇，后面一个出风扇，保持轻微负压环境，让热风快速排出。第三条，限制GPU功耗墙，把最大功耗限制在90%附近，温度能下降不少，性能损失却微乎其微。

实际运行下来，GPU温度被控制在70到80摄氏度之间，没有出现过因为过热而降频的情况。这套散热投入不算多，但性价比极高，如果这里省了钱，后面跑长任务时大概率要重新折腾。顺便提醒一句，机箱不要买太小，风道空间对散热的影响比很多人想象中更大。

3. 系统环境与软件栈搭建：跑通底座的每一步

3.1 操作系统和显卡驱动怎么装

系统我选择Ubuntu 22.04 LTS，原因很简单：NVIDIA驱动支持最完整、CUDA生态兼容性最好、遇到问题能找到的排查资料最多。系统装好后，第一件事是安装NVIDIA驱动和相关工具链，这里有个容易踩的坑：不要先装CUDA再装驱动，顺序反了很容易出现版本不匹配。

推荐用官方提供的deb方式安装驱动，装完后用nvidia-smi验证是否识别到显卡：

nvidia-smi

正常情况下会输出显卡型号、驱动版本、显存占用和当前功耗。如果命令提示找不到，多半是驱动没装成功或者内核模块没加载，需要重启或者重新编译内核模块。在驱动层面多花点时间排查是值得的，因为后续所有推理框架都依赖这个底层环境。

装完驱动后再安装CUDA Toolkit。建议直接用官方仓库的版本，安装完成后验证环境变量是否生效，重点看nvcc --version输出的版本号，要和你选择的PyTorch版本要求的CUDA版本对得上，否则后续编译时会报各种奇怪错误。这一步看起来简单，实际很多人在这里浪费了一整天，版本号对齐非常关键。

3.2 Python环境与推理依赖的配置

本地AI推理几乎离不开Python生态，我习惯用miniconda来管理环境，避免多个项目之间的依赖冲突。为OpenRIG单独建一个环境，Python版本选3.10，这是当前大多数推理框架兼容性最好的版本。

建环境的命令很简单：

conda create -n openrig python=3.10 -y conda activate openrig

接下来安装PyTorch，需要根据CUDA版本选择对应的安装源。比如CUDA 12.x版本的安装命令如下：

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

装完之后可以用一小段代码确认PyTorch能否调用GPU：

import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))

如果输出True和显卡型号，说明PyTorch和驱动链路是通的。这一步是整个软件栈的关键验证，它过了，后面绝大多数问题都出在推理框架和模型文件层面。如果没有进入这个验证，之后再排查问题时会同时面对驱动、CUDA、Python三方面变量，非常痛苦。

3.3 推理框架怎么选：llama.cpp、Ollama、vLLM

本地推理框架有三个主流选择，各有侧重。llama.cpp对硬件要求最低，CPU也能跑，GGUF量化格式支持最完善，适合资源紧张或者想深入控制量化细节的场景。Ollama封装程度最高，安装简单，一条命令就能拉起本地服务，适合快速上手，但可定制性有限。vLLM主打高吞吐并发，适合部署成服务端给多人使用，但显存占用更大，配置门槛更高。

我这套OpenRIG最终以llama.cpp为主力后端，理由有两个。一是它的量化粒度最细，我可以针对具体模型测试不同量化档位的效果；二是它提供了与OpenAI兼容的本地API服务，既能在终端里交互，也能给上层应用调用，灵活性很高。Ollama其实也在底层用了llama.cpp的代码，如果你追求简便，直接用Ollama也不是问题。

这里把三个框架的差异整理成了表格，方便快速判断：

如果你拿不准选哪个，我的建议是先装Ollama把流程跑通，再切换到llama.cpp做精细调参，这样学习曲线最平滑。

4. 模型下载与本地部署实战：把大模型真正跑起来

4.1 模型怎么选：关注参数量、基座和中文能力

部署的第一步是选模型。目前开源模型生态已经很丰富，主流选择包括Llama系列、Qwen系列和Mistral系列。如果你是中文用户，Qwen系列通常是更省事的选择，中文指令理解、文本生成质量和角色扮演能力都经过了针对性优化；如果想跑英文任务或者做代码辅助，Llama系列和Mistral系列的表现也很扎实。

我在这套OpenRIG上主要跑的是13B参数量级别的Qwen模型，理由很简单：中文内容处理是我的主力需求，13B规模在24GB显存下既能保证较快的生成速度，又能保留足够强的语义理解能力。如果你更多处理英文或者只需要尝试流程，7B模型也是很好的起点，加载更快、参数调试成本更低。模型仓库里通常有多个版本，注意选择GGUF格式且明确标注量化档位的文件，避免下载无法直接使用的原始权重。

4.2 量化格式解析：GGUF与Q4_K_M

开源模型发布时通常是FP16或BF16权重，体积很大，普通显卡很难直接加载。量化就是把这个权重用更低的精度存储，体积缩小到原来的四分之一甚至更小，显存压力大幅下降。

在llama.cpp生态里，GGUF是标准格式，文件后缀常见的有q2_k、q3_k_m、q4_k_m、q5_k_m、q8_0等。档位越高，精度损失越小，但体积和显存需求也越大。以我的实操经验来看，q4_k_m是最推荐的平衡点，综合了速度、体积和质量；如果显存宽裕且更在意输出质量，用q5_k_m；q8_0几乎接近无损，但体积已经接近原始权重的80%，更适合同机存储充裕的情况。

有人会问为什么不直接用FP16。原因很简单，以13B模型为例，FP16权重约为26GB，24GB显卡根本放不下，而q4_k_m版本只有8GB左右，加载后还有充足空间给KV Cache和上下文。量化对最终输出质量的影响取决于任务类型，常规对话和文本生成场景几乎感知不到明显差异。如果你做的是严肃的数据抽取或逻辑推理，可以用q5_k_m档位换取更多准确度。

4.3 显存预算的计算逻辑与实测验证

部署之前最好先按公式估算一下显存需求，免得下载完模型才发现跑不动。核心公式就一条：权重占用等于参数量乘以量化位宽除以8。

以13B模型配q4_k_m量化为例：13乘以4再除以8，约6.5GB权重。加上推理时的KV Cache和临时计算缓冲，总需求按权重乘以1.3到1.5估算，约8.5到10GB。24GB显卡下运行完全没有压力，还能把上下文长度拉到一个比较舒服的值。

再举一个更极限的例子：34B模型配q4_k_m，权重约17GB，按1.4倍估算总需求接近24GB，这意味着24GB显卡刚好能跑，但上下文长度必须严格控制，否则KV Cache一涨就会溢出。这个案例正好能解释为什么第2章把显存目标定为24GB，它让34B级别成为可运行的天花板，而不是遥不可及的数字。下表是常见组合的估算参考：

4.4 启动本地API服务的完整示例

模型文件就位后，llama.cpp可以直接启动一个兼容OpenAI风格的本地API服务。使用llama-server命令并指定模型路径、监听端口和上下文长度，就能让同一局域网内的应用调用这个服务，不需要额外写复杂代码。

服务启动后，可以用curl或者编程语言发起请求。下面是一个简单的请求示例：

curl http://localhost:8080/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen-13b-q4_k_m", "messages": [{"role": "user", "content": "你好，请介绍一下你自己"}], "temperature": 0.7, "max_tokens": 512 }'

返回的JSON里包含模型生成的文本、token使用情况和耗时统计。我在实际测试中的体验是，首Token延迟大约在几百毫秒，后续生成速度稳定在每秒20个token以上，这个体验在本地应用场景里已经相当可用。如果你需要接入自己的应用，把请求地址改成这个本地端点即可，代码迁移成本几乎为零。

5. 性能调优与常见问题排查：实测中避开这些坑

5.1 推理速度上不去：先检查这三个原因

跑起来之后，很多人第一个疑问是“为什么我的速度这么慢”。我排查过很多次，效果最明显的检查项有三个。

第一，确认推理是否真的走了GPU。llama.cpp如果要调用NVIDIA显卡，编译时必须开启CUDA支持，很多预编译包默认只支持CPU推理，速度自然上不去。可以用构建参数重新编译，或者在启动日志里看是否输出GPU相关的加载信息。第二，检查GPU频率。用nvtop这样的工具观察显卡实时频率和占用率，如果温度过高触发了降频，生成速度会突然掉一大截，这种情况需要回到散热那节处理。第三，检查并发和线程设置。llama.cpp允许设置线程数，但线程数并非越大越好，超出物理核心数反而导致切换开销。合理的办法是先冻结其他参数，只调整线程数，通过一组对比测试找最优值。

5.2 显存溢出：优先砍上下文还是换量化

显存溢出是本地推理最常见的报错之一，看到CUDA out of memory先不要慌，按顺序处理。

我的处理顺序通常是这样的：第一步收紧上下文长度，因为KV Cache占用的显存与上下文长度成正比，许多溢出问题其实出在context window调得太大；第二步才是考虑换更低档的量化，比如从q5_k_m降到q4_k_m；第三步仍然不够，就换更小参数的模型，从13B降到7B。不建议一上来就换量化档位，因为量化对质量的损失往往是不可逆的，而上下文长度则可以在不影响生成质量的前提下灵活调整。

可以把这个顺序当作一个速查表：

5.3 长时间运行：温度、降频与功耗墙怎么控

长任务运行时的稳定性很容易被忽视。我遇到过几次跑着跑着速度突然变慢的情况，查看温度后发现显卡频率已经降到基准以下，原因就是连续高负载触发了降频保护。

应对办法主要有两个。一个是设置功耗墙，把显卡功耗限制在默认值的90%附近，温度能下降5到10摄氏度，性能损失却非常小；另一个是调整风扇曲线，让风扇提前介入，而不是等温度上来了才开始转。还可以在机箱层面改进风道，确保热风快速排出而不是在机箱里循环。这一套组合下来，我连续跑了多个小时的大模型对话任务，显卡温度稳定在80摄氏度以内，没有再出现异常降频。如果你打算跑批处理任务，建议先用短任务测试稳定性，再投入长任务。

5.4 典型问题排查实录

最后分享几个实际踩坑的记录。有一次服务启动后返回503错误，排查后发现是上下文长度设置太大，模型加载时KV Cache就占了过多显存，把长度调小后恢复正常。

还有一次所有请求都返回乱码，检查后发现是模型文件下载不完整，重新校验文件完整性之后问题解决。这个提醒很重要：大体积模型文件传输过程中容易出现损坏，下载后务必检查哈希值。另外，如果遇到本地API服务响应慢，优先看是不是CPU推理在兜底，确认启动日志中GPU层的加载信息即可。

这些问题的共同点是，看起来像模型或代码问题，实际根因大多在环境配置层面。建立一个检查清单，从上到下过一遍，能省下大量排查时间。

6. 扩展玩法：从单机工作站到家庭实验室

6.1 接入RAG：把OpenRIG变成本地知识库问答系统

当本地模型跑通之后，一个非常实用的扩展方向是给OpenRIG接入RAG（检索增强生成），把它变成一套私有的知识库问答系统。整个工作流可以分为四步：先把文档切分成小片段，然后通过嵌入模型把每个片段向量化存入向量数据库，接着在提问时检索与问题最相关的片段，最后由本地大模型结合检索结果生成答案。

我在实际场景中用这套方案处理了内部文档问答。之前靠人工翻阅资料，现在直接在对话框里输入问题就能得到带引用的回答，准确度提升明显，而且所有数据都只在本地流转，没有隐私外泄的顾虑。向量库和嵌入模型也都有开源方案可以本地运行，整条链路完全不需要依赖外部服务。如果你想复现，先从几十篇文档起步，跑通流程后再逐步扩大知识库规模，这样调参会更容易。

6.2 多卡方案与分布式推理怎么选

如果后续要挑战更大的模型，单卡的天花板会立刻体现出来。此时有两种主流方案：多卡切分和张量并行。llama.cpp支持把模型权重按层拆分到多张显卡，显存需求成倍下降，部署简单；vLLM则支持张量并行，适合高并发服务场景，但需要更强的系统级支持。

两种方案的取舍取决于实际需求。如果只是要在一台机器上跑更大的模型，多卡切分已经足够；如果要做成多人可用的服务，张量并行和更完善的内存管理是加分项。无论选哪种，PCIe带宽都会成为瓶颈之一，所以不要指望多卡后速度成倍提升，它更多是解决容量问题。以我观察到的经验，双卡方案跑70B量化模型是合理的起点，再往上堆卡的边际收益就会明显下降。

6.3 OpenRIG后续还可以怎么玩

OpenRIG的价值在于它是一套开放的底座，跑通之后可以延伸出很多玩法。比如微调自己的数据，让模型学习特定领域术语和风格；比如把本地服务接入自动化工作流，把日常文本处理变成定时任务；再比如把模型接入开发环境，作为代码补全的后端。

我自己接下来的计划是把量化测试做成自动化流程，针对同一模型的不同档位跑标准评测，生成量化开关对比报告。这样OpenRIG就不再只是一台能跑模型的机器，而是一个持续迭代优化的实验平台，这也是它和普通整机最大的区别。每一次改动都有记录，每一个结果都能复现，整个学习过程本身就非常有价值。

最后说一点我个人的体会。OpenRIG这套方案真正教会我的，是“先算账再动手”的工程思维：先定目标模型，再算显存，然后才谈显卡和其他配件；先跑通最小验证，再谈优化和扩展。如果让我再做一遍，我会第一天就把预算分成两块，一块买显卡，另一块专门留给电源、散热和NVMe硬盘，因为稳定性和I/O速度决定实际体验的下限。搭建过程中遇到问题，先把驱动、显存占用、温度三件事排查一遍，多半能解决你90%的困惑。OpenRIG的配置清单和部署脚本我会继续维护，有任何新体会也会同步更新。希望这篇复盘能让你少走一些我已经走过的弯路。