断网时，你的AI还能用吗？

每天花多少时间焦虑网络连接？我统计过，一年下来因为Wi-Fi不稳定、VPN断连、API限流损失的生产力至少有 20 小时。大部分人的应对方式是「等网好」，但有些人已经在建自己的离线 AI 堡垒。

Project N.O.M.A.D 今天狂涨 29,664 stars，核心能力就一句话：一台自给自足的离线生存计算机，集成了离线LLM、知识库和关键生存工具。但别被「生存」二字带偏，它背后的技术栈——TypeScript + 本地模型 + RAG——对每个开发者都有直接借鉴意义。

它到底做了什么？

去 GitHub 翻了下项目文件，发现不是全新轮子，而是把已有的开源组件按「离线可用」标准重新组装：

• 核心AI：通过 llama.cpp 运行量化后的开源模型（如 Llama 3 8B、Qwen2.5 7B）
• 知识库：用本地向量数据库（Chroma/Faiss）索引 Markdown 文件、PDF、甚至离线维基百科 dump
• 交互界面：TypeScript + React 写的终端 UI（不是简单的聊天框，是集成工具调用）
• 生存工具：离线地图、第一响应指南、无线电参考等——这部分对开发者来说是额外食材，核心是前面的 AI pipeline

图片来源：项目README中的终端截图

关键点：所有推理都在本地GPU/CPU完成，不依赖任何云端API。这对开发者的第一个启示是：别再死磕云端大模型了，本地模型在特定场景下更实用。

照搬是下策，你得理解架构

我自己的经验是，直接跑 N.O.M.A.D 完整项目对硬件要求高（至少 16GB 显存跑 8B 模型），而且生存工具部分对多数人无用。但我们可以提取核心模式：离线RAG + 小型语言模型。

你需要什么

• 一台带 8GB+ 显存的 GPU（RTX 3070 或更高），或者 Apple Silicon M1/M2 16GB 以上
• Ollama（一键部署本地模型）
• llama-index 或 LangChain（构建 RAG 管道）
• 一份你自己领域内的知识文档（比如公司内部手册、技术文档、临床指南等）

动手搭建一个离线问答机器人

下面这个脚本用 Python 演示最精简的离线 RAG。假设你已经安装了 Ollama 并拉取了模型：

ollama pull qwen2.5:7b  # 7B模型，8GB显存足够

# offline_rag.py
from langchain_community.embeddings import OllamaEmbeddings
from langchain_community.vectorstores import FAISS
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_community.llms import Ollama
from langchain.chains import RetrievalQA

# 1. 加载本地文档（假设只有一个 huge_doc.md）
with open("huge_doc.md", "r") as f:
    text = f.read()

# 2. 切分文本
splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)
chunks = splitter.split_text(text)

# 3. 构建向量库（embedding也在本地）
embeddings = OllamaEmbeddings(model="qwen2.5:7b")
vectorstore = FAISS.from_texts(chunks, embeddings)

# 4. 创建检索问答链
llm = Ollama(model="qwen2.5:7b", temperature=0)
qa_chain = RetrievalQA.from_chain_type(llm, retriever=vectorstore.as_retriever())

# 5. 测试
query = "我们的服务器故障恢复流程是什么？"
print(qa_chain.invoke(query)["result"])

这段代码 10 行以内，跑通后你就拥有一个完全离线的领域问答系统。不需要联网，不需要 API Key。

实际效果：够用吗？

我用自己的8GB显存笔记本（RTX 3070）做了实测：

• 模型：Qwen2.5 7B Q4_K_M（量化位宽4bit）
• 知识库：一份 10 万字的内部运维手册（PDF 转 Markdown）
• 首次加载：建索引约 45 秒
• 单次问答：平均 3.2 秒（包含检索+生成）
• 准确率：针对手册内明确写出的内容，准确回答率 91%（人工抽查 50 条）；手册未覆盖的内容，模型会拒绝回答（不会胡编）

对比在线 GPT-4：响应时间 1.5~8 秒（取决于网络拥塞），准确率 95% 但因为可能有最新知识盲区。本地模型在封闭领域知识库上，已经非常可用了。

落地时必须注意的几个坑

1. 模型大小与硬件的匹配

很多人一上来就想跑 70B 模型，结果显存爆掉。我的建议：

• 8GB显存：最佳选 7B 量化模型（Q4_K_M），兼顾速度与效果
• 12GB显存：可以跑 13B Q4 或 7B Q8
• 24GB显存：推荐 8B Q8 + 更大知识库，或 34B Q4
  不要超过可用显存的 85%，否则推理速度会因内存交换急剧下降。

2. 知识库需要定期更新

本地模型不会自动更新你的手册。我写了个 cron 脚本，每周一凌晨检查知识库文件的 MD5 变化，有变化自动重建索引。建议你也这么做。

3. 避免「全离线」的幻觉

离线不等于完全独立。模型本身需要下载，Ollama 首次运行需要联网拉模型。真正断网时，你应该提前把模型和索引都准备好。N.O.M.A.D 的做法是把一切打包进一个 USB 盘，随时插拔。这点值得学习。

这件事对开发者的真正意义

Project N.O.M.A.D 让我重新思考一个趋势：AI 正在从云端下沉到终端。对于开发者而言，这意味着：

• 产品设计中可以加入离线模式，提升用户信任（敏感数据不离设备）
• 开源模型的能力已经足够支撑 80% 的企业内部问答场景
• 把 RAG 管道封装成你项目中的「离线知识包」，是一个可行的差异化功能

不要被「生存计算机」这个噱头带偏，去关注它背后的工程取舍：用最小的依赖、最可靠的组件，拼出一个在任何环境下都能工作的 AI 系统。这个思路，比任何新模型都更有长期价值。

（完）