斷網 AI 操作：在沒有網路連接的情況下運行企業 AI

「本地部署」和「真正無需網路可運作」之間存在差距。大多數以本地部署為名行銷的企業軟體，仍然假設有可靠的網路連接——用於授權驗證、遙測、模型下載、更新檢查或依賴項解析。拔掉網路線，軟體就停止運作了。

對越來越多的組織來說，這是不可接受的。加拿大北部的遠端採礦作業沒有可靠的寬頻網路。在海上的海軍艦艇沒有雲端連接。部署在競爭環境中的軍事單位沒有保證的網路存取。而一些具有嚴格安全政策的組織，特意將其 AI 基礎設施與網際網路斷開，作為一種安全控制措施。

Microsoft 開始使用「斷網」這個術語來描述這種操作模式——有別於「氣隙」，氣隙意味著完全沒有任何資料傳輸能力的實體隔離。這種區別很重要，因為斷網環境有不同的限制、不同的架構模式，以及與連網和氣隙設置都不同的工具要求。

本指南涵蓋如何在整個連接性頻譜中架構、部署和操作 AI 系統。

斷網操作頻譜

斷網操作並非二元的。存在一個頻譜，頻譜上的每個點對 AI 架構施加不同的限制：

大多數操作斷網 AI 的組織屬於中間兩個類別。他們並非完全氣隙——他們有某種定期資料傳輸的機制——但他們無法依賴持續的網際網路存取進行日常 AI 操作。

斷網 AI 的使用案例

遠端工業操作

偏遠地區的採礦作業、海上石油平台和遠端建築工地通常有帶寬有限（256 Kbps 至 2 Mbps）和高延遲（600 毫秒以上）的衛星網際網路。在這些速度下，對雲端 AI 服務進行 API 呼叫，意味著每個請求 5 至 15 秒的響應時間——假設連接還可用的話。

運行 AI 輔助地質分析或設備預測性維護的礦山站點，需要在本地進行推理。模型在現場硬體上運行。當衛星連接可用時，日誌和結果會同步到總部。

海事和海軍操作

商業航運和海軍艦艇在海上度過數週，連接性極少甚至沒有。AI 應用——航線優化、設備監控、文件分析——必須完全在船上硬體上運行。在機密網路上操作的美國海軍艦艇有額外限制：AI 系統必須在艦艇的機密網路邊界內運作，沒有外部資料路徑。

前沿部署的軍事單位

前沿部署的軍事單位在網路連接不可靠、受到競爭或被對手故意阻斷的環境中操作。情報分析、後勤規劃和態勢感知的 AI 能力，必須在單位攜帶的任何硬體上運作。模型需要足夠小，可以在加固型筆記型電腦或邊緣伺服器上運行，並且需要零網際網路依賴地工作。

災害響應

緊急響應團隊部署到基礎設施損毀或摧毀的區域。通訊網路可能中斷數天或數週。用於損害評估（衛星/無人機圖像分析）、資源分配和文件處理的 AI 工具，必須在沒有連接的可攜式硬體上工作。

安全政策斷網操作

一些具有嚴格安全政策的組織，在特意與網際網路隔離的網路上操作其 AI 系統——不是因為他們在偏遠地點，而是因為他們的安全架構要求如此。處理敏感交易算法的金融機構、擁有專有研究資料的製藥公司，以及處理受控非機密資訊（CUI）的政府承包商，都可能選擇故意斷網作為安全控制。

斷網 AI 的技術挑戰

在沒有網際網路連接的情況下運行 AI，引入了連網部署永遠不會遇到的五類技術問題。

1. 模型更新和版本控制

在連網環境中，更新模型是一個拉取命令。在斷網環境中，每次模型更新都需要一個刻意的傳輸過程：

• 如何引入新模型？ 帶有安全掃描的實體媒介（USB、外部硬碟）、機密網路的跨域解決方案，或間歇性連接站點在連接窗口期間的批次下載。
• 如何版本控制？ 本地模型登錄（Harbor、自托管容器登錄或簡單的版本化文件系統）必須追蹤每個模型版本、其雜湊值、來源和批准狀態。
• 如何回滾？ 如果新模型的表現比前一個版本差，您需要本地回滾能力。這意味著在現場儲存每個生產模型的至少兩個版本。

對於間歇性連接環境，模式是：在連接窗口期間將更新下載到暫存區域 → 本地驗證 → 在維護窗口期間升級到生產環境 → 保留前一個版本以供回滾。

2. 監控和日誌記錄

連網 AI 系統將指標串流到集中監控（Prometheus、Datadog、CloudWatch）。斷網系統無法做到。替代方案：

• 本地日誌記錄：所有推理請求、模型效能指標、錯誤和系統健康資料記錄到本地儲存。根據最長預期斷連期加緩衝期來調整儲存大小。
• 批次同步：當連接恢復時，日誌被批次傳輸到集中監控。這需要一個處理部分上傳、去重和衝突解決的同步代理。
• 本地警報：關鍵警報（模型失敗、磁碟滿、GPU 錯誤）必須在本地觸發——發送電子郵件到本地郵件伺服器、SNMP 陷阱或本地網路上的儀表板警報。當沒有網際網路時，您無法依賴 PagerDuty。

規劃日誌儲存。每天產生 10,000 個推理請求並進行完整請求/響應日誌記錄的中等活躍 AI 系統，每天產生 2 至 5 GB 的日誌。對於 30 天的斷連期，在壓縮之前需要 60 至 150 GB 的日誌儲存。

3. 授權管理

這是許多「本地部署」在斷網環境中失敗的地方。企業 AI 中常用的軟體授權模型：

解決方案：在將任何軟體部署到斷網環境之前，在沒有網際網路存取的情況下測試它，持續時間等於您的最長預期斷連期。不要相信供應商文件——實際測試它。許多聲稱「支援本地部署」的工具從未在沒有連接的情況下進行過測試。

對於 NVIDIA AI Enterprise，斷網部署特別需要本地委託授權伺服器（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 自動解決這些問題。在斷網環境中，每個依賴項都必須預先暫存。遺漏一個，您的部署就會因為神秘的匯入錯誤而失敗。

解決方案：所有依賴項都內建的容器化部署。在連網環境中建置容器映像檔，驗證它們可以工作，然後將映像檔（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 作為參考

Microsoft 的 Foundry Local（2025 年發布）值得作為斷網 AI 操作的參考實現來研究。它為在 Windows 和 Linux 設備上運行小型語言模型（SLM）提供本地運行時，在推理時不依賴雲端。

Foundry Local 中適用於任何斷網 AI 設置的關鍵架構決策：

• 模型下載一次並本地緩存。 初始下載後，推理不需要網際網路。這是正確的模式——但這意味著您需要一個在完全斷網環境中進行初始傳輸的過程。
• 本地 API 相容性。 Foundry Local 公開與 OpenAI 相容的 API，因此為雲端 AI 編寫的應用程式可以通過更改端點 URL 切換到本地推理。這對可移植性很重要。
• 無遙測要求。 運行時無需向 Microsoft 發送使用資料即可操作。這是斷網操作的最低要求，但在商業 AI 工具中令人驚訝地不常見。

Foundry Local 針對開發和邊緣場景，而非企業級斷網部署。對於更大規模的斷網操作，您需要上述的叢集模式。但設計原則——本地優先、無運行時依賴、API 相容性——是正確的基礎。

「拔掉網路線」測試

在將任何工具部署到斷網環境之前，執行此測試：

1. 在有網際網路存取的乾淨機器上安裝軟體
2. 完成初始設置（模型下載、授權啟動、配置）
3. 從所有網路斷開機器（禁用 Wi-Fi、拔掉網路線）
4. 等待 48 小時
5. 嘗試使用軟體的每個功能

您會發現：

• 授權檢查失敗：在啟動時或定期驗證其授權的軟體將停止運作。有些有寬限期（7 至 90 天）；有些立即失敗。
• 模型下載嘗試：延遲加載模型（在第一次使用時而非安裝時下載）的工具，在模型未本地緩存時將失敗。
• 更新檢查掛起：在啟動時檢查更新的軟體，可能在繼續之前等待超時 30 至 60 秒。在某些情況下，它根本不會繼續。
• 遙測失敗：發送使用遙測的工具，如果遙測端點不可達且錯誤處理不佳，可能會記錄錯誤、變慢或失敗。
• 資產缺失：從 CDN 加載字型、圖示或 JavaScript 的基於 Web 的 UI 將渲染不正確或無法加載。

記錄每個失敗。對於每個失敗，確定：是否有配置選項可以禁用網路依賴？是否有解決方法？或者工具根本與斷網操作不相容？

乾淨通過此測試的工具：

• Ollama：模型下載後完全本地。無回報。
• llama.cpp：已編譯的二進位文件，本地模型文件，零網路依賴。
• 開源模型（GGUF 格式）：磁碟上的文件。無 DRM，無啟動。
• vLLM（具有本地模型）：一旦模型可用，完全本地運行。

常見失敗的工具：

• 大多數商業 AI 平台：授權驗證中斷。
• 託管的 Kubernetes AI 服務：假設有網際網路用於容器拉取和 DNS。
• 具有雲端層的向量資料庫：某些預設為雲端儲存後端。
• 通過 pip 安裝的 Python 工具：如果依賴項未預先安裝，它們無法離線解析。

斷網環境中的資料準備

資料準備挑戰在斷網環境中被放大。連網企業至少可以使用基於雲端的標注工具、將文件發送到 OCR 服務，或使用 SaaS 資料清理平台（需要適當的安全批准）。斷網組織無法做到。

資料準備管道的每個步驟都必須在本地運行：

• 文件擷取：OCR、PDF 解析、表格提取——全部本地。不對 Google Vision、AWS Textract 或 Azure Document Intelligence 進行 API 呼叫。
• 資料清理：去重、正規化、錯誤修正——全部本地計算。
• 標注和標記：領域專家必須能夠使用不需要網際網路存取的工具在本地網路上標記資料。
• 合成資料生成：如果使用 AI 輔助增強，生成模型必須在本地運行。
• 匯出：輸出訓練就緒的資料集（JSONL、分塊文字、COCO/YOLO）必須在沒有網路依賴的情況下工作。

分散的工具方法（Docling 用於解析 + Label Studio 用於標注 + Cleanlab 用於品質 + 自定義腳本用於匯出）在斷網環境中變得更加有問題。每個工具都有自己的依賴樹、自己的更新週期和自己的潛在網路依賴。在斷網環境中管理五個獨立工具，成倍增加了整合和維護負擔。

具有捆綁依賴項的原生桌面應用程式在這裡具有固有優勢。它們像任何其他應用程式一樣安裝，攜帶自己的依賴項，不需要 Docker、Kubernetes 或任何網路基礎設施即可運作。

斷網 AI 的操作手冊

部署前清單

• 所有軟體通過 48 小時網路線測試
• 所有模型權重已預先下載並本地儲存
• 本地模型登錄已配置並填充
• 授權伺服器（如果需要）已部署在本地網路上
• 所有容器映像檔已緩存在本地登錄中
• 本地監控和警報已配置
• 日誌輪換和儲存已針對最長斷連期進行調整
• 備份和恢復程序已在沒有網際網路的情況下進行測試
• 領域專家已接受本地工具培訓（他們無法上網搜尋幫助）
• 實體或數位操作手冊涵蓋常見失敗模式和修復方法

斷網操作期間

• 監控本地磁碟空間——日誌和推理緩存持續增長
• 在本地追蹤模型效能指標；監視漂移指標
• 維護任何本地配置修改的變更日誌
• 在連接恢復時保持模型更新請求的佇列
• 對照生產模型定期運行驗證基準測試

重新連接和同步

• 首先將日誌和指標同步到集中監控（保留操作可見性）
• 拉取模型更新和安全修補程式
• 推送任何本地微調的模型或資料集以供集中審查
• 更新 RAG 系統的知識庫
• 驗證授權狀態並在需要時續期

規劃斷網 AI：關鍵決策

斷網 AI 操作並不比連網操作更難——它們只是不同。工作從運行時操作（監控、擴展）轉移到部署前準備（暫存、測試、文件記錄）。投入徹底部署前準備的組織發現，斷網操作實際上比連網操作更可預測，因為有更少的活動部件，沒有可以在沒有通知的情況下發生變化的外部依賴。

今天存在的工具和模型能夠以零網際網路連接運行功能強大的 AI 系統。挑戰在於將它們組裝成一個堆疊，其中每個組件——從推理到資料準備到監控——真正離線工作。從網路線測試開始，然後從那裡建立。