如果你跟我一样白天调接口、晚上刷模型迟早会产生一个念头能不能把自己的工作台武装成一套随时能跑的 AI 环境我给这套东西起了个代号叫 OpenRig。Rig 这个词在影视和硬件圈很常见指的是为了特定任务拼装起来的整套设备组合我借它来命名这套用开放组件搭出来的本地推理工作站。它不是一个新框架而是一套把模型、算力、调用接口、管理界面全部装进同一种装配思路里的方案核心解决的是“手头有卡有模型却怎么都串不起来”的问题。这篇文章会把整套搭建过程、选型理由和踩坑记录完整摊开。如果你手里有一张消费级显卡或者一台普通工作站想把开源大模型真正用起来而不是停留在“下载完跑个 demo 就吃灰”的阶段那这篇应该能帮你省下不少弯路。1. 先想清楚OpenRig 到底要解决什么问题1.1 从“点模型”到“平台化”的转变先说个真实场景。我最早玩开源模型的时候桌面上乱七八糟跑着好几个进程一个 chat 模型的 Demo、一个 embedding 服务、一个语音转文字的 Whisper。每个服务都要单独建环境、单独开端口、单独记启动命令。今天用这个模型要另开一个终端明天换另一个模型又要停掉旧的时间全浪费在“切换”上了。OpenRig 的思路其实很简单把所有模型当成可插拔的“算力卡”塞进同一套底座里。底座负责统一加载、统一暴露接口、统一做并发调度上面想插哪个模型就插哪个模型。对使用方来说记住一个入口地址就够了后台换模型、换量化版本都不影响调用方。这种平台化的价值在一个人单机的时候可能感觉不明显但只要模型数量超过三个或者开始有同事、朋友、业务系统来调用你的机器差异立刻就出来了。引用一个很实在的对比单点模型像是厨房里堆了一堆散装食材每次做饭都要现找现切平台化之后像是有了一套带标签的冰箱和料理台菜谱还是那些菜谱但流程顺了太多。1.2 为什么选择本地部署而不是云 API很多人问过我这个问题本地搭一套费电费卡费精力直接用云 API 不是更省事我的判断标准其实就三条数据敏感度、调用频率、单次请求的实时性要求。如果企业内部文档、代码库、客服对话这些信息要过模型云 API 意味着这些数据要离开你的网络边界。信息只在自己手里流动这个心理门槛很多人过不去。成本方面可以算一笔粗账一个小团队高频调用一个月几千块 API 费用很常见而一张本地显卡一次性投入摊到两三年使用周期里每天可能就二三十块还不限调用次数。当然本地部署要自己处理驱动、依赖、并发这些事运维成本是真实存在的不能假装看不见。延迟也值得一提。同一台机器上跑本地模型单次请求省去了网络往返和云端排队首字延迟能压到百毫秒级别。对交互式应用来说体感差异非常明显。我个人的建议是“混合”对外部真实用户、突发流量用云 API内部高频、敏感、固定场景的请求走本地 OpenRig两边用同一套 OpenAI 风格的接口封装切换成本几乎为零。2. 硬件与软件底座装配一套能跑的 Rig2.1 硬件层的取舍原则很多人以为搭推理工作站必须上多卡服务器其实完全不是。我手头这张 12GB 显存的卡就能跑不少主流 7B 模型的量化版本效果足够日常使用。硬件选择的关键不是“越大越好”而是“显存够算力恰好”。先教你怎么估算显存需求。推理时的显存占用主要由三块组成模型权重、KV Cache上下文缓存、运行时激活值。模型权重好算7B 参数在 FP16 下大约 14GB换成 4bit 量化AWQ 或 GPTQ后大约 4~5GB。KV Cache 和模型结构、上下文长度直接相关计算公式是KV Cache 大小约等于 2 × 层数 × 注意力头维度 × 序列长度 × 批大小 × 字节数。以 Qwen2.5-7B 为例GQA 结构下每 token 大约占 1.2GB8K 上下文时单条序列这个数字会随上下文长度线性增长。所以一个粗略的判断标准就出来了7B 模型 4bit 量化 8K 上下文总显存需求大约 6~8GB8GB 卡勉强能跑12GB 卡比较舒服16GB 卡可以随意开长上下文。如果是 14B、32B 这种规模就要上 24GB 或双卡方案了。内存建议 32GB 起步因为加载模型、处理输入数据都需要内存中转磁盘必须是 SSD模型文件动辄几个 GB机械盘加载会让人等到怀疑人生。2.2 推理引擎选型Ollama、vLLM 与 TensorRT-LLM软件栈是整个 OpenRig 的核心。目前主流开源推理引擎里我实际用过且觉得值得推荐的有三个Ollama、vLLM、TensorRT-LLM。它们各自的定位完全不同放在一张表里对比就很清楚了。引擎核心优势并发能力配置难度适用场景Ollama安装快、模型管理方便、开箱即用中低可通过参数调大极低个人体验、小规模内部使用vLLMPagedAttention 显存优化、连续批处理高中等正式服务、多用户并发、业务接入TensorRT-LLM延迟最低、吞吐上限最高高高N 卡专用、追求极致性能的长稳服务我的建议是先上 Ollama 跑通流程感受一下模型效果是否符合预期再切换到 vLLM 做服务化。Ollama 的ollama pull一行命令就能下好模型环境变量一配就能对外服务很适合快速验证。但当并发请求上来之后Ollama 的调度能力明显不是专为高并发设计的这时候 vLLM 的优势就体现出来了它的 PagedAttention 能把显存利用率提升不少连续批处理机制可以在不大量牺牲单请求延迟的前提下显著提高吞吐。2.3 调用层与管理界面引擎属于底层真正让 OpenRig 好用起来的是上面那层统一的 API 入口和一个能看能聊的管理界面。OpenAI 的接口格式已经成为事实标准vLLM 和 Ollama 都原生支持兼容接口调用方不需要改代码就能切换引擎这非常重要。人机交互界面我比较推荐 OpenWebUI。它可以直接连接 Ollama 或 vLLM提供聊天界面、会话管理、模型切换、知识库上传这些功能。你也可以用 FastAPI 自己包一层业务接口把内部系统的账号体系、权限逻辑接进来。OpenRig 的“组装感”就在这一步体现出来了底层引擎负责把模型跑起来OpenWebUI 负责给人用业务网关负责给系统用三者就像拼乐高互不干扰。3. 实操从零搭建一个可用的 OpenRig 环境3.1 基础环境准备我以 Ubuntu 22.04 LTS 为例因为这是目前兼容性最好的发行版NVIDIA 驱动、CUDA 运行时、容器工具链都有现成支持。系统装好之后第一步安装显卡驱动建议直接用ubuntu-drivers工具装推荐的 proprietary 版本然后重启确认nvidia-smi能正常输出显卡信息和驱动版本。Python 环境我强烈建议用虚拟环境隔离别把包装进系统 Python否则后患无穷。创建目录比如/home/rig/vllm-venv然后python3 -m venv初始化。如果要用 Docker 跑 OpenWebUI还需要装nvidia-container-toolkit否则容器里看不到 GPU装了之后一定要sudo nvidia-ctk runtime configure --runtimedocker再重启 Docker这个步骤漏掉的人非常多。3.2 推理引擎安装与模型加载先跑 Ollama 验证硬件和模型。安装脚本一行搞定curl -fsSL https://ollama.com/install.sh | sh装完先确认服务在跑然后把模型目录改到数据盘防止系统盘被几个模型塞满mkdir -p /data/ollama export OLLAMA_MODELS/data/ollama export OLLAMA_HOST0.0.0.0:11434拉取模型我用的是 Qwen2.5-7B 的指令版 GGUF 量化格式名字里q4_K_M的意思是 4bit 量化、K 量化方法、M 档大小这个档位比 Q4_0 质量略高显存差异不大ollama pull qwen2.5:7b-instruct-q4_K_M ollama run qwen2.5:7b-instruct-q4_K_M模型能正常回答问题后再装 vLLM 做正式服务。单独建一个虚拟环境然后安装python -m venv /home/rig/vllm-venv source /home/rig/vllm-venv/bin/activate pip install -U vllm启动命令我用的是 AWQ 量化版本参数含义后面会详细解释vllm serve Qwen/Qwen2.5-7B-Instruct-AWQ \ --quantization awq \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000 \ --api-key sk-local-demo这里--max-model-len 8192是上下文长度上限和显存占用呈线性关系卡不够用就调小。--gpu-memory-utilization 0.9表示把 90% 的显存预留给模型和 KV Cache剩下 10% 给显卡驱动和显示进程留余地。--api-key是 vLLM 自带的简单鉴权参数正式环境我会用更严格的网关方案。3.3 对外接口与统一入口vLLM 启动后默认监听 8000 端口提供一个 OpenAI 风格的/v1/chat/completions接口。我用 curl 验证一下服务是否正常curl http://127.0.0.1:8000/v1/chat/completions \ -H Authorization: Bearer sk-local-demo \ -H Content-Type: application/json \ -d { model: Qwen/Qwen2.5-7B-Instruct-AWQ, messages: [{role: user, content: 用一句话解释什么是 RISC-V}] }返回正常的choices结构说明管道通了。这一步做完OpenRig 的核心已经成立内部系统只要把base_url指到这台机器的 8000 端口就能开始用。用户聊天这一层交给 OpenWebUI。官方推荐用 Docker 跑我给的命令会同时连通 Ollama 和 vLLM这样一套界面就能管理两个引擎docker run -d --name open-webui \ -p 3000:8080 \ -e OLLAMA_BASE_URLhttp://host.docker.internal:11434 \ -e OPENAI_API_BASE_URLhttp://host.docker.internal:8000/v1 \ -e OPENAI_API_KEYsk-local-demo \ -v open-webui:/app/backend/data \ --add-hosthost.docker.internal:host-gateway \ ghcr.io/open-webui/open-webui:main浏览器打开 3000 端口注册一个本地账号就能在界面里看到两个引擎下的所有模型。3.4 验证与最小压测服务跑起来只是第一步我通常会做一些基础验证确保它不是“能响应”而是“能稳定响应”。先看显存实际占用和 GPU 利用率nvidia-smi nvidia-smi dmondmon可以实时滚动显示利用率、温度、显存使用观察连续几轮请求时显卡是否吃满、温度有没有异常升高。接着我会用一个简单的 Python 脚本做最小并发测试20 个并发请求同时打上去记录响应时间和吞吐量import asyncio import httpx import time async def one_call(client, i): payload { model: Qwen/Qwen2.5-7B-Instruct-AWQ, messages: [{role: user, content: 写一段 50 字的会议纪要}], max_tokens: 100, } headers {Authorization: Bearer sk-local-demo} t0 time.time() r await client.post(http://127.0.0.1:8000/v1/chat/completions, headersheaders, jsonpayload) dt time.time() - t0 return dt, r.status_code async def main(): async with httpx.AsyncClient(timeout120) as client: results await asyncio.gather(*[one_call(client, i) for i in range(20)]) for dt, code in results: print(f{dt:.2f}s {code}) ok [dt for dt, code in results if code 200] print(f成功率 {len(ok)}/20, 平均耗时 {sum(ok)/len(ok):.2f}s) asyncio.run(main())我的实测结果是单卡环境下20 个并发请求全部成功平均响应时间大约 6~8 秒。这说明连续批处理在生效请求被分批塞进 GPU 运算而不是排队等待。如果这里出现大面积超时或者显存 OOM说明并发参数需要调优后面章节会展开讲。4. 调优经验与常见问题排查实录4.1 显存不足量化与上下文长度怎么配遇到 “CUDA out of memory” 别慌这是 OpenRig 最常遇到的问题解决路径有一条明确的优先级。第一优先缩短max-model-len把 8192 降到 4096 可以让 KV Cache 显存直接减半。第二换更激进的量化格式比如 AWQ 4bit 换到 GGUF Q4_K_M。第三降低gpu-memory-utilization给系统留更多余量。第四关闭多余的前后台进程。这条优先级之所以照这个顺序排是因为改上下文长度对生成质量影响最小换量化格式可能带来微小的质量损失调低显存利用率则是让卡“闲着”而不是“干满”浪费了性能。这里有个容易忽视的细节nvidia-smi显示内存占用很高并不一定是模型吃掉的可能是之前跑死进程的显存没释放。遇到 OOM 先看一眼进程列表把残留进程杀掉再重启服务。4.2 并发差从单请求到批量服务很多人测并发发现“一多就慢”甚至“阻塞”就觉得是显卡不行。其实更常见的原因是默认并发参数没调。Ollama 默认对模型加载、并发请求都有保守限制可以设置OLLAMA_NUM_PARALLEL4让它同时处理更多请求。vLLM 的连续批处理机制则更先进它会动态地把到达的请求组合成 batch 送进 GPU但也不能无限制地塞。vLLM 里和并发最相关的参数是--max-num-seqs默认 256这个值不是越大越好。并发太高时单个请求要等 batch 里其他请求算完才能返回表现为“吞吐上去了但延迟很难看”。我一般会把max-num-seqs控制在 64 到 128 之间配合--max-padding-length一起调整。判断方法很简单跑一轮并发测试观察平均延迟和吞吐。如果平均延迟飙升而吞吐没涨说明并发参数已经到瓶颈该做容量规划了。4.3 输出质量与 Prompt 格式的坑OpenRig 跑起来了模型也响应了但生成结果不对劲这事我遇到最多的是英文回答。中文提问、中文模型结果输出变成一长串英文十有八九是系统提示词里混入了英文模板或者对话格式没按模型的 Chat Template 走。每个开源模型的对话模板都不一样尤其 Llama 系列有自己的特殊 tag。如果手动拼接 prompt 少了这些 tag模型经常会出现角色混乱、幻觉加剧、语种漂移。正确做法是永远走 OpenAI 兼容接口的messages结构让引擎自动套用模型内建的 Chat Template。vLLM 在加载模型时已经读取了这些模板只要不手动拼 prompt基本不会出格式类问题。另外temperature和top_p这两个采样参数值得仔细调temperature太高模型会“发疯”太低又容易复读。我常用temperature0.7, top_p0.9作为通用起点代码审查或抽取类任务会把 temperature 压到 0.2。4.4 常见问题速查表现象可能原因处理建议启动报 CUDA out of memory模型权重 KV Cache 超显存缩短 max-model-len、换 4bit 量化、清理残留进程请求返回 401 或 403API Key 没配或配错检查调用头里的 Authorization确认 vLLM 的 --api-key响应超时并发堆积或模型仍在加载看 nvidia-smi 确认 GPU 是否被占满调低 max-num-seqs中文问答输出英文系统提示词中英文混杂统一用中文 system prompt不要手动拼接 prompt模型加载极慢磁盘读取瓶颈确认模型文件在 SSD 上不要放机械盘OpenWebUI 看不到模型引擎地址或 Key 配置错误检查 OLLAMA_BASE_URL 和 OPENAI_API_BASE_URL 容器内可达性温度过高导致显卡降频散热不足或长时间满载观察 dmon 温度增加机箱风道必要时锁功耗5. 从能用走向好用OpenRig 的生产化补全5.1 访问控制与密钥管理OpenRig 在局域网里跑通之后第一件事不是加模型而是加访问控制。vLLM 的--api-key是最薄的防护只能防误连挡不了有意的扫描。如果服务要暴露到更广的范围我建议在前面加一层反向代理用 HTTP Basic Auth 做身份校验再用路由规则只放行/v1路径。OpenWebUI 自带用户注册、登录和会话隔离内部使用完全够了。如果业务系统要接入更好的方案是用 FastAPI 包一层自己的网关校验内部账号体系的 token再转发到 vLLM。这样就算哪天把 vLLM 换成 TensorRT-LLM调用方也完全无感OpenRig 的“门户”性质就体现出来了。5.2 日志、监控与告警推理服务最怕的不是报错而是“默默变慢”。显存泄漏、温度升高、SSD 空间耗尽这些都会让服务质量缓慢退化。vLLM 自带/metrics端点输出 Prometheus 格式的指标包括请求耗时、吞吐、KV Cache 使用率。我会再挂一个 node_exporter 收集系统级指标用一套简单的 Grafana 面板把 GPU 利用率、显存占用、请求数放在一张图上。告警规则我定了三条GPU 温度超过 85 度、磁盘剩余少于 20GB、vllm 进程消失。这三条分别对应散热故障、模型文件写满磁盘、进程崩溃。系统服务配了Restartalways之后进程崩溃会自动拉起但监控必须及时通知到人否则 OpenRig 变成“躺在那里假装健康”的黑盒。5.3 模型生命周期与备份模型管理是 OpenRig 最容易忽略的部分。模型文件动辄几个 GB如果随便放用不了几次硬盘就满了。Ollama 的好处是自带模型管理ollama list查看已装模型ollama rm删除不需要的版本。vLLM 这边我习惯把权重文件按“模型名-参数量-量化方式”的目录结构整理比如Qwen2.5-7B-AWQ、Qwen2.5-14B-GPTQ一目了然。备份策略我分两级模型权重属于“可重新下载但耗时”的资源一般不做全量冷备而是把下载命令整理成脚本方便重建真正必须备份的是配置文件、systemd 服务文件、OpenWebUI 的用户数据目录。用一个定时 rsync 把/etc/systemd/system/里的服务文件和 OpenWebUI 的 volume 目录同步到另一块盘整个 OpenRig 的“配方”就算保住了。systemd 是让 OpenRig 真正“隐形化”的关键。把启动命令写成服务文件开机自启、崩溃自动拉起配好之后就忘了它的存在。下面是一个可直接改的服务文件示例[Unit] DescriptionvLLM OpenAI-Compatible Server Afternetwork.target [Service] Typesimple Userrig WorkingDirectory/home/rig/vllm-venv ExecStart/home/rig/vllm-venv/bin/vllm serve Qwen/Qwen2.5-7B-Instruct-AWQ --quantization awq --max-model-len 8192 --gpu-memory-utilization 0.9 --port 8000 --api-key sk-local-demo Restartalways RestartSec5 [Install] WantedBymulti-user.target放好之后systemctl enable vllm和systemctl start vllm这台机器就正式成为一台可以忘掉存在感的推理节点了。我个人在实际操作中的体会是OpenRig 这套东西前后折腾了大概一周最花时间的不是装软件而是想明白每个组件之间怎么配合。硬件的显存要提前算好引擎的并发参数要按实际负载调访问控制和监控要在刚搭完热乎劲还在的时候顺手做完等真出了事再补就晚了。最后再分享一个小技巧把不同模型的启动脚本统一放在一个目录里每次切换模型只改 systemd 的 ExecStart 然后 reload比每次手动敲长命令靠谱得多。配好一套能稳定跑上几个月的推理环境之后你会有种“设备自己会呼吸”的感觉那才算真正从一个会跑模型的人变成一个会养系统的人。