NAS玩转本地私有大模型与RAG知识库：Ollama+AnythingLLM+Docker硬核部署与GPU直通踩坑

5次阅读

共计 3475 个字符，预计需要花费 9 分钟才能阅读完成。

很多朋友把威联通、群晖或自建的 TrueNAS/Unraid 搬回家后，日常除了挂 PT、跑 Plex/Jellyfin 和做定时备份，机子长年处于算力闲置状态。近来很多开发者和小团队都在折腾本地知识库（RAG），但公有云 API 既有隐私泄露风险又有 Token 计费焦虑。其实，只要你的 NAS 拥有一颗支持核显硬解的 Intel CPU（第 8 代及以上）或者塞了一张半高 N 卡（比如 RTX 3060/4060），完全可以直接把它打造成 24 小时不间断运行的离线大模型与企业级代码 / 文档知识库。

在折腾 NAS 本地 AI 方案的初期，我试过用纯 Python 脚本手搓一套基于 Langchain + ChromaDB 的工作流。但跑在 NAS 这种多任务容器化宿主机上，依赖冲突、显卡驱动容器穿透以及前后端分离管理简直是场运维灾难。后来我全面倒向了更加工程化、解耦更彻底的架构：Docker + Ollama（底层推理引擎）+ AnythingLLM（向量嵌入、文档切片与多租户前端）。

这套组合有三个直戳痛点的优势：

资源占用极度可控： 底层模型引擎（Ollama）与上层业务完全解耦，模型量化格式统一为 GGUF，显存不够可以直接利用 NAS 大容量内存通过 mmap 卸载机制（CPU Offloading）平稳补足。
文档切分与向量索引开箱即用： AnythingLLM 自带轻量级内置向量库（LanceDB），不需要你额外拉一个极其吃内存的 Milvus 或 Pinecone 容器，对 16GB-32GB 内存的 NAS 极其友好。
完整的权限与 API 隔离： 可以在局域网内分配只读、编辑权限，还能提供兼容 OpenAI 格式的标准 API 给 Obsidian、沉浸式翻译或 VS Code 的 Continue 插件调用。

这是整套方案中最容易翻车的环节。很多人在 NAS 的 Portainer 里简单拉个 ollama/ollama:latest 镜像，结果跑起来发现模型推理纯走 CPU，8 个核心被占满不说，Tokens 每秒输出（TPS）直接掉到惨不忍睹的 1.5。必须把 NAS 的 GPU 资源穿透给容器。

确保宿主机已经安装了 nvidia-container-toolkit。编写你的 docker-compose.yml 片段：

version: '3.8'

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama-nas
    restart: unless-stopped
    ports:
      - "11434:11434"
    volumes:
      - /volume1/docker/ollama:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    environment:
      - OLLAMA_KEEP_ALIVE=24h # 避免空闲时模型频繁从内存 / 显存中卸载和重载
      - OLLAMA_NUM_PARALLEL=2 # 限制并行并发数，防止并发把 NAS 显存挤爆

如果是 11 代、12 代以后的 Intel 集显（iGPU），目前通过纯 CPU-AVX2 或借助 OpenVINO 加速也能跑得很体面。需要挂载 DRI 驱动设备节点：

    devices:
      - /dev/dri:/dev/dri # 穿透核显驱动渲染节点
    environment:
      - OLLAMA_NUM_PARALLEL=1
      - OLLAMA_FLASH_ATTENTION=1 # 开启注意力机制显存优化

容器跑起来后，进容器执行拉取。对于 NAS 部署，不要贪大求全，强烈推荐 Qwen2.5-7B-Instruct-Q4_K_M 或 Llama-3.1-8B-Instruct-Q4_K_M。4-bit 量化版本模型文件仅需 4.7GB 显存，推理速度与逻辑能力在小尺寸模型中平衡得极好：

# SSH 登录 NAS 进入容器拉取模型
docker exec -it ollama-nas ollama run qwen2.5:7b-instruct-q4_K_M

# 别忘了拉取一个专用于 RAG 文本向量化的高质量 Embedding 模型（推荐 nomic-embed-text，上下文长且小巧）docker exec -it ollama-nas ollama pull nomic-embed-text

有了底层推理接口，接下来部署负责文档解析、切块向量化的 AnythingLLM 容器。我们需要把它们连在同一个 Docker 网桥中，避免跨容器走外网反代降低吞吐。

  anythingllm:
    image: mintplexlabs/anythingllm:latest
    container_name: anythingllm-nas
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - /volume1/docker/anythingllm/storage:/app/server/storage
    environment:
      - SERVER_PORT=3001
      - STORAGE_DIR=/app/server/storage
    depends_on:
      - ollama

LLM Provider 配置： 选择 Ollama，Base URL 填入容器内网通信地址：http://ollama:11434（如果未加入同一自定义 Docker 网络，则填 NAS 本地静态 IP http://192.168.x.x:11434）。
Embedding 引擎配置： 很多人默认用 AnythingLLM 内置的 ONNX 模型，不仅极其消耗 CPU 资源，处理中文还经常出现语义漂移。这里务必切换为 Ollama，模型选择刚刚下载好的 nomic-embed-text。
Vector Database： 直接勾选默认的 LanceDB。在文档总数少于 20 万篇的个人及小团队场景下，LanceDB 基于文件系统的轻量查询响应耗时仅在几十毫秒级，比单开一套 Milvus 容器省下至少 1.5GB 的常驻内存。
文本切块（Text Splitter）优化： 默认的 Chunk 长度通常是 1000 Tokens，但在实操中如果丢进去很多开发文档、接口 JSON 或 Markdown 笔记，1000 会导致上下文被截断太碎。建议把 Max Chunk Length 调整为 600~800，并将 Chunk Overlap 设为 100~150，显著提高语义检索的命中率。

我在测试一份 80 页的微服务架构规范 PDF 时发现，RAG 的召回内容非常散。排查发现是 AnythingLLM 的温度系数（Temperature）默认为 0.7，这个值对于创意写作合适，但对严谨的技术文档问答而言太高了。在 Workspace 设置中，将 Temperature 调到 0.1~0.2，并调整检索返回数量（Top-K）至 3~4，回答准确度立竿见影地提升，基本消除了幻觉。

如果你的 NAS 显卡显存较小（例如 6GB 显存的卡跑 7B 模型再加上向量计算），当并发请求进来时，Ollama 很容易把显存吃穿，进而触发 Linux 内核的 OOM 保护干掉进程。解决办法是在运行参数中严格限制上下文窗口大小：

# 创建一个自定义 Modelfile 来锁死 context 长度
FROM qwen2.5:7b-instruct-q4_K_M
PARAMETER num_ctx 4096
PARAMETER num_predict 512

将上下文强行限定在 4096 Tokens，可以稳稳将 VRAM 占用锁定在 5.2GB 以内，彻底告别突发崩溃。

经过两周的持续高频使用，这套基于 NAS 的全天候本地知识库方案已经完全嵌入到我的日常开发流中：不仅是写代码时可以随时查阅私有工程的规范脚手架，平日收集的各类数据表、设备操作手册也全被丢进 AnythingLLM 建立了专属检索 Workspace。只要选对量化模型尺寸、用 Docker 把驱动打通、把 Embedding 引擎交给专有小模型打理，哪怕只是一台闲置的家用 NAS，也能稳定输出令人惊艳的本地私有 AI 算力。

正文完