这篇文章记录我在 macOS 下使用 Ollama 安装 通义千问 QwQ-32B 推理模型/ DeepSeekR1-llama-70b 和下游三个软件 Open-webui/AnythingLLM/Dify 的过程，以备后续查阅。

我的 Mac studio 是 96G 的 M2 Max，macOS 15.2。日常使用我感觉 QwQ已经很不错了。

先给这篇文章的几个工具做简单的介绍：

• ollama，一个简单易用的大语言模型的部署工具。

  同类还有vLLM，吞吐量和扩展性更好，但生态较弱，部署相对复杂。

• open-webui，一个web前端工具，用于对接ollama启动的大语言模型。

  同类的还有 chatbox等客户端。

专业术语：

• RAG

  检索增强生成（RAG）是一种将外部知识检索与大语言模型（LLM）相结合的技术。传统的大语言模型虽然拥有丰富的知识，但知识更新可能不及时，或者在特定领域的知识储备不足。RAG 通过在生成回答之前，先从外部知识源（如文档数据库、网页等）中检索相关信息，然后将这些信息与用户的问题一起输入到大语言模型中，从而生成更准确、更具时效性的回答。

接下来是本地知识库搭建开源方案：

1. AnythingLLM：开源企业级文档聊天机器人，支持本地部署和多用户权限管理，通过工作区隔离文档，确保数据隐私。适合注重隐私与定制化的企业级RAG应用。
2. Dify：开源LLM应用开发平台，集成数百种模型，支持可视化工作流编排和高质量RAG引擎，覆盖对话与自动化场景。开发者友好，适合构建多样化AI应用。
3. RAGFlow：端到端RAG引擎，以深度文档解析见长，支持表格、图片等复杂格式处理，提供可追溯的答案引用以降低幻觉。文档处理能力突出，适合高精度知识检索场景。
4. MaxKB：开箱即用的知识库问答系统，支持多模型接入（如Llama、GPT），可零代码嵌入第三方业务系统。适用于企业构建私有知识库，部署便捷。
5. FastGPT：专注知识库问答，提供Flow可视化流程设计，结合混合检索与重排序优化回答质量。灵活应对复杂问答，适合技术团队深度定制。

也问了deepseek他们的区别，这是回答：

ollama

Ollama 是简单易用的LLM部署工具。正常安装即可：

ollama run deepseek-r1:70b
ollama run qwq

可以直接运行然后对话：

单请求qwq下占用显存大概20G，功率100W（平时待机8W）。

如果使用其他的UI客户端，则不需要run，只要把 ollama 应用打开就好了。

ollama可以简化我们使用大模型的安装问题。当然既然简化了，就说明它在生产环境上使用不如其他的工具强大。以下是一些其他替代工具，我有空也会研究下：

• LMDeploy，能够针对内存管理、并发处理和负载均衡等多个方面进行细致的优化。
• vLLM，vLLM通过 PagedAttention 高效地管理attention中缓存的张量，实现了比HuggingFace Transformers高14-24倍的吞吐量。

open-webui

可以使用 open-webui 进行简单的问答。

参考官方文档运行pip安装的open-webui。由于我用miniconda管理python环境，所以需要先激活环境。如果你没有使用，则不需要关注第一行：

conda active pandas
open-webui serve

输入账号密码登录即可。左上角可以选择本机上的模型。

同类的我还使用 chatbox 和 浏览器的插件Page Assist

• Page Assist

  利用本地运行的AI模型，在浏览网页时进行交互.

  

• chatbox

  Chatbox AI 是一款 AI 客户端应用和智能助手，支持众多先进的 AI 模型和 API，可在 Windows、MacOS、Android、iOS、Linux 和网页版上使用。

  

  

• Cherry Studio

  轻量级的桌面端工具，集成多种开源模型，支持离线问答，适合个人用户快速验证创意。

  

  

anythingllm

开源企业级文档聊天机器人，支持本地部署和多用户权限管理，通过工作区隔离文档，确保数据隐私。适合注重隐私与定制化的企业级RAG应用。

只是粗浅使用，我感觉效果不好，可能还要调整配置吧。先浅尝则止，到此为止了。官方文档。

上传文档：

几乎把我gpu和内存吃满了：

工作区中共享文档：

seve后pin一下：

就可以在当前工作区共享文档的内容了。

Dify

Dify 是一个开源的大语言模型（LLM）应用开发平台，融合了后端即服务（Backend as Service, BaaS）和 LLMOps 理念，旨在简化和加速生成式AI应用的创建和部署。它支持多种大型语言模型（如OpenAI的GPT系列、Claude3等），并提供强大的数据集管理功能、可视化的 Prompt 编排以及应用运营工具。

安装包括原生安装和容器安装两种方式。推荐使用容器安装，因为原生的组件太多辣：

• 数据库：PostgreSQL 或 MySQL。
• 缓存：Redis。
• 向量数据库：Weaviate。
• 代理服务：Nginx 或 Squid。
• Dify 源码运行：需配置 Python 环境、依赖库及前后端构建。

1. 安装

wget https://github.com/langgenius/dify/archive/refs/tags/1.0.0.zip
unzip 1.0.0.zip
cd dify-1.0.0/docker
cp .env.example .env  # 修改端口等参数（可选）

国内拉不到docker.io，需要修改容器源的地址，拷贝内容到下图位置，重启docker：

"registry-mirrors":[
    "https://9cpn8tt6.mirror.aliyuncs.com",
    "https://registry.docker-cn.com",
    "https://mirror.ccs.tencentyun.com",
    "https://docker.1panel.live",
    "https://2a6bf1988cb6428c877f723ec7530dbc.mirror.swr.myhuaweicloud.com",
    "https://docker.m.daocloud.io",
    "https://hub-mirror.c.163.com",
    "https://mirror.baidubce.com",
    "https://your_preferred_mirror",
    "https://dockerhub.icu",
    "https://docker.registry.cyou",
    "https://docker-cf.registry.cyou",
    "https://dockercf.jsdelivr.fyi",
    "https://docker.jsdelivr.fyi",
    "https://dockertest.jsdelivr.fyi",
    "https://mirror.aliyuncs.com",
    "https://dockerproxy.com",
    "https://mirror.baidubce.com",
    "https://docker.m.daocloud.io",
    "https://docker.nju.edu.cn",
    "https://docker.mirrors.sjtug.sjtu.edu.cn",
    "https://docker.mirrors.ustc.edu.cn",
    "https://mirror.iscas.ac.cn",
    "https://docker.rainbond.cc"
    ]

执行启动命令：

docker-compose up -d

最终结果：

有一个比较奇怪的地方，我本机已经跑了nginx了。

brew services start nginx

也占用的80端口和443端口。但是挺奇怪，它和Dify的80/443竟然不冲突？！发现原来是因为docker监听的是ipv6地址，而我默认的nginx监听的是ipv4的地址：

lsof -i :80 -n -P

访问：http://localhost

设置完成后就进入Dify了，右上角设置ollama内容：

配置Ollama信息：

2. 增加一个nomic-embed-text模型

nomic-embed-text，这是一个文本向量化的模型，做向量化检索时使用。

ollama pull nomic-embed-text

此时有两个模型了：

3. 创建知识库

1. 选择数据源：

   

2. 数据分段与清洗

   

3. 处理

   等待完成即可。

   

   处理的时候占用的CPU/GPU/内存大概如下：

   

   

   

4. 完成

   

4. 创建聊天助手

选择知识库，开始提问。明显感觉比anythingLLM靠谱。

5. 工作流

GitHub上有一些有趣的工作流，可以看看：Awesome-Dify-Workflow

比如：《完蛋！我被LLM包围了！》

RagFLow

wget https://github.com/infiniflow/ragflow/archive/refs/tags/v0.17.0.zip
unzip v0.17.0.zip
cd ragflow-0.17.0/docker
cp docker-compose-macos.yml docker-compose.yml

改一下docker-compose.yml 的 80和443端口，然后修改.env，将macOS的注释去了。

vi .env

增加一个环境变量：

 export HF_ENDPOINT=https://hf-mirror.com

运行：

docker-compose up -d

参考文章：https://zhuanlan.zhihu.com/p/701768574

因为项目下载比较大，要50G空间。因为Mac这里寸土寸金，就先不跑了。

参考资料

• 深化知识管理：Ollama & AnythingLLM 打造专属全新的本地知识库管理系统
• DeepSeek企业级部署实战指南：从服务器选型到Dify私有化落地
• RAG+AI工作流+Agent：LLM框架该如何选择，全面对比MaxKB、Dify、FastGPT、RagFlow、Anything-LLM,以及更多推荐

在折腾 Docker ，发现 docker-compose 默认是 Docker Desktop 自带的版本，路径是：

/usr/local/bin/docker-compose -> /Applications/Docker.app/Contents/Resources/bin/docker-compose

但我更希望使用 Homebrew 安装的最新的版本，比如：

/opt/homebrew/Cellar/docker-compose/2.33.1/bin/docker-compose

为了让 docker-compose 指向 Homebrew 版本：

1. 移除 Docker Desktop 自带的 docker-compose

sudo rm /usr/local/bin/docker-compose

2. 软链接到 Homebrew 版本

sudo ln -s /opt/homebrew/bin/docker-compose /usr/local/bin/docker-compose

3. 验证

which docker-compose

输出：

/usr/local/bin/docker-compose

再确认版本号：

docker-compose version

最近心血来潮把wireguard的监控搬到 prometheus 上来，在 Grafana 中动态展示 WireGuard 网络的健康状态，如果某条断联了，由prometheus进行告警，于是便有了这篇文章。

1. WireGuard Exporter 安装

参考：MindFlavor/prometheus_wireguard_exporter，为每一个节点安装exporter：

version: '2.4'

services:
  wgexporter:
    image: mindflavor/prometheus-wireguard-exporter
    network_mode: host
    container_name: wg-exporter
    cap_add:
      - NET_ADMIN
    privileged: true
    command: ["--prepend_sudo", "true"]
    environment:
      - PROMETHEUS_WIREGUARD_EXPORTER_VERBOSE_ENABLED=true
      - PROMETHEUS_WIREGUARD_EXPORTER_PORT=12386
    restart: always

相关的配置参考github即可。我是用了两个配置：

• PROMETHEUS_WIREGUARD_EXPORTER_VERBOSE_ENABLED，详细模式
• PROMETHEUS_WIREGUARD_EXPORTER_PORT，自定义端口

2. Prometheus 采集 WireGuard 状态

在 Prometheus 的配置文件 prometheus.yml 中添加 scrape_configs 来收集 WireGuard 的指标：

scrape_configs:
  - job_name: 'wireguard_exporter'
    static_configs:
      - targets:
          - 'wg-exporter.nanjing1.local:12386'
          - 'wg-exporter.chengdu2.local:12386'
    relabel_configs:
      - source_labels: [__address__]
        regex: 'wg-exporter\.([^.]+)\..*'
        target_label: src_peer
    metric_relabel_configs:
       - source_labels: [allowed_ips]
         regex: .*100\.100\.100\.100/32.*
         action: replace
         target_label: target_peer
         replacement: OnePlus

此配置帮助我从每个节点的 instance 中提取出 nanjing1 或 chengdu2 作为新的 src_peer 标签，从结果中将 100.100.100.100 的节点标记为OnePlus节点，增加可读性。

这里涉及到了 relabel_configs 和 metric_relabel_configs 两个配置项，能够帮助我们灵活地重命名、修改、删除或过滤标签以及指标。常用于数据抓取（scrape_configs）和指标数据的处理（metric_relabel_configs）

• relabel_configs：当我们要修改或过滤抓取目标时使用。例如，改变目标实例的名称，或选择性地抓取某些目标。
  • source_labels：一个标签列表，Prometheus 会从这些标签中提取信息进行后续处理。它的内容可以是任何来自目标的标签。
  • target_label：表示你希望修改或创建的目标标签的名称。如果你想修改现有的标签值，指定该标签的名称即可。如果你想添加新的标签，则可以指定新的标签名称。
  • regex：一个正则表达式，用来匹配标签的值。如果正则表达式匹配成功，就可以根据 replacement 替换值或执行其他操作。
  • replacement：如果 regex 匹配成功，可以用 replacement 字符串替换标签值。如果 replacement 为一个空字符串，则会删除匹配的标签
• metric_relabel_configs：已经抓取了指标数据，但想对这些数据进行修改或过滤时使用。例如，修改指标标签的值，重命名指标，或删除一些不需要的指标。
  • source_labels：一个标签列表，类似于 relabel_configs，它指定要修改的标签。
  • target_label：希望修改或添加的指标标签的名称。
  • regex：用于匹配标签值的正则表达式。
  • replacement：当 regex 匹配成功时，用来替换标签值或创建新的标签。
  • action：定义如何处理匹配的指标，可以是：
    • replace：替换标签值。
    • keep：保留该指标数据。
    • drop：丢弃该指标数据。

3. Grafana 可视化

1. 可视化握手时间

   (time() - wireguard_latest_handshake_seconds{src_peer!="",target_peer!=""})
   

2. 可视化连接速率

   irate(wireguard_sent_bytes_total{node=~"a1|b1",target_peer=~"a2|b2"}[$interval])
   

我上一篇文章《neovim 安装使用备忘》已经有点老了，这会儿 NvChad 已经更新到2.5了。按照之前的办法已经无法安装了。

1. 编写 Dockerfile

FROM alpine:latest

# 设置工作目录
WORKDIR /root

# 安装必要的软件包：git、nodejs、neovim 等
RUN apk add --no-cache git nodejs neovim ripgrep build-base wget && \
    git clone https://github.com/NvChad/starter ~/.config/nvim && \
    nvim --headless +PlugInstall +qall

CMD ["nvim"]

• 自动安装插件：使用 nvim –headless +PlugInstall +qall 来在容器构建过程中自动安装 Neovim 插件。–headless 使得 Neovim 在没有 GUI 的情况下运行，而 +PlugInstall +qall 则是自动安装插件并退出 Neovim。

2. 构建镜像

docker build -t nvchad:v20241223 .

构建完成后，Docker 会生成一个镜像，可以用于后续的容器启动。

3. 使用 docker-compose

version: '3.2'

services:
  nvChad:
    image: nvchad:v20241223
    network_mode: bridge
    container_name: nvchad
    volumes:
      - /root/Workspace:/root/Workspace
    command: nvim +NvimTreeToggle
    working_dir: /root/Workspace
    tty: true
    stdin_open: true

• command: nvim +NvimTreeToggle：每次容器启动时，nvim 会自动执行 :NvimTreeToggle，打开 NvimTree 文件树视图。

4. 通过 docker exec 进入容器时自动打开 Neovim

docker exec -it nvchad nvim +NvimTreeToggle

nvim +NvimTreeToggle：容器启动时，nvim 会自动执行 :NvimTreeToggle，打开 NvimTree 文件树视图。

5. 后续

push 镜像到docker.io了：

docker tag nvchad:v20241223 kelvinblood/nvchad:v20241223
docker push kelvinblood/nvchad:v20241223

6. 快速打开容器

基于步骤4，我写了一个 alias，方便在目录下快速进入容器中，它需要预设该容器的名字为 文件夹名+nvchad：

dneo() {
  # 如果没有参数，获取当前文件夹名并追加 "-nvchad"
  if [ -z "$1" ]; then
    local folder_name=$(basename "$PWD")
    local container_name="${folder_name}-nvchad"
    docker exec -it "$container_name" nvim +NvimTreeToggle
  else
    docker exec -it "$1" nvim +NvimTreeToggle
  fi
}

例如我在文件夹 workspace下，此时有一个 workspace-nvchad 的容器，输入 dneo 命令即可快速进入。

7. 同步更新组件+修改落盘

参考资料

• https://nvchad.com/docs/quickstart/install/

我的 Vim 编辑器用了很多的配置，粘贴代码时，默认的自动换行或自动缩进功能会导致内容显示异常。以下是解决方法。

启用粘贴模式

粘贴模式会临时禁用缩进与换行规则，仅适用于当前会话。

:set paste

关闭 Vim 后，新的会话会自动恢复为非粘贴模式，无需手动设置，也可以手动关闭粘贴模式：

:set nopaste

其他：禁用自动换行

这部分内容是扩展的知识，记录一下。

默认情况下，Vim 可能会开启自动换行（wrap）。可以通过以下命令禁用：

:set nowrap
:set textwidth=0
:set wrapmargin=0
:set formatoptions-=t

快捷键配置

为了更高效地切换，可以在 ~/.vimrc 中为 paste 和 nopaste 设置快捷键：

nnoremap <F2> :set paste<CR>
nnoremap <F3> :set nopaste<CR>

这样，按 F2 可以进入粘贴模式，按 F3 退出粘贴模式，方便快捷。