架构师（2024 年第二季）

CONTENTS/目录 大模型时代的架构思维 热门演讲实录|QCon 章文嵩、蒋晓伟、李飞飞、张凯巅峰对谈：大模型时代的数据智能新趋势半年涨粉1000万！揭秘快意大模型在短视频互动场景中的大规模应用实践通往AGI之路，数据系统还需挑战哪些物理极限？ 跨平台CPU加速，百度智能云的一键性能调优技术分享 特别专题|Kubernetes十年回顾 AI时代，这个团队正在打造全世界最复杂的高性能编辑器云时代下，云和开源软件厂商如何共存共荣？ Kubernetes十年：盛宴已过，长路漫行Kubernetes前首席架构师：漫谈K8s十年技术史 摆脱AI生产“小作坊”：如何基于Kubernetes构建云原生AI平台OpenAI：我们将Kubernetes扩展到了7500个节点 为什么Kubernetes对于我的SaaS业务来说是一个错误 不敢把数据库运行在K8s上？容器化对数据库性能有影响吗？Kubernetes开源10年，但我们已经有了8年的踩坑史 推荐文章|Article 专访阿里云张凯：Kubernetes是如何从云原生走向AI时代的？ 大模型应用的10种架构模式 Meta如何搭建训练Llama3的基础设施InfoQ2024年趋势报告：架构篇 蜂窝架构：一种云端高可用性架构金融企业落地大语言模型的路线图 知乎：多云架构下大模型训练，如何保障存储稳定性？ 为什么又造了个新词DataWarebase：我看到了AI时代数据平台应当的样子老架构师总结的12个软件架构陷阱 II 架构师2024年第二季 本期主编Tina 流程编辑丁晓昀发行人霍泰稳 反馈feedback@geekbang.com 商务合作hezuo@geekbang.org 内容合作editors@geekbang.com 热点访谈|Interview 禁令再升级！拜登政府已不想让中国人在美从事AI工作了 巴菲特股票暴跌99%！软件bug造成万亿美元市值蒸发，技术专家：他们的IT水平不如国内大厂 10天吸粉1900万，“幻兽帕鲁”将无数技术小白逼成了服务器大佬闭关4月，这支年轻的创新团队如何做出国内首款C端大模型App把大模型装进手机，小米、OPPO、vivo卷起来了！ 卷首语 用过去的智慧引导AI变革 Kubernetes已经存在十年了。在过去的十年中，云计算和Kubernetes因其可扩展性、高效性和操作灵活性，作为革命的中坚力量脱颖而出。云服务实现了轻松的资源扩展，而Kubernetes则实现了容器化应用的自动化部署、扩缩容以及运行，让开发者能够更专注于应用的开发而非基础设施。 尽管好处多多，Kubernetes也带来了配置管理的复杂性，因为最佳实践的不一致可能会带来大量的配置债务。Kubernetes社区开发了各种的工具和实践，比如用于管理软件包的Helm图表、负责自动化应用管理的运维，以及Terraform等基础设施即代码（IaC）工具，以及用于高效配置的CI/CD管道。 另一方面，AI发展是和云服务及Kubernetes快速发展一同进行的，通过增强决策和任务自动化等新功能彻底改变业务的运营方式。然而，正如云和Kubernetes中发生的一样，这种快速发展可能会导致另一轮由配置带来的技术债务。AI系统的配置复杂性极高：只有正确地配置AI技术栈、算法、数据管道和模型，才能收获最佳的性能、可扩展性和安全性。 AI技术栈中的错误配置会导致数据摄取管道的管理不善、模型训练效率低下，以及安全防护测试不足的问题。要应对这些挑战，我们不能再重复在云和Kubernetes中犯下的错误。 有效的治理和清晰的配置管理策略对维护系统的完整性和合规性至关重要，这点在 快节奏的AI创新中尤为重要。为避免AI开发中的配置债务，企业可以向云计算和Kubernetes取经，着重关注战略规划、自动化，以及持续学习的文化。通过这些经验教训，AI的发展道路将更为清晰，这项技术能实现其变革的潜力，同时还能避免技术债务。我们还需要培养一种优先考虑持续改进的文化可以帮助团队紧跟最新技术。这些策略可以确保有效且高效的AI系统管理，从而摆脱配置债务的负担。 大模型时代的架构思维 编辑华卫 嘉宾|郭东白，Coupang副总裁 对于一名架构师，最能让其感到兴奋的词汇莫过于“重构”。只要有重构的需求，就意味着有工作可做。 在大模型时代，全球范围内的大模型正在重新定义软件的面貌。在当前的世界正在重新定义软件的背景下，作为架构师应该如何应对？面临哪些机会和挑战？这些都是本演讲想要探讨的主题。 本文由InfoQ整理自QCon北京2024主论坛演讲《大模型时代的架构思维》，经郭东白老师授权发布。以下为演讲实录： 本演讲将从大模型讲起，分析大模型的本质及其影响；然后我们将探讨大模型如何影响软件研发，以及它对软件架构的冲击是什么；最后将讨论我们应该如何应对这些挑战和冲击。这是一个清晰的逻辑过程：首先理解问题，然后制定应对策略。 大模型时代的新生产力 大模型的基本原理很简单：你有一套训练数据，通过训练生成式模型，产生许多候选样本，然后人工挑选出较好的内容。接着，使用验收模型将人工挑选的过程自动化。这样一来，我们就形成了一个从生成式模型到验收模型的完整过程。当这个过程上线后，就可以形成一个循环，使得模型能够持续学习和进步。 大模型的突破之处在于其处理大量数据的能力，这使得它能够涌现出类似语义理解的能力。这让我们可以感觉到，大模型似乎能够在完全不同的语境中，甚至是跨越传统意义上的语言界限，实现近乎无损的语义转换。这就是大模型突然变得如此热门的原因。 事实上，我在一年前就已经在网易的一次演讲中提到了这些观点。我认为这个逻辑非常强大，它解释了为什么大模型对我们程序员或者说我们这个行业的冲击是最大的。大模型的冲击并不在于我们现在讨论的各种应用，而是在于它改变了传统软件开发中的角色。在传统软件中，生成式模型和验收模型都是由程序员和测试人员来完成的。但现在，生成式模型和验收模型都变成了机器模型，这就改变了程序员的位置。 如果你有一个从需求到代码，再到测试的映射过程，并且这些过程都能够进行自洽性验证，那么你可以在多种语言、不同的编译环境、测试环境和运营环境中形成多次约束，确保整个语义系统的正确性。这就是我们所说的闭环，而这个闭环在我们的领域是第一个形成的，它是一个非常强的语义闭环。因为它所施加的约束是严格的：代码要么无法运行，要么运行结果与预期验证结果不一致，这些都是容易出现的错误。在大模型出现之前，我们已经能够进行许多自动化测试，包括半自动化和半智能的测试。而大模型的出现使得测试过程变得更加迅速。拥有了这种能力之后，我们需要重新审视程序员的价值所在。如果产品和用户能够利用生成的文档来完全验证开发过程，那么在许多情况下，程序员的角色可能变得多余。 从今天的角度来看，我去年写的幻灯片其实已经完全成为事实了。图灵测试已经通过，人类的简单意图可以在代码层面上做到无损，而且成本低了很多，提高了好几个数量级的速度。 对于程序员来说，我们正处于不同的时代轮换中。在大模型时代到来时，它应该成为主要的生产力。就像马车时代马的重要性一样，在汽车时代汽车成为主要生产力，在大模型时代，大模型就是为该场景提供主要生产力。这意味着，并不是说大模型要取代所有人，而是如果一个人加上一个模型就比三个人快，那就已经很好了。就像汽车和马车一样，马在当时也是非常重要的生产力。我还记得之前举过的例子，直到现代社会发明蒸汽机之前，马一直具有很高的价值。在不同的社会中，马的价值是人的价值的三倍。如果某样东西的价值是你的两倍，那么它必然会取代你。这是一个非常有意义的观点。 大模型会如何影响软件研发 接下来我想谈谈大模型对软件研发的影响。在我的极客时间架构课程和书中，我描述了传统软件研发中架构师的角色，通常被限定在一个相对较小的范围内。实际上，一个真正的架构师应该拥有更广阔的视野，考虑的因素应当包括人员、目标、经济价值、环境、过程控制以及文化等多个方面。 当我们进一步审视这个问题时，我们可以思考AI，特别是大模型，对这些架构要素的影响程度。在这些架构要素中，哪一个会受到最大的影响？在进行大规模的架构活动， 比如重构时，我们必须为这个活动设定一个明确的目标。这个目标定义了我们努力的方向和期望达成的成果。我们需要明确这个目标是什么，并考虑如何衡量成功与否。 人性是一个极其重要的元素，正如韦青老师之前提到的，它在架构中扮演着关键角色。人性涉及到参与者，包括目标用户的人性。这些因素会如何影响你的软件架构呢？此外，软件架构始终是一个成本问题，在任何企业中，成本都是不可忽视的因素，还有当前的计算软件环境。 我的评估是，大模型对我们最大的冲击在于成本方面。这种冲击可能会持续今后几年。人们关注大模型并不仅仅是因为它们有趣，而是因为它们能够以更低的成本完成工作。例如，在数据标注任务中，与传统的人工标注相比，使用大模型来生成样本的成本更低，而且生成的样本与人工标注的样本具有相同的价值。这就使得人工标注变得不再必要，大模型的引入成为了一种替代人工的过程。 从能力的角度来看，大模型对传统架构师的影响是客观存在的。我之前已经分享过相关的幻灯片，今天我们再次审视这个问题，即大模型的到来到底对哪些方面产生了冲击。其中，红色标记的部分显示，代码交付这一环节受到的冲击最为严重，这种冲击不仅限于未来，而是已经从现在就开始了。 在当前的软件开发环境中，即使是像兼职架构师这样的角色，也需要进行进度沟通等工作。然而，这些工作的价值已经不如以往。因为现在我们可以通过代码自动生成的 总结来更准确地了解代码的改动情况，这种自动化的总结比人工编写的总结更为可靠。它能够清晰地展示出具体的代码更改，而不仅仅是描述完成了哪些任务。 在整个软件开发过程中，越是偏向个体研发的能力，受到的冲击就越大。换句话说，那些依赖于单兵作战的开发工作，如编写代码、调试等，更容易被自动化工具和智能系统所取代。而越往下，即越偏向于对整个开发场景的控制和管理，这些工作受到的冲击相对较小。 大模型对软件架构的冲击 当我们意识到这些冲击必然会发生时，作为架构师或至少是决策者，我们应该采取什么行动呢？我们是与软件架构相关的独立决策者，我们应该考虑做些什么？ 首先，我们需要思考我们要做什么决定，必须清楚我们到底是为企业创造了什么价值。我们需要分析出我们的价值，并在之前创造的价值不再存在时重新定位。作为架构师，真正的价值创造来自于弥补其他人决策盲区，这一点非常重要。你之所以被认为是架构师，是因为你能看到别人看不到的东西。 在大模型时代，我们必须认真思考：大模型时代是否存在决策盲区？这些决策盲区在哪里？大模型的出现是否会导致新的决策盲区？举例来说，钉钉正在研究AI模型，这些模型涉及数千个人工智能代理和人类之间的网络配对。例如，他创建了成千上万个这样的配对。在这些配对中，你该如何应对？你在这种情境下如何改变自己在这个新的决 策环境中，你能弥补的盲区的价值定位是什么？我认为最重要的一点是，当前的大模型无法回答的问题。 大模型的盲区就是架构师创造价值的所在。实际上，关于我在《架构思维，从程序员到CTO》这本书中提到的每一个架构要素，大模型都无法回答。第一个要素是大模型不知道你要解决什么问题。比如你要开发一个操作系统或做一个AI代理，你要解决什么问题是别人无法知晓的，作为架构师必须清楚地知道你的商业目标是什么。同样，人性方面，大模型的引入会改变某些人性机制。我们本来具有怎样的人性？现在突然引入大模型，会影响我们的人性。尽管大模型本身可能不具备人性，但是它的引入会给企业软件开发带来人性挑战。开发人员会怎么想？用户会怎么想？用户可能并不关心软件是由程序员编写还是由大模型生成的，但是企业人员可能会关心。经济价值会发生何种变化？收入和成本会发生巨大变化，因为作为架构师，你组织的架构活动中最大的成本是人力和时间。有了大模型，这两个成本都会发生巨大变化。你应该如何应对这些变化？还有环境和各种过程，