云端基础：云计算核心概念、主流云平台与云上ML服务

2.1 云计算的核心概念：从物理机到弹性资源池

在讨论云端ML工作流之前，必须先建立对云计算本质的准确认知。云计算并非“把服务器放到别人机房”这么简单，其核心是资源池化与按需分配。传统自建机房中，CPU、内存、存储和网络是物理绑定的，扩容需要采购、上架、布线，周期以周甚至月计。而云平台通过虚拟化层将物理资源切分为可动态调度的逻辑资源池，用户通过API或控制台在分钟级甚至秒级完成资源创建与释放。

理解云计算需要抓住三个关键属性：

• 按需自助服务：无需人工审批，通过Web控制台或CLI即可自助开通资源。
• 广泛网络接入：所有能力通过标准网络协议（HTTPS/REST）暴露，支持任意终端访问。
• 可计量服务：资源使用量（vCPU小时、GB-秒、请求次数）被精确记录，按量付费。

部署模型上，公有云（多租户共享）、私有云（独享VPC）、混合云（数据本地化+计算弹性）是三种主流选择。对于ML工作流，混合云策略尤为常见——训练数据驻留在本地合规区，而GPU训练集群则从公有云弹性获取。

2.2 三大主流云平台：AWS、Azure、GCP的差异化定位

当前ML工作流自动化领域，AWS、Microsoft Azure、Google Cloud Platform（GCP）构成第一梯队。三者均提供完整的ML服务链，但设计哲学和优势领域有明显差异。

选择云平台时，不应仅看ML服务本身，还需考虑组织现有技术栈、数据合规要求、成本模型和运维团队熟悉度。例如，一家深度使用Office 365和Active Directory的企业，迁移到Azure的IAM集成成本远低于AWS；而一家以Kubernetes为基础设施标准的团队，GCP的GKE（Google Kubernetes Engine）体验最为顺滑。

2.3 云上ML服务全景：从托管Notebook到全流程Pipeline

云上ML服务可按照管理层次分为三类，理解这个分层对设计自动化工作流至关重要：

1. 基础设施层（IaaS）：直接提供GPU虚拟机（如AWS EC2 P4d实例、Azure ND系列、GCP A2系列）。用户自己管理驱动、容器运行时和ML框架。灵活性最高，但运维负担重。
2. 平台层（PaaS）：托管ML平台（如SageMaker、Azure ML、Vertex AI）。平台自动处理基础设施、环境配置、模型部署和自动扩缩容。用户只需关注训练脚本和模型本身。
3. 服务层（SaaS）：预训练API（如AWS Rekognition、Azure Computer Vision、GCP Vision API）。直接调用REST接口获取推理结果，无需训练自己的模型。

对于ML工作流自动化部署与监控这一课程主题，PaaS层是核心战场。以AWS SageMaker为例，其Pipeline组件允许用户用Python SDK定义完整的ML流程：

from sagemaker.workflow.pipeline import Pipeline
from sagemaker.workflow.steps import TrainingStep, CreateModelStep
from sagemaker.workflow.model_step import ModelStep

# 定义训练步骤
train_step = TrainingStep(
    name="XGBoost-Train",
    estimator=estimator,
    inputs=TrainingInput(s3_data="s3://bucket/train.csv")
)

# 定义模型创建步骤
create_model_step = ModelStep(
    name="Create-Model",
    model=Model(
        image_uri=estimator.training_image_uri(),
        model_data=train_step.properties.ModelArtifacts.S3ModelArtifacts
    )
)

# 组装Pipeline
pipeline = Pipeline(
    name="ML-Workflow-Pipeline",
    steps=[train_step, create_model_step]
)
pipeline.upsert(role_arn=role_arn)
pipeline.start()

这段代码展示了云上ML工作流自动化的核心范式：用代码定义基础设施和流程，而非手动点击控制台。Pipeline的每个步骤都有独立的日志、监控指标和重试策略，这为后续章节的监控告警奠定了基础。

2.4 案例：某电商推荐系统的多云ML架构

为帮助理解，我们看一个真实场景。某跨境电商公司需要构建实时商品推荐系统，其架构决策如下：

• 数据存储：用户行为日志存储在AWS S3（成本低、生命周期管理灵活），每日约5TB新增数据。
• 特征工程：使用GCP BigQuery进行大规模SQL特征计算（利用其Serverless和列式存储优势），结果回传S3。
• 模型训练：在Azure ML上使用ND96asr_v4（A100 GPU）集群训练深度排序模型，利用Azure ML的HyperDrive进行超参搜索。
• 模型部署：最终模型导出为ONNX格式，部署到AWS SageMaker Endpoint，利用其多模型端点（Multi-Model Endpoint）降低推理成本。
• 工作流编排：使用AWS Step Functions统一调度跨云任务，通过Lambda函数触发各云平台的API。

2.5 常见误区与复盘：云端ML部署的五个坑

根据大量企业上云实践，以下误区最具代表性：

误区二：GPU实例“用完不释放”。按需GPU实例价格约为每小时$3-10美元，一个p3.16xlarge实例闲置一个月成本超过$5000。必须设置自动关机策略（如CloudWatch定时事件）或使用Spot实例（可节省60-70%成本）。

误区三：将所有数据放在一个Region。某欧洲客户将数据存储在美国东部（us-east-1），导致每次训练都跨大西洋传输，延迟增加150ms且产生额外费用。应遵循数据驻留与计算就近原则。

误区四：忽略IAM权限最小化。为图方便直接给ML服务附加“AdministratorAccess”策略，一旦训练脚本被注入恶意代码，攻击者即可控制整个云账号。应使用AWS IAM Role + 条件键限制资源访问范围。

误区五：盲目追求“全托管”。SageMaker等托管服务虽然省心，但抽象层也意味着排障困难。当训练任务异常退出时，平台日志可能不包含底层CUDA错误信息。建议在开发阶段使用IaaS虚拟机调试，稳定后再迁移到托管平台。

2.6 云端ML服务选型决策清单

在进入后续章节前，请对照以下清单评估你的项目需求：