AI架构设计5：CN+AI的三国杀

庞德公

已于 2024-05-28 16:49:17 修改

阅读量895

点赞数 16

分类专栏： AI架构设计文章标签：人工智能 LLMops 自然语言处理 GPU

于 2024-05-24 10:00:54 首次发布

本文链接：https://blog.csdn.net/Janexjy/article/details/139166972

版权

AI架构设计专栏收录该内容

7 篇文章 1 订阅

订阅专栏

本文最后的图展示了气势磅礴的AI+CN（云原生）的技术栈，潜藏着无限的杀机。还在云原生的时候，研发和运维一直围绕着Devops进行两国杀。CN+AI的时代，数据科学家加入了战局，彻底变成三国杀。边界的不断互相渗透，全栈的人才最宝贵，抑或要找到新型的跨团队合作模式。

机器学习管道

Pipeline翻译为管道其实不大贴切，翻译为流程较为妥当。AI平台的架构设计离不开基本的ML流程。正因为人工智能的规模化扩展和低延迟性的需求给传统的架构设计带来了挑战。虽然基于云原生的架构灵活和高扩展，但是它又不得不面对新的挑战。

典型机器学习流程包括，数据准备（收集、清洁/预处理、特征工程）、模型训练（含模型管理，测试与超参数调整）、CI/CD（含模型仓库与存储）、模型服务、应用与系统监测（负载、模型漂移、安全性）。若是AI基于云原生，那么在各个环节的挑战又什么，又应该在设计的时候考虑到哪些维度？

数据准备挑战

在架构设计的前期阶段可以按照摩尔定律预估数据规模，按照每隔18个月增加一倍的进行预估。数据格式和数据源一定是多样化的。开发环境和生产环境通常会存在差异，部分是因为分布式计算带来的复杂度（例如分区和同步）。

以Spark的数据处理引擎而言，SQL为用户提供标准化且熟悉的使用体验。无论用户在本地进行原型设计还是运行大型的分布式计算任务。然而，机器学习工作负载没有行业标准接口。一般而言，数据科学家在本地使用小型数据集利用Python语言进行研发，然后量产团队（分布式系统工程师）需要采用新编程语言或者调整算法重新编写脚本以便后期的分布式运算。

一旦分布式的机器学习任务未能按预期运行，数据科学家可能需要本地 Python脚调试。整个过程效率低下，而且常常经常找不到问题所在，即便有好的可观察性工具和可再现的容器技术。

潜在可行的解决方案第一个是使用行业标准接口来支持端到端的机器学习生命周期。例如，可以利用PyTorch或TensorFlow等本机ML框架创建训练代码，并通过在Python运行时本地运行来验证它。然后用户可以轻松地重用相同的代码，并利用Kubeflow的Python SDK通过Kind/Minikube以分布式方式在本地运行此代码，或者通过使用相同的代码将其部署到远程大型 Kubernetes 集群来轻松扩展其训练代码。另一种选择是使用通用分布式计算引擎，例如Ray，其计算抽象还使用户能够在本地和生产环境中无缝运行相同的 Ray 脚本。

另外在数据监管层面，架构设计时候需要考虑到隐私、安全、权限管控、血缘追踪和数据偏差。

模型训练挑战

大模型正在快速的推动云原生的边界突破，以便于满足不断增长的人工智能/机器学习训练和推理计算需求，同时各类的加速器正在变得流行。正如前面提到的，云原生通过利用容器化、微服务和可扩展云基础设施的固有功能，简化了人工智能工作负载的编排和调度。复杂的人工智能工作流程可以分解为模块化组件，从而更容易独立管理和扩展特定功能。

这里包括多家供应商提供的具有不同功能的GPU，到Google的TPU、Intel的 Gaudi，甚至FPGA。这些不同的计算资源需要虚拟化支持、驱动程序、配置和共享的能力以及云原生的调度增强。加速器的可用性和成本受限的前提下，人们更多的探索云资源，甚至天空计算（Sky Compute 智能地连接不同的云服务器，它利用负载平衡实现了每个设备的统一处理时间，确保计算任务的一致完成并优化整体训练时间。）。

GPU是一种宝贵且需求旺盛的资源。能够更有效地管理基于GPU的AI任务的共享和调度对于 AI任务的成功至关重要。这里比较大的挑战在于GPU虚拟化和动态分配方面，将云原生技术用于于 AI会比较复杂。vGPU、MIG、MPS和动态资源分配 (DRA) 等技术使多个用户能够共享单个 GPU，同时为相同Pod中的容器之间提供隔离和共享能力。除此之外还提高了GPU的利用率，从而降低成本。

一些经过充分测试的工具用于解决高级调度需求（二进制打包、放置、资源争用和抢占）。这些工具对于AI云原生的蓬勃发展起到很关键的作用。通过Yunikorn、Volcano 和Kueue等努力，Kubernetes 中正在不断进化更好的调度支持。后两者解决了批量调度问题，这对于高效的AI/ML训练特别有价值。

模型服务挑战

AI的能力总归是要输出，那么如何输出。云原生基于微服务架构，将ML流程中的每个阶段作为单独的微服务进行处理，对AI构成一定的挑战。很多组件在同步输出结果和任务切换变得困难。即便用户在单机上使用这些解决方案，他们仍然需要创建数十个Pod。这样的复杂度使得基础设施缺乏灵活性来适应多样化的机器学习任务。

其次，基于微服务的机器学习架构会让用户体验支离破碎，或者换句话说对用户的能力提出更高的要求。例如，用户需要构建容器映像、编写自定义资源 YAML 文件、使用工作流程编排器等，而不仅仅关注他们的ML Python脚本。这种复杂度还体现在更陡峭的学习曲线，要求用户学习其专业知识和/或兴趣之外的许多系统和技术。

机器学习模型生命周期中若存在不同的软件和系统，那么成本会显着增加。机器学习生产环境托管在多个微服务中，具有单独的数据处理、模型推理和业务逻辑步骤。基础设施拆分涉及复杂的资源同步管理，降低了开发和模型发布的速度。若是采用Ray构建了一个统一的ML平台，增强了其生产环境的性能，会让ML的推理总成本一年降低了近 50%，主要归功于资源共享以及节省跨阶段的序列化和反序列化过程。