如何将AI工作负载从云端迁移到本地：企业手册

把 AI 工作负载从云端搬到本地，是一连串审慎的动作，每一步都有各自的风险画像和回报。想一次性全搬完的组织，也就是所谓「大爆炸」式迁移，结局往往是工期延误、预算超支、生产系统被打断。按阶段推进的组织，迁移速度反而更快，运营风险也更低。

本手册讲清楚三件事：云端到本地的 AI 迁移分成哪六个阶段；用什么样的工作负载分类框架，来决定哪些负载该搬、按什么先后顺序搬；以及连经验丰富的基础设施团队也照样会踩的那几个坑。

开始之前：迁移前检查清单

在投入资源之前，先把三个问题答清楚。

1. 你到底花了多少钱？ 多数组织把自己的云端 AI 支出低估了 30% 到 50%，因为这笔钱分散在计算、存储、出网流量、托管服务和监控等好几个账户里。把 6 个月的账单数据拉出来，逐条给每一项与 AI 相关的开销归类。周边服务同样要算进去：向量数据库、日志管道、密钥管理服务，还有推理端点前面那台负载均衡器。

2. 你的约束条件是什么？ 数据主权要求、延迟 SLA、合规规定、网络架构限制、机房容量，这些都会决定迁移方案的形状。选硬件之前先把它们写下来。

3. 你的时间线是什么？ 硬件采购要 4 到 12 周，具体看 GPU 的供货情况。机房准备（供电、制冷、机柜空间）可能更久。如果你要求 30 天内完成迁移，那你已经晚了。从决策到承接生产流量，第一阶段迁移的现实时间线是 8 到 16 周。

阶段 1：审计当前的云端 AI 工作负载与成本

审计阶段产出两份交付物：一份完整的工作负载清单，一份成本归因模型。

工作负载清单

对每一个跑在云上的 AI 工作负载，记录以下内容：

• 负载类型：推理、微调、训练、数据准备、嵌入向量生成、评估
• 计算画像：GPU 型号、实例数量、平均利用率、峰值利用率
• 数据特征：输入数据量、输出数据量、数据敏感度分级、存储占用
• 性能要求：p50/p95/p99 延迟、吞吐（每秒请求数或每秒 token 数）、可用性 SLA
• 依赖项：所消耗的其他云服务（存储、数据库、队列、监控）
• 使用模式：持续运行、定时批处理、按需突发

成本归因

把云端支出的每一块钱都对应到具体的工作负载上。这件事做起来比听上去难，因为云厂商的账单是把各项服务的费用汇总在一起出的。如果你已经打好了成本分摊标签，就直接用标签来拆；如果没有，就从资源用量指标反推出归属关系。

目标是得到这样一张表：

后面每一个决策都建立在这张表上。没有它，你只是在猜。

阶段 2：工作负载分类

并非每个工作负载都该搬到本地。这套分类框架从四个维度逐一给每个负载打分：

给每个工作负载打分。总分 16 到 20 分的，是立刻迁移的有力候选。10 到 14 分的，列入第二批迁移。低于 10 分的，留在云上。

产出是一份排好优先级的迁移队列。

第一梯队（最先迁移）：

• 处理敏感数据的数据准备管道
• 有延迟要求的高利用率推理负载
• 负有数据主权合规义务的负载

第二梯队（其次迁移）：

• 基于专有数据的微调负载
• 面向内部知识库的嵌入向量生成
• 成本持续攀升的批处理

第三梯队（以后再评估）：

• 实验性和研发类负载
• 低频批处理作业
• 需求模式难以预测的负载

阶段 3：搭建本地基础设施

把工作负载的各项需求都记录清楚之后，就可以着手确定硬件规格了。

选型参考

• 仅推理（单个 7B 到 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 operator 的 Kubernetes，或裸金属管理
• 监控：Prometheus/Grafana 或同类方案，覆盖 GPU 利用率、温度、显存
• 安全：网络分段、访问控制、审计日志

并行推进：软件栈

硬件还在采购的时候，就把软件栈准备好：

• 模型服务框架的容器镜像（vLLM、TGI、Triton）
• 数据准备管道的容器
• 微调自动化脚本
• 模型评估框架
• 模型部署用的 CI/CD 管道
• 监控与告警配置

这样并行推进，硬件到货后几天内就能把工作负载部署上去，省掉「等服务器上架完了再开始装软件」的那段时间。

阶段 4：先迁移数据准备

对多数企业来说，数据准备是最合适的第一个迁移对象，理由有三条。

它处理的是最敏感的数据。 合同、病历、财务申报、客户往来通信，这些原始企业文档都要先流经数据准备管道，然后才轮到别的环节。如果数据主权是你这次迁移的动因，风险最高的地方就在这里。

按单位数据量算，它最耗成本。 数据准备对每份文档都要走多个处理步骤：抽取、清洗、分块、分类、格式化。每一步都吃计算资源。按云端价格，处理大规模文档语料非常贵；放在本地，它就是一笔固定成本。

它的生产依赖最少。 数据准备管道通常以批处理方式运行，不承接线上流量。迁移过程中出了状况，用户侧感知不到。过渡期还可以让云端和本地两条管道并行跑。

数据准备的迁移步骤

1. 把云端的数据准备管道容器化，如果还没做的话。每个处理步骤都应该是可复现的容器。
2. 在本地部署这条管道，用同一套容器镜像。
3. 两条管道并行跑同一批输入数据，比对输出，验证结果等价。
4. 验证数据质量：确认本地输出与云端输出的差异落在可接受范围内。
5. 切换：把新数据路由到本地管道。云端管道再保留 2 到 4 周作为回退方案。
6. 下线云端管道，前提是本地运行已确认稳定。

预期时间线：从基础设施就绪到承接生产流量，2 到 4 周。

阶段 5：迁移推理工作负载

推理是你向用户或下游系统交付预测结果的那一环。它承接的是实打实的生产流量，所以迁移的时候要格外小心。

蓝绿方式

让本地推理与云端推理并行运行，用负载均衡器或 API 网关来分流：

1. 在本地部署模型，验证它的输出与云端版本一致。
2. 把 5% 的流量导到本地，观察延迟、错误率和输出质量。
3. 提到 25%，再到 50%、75%，每一步都持续观察。
4. 指标稳定后，把 100% 的流量切到本地。
5. 云端推理继续保留 2 到 4 周作为热备。
6. 过了稳定观察期，下线云端推理。

切换期间要盯的指标

• 延迟：p50、p95、p99。本地延迟应当等于或优于云端。
• 吞吐：峰值时的每秒请求数。确认本地硬件扛得住你的负载。
• 错误率：5xx 错误或超时一旦上升，说明容量有问题。
• 输出质量：对本地输出跑评估基准，抓出模型服务层面的差异。
• GPU 利用率：持续高于 90%，说明你需要加容量。

阶段 6：评估训练工作负载的部署位置

训练放在最后评估，因为它是最吃算力、发生频次也最低的一类负载。不少企业把其他负载都迁完之后，仍然选择把大规模训练继续留在云上。

这个决定取决于你的训练节奏：

微调对算力的消耗比完整训练轻得多，所以只要你已经有一批推理硬件在跑，把微调放到本地几乎总是划算的。GPU 就在那里，数据也在那里。挑推理集群的低峰时段跑一个微调作业，从边际成本上看基本等于免费。

常见陷阱

陷阱 1：低估数据引力

数据引力指的是应用和服务倾向于向数据所在的位置聚拢。如果你的 AI 模型在云上，而数据在本地，你就得付钱把数据传上云；反过来，模型在本地而一部分数据还留在云上，你就得付钱再把数据传回来。

解法是先把数据准备迁过去（阶段 4），这样等推理搬过来的时候，处理好的数据已经躺在本地了。

陷阱 2：没算上运维人力

本地基础设施需要人盯着。GPU 驱动要更新，硬件会坏，容器要打补丁。如果团队没有本地基础设施经验，请在硬件到货之前就把培训或招聘的预算留出来。

经验值：稳态运行下，每 4 到 8 台 GPU 服务器配 1 名基础设施工程师。迁移期间还要临时增派人手。

陷阱 3：一次性全搬

「大爆炸」式迁移，周五关掉云端、周一本地上线，失败的次数远多于成功。每个阶段在过渡期都应该让云端和本地并行运行。重叠期多花的那点云端费用，是给停机风险买的保险。

陷阱 4：硬件到货才想起软件栈

硬件采购要花好几周。用这段时间把软件栈准备好，在小规格硬件上跑测试，把部署流程写成文档。等服务器上架了才开始装软件的团队，工期通常要多出 2 到 4 周。

陷阱 5：把迁移当成一次性项目

迁移是一项要长期维持的能力，而不是一锤子买卖。以后会有新模型要部署，会有新数据源要接入，评估管道也要跟着更新。从第一天起就把自动化建起来：把本地 AI 基础设施当成任何一套生产系统来对待，配齐 CI/CD、监控和运行手册。

时间线汇总

从做出决策到第一个生产工作负载真正落到本地，总时间线是 8 到 16 周，前提是硬件拿得到。硬件采购那段时间有没有并行把软件准备好，就是 8 周迁移和 16 周迁移之间的分水岭。

真正的目标是把每一个工作负载都放进最合适的环境里：在那里它跑得最好、花的钱最少，同时还满足你的合规要求。对 2026 年的多数企业而言，这意味着适合放到本地的工作负载，比现在实际放在那里的要多得多。