去年有组数据挺有意思：Reddit上自托管AI的帖子，60%都在问"怎么又崩了"。不是模型跑不动，是Python环境炸了、CUDA版本冲突、或者某个依赖升级后整个链路瘫痪。作者花了18个月踩完这些坑，最后把7个容器锁死在Docker里，全年宕机时间不到4小时。
这像什么？像早期安卓用户刷机——折腾ROM比用手机还累。作者说他的转折点很具体：某天发现维护服务器的时间，超过了用AI干活的时间。于是他做了产品经理最擅长的减法。
从"实验室"到"家电"的转身
作者的第一版方案很典型：裸机部署Ollama，手动装PyTorch，再搭个向量数据库。每试一个新模型，环境就要重修一遍。三个月后，他的服务器里有17个Python虚拟环境，他自己都分不清哪个在用。
Docker不是最优解，是唯一解——如果你不想当运维的话。
现在的架构极简：一个docker-compose.yml文件，7个服务定义清楚。Ollama跑模型，Open WebUI当界面，n8n处理工作流，再加上向量数据库和几款专用工具。新增服务？复制粘贴三行配置，重启完成。
这种"家电化"思路有个细节：作者把所有配置文件夹映射到持久卷。备份时不用管容器里装了什么，只拷几个文件夹就行。迁移服务器？在新机器上跑docker-compose up，15分钟后一模一样。
核心层：Ollama的隐藏设计
很多人把Ollama当"本地版ChatGPT客户端"，作者把它当操作系统。关键区别在API层——Ollama原生兼容OpenAI的接口格式，这意味着市面上90%的AI工具能直接对接，不用改代码。
他跑的主力模型是Llama 3.1 70B，量化到4-bit后显存占用约40GB。这个尺寸很微妙：刚好卡在单卡4090能跑、但双卡更稳的边界。作者选了后者，不是为速度，是为"晚上挂机生成报告时不会把其他服务挤崩"。
模型加载策略被很多人忽略：Ollama默认常驻内存，作者改成了按需加载。第一次响应慢3秒，但日常内存压力降了60%。配合Docker的内存限制，多个模型可以和平共处，不会某个任务把机器吃满。
有个细节他提得很具体：用Ollama的/modelfile功能自定义系统提示词。比如给代码模型预设"你是一位资深Python工程师，优先给出性能优化建议"，给写作模型预设"用中文回答，避免学术腔"。这样切换模型时，上下文不会乱。
界面层：为什么选Open WebUI
作者试过十几款前端，最后锁定Open WebUI（原Ollama WebUI）。理由很实际：它支持多用户、有权限管理、能直接调用Ollama的API，而且更新频率高——2024年提交了400多次代码。
但真正的决策点是"管道功能"（Pipelines）。这相当于给对话流加中间件：用户提问→管道处理→模型回答。作者搭了三条常用管道：
第一条过滤敏感请求，用本地小模型做意图识别，可疑内容直接拦截，不碰大模型。第二条做RAG（检索增强生成），先把问题向量化，去本地知识库搜相关片段，再拼进提示词。第三条最实用：自动把长对话总结成摘要，超过20轮就压缩，省token也省显存。
管道的设计让Open WebUI不只是"聊天窗口"，而是可编程的AI网关。作者甚至写了个管道专门处理代码请求——检测到编程相关问题时，自动切换成代码专用模型，同时打开网页搜索开关。
界面层的另一个隐藏价值：多模态支持。作者接入了本地运行的LLaVA模型，能解析图片。流程是用户上传图→Ollama调用LLaVA生成描述→描述文本进入主对话。全程不出局域网，扫描件、截图、设计稿都能直接扔进去问。
工作流层：n8n的自动化拼图
如果说Open WebUI是"人机对话"，n8n就是"机器与机器对话"。作者把它定位为"AI的四肢"——模型出主意，n8n去执行。
他的第一个自动化很朴素：每天早上8点，n8n抓取其订阅的20个技术博客，用Ollama生成摘要，筛选出与他工作相关的，发到飞书。全程无人干预，准确率约75%，"剩下的25%漏掉就漏掉，比信息过载强"。
更复杂的场景是客服工单处理。作者把企业微信的机器人接进n8n，用户提问→n8n调用Ollama分析意图→简单问题直接回答，复杂问题创建工单并分配。响应时间从平均4小时压到15分钟，且所有数据留在本地。
n8n的节点设计有个巧思：每个步骤可以插入"人工确认"节点。比如自动回复前，把草稿发给值班人员，点确认才发出。这在合规严格的场景是刚需——AI可以快，但不能失控。
作者提到一个踩坑点：早期版本的工作流遇到Ollama响应慢时会超时重试，导致重复创建工单。解法是用n8n的"等待"节点配合Webhook，让Ollama完成后主动回调，而不是轮询等待。
数据层：向量数据库的选型逻辑
RAG（检索增强生成）是本地AI的刚需——没有它，模型只能回答训练数据里的知识，无法对接私有文档。作者对比了Pinecone、Weaviate、Chroma、Qdrant四款向量数据库，最后选了Qdrant。
决策维度很产品经理：部署复杂度、查询速度、许可协议。Pinecone只有云服务，出局。Weaviate功能全但镜像体积大，他的小服务器扛不住。Chroma最轻量，但分布式支持弱，万一以后要扩容会卡脖子。
Qdrant的胜出点是"刚好够用"：单节点部署一条命令启动，向量索引速度每秒过万，Apache 2.0协议商用无忧。
实际使用中，作者把Qdrant接进了两个入口：Open WebUI的管道（对话时自动检索），以及一个独立的文档上传页面。后者用n8n搭建，用户传PDF→自动切分→向量化入库→邮件通知完成。整个流程他写了不到50行配置。
数据量的参考：目前存了约12万份技术文档，向量维度768，总占用约80GB磁盘。查询延迟P99在50毫秒以内，"比打开一个网页还快"。
监控层：Prometheus+Grafana的沉默守护
作者原话："没有监控的AI服务器，就像没有油表的车——你能开，但不知道什么时候抛锚。"
他的监控栈很标准：Prometheus抓指标，Grafana画图，Alertmanager发告警。但针对AI场景做了定制：
显存占用是核心指标。作者设了两道线：70%预警，90%自动杀进程。触发过两次，都是用户同时开了多个大模型对话，Docker的内存限制没拦住，靠监控层兜底。
模型推理延迟被拆解成三段：请求队列等待时间、模型加载时间、实际生成时间。作者发现大部分时间花在"等GPU"，而不是"算"。这推动他调整了Ollama的并行策略，把batch size从默认的1提到4，吞吐量翻倍。
最意外的发现：磁盘IO是隐形瓶颈。当多个用户同时上传文档做RAG时，向量数据库的写入会把机械硬盘吃满，导致查询卡顿。作者加了块500GB的NVMe缓存，问题消失。这个优化在官方文档里没提，是他看Grafana的磁盘延迟曲线猜出来的。
告警策略有个细节：只发"需要人处理"的事。模型加载慢、偶尔的高延迟，这些自动恢复的不打扰。但"Ollama服务崩溃超过2分钟"会同时推送到手机和邮箱，附带最近的日志片段。
安全层：不出局域网的底气
作者对"本地部署"的定义很严格：推理数据不出网关，模型文件不上云，甚至更新检查都走代理。
具体措施分三层。网络层：服务器在内网，只暴露80/443到反向代理，代理再对接公网。所有服务间的通信走Docker内部网络，外部扫不到端口。认证层：Open WebUI和n8n都接了LDAP，用公司统一账号体系，离职人员权限自动回收。
最偏执的设计：模型下载走手动镜像。Ollama默认会从官方库拉模型，作者改成了本地文件加载。新版本模型？先在一台隔离机器跑一周，确认没异常行为，再scp到生产环境。这拖慢了更新速度，但杜绝了"模型供应链攻击"的可能——2024年确实发生过HuggingFace被投毒的事件。
日志策略也做了切割：用户对话内容只存7天，向量检索日志存30天，系统监控日志存90天。作者说这不是为合规，是"万一服务器被黑，减少信息泄露的窗口"。
维护哲学：少即是多的长期主义
作者列了他的"不碰清单"：不追新模型（除非现有模型确实解决不了）、不装浏览器插件（用独立前端替代）、不用图形化Docker工具（命令行更可控）、不做多机集群（单点故障好过分布式调试地狱）。
这套架构跑了一年，升级次数屈指可数：Ollama大版本升级2次，都是docker pull后重启，无感完成。Open WebUI更新频繁，但他只跟进稳定版，"功能差两周不致命，稳定性差两小时就致命"。
年度维护时间统计：约16小时，其中12小时是主动优化，4小时是处理告警。作为对比，他第一年的裸机方案，月均维护时间就超过20小时。
作者最后提了一个反直觉的观察：用户最满意的不是"功能多"，是"从不掉链子"。他的同事里有几个人完全不懂技术，但每天用Open WebUI查文档、写邮件草稿、翻译论文。他们从没问过"这怎么部署的"，因为从来不用关心。
这大概就是"家电"和"实验室"的区别——前者存在感的极致，是让你忘记它的存在。
如果让你选，你会为"可能用上的功能"提前埋复杂度，还是像作者一样，先让核心链路稳到无聊？
热门跟贴