如何將 AI 工作負載從雲端遷移到本地端：企業手冊

將 AI 工作負載從雲端遷移到本地端不是一個單一專案。這是一系列有意識的行動，每個都有其自己的風險特徵和回報。試圖一次移動所有事情的組織——「大爆炸」方式——往往錯過時間表、超出預算並破壞生產系統。遵循分階段方法的組織以更少的運營風險更快地完成工作負載遷移。

本手冊涵蓋雲端到本地端 AI 遷移的六個階段、決定什麼移動以及以什麼順序移動的工作負載分類框架，以及即使有經驗的基礎設施團隊也會遇到的陷阱。

在開始之前：遷移前清單

在投入資源之前，你需要回答三個問題：

1. 你實際上在花多少錢？ 大多數組織低估其雲端 AI 費用 30-50%，因為費用分散在計算、儲存、出站、託管服務和監控帳戶中。提取 6 個月的帳單資料，並對每個與 AI 相關的行項目進行分類。包括輔助服務——向量資料庫、記錄管道、機密管理器、你的推理端點前面的負載均衡器。

2. 你的限制是什麼？ 資料主權要求、延遲 SLA、合規要求、網路架構限制和設施容量都影響遷移計劃。在選擇硬體之前記錄這些。

3. 你的時間表是什麼？ 硬體採購需要 4-12 週，取決於 GPU 可用性。設施準備（電力、冷卻、機架空間）可能需要更長時間。如果你需要在 30 天內完成工作負載遷移，你已經遲了。第一階段遷移的現實時間表是從決定到生產流量 8-16 週。

第一階段：審計當前雲端 AI 工作負載和費用

審計階段產生兩個可交付成果：完整的工作負載清單和費用歸因模型。

工作負載清單

對於在雲端中執行的每個 AI 工作負載，記錄：

• 工作負載類型：推理、微調、訓練、資料準備、嵌入產生、評估
• 計算特徵：GPU 類型、實例數量、平均利用率、峰值利用率
• 資料特性：輸入資料量、輸出資料量、資料敏感性分類、儲存佔用
• 效能要求：延遲 p50/p95/p99、吞吐量（每秒請求數或每秒 token 數）、可用性 SLA
• 依賴關係：消耗的其他雲端服務（儲存、資料庫、佇列、監控）
• 使用模式：連續、排程批次、按需突發

費用歸因

將每一分雲端支出映射到特定的工作負載。這比聽起來更難，因為雲端計費跨服務聚合費用。如果你有費用分配標籤，使用它們。如果沒有，從資源使用指標反向推導歸因。

目標是一個看起來像這樣的表格：

這個表格驅動每個後續決策。沒有它，你只是在猜測。

第二階段：分類工作負載

並非每個工作負載都應該移動。分類框架在四個維度上評估每個工作負載：

對每個工作負載打分。任何得分 16-20 的都是立即遷移的強力候選。10-15 分是第二階段遷移的候選。低於 10 分，保留在雲端。

輸出是一個優先遷移佇列：

第一層（首先移動）：

• 處理敏感資料的資料準備管道
• 有延遲要求的高利用率推理工作負載
• 有資料主權合規義務的工作負載

第二層（第二移動）：

• 在專有資料上微調工作負載
• 內部知識庫的嵌入產生
• 費用不斷增長的批次處理

第三層（稍後評估）：

• 實驗和研發工作負載
• 不頻繁的批次作業
• 需求模式不可預測的工作負載

第三階段：構建本地端基礎設施

記錄了你的工作負載要求後，你可以規格化硬體。

大小指南

• 僅推理（一個 7-70B 模型）：1 台伺服器，4-8 個 GPU（L40S 或 A100）
• 推理 + 微調（一個模型，每週微調）：1-2 台伺服器，8 個 GPU（A100 或 H100）
• 多個模型 + 資料準備：2-4 台伺服器，混合 GPU 層級
• 完整管道（資料準備、訓練、推理、評估）：4 台以上伺服器，專用角色

基礎設施清單

• GPU 伺服器已訂購並確認交貨時間表
• 分配了足夠電力的機架空間（GPU 伺服器每機架需 30-50kW）
• 驗證了冷卻容量（GPU 伺服器產生大量熱量）
• 網路基礎設施：伺服器之間最少 25GbE，多節點訓練需 100GbE
• 儲存：活躍工作負載的高速 NVMe，資料集的 NAS/SAN
• 作業系統和驅動程式：CUDA 工具包，容器執行時間（Docker/Podman）
• 編排：帶 GPU 運算符的 Kubernetes，或裸機管理
• 監控：Prometheus/Grafana 或同等工具用於 GPU 利用率、溫度、記憶體
• 安全：網路分段、存取控制、稽核記錄

平行軌道：軟體堆疊

在硬體採購期間，準備軟體堆疊：

• 你的模型服務框架容器映像（vLLM、TGI、Triton）
• 資料準備管道容器
• 微調自動化腳本
• 模型評估框架
• 用於模型部署的 CI/CD 管道
• 監控和警報配置

這個平行工作意味著你可以在硬體到達後幾天內部署工作負載，而不是在硬體安裝後才開始軟體設置。

第四階段：首先遷移資料準備

對於大多數企業，資料準備是正確的第一次遷移，原因如下：

它處理最敏感的資料。 原始企業文件——合約、醫療記錄、財務申報、客戶通訊——在任何其他事情之前流經資料準備管道。如果資料主權是你遷移的驅動因素，這是風險最高的地方。

每單位資料的費用最高。 資料準備涉及每個文件的多個處理步驟：提取、清理、分塊、分類、格式化。每個步驟消耗計算。按雲端價格準備大型文件語料庫很昂貴。在本地端，它是固定費用。

它的生產依賴關係最少。 資料準備管道通常以批次模式執行，而非服務實時流量。如果在遷移期間出現問題，不會有面向使用者的影響。你可以在過渡期間平行執行雲端和本地端管道。

資料準備的遷移步驟

1. 容器化你的雲端資料準備管道（如果還沒有）。每個處理步驟都應該是可重現的容器。
2. 在本地端部署管道，使用相同的容器映像。
3. 在相同的輸入資料上平行執行兩個管道。比較輸出以驗證等效性。
4. 驗證資料品質——檢查本地端輸出在可接受的容差內與雲端輸出匹配。
5. 切換——將新資料路由到本地端管道。將雲端管道作為後備保留 2-4 週。
6. 停用雲端管道，一旦你確認了穩定的本地端操作。

預計時間表：從基礎設施可用性到生產流量 2-4 週。

第五階段：移動推理工作負載

推理是你向使用者或下游系統服務預測的地方。它是生產流量，所以遷移需要更多謹慎。

藍綠方法

平行執行本地端推理和雲端推理。使用負載均衡器或 API 閘道路由流量：

1. 在本地端部署模型並驗證它產生與雲端版本相同的輸出。
2. 將 5% 的流量路由到本地端，監控延遲、錯誤率和輸出品質。
3. 增加到 25%，然後 50%，然後 75%，在每一步監控。
4. 將 100% 路由到本地端，一旦指標穩定。
5. 將雲端推理作為熱備援保留 2-4 週。
6. 停用雲端推理，在穩定視窗之後。

在切換期間監控什麼

• 延遲：p50、p95、p99。本地端延遲應該等於或優於雲端。
• 吞吐量：峰值時每秒請求數。確保本地端硬體處理你的負載。
• 錯誤率：5xx 錯誤或超時的任何增加表明容量問題。
• 輸出品質：在本地端輸出上執行評估基準以捕捉模型服務差異。
• GPU 利用率：持續超過 90% 的利用率意味著你需要更多容量。

第六階段：評估訓練工作負載放置

訓練是最後評估的工作負載，因為它是計算最密集且最不頻繁的。即使在遷移其他一切之後，許多企業仍然將大規模訓練保留在雲端。

決定取決於你的訓練節奏：

如果你已經在執行推理硬體，微調（比完整訓練計算密集度更低）幾乎總是在本地端有意義。GPU 在那裡。資料在那裡。在非高峰時間在你的推理集群上執行微調任務在邊際上幾乎是免費的。

常見陷阱

陷阱 1：低估資料重力

資料重力是應用程式和服務圍繞資料聚集的傾向。如果你的 AI 模型在雲端而你的資料在本地端，你在為將資料移動到雲端付費。如果你的模型在本地端而你的某些資料仍在雲端，你在為將資料移回付費。

解決方案：首先遷移資料準備（第四階段），這樣當推理移動時，你處理的資料已經在本地端了。

陷阱 2：沒有考慮運維人員配置

本地端基礎設施需要人工關注。GPU 驅動程式需要更新。硬體會失效。容器需要修補。如果你的團隊沒有本地端基礎設施經驗，在硬體到達之前預算用於培訓或招聘。

經驗法則：穩態運營每 4-8 台 GPU 伺服器需要 1 名基礎設施工程師。在遷移期間，你暫時需要更多人手。

陷阱 3：一次移動所有事情

「大爆炸」遷移——週五關閉雲端，週一在本地端上線——失敗的頻率比成功更高。每個階段都應該在過渡期間平行執行雲端和本地端。重疊期間的額外雲端費用是防止停機的保險。

陷阱 4：在硬體到達之前忽視軟體堆疊

硬體採購需要幾週。利用這段時間準備軟體堆疊、在較小的硬體上執行測試並記錄部署程序。等到伺服器架好才開始軟體設置的團隊，會在其時間表上再增加 2-4 週。

陷阱 5：將遷移視為一次性專案

遷移是一種持續能力，而非一次性專案。新模型需要部署。新資料來源需要整合。評估管道需要更新。從一開始就構建自動化——像對待任何生產系統一樣對待你的本地端 AI 基礎設施，具有 CI/CD、監控和運行手冊。

時間表摘要

從決定到第一個生產工作負載在本地端的總時間表：8-16 週，假設硬體可用。在硬體採購期間的平行軟體準備，是 8 週遷移和 16 週遷移的區別。

目標不是完全消除雲端 AI。而是將每個工作負載放在它表現最好、費用最低且滿足你的合規要求的環境中。對於 2026 年的大多數企業，這意味著比今天更多的工作負載在本地端。