课程十二：DevOps

课程十二：AI 平台架构演进案例

目标：人工智能正在重塑各行各业，而构建高效、可扩展的 AI 平台是释放 AI 生产力的关键。本课程将以一个典型的 AI 平台的演进过程为例，带你掌握数据管理与特征工程、分布式训练、模型服务化、MLOps 全流程、以及大模型专项架构等核心能力，理解从算法实验到规模化生产的架构挑战与实践。

---

阶段 0：蛮荒时代（数据科学家的本地实验：Jupyter Notebook）

场景描述

• 工作模式：数据科学家在自己的笔记本电脑或单台工作站上，使用 Jupyter Notebook 进行算法探索和模型训练。
• 数据处理：直接读取本地文件（CSV, Parquet）或连接数据库获取小规模数据。
• 环境管理：依赖 conda 或 virtualenv 管理本地 Python 环境。
• 模型共享：训练好的模型以序列化文件（如 .pkl, .h5）的形式，通过邮件、网盘等方式共享。

架构示意：

graph LR
    DS["Data Scientist"];
    Laptop["笔记本电脑/工作站"];
    LocalData["本地数据文件"];
    Jupyter["Jupyter Notebook"];
    ModelFile["模型文件 .pkl"];

    DS -- "本地操作" --> Laptop;
    Laptop -- "加载" --> LocalData;
    Laptop -- "运行" --> Jupyter;
    Jupyter -- "输出" --> ModelFile;

此刻的痛点： - "在我机器上能跑"综合症：环境不一致导致实验结果难以复现。 - 资源瓶颈：本地计算资源（CPU, GPU, 内存）有限，无法处理大规模数据或训练复杂模型。 - 协作困难：模型、代码、数据管理混乱，团队协作效率低下。 - 无法部署上线：实验结果难以转化为生产可用的服务。

---

阶段 1：集中计算资源（GPU 服务器集群 + 共享存储）

挑战浮现

• 数据量增大（如超过 10GB），本地内存不足。
• 模型复杂度提升，需要强大的 GPU 资源进行训练加速。
• 多人协作需要统一的开发环境和数据存储。

❓ 架构师的思考时刻：如何为数据科学家提供更强大的计算资源和协作环境？

（本地不行就用服务器。GPU 服务器怎么共享？数据放哪里方便大家用？环境怎么统一？）

✅ 演进方向：构建 GPU 资源池 + 共享存储 + 环境容器化

1. 集中 GPU 资源池：
   • 采购或租用一批配备高性能 GPU 的服务器。
   • 使用作业调度系统（如 Slurm, PBS）来管理和调度 GPU 资源，允许多个用户共享服务器。
2. 共享存储：
   • 搭建网络文件系统 (NFS) 或使用分布式文件系统 (如 HDFS, Ceph)，用于存储训练数据、代码和模型，方便所有用户和服务器访问。
3. 环境容器化 (Docker)：
   • 使用 Docker 将包含所需库（TensorFlow, PyTorch, Scikit-learn 等）和驱动的训练环境打包成标准镜像。
   • 数据科学家在提交训练任务时，指定使用哪个 Docker 镜像运行，保证环境的一致性和可复现性。

架构调整（引入计算集群与共享环境）：

graph TD
    DataScientist(数据科学家) -- 提交 Job --> Scheduler(作业调度系统 Slurm/PBS);
    Scheduler -- 分配资源 & 运行 --> GPUNode1(GPU 服务器 1 - Docker Container);
    Scheduler -- 分配资源 & 运行 --> GPUNode2(GPU 服务器 2 - Docker Container);
    Scheduler -- 分配资源 & 运行 --> GPUNodeN(GPU 服务器 N - Docker Container);
    subgraph "共享资源"
        SharedStorage(共享存储 NFS/HDFS);
        DockerRegistry(Docker 镜像仓库);
    end
    GPUNode1 -- 读写数据/模型 --> SharedStorage;
    GPUNode2 -- 读写数据/模型 --> SharedStorage;
    GPUNodeN -- 读写数据/模型 --> SharedStorage;
    GPUNode1 -- 拉取镜像 --> DockerRegistry;
    GPUNode2 -- 拉取镜像 --> DockerRegistry;
    GPUNodeN -- 拉取镜像 --> DockerRegistry;

解决了：计算资源不足和基本环境一致性问题，支持了更大规模的模型训练。 仍存在：分布式训练能力缺失（单机多卡或单节点训练），特征工程重复建设，模型部署上线困难。

---

阶段 2：模型大了，单卡不够 → 分布式训练框架

挑战再升级：训练效率与模型规模瓶颈

• 模型规模（参数量）持续增大（如 BERT, GPT 等），单张 GPU 显存无法容纳，或者单节点训练时间过长（数天甚至数周）。
• 需要利用多台机器、多张 GPU 卡并行训练来加速训练过程和支持更大模型。

❓ 架构师的思考时刻：如何让多台机器、多张 GPU 协同训练一个模型？

（怎么把数据和计算分发下去？节点间怎么同步模型参数？有哪些成熟的分布式训练框架？）

✅ 演进方向：引入分布式训练框架

根据并行策略的不同，主流框架包括：

1. 数据并行 (Data Parallelism)：最常用。
   • 原理：将训练数据分成多份，每个 GPU 处理一份数据，计算梯度；然后通过通信（如 All-Reduce）聚合所有 GPU 的梯度，更新全局模型参数；再将更新后的参数广播给所有 GPU。
   • 框架：Horovod (Uber 开源，跨框架支持好), PyTorch DistributedDataParallel (DDP) (PyTorch 原生，易用性高), TensorFlow MirroredStrategy/MultiWorkerMirroredStrategy。
   • 适用：模型可以放在单卡显存中，但需要加速训练的场景。
2. 模型并行 (Model Parallelism)：
   • 原理：将模型本身的不同部分（如不同的层）切分到不同的 GPU 上。数据流经不同的 GPU 完成前向和后向计算。
   • 挑战：切分策略复杂，通信开销大。
   • 框架：通常需要手动实现或使用特定库（如 PyTorch Pipeline Parallelism, Megatron-LM）。
   • 适用：模型巨大，单卡显存无法容纳。
3. 参数服务器 (Parameter Server - PS) 架构：
   • 原理：将模型参数存储在专门的参数服务器上。训练节点 (Worker) 从参数服务器拉取最新参数，计算梯度，再将梯度推送给参数服务器进行更新。
   • 框架：TensorFlow ParameterServerStrategy。
   • 适用：超大规模稀疏特征模型（如推荐、广告），通信可以异步化。
4. 混合并行：结合数据并行、模型并行、流水线并行等多种策略，应对超大模型（如 GPT-3 级别）。如 DeepSpeed (Microsoft)。

优化技巧： * 混合精度训练 (AMP - Automatic Mixed Precision)：使用 FP16（半精度）进行大部分计算，减少显存占用和计算量，同时保持关键部分的 FP32（单精度）以维持精度。 * 梯度累积 (Gradient Accumulation)：在显存有限时，模拟更大的 Batch Size。 * 梯度检查点 (Gradient Checkpointing)：用时间换空间，减少中间激活值的存储。

架构调整（以数据并行 Horovod/DDP 为例）：

graph TD
    Scheduler(作业调度 Slurm/K8s) -- 启动 N 个 Worker 进程 --> Worker1(Worker 1 - Rank 0);
    Scheduler -- 启动 N 个 Worker 进程 --> Worker2(Worker 2 - Rank 1);
    Scheduler -- 启动 N 个 Worker 进程 --> WorkerN(Worker N - Rank N-1);
    subgraph "Worker 内部 (每个 Worker 运行在 GPU 上)"
        DataShard(处理本地数据分片);
        ModelReplica(持有模型副本);
        ComputeGradient(计算本地梯度);
    end
    Worker1 --> ComputeGradient;
    Worker2 --> ComputeGradient;
    WorkerN --> ComputeGradient;
    ComputeGradient -- 本地梯度 --> AllReduce(All-Reduce 通信 NCCL/Gloo);
    AllReduce -- 全局梯度 --> UpdateParams(更新模型参数);
    UpdateParams -- 同步参数 --> Worker1 & Worker2 & WorkerN;
    Worker1 & Worker2 & WorkerN -- 读写 --> SharedStorage;

解决了：训练效率低下和单卡显存瓶颈问题，支持了更大规模模型的训练。 引入新问题：特征工程各自为战，特征复用困难，线上线下特征不一致。

---

阶段 3：特征生产混乱 → 建设特征平台 (Feature Store)

挑战浮现：特征生产的"意大利面条"状态

• 不同的算法团队、不同的模型可能都在重复开发相似的特征，浪费人力。
• 线上预测使用的特征逻辑可能与线下训练时使用的特征逻辑不一致，导致模型效果下降（Train-Serve Skew）。
• 缺乏统一的特征管理、版本控制和监控机制。
• 实时特征的获取和使用困难。

❓ 架构师的思考时刻：如何统一管理特征的生产和使用？如何保证线上线下一致性？如何方便地使用实时特征？

（需要一个中央平台来管理特征。特征怎么定义？怎么存储？怎么版本化？实时特征流怎么接入？）

✅ 演进方向：构建特征平台 (Feature Store)

特征平台旨在解决特征生产和消费过程中的各种问题，提供统一的特征管理和服务能力：

1. 统一特征定义与注册：
   • 提供统一的界面或 SDK，让数据科学家或工程师定义特征（名称、类型、来源、计算逻辑、元数据等）并注册到平台。
2. 离线特征存储与计算：
   • 将历史特征数据存储在离线存储中（如 Hive, Delta Lake, Snowflake）。
   • 提供或集成批处理计算引擎（如 Spark）来批量计算和更新离线特征。
3. 在线特征存储与服务：
   • 将需要在线预测使用的特征（通常是最新值或预计算好的）加载到在线存储中（通常是低延迟的 Redis, DynamoDB, Cassandra 等 KV 存储）。
   • 提供低延迟的在线特征服务 API，供线上模型推理时实时查询特征。
4. 实时特征计算与注入：
   • 集成流处理引擎（如 Flink, Spark Streaming）消费实时事件流 (Kafka)，实时计算特征（如用户最近 N 分钟行为统计），并写入在线特征存储。
5. 特征发现与版本控制：
   • 提供特征目录供用户发现和复用已有特征。
   • 支持特征的版本管理，保证模型训练和推理时使用正确版本的特征。
6. 特征监控：
   • 监控特征数据的分布、质量、漂移情况（如使用 Great Expectations），及时发现数据问题。

开源特征平台方案：Feast, Tecton (商业化)。

架构调整（引入特征平台）：

graph TD
    subgraph "特征生产"
        BatchSource(离线数据源 Hive/DB) --> SparkBatch(Spark 批处理 计算离线特征);
        StreamSource(实时事件流 Kafka) --> FlinkStream(Flink 流处理 计算实时特征);
        SparkBatch -- 写入 --> OfflineStore(离线特征存储 Hive/Delta);
        SparkBatch -- 写入 --> OnlineStore(在线特征存储 Redis/KV);
        FlinkStream -- 写入 --> OnlineStore;
        FeatureRegistry(特征注册/管理中心);
        SparkBatch -- 注册/使用定义 --> FeatureRegistry;
        FlinkStream -- 注册/使用定义 --> FeatureRegistry;
    end
    subgraph "特征消费"
        OfflineStore -- 提供训练数据 --> ModelTraining(模型训练);
        OnlineStore -- 提供在线特征 --> OnlineInference(在线模型推理);
        ModelTraining -- 查询特征定义 --> FeatureRegistry;
        OnlineInference -- 查询特征定义 --> FeatureRegistry;
    end
    subgraph "监控"
        OfflineStore & OnlineStore --> FeatureMonitoring(特征监控 Great Expectations);
    end

解决了：特征重复开发、线上线下不一致的问题，提升了特征工程效率和规范性。 下一步挑战：如何将训练好的模型快速、可靠地部署到生产环境提供服务？

---

阶段 4：模型上线难 → 模型服务化 (Model Serving)

挑战再临：模型部署的效率与稳定性

• 将 Python Notebook 中训练好的模型部署成一个稳定、高性能、可扩展的在线预测服务并非易事。
• 需要处理并发请求、模型版本管理、资源隔离、性能监控等问题。
• 不同的模型（Scikit-learn, TensorFlow, PyTorch, XGBoost 等）需要不同的运行时环境和依赖。

❓ 架构师的思考时刻：如何将各种框架训练的模型打包成标准的、高性能的在线服务？

（直接用 Flask/Django 包装一下？性能扛得住吗？有没有更专业的模型部署方案？怎么做 AB 测试和版本管理？）

✅ 演进方向：采用专业的模型推理服务器或平台

1. 模型格式转换与优化：
   • 将不同框架训练的模型转换为标准的、便于部署的格式（如 ONNX, TensorFlow SavedModel, TorchScript）。
   • 使用推理优化库（如 TensorRT, OpenVINO, ONNX Runtime）对模型进行优化（量化、算子融合等），提升推理速度，降低资源占用。
2. 专用推理服务器：
   • 使用专为模型推理设计的服务器软件，如：
     • NVIDIA Triton Inference Server：支持多种框架（TF, PyTorch, ONNX, TensorRT 等），支持多模型、动态批处理 (Dynamic Batching)、模型编排 (Ensemble)，性能优异。
     • TensorFlow Serving：专注于 TensorFlow 模型部署。
     • TorchServe：专注于 PyTorch 模型部署。
   • 这些服务器通常提供标准的 HTTP/gRPC 接口，易于集成。
3. 基于 Kubernetes 的模型服务平台：
   • 将推理服务器容器化，并部署在 Kubernetes 上。
   • 可以使用 KFServing (现 KServe) 或 Seldon Core 等开源平台，它们在 K8s 之上提供了更高级的模型部署、版本管理、流量切分（Canary/Shadow）、自动扩缩容、可解释性等能力。

架构调整（引入模型服务平台 KServe/Triton on K8s）：

graph TD
    subgraph "模型训练与转换"
        ModelTraining(模型训练) --> ModelRegistry(模型仓库 MLflow/S3);
        ModelRegistry -- 下载模型 --> Optimizer(模型优化 TensorRT/ONNX);
        Optimizer -- 优化后模型 --> OptimizedModelRegistry;
    end
    subgraph "模型部署 (KServe on K8s)"
        KServeController(KServe Controller) -- 监听 CRD --> K8sAPIServer;
        K8sAPIServer -- 创建 --> InferenceService(InferenceService Pod);
        OptimizedModelRegistry -- 加载模型 --> InferenceService;
        subgraph "InferenceService Pod 内部"
            Predictor(预测器 Triton/TFServing/TorchServe);
            Transformer(可选: 特征转换器);
            Agent(KServe Agent);
            Agent -- "提供模型" --> Predictor;
            Transformer <-->|请求| Agent;
            Predictor <-->|请求| Agent;
        end
    end
    subgraph "服务调用"
        ClientApp(客户端应用) --> K8sIngress(K8s Ingress/Istio Gateway);
        K8sIngress -- 路由/流量切分 --> InferenceService;
    end
    %% 监控
    InferenceService -- Metrics --> Prometheus;

解决了：模型部署效率低、性能差、管理难的问题，实现了模型的标准化、高性能服务。 最终挑战：如何将数据处理、特征工程、模型训练、模型部署、监控反馈等环节串联起来，形成自动化、可重复、可靠的机器学习流程？

---

阶段 5：流程自动化 → MLOps 流水线

挑战：端到端流程的效率与可靠性

• 手动执行数据处理、特征工程、模型训练、评估、部署等步骤，效率低下，容易出错，难以跟踪和回溯。
• 需要一套自动化的流程来管理从数据到模型的整个生命周期，实现持续集成、持续交付和持续训练 (CI/CD/CT)。

❓ 架构师的思考时刻：如何将机器学习的各个环节串联成自动化的流水线？

（需要一个工作流引擎吗？怎么管理实验版本？模型效果怎么监控并触发再训练？）

✅ 演进方向：构建 MLOps (Machine Learning Operations) 平台

MLOps 借鉴了 DevOps 的思想，旨在实现机器学习生命周期的自动化和标准化：

1. 数据与特征流水线 (Data & Feature Pipelines)：
   • 使用工作流编排工具（如 Airflow, Kubeflow Pipelines, Metaflow）自动化数据清洗、特征提取、特征验证等步骤。
   • 与特征平台集成。
2. 模型训练流水线 (Model Training Pipelines)：
   • 自动化模型训练、超参数调优、模型评估等过程。
   • 训练过程和结果（模型、指标、参数）需要被记录和版本化。
3. 模型部署流水线 (Model Deployment Pipelines)：
   • 自动化模型的打包、测试、部署（如蓝绿部署、金丝雀发布）到模型服务平台。
4. 实验跟踪与模型注册 (Experiment Tracking & Model Registry)：
   • 使用工具（如 MLflow, Weights & Biases (W&B)）记录每次实验的配置、代码版本、数据版本、参数、指标和产出的模型。
   • 提供模型注册中心，管理不同版本模型的生命周期（开发、暂存、生产、归档）。
5. 模型监控与反馈闭环 (Model Monitoring & Feedback Loop)：
   • 持续监控线上模型的性能指标（如准确率、延迟）和数据分布（检测数据漂移）。
   • 当监控到模型效果下降或数据发生显著变化时，自动触发再训练流水线 (Retraining Pipeline) 或告警。

MLOps 全流程示意图：

graph TD
    A[数据准备/特征工程 Pipeline] --> B(触发); 
    B --> C[模型训练/评估 Pipeline];
    C -- (模型指标/参数/版本) --> D(实验跟踪/模型注册 MLflow/W&B);
    D -- 选择模型版本 --> E[模型部署 Pipeline];
    E --> F(在线模型服务 KServe/Triton);
    F -- 预测 --> ClientApp;
    F -- (性能/数据分布) --> G[模型监控 Prometheus/Evidently];
    ClientApp -- (用户反馈/标注) --> H(反馈数据收集);
    G -- (效果下降/数据漂移) --> I(触发); 
    H -- (新标注数据) --> I;
    I -- (触发再训练) --> A;
    I -- (告警) --> OpsTeam(运维/算法团队);
    %% 工具支撑
    J(工作流引擎 Airflow/Kubeflow Pipelines) -- 编排 --> A & C & E;

实现了：机器学习全生命周期的自动化、标准化和可追溯性，提高了 AI 应用的交付速度、质量和可靠性。

---

(进阶) 阶段 6：拥抱巨无霸 → 大模型专项架构

挑战：千亿甚至万亿参数模型的训练与推理

• GPT-3、LLaMA 等大语言模型 (LLM) 的参数量达到千亿甚至万亿级别，对计算资源、存储、通信都提出了前所未有的挑战。
• 如何高效地训练如此巨大的模型？如何以可接受的成本和延迟进行推理？

❓ 架构师的思考时刻：训练和推理超大模型，现有的分布式训练和模型服务架构还够用吗？

（显存根本不够用！通信带宽是瓶颈！推理成本太高了！需要更极致的优化策略。）

✅ 演进方向：采用更高级的并行策略 + 推理优化

1. 训练优化 (大规模集群 + 高级并行)：
   • 超大规模 GPU 集群：需要成百上千甚至上万张 GPU 卡，并通过高速互联（如 NVLink, InfiniBand）连接。
   • 高级并行策略：必须综合运用数据并行、流水线并行 (Pipeline Parallelism)、张量并行 (Tensor Parallelism) 以及 ZeRO (Zero Redundancy Optimizer) 等优化技术（如 DeepSpeed 框架）来切分模型、数据和优化器状态，减少显存占用和通信开销。
2. 推理优化 (降低成本与延迟)：
   • 模型压缩：
     • 量化 (Quantization)：将模型的 FP32/FP16 参数和计算转换为 INT8 甚至更低精度，大幅减少模型大小和计算量。
     • 剪枝 (Pruning)：移除模型中冗余的权重或结构。
     • 蒸馏 (Distillation)：用大模型指导训练一个小模型。
   • 推理引擎优化：使用专门针对大模型优化的推理引擎（如 NVIDIA FasterTransformer, vLLM, DeepSpeed Inference），它们内置了算子融合、KV Cache 优化、PagedAttention 等技术。
   • 硬件加速：利用最新的 GPU 或专用 AI 芯片 (TPU, NPU)。
   • 分布式推理：对于无法放在单卡上的模型，需要将推理任务也分布到多张卡或多台机器上（如张量并行推理）。

大模型训练架构示意（简化）：

graph TD
    Controller(训练控制节点) -- 调度 --> NodeGroup1(节点组 1 - Pipeline Stage 1);
    Controller -- 调度 --> NodeGroup2(节点组 2 - Pipeline Stage 2);
    Controller -- 调度 --> NodeGroupN(节点组 N - Pipeline Stage N);
    subgraph "节点组内部 (多 GPU, 多 Node)"
        DataParallel(数据并行);
        TensorParallel(张量并行);
        ZeRO(ZeRO 优化器状态分片);
        GPU1 <-->|"NVLink/InfiniBand"| GPU2;
        GPU2 <-->|"高速互联"| GPUN;
    end
    NodeGroup1 -- 流水线通信 --> NodeGroup2;
    NodeGroup2 -- 流水线通信 --> NodeGroupN;

解决了：超大规模模型训练和推理的效率、成本和可行性问题。

架构调整（大模型训练与服务）：

graph TD
    subgraph "训练基础设施"
        GPUCluster(大规模 GPU 集群 Slurm/K8s);
        HighSpeedNetwork(高速网络 RoCE/InfiniBand);
        ParallelFileSystem(并行文件系统 Lustre/GPFS);
        GPUCluster -- 依赖 --> HighSpeedNetwork & ParallelFileSystem;
    end
    subgraph "数据处理流水线"
        RawData(海量原始数据) --> DataCleaning(数据清洗/去重);
        DataCleaning --> DataFormat(格式转换/Tokenization);
        DataFormat --> ProcessedData(处理后数据集) --> ParallelFileSystem;
    end
    subgraph "高效训练框架"
        TrainingFramework(Megatron-LM/DeepSpeed/Colossal-AI);
        TrainingFramework -- 运行于 --> GPUCluster;
        TrainingFramework -- 读取 --> ProcessedData;
        subgraph "节点组内部 (多 GPU, 多 Node)"
           Worker1(训练 Worker 1);
           Worker2(训练 Worker 2);
           PS(可选: 参数服务器);
           Worker1 <-->|"混合并行通信"| Worker2;
           Worker1 --> PS;
        end
        TrainingFramework -- 管理 --> Worker1 & Worker2 & PS;
    end
    subgraph "推理优化与服务"
        TrainedModel(训练好的大模型) --> ModelQuant(模型量化/压缩);
        ModelQuant --> InferOptimize(推理加速 TensorRT-LLM);
        InferOptimize --> InferService(模型服务 Triton/vLLM);
        InferService -- 运行于 --> GPUCluster;
    end
    subgraph "对齐与安全"
        Alignment(RLHF/指令微调);
        SafetyGuardrails(安全护栏/内容审核);
        TrainedModel -- 需要 --> Alignment;
        InferService -- 需要 --> SafetyGuardrails;
    end

---

AI 平台技术选型考量

需求维度	可选技术/方案	考量因素
数据与特征	本地文件/DB -> NFS/HDFS -> 特征平台 (Feast/Tecton)	数据规模、实时性、一致性、复用性
训练框架	单机 (TF/PyTorch) -> 分布式 (Horovod/DDP/PS/DeepSpeed)	模型规模、训练速度、硬件资源
资源调度	手动/Slurm -> Kubernetes (Native/Operator)	弹性、利用率、统一管理
模型部署	Flask/Django -> Triton/TFServing -> KServe/Seldon	性能、并发、多框架支持、版本管理
MLOps 流程	手动脚本 -> Airflow/Kubeflow Pipelines + MLflow/W&B	自动化、可重复性、可追溯性
大模型专项	高级并行 + 推理优化 (TensorRT/vLLM/DeepSpeed Inference)	显存、通信、成本、延迟

---

演进路线总结：从炼丹到工厂

阶段	核心能力	典型技术/平台	解决的核心问题
0. 本地实验	快速验证算法	Jupyter Notebook, Scikit-learn/TF/PyTorch	(起点)
1. 集中资源	共享计算/存储/环境	GPU 服务器, Slurm/PBS, NFS/HDFS, Docker	本地资源不足，环境不一致，协作困难
2. 分布式训练	加速训练/支持大模型	Horovod, PyTorch DDP, TensorFlow PS, DeepSpeed	单卡/单节点训练效率低，显存瓶颈
3. 特征平台	特征工程规范化/复用/一致性	Feature Store (Feast/Tecton), Spark/Flink	特征重复开发，线上线下不一致
4. 模型服务化	高性能/稳定/标准模型部署	Triton Inference Server, KServe/Seldon Core	模型上线难，性能差，管理复杂
5. MLOps 流水线	自动化/可重复/可靠交付	Kubeflow Pipelines/Airflow, MLflow/W&B	手动流程效率低，易错，不可追溯
6. 大模型专项	千亿+参数模型训练/推理	高级并行策略 + 推理优化框架	超大模型带来的计算/存储/通信/成本挑战

---

深度实践与思考

1. 分布式训练实践：使用 Horovod 或 PyTorch DDP 在多 GPU 环境下训练一个模型，对比单卡训练速度。
2. 特征平台试用：安装并试用 Feast，定义特征，模拟离线和在线特征的写入与读取。
3. 模型服务性能对比：使用 Triton 或 KServe 部署同一个模型，对比其与简单 Flask 包装的性能差异（QPS, 延迟）。
4. MLOps 流程体验：运行一个简单的 Kubeflow Pipelines 或 MLflow Pipeline 示例，体验自动化流程。
5. 大模型推理探索：尝试使用 Hugging Face Transformers 结合 DeepSpeed Inference 或 vLLM 对一个开源大模型进行推理，观察性能。

构建现代 AI 平台是一个复杂的系统工程，需要综合考虑数据、算法、算力、工程流程等多个方面。理解其架构演进，有助于把握 AI 技术规模化落地的关键脉络。