作为当前两大核心IT发展趋势，AI/ML与容器已经被企业广泛应用。各个团队不断寻求将人工智能与机器学习工作负载良好结合的方法，而二者之间愈发紧密的结合也让企业不得不向各类商业及开源技术发出求助请求。
ISG公司企业技术分析师Blair Hanley Frank表示，“对IT领导者们来说，最好的消息莫过于过去几年来，在容器当中大规模运行机器学习的工具与流程都得到了显著改善。丰富的开源工具、商业产品及教程正在帮助数据科学家和IT团队启用并运行这类复杂系统。”
但在IT领导者与团队深入研究容器化AI/ML工作负载的基础技术之前，不妨先认真考虑以下几项原则。打好基础，未来的道路才能走得平稳而轻盈。
AI/ML工作负载代表的是工作流
根据Red Hat技术布道师Gordon Haff的观点，与其他各类工作负载一样，AI/ML工作负载的本质也可以被视作工作流。从工作流的角度加以审视，有助于阐明在容器内运行AI/ML的一些基本概念。
在AI/ML领域，工作流的起点始于数据收集与准备。没有这一步，模型不可能走得太远。
Haff强调，第一步就是数据的收集、清洁与处理。完成了这些环节，“接下来才是模型训练，即根据一组训练数据调整参数。模型训练完成后，工作流中的下一步就是部署至生产环境。最后，数据科学家们需要监控模型在生产中的性能，跟踪各类预测及性能指标。”
Haff用高度简化的方式描述了整个工作流，但其中仍然充斥着巨大的人员、流程及环境等相关工作量。为了提高一致性与可重复性，我们需要容器化工具协助简化整个流程。
Haff解释道，“在传统上，这样的工作流往往需要跨越不同环境、在两到三位负责人之间往来交接。但基于容器平台的工作流能够支持自助服务，帮助数据科学家轻松将开发好的模型集成到应用场景当中。”
与其他容器化工作负载相似的收益
Autify公司AI与ML负责人Nauman Mustafa认为，容器化技术在AI/ML工作流场景下拥有三大总体优势：
- 模块化：让工作流中的各个重要组成部分(例如模型训练与部署)高度模块化。这种收益在整个软件开发领域也有鲜明体现，即容器化支持下的高度模块化微服务架构。
- 速度：容器化还能“加速开发/部署与发布周期”。
- 人员管理：容器化还能“降低跨团队依赖性，让团队管理更简单。”与其他IT领域一样，工作内容会在不同职能团队间往来交换，而容器化有助于减少“交出去就算结束”的消极心态。
虽然机器学习模型与其他应用或服务有着完全不同的技术要求与考量因素，但容器化能够带来的好处仍然高度共通。
Red Hat公司数据科学家Audrey Reznik还提到，容器化在增强AI/ML工作负载或解决方案的可移植性与可扩展性(例如混合云环境)方面同样功效卓著，同时有望降低运营开销。
Reznik强调，“容器使用的系统资源要低于裸机或者虚拟机系统。”这又能进一步加快部署速度。“我很喜欢问「你的编码速度能有多快」，因为越早完成编码、就能先一步使用容器部署解决方案。”
各团队仍须保持一致
虽然工作流程的模块化程度更高，但各团队、各成员仍然需要保持密切的协同关系。
ISG公司的Frank表示，“要保证参与容器化环境下机器学习工作负载构建与运行的每位员工都能相互理解。运维工程师虽然熟悉Kubernetes的运行需求，但往往不了解数据科学工作负载的具体特性。另一方面，数据科学家对机器学习模型的构建与部署流程也许了然于胸，但却不擅长把模型迁移进容器、或者保持模型的稳定运行。”
容器化当然能够提高一致性与协作水平，但这些增益绝不会凭空而来。
Red Hat公司全球软件工程总监Sherard Griffin指出，“如今这个时代高度强调结果的可重复性，所以企业可以使用容器来降低AI/ML技术的准入门槛，帮助数据科学家轻松共享并重现实验结果，同时始终遵循最新的IT与信息安全标准。”
运营要求其实并没有变
容器化技术的各项优势对AI/ML的帮助与其他工作负载类型基本相同，这一点在运营中也有体现。因此在实际运营过程中，我们也需要像对待其他容器化应用一样认真思考以下三项运营要求：
- 资源分配：Mustafa指出，随着时间推移，资源分配是否合理将直接决定成本优化与性能表现。如果资源分配过量，那么我们必然浪费掉大量资源和资金;如果分配不足，肯定会遇上性能问题。
- 可观察性：看不见问题，绝不代表问题就不存在。Frank建议“应保证部署必要的可观察性软件，更全面地理解多容器应用的实际运作方式。”
- 安全性：Positive Technologies公司机器学习工程师Alexandra Murzina认为，“从安全的角度来看，在容器中启用AI/ML类解决方案跟使用其他解决方案并没有多大区别。”所以我们仍然应该把最低权限原则(包括对员工和对容器本身)、仅使用经过验证的受信容器镜像、定期运行漏洞扫描以及其他安全策略放在工作清单的前列。
容器不可能解决一切潜在问题
如同自动化没办法改善天然存在缺陷的流程，容器化也不可能解决AI/ML工作负载中的那些根本问题。例如，如果机器学习模型里存在偏见/偏差，那在容器中运行也丝毫不会改善产出效果。
诚然，容器化有着自己的独特优势，但这些优势绝非万金油、不可能解决一切潜在问题。面对数据错误或者是偏见/偏差，容器化唯一能做的就是加快工作流中的各个环节，也仅此而已。
凯捷工程技术总监Raghu Kishore Vempati表示，“容器特别适合用来运行AI/ML工作负载，但单靠容器化没办法提高这类模型的效率。容器化只是提供了一种能够提高模型训练与模型推理生产力的方法，但显然还有其他问题需要解决。”
自建还是采购，哪种方式更好?
与大多数技术选择一样，AI/ML工作负载的容器化领域也会带来“该这样，还是该那样”的困扰。而且这个问题并没有简单直观的答案。
目前市面上有着众多用于容器化运行AI/ML负载的开源项目选项。
Autify公司的Mustafa表示，“机器学习工作流的容器化进程会带来新的成本，而且这部分成本很可能超出小型团队的承受范围。但对大型团队来说，收益却可能远高于成本。”
所以，IT领导者及团队必须带着明确的目标或者理由推动容器化工作。Frank坦言，“总之，别让本就复杂的情况变得更加复杂。除非容器化机器学习负载能够带来超越精力投入的业务价值，否则最好别乱折腾。”
但这种价值已经渗透到越来越多的企业当中，也随着AI/ML的总体普及而不断增加。所以当“我们应该选择容器化吗?”的问题获得了肯定的答案，接下来要考虑的则是自建还是采购。
好消息是，各类容器化平台、工具与服务正在不断涌现，目前市面上有着众多用于容器化运行AI/ML负载的开源项目选项。比如Kubeflow就专门负责在Kubernetes上编排机器学习类工作负载。
这里分享一条普适标准，除非AI/ML工作流的容器化、部署与管理事务就是企业的业务核心，否则千万别在这方面耗费太多精力。Haff表示，“与云原生领域的情况类似，当团队过度专注于组装平台与工作流、却忽视了处理手头的实际业务问题时，也就离失败不远了。很多团队在平台构建完成之后，才意识到自己需要使用的是GPU资源，这时候再要调整已经来不及了。”
一旦遇到这种状况，团队只能把大量时间浪费在补救和处理设计失误当中，根本没工夫思考真正重要的模型开发、训练与推理工作。
Haff强调，“作为一种可行的办法，我们不妨选择统一的自助服务平台，例如OpenShift Data Science。它既能提供集成化工作流，也允许用户根据实际需求添加额外的开源和专有工具。”
另外，无论大家走的是商业路线、开源路线还是二者兼有，请务必为未来发展预留回旋空间。AI/ML生态系统每分每秒都在迅猛发展，我们自己的战略也随时可能有所变化，必须提前做好规划。
Reznik最后总结道，“别把自己绑在一家供应商身上。我们应该充分发挥各类开源解决方案的优势，不要满足于供应商摆在面前的那少数几种选项。方案的多样性越强，我们的团队就将拥有更多的创新可能性。”
