简介

• 简介
• 《MLOps实践》
• 业界实践
  • 虎牙
  • 腾讯
  • 阿里
  • vivo
  • 腾讯
  • 美团
  • 百度
• 字节
• 基础设施
  • 工作流
  • 模板市场
  • 存储
  • 分布式加速
  • 资源利用率
  • Scheduler调度
  • 依托平台
• 其它

《人工智能云平台原理、设计与应用》近年来涌现了很多智能算法，这些算法需要软件的支撑，没有软件的支撑，理论很难与应用相结合，新硬件也很难为应用提速，所以巨头们推出了TensorFlow、Pytorch等开源框架，然而这些框架不足以支撑人工智能全流程生产化应用，它们仅面向个人开发者和研究人员，管理少数计算设备资源，无法在云计算资源上提供面向多租户的智能应用全流程服务。欠缺诸如海量样本数据管理与共享存储、集群管理、任务调度、快速训练与部署、运行时监控等能力，缺乏人工智能生产流程的抽象、定义和规范，导致用户形成生产力的成本过高。

海量数据标注 + 大规模计算 + 工程化（python或c++）=AI系统，也被称为MLaaS/MLOps。

AI 平台可能是云原生技术栈上最具”可玩性”的一种场景。种类繁多的异构资源和通讯形式、调度策略、常规业务不需要的拓扑感知、花式任务编排、数据密集型有状态应用、天然离/在线混部。

MLOps落地持续推进 AI生产力转化加速能力成熟度划分：

1. 基础级：以人工方式初步开展模型开发、部署、上线等工作
2. 专业级：规范化。具备模型研发和运营管理体系及规范，并依据规范初步形成了数据处理、模型开发、模型部署流水线，具备版本控制能力。
3. 领先级：系统化。具备包括数据处理、模型开发、模型集成和部署，以及模型持续监控和更新维护的机器学习全链路流水线，且流水线支持部分自动化执行能力。
4. 卓越级：自动化。具备机器学习全链路流水线的全自动化执行能力。
5. 领航级：智能化。支持机器学习流水线部分环节的智能化学习和执行。

《MLOps实践》

我们开发ML模型依赖于几个要素，如数据、算法或参数，在实验过程中，这些要素会随着时间的推移而改变，从而生成不同的版本。创建数据和参数版本镜像可以帮助我们跟踪不同的版本，但版本控制有其自身的成本。市面上有很多书讲算法原理、如何训练ML模型，也有很多书讲如何构建软件项目，但很少有书把这两个世界融合起来，对于如何构建由ML驱动实际应用的项目工程方面，如数据收集、存储、模型部署、管理以及监控运维等方面的书却很少见。

DevOps依靠工具、自动化和工作流程来抽象软件工程的复杂性，让开发人员专注于需要解决的实际问题，在软件开发领域已经基本成为标配，那为什么这套方法论或经验不能直接应用到ML领域呢？其原因在于，ML的跨领域特性延伸出了新的维度，比如增加了一个额外的数据维度

1. 对于传统软件，几乎可以即时体现代码变化对结果的影响，但在ML中，想到看到代码变化对结果的影响需要重新训练模型
2. 对于传统软件，一个版本的代码产生一个版本的软件，在版本控制系统的辅助下，我们可以在任何时候创建应用程序的任意变体。在ML中，开发的结果不是代码而是模型，而这个模型又是由创建和训练模型的代码版本及其所使用的数据产生。代码和数据分别处在两个平行的平面上，它们之间共享时间维度，但在所有其它方面都是独立的。
3. 在ML 中，不仅要保存不同版本的代码，还需要一个地方来保存不同版本的数据和模型工件，和涉及的元数据信息。与代码不同，模型性能会随着时间的推移而衰退，这就需要监控。一旦发现预测准确率下降， 就需要新的数据重新训练模型，训练永远不会结束，即ML的迭代属性。 ML的迭代属性意味着， 如果没有完备的自动更新流程，想要通过手动的方式来反映这些变化需要大量的工作，这是一个系统工程。

当我们在说云原生AI的时候，我们在说什么？

业界实践

2022年8个好用的MLOps工具和平台 未读

虎牙

互动直播场景下的AI基础设施建设

近几年AI 算法需求量呈现指数级增长，同时在实际应用中，机器学习的代码量（ML code）仅占整个机器学习pipeline的较小比例，更大比例模块为与ML code交互的模块，如数据收集、特征工程、资源管理等。交互模块繁多导致整体机器学习 pipeline的复杂度和工作量加大，因此，需要与ML库交互的模块更简洁友好，方便算法工程师应用。

手动时代

AI平台的定位：面向算法工程师，围绕AI 模型的全生命周期去提供一个一站式的机器学习服务平台。

腾讯

高性能深度学习平台建设与解决业务问题实践构建公司统一的大规模算力，方便好用的提供GPU

腾讯自研机器学习平台“太极”八年进化之路

阿里

KubeDL 加入 CNCF Sandbox，加速 AI 产业云原生化

从算法工程师着手设计第一层神经网络结构，到最终上线服务于真实的应用场景，除 AI 算法的研发外还需要大量基础架构层面的系统支持，包括数据收集和清理、分布式训练引擎、资源调度与编排、模型管理，推理服务调优，可观测等。众多系统组件的协同组成了完整的机器学习流水线。

具体的说

1. 数据抽取组件->实现样本数据筛选
2. 画像组件->实现样本数据与画像字段的关联
3. 特征组件->实现画像数据到特征数据格式的转换
4. 切分组件->实现样本抽样
5. 深度组件->实现用户自定义模型训练
6. 预测组件->验证模型指标
7. 部署组件->模型部署上线
8. 串联上述所有组件的工作流组件，以支持算法工程师 模型训练部署的整个过程。PS: 具体实现上设计到 自己实现或使用工作流引擎。 自动化能自动的，加速能加速的，减少模型耗时，加快算法工程师的产出效率，并以此为前提提高资源利用率。

摆脱 AI 生产“小作坊”：如何基于 Kubernetes 构建云原生 AI 平台在初期，用户利用 Kubernetes，Kubeflow，nvidia-docker 可以快速搭建 GPU 集群，以标准接口访问存储服务，自动实现 AI 作业调度和 GPU 资源分配，训练好的模型可以部署在集群中，这样基本实现了 AI 开发和生产流程。紧接着，用户对生产效率有了更高要求，也遇到更多问题。比如 GPU 利用率低，分布式训练扩展性差，作业无法弹性伸缩，训练数据访问慢，缺少数据集、模型和任务管理，无法方便获取实时日志、监控、可视化，模型发布缺乏质量和性能验证，上线后缺少服务化运维和治理手段，Kubernetes 和容器使用门槛高，用户体验不符合数据科学家的使用习惯，团队协作和共享困难，经常出现资源争抢，甚至数据安全问题等等。从根本上解决这些问题，AI 生产环境必然要从“单打独斗的小作坊”模式，向“资源池化+AI 工程平台化+多角色协作”模式升级。我们将云原生 AI 领域聚焦在两个核心场景：持续优化异构资源效率，和高效运行 AI 等异构工作负载。

1. 优化异构资源效率
2. 运行 AI 等异构工作负载，兼容 Tensorflow，Pytorch，Horovod，ONNX，Spark，Flink 等主流或者用户自有的各种计算引擎和运行时，统一运行各类异构工作负载流程，统一管理作业生命周期，统一调度任务工作流，保证任务规模和性能。一方面不断提升运行任务的性价比，另一方面持续改善开发运维体验和工程效率。

云原生 AI 套件的功能从底向上分为：

1. 异构资源层，包括异构算力优化和异构存储接入
2. AI 调度层，包括各种调度策略优化
3. AI 弹性层，包括弹性 AI 训练任务和弹性 AI 推理服务
4. AI 数据加速与编排层，包括数据集管理，分布式缓存加速，大数据服务集成
5. AI 作业管理层，包括 AI 作业全生命周期管理服务和工具集
6. AI 运维层，包括监控、日志、弹性伸缩、故障诊断和多租户
7. AI 制品仓库，包括 AI 容器镜像，模型和 AI 实验记录

用户体验：对于数据科学家和算法工程师开发训练 AI 模型来说，Kubernetes 的语法和操作却是一种“负担”。他们更习惯在 Jupyter Notebook 等 IDE 中调试代码，使用命令行或者 Web 界面提交、管理训练任务。任务运行时的日志、监控、存储接入、GPU 资源分配和集群维护，最好都是内置的能力，使用工具就可以简单操作。因此要提供命令行工具/SDK/运维大盘/开发控制台来满足用户的各种需要。 AI 作业生命周期管理（Arena）

云原生深度学习平台 PAI-DLC 架构设计

vivo

训练平台 + 推理平台 + 容器平台（日常维护cli ==> 白屏化）

一站式机器学习平台在 vivo AI 的实践

算力的易用性

1. 分布式训练
2. 交互式调试
3. 容量托管
4. 训练sdk

算力的灵活调度

1. 基于容器的资源调度
2. 在离线统一资源池
3. 混合云 vivo AI 计算平台的 ACK 混合云实践
4. 基于GPU 拓扑的调度

算力的高效利用

1. 资源分配：弹性伸缩、算力超卖（多个容器使用一张卡，GPU隔离）
2. 资源使用：训练/推理加速，训练容错
3. 弹性训练 vivo AI 计算平台弹性分布式训练的探索和实践
4. 训练性能剖析
5. GPU 远程调用
6. 数据编排和加速

vivo推荐中台升级路：机器成本节约75%，迭代周期低至分钟级玲珑·推荐中台主要为数据及算法工程师提供从算法策略到 A/B 实验的工程架构解决方案、通用的特征服务和样本生产服务、模型的离线训练到上线部署全生命周期管理、高性能推理等能力。玲珑·推荐中台包含四大模块：推荐中心、特征中心、模型中心、端云协同推荐。

具体一点

vivo互联网机器学习平台的建设与实践 有一个比较有意思的地方，算法工程师 配置自己的任务需要xx cpu xx 内存，但经常配高了，我们也轻易不敢替他改，且训练任务 不是long-running的，没有历史数据给建议值。vivo的方案是

1. 有一个CPU和内存的上限。超过这个限额就需要提交审批。也避免单个训练资源独占。
2. 进行了环境的划分，测试开发和生产，要是想去生产环境（机器配置更高，排队时间短），资源利用率，必须达标才能申请。PS：充分把握了人性，凭空制造了一个糖果。我们因为 都在一个集群，用户已经跑起来了，你再push他 多关注 下利用率啥的，他们也不care
3. 有一个排队的调度拉起机制。会算出一个得分，基于得分去拉起。训练利用率的情况会影响他先还是别人先。PS：阿里会给任务打一个资源分，如果资源分很低，任务排队的优先级就很低。此外还会给人打分，如果某个人的任务利用率总是很低，人的资源分也很低。 PS：让pod 资源尽量匹配真实需求这个事儿，业务pod 使用vpa等机制自动更新，ai 训练pod 则通过平台奖惩 push 用户。

腾讯

腾讯般若系统

cube-studio腾讯音乐直接开源的一个ai训练平台。 QQ音乐推荐系统算法架构实践

https://github.com/tencentmusic/cube-studio/wiki

腾讯广告模型基于”太极”的训练成本优化实践

美团

美团外卖特征平台的建设与实践

美团图灵机器学习平台性能起飞的秘密（一） 用spark实现的。

百度

云原生 AI 的资源调度和 AI 工作流引擎设计分享客户所关心的痛点问题可以归为4类

1. 资源分配的不均衡，或者规划的不合理，往往会导致高优任务无法高效的运行；
2. 资源碎片较多，导致在集群有空余资源的情况下，某些任务依旧无法运行，这个问题在 AI 训练的场景中尤为明显；
3. 集群 GPU 资源利用率低，当然这个问题与前两个密切相关；
4. AI 工程效率低下，这其实也是一个综合性问题，比如分布式训练任务编排复杂度较高、训练数据加载缓慢、训练算子实现不合理导致 GPU 利用率低，以及 AI 作业的镜像往往比较大启动会很缓慢，这些都会导致 AI 工程效率低下。

百度百舸 · AI 异构计算平台，加速自动驾驶模型迭代AI 加速套件：数据湖存储加速 RapidFS、模型推理加速 AIAK-Inference、模型训练加速 AIAK-Training，以及针对大规模容器处理的 AI 容器调度平台。

1. 一个分级的存储底座，这里包括了极低成本的冷存储系统和归档存储系统，也包括了高性能的并行文件存储系统，总计有 6 级的分级数据湖存储的能力。并且基于我们统一的数据管理，这些数据在不同级别的存储系统之间还可以自由的迁移。
2. 推理加速：模型精简（减少计算量），包括量化、减枝、蒸馏和 NAS 等；提高GPU 利用率，算子融合和单算子优化
3. 训练加速：AIAK-Training 训练加速引擎是一个面向 AI 训练全生命周期的全链路优化的产品。
   1. 从一个模型训练的过程来看，它其实分为数据的加载、前向的计算、参数的更新等等这些环节。对应数据加载过程中的显存优化，也包括前向计算过程中的算子优化，即损失函数中的算子优化，甚至包括我们在梯度更新过程中的分布式相关的组件。
   2. 由于模型跟框架的耦合度会非常高，使得第三方的客户或者第三方的合作伙伴在应用起来的过程中需要去修改比较多的代码，用起来比较麻烦。AIAK-Training 针对于框架的几大组件进行了相关的抽象。抽象出了 AIAK.OP、AIAK.IO、AIAK.Loss，甚至和分布式相关的几个组件，这样用户仅仅需要修改几行代码，就能够享受到我们 AIAK-Training 所实现的各种加速的功能。
   3. 针对不同的模型，基于模型结构的复杂性，还有基础设施环境的复杂性，不同的优化策略在不同模型上有时候可能会存在负的收益。 AIAK-Training 正在研发的实际上是基于一个自动调优的策略。实时的跟踪运行过程中的各种性能指标，再动态的去使用我们所配置的各种优化能力
   4. 为了追求训练的极致性能，我们跟踪的主要有两个指标：一个是单卡本身的训练性能，另一个是多卡之间的并行效率。这也对应着三个事情：数据的加载优化、模型计算的优化、以及多卡并行的优化。细节看文档
4. AI 容器的任务调度
5. 资源池化。
   1. GPU 容器虚拟化，提供了 1/4、1/2，甚至更细力度的这种容器的使用能力。PS：GpU 隔离能力越好，才能够支持GPU 在离线混部。
   2. 远程 GPU，打破了单机层面 CPU 和 GPU 资源的硬配比的一个限制； 让间歇式的任务在需要的时候去挂载，在不需要的时候就释放；根据任务的本身的需求动态的去调整算力和显存的隔离能力与资源的分配；透明容错：当后端的 GPU 发现故障的时候，我们会将 GPU 上的任务透明化，让业务无感的迁移到一个新的 GPU 上继续运行。

AI 训练加速原理解析与工程实践分享

AI推理加速原理解析与工程实践分享

字节

字节跳动正式开源分布式训练调度框架 Primus 支持yarn 和 k8s任务统一调度，会为每一个任务生成一个Application Manager，

基础设施

功能侧从下到上：异构资源；异构workload；工作流。 效率/体验侧：提高效率（数据加速、通信加速、调度侧共享、弹性、拓扑感知），提高规模（多集群）和扩展性。

1. 工作流编排
2. AI 任务可视化，实际的 AI 训练过程包含数据处理、模型训练、模型评估、模型部署和发布等一系列过程，每个 AI 算法工作者针对每个步骤都会用自己的方式去临时管理，这样会导致代码和模型管理混乱，难以追踪和复现结果，也无法进行高效分享和代码复用。

工作流

美团外卖特征平台的建设与实践平台化建设最重要的流程之一是“如何进行流程抽象”，业界有一些机器学习平台的做法是平台提供较细粒度的组件，让用户自行选择组件、配置依赖关系，最终生成一张样本构建的DAG图。对于用户而言，这样看似是提高了流程编排的自由度，但深入了解算法同学实际工作场景后发现，算法模型迭代过程中，大部分的样本生产流程都比较固定，反而让用户每次都去找组件、配组件属性、指定关系依赖这样的操作，会给算法同学带来额外的负担，所以我们尝试了一种新的思路来优化这个问题：模板化 + 配置化，即平台提供一个基准的模板流程，该流程中的每一个节点都抽象为一个或一类组件，用户基于该模板，通过简单配置即可生成自己样本构建流程。PS：就是多提供了一个模板？

大规模运行 Apache Airflow 的经验和教训Apache Airflow 是一个能够开发、调度和监控工作流的编排平台。未细读

深入探索云原生流水线的架构设计

1. 在 Pipeline 中，我们对一个任务执行的抽象是 ActionExecutor。一个执行器只要实现单个任务的创建、启动、更新、状态查询、删除等基础方法，就可以注册成为一个 ActionExecutor。
   1. Engine 层负责流水线的推进，包括：Queue Manager 队列管理器，支持队列内工作流的优先级动态调整、资源检查、依赖检查等。Dispatcher 任务分发器，用于将满足出队条件的流水线分发给合适的 Worker 进行推进。Reconciler 协调器，负责将一条完整的流水线解析为 DAG 结构后进行推进，直至终态。
   2. 模块内部使用插件机制，对接各种任务运行时。
2. 在一条流水线中，节点间除了有依赖顺序之外，一定会有数据传递的需求。上下文传递，后置任务可以引用前置任务的“值”和“文件”
3. Pipeline 之所以好用，是因为它提供了灵活一致的流程编排能力，并且可以很方便地对接其他单任务执行平台，这个平台本身不需要有流程编排的能力。调度时，根据任务类型智能调度到对应的任务执行器上，包括 K8sJob、Metronome Job、Flink Job、Spark Job 等等。
4. 这里简单列举一些比较常见的功能特性：
   1. 配置即代码
   2. 扩展市场丰富
   3. 可视化编辑
   4. 支持嵌套流水线
   5. 灵活的执行策略，支持 OnPush / OnMerge 等触发策略
   6. 支持工作流优先队列
   7. 多维度的重试机制
   8. 定时流水线及定时补偿功能
   9. 动态配置，支持“值”和“文件”两种类型，均支持加密存储，确保数据安全性
   10. 上下文传递，后置任务可以引用前置任务的“值”和“文件”
   11. 开放的 OpenAPI 接口，方便第三方系统快速接入

超大模型工程化实践打磨，百度智能云发布云原生 AI 2.0 方案针对 DAG 运行全方面优化，提升 DAG 执行效率

1. 通过节点产出数据统一管理，自动跳过未发生变化的节点，缩短 DAG 运行时间。
2. 通过感知节点产出临时数据位置，减少中间数据读写的频率和远程访问频率。
3. 通过 AI 资源调度的异构能力，检测节点的运行环境（CPU、GPU 等）按需调度不同节点，降低算力占用成本。

算法对工作流的使用有两种场景：

1. 对新业务进行探索，一般还未上线，手动触发DAG的执行
2. 模型结构基本确认，仅根据每日数据更新模型参数。 探索时可以随便搞，但纳入日常调度的任务，应该标准化流程（样本生成，特征工程，训练），这样才能各个阶段进行优化。

火山引擎数据调度实例的 DAG 优化方案 DAG 优化也有这么多花活儿。

模板市场

腾讯音乐cube-studio开源一站式云原生机器学习平台直接使用airflow/argo等调度组件，但没有编排界面，直接编辑yaml也很麻烦。所以我们单独开发了模板市场和pipeline编排工具，并在开源中提供多种分布式模板。用户通过拖拉拽方式编排pipeline，配置执行参数（模板需要设置参数）后就可运行。模板市场的模板是注册进去的，用户和平台都可操作。流程比较简单：准备镜像，标注清楚该镜像的参数、类型、限制条件、用户提示等，使用标准化的注册流程注册至平台后，平台用户就可使用该模板。模板开发者多为平台方或使用方组织架构内特定工程人员。PS：pipeline 和模板是分不开的。ai工作流的模板一般分为四类：数据导入；分布式训练；模型校验；模型部署。

存储

整体脉络：hdfs+MapReduce 存算一体 ==> 存算分离 ==> 存算分离+ 分布式缓存系统粘合。

如何分析一个任务的io耗时？一般GPU利用率70%以上说明短板不是在数据读取了。可以做一些对比实验，比如单节点单任务，数据放到内存，对比下gpu利用率。一般训练过程中卡顿，除非在tf graph中有一些利用率低的op算子，否则大部分都是dataloader/prefetch的问题，有的是dataloader的设计问题，有的是硬盘问题。

Fluid + JindoFS 助力微博海量小文件模型训练速度提升 18 倍

1. 计算存储分离架构导致数据访问高延时，导致训练慢。平台的文件存储在远端的分布式存储中，但是计算集群可能是不同网络的私有集群。
2. Kubernetes 调度器数据缓存无感知，同一数据源多次运行访问依旧慢
3. 多数深度学习框架并不支持 HDFS 接口，导致开发难：比如 PyTorch，MxNet 等框架只支持 POSIX 协议接口，HDFS 接口需要额外的对接开发。因此需要同时支持模型开发阶段的 POSIX 接口以及模型训练阶段的 HDFS 接口，引入模型代码适配不同存储的复杂性。
4. HDFS 服务成为了性能单点，一旦某个任务拖慢了 HDFS 系统，其他的训练任务也会受到影响。而且，一旦 HDFS 无法工作，整个训练集群也会受到影响。

如何用Alluxio来加速云上深度学习训练？在Alluxio之上可以对接不同的数据应用，包括Spark、Flink这种ETL工具，presto这种query工具，以及TensorFlow、PyTorch等深度学习框架。在Alluxio下面也可以连接不同数据源，比如阿里云、腾讯云、HDFS等。深度学习训练框架PyTorch、TensorFlow、Caffe，它们的原生数据源都是本地文件系统。企业数据量日益扩大，导致我们需要去使用分布式数据源。Alluxio可以把来自不同的远端存储系统，以及分布式文件系统的数据都挂载到Alluxio统一的命名空间之内。通过Alluxio POSIX API，把这些数据变成类似于本地文件的形式，提供给各种训练任务。对数据进行读写缓存，对元数据进行本地缓存。A ==> hdfs ==> B 可以变为 A ==> Alluxio ==> hdfs ==> Alluxio ==> B，实际数据还未写入hdfs 即可被读取，即使数据持久化的速度比较慢，也不影响B。PS：深度学习有很多epoch，一个文件会被读取epoch次，理论上说，如果训练样本大于单节点 内存，那么第二轮epoch 不会比第一轮epoch快多少，还得从hdfs 再读一下，这个时候用缓存就很有意义。

Atlas超算平台基于 Fluid + Alluxio 的计算加速实践 对于音频训练场景（其它场景也很有参考意义）

一文读懂 高性能可预期数据中心网络近年来人工智能产业快速增长，但GPU算力的增长速率始终无法满足人工智能应用的需求，因而分布式机器学习模式成为业界常态。让数量巨大的异构计算资源高效协同工作，并不是一件容易的事情，高性能网络，就是其中关键的使能技术。

分布式加速

腾讯音乐cube-studio开源一站式云原生机器学习平台pipeline搭建好后会发现虽然编排流程简化了，但是运行时间并没有减少，耗时主要集中在数据处理和训练上。数据处理分为结构化和非结构化数据处理，对于结构化数据处理，像sql等形式目前还是采用公司已有的大数据spark平台。对于非结构化数据处理/训练以及结构化数据的训练部分的耗时，考虑使用分布式加速的方式。

平台对分布式训练的优化，分为四块

1. 在用户代码层面，深入进程内部进行优化；
2. 在数据层面，避免数据倾斜、优化数据加载；例如一个任务提前分布好每个worker的内容，当数据分配不均匀和部分worker受其他机器worker影响时，性能会下降，此时每个worker剩余任务数量就不一样，导致用户任务迟迟不能完成，不能推进其他事情。
3. 物理层面，优化大文件、带宽问题；
4. 在此之上，使用共享gpu提升使用率，动态cpu算力调整，上层优化任务调度，亲密性，多项目组的资源共享等。

对于通信耗时，可以使用单机多卡和多机单卡来做对比，优化手段会硬核一些，一般集中在框架层和硬件层。

资源利用率

1. 对于cpu分布式任务，用户可自己借助多进程、协程提升单个pod的cpu利用率。此部分倾向于让用户申请更多worker数提升性能。对于用户没有主动优化cpu利用的情况，支持通过系统的监控和智能调整优化方案将该任务的资源申请值调整至合理的范围，进而提升cpu使用率。
2. gpu比较特殊，平台在训练过程中对gpu的占用为整卡占用的方式，因为在训练中使用vgpu非常容易出现卡零碎浪费的情况，并且即使使用vgpu，并处理好零碎卡的问题，提升了平台整体gpu利用率，但任务耗时没有降低。故平台方倾向于提升用户占用的gpu卡的单卡利用率，进而提升单个分布式任务的运行效率。

3. gpu利用率低的核心问题是gpu等待时间太长，可能cpu处理或io等操作，包括优化磁盘存储、数据加载、网络通信、预处理、cpu上的模型保存。

   

代码层面gpu利用率优化

1. 数据加载相关
   1. 存储计算不在同一个城市：数据导入到集群存储
   2. 磁盘io性能太差：对于临时数据可以将内存映射为磁盘
   3. 小文件太多，频繁io：合并为大文件处理
   4. 未启用多进程并行读取数据：pytorch提高num_workers，tf配置num_parallel_calls/num_parallel_reads
   5. 未启用提前加载机制来实现 CPU 和 GPU 的并行：pytorch配置prefetch_factor，tf配置Dataset.prefetch()
   6. 未设置共享内存 pin_memory：设置为true
   7. 每次送入gpu的_size太少：模型固定后，调整 batch_size，尽量增大显存的利用率。然后再调节num_workers提高gpu利用率
2. 数据预处理相关
   1. 数据处理和训练耦合在一起：将数据处理和训练分成两个task，训练中需要的配置之类的全部提前加载到内存，让gpu只做训练任务。
   2. 使用Nvidia DALI，在gpu中做数据处理
3. 频繁IO操作
   1. 模型保存太频繁：减少保存模型(checkpoint)的频率
   2. tensorboard文件保存太频繁
   3. 日志打印太频繁，频繁cpu/gpu切换：不要打印训练迭代中个人日志
   4. 存储io性能太低
   5. 对于频繁使用的文件(库文件，lib等)放入了性能不高的存储中

对于一些场景，平台或用户不能投入人力定向优化，这时候就需要架构层面来解决利用率的问题。

1. 使用vgpu的形式。
2. 共享gpu，在架构层面我们调整用户可以配置共享同一个gpu的进程数目，以此来让在相同gpu卡上，跑出更多分布式worker的效果。直到机器的某个资源达到瓶颈。比如3个进程共享一张卡，一台机器4张卡，同时12个进程，此时cpu使用率已经接近100%，那么就可结束进程增加，从其他的地方进一步加速了。

Scheduler调度

1. 首先批调度能力，引入kube-batch的gang
2. 另外是亲密度和调度算法的调整：
   1. 对cpu型任务倾向于把不同的任务分配到不同的cpu机器上避免单机瓶颈；
   2. 对gpu任务，多个任务尽量分配到同一个gpu机器上，减少网络通信消耗；
   3. 对同一pipeline中的不同任务，尽量部署到不同的机器上，避免存在相似任务任务达到单机瓶颈。对于不同的pipeline，放到算力相对空闲的机器上，平衡集群使用率。
3. 弹性伸缩
4. GPU 共享调度、GPU 拓扑感知调度。对于使用梯度下降优化的算法，多 GPU 卡之间需要频繁传输数据，数据通信带宽往往成为限制 GPU 计算性能的瓶颈。GPU 拓扑感知调度功能，通过获取计算节点上所有 GPU 卡间连接拓扑结构，调度器为多卡训练任务选择 GPU 资源时，根据拓扑信息考虑 NVLINK，PCIe Switch，QPI 以及 RDMA 网卡等所有互联链路，自动选择出能够提供最大通信带宽的 GPU 卡组合，避免带宽限制影响 GPU 计算效率。

依托平台

Serverless 架构下的 AI 应用开发

基于 KubeVela 的机器学习实践

从神经搜索到多模态应用

阿里云机器学习平台 PAI 的云原生实践与落地 讲了产品设计和架构设计

其它

深度学习平台的搭建，将遇到诸多挑战，主要体现在以下方面：

1. 数据管理自动化。在深度学习的业务场景中，从业人员会花费大量的时间获取和转换建立模型需要的数据。数据处理过程中还将产生新的数据，这些数据不单单应用于本次训练，很可能用于后续推理过程。并且新 生成的数据不需要传给数据源，而是希望放置在新的存储空间。这需要基础平台提供可扩展的存储系统。PS： 手动命令行、页面、代码上传、下载，pod 随时可以访问，分布式训练任务多pod 之间也要共享一些临时的存储文件。 AI 数据编排与加速（Fluid） 因为训练任务实例都是临时创建的，实例刚创建时没有任务、数据文件，需要训练脚本自己下载，数据流转很不方便。同时多部门、部门内人员的任务、数据文件也需要分目录隔离和共享。
2. 资源的有效利用。深度学习相关的应用是资源密集型，资源使用波动大，存在峰值和谷值。在应用开始运行的时候，快速获取计算资源；在应用结束后，回收不适用的计算资源对于资源利用率的提升相当重要。数据处理、模型训练和推理所使用的计算资源类型和资源占用时间有所不同，这就需要计算平台提供弹性的资源供应机制。
3. 屏蔽底层技术的复杂性

如何跟公有云协同 vivo AI 计算平台的 ACK 混合云实践

AI 中台具备六大能力。

1. 统一的存储空间，支持多数据源导入。
2. Pipeline 可视化工作流管理与执行，支持数据科学家从数据建模阶段开始的可视化管理，节省成本，快速体现数据科学家的价值。深入探索云原生流水线的架构设计
3. 基于容器的计算资源分配和软件库安装，支持 TensorFlow、PyTorch 等各种框架。
4. 支持 GPU、TPU、CPU 框架和基于异构计算的模型管理。
5. 模型管理，支持新手快速上手，无需通过自己实现原始算法，只需要理解算法原理就可以通过调参实现。
6. AI Serving，模型一键封装为 API，一键部署。