断连 AI 运维：在没有互联网连接的情况下运行企业 AI

“本地部署”和“真正脱离互联网也能工作”之间隔着一道鸿沟。大多数以本地部署为卖点的企业软件，仍然默认存在一条可靠的网络链路：许可验证、遥测上报、模型下载、更新检查、依赖解析，都要走网络。把网线拔掉，软件就不工作了。

对越来越多的组织来说，这样的前提已经无法接受。加拿大北部的偏远矿区拿不到可靠的宽带，在海上航行的舰船没有云端连接可用，在争议环境中部署的军事单位也无法保证随时都有网络。除此之外，还有一些组织出于严格的安全策略，主动把自己的 AI 基础设施与互联网切断，把断连本身当作一项安全控制手段来执行。

微软开始用“断连”（disconnected）这个词来描述这种运行模式，以区别于“气隙”（air-gapped）。后者指的是彻底的物理隔离，完全不具备任何数据传输能力。这个区分之所以重要，是因为断连环境的约束条件、架构模式和工具要求，跟联网环境和气隙环境都不相同。

本文要讲的，是如何在整条连接性频谱上设计、部署和运维 AI 系统。

断连运维频谱

断连是一条连续的频谱，频谱上的每个位置都会给 AI 架构施加不同的约束：

大多数运行断连 AI 的组织落在中间这两类：它们手上保留了某种周期性的数据传输手段，够不上完全气隙的程度，而日常的 AI 运维又无法依赖持续可用的互联网接入。

断连 AI 的应用场景

远程工业作业

偏远矿区、海上石油平台和远程施工现场通常只有卫星互联网，带宽有限（256 Kbps 到 2 Mbps），延迟很高（600 毫秒以上）。在这种速率下，向云端 AI 服务发起流式 API 调用，每个请求要等 5 到 15 秒才有响应，前提还是链路当时确实可用。

矿区如果要跑 AI 辅助的地质分析或设备预测性维护，推理就必须在本地完成。模型跑在现场硬件上，等卫星链路可用时，再把日志和结果同步回总部。

海事与海军作业

商业航运和海军舰船一次出海数周，连接微弱甚至完全没有。航线优化、设备监测、文档分析这类 AI 应用，必须完全跑在船载硬件上。在涉密网络上作业的美国海军舰船还有额外约束：AI 系统必须留在舰船涉密网络的边界之内，不能有任何对外的数据通路。

前沿部署的军事单位

前沿部署的军事单位所处的环境，网络连接本身就不可靠，还可能被争夺，甚至被对手主动拒止。用于情报分析、后勤规划和态势感知的 AI 能力，必须能在这支单位随身携带的任何硬件上跑起来。这意味着模型要小到能装进加固笔记本或边缘服务器，同时对互联网保持零依赖。

灾害响应

应急响应队伍进入的是基础设施受损甚至被彻底摧毁的区域，通信网络可能中断数天乃至数周。用于损毁评估（卫星或无人机影像分析）、资源调配和文档处理的 AI 工具，必须在完全没有连接的便携硬件上照常工作。

出于安全策略的断连运维

有些组织的安全策略要求 AI 系统跑在刻意与互联网隔离的网络上，驱动因素是安全架构本身，而不是所处的地理位置。处理敏感交易算法的金融机构、掌握专有研究数据的制药公司，以及接触受控非涉密信息（CUI）的政府承包商，都可能把主动断连当作一项安全控制措施。

断连 AI 的技术挑战

脱离互联网运行 AI，会带来五类技术问题，这些问题在联网部署里从来不会出现。

1. 模型更新与版本管理

联网环境里，更新模型就是一条 pull 命令。断连环境里，每一次模型更新都要走一套刻意设计的传输流程：

• 新模型怎么进来？ 通过带安全扫描的物理介质（U 盘、移动硬盘），涉密网络走跨域解决方案，间歇连接的站点则在连接窗口内批量下载。
• 版本怎么管？ 本地模型注册中心（Harbor、自建容器镜像仓库，或者一套带版本号的文件系统）必须记录每个模型版本的哈希、来源和审批状态。
• 怎么回滚？ 新模型如果表现不如上一版，就需要本地回滚能力。这意味着现场至少要保存每个生产模型的两个版本。

间歇连接环境的通行做法是：在连接窗口内把更新下载到暂存区 → 本地验证 → 在维护窗口内提升到生产 → 保留上一版本以备回滚。

2. 监控与日志

联网的 AI 系统会把指标推送到集中监控（Prometheus、Datadog、CloudWatch）。断连系统做不到这件事，取而代之的是：

• 本地日志：所有推理请求、模型性能指标、错误和系统健康数据都写入本地存储。存储容量按预期最长断连时长再加一段缓冲来规划。
• 批量同步：连接恢复后，日志打包上传到中心监控。这需要一个能处理断点续传、去重和冲突解决的同步代理。
• 本地告警：关键告警（模型故障、磁盘写满、GPU 错误）必须在本地触发，比如发到本地邮件服务器、SNMP trap，或者内网上的仪表盘告警。没有互联网的时候，PagerDuty 指望不上。

日志存储要单独做预算。一套活跃度中等的 AI 系统，每天 1 万次推理请求，完整记录请求和响应，每天产生 2 到 5 GB 日志。按 30 天断连期算，压缩前需要 60 到 150 GB 的日志存储空间。

3. 许可管理

很多“本地部署”方案就是在这一环上栽在断连环境里。企业 AI 常见的软件许可模式：

办法很直接：任何软件在部署到断连环境之前，先在完全断网的条件下，按你预期的最长断连时长完整跑一遍。厂商文档只能当参考，实测出来的结果才算数。很多号称“支持本地部署”的工具，压根就没有在断网条件下被验证过。

以 NVIDIA AI Enterprise 为例，断连部署需要一台本地的 Delegated License Server（DLS）。官方文档里写了这套配置，可它并非默认选项。断网之前没有把它搭起来，GPU 算力许可到期就会失效。

4. 知识库时效性

使用检索增强生成（RAG）的 AI 系统，依赖一个理应反映当前信息的知识库。在断连环境中：

• 数据会陈旧到什么程度？ 有些应用（分析历史文档、设备维护手册）的知识库变化缓慢，陈旧几乎没有影响。另一些应用（威胁情报、市场分析）哪怕只陈旧一周，输出质量也会下降。
• 知识库怎么更新？ 新文档必须在本地完成摄取、切块、向量化和索引。一旦嵌入模型或向量数据库需要联网，整条 RAG 链路就断了。
• 矛盾怎么处理？ 连接窗口之后到达的知识库更新，可能与断连期间 AI 一直在分析的文档相互矛盾。

设计 RAG 链路时就要把陈旧容忍度考虑进去。在知识库中保留元数据时间戳，让 AI 能说明它引用的资料最后更新于什么时候。

5. 依赖管理

现代 AI 软件的依赖树很深。一套典型的推理环境可能依赖：

• Python 包（PyTorch、transformers、vLLM）
• 系统库（CUDA、cuDNN、NCCL）
• 容器镜像（如果用 Docker/Kubernetes）
• 模型权重（从 Hugging Face 下载，动辄数 GB）
• 分词器文件、配置文件、安全过滤器

联网环境里，pip install 和 docker pull 会自动解析这些依赖。断连环境里，每一项依赖都必须提前准备好。漏掉一项，部署就会以一条语焉不详的 import 错误告终。

解决办法是把所有依赖都打进容器镜像。在联网环境里构建镜像并验证可用，再把镜像（AI 负载通常有 10 到 50 GB）传输到断连站点，用本地镜像仓库（Harbor、registry:2）托管。

断连 AI 的架构模式

模式 1：自包含推理节点

最简单的一种。一台服务器或工作站，装齐本地跑 AI 推理所需的一切。

组成：

• GPU 硬件（工作站用 NVIDIA RTX 4090/A6000，服务器用 A100/H100）
• 本地模型文件（llama.cpp/Ollama 用 GGUF 格式，vLLM 用 PyTorch 权重）
• 本地推理服务（Ollama、llama.cpp server、vLLM 或 TGI）
• 调用本地推理端点的应用层

适合：单人或小团队部署、边缘与战术应用、基于笔记本的野外部署。

局限：没有冗余，只能跑现有硬件装得下的模型，缺少集中管理。

模式 2：本地 AI 服务集群

多节点部署，把 AI 推理当作一项服务提供给内网用户。

组成：

• 2 个以上 GPU 推理节点（负载均衡与冗余）
• 存放已审批模型版本的本地模型注册中心
• 转发推理请求的 API 网关（Kong、NGINX）
• 本地监控栈（内网上的 Prometheus + Grafana）
• 认证与授权（对接本地 LDAP/AD）

适合：部门级部署、多用户的远程站点作业、有意断连的企业网络。

更新方式：新模型通过物理介质传入，或在连接窗口内下载，先在内网的预发布环境里测试，验证通过后再提升到生产。

模式 3：中心辐射式加周期同步

适用于总部联网、多个远程站点断连的组织。

中心（联网）：

• 集中的模型训练与微调
• 模型验证与审批流水线
• 汇总的监控与分析
• 知识库管理

站点（断连）：

• 本地推理集群
• 本地模型注册中心（镜像中心的一个子集）
• 本地日志汇聚
• 批量同步代理

同步流程：站点一旦建立连接（预定的卫星窗口、物理介质专人递送，或 VPN 链路），就从中心拉取已审批的模型更新，并把汇总的日志和用量数据推送上行。同步过程是幂等的，中断之后可以从断点继续。

适合：有远程站点的矿业公司、海运船队，以及联网和断连位置混合存在的组织。

以 Microsoft Foundry Local 为参照

微软的 Foundry Local（2025 年发布）值得当作断连 AI 运维的参考实现来研究。它提供一套本地运行时，在 Windows 和 Linux 设备上运行小语言模型（SLM），推理时不依赖云端。

Foundry Local 的几项架构决策，对任何断连 AI 部署都适用：

• 模型只下载一次，之后缓存在本地。 首次下载完成后，推理不再需要互联网。这个模式是对的，代价是在完全断连的环境里，首次传输得由你自己解决。
• 本地 API 兼容。 Foundry Local 暴露的是兼容 OpenAI 的 API，为云端 AI 写的应用只要改一下端点 URL 就能切到本地推理。这一点对可移植性很关键。
• 不强制遥测。 这套运行时在运行期间不会向微软回传任何使用数据。这在断连场景里属于底线要求，而商业 AI 工具中真正做到的意外地少。

Foundry Local 面向的是开发和边缘场景，企业规模的断连部署超出了它的定位。更大规模的断连运维，还是要用上面讲的那几种集群模式。不过它遵循的设计原则（本地优先、运行时零依赖、API 兼容）是正确的地基。

“拔网线”测试

任何工具在部署到断连环境之前，先跑这个测试：

1. 在一台联网的干净机器上安装软件
2. 完成初始设置（模型下载、许可激活、配置）
3. 断开机器的所有网络（关掉 Wi-Fi，拔掉网线）
4. 等待 48 小时
5. 尝试使用软件的每一项功能

你会看到这些情况：

• 许可校验失败：启动时或周期性校验许可的软件会停止工作。有些留了宽限期（7 到 90 天），有些立刻失效。
• 尝试下载模型：懒加载模型的工具（首次使用时才下载，而非安装时下载）会在本地没有缓存的情况下失败。
• 更新检查卡死：启动时检查更新的软件可能要等 30 到 60 秒的超时才继续，有些干脆卡住不再往下走。
• 遥测失败：上报使用遥测的工具，在遥测端点不可达且错误处理粗糙时，可能疯狂打错误日志、变慢，甚至直接失败。
• 资源缺失：从 CDN 加载字体、图标或 JavaScript 的 Web 界面会渲染错乱，或者根本加载不出来。

把每一次失败都记录下来。逐项判断：有没有配置项可以关掉这个网络依赖？有没有绕过去的办法？还是说这个工具从根上就不适合断连运行？

能干净通过这个测试的工具：

• Ollama：模型下载完成后完全本地运行，不回连。
• llama.cpp：编译好的二进制加本地模型文件，网络依赖为零。
• 开源模型（GGUF 格式）：磁盘上的文件，没有 DRM，不用激活。
• vLLM（配本地模型）：模型就位后全程本地运行。

常见失败的工具：

• 大多数商业 AI 平台：许可校验过不去。
• 托管的 Kubernetes AI 服务：默认拉容器镜像和解析 DNS 都要联网。
• 带云端层的向量数据库：有些默认走云存储后端。
• 用 pip 安装的 Python 工具：依赖没有预装，离线状态下解析不了。

断连环境中的数据准备

数据准备本来就是难题，在断连环境里这个难题被进一步放大。联网企业至少还能用云端标注工具，把文档送去 OCR 服务，或者在拿到相应安全审批的前提下使用 SaaS 数据清洗平台。断连组织这几条路都走不通。

数据准备链路的每一步都必须在本地跑：

• 文档摄取：OCR、PDF 解析、表格抽取，全部本地完成，不调用 Google Vision、AWS Textract 或 Azure Document Intelligence。
• 数据清洗：去重、归一化、纠错，全部由本地算力承担。
• 标注与打标：领域专家必须能在内网上用不联网的工具完成数据标注。
• 合成数据生成：如果用 AI 辅助扩增，生成模型也得跑在本地。
• 导出：输出可直接训练的数据集（JSONL、切块文本、COCO/YOLO）不能带网络依赖。

拼装式的工具组合（Docling 做解析、Label Studio 做标注、Cleanlab 把质量关、自研脚本做导出）在断连环境里的麻烦更大。每个工具都有自己的依赖树、自己的更新节奏，以及自己那份潜在的网络依赖。在断连环境里同时维护五套彼此独立的工具，集成成本和长期维护负担都会成倍增加。

自带依赖的原生桌面应用在这里有天然优势。它们像装普通软件一样安装，依赖随安装包一起携带，跑起来不需要 Docker、Kubernetes 或者任何一层网络基础设施。

断连 AI 运维手册

部署前检查清单

• 所有软件都通过了 48 小时拔网线测试
• 所有模型权重已预先下载并保存在本地
• 本地模型注册中心已配置并填充完毕
• 许可服务器（如果需要）已部署在内网
• 所有容器镜像已缓存到本地镜像仓库
• 本地监控和告警已配置
• 日志轮转和存储容量按最长断连时长做过规划
• 备份与恢复流程已在没有互联网的条件下验证
• 领域专家已接受本地工具培训（他们没法上网搜答案）
• 有一份纸质或电子的运行手册，覆盖常见故障与处置方式

断连运行期间

• 盯住本地磁盘空间，日志和推理缓存会持续增长
• 在本地跟踪模型性能指标，留意漂移迹象
• 为任何本地配置改动维护变更记录
• 把模型更新需求排成队列，等连接恢复后处理
• 定期对生产模型跑验证基准

重新连接与同步

• 先把日志和指标同步到中心监控（保住运维可见性）
• 拉取模型更新和安全补丁
• 把本地微调的模型或数据集推送上去，供中心审核
• 更新 RAG 系统的知识库
• 核对许可状态，必要时续期

断连 AI 的规划：关键决策

断连 AI 运维和联网运维的差别在于形态。工作重心从运行时那一端（监控、扩缩容）整体前移到了部署之前（预置、测试、编写文档）。愿意在部署前准备上投入的组织会发现，断连运维反而比联网运维更可预测：活动部件更少，也没有那种会不打招呼就自己变动的外部依赖。

今天已经有足够成熟的工具和模型，可以在零互联网连接的条件下跑起真正能干活的 AI 系统。难点在于把它们组装成一套技术栈，让从推理到数据准备再到监控的每一个组件都真正能在离线状态下工作。从拔网线测试开始，一步步往上搭。