NAS深度改造：基于Docker与Ollama部署DeepSeek私有化RAG知识库实战

2次阅读

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

很多极客手里的低功耗 NAS 平时只用来跑 qBittorrent、Plex 或是存冷备份，CPU 占用常年趴在个位数。随着近期 DeepSeek-R1 系列开源权重与蒸馏模型大火，将本地 NAS 升级为一个 24 小时低噪音待机、数据完全不出内网的“私有智能知识库中枢”成了性价比极高的选择。

我上周用手头一台运行 Debian 12 的 8 盘位自建 NAS，插上一张二手的 RTX 3060 12G（单槽 / 双槽涡轮卡更优），彻底打通了 Ollama + DeepSeek-R1:14b + Qdrant + AnythingLLM 全套私有管线。整套方案在小团队内部测试跑了三天，吃下了几百份内部架构设计 PDF 和 Markdown 文档。本文把这套可复现的极客架构、显卡穿透踩坑点以及针对 ZFS 存储的 I/O 调优细节完整端出来。

跑本地 LLM 最致命的瓶颈永远是显存带宽和容量。家用 NAS 绝大多数是 Xeon E3、Intel 12/13/14 代非 K 平台或 AMD 平台，内存通常在 32G 到 64G 左右。模型选型必须卡在甜点位：

显卡选型：RTX 3060 12G（小成本极客首选）或单卡 RTX 4060Ti 16G。显存必须大于等于 12GB，否则加载 14B 参数模型时一旦 Context 窗口撑大直接挤爆（OOM）。
模型规格：deepseek-r1:8b（全显存容纳，生成速度可达 45+ tok/s）或 deepseek-r1:14b 的 Q4_K_M 量化版本（12G 显存压线跑，约 18~22 tok/s）。
存储规划：模型文件（几十 G）以及向量数据库（高频随机读写）切记不要直接扔在机械硬盘阵列上，必须放在 NVMe SSD 的专用 Pool 中。

Debian 12 默认开源驱动 Nouveau 必须禁用。首先安装官方驱动和 nvidia-container-toolkit。这一步如果漏掉，Docker 内部无论如何都抓不到显卡。

# 1. 禁用系统自带 nouveau 驱动
sudo bash -c "echo -e'blacklist nouveau\noptions nouveau modeset=0'> /etc/modprobe.d/blacklist-nouveau.conf"
sudo update-initramfs -u

# 2. 安装非自由驱动组件（以 Debian 官方源为例）与基础工具
sudo apt update && sudo apt install -y linux-headers-$(uname -r) nvidia-driver firmware-misc-nonfree

# 3. 安装 Nvidia Container Toolkit
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt update && sudo apt install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

检查宿主机显卡状态，执行 nvidia-smi，若能看到 GPU 拓扑及驱动版本（建议驱动版本 ≥ 535），基础层才算就绪。

知识库体系中，Ollama 负责推理计算，Qdrant 负责海量切片文本的向量索引检索，AnythingLLM 负责解析文档、权限隔离与前端交互。我们在高速 SSD 挂载点（如 /mnt/nvme-pool/docker/ai）下创建 docker-compose.yml：

version: '3.8'

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    ports:
      - "11434:11434"
    volumes:
      - /mnt/nvme-pool/docker/ai/ollama:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    environment:
      - OLLAMA_KEEP_ALIVE=24h
      - OLLAMA_NUM_PARALLEL=2

  qdrant:
    image: qdrant/qdrant:latest
    container_name: qdrant
    restart: unless-stopped
    ports:
      - "6333:6333"
    volumes:
      - /mnt/nvme-pool/docker/ai/qdrant_storage:/qdrant/storage

  anythingllm:
    image: mintplexlabs/anythingllm:latest
    container_name: anythingllm
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - /mnt/nvme-pool/docker/ai/anythingllm:/app/server/storage
    environment:
      - SERVER_PORT=3001
      - STORAGE_DIR=/app/server/storage
    depends_on:
      - ollama
      - qdrant

启动容器集群并拉取 DeepSeek-R1 蒸馏模型和高性能 Embedding 向量模型：

docker compose up -d

# 拉取 14b 蒸馏模型（约 9GB 显存占用）docker exec -it ollama ollama run deepseek-r1:14b

# 必须拉取专业向量模型，不要用通用 LLM 做 Embedding
docker exec -it ollama ollama pull bge-m3

这里踩过一个大坑：很多新手直接拿 DeepSeek-R1 作为 Embedding 向量模型，不仅显存瞬间吃光，检索匹配度还一塌糊涂。语义向量务必选用专用的 bge-m3 或 nomic-embed-text。

知识库在切分海量 Markdown、源码或 PDF 时，会有大量密集的 4K/16K 向量数据频繁写入数据库。如果你的 NAS 底层文件系统是 ZFS 或 Btrfs，默认配置会导致严重的写入放大，让磁盘 I/O 瞬间飙高，连带拖慢 NAS 的 SMB 共享响应速度。

在 ZFS 下，强烈建议为向量数据库单独建立一个 Dataset，修改 recordsize：

# 创建专属于向量库的 dataset
zfs create nvme-pool/docker-ai
# Qdrant 内部索引读写以 16KB/32KB 页面为主，默认 128KB 会造成严重的写放大
zfs set recordsize=16k nvme-pool/docker-ai
zfs set compression=lz4 nvme-pool/docker-ai
zfs set atime=off nvme-pool/docker-ai

Ollama 默认分配给上下文窗口的大小通常只有 2048（2k tokens）。在喂给它长篇技术白皮书时，AnythingLLM 会自动触发上下文截断，导致模型胡言乱语。若在 UI 中强行将上下文拉到 16384 或 32768，显存会按几何级数暴涨。如果显存塞不下，部分层（Layers）会被踢到宿主机系统内存，Token 输出速度会瞬间从 25 tok/s 暴跌至 1.5 tok/s。

对于 12G 显存环境，平衡稳定性和速度的最佳配置如下：在 AnythingLLM 的 Workspaces -> Settings -> Vector Database 设置项中，将每个 Query 召回的文本片段（RAG Context Window）限制在 4~6 个片段，同时在 Ollama 的 Modelfile 中将 num_ctx 明确锁死在 8192：

# 导出自定义模型配置，创建 Modelfile
FROM deepseek-r1:14b
PARAMETER num_ctx 8192
PARAMETER temperature 0.6

使用 ollama create deepseek-r1:14b-nas -f ./Modelfile 重新打包运行，可在 11.2GB 显存占用内稳定吃下大多数技术文档的单次检索上下文。

小团队或家庭网络部署私有知识库，核心诉求是“数据资产闭环”与“低维护成本”。相比把数据毫无保留地推给公共 API，本地部署不仅完全没有数据外泄风险，而且只要硬件在线就能无限次并发调用。

在日常运维中，建议牢记以下两条铁律：

定期落盘与冷备：向量索引的重建极其消耗算力，务必利用 NAS 自带的快照机制（如 ZFS Snapshot 或 Rsync）每晚定期备份 qdrant_storage 和 AnythingLLM 的存储目录，切忌将索引与源文件混存。
温度与功耗监控：显卡一旦处于长时间推理（如批量处理上百份历史文档切片），整机功耗可能连续几小时飙升至 200W 以上。在紧凑型 NAS 机箱内，务必通过 crontab 定期轮询 nvidia-smi --query-gpu=temperature.gpu --format=csv,noheader，防止盘笼积热导致机械硬盘高温老化。

把原本吃灰的 NAS 加上一张消费级显卡改造成 AI 基础设施，不仅算力物尽其用，这套系统在处理内网各类杂乱的配置文档、运维日志检索时所表现出的准确性，会彻底颠覆你对“家用 NAS”能力的认知。

正文完