自建NAS全天候AI私有知识库：Docker部署Ollama+Qdrant+Dify实战与内存调优避坑

4次阅读

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

如果你的 x86 NAS 机器全天候 24 小时开机，却仅仅用来跑几个 SMB 共享、微力同步外加 Transmission 刷流，那这颗 CPU 和多余的 PCIe 扩展槽显然处于算力荒废状态。上个月我给自建 NAS 塞进了一张捡垃圾淘来的半高单槽卡（Tesla P4 / 8G 显存），目标很明确：打造成一台完全断网可用的私有化本地知识库集群。所有技术文档、财务凭证和私密数据绝对不能上公有云，响应延迟还要压到可交互级别。

在 NAS 这类追求低功耗、高稳定性的环境下搭建 RAG（检索增强生成）系统，服务选型必须遵循轻量化与极低内存损耗原则：

底层系统 ：Ubuntu Server 22.04 LTS / TrueNAS SCALE（不建议使用黑群晖，其内核与 Nvidia 驱动集成极其别扭）。
推理后端 ：Ollama（利用其量化加载能力与简洁的 RESTful API）。
向量数据库 ：Qdrant（Rust 编写，对比 Java 编写的 Milvus 或 Elasticsearch，它在 NAS 这种资源敏感型环境下内存开销极低）。
应用编排引擎 ：Dify（社区版开箱即用，支持多知识库切片、混合检索与重排序）。

开工前的硬性检查：确保宿主机已安装无头显卡驱动与 NVIDIA Container Toolkit。执行以下命令，必须能正常打印 GPU 状态卡：

# 检查宿主机 GPU 状态
nvidia-smi

# 验证 Docker 是否能够捕获 GPU 运行时
docker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi

许多初学者直接把各个组件的原生 Compose 文件简单拼凑，导致网络串扰和存储卷挂载混乱。在 NAS 上运行这些服务，关键在于对持久化路径进行细致规约，并对可能发生显存 / 内存泄漏的服务施加硬限制。

这是我经过数轮压测后稳定使用的 docker-compose.yml 生产级配置：

version: '3.8'

networks:
  ai-net:
    driver: bridge

volumes:
  ollama_data:
    driver: local
  qdrant_data:
    driver: local

services:
  # 推理引擎：Ollama
  ollama:
    image: ollama/ollama:latest
    container_name: nas-ollama
    restart: unless-stopped
    ports:
      - "11434:11434"
    volumes:
      - /mnt/storage/ai/ollama:/root/.ollama
    environment:
      - OLLAMA_KEEP_ALIVE=24h        # 避免模型频繁从慢速 HDD 进出内存
      - OLLAMA_NUM_PARALLEL=2        # 根据并发需求设置，降低显存碎片
      - OLLAMA_FLASH_ATTENTION=1     # 启用 Flash Attention 降低长上下文显存占用
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    networks:
      - ai-net

  # 向量数据库：Qdrant
  qdrant:
    image: qdrant/qdrant:v1.8.4
    container_name: nas-qdrant
    restart: unless-stopped
    ports:
      - "6333:6333"
    volumes:
      - /mnt/storage/ai/qdrant:/qdrant/storage
    environment:
      - QDRANT__SERVICE__GRPC_PORT=6334
    ulimits:
      nofile:
        soft: 65535
        hard: 65535
    networks:
      - ai-net

  # 编排平台：Dify Core 与 Worker (此处列出核心服务依赖)
  dify-api:
    image: langgenius/dify-api:0.6.9
    container_name: nas-dify-api
    restart: unless-stopped
    environment:
      - MODE=api
      - DB_USERNAME=postgres
      - DB_PASSWORD=your_secure_password
      - DB_HOST=dify-db
      - DB_DATABASE=dify
      - REDIS_HOST=dify-redis
      - VECTOR_STORE=qdrant
      - QDRANT_URL=http://nas-qdrant:6333
    volumes:
      - /mnt/storage/ai/dify/storage:/app/api/storage
    depends_on:
      - qdrant
    networks:
      - ai-net

在仅有 8GB 显存或核显共享内存的机器上跑推理，无脑上大模型必然遭遇 CUDA OOM 崩溃。我在 NAS 环境实测了以下不同模型组合下的推理吞吐表现（Token/s）：

模型名称	量化级别	静态显存占用	推理吞吐 (Context 2k)	适用场景
DeepSeek-R1-Distill-Qwen-1.5B	Q8_0	~1.9 GB	48 tokens/s	实时语义解析与路由
DeepSeek-R1-Distill-Qwen-7B	Q4_K_M	~4.7 GB	19 tokens/s	长文本复杂推理与总结
bge-m3 (Embedding)	FP16	~1.2 GB	高并发秒级响应	中文多语言向量化

推荐组合：使用 bge-m3 负责切片向量化，生成模型采用 deepseek-r1:7b。两者同时常驻，显存消耗约 5.9 GB，为 CUDA 上下文保留了 2GB 的动态回旋空间。

拉取并测试模型响应：

# 拉取 Embedding 模型
docker exec -it nas-ollama ollama pull bge-m3

# 拉取 7B 蒸馏版大模型
docker exec -it nas-ollama ollama pull deepseek-r1:7b

# 测试流式生成速度
time docker exec -it nas-ollama ollama run deepseek-r1:7b "请解释什么是 ZFS 写放大？"

我在测试初期犯了一个严重错误：把 Qdrant 向量数据库目录直接挂载到了由机械硬盘组建的 ZFS RaidZ2 存储池中。RAG 每次检索都会触发密集的随机只读小 IOPS，导致整个阵列机械臂寻道疯狂作响，响应延迟飙升至 3 秒以上。

解决方案 ：针对 AI 知识库的数据读写特性，在宿主机规划存储层级：

NVMe SSD 池 ：专门存放 qdrant/storage、ollama/models 和 Dify 的 SQLite/Postgres。必须关闭 ZFS 的 atime（zfs set atime=off pool/nvme），避免每次向量比对都触发文件元数据写入。
机械硬盘池 ：只用于知识库原始非结构化文件（PDF、Markdown、DOCX）冷备份，通过 Dify 的持久化卷挂载。

当并发请求拉大上下文时，Ollama 可能会尝试分配超出物理限制的内存。默认情况下，Linux 可能会将开销巨大的 Dify 服务或向量库直接 Kill 掉。建议调整 systemd 或者是 Docker 容器的 OOM 优先级评分：

# 降低 Qdrant 成为 OOM 受害者的概率（确保向量库不丢失内存状态）pgrep -f qdrant | while read pid; do
    echo -500 > /proc/$pid/oom_score_adj
done

在 Dify 知识库中导入 Markdown 技术文档时，千万别使用默认的通用分段。默认 500 Token 的段落常常将配置块或代码段“拦腰截断”，严重干扰大模型的代码理解能力。

推荐分段策略 ：在 Dify 的“自定义切片”中，将分段标识符设置为 \n\n# 或 \n\n## ，最大段落长度调至 800 Token，并配置 10% 的段落重叠度（Overlap），同时在 Qdrant 端启用“混合检索”（Hybrid Search：向量余弦距离 + 全文 BM25 检索），这能让技术文档中关键配置参数的检索召回率提升 40% 以上。

将 NAS 转化为私有 AI 算力中心，关键不在于盲目追求 70B 等超大模型，而是在受限的硬件算力、功耗与散热预算中，找到模型量化等级与并发检索能力的精确平衡点。通过将 Qdrant 钉死在高速 NVMe 盘、合理配置 Ollama 内存保活时间（OLLAMA_KEEP_ALIVE），配合 Dify 的流式 RAG 编排，整套系统在仅增加不到 30W 空载功耗的前提下，实现了毫秒级本地文档检索与准确归纳，真正完成了私有数据的本地资产化闭环。

正文完