夜雨聆风每次你用 Claude Code 或 ChatGPT，生产环境的日志、配置、IP 地址其实都在往别人的服务器上送。本文教你拿 Ollama 在自己显卡上部署三个开源模型，分别帮你写脚本、查日志、审配置——全程离线，一张 RTX 3060 就够。安全部门再也不会请你喝茶了。
上个月，我们公司安全部群发了一封邮件。
标题特直白：「禁止将生产环境数据输入外部 AI 服务」。里面挂了三个案例，有一个就是我们隔壁组一哥们儿，把几百行带内网 IP 和数据库连接串的 Nginx 配置，原封不动贴进了 ChatGPT。安全部在网关日志里逮到的，一抓一个准。
收到那封邮件之后，我就开始琢磨：能不能搞一套在本地机器上就能跑的运维 AI？
还真有。答案就是 Ollama。三行命令装好，几个模型轮着用，全程不联网。我的卡是 RTX 3060，12GB 显存，跑 7B 参数的模型很轻松。你要是有 RTX 4090，24GB 显存，13B 也能流畅跑。
下面是我这两个月实际在用的三个场景，每个都有完整命令和真实输出，照着敲就行。
一分钟装好
# Linuxcurl -fsSL https://ollama.com/install.sh | sh# macOSbrew install ollama# Windows# 直接去 ollama.com 下载安装包装完验一下：
ollama --version# ollama version is 0.5.x场景一：让 AI 帮你写 Shell 脚本
运维里最烦人的就是那些重复性劳动：监控脚本、备份脚本、日志清理脚本……手写一个，查 man page、试错、来回调，没半小时下不来。
我用的 DeepSeek-Coder 6.7B，一个专门为写代码优化过的模型，个头才 4GB，连 GTX 1060（6GB 显存）都能跑。
# 下载模型（第一次会自动下载，大约 4GB）ollama pull deepseek-coder:6.7b# 让它写一个监控脚本ollama run deepseek-coder:6.7b 「写一个 bash 脚本，监控 /data 目录使用率，超过 80%发钉钉告警。要求：用 df 命令、用 curl 调钉钉 webhook、加注释」它会直接吐出来一个完整的、带注释的脚本。下面这个就是我拿它生成后，只稍微改了几处的真实版本：
#!/bin/bash# 磁盘使用率监控 + 钉钉告警# 用法: */5 * * * * /opt/scripts/disk_monitor.shTHRESHOLD=80WEBHOOK=「https://oapi.dingtalk.com/robot/send?access_token=你的 token」USAGE=$(df /data | tail -1 | awk '{print $5}' | sed 's/%//')if [ 「$USAGE」 -gt 「$THRESHOLD」 ]; then MESSAGE=「{\」msgtype\「:\」text\「,\」text\「:{\」content\「:\」⚠️ /data 使用率 ${USAGE}%，已超阈值 ${THRESHOLD}%\「}}」 curl -s -H 「Content-Type: application/json」 -d 「$MESSAGE」 「$WEBHOOK」fi往 crontab 里一丢，每 5 分钟跑一次，比你手写快十倍不止。
实际效果： 我拿它生成了五个不同用途的运维脚本——磁盘监控、Nginx 日志轮转、MySQL 备份、SSL 证书过期检查、进程守护。这五个脚本如果人工手写，加起来至少花 3 小时。AI 生成加上我审查修改，总共 40 分钟。其中有三个我连改都没改，直接就能用。
场景二：用 AI 分析生产日志
出故障的时候，你吭哧吭哧 SSH 上服务器，对着一屏一屏的日志一行一行找——太慢了。
直接把日志丢给本地模型，让它帮你找规律、抓异常、定位根因。我用的是 Qwen2.5 7B，体积 6GB，中文理解能力很强，特别适合分析中文日志。
# 下载模型（约 6GB）ollama pull qwen2.5:7b# 分析 Nginx 访问日志，找异常ollama run qwen2.5:7b 「分析这段 Nginx 日志，找出异常访问模式：$(tail -50 /var/log/nginx/access.log)」我拿一次真实故障排查做过测试。当时生产环境突然狂报 502，Nginx 错误日志长这样：
2026/06/10 14:23:15 [error] 1234#0: *5678 upstream timed out (110: Connection timed out) while connecting to upstream2026/06/10 14:23:16 [error] 1234#0: *5679 connect() failed (111: Connection refused) while connecting to upstream...（后面还有 300 多行类似的）把这段日志喂给 Qwen2.5 7B：
ollama run qwen2.5:7b 「分析以下 Nginx 错误日志，找出根因：$(cat /var/log/nginx/error.log | tail -100)」模型是这么回的：
关键发现：1. 14:23:15 开始出现大量 upstream timed out，超时时间集中在同一秒——说明上游服务在这个时间点整体响应变慢2. 14:23:16 出现 connect() failed (111: Connection refused)——上游服务进程可能已崩溃3. 所有错误指向同一个 upstream 地址 10.0.2.15:8080——问题集中在单台后端结论：10.0.2.15 这台后端在 14:23:15 先变慢、14:23:16 彻底挂掉。建议先 check 该服务器上的应用进程和系统资源。这 100 行日志如果让我手工查，得出同样的结论大概要 15 分钟。模型用了不到 5 秒。
注意： 模型全程在本地跑，日志压根没离开过你的机器。安全部门想找麻烦都找不到理由。
三种 AI 分析场景对比——手写脚本 vs AI 生成、人工查日志 vs AI 分析、人工审配置 vs AI 审查
场景三：用 AI 审查 Ansible Playbook
配置管理是运维的核心活儿——但越是核心越容易出错。一个 Ansible Playbook 经过十几个人改来改去，到后面没人记得当初为什么那么写。
我用 CodeLlama 13B 来审查配置。这个模型在代码理解和安全审计方面表现最好，比较适合 RTX 4090（24GB）或更高配的卡。显存不够可以用 7B 版本。
# 有 24GB 显存，用 13B 版本ollama pull codellama:13b# 显存只有 12GB，用 7B 版本ollama pull codellama:7b# 审查一个 Ansible Playbookollama run codellama:13b 「审查这个 Ansible Playbook，找出潜在问题：$(cat deploy-app.yml)」我拿了一个生产环境实际在用的 deploy-app.yml 做测试。这个文件 200 行，用来部署一个 Java 应用。CodeLlama 找出了三个问题：
command模块没加 creates参数——导致每次执行都会重复跑重启服务的 handler 没加 throttle——如果 20 台机器同时重启，会产生瞬时高峰lineinfile用了简单匹配，如果配置里有相似行，容易误修改
这三个问题里，第一个和第三个确实是我 review 时漏掉的。
选型速查
记住两条：
7B 以下用 qwen2.5:7b，13B 用codellama:13b显存不到 8GB 就选 deepseek-coder:6.7b，写脚本专精，其他场景会弱一点
本地跑 vs 云端 API 对比
结论： 敏感数据（日志、配置、IP）走本地模型。复杂推理（架构设计、多文件重构）走云端。这俩不是替代关系，是互补。
安全部那封全员邮件发出的当天，我就把这套东西搭起来了。两个月后安全审计抽查，我的机器干干净净——所有 AI 流量都在本地，网关日志里一条外部 AI 服务的记录都找不到。
其实就一个下午的事儿：Ollama 装好、模型下好、三个场景挨个试一遍。换来的好处是，以后每次 copy 日志给 AI 分析时，不用再先手动去脱敏了。
显卡闲着也是闲着，不如让它干点正事。
关注我，每周拆一个运维场景的本地 AI 方案。不推 API，只推命令行。你的显卡是哪款？评论区聊聊，我帮你看看能跑什么模型。
