背景与目标

在无 GPU、仅依赖 CPU 的环境中运行本地大模型,核心目标并不是追求参数规模,而是可长期运行、响应稳定、不干扰其他服务。本文记录了一套经过验证的实践方案:使用 Ollama 作为推理引擎,配合 Open WebUI 提供交互界面,并围绕模型体量、内存常驻、容器健康状态等关键点进行取舍与优化。

运行环境与约束条件

  • CPU-only 环境(无 GPU 加速)
  • 需要与其他服务长期共存
  • 容器化部署(Docker / Docker Compose)

在该条件下,7B 级模型可以加载,但并不适合作为日常默认模型,会带来明显的加载延迟与系统压力。

模型选择策略(按体量与用途分层)

推荐的本地模型梯度

体量模型示例主要用途评价
~1.5BQwen2.5 1.5B兜底、系统繁忙时极轻量,可长期常驻
~2BPhi-3 Mini默认工程模型推理快、代码/脚本稳定
~3BQwen2.5 3B中文/日语表达语言自然度更好
~7BQwen2.5 7B实验/对比不建议常驻

结论:在 CPU-only 环境中,3B 以内是“甜点区间”,7B 更适合作为偶尔实验而非常驻。

部署架构概览

  • Ollama:负责模型管理与推理
  • Open WebUI:Web 交互界面
  • Docker volume:用于模型与 WebUI 数据的持久化

模型文件统一存放在持久化卷中,支持多模型并存,下载一次即可长期复用。

Docker Compose 配置(关键点)

在保持原有结构与注释的前提下,仅增加了模型内存常驻策略

  • 通过环境变量控制模型在最后一次使用后保留在内存中的时间
  • 以 30 分钟为例,兼顾响应速度与内存回收
services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped

    # 模型常驻内存(最后一次使用后保留 30 分钟)
    environment:
      - OLLAMA_KEEP_ALIVE=30m

    # 模型与配置持久化(复用原卷,模型不会丢)
    volumes:
      - ollama:/root/.ollama

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: unless-stopped

    environment:
      - OLLAMA_BASE_URL=http://ollama:11434

    # WebUI 对外端口映射
    ports:
      - "<HOST_PORT>:8080"

    volumes:
      - open-webui:/app/backend/data

    depends_on:
      - ollama

volumes:
  ollama:
  open-webui:

说明:KEEP_ALIVE 为全局策略,只有“被使用过的模型”才会加载并进入计时,不会一次性占用所有模型的内存。

模型下载与管理

通过在运行中的容器内执行命令即可下载模型,例如:

  • 轻量兜底模型
  • 默认工程模型
  • 语言表达模型

模型下载完成后:

  • 自动进入持久化卷
  • 无需重启服务
  • WebUI 刷新即可识别

容器状态与健康检查的解读

常见现象

  • ollama:通常直接进入 Up 状态
  • open-webui:启动初期可能显示 health: starting 或短暂 unhealthy

这通常与以下因素有关:

  • 首次启动时的数据库初始化(SQLite + Alembic)
  • 后端尚未完全就绪即触发 healthcheck
  • 在低性能 CPU 环境下,初始化耗时更明显

只要页面可访问、模型列表可见、能正常对话,health 状态并非致命问题。

连通性验证方法(容器内)

判断 WebUI 是否真正连上推理引擎,可在 WebUI 容器内直接请求接口:

  • 若能返回模型列表 JSON,说明容器网络与配置正确
  • 此方法比单纯看 health 状态更可靠

内存常驻策略的实际效果

  • 第一次使用模型:需要加载(慢)
  • 保留期内再次使用:响应明显加快
  • 超过保留期:模型自动卸载,释放内存

在资源受限的环境中,这是一种用时间换内存、且可控的策略

实践总结

  • 不要盲目追求大模型:在无 GPU 的环境中,3B 往往比 7B 更“好用”
  • 模型分层比单一模型更重要:按用途切换,而非硬撑一个模型
  • health 状态需结合实际功能判断:页面与接口可用性优先
  • Keep Alive 是关键优化点:显著改善日常交互体验

适用场景

  • 家用/个人服务器
  • 多服务并行运行的宿主机
  • 希望完全本地化、可控的 AI 辅助环境

在这些前提下,这套组合可以在有限硬件条件下,提供一个稳定、克制、可长期运行的本地大模型解决方案。

Leave a Reply

Your email address will not be published. Required fields are marked *