共计 6598 个字符，预计需要花费 17 分钟才能阅读完成。
本文整顿自第四范式技术日中第四范式技术总裁、根底技术负责人郑曌在主论坛的演讲。大家好，我是郑曌，很荣幸明天能代表第四范式，和大家分享第四范式在决策 AI 工程技术方向的翻新与实际，以及咱们基于此的一些思考。
在去年 2021 年 6 月，第四范式对外正式公布了开源凋谢的 AI 底层技术策略，通过过来一年的倒退，范式底层技术社区在技术落地、生态单干上都获得了显著的停顿，咱们也有幸和各位企业开发者、社区开发者独特见证了第四范式 AI 底层技术社区从 0 到 1，从无到有的成长。
目前，第四范式的底层技术以及商业产品，取得了社区开发者的宽泛关注和应用。截止到明天，咱们将全副 12 个底层技术方向社区进行了开源，其中超过 40 家企业退出社区，笼罩了互联网、金融、批发、制作、自然科学等多个行业与畛域；咱们目前有超过 1200 名社区用户参加到应用和奉献，咱们的镜像下载和部署累计超过 45000 次。底层技术社区的倒退，离不开社区开发者和生态合作伙伴对第四范式的信赖和奉献，在此，我代表第四范式，向所有参加范式底层技术社区奉献和建设的小伙伴们表示感谢，谢谢大家的反对。同时，咱们也欢送更多的开发者、生态合作伙伴退出到社区，独特合作将 AI 落地的门槛和难度升高，为 AI 开发者提供切实、好用的根底软件。在第四范式，除了提供当先的算法模型，咱们同样关注算法在利用中的规模化落地。从去年开始，第四范式围绕 AI 利用落地的三大外围生产因素：利用、数据和算力，将 AIOS 产品中的两大底层核心技术栈进行了开源，一个是机器学习数据库 OpenMLDB，一个是开源 AI 操作系统内核 OpenAIOS，帮忙开发者解决利用落地过程中遇到的痛点问题。
咱们认为，只有当算法从开发者的笔记本电脑走向生产集群，模型从摸索环境部署至生产环境，利用与真实世界产生合乎预期的相互影响，才是真正意义上的落地。明天如果模型的准确率做得再高再丑陋，然而模型没法进入到生产，没法注入到理论业务中，咱们依然只是夸夸其谈。将来十年，企业 AI 开发者面临的三大冲击在 2022 年，随同着更多的 AI 落地，第四范式和企业开发者、社区开发者一起将踩过的坑进行了积淀总结。咱们认为，企业 AI 开发者在将来将面临的冲击次要来自三个方面。**
**
冲击一首先是利用价值疾速落地的需要。我的项目周期紧、工夫不够用是明天企业开发者广泛面临的现状。究其原因，一方面 AI 的工具栈进入了百花齐放的阶段，然而工具链的碎片化也同样给开发者造成了困扰，开发者须要面临不同工具的技术选型，面临不同工具的学习和应用，在这个过程中，开发者还得迈过人工智能各个环节的平缓学习曲线；另一方面，AI 工程化的链路长、环节多，开发者在落地过程中须要进行重复的荡涤数据、重复的生成特色、重复的模型调参，每一个环节的失误都会造成业务成果的折损和我的项目周期的拉长。这是第一个冲击，利用价值疾速落地的需要。冲击二第二点是精准可信赖的数据供应。实际上，在 15 到 16 年，第四范式刚刚成立的时候，范式的小伙伴们发现，应用传统的数据库时，会有很多最佳实际、有很多材料能够参考，咱们能够比拟间接的从网上看到相干文章，间接拷贝源代码抄作业和学习，然而当我解决机器学习、解决所遇到的数据问题时，咱们却很难在网上找到领导，整个机器学习数据开发的过程不足一个像 Web2.0 时代 Spring Boot 相似的开发范式。最近 5~6 年，咱们看到随着数据的爆炸式增长，数据开发的工具越来越简单，一套残缺的机器学习数据系统往往须要 MySQL、Kafka、Spark、Flink、Hbase/Cassandra/Redis 等一系列数据组件的组合和搭建，大部分以互联网企业为代表的公司开始破费数以月计的工夫构建这样一套零碎。然而破费数个月搭建实现这样一套零碎之后，是否 AI 数据开发的问题就解决了呢。咱们察看到，绝大部分企业的数据科学家和数据工程师 依然在破费每个模型上月的周期用以数据开发迭代和排查数据的正确性，数据的时序穿梭、线上线下一致性、数据的闭环完整性这些生产问题开始耗费大量的数据开发工夫。而一份数据是不是正确的数据，他是不是生产可用，这份数据是否造成了业务成果的降落，这些问题充斥在数据开发的日常工作中，客户常常会和咱们感叹说：有的时候比没有数据更可怕的是不晓得数据到底哪里开发错了。实际上 IT 层面的技术封装和形象，无奈全面的解决数据正确可信赖的问题，咱们依然重度依赖于人与人的沟通、校验、对齐，而这种隐性沟通老本，事实上成为了企业数字化转型过程中最大的老本收入。这是第二点，精准可信赖的数据供应。冲击三第三个冲击来自算力，模型的表达能力越来越强是一个不可逆的趋势。随着模型的构造更大、更宽、更深，这些大模型、宽模型、深模型所耗费的算力也成指数级的回升趋势。明天咱们看到，业界有大量的技术和产品在优化简单模型的训练性能。然而，在 AI 利用的流程中，模型训练只是整个链路中的一个环节，模型训练在很多场景中，甚至只占到不到 AI 利用生命周期的 1%，线上推理零碎、数据处理、业务零碎都会波及到大量的算力占用。在理论开发过程中，很多企业开发者会遇到一个窘境，一方面 AI 芯片、AI 硬件、AI 服务器不够用，另一方面，站在 IT 的视角，算力的资源利用率又非常低，咱们无奈做出正当的判断，到底应该洽购更多算力还是优化以后的零碎。这是第三个冲击，来自算力的冲击。面临冲击的应答门路总结来说，企业 AI 开发者，明天须要面临来自利用、数据、算力等多方面的挑战，咱们认为，如何在这样一个高复杂度的环境下进行麻利的利用开发，这将会是将来辨别企业 AI 开发者能力高下的要害。
那么，在高简单环境下进行麻利的 AI 利用开发，企业 AI 开发者的应答门路是什么。咱们认为须要着眼于两个方面。
新办法首先是新的办法，在利用疾速落地的需要下，企业开发者应该尽可能专一在定义业务优化指标，在此基础上充沛利用软件和基础设施继续迭代，找到达成指标的最优解。相比基于流程的传统软件工程体系，这种价值指标驱动的模式，强调小步快跑、继续晋升，而不是依照传统软件我的项目的模式定指标、定打算、开发、上线、验收、结项。新工具当然，新的办法也须要搭配新的工具链配合落地。尽管有时候工具链的演进会比方法论走的更加靠前，然而决大多数时候，工具的变革都赶不上思维办法上的逾越。所以说，一个称手的工具，对企业 AI 开发者来说非常要害，就好比雷神托尔有了雷神之锤、钢铁侠有了钢铁盔甲，才变成真正的超级英雄。新工具——好工具？那么，什么样的 AI 根底软件算是称手的工具？咱们回到开始提到的三个挑战和冲击。首先在利用侧，面对利用价值疾速落地的需要，第四范式的主张是，一个称手的工具，该当让开发者聚焦最具价值的业务问题定义，让工具实现重复性工作，为开发者屏蔽掉繁冗的零碎细节。
在数据侧，咱们主张捕获真实世界精确、及时的反馈，通过工具和软件保障数据在线上线下、零碎内外部继续统一；
在算力端，咱们主张充沛的了解利用负载，面向每一个利用环节进行针对性的优化，将负载调配和调度到适合的算力设施上，最大化资源利用率。
第四范式的翻新和摸索基于此，最近一年，第四范式也在思考 AI 工具的翻新，咱们能不能构建一个 能够让开发者专一业务价值的工具链，能不能有一个 All in One 开箱即用、低学习门槛，易用易保护的工具，来解放大家的生产力。这些思考，也是第四范式进行新的 AI 工具翻新和摸索的最原始动机。那第四范式摸索了一些什么样的工具链，来应答新的工具链需要呢？应答疾速落地需要的重磅工具首先应答利用价值疾速落地的需要，第四范式的解法：北极星试验平台 +AutoML 主动机器学习
北极星平台为开发者提供了疾速进行翻新和迭代的最佳工程实际，可能帮助开发者聚焦最具价值的业务问题定义，撑持疾速、持重的价值迭代。通过高效迷信分流算法，开发者能够升高一次验证一种计划的高试错老本，有能力并行进行海量的试验；通过挑战区与冠军区的机制，开发者能够确保上线成果的稳固可控，反抗业务稳定的不稳固；通过多环境综合验证，开发者能够应用到业务仿真沙箱，以芯片设计验证级别的仿真环境，在构建试验的过程中逐渐修改咱们的智能零碎，从而提前预知试验的缺点和成果；咱们再看 AutoML 主动机器学习零碎，AutoML 次要负责主动进行数据工程和算法工程，帮忙开发者进行自动化的 AI 全流程，他相当于是一个机器人，咱们用机器人去代替人建模，缩小开发者在简短流程中的重复劳动。第四范式在 AutoML 的方向上，除了业界当先的算法成果，咱们在工程上的指标是做到极致的 TCO 和性能。通过第四范式的软硬一体技术，咱们不仅将 AutoML 的 TCO 算力老本升高至 Google 的 1/10。在过来的一年工夫里，咱们在主动跨表特色加强、主动深度稠密神经网络等方向进行了粗疏的工程优化，以 FeatureZero 和 AutoDSN 为代表的工具组件，帮忙咱们在性能上取得了超过 10 倍的晋升，在内存耗费上取得了超过 70% 的节俭。在下午的技术分论坛中，咱们的架构师也会为大家带来工程优化的开展介绍。
应答数据挑战的重磅工具解决完利用价值疾速落地的需要，咱们再看看数据的供应。咱们的工程指标是通过欠缺的数据系统，去捕获真实世界精确、及时的反馈，同时确保数据在线上线下、零碎内外部的统一，最终做到开发者能够释怀、省心的应用零碎开发进去的数据和模型。这件事件听下来十分重要，但为什么长久以来始终没被解决。咱们看到，随着数据侧的技术演进，数据系统记录行为、反馈数据的能力越来越强，机器参加人机协同的决策也从不可能变成了可能。以数据库系统的演进为例，晚期的 DBMS 零碎，它的设计指标是如何去把数据和信息记对记全，进入到互联网时代，来自传感器的数据越来越多，数据量级越来越大，再到明天，像 HTAP 和云原生等技术的成熟，让数据系统有能力提供更大量级的解决能力
尽管如此，数据品质依然制约了最终 AI 的业务成果，理论落地过程中，数据工程师明天依然有超过 90% 的精力花在数据的建设上。尽管机器学习技术的冲破让机器有能力帮忙人实现相对感性和刹时高效的推理判断，然而不论是事务型数据库、剖析型数据库还是传统数仓，面向机器学习都无奈保障正确的数据供应。
数据的第二个挑战是时效性。明天咱们常常会看到依赖于大数据框架的离线批量机器学习零碎，通常来说，这些离线批量工作会通过 cron job 解决 小时级别甚至是天级别提早的数据。
事实上，这样的零碎设计会遇到十分多的问题，比方 cron job 运行间隙的新用户冷启动问题，比方无奈刻画长尾用户和长尾物料的个性化特色，比方 session 内的行为用意特色无奈刻画，比方长时间运行的离线数据工作很难 debug，这些问题，背地除了对数据开发效率的影响，更重要的，是因为数据的不陈腐导致模型成果的折损。因而，第四范式认为，数据时效性的好坏，将间接影响模型成果的好坏。数据工具的第三个挑战，是数据线上线下不统一造成的隐性沟通和决策老本。
这个数据不统一是呈现在，当咱们在做线下算法摸索的时候，咱们写的代码，往往须要在上线的时候，把这部分数据开发的逻辑再开发一遍，从大数据和数仓零碎的 ETL 代码转换成线上业务零碎的实时计算代码，咱们看到，目前机器学习上线难，有 90% 以上的问题和 bug，源自于这两段代码不统一。而这会触发两个开发角色不停的比对代码，不同的校验后果，以确保数据的统一。而应用过期的数据，应用不统一的数据，最初造成的灾难性结果，就是因为人可能出错的中央太多，导致咱们不晓得数据是否真的出问题了，以及数据在哪个环节出问题了。那咱们是怎么解决这个问题的呢？咱们提出了一个对立的数据开发零碎：开源机器学习数据库 OpenMLDB**
**
通过对立的一致性执行打算生成器，应用规范易学习的 SQL，去对立线上和线下数据计算的执行逻辑。做到线下摸索的特色能够一键上线投产。
因而，很多企业开发者也把 OpenMLDB 叫做 Feature Store Plus，一个领有数据计算、解决、上线能力 且 线上线下统一的 特色平台。
在过来的一年工夫里，OpenMLDB 与 DataOps、ModelOps 和 ProductionOps 层泛滥开源技术组件造成了残缺的 AI 利用全流程生态，在今天下午的技术分享中，OpenMLDB 团队，也将为大家展现如何在开源机器学习平台上，通过 OpenMLDB 构建一个残缺的 AI 利用。OpenMLDB 的社区合作伙伴和社区企业用户也将为大家分享他们的实际。
往年 1 月，通过收集客户和社区的反馈，咱们在 OpenMLDB 的根底之上，构建了一个 从 T +1 批量数据系统向 实时数据系统 切换的最佳工程实际 Profile Engine。通过 Profile Engine，咱们可能在兼顾批量计算与实时计算的前提下，保障批量、流式计算逻辑和后果的统一。
那 OpenMLDB 到明天曾经开源一年工夫了，到明天为止，OpenMLDB 曾经公布了 6 个版本，这个过程中，OpenMLDB 落地了包含互联网风控、举荐零碎、用户标签零碎、AIOps、AIoT 设施预警等机器学习场景。
咱们也欢送对 OpenMLDB 感兴趣的开发者小伙伴，可能退出咱们的社区，和咱们一起独特建设机器学习数据开发的最佳体验。应答算力老本高的重磅工具说完了利用和数据，接下来咱们看下如何破解算力老本的挑战，在解决这个问题的过程中，第四范式的工程思路是通过对软件负载的深度了解，从软件应用负载的全流程登程充分利用 AI 异构算力，在具体的落地过程中，第四范式的工程团队，会面向机器学习落地的每个环节，从计算、存储、通信、调度等几个维度别离排查零碎的算力瓶颈在充沛了解各环节瓶颈之后，咱们再进行头痛医头脚痛医脚的工程优化，将瓶颈一一击破。
往年，第四范式也进一步降级了软硬一体优化的技术，除了面向机器学习工作负载，咱们重点进行了全流程数据处理的算力优化和改良，通过 ReCA 第二代 可重配硬件加速架构，咱们能更灵便的在加速卡上拓展数据工作的负载优化。目前，第二代 ReCA 加速卡能够在零业务代码批改的状况下，实现音讯队列、Spark 离线大数据计算框架、Redis、Elastic Search 等泛滥数据组件进行算力优化。
在 ReCA 的加持下，机器学习整体的机器时有了大幅的节俭，以一个端到端的举荐场景为例，ReCA 相比 Tensorflow + GPU 的计划做到了高达 6 倍的机器时节俭。建模工夫也从 2 周缩短至 2 天。
此外，除了规范卡外，ReCA 也提供了 Made In China 版本，为开发者提供 MIC 国产算力的选型，为国产 AI 服务器提供软件定义的算力优化计划
应答 GPU 调用问题的重磅工具除了第四范式自研的加速卡外，面向 GPU，第四范式同样从软件负载登程最大化应用和调度 GPU 资源，往年，咱们也正式对外公布了 OpenAIOS 云原生 vGPU 解决方案，帮忙咱们的开发者实现显存的超售，通过主动将内存置换成显存的机制，让 GPU 反对数量更多、规模更大的 GPU 工作。在今天下午的技术分享中，咱们也将为大家演示，如何在一台 GPU 服务器上，同时运行 20 个 Resnet。咱们也欢送感兴趣的开发者小伙伴们退出 vgpu 社区，和咱们独特交换、探讨。
最初那明天演讲的最初，我想借机会总结一下第四范式对 AI 工程技术的观点和设计理念，咱们认为，决策 AI 的实质，是软件系统和真实世界进行合乎预期的相互影响。在这个过程中，咱们须要继续的关注 算法、数据 和算力三个维度。在算法端，咱们重点投入的方向是，稳固可验证的决策与反馈动作、疾速的试验与试错、真实世界细致入微的表白；在数据端，咱们的工程设计理念是，继续的晋升捕获真实世界及时陈腐变动的能力，保障数据线上线下的一致性，构建行为 - 反馈的数据闭环。在算力端，咱们将继续保持软件定义算力的长期主义，面向利用负载的全流程进行针对性优化，同时保持提供稳固、牢靠的国产化代替计划。
第四范式的工程技术组件也是围绕上述算法、数据、算力方向的工程理念进行的摸索和打造。咱们明天十分的荣幸，十分的快乐，能与各位企业开发者一起探讨 AI 的问题，心愿和各位开发者能有更多的交换、探讨和更加严密的单干。将来，第四范式也会保持围绕这三个 AI 外围因素打造开发者青睐的、称手的工具链，和企业开发者小伙伴们一起，缩小 AI 落地过程中的踩坑，更高效更疾速的落地 AI 利用，在高简单环境中迈向决策智能时代。谢谢大家！1END1
