NAS玩转本地大模型与知识库：vLLM与Ollama混合部署与硬核调优实战

12次阅读

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

很多极客在折腾完 NAS 的基础服务（影音库、备份中心、内网穿透）后，往往面临硬件算力过剩或闲置的窘境。随着近两年轻量化开源大模型（如 Qwen2.5、Llama-3.1）在端侧和消费级显卡上的爆发，把 NAS 改造成局域网内的“私有大模型与知识库一体机”，成了最实用的进阶玩法。

但实际动手时，很多人第一步就卡壳了：要么全丢给 Ollama，结果遇到并发请求直接排队卡死；要么想上高吞吐的 vLLM，却发现 NAS 环境下的显存动态分配和容器直通到处是暗坑。上个月我给家里的万兆 NAS（i5-13500 + 单张 RTX 4060Ti 16G）重构了 AI 推理链路，跑通了 “vLLM 承载高频高吞吐 API + Ollama 轻量按需加载小模型 /Embedding + Dify 管理私有 RAG” 的高效架构。这套方案连续稳定跑了一个月，今天把完整的部署思路、Compose 配置和避坑细节全盘托出。

在消费级 NAS 单卡或双卡环境下，显存和系统内存永远是稀缺资源。市面上最主流的两大推理方案各有优劣：

Ollama：开箱即用，支持模型按需加载与自动卸载（OLLAMA_KEEP_ALIVE），但内部基于 llama.cpp，面对连续多用户并发请求时，吞吐上限受限，KV Cache 复用和 PagedAttention 能力不如专业推理框架。
vLLM：原生 PagedAttention，高并发、连续 Batching 极强，适合做固定的主力文本生成底座，但它会默认预扣大量 GPU 显存，哪怕空闲时也不轻易释放。

因此，最适合个人 / 小团队 NAS 的方案是 混合编排：

vLLM 作为常驻网关：载入主力量化模型（如 Qwen2.5-7B-Instruct-GPTQ-Int4 或 AWQ），严格限制其显存占用上限（如 70% 显存，约 11GB）。负责知识库检索后的主文本生成与日常对话。
Ollama 作为辅助算力池：负责运行 Embedding 模型（如bge-m3）或偶尔调用的冷门小模型，设置空闲 5 分钟自动卸载显存，避免与 vLLM 抢显存。

不管底层是 Debian 原生系统、Unraid 还是 TrueNAS SCALE，务必先保证 NVIDIA 驱动及 nvidia-container-toolkit 正常工作。很多新手在 Docker 运行时报错could not select device driver "" with capabilities: [[gpu]]，根源就在这里。

以标准的 Debian/Ubuntu 基础 NAS 系统为例，验证与配置命令如下：

# 1. 验证显卡驱动是否就绪
nvidia-smi

# 2. 安装 NVIDIA Container Toolkit（必须步骤）distribution=$(. /etc/os-release;echo $ID$VERSION_ID) \
      && 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/$distribution/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-get update
sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

接下来我们通过单份 docker-compose.yml 编排三个核心组件：vLLM（主推理引擎）、Ollama（辅助 / 向量模型）、以及提供 OpenAI 兼容接口的调度层。

version: '3.8'

services:
  # 主力高吞吐推理引擎
  vllm-server:
    image: vllm/vllm-openai:latest
    container_name: vllm-server
    restart: unless-stopped
    runtime: nvidia
    environment:
      - NVIDIA_VISIBLE_DEVICES=all
      - NCCL_P2P_DISABLE=1 # 消费级显卡（非 NVLink）必须禁用，避免初始化通讯死锁
    volumes:
      - /mnt/storage/ai/models:/root/.cache/huggingface
    ports:
      - "8000:8000"
    ipc: host # 避免显存交互时共享内存溢出崩溃
    command: >
      --model Qwen/Qwen2.5-7B-Instruct-AWQ
      --quantization awq
      --gpu-memory-utilization 0.68
      --max-model-len 8192
      --enforce-eager
      --host 0.0.0.0
      --port 8000
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

  # 向量化与辅助模型引擎
  ollama-helper:
    image: ollama/ollama:latest
    container_name: ollama-helper
    restart: unless-stopped
    environment:
      - NVIDIA_VISIBLE_DEVICES=all
      - OLLAMA_KEEP_ALIVE=5m # 空闲 5 分钟自动卸载显存，还给系统
      - OLLAMA_NUM_PARALLEL=2
    volumes:
      - /mnt/storage/ai/ollama:/root/.ollama
    ports:
      - "11434:11434"
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

1. `--gpu-memory-utilization` 的黄金切割点

我在部署初期直接设为 0.9，结果发现 vLLM 直接占满了 16G 显存中的 14.4G，导致后面的 Ollama 加载bge-m3 向量模型时直接 CUDA Out of Memory 退出崩溃。

实测解法：将 vLLM 的显存占用严格卡在0.68（约 10.8G）。剩下的 5.2G 显存中，留出 1.5G 给 Ollama 运行向量模型，剩余 3.5G 作为系统缓存与瞬时计算 Buffer。这样两个服务并行工作时，显存水位稳定在 90% 以下，彻底告别 OOM。

2. 消费级显卡必须开启 `--enforce-eager`

vLLM 默认会使用 CUDA Graphs 来优化计算图，但在 GTX/RTX 消费级显卡以及非标准 NUMA 架构的 NAS 主板上，首次捕获计算图极易造成显存瞬时暴增甚至服务挂起报错。加上 --enforce-eager 参数后，虽然极限微批处理性能损失了不到 5%，但启动耗时从 3 分钟缩短到 20 秒，且服务运行极其稳定。

容器启动后，进入 Ollama 拉取 Embedding 专用模型：

# 拉取多语言效果出色的向量模型
docker exec -it ollama-helper ollama pull bge-m3

# 验证 vLLM 是否正确暴露 OpenAI 接口
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"Qwen/Qwen2.5-7B-Instruct-AWQ","messages": [{"role":"user","content":"NAS 配置 vLLM 最关键的显存参数是哪个？"}],"temperature": 0.3
  }'

我使用自写的并发压测脚本，对这套 NAS 上的部署方案进行了连续 20 个并发的 Stream 输出测试：

模型：Qwen2.5-7B-Instruct-AWQ (4-bit)
硬件：i5-13500, 64GB DDR4 3200, RTX 4060Ti 16G (PCIe 4.0 x8 运行于 NAS 扩展槽)
吞吐表现：单用户 Token 输出速率稳定在 65~72 tokens/s；当模拟内网 5 人同时进行知识库问答时，总吞吐量依然能稳定在 140+ tokens/s，首字延迟（TTFT）控制在 280ms 以内。

相比于纯 Ollama 单实例跑 7B 模型，在高并发下响应速度提升了接近 3 倍，更重要的是，显存资源被彻底盘活了。

把 NAS 打造成私有大模型与知识库中心，并不是盲目堆砌显卡，而是要学会在受限资源下做 精细化显存切片。不要迷信“全量跑大模型”，在当前技术阶段，7B/8B 的量化模型搭配高效的 RAG（知识库检索增强），已经能解决个人技术文档管理、代码片段索引与智能家居中控 95% 以上的需求。

如果你手头也有带 PCIe 槽位的 NAS 主机，不妨翻出一张二手的 12G 或 16G 显存 N 卡，按照上面的编排跑起来。私有数据不出内网、毫秒级响应的大模型体验，绝对能让你的 NAS 生产力再上一个台阶。

正文完