陈陈读书上个月有个做数据分析的朋友跟我抱怨：客户给了一批脱敏后的业务数据，想用大模型做信息抽取和摘要，但企业规定任何数据都不能发到外部 API。他试了一圈市面上的工具，要么只能在命令行里玩个小模型，要么就是绑定了云端服务，绕来绕去还是过不了合规那一关。我问他：为什么不直接在本地起一套完整的推理服务？他愣了半天。
后来我把自己在内部折腾了小半年的方案发给他看，就是我这边代号叫 IronClaw 的这套本地 AI 基础设施。它不是某个单一软件，而是把模型管理、推理引擎、API 网关、访问控制、监控日志这几个环节用开源组件拼起来的一套体系。核心思路很简单：大模型完全跑在自己的机器上，对外只暴露一个兼容 OpenAI 格式的接口，所有数据在本地闭环，谁调了哪个模型、传了多少 token，全都有日志可查。
这套方案我实际用了挺长时间，中间经历过显存爆掉、并发排队、模型答非所问、网关被人扫端口这些乱七八糟的问题，也一点点把流程理顺了。这篇东西我尽量把从选硬件、装环境、配模型、调性能到做安全加固的完整过程写出来，适合下面这几类人看：
- 公司有数据合规要求，不能把业务数据发给外部大模型 API 的人；
- 手头有一块还不错的显卡，想在家搭一个私有 AI 服务、给局域网内多个设备用的人；
- 用 Ollama 玩过一阵，但觉得单机命令行不够用、想升级成"带认证、带审计、带并发管理"的正规服务的人。
1. 先把话说清楚：IronClaw 到底是套什么方案
1.1 它不是某个软件，而是一套组合逻辑
IronClaw 这个名字是我们内部的叫法，寓意是"用爪子牢牢抓住自己的数据"。整个方案里没有一个是自研的神秘组件，全部是成熟开源项目，我做的只是把它们按照正确的姿势拼到一起。
组件分工大概是这样的：
| 层次 | 承担职责 | 我用的方案 |
|---|---|---|
| 基础设施 | 容器运行、GPU 透传 | Docker + NVIDIA Container Toolkit |
| 推理引擎 | 真正跑模型、生成 token | vLLM（主力）+ llama.cpp（备选） |
| 模型仓库 | 管理本地模型文件、版本、量化格式 | HuggingFace CLI + 本地模型目录 |
| API 网关 | 统一入口、认证、限流、审计 | FastAPI + 自研轻量 Token 中间件 |
| 前置代理 | TLS 终结、路由转发 | Nginx |
| 可观测性 | token 统计、显存监控、日志采集 | Prometheus + Grafana + Loki |
你可以把 vLLM 理解成发动机，模型是油，FastAPI 那层是车身控制系统，Nginx 是车门，Prometheus 和 Grafana 是仪表盘。平时本地自己玩，可以只用发动机和油；但一旦要让团队用、让业务系统接，车身、车门和仪表盘一个都不能少。
1.2 它解决了单机玩模型时最头疼的几个问题
我用 Ollama 也跑了挺长时间，单机自嗨确实爽，ollama run qwen2.5 一条命令就能聊起来。但真的拿来当基础设施用，问题就出来了：
- 没有统一的认证机制，局域网里谁拿到端口谁就能调用；
- 没有调用审计，出了问题不知道谁调的、调的哪个模型；
- 连续多个请求进来时，Ollama 的并发排队策略比较粗糙，一个长任务能把后面所有请求堵死；
- 模型一多，管理起来全靠记忆，没有版本概念，换模型要手动停服务。
IronClaw 这套方案要解决的，不是"怎么把模型跑起来"，而是"怎么把模型跑成一个受管控的服务"。这是两个量级的事。
1.3 那些年我踩过的"伪本地"坑
我得先说一句大实话：市面上很多号称"本地部署"的产品，其实只是把客户端装在你机器上，模型推理还是在云端完成的。判断方法很简单：拔掉网线，看它还能不能用。 真正的本地 AI 服务，拔了网线照样能跑，因为它只依赖本机的 CPU、GPU 和硬盘。IronClaw 从设计上就保证这一点，所有模型权重都落在本地磁盘，推理进程只监听内网地址。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 硬件底座的三个选择题：显卡、内存与存储怎么不踩坑
2.1 显卡选型的核心不是"越大越好"，是"够用且不浪费"
很多人上来就问：是不是得上 A100？其实绝大多数场景用不到。本地部署大模型，显卡选择主要看两个参数：显存容量 和 显存带宽。
显存容量决定你能跑多大参数的模型。以 Qwen2.5 系列为例，7B 模型用 4-bit 量化后大约需要 6-7GB 显存，14B 模型 4-bit 量化大约需要 11-13GB，32B 模型 4-bit 量化需要 22-26GB。如果你手头是 24GB 显存的 RTX 4090，那 14B 模型可以跑得很从容，32B 模型用 4-bit 量化也能塞进去但余量不大。
显存带宽则决定生成速度。同样一个 14B 模型，RTX 4090（带宽约 1TB/s）和 RTX 4060（带宽约 272GB/s）的出字速度能差好几倍。大模型推理是显存带宽密集型任务，这句话我在实际测试中体会特别深——同一个 GGUF 文件，放 4090 上能跑到每秒 60-80 个 token，放 4060 上可能只有每秒 10 几个。
所以我给的建议是：预算有限的话，优先保显存带宽，其次才是显存容量。二手 3090 是性价比很高的选择，24GB 显存、936GB/s 带宽，实际跑模型的表现跟 4090 差距没有价格差距那么大。
2.2 内存和存储：容易被忽视的系统性瓶颈
除了显卡，有两个地方特别多人忽略。
第一是系统内存。加载模型的时候，推理引擎通常会把模型权重先读到系统内存再拷贝到显存。如果系统内存不够，系统会走 swap，那加载速度慢到怀疑人生。我的经验是：至少要有显卡显存的 2 倍以上系统内存。比如 24GB 显存，系统内存至少 48GB，64GB 会更从容。
第二是存储。一个 14B 的模型，不量化的话光权重文件就 28GB 以上，4-bit 量化后大概 8-10GB。如果你打算多放几个模型，加上 Docker 镜像、日志、监控数据，2TB 的 NVMe SSD 是最基本的。而且务必注意：模型文件的读取速度会影响首次加载时间，也影响换模型时的体验。 用机械硬盘存模型，加载一个 14B 模型可能要等好几分钟，用 PCIe 4.0 NVMe 基本几十秒搞定。
2.3 一张关于多大显卡跑多大模型的参考表
| 模型规模 | 量化方式 | 占用显存（约） | 最低建议显卡 | 实际体验 |
|---|---|---|---|---|
| 7B | Q4_K_M | 6-7GB | 8GB 显存 | 流畅 |
| 14B | Q4_K_M | 11-13GB | 16GB 显存 | 流畅 |
| 32B | Q4_K_M | 22-26GB | 24GB 显存 | 可用，余量紧张 |
| 32B | AWQ/GPT |