NAS玩转本地私有知识库：Docker轻量部署Ollama+Qdrant+Dify实战调优

6次阅读

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

前阵子我把团队两年的开发文档、接口设计规范和个人近十年的技术笔记全塞给了市面上的公有云知识库，结果不到一个月就遇到了两个恶心的问题：一是某些敏感的业务架构图和私钥配置触发了所谓的“安全脱敏过滤”，直接报空；二是团队几个人同时跑检索和代码辅助时，API Token 扣费像流水一样，偶发的公网网络抖动更是经常让 IDE 补全转圈转到超时。

索性直接把目光转回家里那台 24 小时开机的 8 盘位自建 Debian NAS（配置是 i5-13500 + 64G DDR4 + 2T NVMe 缓存盘 + 8T CMR 机械盘 RAID5，闲置着一张旧 RTX 3060 12G）。经过两周的踩坑与压测，我梳理出了一套基于 Dify + Ollama + Qdrant 的纯本地、高响应、零公网依赖私有知识库方案。今天把整套开箱即用的 Docker Compose 编排文件以及压测调优避坑细节全部整理出来。

在 NAS 这种资源受限（尤其是单节点混合部署）的场景下，组件选型必须极其克制：

LLM & Embedding 引擎（Ollama）： Ollama 对 CPU AVX2 指令集和核显 / 独显 Passthrough 的支持目前做得最丝滑，不仅支持动态加载 / 卸载模型，内存控制也比原生的 llama.cpp server 更省心。
应用编排层（Dify）： 相比于纯面向极客但定制极其繁琐的 FastGPT 或者臃肿的 LangChain 原生脚手架，Dify 的 Prompt 编排、文档分块预览和多模型路由是我用过最顺手的，UI 对团队协作极其友好。
向量数据库（Qdrant 替换默认的 PGVector）： 这是我踩坑后做出的最重要调整。Dify 默认推荐使用 PostgreSQL 扩展 pgvector。在万级切片规模下，PGVector 的 HNSW 索引构建会极其消耗 PostgreSQL 的 maintenance_work_mem，在机械硬盘为主的 NAS 上甚至频繁把数据库读写打挂，引发服务健康检查超时。改用纯 Rust 构建的 Qdrant 后，内存开销直接缩减了 40%，且原生支持磁盘存储向量 Payload、内存加载 HNSW 索引，查询 P99 延迟从 820ms 压到了 75ms。

很多新手部署 Dify 都是直接 git clone 官方仓库，然后一键 docker compose up，结果一口气起 9 个容器，吃掉 8G 内存，排查日志时直接眼花。这里我提取并精简出核心组件，拆分为本地推理层与 Dify 业务层。

创建运行目录并编写 docker-compose.yml：

version: '3.8'

networks:
  ai-net:
    driver: bridge

volumes:
  ollama_data:
  qdrant_data:
  dify_db_data:
  dify_storage_data:

services:
  # 1. 本地大模型引擎
  ollama:
    image: ollama/ollama:latest
    container_name: nas-ollama
    restart: unless-stopped
    ports:
      - "11434:11434"
    volumes:
      - /mnt/user/appdata/ollama:/root/.ollama
    environment:
      - OLLAMA_KEEP_ALIVE=24h
      - OLLAMA_NUM_PARALLEL=2
      # 如果有核显或无独显，注释下方的 deploy 块即可跑纯 CPU 模式
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    networks:
      - ai-net

  # 2. 向量数据库 (Qdrant 替代默认 pgvector)
  qdrant:
    image: qdrant/qdrant:v1.9.0
    container_name: nas-qdrant
    restart: unless-stopped
    ports:
      - "6333:6333"
    volumes:
      - /mnt/user/appdata/qdrant:/qdrant/storage
    environment:
      - QDRANT__SERVICE__GRPC_PORT=6334
    networks:
      - ai-net

  # 3. 业务数据库 (PostgreSQL 仅负责元数据，无须加载 pgvector 插件)
  db:
    image: postgres:15-alpine
    container_name: nas-dify-db
    restart: unless-stopped
    environment:
      - POSTGRES_DB=dify
      - POSTGRES_USER=dify
      - POSTGRES_PASSWORD=NAS_Secure_Passwd_2026
    volumes:
      - dify_db_data:/var/lib/postgresql/data
    networks:
      - ai-net

  # 4. 缓存层
  redis:
    image: redis:7-alpine
    container_name: nas-dify-redis
    restart: unless-stopped
    networks:
      - ai-net

  # 5. Dify API 后端
  api:
    image: langgenius/dify-api:latest
    container_name: nas-dify-api
    restart: unless-stopped
    depends_on:
      - db
      - redis
    environment:
      - MODE=api
      - DB_USERNAME=dify
      - DB_PASSWORD=NAS_Secure_Passwd_2026
      - DB_HOST=db
      - DB_PORT=5432
      - DB_DATABASE=dify
      - REDIS_HOST=redis
      - REDIS_PORT=6379
      - VECTOR_STORE=qdrant
      - QDRANT_URL=http://qdrant:6333
      - SECRET_KEY=generate_your_random_secret_key_here
      - STORAGE_TYPE=local
      - STORAGE_LOCAL_PATH=/app/api/storage
    volumes:
      - dify_storage_data:/app/api/storage
    networks:
      - ai-net

  # 6. Dify Web 前端
  web:
    image: langgenius/dify-web:latest
    container_name: nas-dify-web
    restart: unless-stopped
    ports:
      - "8088:3000"
    environment:
      - CONSOLE_API_URL=http://127.0.0.1:8088
      - APP_API_URL=http://127.0.0.1:8088
    networks:
      - ai-net

很多玩家把 32B 甚至 70B 模型硬塞进 NAS，结果就是：显存塞不下，CPU 爆满，每秒吐 1.2 个 Token，问一个技术问题要等两分钟，完全失去交互价值。我在 NAS 上实测了不下十个模型，最终敲定以下“黄金组合”：

千万别用通用 LLM 去做向量化，速度慢到吐血。直接在终端执行：

docker exec -it nas-ollama ollama pull bge-m3:latest

实测点评：bge-m3 支持多语言、8192 长度上下文，且完美支持多粒度检索（密集检索 Dense + 稀疏检索 Sparse 混合）。在 NAS 上占用显存仅 1.1GB 左右，切片向量化速度可达 150 段 / 秒，极其强悍。

# 首选：兼顾速度与代码 / 文档理解能力
docker exec -it nas-ollama ollama pull qwen2.5:7b-instruct-q4_K_M

# 如果 NAS 纯 CPU 运行（如 N100 等低功耗工控机）：docker exec -it nas-ollama ollama pull qwen2.5:3b-instruct-q4_K_M

实测在 12G 显存的 3060 上，qwen2.5:7b 配合 Q4 量化全入显存，吐字速度能达到 45 Token/s，首字响应时间（TTFT）在 300ms 左右，体验和云端 API 几乎无差别。

默认情况下，如果 Dify 发起向量化检索的同时你正在打字对话，Ollama 可能会尝试在显存中同时维护两个实例或频繁 Swap，直接触发显卡驱逐。解决方案是在 Compose 文件中固化环境变量：

# 保持模型长驻显存，避免频繁读写机械硬盘唤醒
OLLAMA_KEEP_ALIVE=24h
# 严格限制并发 slot，避免上下文堆叠挤爆显存
OLLAMA_NUM_PARALLEL=2

这是 NAS 用户最容易犯的错误：把 qdrant_data 映射到了机械硬盘阵列上（如 /mnt/user/data/qdrant）。知识库每次做 Top-K 向量相似度计算时，会触发高密度的随机 I/O，机械硬盘的磁头寻道会导致查询延迟飙升至秒级。请务必将 qdrant_data 和 dify_db_data 映射在 NVMe SSD 缓存盘上，机械盘仅用来存放归档的原始 PDF/Markdown 文件。

在 Dify 知识库后台上传技术文档时，很多人直接点“自动分段”，结果代码块被腰斩，检索结果一团糟。在配置【清洗与分段】时，建议手动调整：

分段标识符： 针对技术文档，建议设为 \n\n### 或 \n\n```，保证 Markdown 的代码块和三级标题结构完整。
分段最大长度： 建议设置为 800 Token，重叠长度（Overlap）设为 100 Token。
检索设置： 务必启用 混合检索（Hybrid Search），将语义检索与全文关键词匹配权重设为 0.7 : 0.3。纯向量检索对于具体的函数名（如 get_user_by_uuid）很容易产生误匹配，结合关键词检索才能刀刀见血。

知识库建好了，手动上传维护是最反人性的。我在 NAS 上写了一个极简的 Shell 监控脚本，利用 inotifywait 监控本地 Markdown 笔记目录。只要 Obsidian 同步了新笔记，自动触发 Dify 的 API 接口实现增量更新：

#!/usr/bin/env bash
# 监控 NAS 本地笔记目录，自动触发 Dify 知识库更新
WATCH_DIR="/mnt/user/documents/obsidian_vault"
DIFY_API_KEY="dataset-your-dify-api-token"
DATASET_ID="your-dataset-uuid"

inotifywait -m -r -e create,modify --format '%w%f' "$WATCH_DIR" | while read FILE
do
  if [["$FILE" =~ \.md$]]; then
    echo "[$(date)] 检测到文档变动: $FILE，正在推送到本地知识库..."
    curl -X POST "http://127.0.0.1:8088/v1/datasets/${DATASET_ID}/document/create_by_file" \
      -H "Authorization: Bearer ${DIFY_API_KEY}" \
      -F "file=@${FILE}" \
      -F 'data={"indexing_technique":"high_quality","process_rule":{"mode":"automatic"}}'
  fi
done

使用 nohup ./sync_knowledge.sh > /var/log/dify_sync.log 2&1 & 挂在后台，从此日常随手记录的工程 Bug、部署备忘录，就会在几秒钟内自动被切片、向量化并录入 NAS 大脑。

搭建私有本地知识库，从来不是参数越大越好。在个人和中小团队场景下，更稳的向量检索选型（Qdrant）+ 适配硬件的 7B/8B 精度量化 + 合理的混合召回权重，其可用度和准确率完全能暴打那些无脑堆 70B 却分段稀碎的公有云方案。现在无论我在家里、咖啡厅（通过 Tailscale/WireGuard 组网穿透），都能随时随地秒级检索我私有硬盘里的全部数据资产，最重要的是：数据完全属于自己，不用担心隐私泄露，更不用看任何云厂商的账单脸色。

===EOF===

正文完