Cherry Studio，很好用的一个大模型的本地客户端。安装的没有什么特别需要提的，这里就记录平时使用的一些点，文章也会持续更新。有啥新的好玩的就补一下到这里。
点击管理按钮，选择嵌入模型，可以把这几个都添加进去。
确认后可以看到我们之前添加嵌入式模型了。
拷贝拿到model id：
连接测试：
这篇文章记录我在 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 通过在生成回答之前，先从外部知识源（如文档数据库、网页等）中检索相关信息，然后将这些信息与用户的问题一起输入到大语言模型中，从而生成更准确、更具时效性的回答。
接下来是本地知识库搭建开源方案：
核心差异点：
| 维度 | AnythingLLM | Dify | RAGFlow |
|---|---|---|---|
| 数据隐私 | 完全本地化，无数据外传 | 支持本地部署，但依赖部分云服务 | 本地部署为主，强调数据控制 |
| 开发门槛 | 低（开箱即用） | 中（需配置工作流与模型） | 高（需调整文档解析参数） |
| 文档处理能力 | 基础格式（PDF/TXT/DOCX） | 常规格式（PDF/PPT） | 复杂格式（影印件、表格、音频） |
| 定制化能力 | 有限（依赖预置模板） | 高（支持自定义工具与流程） | 中（需调整检索策略与切片规则） |
| 适用规模 | 中小型知识库 | 中大型企业应用 | 企业级复杂文档处理 |
也问了deepseek他们的区别，这是回答：
Ollama 是简单易用的LLM部署工具。正常安装即可：
ollama run deepseek-r1:70b
ollama run qwq
可以直接运行然后对话：
单请求qwq下占用显存大概20G，功率100W（平时待机8W）。
如果使用其他的UI客户端，则不需要run，只要把 ollama 应用打开就好了。
ollama可以简化我们使用大模型的安装问题。当然既然简化了，就说明它在生产环境上使用不如其他的工具强大。以下是一些其他替代工具，我有空也会研究下：
可以使用 open-webui 进行简单的问答。
参考官方文档运行pip安装的open-webui。由于我用miniconda管理python环境，所以需要先激活环境。如果你没有使用，则不需要关注第一行：
conda active pandas
open-webui serve
输入账号密码登录即可。左上角可以选择本机上的模型。
同类的我还使用 chatbox 和 浏览器的插件Page Assist
利用本地运行的AI模型，在浏览网页时进行交互.
Chatbox AI 是一款 AI 客户端应用和智能助手，支持众多先进的 AI 模型和 API，可在 Windows、MacOS、Android、iOS、Linux 和网页版上使用。
轻量级的桌面端工具，集成多种开源模型，支持离线问答，适合个人用户快速验证创意。
开源企业级文档聊天机器人，支持本地部署和多用户权限管理，通过工作区隔离文档，确保数据隐私。适合注重隐私与定制化的企业级RAG应用。
只是粗浅使用，我感觉效果不好，可能还要调整配置吧。先浅尝则止，到此为止了。官方文档。
上传文档：
几乎把我gpu和内存吃满了：
工作区中共享文档：
seve后pin一下：
就可以在当前工作区共享文档的内容了。
Dify 是一个开源的大语言模型（LLM）应用开发平台，融合了后端即服务（Backend as Service, BaaS）和 LLMOps 理念，旨在简化和加速生成式AI应用的创建和部署。它支持多种大型语言模型（如OpenAI的GPT系列、Claude3等），并提供强大的数据集管理功能、可视化的 Prompt 编排以及应用运营工具。
安装包括原生安装和容器安装两种方式。推荐使用容器安装，因为原生的组件太多辣：
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 # 修改端口等参数（可选）
如果需要修改nginx映射的端口，则修改 .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
需要修改nginx映射端口的话，修改 .env 文件里EXPOSE_NGINX_PORT和EXPOSE_NGINX_SSL_PORT配置即可。
后来我改成了12080端口：
设置完成后就进入Dify了，右上角设置ollama内容：
配置Ollama信息：
nomic-embed-text，这是一个文本向量化的模型，做向量化检索时使用。
ollama pull nomic-embed-text
此时有两个模型了：
选择数据源：
数据分段与清洗
处理
等待完成即可。
处理的时候占用的CPU/GPU/内存大概如下：
完成
选择知识库，开始提问。明显感觉比anythingLLM靠谱。
GitHub上有一些有趣的工作流，可以看看：Awesome-Dify-Workflow
git clone https://github.com/infiniflow/ragflow.git
cd ragflow/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
看这个提示，似乎是不支持macOS？
没道理，我看这个bug他们已经修复了：https://github.com/infiniflow/ragflow/issues/5171
换了最新的版本v0.17.1,还有问题。又翻了下：有大佬给解决办法了，直接本地build这个基础镜像：
git clone https://github.com/infiniflow/ragflow.git
cd ragflow/
pip3 install huggingface_hub nltk
python3 download_deps.py
docker build -f Dockerfile.deps -t infiniflow/ragflow_deps .
docker build -f Dockerfile -t infiniflow/ragflow:nightly .
docker build --build-arg LIGHTEN=1 -f Dockerfile -t infiniflow/ragflow:nightly-slim .
ps：注意要git下载啊！ nightly 的镜像还要拷贝 .git 目录，我服了。
下载有点狠，不知道要占用多少空间，本不富裕的Mac硬盘又要雪上加霜：
下载完了，开始build：
build好花时间啊。
在折腾 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进行告警，于是便有了这篇文章。
参考：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 的配置文件 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）
可视化握手时间
(time() - wireguard_latest_handshake_seconds{src_peer!="",target_peer!=""})
可视化连接速率
irate(wireguard_sent_bytes_total{node=~"a1|b1",target_peer=~"a2|b2"}[$interval])
我上一篇文章《neovim 安装使用备忘》已经有点老了，这会儿 NvChad 已经更新到2.5了。按照之前的办法已经无法安装了。
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"]
docker build -t nvchad:v20241223 .
构建完成后，Docker 会生成一个镜像，可以用于后续的容器启动。
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
docker exec -it nvchad nvim +NvimTreeToggle
nvim +NvimTreeToggle：容器启动时，nvim 会自动执行 :NvimTreeToggle，打开 NvimTree 文件树视图。
push 镜像到docker.io了：
docker tag nvchad:v20241223 kelvinblood/nvchad:v20241223
docker push kelvinblood/nvchad:v20241223
基于步骤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 命令即可快速进入。
