科室八个人都要用 AI 校对，但机器是涉密内网，外网一个包都进不来；全科室只有一台机器有 GPU。这是上个月我接到的活。最后落地方案：那台 GPU 机器跑 Ollama 当推理底座，全科室共用，所有人 WPS 里的察元AI文档助手都指向它——文档和模型全程不出内网。这篇把部署过程按步骤记下来。
为什么选 Ollama 当底座
察元的模型配置支持任意 OpenAI 兼容端点：Ollama、LM Studio、Xinference、OneAPI 都行。选 Ollama 是因为部署最省事、社区包最多，配上 Qwen、DeepSeek 这些国产开源模型，校对和润色的活够用。这两年国产模型本地部署的热度一直没降，内网场景里它不是选择题，是唯一解。
第一步：GPU 机器装 Ollama，拉模型
内网装包走离线安装，这里不展开。模型提前在外网用好机器拉好，摆渡进内网后导入，或者直接在 GPU 机器上执行：
ollama pull qwen2.5:7b显存够就上更大的模型，校对任务对推理要求不高，7b 级别是性价比起点。拉完用ollama list确认模型都在，免得端点配好了才发现模型名拼错——离线环境里排查这种低级错误格外烦人。
第二步：让 Ollama 监听内网地址
Ollama 默认只听本机回环，全科室共用必须改成监听所有网卡：
OLLAMA_HOST=0.0.0.0 ollama serve改完在内网另一台机器上 curl 一下这个端口，通了才算数。别忘了在内网防火墙上给这台机器放行对应端口，这一步漏了能排查一下午。
第三步：各客户端配置察元的模型端点
每台机器上的察元加载项里，把模型端点指向http://GPU机器内网IP:11434——Ollama 的默认端口，协议本来就是 OpenAI 兼容，察元直接认。科室级更彻底的做法是上服务版（Docker 网络版），全科室共用一套服务，管理起来比逐台配省心。逐台配置的小团队注意统一写法：地址、端口、模型名三样做成一张卡片发群里，谁配错了照着抄。别低估这件事——八台机器八种写法，排查的时候够喝一壶。
第四步：两跳各验一次，再收工
验证别只验一半。先验文档工具链：
curlhttp://127.0.0.1:62588/healthz返回online说明本机 sidecar 正常。再验推理链路，让任何一台客户端跑一遍校对 dryRun：
先跑一遍校对（dryRun），汇总问题列表，不要先改正文；我确认后再写成批注如果这一步报MODEL_NOT_CONFIGURED，说明端点没配对——回第三步查三件事：地址写没写对、端口通没通、防火墙放没放行。清一色的低级错误，但占了部署问题的九成。还有一类隐蔽问题：端点通了但模型名对不上，报错不一定直观。让科室里最先跑通的那台机器当模板，其余照抄配置，是最笨也最稳的推广路径。
部署后的账
八个人共用一块 GPU，白天高峰期推理排队几乎无感；所有文档处理、模型推理都在内网完成，一个字节不出域，安全科那边一次验收通过。后续运维也省心：模型升级只动 GPU 机器一台，八台客户端无感知；真要换推理底座——比如多模型并存的场景换 Xinference——客户端只改端点地址，其他一律不动。唯一的代价是模型能力天花板摆在那儿，复杂改写不如云端大模型——但内网场景里，"能用且合规"的优先级永远排在"效果拔群"前面。
边界照例讲清楚：本地模型做校对建议，最终采纳要人工过目；密级标识、涉军涉装这类敏感判断，工具提示只能当参考，定密必须走人工流程。另外内网部署前记得照例走单位审批，合规动作一个不能省。还有条经验：先拿非涉密的日常材料试跑一周，把误报率摸清楚再正式上量，科室里对工具的信任，是一次一次靠谱攒出来的。一台 GPU 撬动一个科室的 AI 校对，这事在 2026 年已经不算稀奇，稀奇的是有人还在把文档往外网传。
