百度搜索数据建设以创新实践突破传统数仓挑战，依托宽表模型、计算引擎优化及图灵3.0模式，实现高效稳定低成本，赋能业务敏捷迭代。

文章主要介绍Iceberg在百度MEG图灵湖仓生态中的能力建设及业务场景的落地实践。百度MEG上一代大数据产品存在平台分散、易用性差等问题，导致开发效率低下、学习成本高，业务需求响应迟缓。

度副总裁陈洋现场发布了文心快码独立 AI 原生开发环境工具——Comate AI IDE，是行业首个多模态、多智能体协同的 AI IDE。

从代码规范, 前端工程化, 性能优化等方面介绍一个前端老项目的深度重构的过程。百度日志中台前端项目起源于2020年初，整个前端项目有500多个文件，共11万多行源码。项目已经变得老旧而臃肿。

文章主要介绍了百度反作弊业务中应用极大连通子图、标签传播、Fraudar、图神经网络算法各类图算法挖掘作弊团伙的实践经验。

百度垂直搜索系统将搜索核心能力赋能阿拉丁（百度搜索特型结果）、垂直领域搜索、应用内搜索等场景，支撑了数百个检索场景、百亿级内容数据的检索。

6月6日，由人民日报文化传媒、百度公司联合主办的2025智能经济论坛在人民日报社举行。会上，百度集团执行副总裁、百度智能云事业群总裁沈抖分享了百度智能云以全栈自主可控能力赋能企业创新和产业升级的实践与

导读 BaikalDB作为服务百度商业产品的分布式存储系统，支撑了整个广告库海量物料的存储和OLTP事务处理。随着数据不断增长，离线计算时效性和资源需求压力突显，基于同一份数据进行OLAP处理也更为经

在数据库的运维工作中，DBA 应该选择哪一种方案，确保 Redis 数据库崩溃后可以对数据进行回档，恢复业务运行？ 一般情况下，DBA 可以通过 Redis 原生的持久化机制，如 RDB 快照持久化或

随着互联业务的发展、业务逐渐的复杂，传统代码架构在日常开发中存在的多种弊端，如代码混乱、补丁式开发、迭代成本高等问题，大大影响了迭代的效率。本文作者借助 DDD 的战略设计和战术设计，介绍了如何通过限界上下文、领域模型、聚合、资源库等概念，实现业务逻辑与技术的解耦，提升代码的可维护性、扩展性和稳定性。同时，文章作者结合团队在落地DDD时，遇到的卡点、痛点，创新性的提出一种 DDD 的分层实践，并在实际开发中取得了较好的效果

01 背景

不知不觉从事To B业务已经3年，笔者在工作中看了很多、也写了很多的代码，由此也产生很多的思考和感悟：在日常的工作中，我们的主要矛盾在于日渐复杂、动态变化的业务诉求与有限的人力之间的矛盾。而为了解决这一矛盾，我们要尽可能的保证代码的优雅。

但是传统的代码设计，如：面条式代码架构、基于面向对象+MVC的代码架构，大部分无法保证在日趋复杂的业务中以优雅的代码架构持续发展。一旦迭代时间拉长，这类代码往往会或多或少地表现出以下特征：

1. 代码组织混乱（数据的获取随意、业务逻辑与数据逻辑纠缠、结构随意）;

2. 业务逻辑透传数据数据库（业务逻辑层层透传到数据库层）;

3. 隐式代码逻辑横行（业务代码到处散落、对象的初始化通过隐式init）。

笔者在这里画一下这套代码的逻辑组织结构：

具体来分析，笔者认为主要存在以下几种问题：

1. 稳定性&性能低下：由于代码组织结构的混乱，导致开发模式变成了打补丁，迭代方式变成了在原有的代码基础上继续填充if else、或者新开辟一个func用于实现本次新加的代码逻辑。这往往会导致重复数据的获取、重复的数据校验、重复的对象创建.....，从而导致性能的大幅下降。

2. 代码复杂程度高

a.补丁式的开发模式:

i. 由于补丁的开发，数据的获取随意从而导致代码的复用性降低，毕竟每同学在开发时，如果不全盘梳理代码已无法抽取合理的公共代码逻辑。而新添加的代码又会成为下一个同学的开发负担，从而导致_代码一直处于恶性循环，从而导致复杂度一直增长*。笔者就见过一些超过1500行的函数，这些函数除了重新推倒重来基本无迭代的可能性，因此我们应该尽可能避免这种情况发生。除了以上问题，补丁式的开发缺少统一的规划，*圈复杂度的急剧上升也是代码复杂度上升_的一个重要原因。

b. 代码组织混乱:

i. 数据获取随意:由于没有统一的代码格式层级,数据的获取散列在整个代码的各处、赋值修改亦如此,导致数据污染。

ii.据获取通过Map结构：笔者见过一些代码通过Map获取数据，后续的开发的同学必须不仅要关注这个map的成员、还要关注Map中每个成员的生命周期是否有过修改、更新，迭代过程中十分痛苦。

iii .....

c. 隐式的业务逻辑:

i.代码只体现对数据修改、更新,而没有显示注明业务逻辑。

d. 业务逻辑透传数据数据库:

i. 笔者见过一些代码,请求的参数直接从api透传到dao层,导致对这段代码进行扩展十分困难。

3. 迭代成本高:由于代码复杂度过高,导致迭代复杂度同比增加。

从实际工作中来看，一旦代码选择这种架构，便只能沿着混乱继续一路狂奔，从而无法挽回直到业务无法忍受技术的短板，选择进行重构！笔者在这里截取一些代码片段，作为示例：

△map获取

△超长代码

02 那什么才是好的代码架构？优雅的结构？

从笔者的工作经验来看，好的代码结构一般具有以下几种特点：

1. 代码的可扩展性：好的代码架构帮助代码开发人员将业务与技术解耦，增加代码的扩展性;

2. 代码的可维护性：好的代码架构能将业务和依赖进行解耦，增加代码的可维护性；同时好的代码架构可以降低代码和文档的腐化程度;

3. 代码复用性高、可测试性强：代码架构有助于提升代码的复用性、可测试性;

锦上添花:

4. 系统稳定性高:好的代码架构有助于提升系统的稳定性。

很高兴的事情是DDD是从一种更高纬度的设计思想去思考问题，他以业务驱动为核心，从稳定性的角度去构建代码结构。某种意义而言，DDD也许是一种更巧妙的解决方案，帮助我们去构建更优雅的结构，从一定维度上减缓项目代码的腐化。

03 什么是领域驱动设计

DDD是一种围绕领域建模来解决复杂业务交付的设计思想。

1. 什么是复杂？如何理解复杂？

• 复杂可能是现状业务就复杂，也可能是业务日渐演变成复杂。复杂来自规模在变，比如几个业务对象的逻辑不复杂，几十上百个业务对象就会变得错综复杂;

• 复杂来自结构化不足，例如结构化的中国结比非结构化的意大利面更有序、易于大脑理解。此外，如何协同不同团队完成软件交付也是一种复杂。

2. 什么是领域建模？

• 领域模型跟技术毫无关系，而是为了更有结构化的拆解和表达业务逻辑。业务逻辑来自现实世界里的具体场景，涉及可视画面、操作动作和流程。要准确表达业务逻辑需要先讲清楚每个概念是什么，再建立概念之间的联系，基于这些关系再组合出更多的流程;

• 概念、联系、流程就是领域模型。围绕领域模型去表达业务时也自然而然地把技术实现细节分离出去了。后续代码实现就是将业务架构映射到系统架构的过程，以后业务架构调整了能快速的调整技术架构。

3. DDD用哪些领域概念表达业务？

• 表示业务逻辑的是：实体、值对象、领域服务、领域事件。这意味着所有领域逻辑都应该在这四种对象里，统一称为领域模型对象，这将极大_减少业务逻辑的蔓延;_

• 引入聚合进一步封装实体和值对象，让领域逻辑更内聚，起到边界保护的作用。聚合的引入使得业务对象间的关联变少。如何设计聚合见下面实践部分;

• 围绕聚合的操作引入工厂和资源库。工厂负责复杂聚合的创建，资源库负责聚合的加载、添加、修改、删除。聚合内的实体状态变更通过领域事件来推动;

• 应用服务处于应用层，对领域逻辑编排、封装之后对上层接口层暴露。一次编排就是一个用户用例。

04 领域驱动设计如何解决问题

DDD 包括战略设计和战术设计两部分。

• 战略设计：主要从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。

• 战术设计：从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地，包括：聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。

4.1 战略设计：分割你的设计，以免无法控制

4.1.1 Bounded Context（限界上下文）

限界上下文是围绕应用程序和/或项目部分的概念边界，涉及业务领域、团队和代码。它将相关组件和概念分组，避免歧义，因为其中一些可能在没有明确上下文的情况下具有相似的含义。

• 比如电商领域的商品，商品在不同的阶段有不同的术语，在销售阶段是商品，而在运输阶段则变成了货物。同样的一个东西，由于业务领域的不同，赋予了这些术语不同的涵义和职责边界，这个边界就可能会成为未来微服务设计的边界。领域边界就是通过限界上下文来定义的。

• 比如财务领域、审核领域。DDD里的限界上下文（Bouded Context）是对广告领域的软件实现，比如钱包体系、账户体系就是财务领域内的限界上下文。

• 限界上下文定义了解决方案的明显边界，边界里的每一个领域概念，包括领域概念内的属性和行为都有特殊含义。出了限界上下文这个边界这层含义就不复存在。

• 如何划分限界上下文？

1. 根据相关性做归类。一般是优先考虑功能相关性而不是语义相关性，比如创建订单和支付订单都是订单语义，但功能相差比较大，应该划分为两个限界上下文。

2. 根据团队粒度做裁剪、根据技术特点做裁剪。一些通用的技术功能应该尽可能归拢到一个限界上下文，比如每个业务限界上下文都有监控，但监控能力应该归拢到监控限界上下文。

4.1.2 Context Mapping（上下文映射）

识别并以图形方式记录项目中的每个限界上下文称为上下文映射。上下文映射有助于更好地理解有界上下文和团队如何相互关联和沟通。它们给出了实际边界的清晰概念，并帮助团队直观地描述系统设计的概念细分。

受限上下文之间的关系可能会有所不同，这取决于设计要求和其他特定于项目的约束，本文将省略某些关系，但以下四种关系除外：

4.1.3 Anti-corruption Layer（防腐层）:

下游限界上下文实现了一个转换来自上游上下文的数据或对象的层，确保它支持内部模型。

4.1.4 Conformist（跟随者关系）:

下游有界上下文符合并适应上游上下文，如果需要，必须进行更改。在这种情况下，上游环境对满足下游需求不关心。

4.1.5 Customer/Supplier（客户/供应商关系）:

上游向下游提供服务，下游上下文充当客户，确定需求并向上游请求更改以满足其需求。

4.1.6 Shared Kernel（共享内核）:

有时，两个（或更多）上下文不可避免地重叠，最终共享资源或组件。这种关系要求两个上下文在需要更改时保持连续同步，因此如果可能的话应该避免。

4.2 战术设计:DDD的螺母和螺栓

4.2.1 Entity（实体）

具有唯一标识并具有连续性的对象称为实体，它们不仅仅由属性定义，更多地由它们是谁定义。

它们的属性可能会发生变异，它们的生命周期可能会发生剧烈变化，但它们的身份依然存在。身份通过唯一密钥或保证唯一的属性组合来维护。

例如，在电子商务领域，订单有一个唯一的标识符，它经历几个不同的阶段：打开、确认、发货和其他，因此它被视为领域实体。

重点关注：Entity最重要的设计原则是保证实体的不变性（Invariants），也就是说要确保无论外部怎么操作，一个实体内部的属性都不能出现相互冲突，状态不一致的情况。

这里给出一些总结的规范：

1. 创建一致性 ，实体的创建尽量通过Factory或者规约进行创建;

2. 在代码实践中，尽量保证实体的创建唯一性（避免过多的创建实体的方法）。

3. 实体的属性尽量使用小写，避免外部直接对属性的操作，从而导致实体与业务出现不一致的情况;

4. 通过聚合根对子实体进行访问；子实体的一致性交由聚合根保证;

5. 任何实体的行为只能直接影响到本实体（和其子实体）。

应当遵守的原则：在一个系统里一个实体对象的所有变更操作应该都是预期内的，如果一个实体能随意被外部直接修改的话，会增加代码bug的风险**。**

4.2.2 Value Object（值对象）

描述特征的对象，不具有任何唯一性的对象称为价值对象，它们只关心自己是什么，而不关心自己是谁，值对象是多个实体的属性，可以由多个实体共享。

例如：两个客户可以具有相同的发货地址，尽管存在风险，但如果其中一个属性需要更改，则共享这些属性的所有实体都会受到影响。为了防止这种情况发生，值对象必须是不可变的，当需要更新时，强制系统用新实例替换它们。

此外，价值对象的创建应始终取决于用于创建它们的数据的有效性，以及它如何尊重业务不变量。

因此，如果数据无效，将不会创建对象实例。例如，在北美，带有非字母数字字符的邮政编码将违反业务不变量，并将触发地址创建异常。

4.2.3 Aggregate（聚合）

聚合是相关实体和值对象的集合，聚集在一起表示事务边界。每个聚合都有一个朝外的实体，控制对边界内对象的所有访问，该实体称为聚合根，是其他对象可以交互的唯一对象。

聚合中的任何对象都不能直接从外部世界调用，从而保持内部的一致性。业务不变量是保证聚合及其内容完整性的业务规则，换句话说，它是一种确保其状态始终与业务规则一致的机制。例如，当某个产品的库存量为零时，就永远不能下订单。

4.2.4 Repository（资源库）

为了能够从持久性中检索对象，无论是在内存、文件系统还是数据库中，我们需要提供一个对客户机隐藏实现细节的接口，以便它不依赖于基础架构细节，而仅仅依赖于抽象。

存储库提供了一个接口，域层可以使用该接口来检索存储的对象，避免了与存储逻辑的紧密耦合，并使客户端产生了直接从内存检索对象的错觉。

值得一提的是，所有存储库接口定义都应该位于domain层，但它们的具体实现属于基础架构层。

4.2.5 Domain Event（领域事件）

领域事件是过去时态的业务事实，当聚合根状态变更时触发，它的核心职责是跨聚合/微服务的业务协同，我们将它定义在领域层，发布/处理可在应用层。

例如订单创建后触发库存更新、通知等跨系统操作，它不需要强一致性保证，只需要保证最终一致性。

4.2.6 Domain Service（领域服务）

在许多情况下，领域模型需要某些与实体或值对象不直接相关的动作或操作，将这些动作或操作强制到它们的实现中会导致它们的定义失真。

如电商订单支付，需要协调订单、库存、支付三个实体完成事务。

服务****应该精心设计，始终确保它们不会剥夺实体和价值对象的直接责任和行为。

它们还应该是无状态的，这样客户机就可以使用服务的任何给定实例，而不考虑该实例在应用程序生命周期中的历史记录。

4.2.7 Application Service（应用服务）

和领域服务的区别在于，应用服务处理流程编排、捕获异常，领域服务处理核心业务规则。

应用服务是协调领域模型与外部系统交互的中间层，负责处理非业务逻辑的横切关注点，如事务管理、安全认证、参数校验、事件发布等。

通过一个应用服务，我们能够清晰地看出对哪些实体行为进行了调度，它依赖于领域服务和基础设施组件，进行日志记录、异常捕获、权限验证、数据转换等基础设施层交互，保持领域层与技术实现解耦。

此外，应用服务还需要对外暴露REST API或RPC接口，对内将DTO转换为领域对象，隔离外部请求与内部模型。

05 领域驱动设计分层架构

** 六边形架构**

从代码演进的角度来看/需求变更的速度来看，我们将各层按照变更速度排序：

1. Domain（领域）层属于核心业务逻辑，属于经常被修改的地方；这部分的需求经常随着产品的迭代进行变更。领域层不依赖其他层，通过资源库包下的接口定义做到依赖倒置，接口参数不能体现具体技术实现细节，领域模型里的实现逻辑只依赖接口。这样做到对领域逻辑的一层防腐。本层里以聚合为单位放置代码，便于以后系统拆分，以聚合为单位。

2. Application（应用）层属于Use Case（业务用例）。业务用例一般都是描述比较大方向的需求，接口相对稳定，特别是对外的接口一般不会频繁变更。_添加业务用例可以通过新增Application Service或者新增接口实现功能的扩展_**。**此外应用层还可以处理横切面事务比如启动数据库事务。

3. Interface（接口）层主要负责解决外部通信、协议等问题，将外部的定时任务、请求、rpc、事件消费都进行透明处理。

4. Infrastructure（基础设施）层属于最低频变更的。基础设施层完成资源库的实际实现，以及领域层定义的其他接口的实现如对外部服务的访问，领域事件发布到消息队列中间件等。一般这个层的模块只有在外部依赖变更了之后才会跟着升级，而外部依赖的变更频率一般远低于业务逻辑的变更频率。

5.1 DDD FrameWork（四层架构）

后文中，我们对于层的介绍将类比接口的概念进行介绍，重点关注3个概念：

• 入参

• 出参

• 内容

5.1.1 用户接口层

• 定义：用户接口层负责向用户显示和解释用户指令。这里的用户可能是:用户、程序、自动化测试和批处理脚本等等。

• 目的：我们希望通过分层,来提升application层的稳定性。

• 构成结构

1. 入参:  CQE对象;

2. 出参：DTO对象;

3. 内容 : 对玩不输入进行校验,输出内容的处理结果;

• 笔者在这里给出一些落地规范:

1. 统一的鉴权：比如在一些需要AppKey+Secret的场景，需要针对某个租户做鉴权的，包括一些加密串的校验;

2. 网络协议的转化：这个尽量交给框架处理，我们主要的工作是关注如何将参数反序列化或者序列化;

3. Session的管理：一般在面向用户的接口或者有登陆态的，通过Session或者RPC上下文可以拿到当前调用的用户，以便传递给下游服务;

4. 限流配置：对接口进行限流;

5. **异常处理：**通常在接口层要避免将异常直接暴露给调用端，所以需要在接口层做统一的异常捕获，转化为调用端可以理解的数据格式;

6. 日志打印：在该层进行日志的打印;

7. CQE的校验：在该层进行业务无关的校验，推荐依赖框架本身实现;

8. 可选：部分代码会在interface层引入缓存。

补充：浅谈CQE模型和CQRS

从笔者的经验来看，这两者概念上区别不大，他的思路就是将系统的Input，根据语义拆分成write和read。这里先只谈CQE模型：

Command指令：指调用方明确想让系统执行的指令，他的预期是对一个系统进行影响，即写操作。通常来说，需要一个明确的返回值（如：同步的操作结构、异步的指令被接受）

Query指令：指调用方明确想查询的东西，包括查询参数、过滤、分页等条件，其预期是对一个系统的数据完全不影响的，也就是只读操作

Event指令：指一件已经发生过的事情，需要系统根据这个事实进行相应，通常都会伴随一个写操作。事件处理器不会有返回值。补充一下，Application层的Event概念和Domain层的DomainEvent是类似的概念，但不一定是同一回事，这里的Event更多是外部一种通知机制而已。

Q：为什么使用CQE对象?

这是一个好的问题，从笔者的经验来看，DDD在于解决复杂的业务；

从某种意义上来说，笔者认为读不算真正的业务，读往往可以理解成数据的组装。

因此，对问题进行拆分，分而治之，从工程学上来说是一种简单可行的方案。从完美的角度上来说，如果能有一种可以全治理的方案一定是最好的！But we live in the real world!

5.1.2 应用层（落地重点）

• 定义：应用层是很薄的一层，理论上不应该有业务规则或逻辑，主要面向用例和流程相关的操作。

• 目的：应用层的核心是：Manage或者Orchestration，编排是应用层最关心的事情，他负责将业务编排到各个领域中。

• 构成结构

1. 入参:  CQE(Command、Query、Event)对象

2. 出参：DTO对象

3. 内容：

a.应用层位于领域层之上，可以协调多个聚合的服务和领域对象完成服务编排和组合，协作完成业务操作。

b.应用层也是微服务之间交互的通道，它可以调用其它微服务的应用服务，完成微服务之间的服务组合和编排。

c.应用服务是在应用层的，它负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装，以粗粒度的服务通过 API 网关向前端发布。

d.应用服务还可以进行安全认证、权限校验、事务控制、发送或订阅领域事件等。

• 落地规范

a.应用层应该只包含业务流程的封装，不处理业务逻辑;

b.避免进程内部的EDA驱动。

Q:什么是DTO？为什么要有DTO？带来的额外成本是什么？

DTO存在的意义在于我们可以将实体与数据传输解耦，使得领域层只和应用层有关联性、对外透明；额外成本：性能&冗余&额外引入的DTO Assembler层（用于实体到DTO的转换）。一个基本的DTO对象，如下（简单的pojo对象）：

type AdWalletDTO struct {
    AdAccountID          string          `json:"ad_account_id"         orm:"ad_account_id"         `   // 子账户ID
    WalletStatus         uint            `json:"wallet_status"         orm:"wallet_status"         `   // 钱包状态：1-正常 2-欠费状态 3-关闭
    DepositBalance       decimal.Decimal `json:"deposit_balance"        orm:"deposit_balance"        ` // 存款余额
    FrozenDepositBalance decimal.Decimal `json:"frozen_deposit_balance" orm:"frozen_deposit_balance" ` // 冻结存款余额
    CreditBalance        decimal.Decimal `json:"credit_balance"        orm:"credit_balance"        `   // 信用余额
    FrozenCreditBalance  decimal.Decimal `json:"frozen_credit_balance" orm:"frozen_credit_balance" `   // 冻结信用余额
    CouponBalance        decimal.Decimal `json:"coupon_balance"`                                       // 代金券余额
    Title                string          `json:"title"`                                                // 名字
    Currency             string          `json:"currency"`                                             // 货币
}

Q:CQE 和 DTO有什么区别？

ApplicationService的入参是CQE对象，但是出参却是一个DTO，从代码格式上来看都是简单的POJO对象，那么他们之间有什么区别呢？

可以简单做如下理解：

• 入水口的pojo是CQE，出水口的是DTO（因为入水口天然自带业务含义，因此需要严格的校验；出水口是安全的，只承担数据传输的载体）

• 复用性上而言：CQE对象复用性更低，DTO的复用性更强

CQE对象：CQE对象是ApplicationService层的输入，也可以是interface层的输入，有明确的意图，这个对象必须保证输入的正确性。

DTO对象：是负责承接数据的容器，不负责具体的业务，不包含任何逻辑，只是贫血对象

最重要的一点：因为CQE是”意图“，所以CQE对象在理论上可以有”无限“个，每个代表不同的意图；但是DTO作为模型数据容器，和模型一一对应，所以是有限的。

Q:为什么出参应该返回DTO而不是Entity?

这个是一个非常好的问题，笔者在DDD落地实践的时候，笔者是这么去想的：

1. 稳定性思考：Entity里面通常会包含业务规则，如果ApplicationService返回Entity，则会导致调用方直接依赖业务规则，如果内部规则变更可能直接影响到外部。

2. DTO的不稳定性大于实体：业务经常会增加、改变一些字段，而实体的字段相对更加稳定，这也让我们尽量在application层的出参去屏蔽实体

3. 领域边界稳定性：ApplicationService的入参是CQE对象，出参是DTO，这些基本上都属于简单的POJO，来确保Application层的内外互相不影响。

4. 通过DTO组合降低成本：Entity是有限的，DTO可以是多个Entity、VO的自由组合，一次性封装成复杂DTO，或者有选择的抽取部分参数封装成DTO可以降低对外的成本。

Q:在上述的过程中，我们似乎只解决了C、E对象，我们应该如何针对Query进行处理？

在实践过程中，我们发现Query往往是复杂的、随意的、且交付对象是异变的，因此如果强行将Query作为业务来嵌入我们的DDD中，简直是自讨苦吃——我们很难保证一个操作既是高效读、又是高效写、同时还要兼顾一致性。因此我们的解决思路是，针对Query采用传统的开发模型，虽然不够优雅、但是足够有效，毕竟因为改动代码，导致读错的成本实在是太小了。

在实践过程中，我们推荐使用调用链去尽量简化、复用读的场景，并且取得较好的实践效果。

应用层，因为我们操作的对象是Entity，但是输出的对象是DTO，这里就需要一个专属类型的对象叫DTO Assembler。DTO Assembler的唯一职责是将一个或多个Entity/VO，转化为DTO。

注意：DTO Assembler通常不建议有反操作，也就是不会从DTO到Entity**，因为通常一个DTO转化为Entity时是无法保证Entity的准确性的。**

5.1.3 领域层

• 定义：领域层的作用是实现企业核心业务逻辑,通过各种校验手段保证业务的正确性。

• 目的：领域层的目的是完成业务的核心逻辑,降低实体之间的依赖性。

• 构成结构

1. 入参: 实体、聚合根、基础的数据结构(int、string......)......

2. 出参：实体、聚合根、基础的数据结构

3. 内容：

a.应领域层包含聚合根、实体、值对象、领域服务等领域模型中的领域对象，主要体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。

b.领域模型的业务逻辑主要是由实体和领域服务来实现的，其中实体会采用充血模型来实现所有与之相关的业务功能。

c.当领域中的某些功能，单一实体（或者值对象）不能实现时，我们就会将这样的逻辑放在领域服务里，__通过领域服务组合聚合内的多个实体（或者值对象），实现复杂的业务逻辑。

• 落地规范

a.避免领域事件的使用。

Q:为什么我们要避免进程内部的领域事件的使用？

进程内的领域事件，会导致显示的调度变成隐式，这种隐式的场景在测试阶段很难发现问题，从而导致线上问题的产生。从迭代的发展来看，隐式的事件驱动对于我们设计一个好的代码架构不是一件好事情，反而会大大提高代码的复杂度！因此，我们要尽量去避免进程内部级别的事件驱动~

5.1.4 基础设施层

• 定义：基础层是贯穿所有层的，它的作用就是为其它各层提供通用的技术和基础服务，包括第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库等。

• 目的：对业务提供最基本的服务

• 落地规范

a.比较常见的功能还是提供数据库持久化

b.基础层包含基础服务，它采用依赖倒置设计，封装基础资源服务，实现应用层、领域层与基础层的解耦，降低外部资源变化对应用的影响。

5.1.5 Data flow direction（数据链路）

在数据链路维度，我们来看DDD的数据流转，可以更清晰地看出每一层之间的交互。

数据持久化对象 PO(Persistent Object)，与数据库结构一一映射，是数据持久化过程中的数据载体。

领域对象 DO（Domain Object），微服务运行时的实体，是核心业务的载体。

数据传输对象 DTO（Data Transfer Object），用于前端与应用层或者微服务之间的数据组装和传输，是应用之间数据传输的载体。

视图对象 VO（View Object），用于封装展示层指定页面或组件的数据。

5.1.6 附录：生产环境中项目结构

目录结构：

5.2 领域驱动VS数据驱动

5.2.1 对比

传统的接口-逻辑-数据访问三层架构里，往往是这么个逻辑。

前几行代码做validation，接下来做convert，然后是业务处理逻辑的代码，中间穿插着通过RPC或者DAO获取更多的数据，拿到数据后，又是convert代码，然后接着一段业务逻辑代码，最后可能还要落库，发消息等等。

MVC三层架构

• 用户界面层（View/Controller）**负责用户交互和界面展示，接收用户输入并传递至业务逻辑层，同时将处理结果返回给前端。

• 业务逻辑层（Service）**包含核心业务逻辑，但常因过度集中而臃肿，容易成为“大泥球”。业务逻辑可能分散在多个Service类中，甚至通过SQL实现部分逻辑，导致耦合度高。

• 数据访问层（DAO）**直接操作数据库，依赖ORM框架，与数据库表结构紧密绑定。

MVC VS DDD：

5.2.2 转化

三层架构向 DDD 分层架构演进，主要发生在业务逻辑层和数据访问层。

DDD 分层架构在用户接口层引入了 DTO，给前端提供了更多的可使用数据和更高的展示灵活性。

DDD 分层架构对三层架构的业务逻辑层进行了更清晰的划分，改善了三层架构核心业务逻辑混乱，代码改动相互影响大的情况。DDD 分层架构将业务逻辑层的服务拆分到了应用层和领域层。应用层快速响应前端的变化，领域层实现领域模型的能力。

另外一个重要的变化发生在数据访问层和基础层之间。三层架构数据访问采用 DAO 方式；DDD 分层架构的数据库等基础资源访问，采用了仓储（Repository）设计模式，通过依赖倒置实现各层对基础资源的解耦。

仓储又分为两部分：仓储接口和仓储实现。仓储接口放在领域层中，仓储实现放在基础层。原来三层架构通用的第三方工具包、驱动、Common、Utility、Config 等通用的公共的资源类统一放到了基础层。

5.2.3 CQRS

不得不提的CQRS结构（参考文档：learn.microsoft.com/zh-cn/azure…

简介：CQRS 是“命令查询责任分离”（Command Query Responsibility Segregation）的缩写

定义：CQRS是一种设计模式，可将数据存储的读取和写入操作隔离到单独的数据模型中。 此方法允许每个模型独立优化，并可以提高应用程序的性能、可伸缩性和安全性

核心：将外部系统的输入区分为：Cmd(包含Event)和Qurey。

因为我们知道，在DDD的模式中，所有的操作都是以实体为基础的，一个实体很有可能很大，涵盖了多种数据来源组成。

那这里就出现了一个问题，业务中需要出一个接口，查询一个account list，以label value的形式返回，我们该怎么做？

是先通过一系列工厂校验，拿到一个大实体，然后通过这个实体操作数据，拿到account list，再处理成dto返回。

还是直接写一个简单的mvc，查询然后拿结果组装返回。

毫无疑问，我们选择后者。

这就是CQRS，用比较粗糙的说法：我们建议在业务逻辑的写入Cmd(包含Event)用DDD来进行，也建议在业务逻辑的查询Query用MVC来进行。

一切模型或者框架，都是为了简化我们的工作，如果我们因为使用了某一种设计模式，而导致开发严重受限，那说明这种设计模式，并不适合我们。

06 总结

正如那句话说的，DDD不是银弹，它不能解决所有问题，但是我们在尝试解决的路上，发现了这样一种模式。

07 彩蛋

看到了这里想必你的脑子里现在全是实体、领域等等这些理论概念，已经忘记了文章一开始我们要干什么，这其实也是在落地DDD时一大痛点。那就让我们不忘初心，再重新回顾和强调一下：我们的目的是要去写一个好的代码。

-----END-----

推荐阅读

读友好的缓存淘汰算法

如何定量分析 Llama 3，大模型系统工程师视角的 Transformer 架构

微服务架构革新：百度Jarvis2.0与云原生技术的力量

技术路线速通！用飞桨让京剧人物照片动起来

无需业务改造，一套数据库满足 OLTP 和 OLAP，GaiaDB 发布并行查询能力

为了适应 PD 分离式推理部署架构，百度智能云从物理网络层面的「4us 端到端低时延」HPN 集群建设，到网络流量层面的设备配置和管理，再到通信组件和算子层面的优化，显著提升了上层推理服务的整体性能。

百度智能云在大规模 PD 分离式推理基础设施优化的实践中，充分展现了网络基础设施、通信组件与上层业务特征深度融合的重要性。

---

01 PD分离式推理服务对网络的需求

传统的推理服务均是集中式，大多是单机部署。即使是多机部署，机器规模也非常小，对网络的带宽和时延需求都不大。当前大规模 PD 分离式推理系统来说，对网络通信的需求则发生了变化：

• 引入大规模的 EP 专家并行。EP 会从单机和双机的小规模，变成更大规模，因此 EP 之间的「 Alltoall 通信域」成倍增长。这对于网络基础设施、Alltoall 算子等的通信效率都提出了更高的要求，它们会直接影响 OTPS、TPOT 等指标，从而影响最终的用户体验。

• PD 分离式部署，Prefill 和 Decode 之间会有 KV Cache 流量的传输，KV Cache 通信的时延直接影响推理服务整体的性能。

为了提升大规模 PD 分离式推理系统的效率，百度智能云针对性地优化了网络基础设施和通信组件：

• 物理网络层面：为适配 Alltoall 流量专门建设了「4us 端到端低时延」 HPN 集群，支持自适应路由功能彻底解决网络哈希冲突，保证稳定的低时延。

• 流量管理层面：优化 Alltoall 多打一 incast 流量导致的降速问题。对 HPN 网络中训练、推理等不同类型流量进行队列管理，实现训推任务的互不干扰。通过自研高性能 KV Cache 传输库实现 DCN 弹性 RDMA 满带宽传输。

• 通信组件层面：Alltoall 算子优化，相比开源的方案，大幅提升 Prefill 和 Decode 的 Alltoall 通信性能。针对 batch size 级别的动态冗余专家编排，将专家均衡度控制在了 1.2 以下，确保集群中所有 GPU 通信时间大致相同。优化双流，实现最大程度的计算和通信 overlap，整体提升 20% 吞吐。

下面我们逐一介绍百度智能云在以上几个层面的优化实践。

02 解决方案和最佳实践

2.1 建设适配的 HPN 网络设施

百度智能云在训练场景下的 HPN 网络架构设计已经有着丰富的经验，AIPod 使用多导轨网络架构，GPU 服务器配有 8 张网卡，然后每张网卡分别连到一个汇聚组的不同 LEAF 上。在 LEAF 和 SPINE 层面，通过 Full Mesh 的方式进行互联。

以下图为例，考虑一个训练场景下的 3 层架构 HPN 网络：

2.1.1 训练和推理任务的流量特征

• 非 MoE 训练任务的流量特征

在传统非 MoE 的训练场景下，跨机通信产生的流量大多数都是同号卡流量。例如在梯度同步时候产生的 AllReduce 或者 ReduceScatter 或者 AllGather，PP 之间的 SendRecv 等。同号卡通信最佳情况可以只经过一跳，以上图为例，每个 LEAF 交换机有 64 个下联口，因此 64 台服务器规模同号卡通信理论上可以做到一跳可达。

规模再大，就只能经过 SPINE 或者最差经过 SUPER SPINE 来进行通信。为了减少流量上送 SPINE，百度百舸在任务调度的时候会自动进行服务器的亲和性调度。在创建任务的时候，尽量把同一通信组下的 Rank 排布在同一 LEAF 交换机下的服务器内，那么理论上大部分流量都可以收敛在 LEAF 下。

• MoE 推理流量特征

对于推理服务来说，MoE EP 之间的 Alltoall 通信流量模式与 AllReduce 等不同，会产生大量的跨导轨流量。虽然对于 Prefill 阶段来说，可以通过软件实现层面规避掉跨导轨的流量，但是 Decode 阶段仍然无法避免跨导轨，这会导致多机之间的通信不只是同号卡通信，跨机流量大部分并不能一跳可达，会有大量的流量上到 SPINE 或者 SUPER SPINE，从而导致时延增加。

• MoE 训练流量特征

对于 MoE 训练的流量会更加复杂，综合了训练和推理的流量特征，既存在传统的梯度同步产生的 AllReduce 或者 ReduceScatter 或者 AllGather，PP 之间的 SendRecv，也存在 EP 之间的 Alltoall 流量。这些流量不但会出现跨导轨传输的问题，他们之间可能会存在 overlap 导致互相干扰。

2.1.2 面向 EP 的 HPN 架构优化

鉴于 Alltoall 通信的特点，我们在设计 HPN 网络的时候，会考虑优先保证跨导轨流量至多 2 跳可达，让 Alltoall 流量收敛到 SPINE 层，以这种方式尽量减少跨导轨的通信时延。如下图所示：

LEAF 层所有设备全部有一根线接入同一台 SPINE 交换机，这样可以让集群内 Alltoall 跨导轨流量全部收敛到 SPINE 层，跨导轨通信时延可以进一步从 5us+ 缩小为 4us。

这种经过优化后的 HPN 网络架构，能接入的卡数主要取决于交换机芯片支持的最大的下联口有多少。虽然对于超大模型的训练任务来说，这个集群规模可能不够，但是对于推理来说，通常不需要那么大规模的机器，是可以满足需求的。

2.1.3 自适应路由彻底消除 hash 冲突

同时，由于 Alltoall 通信流量的特征，LEAF 到 SPINE 之间的通信流量会成为常态。当流量需要通过 SPINE 传输的时候，会由 hash 选择 SPINE 出口的过程，这时候有可能会产生 hash 冲突，导致网络抖动。因此为了避免 hash 冲突，百度智能云基于自研交换机实现自适应路由。如下图所示：

假设 A 和 C 进行 Alltoall 跨导轨通信，A 发出的流量必然要经过 SPINE，那么流量在到达 LEAF 的时候，会基于 packet 做 hash，并结合链路的负载情况动态选择最优的出口，将报文发送到多个 SPINE 上。

基于报文 hash 到不同的物理路径，百度智能云实现了链路负载均衡，消除因 hash 冲突时延增加导致的性能抖动，实现稳定的低时延网络。

详情可参考：彻底解决网络哈希冲突，百度百舸的高性能网络 HPN 落地实践

2.2 流量的管理和优化

2.2.1 避免 incast 造成降速，不同类型流量的分队列管理

• Alltoall 多打一，不合理的配置造成降速

在推理服务中，EP 间的 Alltoall 通信流量特性与传统训练中的 AllReduce 完全不同，网络上多打一造成的 incast 流量非常常见。这种 incast 的严重程度会随着规模的增大而增大。incast 流量的突发，可能会造成接收侧网卡上联的交换机端口向发送侧反压 PFC，导致网络降速。

传统 Alltoall 流量多打一的示意图如下，假设机器 A 和机器 C 的 GPU0、GPU2、GPU4、GPU6 都需要给机器 B 的 GPU0 发送数据，那么在网络上就会出现 8 打 1 的情况。

传统的 Alltoall 实现，例如 PyTorch 内部调用的 Alltoall，是使用 send recv 去实现的，如果使用 PXN 可以缩小网络上的发生多打一的规模，但是多打一依然存在，如下图所示：

因此无论 Alltoall 的算子实现方式如何，网络上的多打一都无法避免。此时如果网络侧的拥塞控制算法的配置不合理，对拥塞过于敏感，就会产生降速，进而对整体吞吐造成影响。

• 推理训练任务中非 Alltoall 流量的干扰

除此之外，如果集群内还存在其他流量，例如训练任务 DP（数据并行）之间的 AllReduce 或者 ReduceScatter 或者 AllGather，或者 PD（Prefill-Decode）之间的 KV Cache 传输，也会对 Alltoall 的流量造成影响，从而进一步降低推理引擎的整体吞吐。

因此无论是端侧网卡的配置，或者是交换机的配置，都需要针对 Alltoall 这种多打一 incast 流量做针对性优化，同时尽量避免集群内其他流量对 Alltoall 流量造成影响。

针对这种情况，我们给出的解决方案如下：

• 在队列管理层面，通过端侧网卡将 EP 的流量做专门的优先级配置，将 Alltoall 流量导入到高优先级队列。其他训练的流量，比如 AllReduce 等使用低优先级队列。

• 在资源层面，在端侧网卡和交换机的高优先级队列上，预留更多的 buffer，分配更高比例的带宽，优先的保证高优先级队列的流量。

• 在拥塞控制算法配置层面，高优先级队列关闭 ECN 标记功能，让 DCQCN 算法对 Alltoall 流量微突发造成的拥塞不做出反应，从而解决 incast 问题造成的降速。

在经过端侧网卡和网侧交换机配合调整后，可以保障 Alltoall 通信流量的通信带宽和传输时延，实现训推任务的互不干扰，并有效的缓解 incast 流量带来的非预期的降速而造成的性能抖动。

经过测试，在我们部署的推理服务中，Alltoall 过程的整体通信时延有 5% 的降低。

2.2.2 DCN 支持弹性 RDMA 实现 KV Cache 满带宽传输

在 PD 分离式推理系统中，还存在 PD 之间 KV Cache 传输的流量。相比 Alltoall 虽然他的带宽需求不算大，但为了避免二者的流量互相干扰，通常我们会让 KV Cache 的传输流量单独走 DCN 网络，使其与 Alltoall 的流量完全隔离开。

在 DCN 网络的设计上，为了保证 KV Cache 流量的传输带宽，其网络架构收敛比采用 1：1。端侧网卡支持弹性 RDMA，使用 RDMA 协议保证 KV Cache 的高性能传输。

在传输库层面，百度智能云使用自研的高性能 KV Cache RDMA 传输库，其接口设计与框架层深度定制，支持上层框架分层传输，也支持多层 KV Cache 的批量传输，便于在框架层做计算与传输的 overlap。

通过以上设计优化，KV Cache 传输在主网卡可以用满带宽，传输时间可以完全被计算 overlap 住，不成为推理系统的瓶颈。

2.3 提高推理服务组件的网络通信效率

在有了高带宽低时延的网络基础设施的基础上，如何用好网络基础设施，是推理服务软件层面需要重点考虑的事情。

在我们对 PD 分离推理服务的 profile 分析当中，发现了一些影响网络通信效率的关键因素。

2.3.1 Alltoall 算子的通信效率

目前社区开源的 DeepEP 已经给出了推理系统中 dispatch 和 combine 过程的 Alltoall 高性能的算子的实现，且性能表现优异。

对于 Prefill 来说，由于输入的 batch size 较大，Alltoall 通信算子的同号卡传输阶段为了平衡显存资源和性能，采用分 chunk 传输的方式，发送和接收会循环使用一小块显存，并对每次 RDMA 发送以及机内 NVLink 传输的 token 数做了限制。

通过实际观测网卡的传输带宽，发现其并没有被打满。在此基础上，我们对网络传输的显存的大小，以及每一轮发送接收的最大 token 数等配置，针对不同的 GPU 芯片，做了一些精细化的调整，使之在性能上有进一步的提升。通过优化，DeepEP 的传输性能有大概 20% 的性能提升，网络带宽已经基本被打满。

对于 Decode 来说，DeepEP 的实现是多机之间的 EP 通信，不区分机内和机间，一律采用网络发送。这样做的考虑是为了机内传输也不消耗 GPU 的 SM 资源，完成网络发送后算子即可退出。在网络传输的时间内做计算，完成后再调用 Alltoall 的接收算子，以此来实现计算和通信的 overlap。但这样做的缺点是机内的 NVLink 的带宽并没有被高效的利用起来，网络传输的数据量会变大。

因此，百度智能云通过在 GPU 算子内使用 CE 引擎做异步拷贝，在不占用 GPU SM 资源的情况下，也能实现机内 NVLink 带宽的高效利用，同时不影响计算和通信的 overlap。

2.3.2 动态冗余专家编码，保证 EP 负载均衡

EP 专家之间如果出现处理 token 不均衡的情况，将会导致 Alltoall 通信算子的不同 SM 之间，以及不同 GPU 的通信算子之间，出现负载不均的情况，导致的结果就是整体通信时间会被拉长。

由于 EP 专家之间的负载均衡是推理服务引擎提升吞吐的非常重要的一环，经过百度智能云的大规模的线上实践的经验来看，静态冗余专家并不能很好的保证专家均衡。因此我们专门适配了针对 batch size 级别的动态冗余专家，把专家均衡度（max token/avg token）基本控制在了 1.2 以下，不会出现明显的「快慢卡」的情况

2.3.3 极致优化双流效果，整体吞吐进一步提升

通信和计算 overlap，隐藏通信的开销，一直都是推理服务，或者大模型训练中，非常重要的课题。

在百度智能云的实践中，我们在线上大规模的推理服务中开启了双流。为了尽量隐藏掉通信的开销，达到最好的 overlap 的效果，除了做 EP 之间的专家均衡以外，对计算算子也做了针对性的优化，例如对计算算子和通信算子 kernel launch 的顺序做合理排布，对二者所需的 SM 资源做合理的分配，避免出现计算算子占满 SM 导致通信算子 launch 不进去的情况，尽可能的消灭掉 GPU 间隙的资源浪费。通过这些优化，整体的吞吐可以提升 20% 以上。

03 总结

百度智能云在大规模 PD 分离式推理基础设施优化的实践中，充分展现了网络基础设施、通信组件与上层业务特征深度融合的重要性。这种融合不仅是技术层面的创新，更是对实际业务需求的深刻理解和响应。

01 引言

大模型的训练和推理任务，本质就是海量数据处理的过程。强大的算力集群，不仅需要高性能的AI加速卡和高性能的RDMA网络，还离不开高性能存储系统的支持。

当前，在大模型训练任务的数据读取、Checkpoint加载，推理任务的快速分发和镜像加载等场景，数据的大小少则几十GiB，多则几百TiB甚至至多达到数PiB。存储速度越快，算力空闲时间越短。这需要一套能够支持大规模算力集群、海量数据场景的高性能存储加速系统。

02 RapidFS存储加速集群

在Create 2025大会，昆仑芯3万卡集群正式发布。为此，我们为RapidFS存储加速服务部署了数百台国产CPU服务器，集群设计总吞吐接近10 TiB/s，以满足3万卡昆仑芯集群大规模数据读写需求。

我们使用部分资源进行了RapidFS性能测试（更多测试细节见后文）。

测试结果显示，20个RapidFS存储节点稳定提供了302 GiB/s吞吐，70个RapidFS存储节点稳定提供了1.03 TiB/s吞吐。单台RapidFS存储节点可提供15 GiB/s吞吐，折合单TiB（裸容量）300 MiB/s。

这些数据表明RapidFS存储加速集群的吞吐性能，随着集群规模线性增长。单台RapidFS存储节点经过软硬一体的协同优化，充分发挥出国产CPU的性能和软件加速效果。

同时，这也意味着在70个RapidFS存储节点提供加速的情况下，100个计算节点并发加载10 GiB的文件仅需1秒，让数据随叫随到。

03 RapidFS产品简介

RapidFS是一款近计算存储加速工具。依托对象存储BOS作为数据湖存储底座，构建容量与性能解耦、冷热分层、透明流转的高性能存储方案。以POSIX挂载和HDFS协议，为上层计算应用提供统一文件访问入口，加速AI训练与推理、海量数据处理与分析、数据分发等业务场景下的存储访问。

04 性能测试详细说明

4.1 服务器配置

在本次测试的昆仑芯3万卡集群中，百度智能云RapidFS以全托管集群方式部署于国产CPU服务器，作为近计算存储加速服务使用。详细配置如下：

4.2 测试规模

我们分别对20个存储节点和70个存储节点规模的RapidFS集群进行了性能测试。

4.3 测试方法

按照DeepSeek V3模型文件构造160个4.3 GiB文件，总计688 GiB。将这些文件导入对象存储BOS并加载至RapidFS存储加速集群中。每个计算节点开启8进程从RapidFS存储加速集群中读取模型文件，持续压测600秒。

4.4 测试结果

测试集群A：20个RapidFS存储节点

测试集群B：70个RapidFS存储节点

百度智能云RapidFS存储加速集群用数据证明了国产算力基础设施的突破潜力。存储性能与算力需求实现「同频共振」，成为大模型训练与推理的效率助推器。

Qwen3 系列全家桶包含了 8 款不同尺寸的模型，覆盖了从 6 亿到 2350 亿的参数规模。其中 2 款混合专家（MoE）模型和 6 款稠密（Dense）模型，均支持「混合推理」机制。

目前，百度百舸平台已经同步支持 Qwen3 系列全家桶的一键部署，为企业提供一站式 AI 服务，实现大模型落地「快稳省」的要求。

一键部署流程

登录百度百舸·AI 异构计算平台，在「**快速开始」**找到 Qwen3 系列模型。

点击模型卡片的「一键部署」开始部署模型。目前 Qwen3 系列模型支持 SGLang、vLLM 推理加速方式。

百度百舸平台已推荐部署不同模型的最低配置资源，您可以按需修改。（注意：需要提前购买算力资源，并在百度百舸平台创建自运维或全托管资源池）

部署成功后，通过「在线服务」列表中查看服务调用信息，获取调用地址和 Token 调用服务。

百度百舸·AI 异构计算平台，是面向大模型训推一体化的基础设施，提供领先的 AI 工程加速能力，从资源准备、模型开发、模型训练到模型部署，为 AI 工程全周期提供丰富特性和极致易用体验。

针对大模型 PD 分离式推理部署方案，百度百舸平台支持自适应 PD 任意配比、细粒度 PD 负载均衡、自适应最优混合并行策略、动态冗余专家编排等，降低 40% TPOT 和 95% 推理成本，实现了极致的推理加速优化。

这套方案正在支撑百度智能云千帆平台，为 40 万客户提供服务。上线以来，推理吞吐提升了 20 倍，速度提升了 50% 以上。

4月28日，IDC《中国汽车云市场(2024下半年)跟踪》报告发布，2024下半年中国汽车云市场整体规模达到65.1亿元人民币，同比增长27.4%。IDC认为，自动驾驶技术深化与生成式AI的发展将为汽车云打开新的成长天花板，推动云计算在汽车行业的持续渗透。

IDC报告显示，2024年全年自动驾驶研发解决方案市场规模达16.34亿元人民币，同比增长18.42%，百度智能云以5.64亿元人民币的市场份额排名第一，份额占比达34.51%。

IDC中国企业级研究部分析师陈启今表示：“自动驾驶研发解决方案市场竞争激烈，百度智能云凭借自动驾驶领域的深厚行业积累和企业解决方案优势，重点关注头部车企和Tier1，市场份额重回至行业第一。”

智能驾驶进入AI时代，智算基础设施与算法、数据三者协同发展，端到端智驾正成为业内共识，车企和供应商不断加码算力集群采购、新算法架构搭建、仿真测试等资本支出，头部客户算力花销和算力规模正朝着亿级、10EFlops级别演进。

陈启今表示，智驾领域技术持续迭代、竞争白热化，客户对自动驾驶解决方案的需求不断增加，而新车网联化进程全面加速及车联网场景创新也驱动客户加大相关投入，这些因素共同为汽车云长期发展积累增长势能。

在这样的趋势下，百度智能云快速完成迭代，将汽车云解决方案已经升级到了3.0版，为车企提供了强大的算力支撑、精准的算法适配、高质量仿真场景及车路协同等核心技术，针对端到端智能驾驶进行了重点的适配，有力推动了自动驾驶的量产落地。

目前，百度智能云正加速对头部车企的覆盖，中国市场TOP15销量品牌、TOP10新能源车企中合作客户均已经实现全覆盖、在主流车企中渗透率达到95%。

百度沈抖：智能基础设施，为应用而生

导读

打点是指在网站或者APP中加入一些统计代码，通过日志记录用户在 APP 内触发的一系列行为，包括点击、滑动等。打点上报后汇聚成用户行为日志，用户行为日志可用于报表统计、AB Testing、个性化推荐等，是分析用户、调整策略、迭代产品的重要依据。

日志中台做为百度内一站式打点解决方案，覆盖了厂内以百度APP为代表的大多产品，每天产生千亿级的打点日志PV。这些日志经过格式化之后，满足用户的各种数据消费需求，光是占用的存储资源每天达上百P。为了满足业务长周期的数据统计、分析、回溯等需求，需要大量的计算和存储成本，部分核心数据甚至需要永久存储。

但是，随着业务快速迭代发展，线上打点只增不减，单条日志越来越长，上报量越来越大，规模日渐膨胀。打点日志的无序增长，既影响打点服务的稳定，也带来计算和存储资源的增长。为了在资源有限的前提下，最大化打点日志的价值，需要对打点日志进行持续的治理，提升打点收益。治理手段包括无用点位的定位和下线、异常打点的发现和修复、已有打点的字段裁剪和上报机制优化、新feature放量或运营活动期间打点服务的稳定性保障等。

△点位全生命周期治理

通过点位治理措施，对于正常需求导致pv上涨的点位，中台能够提前扩充资源，保障业务的高效发展；对于异常问题引起的pv上涨的点位，中台能够协助业务方排查潜在风险，减少业务隐患；对于无用打点，及时发现并完成点位下线，节省后续计算和存储资源；对于冗余打点引起pv上涨的点位，中台协助优化打点上报逻辑，实现高质量打点，推动业务方和日志中台的降本增效。因此，点位治理实践能够助力日志中台感知点位波动、预先为正常流量的增幅留足空间，保证打点符合用户预期、限制低质量有问题流量无序发展，为用户提高更优质量的打点体验，高效率高质量支持业务蓬勃发展。

△全生命周期打点管理

01 要治理的问题和方案

日志中台的成本治理实践主要分三个阶段：人工治理、半自动化治理、点位全生命周期标准化治理。在最开始的阶段，首要目标为与用户沟通，制止打点流量无序增长。因此采取人工治理的方式：由中台同学和点位相关业务同学沟通来推进点位治理，人工治理能够充分了解用户治理诉求，分析点位pv增长原因，在支持业务正常推进的基础上采取定制化的治理措施。通过人工治理的方式，在治理前期取得了一定的治理收益，但随着成本治理的不断推进，治理覆盖的点位、业务线和业务方不断增加，治理变得越来越复杂且难以持续跟进。参照人工治理阶段积累的经验，采用技术化的手段，升级到了半自动平台化治理，从治理实施的角度出发，实现流程化治理，推进了治理前发现异常点位、治理中介入点位治理和治理后成果展示与分析的状态流转，大大提高了治理效率。然而，点位治理不是一劳永逸的事情，为了更好的完成点位可持续治理，日志中台从点位全生命周期的角度出发，实现了点位全生命周期标准化治理，能够修复异常打点、优化冗余打点、下线无用点位，并总结点位相关特性，实现了依据点位特性的长期治理，在对打点的健壮性优化的同时提升了重复治理的效率。

1.1阶段一 人工治理

1.1.1 问题分析

打点用户作为日志中台的核心用户群体，是打点的发起者、使用者，因此是点位治理的主要执行者。打点用户只要有两个核心特点：打点目的多样，点位治理措施多样。打点目的多样是指用户会根据实际业务要求进行打点，例如节日/活动流量打点、实验分析打点、实际需求打点等等。同时打点用户在实现点位治理时，也会有不同的实际操作，例如会选择优化打点代码、对打点实验进行固化或者打点下线、对实际需求打点进行缴费以保证计算和存储资源充足。人工治理阶段依靠着中台同学和业务同学的沟通合作能够在充分满足用户打点目的多样性的同时尽可能提供灵活、丰富的打点治理策略。

△问题分析

点位波动的原因能够从三个维度进行解析说明，分别是业务线、内部因素和外界因素。从业务线角度而言，不同业务线之间因其承担着不同的业务定位，因此其点位波动会受到业务整体的决策而波动，因此点位治理策略应当面向业务线特色而展开。对于较大的业务线，例如手百，需要明确到点位的波动是否与某个细节打点相关。而对于较为独立的业务线，例如贴吧，网盘等，中台更关注业务线整体pv的波动。对于内部因素而言，影响点位pv波动的因素是各种各样的，主要分为三大类，即需求上线导致的打点pv增幅，这其中有因为直接需求、级联需求或需求同步导致的pv涨幅（例如极速版同步手百主版）。有异常打点导致的pv增幅，其中主要包括代码本身异常、流量异常和打点时机异常。在外界因素方面，导致打点pv增幅的原因主要分为三部分：节假日、双十一等商业活动或热点直播导致的pv涨幅，以及实验变更的微观涨幅和APP大盘增长导致的宏观涨幅。综上所述，点位pv波动的因素是较为复杂的，因此点位治理的核心目标是针对各种复杂诱因导致的点位pv波动采取面向用户个性化的点位治理措施，实现高效率灵活的点位治理。

1.1.2 解决方案

阶段一主要依靠人工治理，其步骤可以用以下DAG图说明，支持四大类点位治理模式**【需求普涨、异常修复、活动流量和打点优化】**，模版化的处理步骤能覆盖绝大部分点位治理场景。

1.2 阶段二 半自动治理平台化

1.2.1 问题分析

随着成本治理的不断推进，治理覆盖的点位、业务线和业务方不断增加，治理变得越来越复杂且难以仅靠人力沟通持续跟进，而点位治理方作为打点治理的主要发起方和跟进方，需要频繁的与业务方进行交流，以便于针对点位实际和业务现状发起点位治理。同时点位治理过程需要全过程记录，依靠人工治理架构的点位治理过程使用文档记录全过程，同时点位治理流程中产生的点位治理时间轴、点位治理总览、点位治理成果均以文档的形式记录会有展现效果差、依赖人力更新的问题。同时点位治理流程较为复杂，如果使用人力治理+文档记录的措施缺乏标准的状态流转，无法保证打点治理的高效和质量。

△半自动化平台治理

1.2.2 解决方案

打点治理的涉及的方方面面非常多，按照时间顺序而言，主要分为异常点位的发现和挖掘、面向异常点位的治理实施、以及治理后成果的总结和治理全局分析。对于涉及的主体而言，打点治理主要涉及的被动主体为点位用户以及点位信息，主动主体为点位治理方，对点位本身而言，打点治理流程需要感知点位异常波动、整理点位相关基础信息【业务线、负责人、历史相关需求】等、最终整理完成点位自身特色信息【点位属性是活动点位、基础框架点位等】。对于点位治理方而言，需要针对异常点位发起点位治理【通过如流群内部消息面向业务同学】、需要根据点位自身情况选取点位治理策略【打点优化、异常治理、成本追缴】等，同时在点位治理流程中，点位治理负责人需要及时跟进点位治理情况，推进点位治理信息，在治理完成后需要总结点位治理结果报表，并完成阶段性总结。对于业务方而言，用户需要感知点位pv波动信息、点位治理需求并给出点位治理及时反馈。因此在打点治理的重要场景上，主要的难题为：需要形成点位治理【前期、中期和后期】的规范化治理流程，有效推进点位治理状态的流转【发现异常、介入治理、推进治理、完成治理】；由于点位治理是面向用户导向的，其中涉及到大量的沟通成本，为了加速办公效率，针对IM沟通需要做专门的优化。针对上述问题，日志中台推进了打点半自动化治理平台的建设，实现了治理标准流程化、办公沟通智能化、点位治理高效化。

△一站式成本治理平台

成本治理平台将打点治理分为三个阶段**【治理前-异常波动点位挖掘阶段】，【治理中-目标点位介入治理阶段】，【治理后-治理成果展示&分析阶段】**。

在治理前期【异常波动点位挖掘阶段】，该阶段核心为实现一个定时例行任务，该任务定时获取所有点位的天级pv，并根据异常波动识别算法判别出异常点位，并组装该点位的其他相关信息（业务线、是否是实时流点位等），最终完成异常点位信息的下发和邮件通告。异常点位挖掘任务依托定时任务调度系统完成开发，实现算子高效配置，任务定时准确执行，能够有效挖掘出异常点位信息。

在治理实施中期【目标点位介入治理阶段】，按照点位治理状态的不同，分为三个核心页面进行综合治理，即待治理页面，正在治理页面和治理完成页面。其中待治理页面主要展示由【异常波动点位挖掘阶段】所得到的异常点位列表，在点位负责人甄别该点位确实符合点位治理要求后，即可一键建群触发点位治理流程。触发后，该点位即可展示在正在点位治理页面，针对目标点位治理，点位治理负责人即可按照【点位治理默认状态流转图】或【自定义算子点位治理状态图】完成点位治理，在治理过程中，平台使用企业办公IM企业机器人来实时推送点位治理模版信息【点位治理背景、点位治理缴费文档等】，进而加速点位治理过程。同时在点位治理过程中，数据库会记录点位状态变更时间轴，实时记录点位治理状态。当点位流程治理完成后，点位会移入已经治理完成的点位页面。已经治理完成点位页面会同步至指定MySQL数据库中，智能报表平台会针对该数据库做实时数据分析和可视化报表生成。

在治理后期【理成果展示&分析阶段】该阶段核心是展示指定时间范围内的治理效果【已经治理pv、已治理的点位个数】，以及分析相关指标【各个治理种类的点位数目、已经追缴的成本金额】。治理平台采取可视化智能报表平台完成对点位治理的趋势分析，按照时间顺序对已经治理的pv数和点位个数完成了对点位治理的分析。

△办公IM成本治理机器人

在点位治理过程中，点位治理负责同学需要和点位负责同学、点位相关RD有频繁且密集的沟通，为了提高业务沟通效率，点位治理平台接入 办公IM企业级开发机器人【成本治理机器人】，成本治理机器人实现了全流程的治理加速，在治理发起时，点位负责人能够针对异常目标点位一键发起群聊，该群聊名为【点位监控】（相关）点位流量上涨。在治理发起后第一时间，成本治理机器人会同步点位基本信息、点位涨幅pv等，通报使用自动化通报模版。在点位治理推进中，如流机器人支持发送自定义信息并@相关业务人员完成治理状态推进。

1.3 阶段三 点位全生命周期标准化治理

1.3.1 问题分析

△打点全生命周期

点位治理不是一劳永逸的事情，为了更好的完成点位可持续治理，日志中台从点位角度出发实现了点位全生命周期标准化治理架构。打点本身是点位治理的重要对象，同时打点本身自身也有着足够的信息量，例如，点位本身会因为业务下线或业务场景的迭代而成为无用点位；点位本身会因为打点开发代码 BUG而成为异常点位或是冗余点位；同时点位自身因为其长期存在，进而会在一定时间内长期波动，导致需要点位治理频繁介入。因此点位治理问题需要在点位生命周期维度完成对无用点位的下线；对有异常问题的点位完成修复、对于冗余点位的优化；在点位长期波动角度，完成基于点位特性的高效治理，而非是机械重复的全流程点位治理。

1.3.2 解决方案

1.3.2.1  基于点位特性持续治理

基于点位特性持续治理，图中是某运营活动相关点位pv波动图，图中可以清晰看到，该点位在所示周期内出现了三次点位波动，因为该点位属于活动运营性质点位，因此在春节期间、618活动期间以及暑假活动运营期间，出现了多次波动，如果按照常规治理手段，需要多次频繁介入，为了在持续性治理中提高治理效率，应当结合点位业务属性，构建出治理经验总结，在后续多次治理中不断完善治理属性，即可根据历史治理经验实现既定治理措施。我们将点位根据业务属性而形成的分类称之为“点位特性”，而根据点位特性的操作化治理称之为“基于点位特性的持续治理”，实践表明，基于点位特性的持续治理流程针对点位多次治理，大大加速效率。例子中的运营活动点位，在得知其活动属性的基础上，仅需关注涨幅与活动映射关系以及预估流量是否与预期相符合即可，无须重复治理流程。

△基于点位特性持续治理

打点治理是一个长期持续性的操作，单个点位存在多次介入治理的可能性，因此考虑到点位的持续性治理是非常重要的。在长期的点位治理中，点位因其个性化特色，具有自身属性。结合点位自身特色与规则介入，能够在持续性治理操作中实现基于点位特性的治理。从点位特色出发，常见的点位种类有如下六种，分别为单需求类型点位、复合需求类型点位、活动属性类型点位、级联需求类型点位、实验类型点位、框架性质类型点位。其中不同点位种类具有自身的相应的特征，因此应当采取相关的治理策略，进而大大降低了二次治理的难度和工作量。

下面是常见点位特性的说明及相应的再次治理策略：

• 单需求类型点位，该类点位上下游关系较为简单，点位定位明确，主要完成单一或固定类型的需求，因此其涨幅与需求之间关联，对于二次治理时，重点关注点位所对应的需求方即可，治理策略较为简单。

• 复合需求类型点位，该类点位往往是多业务方共用打点，执行不同类型的需求，因此再次治理时，需要补充记录点位使用拓扑关系，完善点位下游关系。

• 活动类型点位，该类打点往往与节假日/运营活动强关联，例如小说相关打点往往和寒暑假密不可分，手百皮肤活动往往与运营活动强相关，对于此类打点，需要核实对应的活动，并保证容量充足即可。

• 级联需求类型点位，该类打点往往提供一个基础性的功能，例如工具性质打点，这类打点并不直接作用于业务方，而是为业务方提供第三方能力，因此其上涨与自身无关，此类打点需要核实符合预期即可。

• 实验类型点位，该类打点往往与策略实验放量相关，具有一定的活动周期属性，但是与活动属性点位不同的是，实验复合预期后可能会固化，需要核实长期上涨带来的费用。

• **框架性质类型打点，**该类打点作为手百等APP的基础打点，承载着多项核心功能，往往打点量级较大（单点位可达百亿）正常涨幅波动也较大（天级波动可达10亿上下），其波动需要结合DAU大盘涨幅进行分析，往往无法与某些需求直接关联。

  

  △治理角度的常见点位分类

  1.3.2.2  推进无用点位下线

  随着业务的持续迭代与推进，点位的状态也在不断更新，一些点位会逐渐成为无用点位。无用点位因其自身属性分为两大类：无流量点位和有流量无使用点位，其中无流量点位往往因为实验的下线或业务线的变更导致点位无流量，而有流量无使用点位往往因为业务的优化升级或是日常迭代导致点位依然有上报，但是不再有下游使用，上报的数据内容也不再有访问记录。其中无流量点位会消耗一定的数据分析和维护成本，并对相关分析带来一定影响，而有流量无使用的点位则会占用一定的计算和存储资源。因此，推进无用点位下线是点位全生命周期治理的重要一环，日志中台及相关数据存储团队形成了完善的无用点位下线流程。

△无用点位下线流程图

在点位负责人完成上线后，中台及相关数据存储团队会进行例行的无用点位识别任务，当识别出无用点位后，会通知相关点位负责人，若点位负责人支持点位下线，则点位会进入预下线状态，当点位在一定时间段内仍无相关业务反馈，则该点位会完成下线。若点位负责人因业务特殊需求，则能够继续保留该点位，若该点位超过三次被识别为无用点位则会报备总监确认，结合业务实际则可以录入白名单。

△基于鉴权信息访问判别来源

无用点位识别任务的核心在于识别出有流量但是没有下游使用的点位，识别任务会根据相关业务的若干数据表的鉴权信息筛选出相关的下游访问来源，这些下游访问来源包括但不限于实验分析平台、数据分析平台、报表平台，相关业务使用和一些定时例行任务。当筛选出相关点位的具体下游访问来源之后，即可联合下游访问来源的具体业务信息识别出该点位是否确实无人使用，进而判断出无用点位。

1.3.2.3  异常点位修复&冗余点位优化

△异常点位修复&冗余点位优化

为了更好的完成点位治理，需要对打点潜在问题进行分析，进而能够根据潜在问题制定相应的解决方案。结合打点实际，业务实际和中台业务逻辑可以发现，打点存在有几类问题：冗余打点浪费了一定的资源，多条打点公共参数相同，仅仅业务参数有差异，但是依然分开若干条上报；对于比值类实验指标，不同的打点量级的实验效果是一致的，但依然打了较大量级的日志条数；异常打点不符合业务预期，异常上报了一定量级的日志，点位缺乏分级别处理无法做到重要点位高优先级处理。为了解决上述问题，我们进行了针对性的方案优化，针对冗余打点采取合并上报、打点采样等打点优化措施，针对异常打点采取【发现异常、确认异常，最终修复异常】的工作流程。

02 项目收益&业务反馈

日志中台点位治理实践项目对点位实现各种灵活治理措施，包括但不限于打点优化、异常修复、成本追缴和活动流量观察。在点位治理项目上线后，助力业务方发现10+潜在风险点，手百每人每天上报日志减少上百条。治理项目每年治理上千亿pv，节省数百万的用于计算、存储的年化成本费用。

在治理过程中，我们坚持用户导向，点位治理流程协助用户方发现很多问题，排查了潜在异常，节约了很多资源，也收到很多高质量的业务方真实反馈。

△业务高质量反馈

03 总结与展望

△总结与展望

日志中台打点治理实践方案已经取得了一定的项目收益，协助用户优化了了打点体验，提升了打点质量，升级了业务性能，同时也助力了手百等业务的稳健、高质量发展，在未来日志中台会持续打造业界领先的打点治理方案，进一步优化用户体验，帮助用户精细化排查点位波动的原因，更为精准化的定位问题原因，精密化提升打点收益与产出，切切实实使每一次打点都取得超出预期的收益。同时进一步助力业务发展，降低手百每人每天上报的日志数目，在有限的打点资源内尽可能创造更高规模的收益。同时随着日志中台对于事件的支持，打点治理方案会探索基于事件的pv治理策略，支持更细粒度的打点治理。

-----END------

推荐阅读

从数字化到智能化，百度 SRE 数智免疫系统的演进和实践

走！Ké武汉，看百度智能云生态大会

名列前茅！百度文心大模型4.5及X1在中国信通院“方升”大模型基准测试中表现优异

飞桨新一代框架3.0正式发布：加速大模型时代的技术创新与产业应用

中国人工智能产业发展联盟（以下简称“AIIA”）紧密跟踪大模型和智能体的技术发展与行业应用动态，构建并发布了“方升”（FactTesting）大模型基准测试体系，自2024年以来已对国内外开源与闭源大模型开展了6轮能力监测，累计测试了200余个大模型，持续跟踪其技术演进与表现，为行业技术选型与能力评估提供了重要依据。2025年，评测范围进一步扩展至多模态理解、文生图、文生视频等领域，并率先开展智能体测试的研究与实践，初步构建了智能体测试验证平台，为产业界提供全面的技术评估参考。

2025年4月9日，在南京召开的中国人工智能产业发展联盟第十四次全体会议上，中国人工智能产业发展联盟正式发布“方升”大模型基准测试结果（2025年1季度）。

“方升”大模型基准测试结果发布现场

在权威发布环节，AIIA 总体组组长、中国信通院人工智能研究所所长魏凯发布了“方升”人工智能基准测试结果及测试观察。在大语言模型测试结果中，文心大模型4.5在基础能力结果、文心大模型X1在推理能力结果中均名列前茅。

大语言模型-基础能力测试结果

大语言模型-推理能力测试结果

3月16日，百度正式发布文心大模型4.5和文心大模型X1。

文心大模型4.5是百度自主研发的新一代原生多模态基础大模型，通过多个模态联合建模实现协同优化，多模态理解能力优秀；具备更精进的语言能力，理解、生成、逻辑、记忆能力全面提升，去幻觉、逻辑推理、代码能力显著提升。

文心大模型X1具备更强的理解、规划、反思、进化能力，并支持多模态，**是首个自主运用工具的深度思考模型。**作为能力更全面的深度思考模型，文心大模型X1兼备准确、创意和文采，在中文知识问答、文学创作、文稿写作、日常对话、逻辑推理、复杂计算及工具调用等方面表现尤为出色。

文心一言官网

目前，两款模型已在文心一言官网上线，免费向用户开放。（yiyan.baidu.com）

2025是大模型技术全面迭代的一年，百度将在人工智能、数据中心、云基础设施上更大胆地投入，打造更好、更智能的下一代模型。

----------END----------

推荐阅读

飞桨新一代框架3.0正式发布：加速大模型时代的技术创新与产业应用

即刻体验！文心大模型X1现面向企业用户全面开放！

一篇论文，看见百度广告推荐系统在大模型时代的革新

前沿多模态模型开发与应用实战3：DeepSeek-VL2多模态理解大模型算法解析与功能抢先体验

秒哒首发即爆发！上线首日吸引2万用户，打造3万应用！

人工智能技术日新月异，深度学习框架作为技术底座深刻影响着算法创新的速度与产业落地的深度。飞桨框架以五大核心突破回应时代命题，正式发布3.0版本。飞桨框架3.0实现了从底层硬件适配到顶层开发体验的全面进化，在训练效率、性能、兼容性等关键指标上建立新标杆，作为支撑千行百业智能化转型的“AI 操作系统”，此次升级不仅是技术参数的迭代，更是面向大模型工业化生产范式的革命性突破。无论是前沿算法研究还是产业级大模型落地，飞桨框架3.0都将成为开发者的首选利器。

作为中国首个自主研发的产业级深度学习平台，飞桨一直坚持开源路线，支撑产业智能化升级。2025年4月1日，飞桨框架迎来重大更新，发布飞桨框架3.0正式版。飞桨框架3.0版本不仅延续了飞桨框架2.0系列动静统一、训推一体的特性，更在自动并行、神经网络编译器、高阶自动微分等方面取得突破，为大模型时代的技术创新与产业应用提供了强大支撑，为开发者打造了一站式、高性能的深度学习开发体验。

飞桨框架3.0具备以下五大新特性：

1）动静统一自动并行：通过少量的张量切分标记，即可自动完成分布式切分信息的推导，Llama 预训练场景减少80%的分布式相关代码开发。

2）大模型训推一体：依托高扩展性的中间表示（PIR）从模型压缩、推理计算、服务部署、多硬件推理全方位深度优化，支持文心4.5、文心X1等多款主流大模型，DeepSeek-R1满血版单机部署吞吐提升一倍。

3）科学计算高阶微分：通过高阶自动微分和神经网络编译器技术，微分方程求解速度比 PyTorch 快115%。

4）神经网络编译器：通过自动算子自动融合技术，无需手写 CUDA 等底层代码，部分算子执行速度提升4倍，模型端到端训练速度提升27.4%。

5）异构多芯适配：通过对硬件接入模块进行抽象，降低异构芯片与框架适配的复杂度，兼容硬件差异，初次跑通所需适配接口数比 PyTorch 减少56%，代码量减少80%。

01 背景概述

在大模型时代，深度学习框架的重要性愈发凸显，成为推动人工智能技术发展的核心引擎。算法、算力、数据作为人工智能技术的三大要素，其相互作用与协同发展不断催生着新的突破。越来越多的实例证明，算法创新能够发挥出更为显著的威力。DeepMind 的 AlphaFold3通过动态扩散算法突破蛋白质结构预测精度，已成功应用于抗疟疾等药物分子设计；DeepSeek 通过算法创新，成功提升了 DeepSeek V3模型的性价比，大幅降低了训练成本。这些突破性进展表明，算法创新正在重构技术发展的成本曲线。

然而，算法创新并非易事，当前算法工程师和科研人员在使用现有深度学习框架进行算法创新时，仍面临诸多挑战。

1）大模型分布式开发门槛高：大模型参数规模庞大，其分布式训练需使用复杂的并行策略，包括数据并行、张量并行、参数分片并行、流水线并行、序列并行、专家并行等。大模型开发中，如何实现多种并行策略的高效协同已成为关键瓶颈。

2）模型推理部署困难重重：由于算法训练和推理任务的计算、通信存在较大差别，算法工程师在完成模型算法创新后，往往难以直接应用于推理部署，需要大量的工程开发工作。

3）前沿模型架构灵活多变：科学智能（AI for Science）等新兴领域的快速发展，对深度学习框架提出了新的要求，包括求解复杂微分方程所需的高阶自动微分、傅里叶变换等科学计算操作、复数的高效运算等。

4）模型极致性能优化难度大：以大模型为代表的很多场景对训练推理速度有严苛要求，为突破计算瓶颈，工程实践中常需通过手写 CUDA 内核代码进行性能优化，这对算法工程师的底层编程能力提出了极高要求。

5）异构芯片适配成本高：AI 应用场景丰富多样、算力需求巨大，单一芯片难以满足业务需求。而不同芯片之间的硬件架构、软件栈成熟度、开发接口差异大，业务适配成本高、软硬协同优化难。

为此，飞桨新一代框架3.0应运而生：该版本提供了丰富的深度学习相关的各种开发接口；表示层专注于计算图的表达与转换，通过高可扩展中间表示 PIR，实现动转静、自动微分、自动并行、算子组合以及计算图优化等核心功能；调度层负责对代码或计算图进行智能编排与高效调度，支持动态图和静态图两种不同的执行模式；算子层由神经网络编译器 CINN 和算子库 PHI 共同构成，涵盖了张量定义、算子定义、算子自动融合和算子内核实现等关键功能；适配层则用于实现与底层芯片适配，包括设备管理、算子适配、通信适配以及编译接入等功能。

飞桨框架3.0架构图

飞桨框架3.0凭借强大的功能和优化的设计，帮助算法工程师和科研人员以更低的成本进行算法创新，并实现产业应用。以百度文心大模型为例，飞桨框架3.0在训练、推理等方面为文心大模型提供端到端优化，训练方面重点提升训练吞吐、训练有效率和收敛效率，集群训练有效率超过98%；推理部署方面通过注意力机制量化推理、通用投机解码等技术提升推理吞吐和效率；全面支持文心4.5、文心X1等大模型的技术创新和产业应用。

02 全面支持自动并行训练

降低大模型开发训练门槛

在大模型时代，随着模型规模和训练数据量的不断增长，传统的单机单卡训练已无法满足需求，分布式并行训练成为加速大模型迭代的关键。然而，无论是动态图还是静态图，当前市场上的并行训练框架普遍存在使用成本高的问题。开发者既要熟知模型结构，还要深入了解并行策略和框架调度逻辑，使得大模型的开发和性能优化门槛非常高，制约了大模型的开发和训练效率。

针对这一痛点，飞桨提出了动静统一自动并行方案。该技术通过原生动态图的编程界面与自动并行能力，同时保障了灵活性和易用性，大幅降低了大模型并行训练的开发成本；同时，利用框架动静统一的优势，一键转静使用静态优化能力，提供极致的大模型并行训练性能。开发者仅需少量的张量切分标记，框架便能自动推导出所有张量和算子的分布式切分状态，并添加合适的通信算子，保证结果正确性。具体工作流程如下图所示：

动静统一自动并行流程图

飞桨框架3.0动静统一自动并行技术的具体特点如下：

1）简单易用，大幅降低大模型并行训练开发成本。飞桨自动并行功能允许用户在不考虑复杂分布式通信的情况下完成算法实现。仅需借助少量 API 调用，即可将算法转换为并行训练程序，显著简化开发过程。以 Llama2的预训练为例，传统实现方式需要开发者精细调整通信策略，以确保正确高效执行，而自动并行实现方式相比传统方式减少80%的分布式核心代码，极大降低了开发复杂度。

2）全面可用，适用于众多大模型训练场景。**基于飞桨大模型开发套件（PaddleNLP、PaddleMIX），飞桨框架已全面验证 Llama、QwenVL 等从大语言模型到多模态模型的预训练、精调阶段的自动并行训练。

3）轻松加速，一键动转静提供极致性能优化。**得益于飞桨框架独特的动静统一设计，用户仅需简单添加一行代码，即可轻松实现从动态到静态的转换。这一转换使得我们能够充分利用多种静态优化技术，匹敌甚至超越经过极致优化的动态图训练效率。

4）协同文心，开源多项大模型独创优化策略。**飞桨协同文心创新实现精细化重计算、稀疏注意力计算优化、灵活批次的流水线均衡优化等，这些优化技术在飞桨框架3.0中开源，助力开发者进行极致的大模型训练性能优化。

未来，我们将进一步探索无需使用张量切分标记的全自动并行，让开发者可以像写单机代码一样写分布式代码，进一步提升大模型的开发体验。

动静统一自动并行训练速度对比

03 大模型训推一体

提升推理部署效率

在完成模型的开发和训练后，我们需要面对推理部署场景的挑战：如何低门槛、低开发成本、快速地将模型部署到业务场景，并提供低时延、高吞吐、低算力成本的推理服务。**自2.0版本起，飞桨便采用了“动静统一、训推一体”的设计理念，3.0版本也继续秉持这一理念，并在大模型场景下持续优化，发挥更大作用。

在推理部署方面，相较于动态图，静态图不仅可部署范围更为广泛，它能够通过整图导出的方式，摆脱对 Python 源代码和执行环境的依赖；而且更适合进行全局调优，可通过手写或者借助编译器自动实现算子融合等方式来加速推理过程。

得益于动静统一的架构和接口设计，飞桨能够完整支持动态图和静态图这两种不同的运行模式，并且具备出色的整图导出能力。飞桨的动转静整图导出成功率高达95%，高于 PyTorch 62%。“训推一体”意味着能够在同一套框架下，尽可能复用训练和推理的代码，特别是复用模型组网代码。**在完成模型的开发训练后，只需进行少量的开发工作，即可实现快速推理部署。**与业界当前先使用 PyTorch 和 DeepSpeed 进行训练，再采用 vLLM、SGLang、ONNXRuntime 等推理引擎进行推理部署的方案相比，飞桨采用训练和推理使用同一套框架的方式，能够有效避免不同框架之间可能出现的版本兼容性问题，以及因模型结构变化、中间表示差异、算子实现差异等带来的困扰。

飞桨训推一体架构设计

大模型的推理部署需要更好地平衡成本、性能和效果，飞桨框架3.0全面升级了大模型推理能力，依托高扩展性的中间表示（PIR）从模型压缩、推理计算、服务部署、多硬件推理全方位深度优化，能够支持众多开源大模型进行高性能推理，并在 DeepSeek V3/R1上取得了突出的性能表现。飞桨框架3.0支持了 DeepSeek V3/R1满血版及其系列蒸馏版模型的 FP8推理，并且提供 INT8量化功能，破除了 Hopper 架构的限制。此外，还引入了4比特量化推理，使得用户可以单机部署，降低成本的同时显著提升系统吞吐一倍，提供了更为高效、经济的部署方案。在性能优化方面，我们对 MLA 算子进行多级流水线编排、精细的寄存器及共享内存分配优化，性能相比 FlashMLA 最高可提升23%。综合 FP8矩阵计算调优及动态量化算子优化等基于飞桨框架3.0的 DeepSeek R1 FP8推理，单机每秒输出 token 数超1000；若采用**4比特单机部署方案，每秒输出 token 数可达2000以上，推理性能显著领先其他开源方案。**此外，还支持了 MTP 投机解码，突破大批次推理加速，在解码速度保持不变的情况下，吞吐提升144%；吞吐接近的情况下，解码速度提升42%。针对长序列 Prefill 阶段，通过注意力计算动态量化，首 token 推理速度提升37%。

DeepSeek 模型单机推理速度对比（H800上256并发不含 MTP 测试）

04 助力科学前沿探索

提升微分方程求解速度

人工智能正以前所未有的方式重塑科学研究范式，成为推动科学发现与技术创新的“超级加速器”。例如，布朗大学团队首次提出物理信息神经网络（PINNs），通过自动微分实现物理约束与数据驱动的结合；NVIDIA 实验室提出全球高分辨率气象预报模型 FourCastNet，预报时长从几个小时缩短到几秒钟；2025年1月，Baker 团队在《Nature》发表研究，利用 RFdiffusion 算法从头设计出能够高效中和眼镜蛇蛇毒中三指毒素的蛋白质。**科学智能（AI for Science）为解决科学问题带来新方法的同时，也对深度学习框架带来诸多新挑战。**对科学问题机理化的探索，需要深度学习框架能够具备更加丰富的各类计算表达能力，如高阶自动微分、傅里叶变换、复数运算、高阶优化器等等；此外，如何实现深度学习框架与传统科学计算工具链的协同，也是需要思考的问题。

为了解决这些挑战，飞桨框架3.0提出了基于组合算子的高阶自动微分技术，如下图所示，该技术的核心思想是将复杂算子（如 log_softmax）拆解为多个基础算子的组合，然后对这些基础算子进行一阶自动微分变换。重要的是，基础算子经过一阶自动微分变换后，其所得的计算图仍然由基础算子构成。通过反复应用一阶自动微分规则，我们可以轻松地获得高阶自动微分的结果。这一机制不仅完美兼容动态图模式和静态图模式，而且在动态图模式下支持 N+1阶微分的灵活拆分，同时在静态图模式下能够进行高效的编译器融合优化。

基于组合算子的高阶自动微分技术

基于飞桨框架的高阶自动微分和编译优化技术，实现了方程求解类模型性能的大幅提升，英伟达 Modulus 的41个不同方程实验显示，飞桨的微分方程求解速度比 PyTorch 开启编译器优化后的2.6版本平均快 115%。此外，飞桨还实现了傅里叶变换、复数运算、高阶优化器等功能，这些方法在航空航天、汽车船舶、气象海洋、生命科学等多个领域都具有广泛的应用潜力，为科学研究和工程实践提供了有力的支持。在模型层面，我们成功研发了赛桨（PaddleScience）、螺旋桨（PaddleHelix）等系列开发套件，为科学计算提供了更为便捷、高效的解决方案。飞桨对 DeepXDE、Modulus 等主流开源科学计算工具进行了广泛适配，并成为 DeepXDE 的默认推荐后端。

飞桨 AI for Science 全景图

05 神经网络编译器技术

实现框架通用性能提升

在众多深度学习的应用场景中，如大模型训练、自动驾驶等，对模型的训练与推理速度均提出了极高的要求。然而，**要实现训练与推理速度的提升并非易事，这需要我们紧密结合模型结构与硬件特性，开展大量的工程实现与优化工作。**在模型结构层面，模型结构正日益呈现出多样化的趋势，从基础的全连接网络，到复杂的卷积神经网络、循环神经网络、Attention 网络、状态空间模型、图神经网络等，每一种模型结构都拥有其独特的计算模式与优化需求。在硬件特性方面，算力的增长速度远远超过了访存性能的提升，访存性能的瓶颈限制了访存密集型算子（如归一化层、激活函数等）的执行效率。特别是，当前市场上硬件平台种类繁多，我们需要投入大量的人力物力，进行针对性的优化工作，这将严重拖慢算法创新和产业应用的速度。

让我们通过一个实例来阐释这一点。我们以 Llama 模型中经常使用的 RMS Normalization（Root Mean Square Layer Normalization）为例，其计算公式相对简单明了。

假设我们需要实现 RMS Normalization 的计算，最简单的办法是，我们可以使用飞桨框架提供的张量运算开发接口，调用平方、求和、除法、开根号等操作来完成，代码如下：

class RMSNorm(paddle.nn.Layer):
    def __init__(self):
        super().__init__()
        self.variance_epsilon = 1e-6
        self.weight = paddle.create_parameter(shape=[768], ...)
        
    def forward(self, x):
        variance = x.pow(2).mean(-1, keepdim=True)
        x = paddle.rsqrt(variance + self.variance_epsilon) * x
        return x * self.weight

上述代码开发简单，但是由于存在大量的访存操作导致性能很差，且显存占比较多；为了突破访存瓶颈，开发者可以选择通过手写 CUDA 代码的方式实现一个融合的 FusedRMSNorm 算子，但是对于开发者要求更高，开发成本也更高，更重要的是这种方式极大降低了可维护性和灵活性。

为此，飞桨框架3.0研制了神经网络编译器 CINN（Compiler Infrastructure for Neural Networks），相比于 PyTorch 2.0的 Inductor 加 Triton 的两阶段编译方案，CINN 支持直接从神经网络中间表述编译生成 CUDA C 代码，通过一阶段的编译方案，CINN 避免了两阶段编译由于中间表示信息传递和表达能力限制所造成的信息损失，具备更通用的融合能力和更好的性能表现。具体一些技术创新如下：

1）以 Reduce 为核心的算子融合技术。摒弃传统的粗粒度 pattern 匹配模式，支持维度轴自动变换对齐融合，在保证计算正确性的同时，具有更强的算子融合能力，带来更大的性能优化潜力。

2）动静态维度的高效后端 Kernel 调优技术。算子全面支持 reduce、broadcast、transpose 等多种算子的不同组合方式，针对各类算子组合和数据类型，自适应不同维度大小与不同硬件配置，进行全场景高效调优。通过自动向量化提高 BF16、FP16等小数据类型的访存效率。通过分析与分桶机制，实现动静态运行时配置生成，根据运行时的硬件配置，在无需 profiling 的情况下生成高效的 kernel。

3）动态维度的复杂表达式化简技术。建立了分层化简体系，Lower、Schedule、CodeGen 阶段执行不同等级化简方法，解决传统化简方法中多场景叠加后化简困难、化简不彻底问题。实现了复杂表达式结构化简，抽取融合算子经过编译、调优后的固定子结构进行专项化简，且灵活支持自定义化简方法。

神经网络编译器 CINN 流程图

借助神经网络编译器技术，我们能够在维持高度灵活性和易用性的基础上，实现性能的显著提升。以下为 A100平台上 RMSNorm 算子的性能测试结果：相较于采用 Python 开发接口组合实现的方式，经过编译优化后的算子运行速度提升了4倍；即便与手动算子融合的方式相比，也实现了14%的性能提升，在灵活性与高性能之间寻找到了较为理想平衡点。我们在 PaddleX 开发套件里选取了超过60模型进行实验，使用 CINN 编译器后超60%模型有显著性能提升，平均提升达27.4%。重点模型相比 PyTorch 开启编译优化后的版本平均快18.4%。

神经网络编译器 CINN 训练速度对比

06 标准化统一硬件适配

加速软硬协同优化

在深度学习的创新探索与产业落地进程中，单一芯片往往难以满足复杂多变的业务需求，因此通常需要融合运用多种芯片来构建解决方案。大模型应用对于算力的需求极为庞大，而单一芯片的供应数量有限，远不足以支撑大模型的高效运行。不仅如此，不同场景对芯片性能有着差异化的严苛要求，单一芯片更是难以全面满足。例如，在大模型训练场景中，需要芯片具备大显存、高带宽以及高可靠性的特性；自动驾驶场景则强调低时延与高可靠性，以保障行车安全；端侧场景则聚焦于低功耗，以延长设备的续航时间。

飞桨框架自发布之初就考虑了多硬件适配的需求，历经持续迭代与演进，3.0版本构建了一套成熟且完善的多硬件统一适配方案：

1）飞桨聚焦于硬件接口的抽象。飞桨将硬件接口细分为设备管理、计算执行、分布式通信等多个类别，通过标准化的硬件接口成功屏蔽了不同芯片软件栈开发接口之间的差异。通过合理的抽象，减少了适配所需的接口数量，以昇腾芯片适配为例，初步跑通所需适配接口数比 PyTorch 方案减少56%，适配代码量减少80%。

2）基于标准化适配接口的定义，飞桨实现了松耦合、可插拔的架构。在此架构下，每类芯片仅需提供标准化适配接口的具体实现，便能轻松融入飞桨后端，极大地简化了芯片接入的流程。

3）考虑到不同芯片软件栈成熟度的差异，飞桨提供了丰富多样的接入方式，涵盖算子开发、算子映射、图接入、编译器接入等。针对大模型训练与推理需求，飞桨还具备全栈优化能力，如支持动静统一编程范式、超大规模分布式训练技术，提高了模型开发与部署效率。

4）飞桨与芯片厂商携手合作，共同构建了官方代码合入机制、例行发版机制和持续集成测试等研发基础设施，还建立了日级别例行功能与精度监测，保障开发者使用体验。

这些举措提升了研发效率，确保飞桨与各类芯片的适配工作高效、稳定推进。

多硬件统一适配方案

基于前述技术，飞桨与芯片厂商紧密合作，**携手共建蓬勃发展的硬件生态，当前飞桨已与超过40家成员单位开展合作，适配超过60个芯片系列。**飞桨已与24家硬件厂商伙伴达成深度合作，共同推出了飞桨生态发行版。飞桨能够有效屏蔽底层硬件之间复杂多样的差异，为开发者提供简洁易用的开发接口。**开发者只需编写一份代码，就可以让程序在不同芯片上顺畅运行，轻松实现业务的跨芯片迁移。**飞桨的跨平台能力为业务在芯片选择方面带来了前所未有的灵活性，使开发者能够根据实际需求，更加自由、高效地规划业务部署。

07 总结

飞桨框架3.0面向大模型、异构多芯进行专属设计，向下适配异构多芯，充分释放硬件潜能；向上一体化支撑大模型的开发、训练、压缩、推理、部署全流程，并助力科学前沿探索。具备动静统一自动并行、大模型训推一体、科学计算高阶微分、神经网络编译器、异构多芯适配五大新特性。

1）动静统一自动并行：用户只需在单卡程序上进行少量的张量切分标记，飞桨就能将其自动转换为并行训练程序，大幅度降低了产业开发和训练的成本，使开发者能够更专注于模型和算法的创新。

2）大模型训推一体：同一套框架支持训练和推理，实现训练、推理代码复用和无缝衔接，为大模型的全流程提供了统一的开发体验和极致的训练效率，为产业提供了极致的开发体验。

3）科学计算高阶微分：科学计算提供了高阶自动微分、复数运算、傅里叶变换、编译优化、分布式训练等能力支撑，支持数学、力学、材料、气象、生物等领域科学探索，微分方程求解速度比 PyTorch 开启编译器优化后的2.6版本平均快115%。

4）神经网络编译器：采用与框架一体化的设计，能够支持生成式模型、科学计算模型等多种模型的高效训练与可变形状推理，在计算灵活性与高性能之间提供了良好的平衡点，显著降低了性能优化的成本。

5）异构多芯适配：构建了一套成熟且完善的多硬件统一适配方案，通过标准化接口屏蔽了不同芯片软件栈开发接口差异，实现可插拔架构，提供多种接入方式和基础设施，支撑硬件厂商合入4001个 PR，包括26584个 commits。

飞桨框架3.0将为开发者提供一个“动静统一、训推一体、自动并行、自动优化、广泛硬件适配”的深度学习框架，开发者可以像写单机代码一样写分布式代码，无需感知复杂的通信和调度逻辑，即可实现大模型的开发；可以像写数学公式一样用 Python 语言写神经网络，无需使用硬件开发语言编写复杂的算子内核代码，即可实现高效运行。目前3.0正式版本已面向开发者开放，并且兼容2.0版本的开发接口，非常欢迎广大开发者使用和反馈。

---------- END----------

推荐阅读

即刻体验！文心大模型X1现面向企业用户全面开放！

一篇论文，看见百度广告推荐系统在大模型时代的革新

前沿多模态模型开发与应用实战3：DeepSeek-VL2多模态理解大模型算法解析与功能抢先体验

秒哒首发即爆发！上线首日吸引2万用户，打造3万应用！

秒哒，全面开放！

4月2日，文心大模型X1正式上线百度智能云千帆大模型平台，企业用户和开发者登录即可调用API。

文心大模型X1具备更强的理解、规划、反思、进化能力，并支持多模态，是能力更全面的深度思考模型。模型兼备准确、创意和文采，在中文知识问答、文学创作、文稿写作、日常对话、逻辑推理、复杂计算及工具调用等方面表现尤为出色。

据权威测试，在多个公开数据集测评中，文心大模型X1在数学、代码、知识推理等能力上表现优异，超越升级后的DeepSeek-V3-0324。在数学场景中，GSM8K数据集测试后结果显示，文心X1得分95.6，DeepSeek-V3-0324得分93.6；代码生成层面，MBPP数据集测试后结果显示，文心X1得分83.3，DeepSeek-V3-0324得分81.2；在知识推理层面，C-Eval数据集测试后结果显示，文心X1得分88.6，DeepSeek-V3-0324得分85.1；在数学推理层面，Aime2024数据集测试后结果显示，文心X1得分78.6，DeepSeek-V3-0324得分57.1。

在模型服务方面，现可直接通过千帆ModelBuilder调用文心大模型X1 API服务，输入价格低至0.002元/千tokens，输出价格低至0.008元/千tokens，同时支持批量推理场景，满足更多元业务需求。

在模型开发方面，千帆ModelBuilder模型蒸馏支持文心大模型X1作为教师模型，一键实现从“思考模型”到“轻量模型”的知识蒸馏。

在应用开发方面，千帆AppBuilder支持用户基于文心大模型X1，快速搭建具有深思考能力的RAG、Agent、AI搜索、工作流，实现更充分的思考规划、更准确的工具调用、更全面的生成效果，助力企业级大模型应用在千行百业落地。

百度智能云千帆大模型平台始终致力于为用户提供全流程、一站式的AI服务，以开放性、易用性、低成本的平台理念，企业用户和开发者能够更高效地探索大模型应用，提升创新效率，加速各类AI应用从概念到落地的转化，为AI技术在更多领域的拓展与应用注入强大动力。

------END------

推荐阅读

一篇论文，看见百度广告推荐系统在大模型时代的革新

前沿多模态模型开发与应用实战3：DeepSeek-VL2多模态理解大模型算法解析与功能抢先体验

秒哒首发即爆发！上线首日吸引2万用户，打造3万应用！

秒哒，全面开放！

图灵数据洞察平台-TDF（Turing Data Finder）

我们见证了 DeepSeek R1，用强大的推理能力再次点燃 AI 智力增长的火箭。 在上个星期，OpenAI 给 GPT-4o 的一波图像生成更新又让全网陷入了梗图、甚至玩梗视频制造的火热氛围中。