Hadoop第三篇：内网服务器不能出公网？用 Ollama 本地模型，AI 运维照样跑

—— 系列第三篇：数据不出门的大模型方案。Ollama 选型、安装、接入 AI SSH 运维 Agent 全流程，含显存对照表

本篇定位：很多公司的运维网是物理隔离的，云端大模型 API 根本通不了。这篇讲清楚怎么用 Ollama 在内网跑本地模型，接入 AI SSH 运维 Agent，实现数据零出门的 AI 运维。从显存选型到接入验证，照抄即可。

目录

• 一、为什么内网场景必须用本地模型
• 二、硬件选型：显存对照表（先看这个再买卡）
• 三、Ollama 安装（Linux / Windows 照抄）
• 四、离线拉模型：三种子方案
• 五、接入 AI SSH 运维 Agent（5 分钟）
• 六、调优：让本地模型"够聪明也够快"
• 七、实测对比：本地模型 vs 云端 API
• 八、常见问题

一、为什么内网场景必须用本地模型

三个典型的"不能出公网"场景：

本地模型的答案很直接：模型跑在自己的机器上，数据从头到尾不出内网一步。Ollama 是目前本地跑大模型最省事的方案——一条命令装好，ollama run 就能聊，同时暴露标准 API 接口供工具调用。

二、硬件选型：显存对照表（先看这个再买卡）

选型第一原则：模型参数量决定显存下限，别让模型挤进小显存后靠 CPU 硬扛，速度会慢到不可用。

经验结论：

• 4G 显存的老卡：能跑 7b，但长输出会掉到 CPU，体验一般；
• 8G 显存（3060/4060Ti）：7b Q4 全程 GPU，够日常运维问答，性价比最高；
• 16~24G（4080/4090/A5000）：上 14b~32b，诊断质量接近云端中档模型；
• 纯 CPU 服务器：跑 7b 也能出结果，适合"值守告警摘要"这种不追求秒回的场景。

三、Ollama 安装（Linux / Windows 照抄）

Linux（内网机器先在有网机器下载安装包再拷入）：

# 有网机器上下载
curl -sSL -o ollama-linux-amd64.tgz \\
https://ollama.com/download/ollama-linux-amd64.tgz

# 拷入内网机器后解压安装
tar zxf ollama-linux-amd64.tgz -C /usr
ollama –version

Windows（管理端）： 官网下载 OllamaSetup.exe，双击装完即有托盘图标，命令行直接可用。

让内网其他机器也能调用（重要）： Ollama 默认只听 127.0.0.1，要改成监听内网地址：

# Linux：systemd 服务加环境变量
systemctl edit ollama
# 写入：
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_KEEP_ALIVE=30m"

systemctl daemon-reload && systemctl restart ollama

安全提醒：0.0.0.0 只应开放在隔离内网里；同时用防火墙把 11434 端口限制到运维网段。

四、离线拉模型：三种子方案

内网机器不能 ollama pull，三个办法从"有网"到"无网"：

方案 A：ollama 官方导出（推荐）

在有网机器上拉好模型，把整个模型目录打包拷入内网机器，放到同路径下即可：

# 有网机器
ollama pull qwen2.5:7b
tar czf ollama-models.tar.gz -C /usr/share/ollama/.ollama/models .

# 内网机器（同名用户同路径）
tar xzf ollama-models.tar.gz -C /usr/share/ollama/.ollama/models/
ollama list # 能看到 qwen2.5:7b 即成功

方案 B：GGUF 文件直接导入

从 ModelScope / HuggingFace 镜像下载 GGUF 文件，写一个 Modelfile 导入：

echo 'FROM ./qwen2.5-7b-instruct-q4_k_m.gguf' > Modelfile
ollama create qwen2.5:7b -f Modelfile

方案 C：内网代理仓（团队级）：在有网机器架一个只代理模型下载的网关，内网统一走它拉取。适合几十台机器都要用的大团队。

新手建议直接用方案 A，文件拷过去就能用，零学习成本。

五、接入 AI SSH 运维 Agent（5 分钟）

模型就绪后，接入只要三步：

第一步：确认 API 可用。 在管理机（Windows 图形版所在机器）测试连通：

curl http://192.168.10.50:11434/api/tags
# 返回模型列表 JSON 即通

第二步：填写连接信息。 在图形版「AI 模型」页签选 ollama，填：

第三步：发一句话验证。

检查一下 mysql-master 的主从同步状态，异常的话说明原因

验证要点：回答里应该出现它执行的真实命令（SHOW SLAVE STATUS 之类）和你的真实主机名——这说明模型、工具、主机三方已经串起来了。

六、调优：让本地模型"够聪明也够快"

四个实测有效的调优点：

七、实测对比：本地模型 vs 云端 API

同一套 15 台主机的巡检任务，实测数据：

结论：日常值守和例行巡检用本地模型，重大变更分析临时切云端（如果合规允许）——两级配置才是内网团队的最优解。而在物理隔离环境里，7b 本地模型 + 好的巡检剧本，已经能覆盖 80% 的日常运维问答。

八、常见问题

Q：报 ollama connect refused？
九成是没改 OLLAMA_HOST，或防火墙没放行 11434。ss -tlnp | grep 11434 看监听地址。

Q：回答特别慢，一卡一卡的？
模型超出显存在用 CPU 兜底。nvidia-smi 看占用，换小一档量化版（Q4），或降低上下文长度。

Q：本地模型答非所问？
先确认拉的是 instruct 版本（如 qwen2.5-7b-instruct）；再把上下文里塞的巡检剧本精简一点——小模型上下文超载会开始胡说。

Q：能一次跑多个模型吗？
显存够就行，Ollama 会自动加载/卸载。但值守场景建议固定一个模型常驻，避免反复换入换出。

本文为「AI SSH 运维 Agent」系列第 3/8 篇。下一篇：《用巡检剧本给 MySQL 做体检》——把 DBA 的巡检清单变成 AI 的一键体检。