技术

数据湖 高性能计算与存储 Linux2.1.13网络源代码学习 《大数据经典论文解读》 三驾马车学习 Spark 内存管理及调优 Yarn学习 从Spark部署模式开始讲源码分析 容器狂占内存资源怎么办? 多角度理解一致性 golang io使用及优化模式 Flink学习 c++学习 学习ebpf go设计哲学 ceph学习 学习mesh kvm虚拟化 学习MQ go编译器以及defer实现 学习go 为什么要有堆栈 汇编语言 计算机组成原理 运行时和库 Prometheus client mysql 事务 mysql 事务的隔离级别 mysql 索引 坏味道 学习分布式 学习网络 学习Linux go堆内存分配 golang 系统调用与阻塞处理 Goroutine 调度过程 重新认识cpu mosn有的没的 负载均衡泛谈 单元测试的新解读 《Redis核心技术与实现》笔记 《Prometheus监控实战》笔记 Prometheus 告警学习 calico源码分析 对容器云平台的理解 Prometheus 源码分析 并发的成本 基础设施优化 hashicorp raft源码学习 docker 架构 mosn细节 与微服务框架整合 Java动态代理 编程范式 并发通信模型 《网络是怎样连接的》笔记 go channel codereview gc分析 jvm 线程实现 go打包机制 go interface及反射 如何学习Kubernetes 《编译原理之美》笔记——后端部分 《编译原理之美》笔记——前端部分 Pilot MCP协议分析 go gc 内存管理玩法汇总 软件机制 istio流量管理 Pilot源码分析 golang io 学习Spring mosn源码浅析 MOSN简介 《datacenter as a computer》笔记 学习JVM Tomcat源码分析 Linux可观测性 学习存储 学计算 Gotty源码分析 kubernetes operator kaggle泰坦尼克问题实践 kubernetes扩缩容 神经网络模型优化 直觉上理解深度学习 如何学习机器学习 TIDB源码分析 什么是云原生 Alibaba Java诊断工具Arthas TIDB存储——TIKV 《Apache Kafka源码分析》——简介 netty中的线程池 guava cache 源码分析 Springboot 启动过程分析 Spring 创建Bean的年代变迁 Linux内存管理 自定义CNI IPAM 共识算法 spring redis 源码分析 kafka实践 spring kafka 源码分析 Linux进程调度 让kafka支持优先级队列 Codis源码分析 Redis源码分析 C语言学习 《趣谈Linux操作系统》笔记 docker和k8s安全访问机制 jvm crash分析 Prometheus 学习 Kubernetes监控 容器日志采集 Kubernetes 控制器模型 容器狂占资源怎么办? Kubernetes资源调度——scheduler 时序性数据库介绍及对比 influxdb入门 maven的基本概念 《Apache Kafka源码分析》——server Kubernetes类型系统 源码分析体会 《数据结构与算法之美》——算法新解 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 ansible学习 Kubernetes源码分析——从kubectl开始 jib源码分析之Step实现 jib源码分析之细节 线程排队 跨主机容器通信 jib源码分析及应用 为容器选择一个合适的entrypoint kubernetes yaml配置 《持续交付36讲》笔记 mybatis学习 程序猿应该知道的 无锁数据结构和算法 CNI——容器网络是如何打通的 为什么很多业务程序猿觉得数据结构和算法没用? 串一串一致性协议 当我在说PaaS时,我在说什么 《数据结构与算法之美》——数据结构笔记 PouchContainer技术分享体会 harbor学习 用groovy 来动态化你的代码 精简代码的利器——lombok 学习 《深入剖析kubernetes》笔记 编程语言那些事儿 rxjava3——背压 rxjava2——线程切换 spring cloud 初识 《深入拆解java 虚拟机》笔记 《how tomcat works》笔记 hystrix 学习 rxjava1——概念 Redis 学习 TIDB 学习 如何分发计算 Storm 学习 AQS1——论文学习 Unsafe Spark Stream 学习 linux vfs轮廓 《自己动手写docker》笔记 java8 实践 中本聪比特币白皮书 细读 区块链泛谈 比特币 大杂烩 总纲——如何学习分布式系统 hbase 泛谈 forkjoin 泛谈 看不见摸不着的cdn是啥 《jdk8 in action》笔记 程序猿视角看网络 bgp初识 calico学习 AQS——粗略的代码分析 我们能用反射做什么 web 跨域问题 《clean code》笔记 《Elasticsearch权威指南》笔记 mockito简介及源码分析 2017软件开发小结—— 从做功能到做系统 《Apache Kafka源码分析》——clients dns隐藏的一个坑 《mysql技术内幕》笔记 log4j学习 为什么netty比较难懂? 递归、回溯、动态规划 apollo client源码分析及看待面向对象设计 学习并发 docker运行java项目的常见问题 OpenTSDB 入门 spring事务小结 分布式事务 javascript应用在哪里 《netty in action》读书笔记 netty对http2协议的解析 ssl证书是什么东西 http那些事 苹果APNs推送框架pushy apple 推送那些事儿 编写java框架的几大利器 java内存模型和jvm内存布局 java exception Linux IO学习 netty内存管理 测试环境docker化实践 netty在框架中的使用套路 Nginx简单使用 《Linux内核设计的艺术》小结 Go并发机制及语言层工具 Linux网络源代码学习——数据包的发送与接收 《docker源码分析》小结 docker namespace和cgroup zookeeper三重奏 数据库的一些知识 Spark 泛谈 链式处理的那些套路 netty回顾 Thrift基本原理与实践(二) Thrift基本原理与实践(一) 回调 异步执行抽象——Executor与Future Docker0.1.0源码分析 java gc Jedis源码分析 深度学习泛谈 Linux网络命令操作 JTA与TCC 换个角度看待设计模式 Scala初识 向Hadoop学习NIO的使用 以新的角度看数据结构 并发控制相关的硬件与内核支持 systemd 简介 quartz 源码分析 基于docker搭建测试环境(二) spring aop 实现原理简述 自己动手写spring(八) 支持AOP 自己动手写spring(七) 类结构设计调整 分析log日志 自己动手写spring(六) 支持FactoryBean 自己动手写spring(九) 总结 自己动手写spring(五) bean的生命周期管理 自己动手写spring(四) 整合xml与注解方式 自己动手写spring(三) 支持注解方式 自己动手写spring(二) 创建一个bean工厂 自己动手写spring(一) 使用digester varnish 简单使用 关于docker image的那点事儿 基于docker搭建测试环境 分布式配置系统 JVM执行 git maven/ant/gradle/make使用 再看tcp kv系统 java nio的多线程扩展 《Concurrency Models》笔记 回头看Spring IOC IntelliJ IDEA使用 Java泛型 vagrant 使用 Go常用的一些库 Python初学 Goroutine 调度模型 虚拟网络 《程序员的自我修养》小结 Kubernetes存储 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件 Go基础 JVM类加载 硬币和扑克牌问题 LRU实现 virtualbox 使用 ThreadLocal小结 docker快速入门

架构

controller-runtime细节分析 finops学习 kubevela多集群 kubevela中cue的应用 基于k8s的工作流 容器和CPU那些事儿 kubevela源码分析 数据集管理fluid 应用管理平台kubevela karmada支持crd 多集群及clusternet学习 AutoML和AutoDL 特征平台 实时训练 分布式链路追踪 helm tensorflow原理——python层分析 如何学习tensorflow 数据并行——allreduce 数据并行——ps 机器学习中的python调用c 机器学习训练框架概述 embedding的原理及实践 tensornet源码分析 大模型训练 X的生成——特征工程 tvm tensorflow原理——core层分析 模型演变 《深度学习推荐系统实战》笔记 keras 和 Estimator tensorflow分布式训练 分布式训练的一些问题 基于Volcano的弹性训练 图神经网络 pytorch弹性分布式训练 从混部到统一调度 RNN pytorch分布式训练 CNN 《动手学深度学习》笔记 pytorch与线性回归 多活 volcano特性源码分析 推理服务 kubebuilder 学习 mpi 学习pytorch client-go学习 tensorflow学习 提高gpu 利用率 GPU与容器的结合 GPU入门 AI云平台梳理 tf-operator源码分析 k8s批处理调度 喜马拉雅容器化实践 Kubernetes 实践 学习rpc BFF openkruise学习 可观察性和监控系统 基于Kubernetes选主及应用 《许式伟的架构课》笔记 Admission Controller 与 Admission Webhook 发布平台系统设计 k8s水平扩缩容 Scheduler如何给Node打分 Scheduler扩展 controller 组件介绍 openkruise cloneset学习 controller-runtime源码分析 pv与pvc实现 csi学习 client-go informer源码分析 kubelet 组件分析 调度实践 Pod是如何被创建出来的? 《软件设计之美》笔记 mecha 架构学习 Kubernetes events学习及应用 CRI 资源调度泛谈 业务系统设计原则 grpc学习 元编程 以应用为中心 istio学习 下一代微服务Service Mesh 《实现领域驱动设计》笔记 概率论 serverless 泛谈 《架构整洁之道》笔记 处理复杂性 那些年追过的并发 服务器端编程 网络通信协议 架构大杂烩 如何学习架构 《反应式设计模式》笔记 项目的演化特点 反应式架构摸索 函数式编程的设计模式 服务化 ddd反模式——CRUD的败笔 研发效能平台 重新看面向对象设计 业务系统设计的一些体会 函数式编程 《左耳听风》笔记 业务程序猿眼中的微服务管理 DDD实践——CQRS 项目隔离——案例研究 《编程的本质》笔记 系统故障排查汇总及教训 平台支持类系统的几个点 代码腾挪的艺术 abtest 系统设计汇总 《从0开始学架构》笔记 初级权限系统设计 领域驱动理念入门 现有上传协议分析 移动网络下的文件上传要注意的几个问题 推送系统的几个基本问题 做配置中心要想好的几个基本问题 不同层面的异步 分层那些事儿 性能问题分析 当我在说模板引擎的时候,我在说什么 用户认证问题 资源的分配与回收——池 消息/任务队列

标签

controller-runtime细节分析 finops学习 kubevela多集群 kubevela中cue的应用 基于k8s的工作流 容器和CPU那些事儿 kubevela源码分析 数据集管理fluid 应用管理平台kubevela karmada支持crd 多集群及clusternet学习 helm 从混部到统一调度 volcano特性源码分析 kubebuilder 学习 client-go学习 tf-operator源码分析 k8s批处理调度 喜马拉雅容器化实践 Kubernetes 实践 openkruise学习 基于Kubernetes选主及应用 Admission Controller 与 Admission Webhook k8s水平扩缩容 Scheduler如何给Node打分 Scheduler扩展 controller 组件介绍 openkruise cloneset学习 controller-runtime源码分析 pv与pvc实现 csi学习 client-go informer源码分析 kubelet 组件分析 调度实践 Pod是如何被创建出来的? Kubernetes events学习及应用 CRI 资源调度泛谈 如何学习Kubernetes 以应用为中心 kubernetes operator kubernetes扩缩容 serverless 泛谈 自定义CNI IPAM docker和k8s安全访问机制 Kubernetes监控 Kubernetes 控制器模型 Kubernetes资源调度——scheduler Kubernetes类型系统 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 Kubernetes源码分析——从kubectl开始 kubernetes yaml配置 CNI——容器网络是如何打通的 当我在说PaaS时,我在说什么 《深入剖析kubernetes》笔记 Kubernetes存储 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件

AI云平台梳理

2021年08月18日

简介

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

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

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

《MLOps实践》

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

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

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

业界实践

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)

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训练平台。

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

美团

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

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

基础设施

功能侧从下到上:异构资源;异构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 的计算加速实践 对于音频训练场景(其它场景也很有参考意义)

Atlas 早期遇到的问题   早期问题的解决方案
存储带宽瓶颈 Atlas有上千块GPU计算卡,每块卡的计算能力非常强,存储带宽与IOPS要求比较高。但由于底层的分布式存储系统带宽有限,而且有些节点并发的带宽就达到数 GB/s,整个集群上千块 GPU 计算卡所需要的总体带宽非常大。带宽与计算能力之间存在差距,因此出现了部分任务计算效率较低。 在每个计算节点上限制最高带宽;存储侧基于用户级别用户的uid和gid对带宽与IOPS进行限制。
优先将任务调度到空闲的节点,添加调度策略,从根本上避免同节点竞争。但由于整体资源紧张,还是很难彻底解决。
提供单节点的多级缓存,任务提交与完成时,自动复制数据和删除数据。但该方案缺少自动化机制与元数据管理,且为单点实现,缺乏对缓存的控制。
同GPU节点的IO带宽竞争 像TTS场景下链路是单机单卡、或单机双卡或叁卡,同GPU计算节点会有5-6个用户链路。多个链路在同GPU节点上,出现了IO带宽竞争。通过监控可以看到,由于IO没有跟上,导致GPU利用率低。  
海量小文件 大量的Wav格式语音以及JPG格式图像散文件,这样的小文件太多会造成存储系统元数据压力大。 限制用户的文件数,要求用户将小文件聚合成lmdb、tfrecord 大文件的格式。但这种大文件格式对音频处理的模型降噪效果会产生影响;因此限制小文件并不能解决所有的问题。

一文读懂 高性能可预期数据中心网络近年来人工智能产业快速增长,但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 的机器学习实践

从神经搜索到多模态应用

其它

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

  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,一键部署。