大多数人使用 AI 的方式，是打开一个网页，把提示词丢给远方的数据中心。但如果你有一台常年开机的家用服务器，事情可以完全不同：让 AI 基础设施跑在自己的网络里，延迟更低、数据不出门、成本趋近于零。

这篇文章记录我搭建本地 AI 基础设施的完整过程。

为什么需要本地网关

直接使用各家 API 有两个痛点：

  1. 密钥管理混乱。每个服务一个 key，分散在不同脚本和配置里，轮转时容易遗漏。
  2. 接口不统一。OpenAI、Anthropic、Gemini 的 SDK 各不相同，换模型就要改代码。

解决方案是一个本地 API 网关——所有请求先到自己的网关，由它统一鉴权、路由、计费、限流。我选用的是 new-api，一个用 Go 写的开源项目，Docker 一行命令就能跑起来：

docker run -d --name new-api \
  -p 3001:3001 \
  -v ./new-api/data:/data \
  quantumnous/new-api:latest

启动后在管理面板里把各家的 API key 配置成"渠道"，业务代码只需要连 http://localhost:3001/v1——一个 OpenAI 兼容端点。

嵌入服务：被忽视的关键组件

本地 AI 基础设施里最容易被低估的组件是嵌入（Embedding）服务。语义搜索、RAG、内容推荐，全部依赖它。

我实测了三个候选模型：

模型 维度 特点
BAAI/bge-m3 1024 多语言，中文表现最佳
nvidia/nemotron-3-embed-1b 2048 英文强，体积大
bge-reranker-v2-m3 — 重排序模型，不能生成向量

最终选了 bge-m3。原因很实际：我的内容以中文为主，而多语言嵌入模型在跨语言检索（比如用英文查中文文档）上也有不错的表现。

一个容易踩的坑：换嵌入模型后必须清空旧向量重新计算，不同模型的向量空间不可比。

向量检索的落地场景

有了嵌入服务，第一个落地的场景是个人知识库的语义搜索。

我的知识库存在 Obsidian vault 里，几千篇笔记。传统的全文搜索只能匹配关键词，而"上次那个关于缓存失效的问题"这种自然语言查询，需要语义理解。

架构很简单：

笔记变更 → 监听文件 → 分块 → bge-m3 嵌入 → 存入向量库
查询 → 嵌入 → 相似度检索 → Top-K 结果

关键细节是分块策略。笔记不像论文有天然章节，我按 markdown 标题切块，每块保留前 200 字作为上下文摘要，避免语义断裂。

多 Agent 协作：基础设施的终极形态

本地 AI 基础设施的真正价值，不在于省几块钱 API 费，而在于让多个 AI Agent 共享同一套基础设施。

我目前的拓扑：

  • x99（工作电脑）：主力开发机，跑 Hermes、prime-agent、opencode
  • n7（家用服务器）：常年开机，跑网关、向量库、备份任务

两台机器通过内网互通，vault 通过 rsync 单向同步。每个 Agent 有自己的"记忆协议"——任务前读共享知识库，任务后把重要结论写回。

这套架构下，AI 不再是"一问一答的工具"，而是有持久记忆的协作者。金鱼模式（每次对话都失忆）是个人效率的最大杀手之一，而本地基础设施给了它一个体面的解法。

成本与收益

一台闲置的家用服务器，电费大约每月几十块。换来的是：

  • 所有 AI 服务延迟 < 10ms（内网）
  • 数据完全私有
  • 多 Agent 共享一套网关和向量库
  • API 用量统一可视、可限流

基础设施的价值，永远在复利里。 单个功能看起来都不起眼，但组合起来，它们构成了一个持续运转的个人 AI 系统。

结语

本地 AI 基础设施不是一个"极客玩具"，它是个人数字生活的底座。就像你不会把家庭网络的核心路由器换成手机热点一样，当 AI 成为日常工具时，它也应该有自己的"家"。