NAS玩转本地私有大模型与知识库：vLLM加持Open-WebUI的高效容器化方案

2次阅读

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

很多极客在折腾家用全能塔式 NAS 或小型工作站时，最常干的一件事就是往 PCIe 插槽里塞进一张二手 RTX 3090 或者 4070Ti Super。原本设想很美好：既当媒体中心和容灾存储，又能挂着本地大模型（LLM）做个人知识库和内网 Agent 接口。但在实际落地时，大部分人第一反应是直接上一键部署的 Ollama。日常单人偶尔问一句还好，一旦接入自动化流式任务、挂载几百份 PDF 切片向量化，或者家里两三台机器并发提问，Ollama 的吞吐瓶颈就会瞬间暴露，显存释放与上下文调度也经常打架。

为了榨干手头这台运行 TrueNAS SCALE（基于 Debian）/ Ubuntu Server 宿主机的显卡算力，我把推理底座彻底切换到了高吞吐的 vLLM，结合 Qdrant 向量引擎与 Open-WebUI。实测在 10 个并发流式请求下，Qwen2.5-7B/14B 的响应延迟和吞吐量相比传统单进程模型服务提升了整整三倍。今天这篇干货，带你一步步避开容器网络穿透、CUDA 驱动挂载以及显存碎片化这些我亲自踩过的深坑。

在 NAS 有限的功耗和异构硬件环境下做本地 LLM，核心矛盾永远是： 有限的显存带宽、不稳定的并发调用，以及模型量化损失之间的权衡 。

组件选型	常见方案（新手走弯路）	硬核方案（生产 / 高吞吐推荐）	选型理由与痛点
推理后端	Ollama / llama.cpp 原生编译	vLLM (PagedAttention)	PagedAttention 极大降低 KV Cache 碎片率，真正支持高并发连续批处理（Continuous Batching）。
向量检索	ChromaDB (内嵌文件存储)	Qdrant (Rust 单容器)	Chroma 在大量文件切片重构时极易锁文件，Qdrant 内存占用低且对高并发 KNN 向量检索极其友好。
交互前端	Dify 完整大套件	Open-WebUI	NAS 内存宝贵，Dify 全家桶启动即占 6GB+ 内存，Open-WebUI 轻量、原生兼容 OpenAI API 且自带 RAG 引擎。

如果你的 NAS 是 TrueNAS SCALE（推荐升级到 Cobian 及以上版本）或者普通的 Debian/Ubuntu，第一步必须确认宿主机已经正确安装了 nvidia-driver 和 nvidia-container-toolkit，确保容器内部可以无缝调用 GPU。

# 1. 宿主机验证 GPU 状态
nvidia-smi

# 2. 测试 Docker 挂载 GPU 驱动是否正常
docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi

如果第二个命令能正常打印出显卡信息（卡型号、CUDA 版本和显存状态），说明 Docker 驱动层配置完毕。如果提示 docker: Error response from daemon: could not select device driver，别慌，运行以下命令刷新并重启 Docker 守护进程：

sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

在你的 NAS 存储池（推荐 SSD 高速缓存池，如 /mnt/pool_nvme/appdata/ai-stack）创建项目目录，并编写 docker-compose.yml。这里我们以国产开源表现优异的 Qwen2.5-7B-Instruct-AWQ 为例。采用 AWQ 4-bit 量化可以在仅仅保留约 6~7GB 显存占用的同时，保留 95% 以上的原始浮点精度，非常适合单张 12G/16G/24G 显存的消费级卡。

services:
  # 1. vLLM 核心推理引擎
  vllm:
    image: vllm/vllm-openai:v0.6.3
    container_name: vllm-engine
    runtime: nvidia
    restart: unless-stopped
    environment:
      - HUGGING_FACE_HUB_TOKEN=your_token_here # 如果需要拉受限模型
    volumes:
      - /mnt/pool_nvme/huggingface_cache:/root/.cache/huggingface
    ports:
      - "8000:8000"
    ipc: host
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    command: >
      --model Qwen/Qwen2.5-7B-Instruct-AWQ
      --quantization awq
      --dtype half
      --max-model-len 8192
      --gpu-memory-utilization 0.85
      --enforce-eager
      --trust-remote-code
      --port 8000

  # 2. Qdrant 向量数据库（用于知识库 RAG）qdrant:
    image: qdrant/qdrant:v1.11.3
    container_name: qdrant-db
    restart: unless-stopped
    volumes:
      - /mnt/pool_nvme/appdata/qdrant_storage:/qdrant/storage
    ports:
      - "6333:6333"

  # 3. Open-WebUI 交互与 RAG 知识库前端
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: unless-stopped
    ports:
      - "3000:8080"
    environment:
      - OPENAI_API_BASE_URL=http://vllm:8000/v1
      - OPENAI_API_KEY=EMPTY
      - VECTOR_DB=qdrant
      - QDRANT_URL=http://qdrant:6333
      # 开启内嵌轻量级向量模型（运行在 CPU 或 GPU 均可）- RAG_EMBEDDING_MODEL=BAAI/bge-m3
      - RAG_EMBEDDING_ENGINE=sentence-transformers
    volumes:
      - /mnt/pool_nvme/appdata/open-webui:/app/backend/data
    depends_on:
      - vllm
      - qdrant

--gpu-memory-utilization 0.85：这是关键避坑点。vLLM 启动时会预先按比例申请 KV Cache 显存。默认是 0.90，如果 NAS 后台恰好还有 Plex/Jellyfin 在做视频硬件转码，或者系统 UI 占了小几百兆显存，0.90 会直接导致 CUDA OOM。留出 15% 的弹性空间给系统和嵌入模型是最佳平衡点。
--enforce-eager：消费级显卡（非 H100/A100）开启后可以跳过冗长的 CUDA Graph 捕获编译阶段，启动时间从 5 分钟缩短到 30 秒，且排查显存泄漏更直观。
ipc: host：PyTorch 在多进程通信时高度依赖共享内存，如果不加，在并发稍高时经常报 bus error (core dumped) 崩溃。

我在测试双卡（比如 1 张 RTX 3090 跑推理，1 张 P4/P40 挂转码）时遇到了诡异的降速问题。排查后发现 NAS 主板的第二条 PCIe 插槽实际走的是 PCH 南桥（PCIe 3.0 x4），而不是直连 CPU 通道。

如果你在多卡环境下只希望把 vLLM 绑定到指定高性能卡，千万不要盲目写 count: all，应该使用环境变量精确限定设备号：

environment:
  - CUDA_VISIBLE_DEVICES=0 # 仅绑定主槽位 GPU 0

很多人刚开始玩 RAG 知识库，习惯在 Open-WebUI 里把 Embedding 模型也扔到同一张显卡上。实战测试发现：当正在进行大规模长文档切片入库时，显卡显存会被瞬间挤占，导致 vLLM 正在进行的流式对话直接被卡死（Pending）。

实战建议：NAS 的 CPU 通常有多个空闲核（如 Intel 12/13/14 代桌面 U 或 E5 系列），将 Embedding 模型完全卸载到 CPU 上跑。在 Open-WebUI 中指定：

# 将文本嵌入计算丢给多核 CPU，把宝贵的 GPU 显存全部留给 vLLM 的 KV Cache
DEVICE_TYPE=cpu

实测对于百篇以内的 Markdown 和 PDF 技术手册，CPU 跑 bge-m3 的检索召回延迟在 30~80ms 以内，体验完全不输 GPU，但彻底消除了显存抢占崩溃的隐患。

折腾 NAS 跑本地私有 AI，最忌讳的是把一大堆微服务套件盲目往上塞。vLLM 的高吞吐和并发能力远超开箱即用但性能受限的简易脚本，配合低开销的 Qdrant 与 Open-WebUI，能够让你在极低资源占用下，拥有一套真正具备可用性的私有大模型与 RAG 知识库节点。

如果你的数据存储在 ZFS 池上，模型权重文件存放的 Dataset 建议将 recordsize 设置为 1M，这样在每次重启容器加载十几 GB 的模型权重时，读取耗时能从数十秒缩短到几秒钟内。技术就是这样，底层一个微小的 IOPS 和显存分配细节，最终决定了你整个系统是卡顿不堪还是丝滑如风。

正文完