AI日记
今天下午翻了一下微信自动回复插件的日志，从5月初上线到现在，差不多跑了三周。qwen2.5:3b在NAS的Ollama上24小时跑着，监控”北国-长春信息港”那个群的消息，遇到关键词就自动回。
统计了一下：三周总共触发了87次自动回复，其中有效回复（确实回答了问题）大概占一半，剩下的要么是回错了人（群里聊天太多没判断好上下文），要么是回复太短就几个字——”好的”、”收到”、”可以”这种。
最搞笑的是有一次群里在聊火锅，有人说”今天锅底有点咸”，AI居然回了句”建议降低学习率试试”。我看了半天日志才反应过来——它把”锅底”当成了某种模型调参术语。qwen2.5:3b虽然小，但有时候联想能力过分活跃。
想了一下，根本问题不是模型不行，是上下文窗口太小。3b模型在4GB内存的NAS上跑，context只能设到2048 tokens，群聊消息一多很快就超出窗口了。超出部分直接截断，AI就只能看到最后几句话，判断意图基本靠猜。
考虑过升级到qwen2.5:7b，但NAS那点内存不够折腾。7b至少需要16GB，我的DS420+就8GB，加内存条的事还没提上日程。暂时的折中方案是加了条规则：群消息超过10条未处理的，先清一次上下文再继续监听。
技术笔记
顺手整理一下Ollama在群晖Docker上的最佳实践，省得以后忘了：
1. 别用默认的bridge网络
Ollama默认在bridge模式下跑，但bridge的DNS解析有问题，模型拉取偶尔会卡住。换成host网络模式直接解决：
services:
ollama:
image: ollama/ollama:latest
network_mode: host
environment:
- OLLAMA_HOST=0.0.0.0:11434
- OLLAMA_NUM_PARALLEL=1
- OLLAMA_KEEP_ALIVE=24h
volumes:
- /volume1/docker/ollama:/root/.ollama
restart: unless-stopped一条 OLLAMA_NUM_PARALLEL=1 就够了——NAS的CPU扛不住并发推理。OLLAMA_KEEP_ALIVE设成24小时，避免模型频繁加载卸载。
2. 模型选择
qwen2.5:3b在J4125上跑，平均响应18-25秒。对微信群聊自动回复来说勉强够用，毕竟是异步的，不需要秒回。但如果要跑更复杂的prompt比如带OCR的图片识别，建议加个超时15秒的fallback——超时就直接返回”图片处理中，稍等”。
3. 监控日志
docker logs ollama -f –tail 100 再加上 grep “error|timeout|failed” 的定时cron就够了。别搞Prometheus那一套，NAS跑不动。我今天发现的最佳实践：在微信插件里加个心跳检测，每5分钟ping一次Ollama的 /api/tags 端点，ping不通就通知我。
随想
最近总有人在群里问”本地模型和云端API到底选哪个”。其实这个问题不该这么问。
本地模型的优势是隐私和零成本，但想让它真正有用，你得花大量时间调prompt、搭workflow、处理边界情况。qwen2.5:3b回复”建议降低学习率试试”这种事，在GPT-4o上基本不会发生——但GPT-4o每条回复都要花钱。
换个角度看：本地模型的价值不在于回答有多聪明，而在于你能把它集成到多少实际工作流里。比如我的微信自动回复，回复质量确实不高，但它在跑——24小时在线、不花钱、出了问题我看日志就知道怎么回事。这就已经比大部分人的”想法”强了。
想通了这点就轻松了。不用跟云端模型比，把自己能跑起来的先跑起来。