Privacy-First Local AI — 完全本地、零外传的 AI 工作栈
十件开源资产,面向数据绝对不能出门的行业 — 律所、医院、政府、外贸合规。从模型 runtime、聊天 UI、文档 RAG 到协议层全套本地化。不调用任何厂商 API、零遥测、不存在「我们可能会用您的对话改进服务」这种条款。
这个 pack 包含什么
这个 pack 是给读到厂商合同里那句「我们可能会用您的数据改进服务」就直接放下笔的买家:办特权事务的律所、处理 PHI 的医院、上了物理隔离网的政府机关、合同条款不能落到德州某台 OpenAI 服务器上的外贸商。整套设计的核心是 推理时不调任何外部 API。
按层切开是这样:
- Runtime 层 — 加载模型权重、对外吐 token 的引擎。Ollama / LM Studio / MLC-LLM 在这一层。
- UI 层 — 不懂技术的律师、医生实际打开的那个窗口。Open WebUI / Jan / GPT4All / LibreChat / Text Generation WebUI 全都是「本地版 ChatGPT」的不同形态。
- RAG 层 — 把模型接到你自己的文档(案卷、病历、报关单)。Khoj 监听一个文件夹,再以 API 形式喂回给本地模型。
- 语音层 — Faster Whisper 本地转写会议、问询、医患对话,音频永远不会到达任何云 STT 厂商。
这是我们 local-first-ai pack(面向开发者个人战机)和 local-llm-runners pack(runtime 横向对比)的隐私优先姊妹篇。这一份明确针对 强监管行业的部署形态 — 当合规官才是真正签字放行的人,你该装哪些工具。
推荐安装顺序
- Ollama — 从这里开始。单二进制,macOS / Linux / Windows 都跑,
ollama pull llama3.1拉模型,localhost 上吐一个 OpenAI 兼容 HTTP API。下游所有东西 — UI、RAG、agent — 都可以把 Ollama 当作 OpenAI 来对接,意味着你只改一个 base URL 就能把任何云端方案翻译成全本地。 - LM Studio — 给不用 CLI 的人备的 GUI 替代品。干的事一样(装 GGUF 权重、起本地 OpenAI 端点),但带桌面 app 做模型搜索、下载、聊天。律师 / 医生工作站上装这个,服务器上装 Ollama。
- MLC-LLM — Ollama 在你的硬件上嫌慢的时候上。用 TVM 编译模型,原生跑在 Apple Silicon、NVIDIA、AMD 甚至 WebGPU 上。如果你的吞吐目标是单工作站同时支撑 10+ 人实时聊天,多花的配置时间值。
- Open WebUI — ChatGPT 复刻。Docker Compose 起,指向 Ollama 的端口,给你多用户账号、聊天历史、模型切换、文档上传。这是终端用户实际打开的那个东西。强监管环境里部署得最多的本地聊天 UI,原因就是它的人均权限模型。
- Jan — 桌面 app 版的 Open WebUI 思路。跨平台 Electron 客户端,内置模型下载器。每个用户一台笔记本、你不想搭中心服务器的时候用它。
- GPT4All — 跟 Jan 同生态位,不同出身(Nomic)。二进制更小、默认模型选得更保守、纯 CPU 老机器也勉强能跑。装在每个信贷员桌上那台用了 5 年的 ThinkPad 上正合适。
- LibreChat — 想要一个前端横跨本地 +(精心放白名单的)云的组织用它。混合场景有用:特权事务路由到 Ollama,一般检索路由到签了合同的云厂。可以做人均路由规则。
- Text Generation WebUI — 高阶用户的兜底。支持比谁都多的模型格式(GGUF、GPTQ、AWQ、EXL2、transformers),暴露原始采样参数,可以跑 LoRA。研究员需要在内部数据上微调模型、又要保持流程私有的时候装它。
- Khoj — RAG 层。监听一个文件夹(案卷、病历、报关 PDF),本地做 embedding,再以聊天 UI 或 API 形式喂回去给任何工具用。把 embedding 和 generation 都配成走 Ollama,你的文档永远不会离开这台机器。
- Faster Whisper — 会议 / 问询 / 医患对话的转写。同精度下比原版 Whisper 快 4 倍。把它的输出灌进 Khoj,你就有了一个完全本地的「参与了这场会议的 AI」,音频不需要发给 AssemblyAI、Deepgram、OpenAI。
它们怎么协同
┌──────────────────────────────────────────────────────────┐
│ 你的工作站 / 机房服务器(出网完全关闭) │
└──────────────────────────────────────────────────────────┘
笔记本 GPU / 服务器 GPU / Apple Silicon NPU
│
▼
┌──────────────────────────────┐
│ Runtime:Ollama / LM Studio │ ◄── 实时多用户需要时
│ (OpenAI 兼容 API) │ 改 MLC-LLM
└──────────────────────────────┘
│
┌─────────┴────────────────────────┐
▼ ▼
聊天 UI RAG 层
├─ Open WebUI (浏览器、多用户) Khoj ◄── 监听文件夹
├─ Jan (桌面客户端) │ (案卷 / 病历 /
├─ GPT4All (低配老机器) │ 报关 PDF)
├─ LibreChat (混合路由) ▼
└─ Text Generation WebUI(高阶) 本地向量库
(SQLite / Qdrant 磁盘文件)
│
▼
Faster Whisper ─► 转写文本 ─► Khoj ─► AI 回答
(音频进、文本出,全本地) 你录的会议
这个结构故意僵硬:一个 runtime 在底层(保证所有下游都指向同一个 OpenAI 兼容 URL)、按用户人群选 1 个或几个 UI、文档重要就上 1 个 RAG 服务、会议重要就上 1 个语音引擎。别同时跑两个 runtime — 那是同一台机器上塞 30 GB 重复模型权重的最快办法。
你会遇到的取舍
- 硬件门槛是真实存在的 — 一个 4-bit 量化的 7B 模型大约要 5 GB 内存,M1/M2 上跑 15-30 tok/s。70B 模型要 40 GB+,M3 Max 上跑 2-5 tok/s — 批处理还行,交互式聊天会痛苦。别向合规官保证「16 GB MacBook 跑出 GPT-4 质量」。
- 质量 vs 大厂前沿模型 — 一个强开源模型(Llama 3.1 70B、Qwen 2.5 72B)在短问答上大致是 GPT-4 量级,长文推理明显弱。特权文书起草,预期比走云前沿模型多 1-2 轮修订。监管买家基本都能接受 — 替代方案是把特权数据发给第三方。
- 维护成本 — 部署归你了。模型升级、GPU 驱动升级、向量库压缩、日志轮转 — 全你的。每 50 个活跃用户预算 0.2-0.5 FTE 的 IT 工时,第一年更多。
- 多用户并发 — Ollama 默认串行处理请求。单卡 5 个以上并发用户,要换真正的推理服务器(vLLM、TGI)放在 Open WebUI 后面。本 pack 的工具组合在单团队规模下正确;同一批 UI 在 vLLM 前面也能跑,规模扩了以后无缝切。
- 物理隔离 vs 部分隔离 — 「全本地」其实分两种姿态。物理隔离:机器完全无网,模型靠 U 盘预装,升级走审批流程。网络隔离:机器只对外开 OS 升级用,AI 流量全部留在 localhost。第二种轻松得多;第一种是部分政府 / 国防买家真的会要求的。
常见踩坑
- M1 / 16 GB MacBook 想跑 70B — 装不下。会走 mmap 然后把 SSD 抖到冒烟。16 GB 老老实实 7-13B,32 GB 上 30-34B,64 GB+ 才碰 70B。Apple 的统一内存让这事比独立 GPU 容易,但数学还是数学。
- 模型选错语种 — 主流开源 base 模型都偏英文。中文法律文本选 Qwen 2.5(中文原生强)。日文病历选 ELYZA 这类微调。给非英文语料挑 Llama 3.1 然后抱怨质量,是最常见的失败模式。
- RAG 切块策略 — 朴素的 1000-token 切法会毁掉合同条款(每条款是独立逻辑单元)和病历记录(每条带时间戳、原子)。先按文档具体边界配好 Khoj 的 chunker,再去 embed 5 万个案卷,否则会发现检索完全没用。
- 忘了关遥测 — Open WebUI、Jan、Text Generation WebUI 都默认带一个可选的匿名遥测。在配置里显式关掉,再用抓包工具验证一次。整套栈的卖点就是「零外联」,一个忘勾的 checkbox 能毁掉整个合规叙事。
- PHI / 特权数据明文落盘 — 模型权重本地了不假,但 Khoj 的向量库如果明文躺在同一块硬盘上,笔记本被偷照样全漏。栈里每台机器都开全盘加密(FileVault / LUKS / BitLocker)。这是审计里最后才发现的发现,所有其他隐私控制都过了之后才暴露出来。
10 个资产打包就绪
常见问题
M1 + 16 GB 内存的 Mac,这套栈实际能跑动哪些东西?
舒服跑:Ollama 或 LM Studio 装 Llama 3.1 8B 或 Qwen 2.5 7B 的 4-bit 量化(驻留内存 ~5 GB)、Open WebUI 或 Jan 当聊天 UI、Khoj 索引一个不大的文档集(< 10000 块)、Faster Whisper 做短转写。能跑出 15-25 tok/s,交互式聊天和私有文档 Q&A 完全够用。跑不动的:70B 模型(要 40 GB+)、实时多用户并发(Ollama 串行)、需要独立向量库进程的大规模 RAG 语料。真在意的话,升级目标是 64 GB 的 M3 Max — 能舒服跑 70B 并支撑小团队。
我们全是 Windows 桌面、没有 GPU,这套栈还行得通吗?
行,但模型尺寸要降。Ollama / LM Studio / GPT4All 在 Windows 上都能纯 CPU 跑。老老实实用 3-7B 模型走重量化(Q4_K_M 或更小),预期 3-8 tok/s — 单人专注问答能用,聊天式来回会痛苦。CPU 上做文档 RAG,Khoj 能用但 embed 10000 个文档要跑一晚。现实形态:一台中配工作站配一张消费级 GPU(RTX 4070 起步)当本地 AI 服务器,其他人 Windows 笔记本上浏览器打开 Open WebUI 指向那台服务器就行。一张 GPU 服务器永远赢过 10 台纯 CPU 笔记本。
医院怎么把这套栈接进电子病历(EMR / EHR)?
不要直接把 EMR 数据库喂给模型 — 按固定节奏从 EMR 抽一个精挑过的子集(医嘱、出院小结、化验单)到一个文件夹,让 Khoj 或类似 RAG 服务监听。EMR 仍然是 source of truth;AI 栈只看到你的数据工程师选择暴露的那一部分,PHI 字段按医院政策做 token 替换。Faster Whisper 本地处理口述医嘱,音频不接触任何云 STT 厂商。集成工作主要是把 EMR(Epic / Cerner / 国内 HIS)建一条单向 ETL 到 Khoj 监听的文件夹,再让医院 IT 给操作系统镜像盖章。首次部署预算 4-8 周,大部分时间花在合规评审,不是工程。
这套栈实际能离线 / 物理隔离运行多久?
无限期,但有 caveat。Ollama 或 LM Studio 一旦把你想用的模型权重拉下来,推理就完全不需要外网。Open WebUI / Khoj / Jan 全在 localhost。无网环境下的维护节奏是:模型升级靠 sneakernet 导入(联网机器下 GGUF、U 盘拷到隔离机),系统和依赖升级走同样流程,审计日志精确写明每个工具跑的是哪个版本。我们见过这个 pack 目标用户群 6-12 个月不做任何升级的部署。真正的约束不是「能不能离线」 — 是你的团队能不能容忍跟不上开源版本节奏。挑一条基线(Llama 3.1、Ollama 0.3.x、Open WebUI 0.3.x),按计划周期升级。
我们升级到更新的模型,聊天历史和已索引文档会丢吗?
不会,如果你一开始把存储布局设计对。Open WebUI 把聊天存在自己的 SQLite 里;这跟 Ollama 当前在服务哪个模型完全独立。Khoj 把 embedding 存在独立的向量库里;切 LLM 不会让它们失效,但切 embedding 模型会(因为新向量住在不同的几何空间)。实操规则:钉住一个 embedding 模型(比如 nomic-embed-text 或 BGE-M3),没把整个语料重建索引的准备,永远别动它。聊天 LLM 可以随便升级 — 老聊天仍然能读,新聊天用新模型。在第一个用户问「我的笔记怎么不见了」之前,把这件事写进运维手册。