今年技术除了 AIGC 真没啥看头？别让“网红效应”遮住了真正的创新！

编辑 | Tina、褚杏娟

过去一年，我们经历了许多意外瞬间，或许当时我们感到有些措手不及，但现在回首一望，这一切都变得一目了然。这正是我们每年对各领域进行盘点的意义所在，我们追求的是在迷雾中找到清晰的方向。

而在 2023 年，这一盘点显得更为特殊。比尔·盖茨指出，过去 12 个月人工智能领域发生的事情“与个人电脑或互联网一样重要”。大模型项目在过去一年中如雨后春笋般涌现，这波创新浪潮给各领域都带来了巨大的变化。

然而，除了 AIGC 领域取得的突破外，在前端、架构、运维和云计算等领域中，也涌现了一系列引人瞩目的进步和革新。在年终盘点之际，InfoQ 邀请到了黄玄（Hux）、曹立成（蒜蓉）、罗广明、董晓聪、杨振涛、张凯，分享在过去一年中各自领域的创新和进展，为我们揭示未来技术发展方向。

前端遇到麻烦了吗？

前两三年，前端技术的发展相对平稳，主要以 React、Vue 等成熟框架的演进为主。但今年，前端技术的发展呈现出新的活力。

编程技术的多样化

相比于过去“各司其职”井水不犯河水的光景，今年大前端领域的各种语言和技术边界都在面临打破和重建。

新兴系统语言 Rust、Zig 已经通过 Rspack、Bun 这样的工具链切入到广大开发者的日常工作中。而 WebAssembly GC 的落地，以及 Static Hermes 这类 JavaScript 原生化探索，也继续宣告着大前端技术进一步“下沉”系统的趋势。

另一边，无论是 React Native、Kotlin Multiplatform、Flutter 以及国内各大厂自研跨端技术的愈演愈烈，还是 Web 领域 JavaScript 框架 Next、Remix、Astro、Qwik、Fresh 纷纷侵蚀服务端的阵势，则宣告着大前端技术进一步在应用层“泛化”的趋势。

我们有理由相信，虽然由 React，Vue 引领的声明式编程范式趋于稳定，但是在性能和应用元框架领域，大前端技术处处都在孕育着新的可能性，我们说不定就在大前端又一轮百花齐放的前夜。

终端平台多元化，前端迎来新机遇

在剧烈变化的环境下，大家可能会更关注生存问题，2023 年，虽然“前端已死”的论调不绝于耳，但这一年也在终端平台上孕育了新的可能性。

去年 6 月，在一年一度的科技春晚 WWDC 上，苹果发布了 Vision Pro。目前，苹果已正式推出 Vision Pro 应用商店，百万款 App 准备上架；去年 9 月，Meta 发布 Quest 3，对打苹果。MR 设备设备的发布，表明硅谷并不服气华尔街资本的短视，依然在为元宇宙成为下一代计算平台而蓄势待发，XR 与图形作为大前端的一个垂类，值得军备和持续关注。

小米澎湃 OS、vivo 蓝河 BlueOS 等国产操作系统先后发布，HarmonyOS NEXT 也在去年 8 月华为开发者大会上第一次公开亮相。其中，HarmonyOS NEXT 的进展受到大量关注，华为的“1+8+N”战略，即以手机为核心的全场景智慧化（物联网）战略，一旦成功了，未来更多厂商 OS 都会涌现出来，大家都可以摸着石头过河。

这将能打破国内移动原生软件平台生态双足鼎立的现状，大概率会像小程序生态的碎片化一样，对国内大前端领域从框架到工程到行业分工，提出新的机遇和挑战。

鸿蒙大考，你准备好了吗？

今年 9 月鸿蒙将跟安卓彻底切分，仅支持鸿蒙内核及鸿蒙系统的应用。同时，原生鸿蒙的开发语言以 ArkTS 为主，不同于 iOS 开发使用的 Swift 语言，以及安卓开发使用的 Java 语言，且不支持打开 APK 文件，开发环境与 IDE 深度绑定，这意味着如果使用今年的最新版本，会跟 iOS、安卓产生巨大的割裂。

开发者需要维护包括 iOS、安卓、Web 以及鸿蒙在内的四端体验一致。生态体验是风险，但这对开发者来说，也代表着新的岗位的出现。

在 QCon 闭门会上，有鸿蒙技术专家透露出一个特别积极的信息：鸿蒙开发供不应求，连外包开发价格都水涨船高。举例来说，假如原来一位外包价格在两千元左右，现在只要做过两个月的鸿蒙功能，价格就翻了一倍。做六个月的，价格可以达到 5-6000 元以上。

他还表示，鸿蒙项目非常受欢迎，只要沾上边，就会有大批公司去抢人。尤其像美团、京东等公司，开出的价格都很高。

鸿蒙官方表示，首批 200+鸿蒙原生应用已启动开发，其中 100+完成了鸿蒙原生应用 Beta 版本。

鸿蒙适配之路，协议是第一步。就像盖房子需要地基一样，没有协议作为基础，开发者就难以下手。设备、教程、专家指导等关键资源，都依赖于双方明确的权利和义务。

有企业向 InfoQ 表示，其与鸿蒙系统的合作目前仍处于前期阶段，尚未进入驻场开发环节。目前的工作主要集中在备忘录签署和深入调研适配过程所需的开发资源上，包括主应用程序的重写需求评估等。

基于目前的研究，该企业认为适配鸿蒙系统存在一定难度，部分功能可能需要完全重写。为应对开发过程中的挑战，该企业的内部相关团队已开始进行技术储备。

另一家商业银行表示已完成其鸿蒙应用的第一版 demo，该版本基本涵盖了应用所需的功能，得益于采用了类似于 H5 的开发方式，使得大部分功能得以顺畅实现。然而，正如 28 定律所言，剩余的 20%难题往往占据了 80%的时间和精力。在该案例中，最大的挑战在于 SDK 适配，比如存在一些使用了不同企业的技术的 SDK。该银行接下来将专注于解决这一问题，对接 SDK 并对每个业务进行深度调试，以确保应用的稳定性和功能完整性。

AI 会取代前端开发吗？

当然，今年的一切“之最”都离不开 2023 年作为“生成式 AI 元年”带来的颠覆性变革，前端也不例外。大家都在研究怎么把这个黑科技融入工作流，让开发效率飞升。不过，也有不少人心里打鼓：“AI 不会把我这份前端饭碗端走吧？”

虽然今年还不用担心失业危机，但不可否认，AI 确实为前端打开了一扇大门，潜力巨大！

一方面，前端工作流程中的诸多环节，包括 PRD 到代码，从设计到代码，或者是 Github Copilot、Vercel 的 v0 这样的 AI 辅助开发，注定它会成为整个行业提效的重要手段。。

另一方面， AI 也可以用来解决大前端面对的问题：前端本质上解决的是将信息映射为用户可以理解和交互的表现形式的过程，它在传统上非常依赖我们进行离线化和静态化的分析（比如产品经理的需求分析、交互与界面的设计、软件的硬编码等），而 AI 为这整个流程带来了一种实时在线的、动态化的可能。

另外，随着大模型兴起，也有了一些 AI native 独立端开发，豆包、通义都有在做这种纯 UI 的应用。

截图为“高级前端开发工程师-大模型应用岗位要求”

虽然现在的大趋势还是超级 App，但移动互联网进入一个后期阶段后，就是朝着消费者的端智能的方向了。

有更好的架构方法了吗

去年 3 月，谷歌开源了一个名叫Service Weaver的框架。它能够实现简化本地开发，并将模块化单体应用转变为分布式微服务架构，在部署时允许自由配置组件的分布式部署方式，从而应对应用演进过程中的不确定性，并轻松适应组件间交互模式的变化。Jeff Dean 也曾发推称这是他的许多同事，包括其长期合作者 Sanjay Ghemaway 开发的系统。

谷歌描述了构建微服务架构的挑战：“维护多个不同的微服务二进制文件的开销显着降低了开发速度”、“分布式系统的问题（故障处理、广泛变化的延迟等）不会神奇地消失” 。在去年 6 月份发布的论文中，谷歌称基于新提出的结构，他们能够将系统的延迟降低 15 倍，成本降低 9 倍。

无独有偶，同样在去年 3 月，AWS 也分享了一个案例，Prime Video 团队将他们的 Serverless 应用中的部分微服务调整成为了一个单体，称此举节省了 90% 的运营成本。

谷歌和 AWS 的这波操作，跟过去十年大部分应用的开发思路反着来的：利用微服务边界进行快速本地开发；保证隔离，以便服务在运送到生产环境时可以组合；将微服务捆绑成大型二进制文件，以简化生产管理和相关服务的并置。

这究竟是架构方法的革新，还是对取舍空间的进一步探索？

Service Weaver 并不是微服务的“解”

从 2017 年起，微服务进入成熟阶段，微服务改造依然是当前趋势。随着互联网业务需求的增长，覆盖度和精细程度不断提高，维护一个模块需要数十人，协同合作出现巨大问题，需要专人负责代码合并，并选择一天统一上线。线上运行中，功能流量差异大，一旦出现故障影响全局。

解决这些问题的解法很简单也很复杂。简单说的是问题域大了，拆分成小的，问题自然就得到解决了。这就是微服务化。复杂说的是，拆分的原则没那么简单。原来的拆分从上而下，按产品按项目拆分即可，更多是组织决策就可以，技术架构的考量因素不多。但现在是要对一个相对比较原子的事物进行拆分，就必须对他所在的领域、公司业务所处的发展阶段、未来发展的重点、团队人员的能力等诸多因素综合考虑，才能得出拆分的方案。这也是微服务架构的魅力所在，也是业务架构师的核心价值所在。

微服务改造是大势所趋，但引入了新问题。在单体架构下，对服务治理体系的要求较低，通信简单，服务感知和流量管控需求有限。然而，微服务模式中，每个请求会构建复杂的调用树，树上的节点几十几百起很正常。在这种模式下，再没有服务治理体系的化，研发效率会极大幅度降低。服务治理的整个体系，甚至其子体系都开始蓬勃发展，也衍生出不少流派。以注册发现为例，有基于客户端负载的模式，也有基于中心负载的模式。各种组件也是层出不穷，如 zookeeper、consul、etcd 等。

微服务引起的问题不仅限于上述，服务数量增加必然导致人员需求上升。虽然效率工具可能改变人员与服务的关系，但趋势仍是增加。由于微服务拆分没有统一解决方案，每个企业和部门的架构师根据不同条件做决策，可能导致超前设计。一旦企业进入了降本增效的阶段，就会打破原本人员数量和服务数量的平衡。这时候微服务就会成为企业的技术负担。因此，一些企业选择回归单体架构，并取得显著成果。

对于常用而拆分过度的服务，需要考虑合并方案，但目前尚未出现一个统一的解决方案。

Service Weaver 提供了一种全新的开发与部署解决方案，其最大的特点就是提供了一种灵活性和可配置性，对于业务的演进非常友好，可以灵活调整部署模式，来实现成本优化和价值最大化。

但是，这种架构模式并不适应于已经落地了微服务架构的业务，也不适应于已经比较稳定的业务，更不适应于对于性能要求极高的业务。反过来说，Service Weaver 对于尚处于快速发展的互联网在线业务比较友好，允许应用程序随着时间的推移进行低成本演进。

2023 年架构领域的关键进展

架构领域一直在不断演进和更新，在 2023 年，一些关键框架和组件经历了重要的更新或者取得了进展：

• 服务网格：更加成熟的实现和标准化。继 Proxyless Mesh，Istio 今年推出 Ambient Mesh 模式，并正式从 CNCF 毕业，成为 CNCF 活跃度排名第三的项目。

• 开发框架：更多适用生产环境微服务架构的开发框架。以 Kitex/Hertz 为例的微服务框架更加关注企业用户在生产环境的落地和使用反馈，关注易用性和降本增效成为框架选型的主流意见。

• 编程语言与生态：Golang 成为国内诸多大厂主流或最热门的编程语言，Golang 相关的开源中间件生态繁荣，竞争加剧；Rust 成为最有潜力的编程语言，诸多大厂纷纷投资入局，新的 Rust 微服务框架如 Volo 推动 Rust 在企业内部更广泛落地。

据观察，前两年比较火的云原生可移植性设计 Dapr 框架在国内并没有得到广泛的采用。

与服务网格相比，Dapr 架构更加复杂，Dapr 的工作模式是能力抽象，需要业务应用程序遵从标准 API 进行请求开发与改造。服务网格主要设计目标是低侵入，采用原协议转发的方式可以尽可能的降低对应用的侵入。Dapr 的主要设计目标是可移植性，即在跨云跨平台的前提下实现无厂商绑定，采用的方式是在将分布式能力抽象为标准 API，并在各种开源项目和云平台上提供这套标准 API 的不同实现，从而达到在不同平台上运行的目标。因此 Dapr 的代价是需要应用进行适配和改造，侵入性比较大。因此 Dapr 更适合新应用开发 （Green Field），对于现有的老应用（Brown Field）则需要付出较高的改造代价。这也是 Dapr 当前并未获得广泛采用的主要原因。

虽然 Dapr 和类似的框架提供了许多优势和新颖的特性，未来仍需要更多时间、成熟度和社区的支持。在面对已有系统、组织惯例和技术选型方面，新框架的采用需要认真权衡其优势与现有解决方案的差异，并选择最适合的方案。

AIGC 来了，架构师岗位会受影响吗

架构师就像是整个系统的设计大师，负责操刀整个系统架构的规划。这个规划不仅仅包括技术选型、架构模式、演进变化，还得考虑业务需求、团队能力、可运维性、成本等一系列不那么技术的要素。现在，架构决策很大程度上还依赖于人的经验和直觉，但如果我们能把设计和变更都记录得明明白白，把架构知识管理搞得井井有条，那么人工智能岂不是能搞定架构领域的一部分工作？这还是未知数。

AI 原生应用的发展现在还处于初级阶段，虽然我们还没看到 AI 在软件架构和设计上有多大的影响，但我们不能否认一点，AI 肯定会给这个领域带来各种有趣的变革。

比方说，AI 可以帮我们提高决策效率、优化设计、增强系统的自适应性和安全性，还能更好地适应系统的演化和变化。当然，AI 技术在这方面的应用也需要考虑隐私以及技术成熟度等方面的问题。

未来，我们可以期待 AI 在架构领域的应用逐渐增多：AI 技术将更广泛地用于架构设计，包括 AI 辅助设计、决策支持与建议、智能监控等方面，从而提高架构设计的智能水平。看来，未来架构师团队里可能不只有人类，还可能有人工智能的！

运维困局，平台工程能否破局？

有些事情是我们预测不到的，Spotify 的 Backstage 开发者门户人气激增。此前被低估的举措，例如开发者体验，变得至关重要。

云原生技术的加速采用，为软件交付及运行态的保障持续产生着深刻的影响，比如开发与运维的边界持续模糊，从而导致双方对系统的控制权也同步持续拉扯。

随着大规模 DevOps 实践所面临的复杂度日趋提升，云原生时带的平台开发者们正在寻找新的解决思路、探索新的解决方案，平台工程则成为其中冉冉升起的一颗未来之星！ 

CNCF 应用交付 TAG 在今年先后发布了平台白皮书和平台工程成熟度模型，加之咨询公司对于平台工程发展趋势的乐观预测，让平台工程连续两年进入年度 10 大新兴技术趋势榜单，并认为中国的平台工程正在萌芽期。

新框架不断涌现

Backstage 正成为一股不可忽视的力量。从具体项目和实践案例来看，以 BackStage 为代表的开源项目正趁着内部开发者平台（IDP）等平台工程最佳实践快速发展，现已从 CNCF 沙箱项目进入孵化阶段。

Backstage 集成了 Git 仓库、构建管道、API 和基础设施自动化等关键资源，将其无缝整合进一个单一门户，供所有开发者随时调用。根据 GitHub 上的 fork 信息，梅赛德斯-奔驰、美国航空、爱立信等知名企业早已加入 Backstage 的行列。

从趋势上看，早期实践者在组织内部明显地分化出了应用开发团队和平台开发团队，传统的运维工程师也经过了 SRE 实践阶段，分化成为通过运维平台来工作的专职应用运维和平台开发者，这在很大程度上验证了《团队拓扑》理论对于实践的指导意义。 

从行业共识角度，目前已涌现出 CNOE、BACK Stack、KAOPS 等框架和实践指南。

其中，CNOE 为 AWS 联合 Adobe、Salesforce 等企业推出的一项用于构建内部开发人员平台 (IDP) 的开源计划。BACK Stack，代表 Backstage、Argo、Crossplane 和 Kyverno 这四个工具组成的一个强大的组合，可以实现安全且可扩展的自助服务工作流程。而 KAOps 则提供了一种集成 DevOps 持续交付和多云服务的创新方法。

这些框架为更加系统化地实践平台工程奠定了基础共识度，也有效促进了技术生态的持续发展和相互融合。

AI 全面入侵：未来的运维工作模式如何进化？

结合 AIGC 与 AGI 的发展趋势来看，AIOps 智能化运维方面的探索已过渡到参考自动驾驶的 L0-L5 成熟度模型来度量的阶段 ，这使得行业开始从整个软件的全生命周期来思考 AI 的赋能和提效。涉及的领域包括需求工程、设计开发、构建与集成、质量保障、持续发布与运行维护、故障分析定位等。业界甚至提出了一个面向未来的、由不同技术方向的 AI Agent 组成的开发团队的构想。这些前期的探索和畅想仍然强调了开发过程的标准化和资源的平台化，要求整个软件研发过程都能够友好地与 AI 协同工作。在这方面，来自 Vercel 的 v0.dev 是一个典型代表产品，它能够根据自然语言指令生成即时可视的前端页面，并自动部署到 Vercel 服务上。

在接下来的 2024 年，我们预测平台工程理念以及实践将更进一步随着云原生技术的加速采纳而深刻影响软件交付与运行保障，DevOps 理念中的左移将进一步发展为左移结合下移，平台的价值会得到更大程度的重视，认知负荷过重的现象对于开发和运维角色来说将会有一定缓解。

同时，结合 AIGC 与 AGI 的发展趋势，以 AIOps、知识库与问答机器人、流程机器人、代码生成等为代表的应用场景将进一步得到深化和拓展，为整个软件工程行业带来效率提升；至于软件研发模式方面，短期内依然会保持现状，但我们不得不在软件设计方面考虑到面向 AI 的 API。 

云计算的新战场

今年，受益于 AIGC 的快速发展，云计算领域的主题基本都是围绕助力 AIGC 来做能力提升。

从用户群体来看，云计算和大模型用户没有很大差异，但关注点会有不同。比如大模型厂商或创业公司最为关注资源的交付；而有的企业是希望在自有产品中快速部署已有的成熟模型，并快速验证；更小众的用户则更关注 LLM 等生成式 AI 模型本身的发展，不仅要高效使用资源，还要借助云原生能力将模型能力转化为自己的 SaaS 服务，继而对外售卖或提供智能服务。

总之，除了传统云原生客户，这些新用户的成熟度更高。他们目的是探索 AI 带来加速业务创新的可能性。还有在支持大模型生产和落地方面进行的能力和需求沉淀，也促进了云计算自身的新一轮迭代。

云原生 AI，更重资源效率和工程化交付效率

云原生与 AI 结合领域被业内称为云原生 AI，目标是利用云原生的标准化、可扩展性、弹性等技术优势，为 AI 模型生成加速，为 AI 服务交付提效。主要包括下面三部分：

• IaaS 资源层，包括高性能存储、计算、网络等基础设施。

• 工程平台，包括云原生和以容器化形式交付的云原生 AI，提供基础异构资源的调度和任务管理、对各种 AI 计算框架的支持、MLOps 生命周期管理、模型开发，训练和推理，以及后续服务化的运维等。

• AI PaaS 平台，用一站式的用户体验，构建、训练，部署和管理数据，模型和服务。

首先，对于 IaaS 层来说，AI 为其带来了规模、性能和效率方面的挑战。为了训练出一个对通用知识或专业领域知识有相当理解和推理能力的大模型，模型参数量往往会超过百亿，甚至千亿。这就需要高达万卡 GPU 集群的算力管理规模；爆炸的数据量将存储提高到了 PB 级、吞吐达到 TB/s 级；网络进入到 800Gbps，甚至达到单机 3.2Tbps RDMA 这样的高性能要求。

为此，在计算上，各家都在卷 GPU 芯片。一定程度上，对于像大模型厂商这样对算力要求极大的用户来说，芯片储备成为选择云厂商的首要考虑因素。但是 GPU 的选择很少，国外基本只有英伟达。但在新禁令情况下，国内各厂商基本很难拿到高性能卡，只能寻求性价比高的"阉割版"或国产化替代，这更加大了国内自研芯片方面的力度。但是，目前这些措施，对于高性能卡缺失带来的市场弥补有限，很多自研芯片更多是厂商内部使用。

网络方面，厂商的做法更是简单粗暴：资金充足就用 InfiniBand（无限带宽），不足就用 RoCE（RDMA over Converged Ethernet）。国内外基本都是满配单机从 800G 到 3.2T 的标配、集群弹性支持几万卡的规模。各家也有自研高性能网络项目，在做产品化和商业化的尝试。

存储方面则是在传统架构的分布式文件系统，或者并行文件系统上进行自研增强。但这种模式在大模型应用中，先前的高性能存储还不太适用聚合带宽压力骤增的场景。传统存储是通过横向容量扩展提升带宽能力，这会带来成本的增加。也有不少用户在尝试基于弹性更好，更廉价的对象存储服务的方案。但仍需要大幅优化训练场景下的数据访问速度。因此在架构上，今年较为明显的一个趋势是各厂商尤为关注数据缓存层的构建。

当然，根据模型的参数规模、数据量、预训练还是微调等的不同，大模型对底层基础设施的需求也不一样。具体到预训练来说，国内各厂的基本做法就是网络带宽、单机满卡满配形成万卡乃至更大的十万卡集群，而高精度的网络拓扑则从原先的三层压缩至两层，从而增加可扩展性并减少跳数。

传统的资源交付多以特定规格实例的形式进行，通过 配置网络、存储、计算等资源方面的需求，在虚拟机或容器实例层面进行集群管理和任务编排调度。但目前 AI 的计算资源类型在性能与成本方面有很高提升，传统交付形式意味着使用者需要自行把控资源的利用率，并且可能带来较高的 TCO (total cost of wonership)。因此，业界也在寻求更为极致的（以秒级)按需弹性交付和计量方式。

目前，Serverless 是业内较为推崇的资源交付形式。Serverless 可以弹性优化资源利用情况，根据资源的真正使用情况自动扩缩容，减轻使用者对集群管理、环境一致性、健康状况检查、错误处理等底层资源运维的负担。但是，这种只购买资源的模式，意味着使用者可能会还需要承担自建 AI 平台所带来的维护复杂度。因此，也有厂商还提供了软硬一体，以 serverless 形态交付的 AI 平台服务。比如阿里云的 PAI 灵骏智算服务。

支撑 AI 复杂任务，容器等云原生技术还有哪些短板？

现在，云原生对人工智能的支持更多是利用其可扩展架构、标准化交付及弹性等自身优势，加速 AI 能力的生产过程。或者说，AI 是云原生平台上的一种特殊类型的工作负载。

实际上，深度学习、大数据处理等数据计算密集型任务已经广泛采用容器、Kubernetes、微服务等一系列云原生技术。比如，OpenAI 为其大模型训练提供可扩展的基础设施， 在 2021 年就已经将 Kubernetes 集群扩展到 7500 个节点。这些任务的计算规模和复杂度远比 Web、微服务等互联网应用要高。

Web 应用可能只需要简单横向扩展实例副本数，就可以提升服务性能和可用性。但数据计算密集型任务自身会有复杂的拓扑关系，一个任务又会细分多个子任务，子任务之间还有逻辑关联，比如数据依赖、时序关系、执行顺序等其他逻辑上的依赖。再加上任务的状态转化和对异构资源的高消耗，对 CPU、GPU、内存容量、内存带宽、网络、磁盘 IO 等资源的协同敏感，导致任务无法轻松地横向扩展。

Kubernetes 或容器在支持这种复杂任务类工作负载方面还很欠缺。体现在对异构资源的协同优化管理，以及对 Batch 任务的调度和整体可扩展性上。为了支持 AI、机器学习这样的工作负载，Kubernetes 就需要做很大的增强，包括核心调度、异构资源统一管理、利用率优化、可观测性、故障诊断和自愈等，甚至整体的架构和生态都需要做很多增强。所有在容器和 Kubernetes 底座上进行的增强，被称为云原生 AI 基础服务层。

云原生的优势在于标准化交付，将业务应用中的运维、架构、DevOps 统一化。企业 IT 可以将更为复杂的数据计算型任务迁移到同一套技术堆栈上，用统一的标准交付模式和 API 来支撑不一样的工作负载，通过弹性和混合调度等手段的综合应用，从而达到整体降本增效的目标。这是一个比较长期且有远见的架构演进上的诉求。

上图是一个非常典型的云原生 AI 系统分层架构。

最底下的是高性异构资源管理，包括对高性能计算、存储、网络的统一管理和运维；上面是 AI 任务调度和流水线的构建。再往上就是为了运行各种各样的计算框架或者训练、推理的运行时，要做容器化支持；当运行时和框架跑起来后，就要关注如何不断优化任务性能，优化方法除了算法和框架以外，还有非常多手段相互配合；性能优化之上，要管理整个 AI 作业的生命周期；而所有这些能力都需要用统一的工具链和统一的标准 API 向上暴露给整个生态，既可以集成开源生态、私有业务系统，也可以跟第三方生态的集成。

从支持系统看，弹性运维和安全始终贯穿其中，而厂商需要对客户的数据和模型进行统一管理，并对效率之外的数据安全和隐私做好保护工作。

MaaS 发展未定，云厂商的“野心”能否实现？

很多产品都在用 LLM 进行增强甚至重构，其中包括智能诊断、AIOps 等在云服务使用助手的场景。模型生态的繁荣会吸引更多新型业务应用围绕 AI 模型关联或集成，更快更广地发展出更多新应用，间接帮云厂商接近了客户的应用需求，往上面向更多需求和机会，往下承接更大的资源消耗。

IaaS 层只是最基本的支持，AI PaaS、AI SaaS 也成为云厂商们提供附加值的关键之一。在这方面，各家也有自己的平台。AI PaaS 包括数据，模型等资产管理平台，模型开发平台、模型训练平台、模型推理平台，还有各行业解决方案。AI SaaS 则更多关注个人工作效率和企业在流程化、规章制度和执行等方面的效率提升，这些都可以交给 AI 工具来完成。

今年，很多云厂商也纷纷发布了自己的大模型，打造自己的 MaaS（ Model as a Service）服务。MaaS 则包括了底层的基础设施、模型相关能力及产品和场景应用等，主要就是以大模型为核心提供场景化智能服务。

出于安全问题或领域定制性较强而外部模型无法达到预期效果等考虑，进行知识库的微调或增强等来自研模型是可以理解的，但效果如何可能要先打个问号，目前国内还没有成熟案例出来。

各家的大模型虽然分层差不多，但如果抽象力度够高，那每层内容展开后也有很多：从下层智算 IaaS 到 AI PaaS 或面向云原生的 AI，再到最上面服务生态的 MaaS 层以及垂直化领域的各类配置化模型。但对云厂商来说，MaaS 商业模式可能只是间接的，但其影响力会更大。现阶段还是会以规模为主，是否会引发新的商业模式还是个未知数。

12 月，科技市场分析公司 Canalys 的一份报告显示，人工智能热潮尚未推动中国云市场增长，“中国云服务市场仍然保守，严重依赖政府和国有企业。”

未来，离业务更近的云原生技术与大模型会有更多集成，这对本身就有很多业务场景的企业来说更为有利。在多云和多集群等更为复杂的环境中，业内也在探索进行统一的 AI 能力交付。此外，在国产化背景和异构芯片现状下，业内将在降低复杂度和提效上努力。

采访嘉宾简介：

黄玄（Hux），字节跨端与 Web 架构师，前 React 团队核心成员

曹立成（蒜蓉），淘天集团 1688 终端架构负责人

罗广明，字节跳动服务框架团队架构师，CloudWeGo 开源负责人

董晓聪，作业帮基础架构负责人

杨振涛，vivo 互联网研发总监，PECommunity 平台工程社区发起人

张凯，阿里云云原生应用平台容器智算负责人

更多阅读：

你当初被谁“忽悠”上了云，现在又在被谁“忽悠”下云？｜盘点

挑战 Spark 和 Flink？大数据技术栈的突围和战争 ｜盘点

今年向量数据库“杀疯了”，但纯向量数据库“凉”了？| 盘点

颠覆软件工程、“杀死”开发者？回溯大模型落地应用这一年 | 盘点

并发王座易主？Java 21 虚拟线程强势崛起，Go & Kotlin 还稳得住吗 | 盘点

国产编程语言新拐点：聊聊从 Mojo 到 MoonBit 的思考 | 盘点

大模型时代，我们可以用 Julia 做什么？| 盘点