4月2日，文心大模型X1正式上线百度智能云千帆大模型平台，企业用户和开发者登录即可调用API。 文心大模型X1具备更强的理解、规划、反思、进化能力，并支持多模态，是能力更全面的深度思考模型。模型兼备准

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

多模态理解大模型，是一类可以同时处理和理解多种数据形式（如图像、文本、视频等）的人工智能大模型，可以应用于图文理解、视觉问答、文档理解、场景描述等任务。本文将介绍目前热门的 DeepSeek-VL2多

3月24日，国内首个对话式应用开发平台百度秒哒全量上线，上线24小时就迅速吸引超2万用户体验，创建应用数量突破3万个，相当于每3秒就诞生1个应用！ 秒哒以 "无代码编程+多智能体协作+多工具调用" 的

导读 在数字化时代，企业对用户数据的挖掘和分析能力直接影响业务增长和竞争力。图灵数据洞察平台(TDF) 是一款面向企业的数据分析与用户增长平台，提供一站式的行为数据生产、用户行为分析、及广告效果评估等

3月16日，文心大模型4.5和文心大模型X1正式发布！ 目前，两款模型已在文心一言官网上线，免费向用户开放。_（https://yiyan.baidu.com/）_同时，文心大模型4.5已上线百度智能

01 AI 训练稳定性的演进历程 2012 年 ImageNet 竞赛中 AlexNet 的横空出世，开启了现代 AI 发展的新纪元。彼时我们不会想到，十年后支撑 AI 训练的 GPU 集群会从研究室

导读 语义嵌入是自然语言处理、信息检索、推荐系统等领域的核心技术，对于精准捕捉文本深层次语义信息至关重要。近年来，大语言模型（LLM）的兴起为语义嵌入技术开拓了新的方向。本文介绍了LLM在提升语义嵌入

导读 本文详细阐述了基于Flink构建的实时反作弊流式过滤系统，针对大流量场景下的复杂特征计算、高频策略热更新、模拟过滤验证及多场景数仓对接等核心挑战，提出来多项解决方案，实现了秒级特征计算的实时过滤

导读

随着AGI理论的不断突破，智能体已经成为LLM在企业落地的最重要的形式之一。一个完备的智能体必须能实现：感知、推理、计划、执行等一套完整的功能，从工程的角度来看workflow特别适合这种复杂任务的分析、拆解、重组、执行,  再结合CoT技术, 实现LLM和业务功能完美契合的智能体应用。本文尝试用成熟的图引擎技术驱动workflow探索更多样性的拓展agent能力的方法，以更好应对各类业务场景。

01 简介

1.1 什么是智能体

以大模型(LLM)为核心, 具备以下特性的智能化系统：

• 交互性: 通过文字，语音，图像等多种交互方式来理解用户的持续性需求  (感知)；

• 适应性: 感知环境的变化持续进化，以更好地完成任务和适应复杂环境      (记忆)；

• 自主性: 能够自主学习，主动思考和决策                                               (推理)；

1.2 业务形态、流程

一个智能体生态平台，用户可以在上面体验功能各异的智能体app，同时也能让用户将自己的优秀想法以极低的成本(通过快速组装已有的插件、workflow、知识库、记忆) 快速实现成新的agent。

系统特色：

• 流程编排能力：支持可视化的数据流加工，通过编辑各个处理节点将原始input加工成output；

• 功能复用能力：众多的agent库、插件库都可直接复用到自己的智能体里, 可插拔、替换；

• 低代码能力：无需大量写代码，直接通过拖拽元素就能拼装出想要的功能。

1.3 业务场景的需求难点

1.3.1 能自由组装流程实现人机无缝衔接、数据解耦

• 能将人的需求表达和agent思考结果的进行完美串联融合，发挥各自优点；

• 除context外更多样性的数据传递方式，更好满足workflow、cot等流程编排的场景；

• 细粒度控制数据传递、适配方式，满足特定场景的灵活性和性能的平衡需求。

1.3.2 能更精细规划路径、简化流程设计

• 支持多种路径控制能力，满足多样性的静态化任务编排；

• 支持在workflow内部动态编排新的子flow, 满足动态化的场景。

1.3.3 能对流程进行统一的控制、干预

• 流程运行过程中当出现超时、异常等非预期情况需要框架能提供快速干预、退出机制；

• 摆脱对executor(执行器的依赖)，更低成本支持大量功能异构的流程。

1.3.4 能进行简单的功能注入

• 支持在模型前后、工具调用前后等地方注入策略逻辑和观测代码，避免对大量节点进行浸入式改造；

• 支持流程编排时给节点初始化赋值，降低数据传递的成本；

• 支持任意节点信息的流式输出能力，满足长流程中阶段性结果的sse输出需求。

1.3.5 能支持缺少代码能力的使用场景

• 将用户生或者LLM产生的cot转化成具体流程配置；

• 将流程配置转换成可运行的代码。

1.4 为什么自研图引擎

1.4.1 常用智能体开发框架简介

• LangChain框架：一个开发智能体的框架，定义了prompts,  index, memory, agents, tools, outputParser等一系列功能抽象,通过chains将各个功能串联成应用。

• 开发模式：

• Chains:  规划静态任务,  很多抽象都实现了chains的接口，规划好路径就能让各功能有序执行

• AgentExecutor:  执行动态任务，某些场景无法预知执行路径，需要不同的输入走不同的分支，因此引入代理人(AgentExecutor), 通过多轮循环推理产生最终结果

• 总结：多轮学习和推理是自主ai系统的基本的能力, Chains不具备循环”能力,  AgentExecutor多轮调度是一个不透明度黑盒。

• LangGraph：基于LangChain基础上演化的框架，引入条件边，赋予用户对循环的控制能力。

• 开发模式：用透明化的有向状态图打破LangChain动态任务的循环黑盒 (AgentExecutor)

已有框架比较注重系统的自主性，对业务执行路径的编排能力较弱。

1.4.2 业务需求的挑战

• 强化的路径控制能力：既能满足llm的多轮循环特性， 又能结合cot模式的功能编排；

• 传统功能的结合能力：模型存在知识能力边界，业务需要结合之前传统功能来满足多样性、个性化的需求， 在数据的校验、传递、并发、同步，流程控制等这些贯穿整个业务随处可见的基建功能都需要支持。

这些都不是已有智能体开发框架本身所擅长的，从下层视角看需要提供一个更通用、更精细化控制能力的流程驱动框架增强以下特性来满足业务需求。

02 用seda图引擎驱动workflow的模式开发智能体

对于以上共性需求我们引入图引擎驱动workflow的开发模式：将任务拆解成独立的功能节点，不仅可以包含 LLM, prompts, memory, tools, 等智能体(ai)元素还融入了 分支、循环、条件、多路复用、数据传递等传统应用所擅长的路径编排、数据转发、超时控制、错误处理等方面的功能，为智能体应用提供一个更强大、稳定、便于解耦且可黏合性强的基座环境。

2.1 实现更灵活的流程拆分组装、数据解耦

2.1.1 流程拆分

元素：

算子:  若干个函数的集合，组成一个业务逻辑上可简单描述的功能模块；

边：  联接2个算子，具有方向性，代表执行顺序，起始节点作为上游算子，指向节点作为下游算子；

联接：

串联: 一个上游算子联接一个下游算子，上下游顺序执行；

并联: 一个上游算子联接多个下游算子，上下游顺序执行，下游算子之间并行执行；

join:   多个上游算子联接一个下游算子，上游之间并行执行，下游等待所有上游执行完后再执行，实现汇聚、归并。

flow:

将复杂业务功能分解成若干个易实现、解耦、可复用的算子，根据业务执行顺序用边将算子串联起来，形成工作流。

用户请求从起始算子流入，通过flow的算子进行加工，最终从结束算子输出，完成整个业务流程。同时支持 dag 和 dcg(有环图)。

2.1.2 分层组装

• 子图(sub-flow)：把一个flow也当成一个算子(sub-flow)，直接挂到另一flow上，当数据推动到这个算子的时候就会触发这个(sub-flow)的内部逻辑，实现flow级别的抽象和复用；

• 分层脉络地图：功能复杂导致算子数量过多时可以按不同粒度划分层级，把相同抽象粒度的算子放到同一个层级，不同层级的算子通过子图实现串联。通过点击进入子图内部浏览功能细节，通过收拢子图回到上层抽象，以此实现功能导航地图，既方便浏览又方便解耦拆分到多人协作开发。

2.1.3 数据解耦

context共享可以方便的在所有算子间传递数据，算子的插拔替换、顺序调整也无需考虑数据的匹配，但同时也带来了数据加工处理过程黑盒，以及为了尽量避免参数读、写范围放大而需要加强数据访问权限保护这2个问题。

为此我们提供了额外的方式，满足不同场景的需求。

• 链式推导 -- 更细粒度数据解耦

描述：上游output和下游input类型一致，就能串联并传递数据。

优势：output/intput是数据传播的契约约束，数据加工流程清晰。相同intput, output定义的算子之间能串联且插拔替换；相互之间不匹配的算子能通过定义中间类型的"桥接"算子来实现串联。

短板：需要用户手工串联算子，而且算子间容易产生串联类型不匹配以及并发问题也需要用户自己解决。

• 自动推导 -- 自动优化使用和运行效率

描述：算子数量越多人工编排效率越低，在链式推导的方式上引入Referential Transparency, Single Assignment等规则约束来实现调用链自动推导。

优势：可以帮助用户自动管理大量算子的联接关系， 省时省力的同时还能在保证数据并发安全性的同时实现最大程度的并行化。

短板：关注的焦点从过程转移到数据，用户需要对流程做设计、优化时需要从数据入手做逆向推导流程(数据是在流程中慢慢产生和迭代的)，违背了用户的使用习惯。而且对现有系统来说这种对数据读写的严格拆分、解耦往往需要全部推翻重来。

2.1.4 拷贝与引用

除了以上的数据传递方式外在不同的需求场景下我们同时还需要思考是传递数据的副本拷贝还是传递数据引用(本身)的问题

• context共享：出于性能考虑，基本都是采用传递引用的方式；

• 链式推导：可以手工指定，默认通过简单的判断下游算子的数量来自动决定：下游算子个数等于1:传引用，大于1: 第一个算子传引用,剩余算子传副本，尽可能在局部范围内降低用户心智负担；

• 自动推导：在Referential Transparency, Single Assignment双重数据访问规则保护下无需用户考虑并发安全性问题；

• 自定义：用户可以在联接2个算子之间的边(edge)上显示指定是副本拷贝还是传递数据引用(本身)来获取更大的灵活度。

2.1.5 类型适配

同一类功往往有多种实现，各自针对不同的使用场景有自己的优化，这些算子的input/output 往往基本结构一致，但又稍稍有一些小差异，为了更方便让这些算子能快速插拔，提高功能复用度，降低复用成本，我们提供了一系列自动适配机制。

• 类型自动放大：内置多种数据类型及其变体自动转换逻辑：

A  <--->  *A,  interface{}

A  -> []A, []*A, []interface{}

• 特型自动匹配：上游算子的output类型是被下游算子input类型内部组合的子类型，相互能串联，并完成自动赋值。

• 自定义适配器：一个单独的适配器完成2个功能类同，但是intput/output参数形式差异较大的算子之间串联，适配器的input是上游算子的output, 其output是下游算子的input。

• 为什么不直接用过度算子实现：避免大量转换算子干扰业务流程；

• 为什么不把适配逻辑放算子内：避免侵入式改造和过度引用导致耦合。

2.2 实现精细化的路径规划

2.2.1 多功能边

• if：                    条件边 (单分支)；

• switch:               多条件边 (多分支)；

• multiplex:           多路复用边 (同时监听多个资源、信号)；

• optional edges:  可选边 (按需放弃对非强依赖上游的等待)；

• while:                 循环边 (条件和循环次数组合实现dcg)；

2.2.2 动态规划

编译时构建一个基础的大致性的功能脉络(上层基础逻辑定义)，具体实现逻辑由执行期根据代码运行情况及LLM返回结果动态规划做逻辑的实时增删、拼接、构建。

2.3 实现统一的驱动控制和干预

2.3.1 流程驱动

• executor 执行器：

• 存算分离设计：执行器读取flow信息并驱动执行，提供路径控制、资源调配，flow仅存储数据；

• 一次解析多次执行：对flow进行一次解析后可以得到该flow的一个excutor, 后续相同的flow都可以通过该executor进行执行；

• 适用场景:系统里flow异构类型有限, 都需要大量重复的被执行, 能节省每次构建重复flow的开销。

• flow自驱动：

• 无需解析，直接执行：flow被构建出来后，利用flow自驱动的功能直接运行, 无需构建执行器；

• 适用场景：系统里大量异构flow，或者会动态产生出新构型的flow，能节省复用度低的执行器构建的开销。

2.3.2 错误处理

• 退出流程

当算子返回值 <0 时表示发生错误，默认直接跳到最后一个算子执行(让系统能有一个给用户回包、打日志的机会) 后并退出当前流程，快速终止无效的执行逻辑，迅速释放资源。

• 逐层退出

当有多层(子图)时候，每一层有算子返回值 <0都会直接跳转到本层子图的最后一个算子执行，随即返回回上一层。用户可以按需给上层指定返回值，当给上层的返回值 >=0时候上游正常往后面算子执行，否则继续跳到本层的最后一个算子执行，以此类推直到整个flow结束。

2.3.3 超时控制

• 图超时

我们可以给整个flow指定一个执行的超时时间，触发后直接跳入到本层最后一个算子(让系统能有一个给用户回包、打日志的机会)，这样快速终止无效的执行逻辑，迅速释放资源。

• 算子超时

一般没有特殊需求我们建议根据业务接口要求通过flow控制整体超时即可，由系统自行判断可以尽量避免一些超时设置不合理的问题，同时我们也保留单独指定算子超时的能力，算子发生超时但flow整体没有超时时会跳过超时算子继续往下执行；，尽可能保持必要的灵活性。

2.4 实现通用注入

2.4.1 事件监听

• 监听通用事件

提供以aop接口的形式统一支持算子 on_enter, on_leave, on_timeout, on_error等关键事件的钩子机制，以全局函数或者算子成员函数的形式进行改写，以便用户能统一加入自定义的日志记录、监控、通知、错误处理等应对机制。

• 监听自定义事件

除了上面的通用事件，我们还提供统一的机制，提供用户在算子内部任意地方加入自定义事件的能力，帮用户简便地完成应用层框架监听机制的建设需求。

2.4.2 附加属性

除了context共享，链式推导的传递机制外我们还提供了额外第三种"附加属性"的方式来给算子传递数据，方便用户在编辑算子时就能给算子指定一些固定属性值，算子运行时能快速被读取，降低初始化成本。

2.4.3 流式输出

放置一个内置的流式输出的算子到workflow里，通过向这个算子的channel里写入数据即可实现在任意算子里流式输出信息来满足sse需求，同时将流式输出算子和最后一个算子相连，即可实现优雅退出。

2.5 实现低代码

• 提供可视化编辑器，让用户拖拽设计流程并产生对应的配置文件；

• 后端提供算子仓库作为用户功能实现的基础素材；

• 图引擎的generate负责将配置翻译成流程代码， builder动态构建流程，driver负责驱动流程运行并返回结果。

2.6 seda相较其他图引擎实现的优势

2.6.1 图引擎实现方案一：多线程并发(thread-base-on-request)

本质：线程数和请求数N:M的模型，基于请求数量规划线程的设计， 由操作系统保证线程调度、资源分配的均衡。

优势：实现简单、数据局部性好，负载在系统处理能力阈值内性能及佳，适用于对耗时要求苛刻的场景。

短板：

• 流程黑盒：线程粒度太粗(请求粒度)，不利于功能迭代、优化。

• 扩展性差：请求数受系统线程数制约, 负载超出系统处理能力阈值会使系统陷入“调度内耗” (上下文切换，锁竞争)，处理能力指数级下降。

2.6.2 图引擎实现方案二：事件驱动并发(thread-base-on-resource)

本质：资源数和线程数N:M的模型， scheduler根据系统资源初始化若干线程，将请求拆解成由若干个non-blocking节点组成的有限状态机(FSM)，节点执行后将状态回传给scheduler, 由其根据当时资源使用情况分配下一个节点的处理线程，直到整个有限状态机结束。

优势：

• 流程可视：通过有线状态机实现各个功能节点之间互相解耦；

• 扩展性佳：线程数不受请求数影响，能始终控制在系统资源可高效运行的阈值范围内；

• 吞吐量大：事件驱动极大程度避免了多线程之间的"资源内耗"，能有效提升系统并发和吞图。

短板：

• 时延增大：一次请求处理过程跨多个线程执行增加了数据传递消耗的同时也降低了硬件缓存命中率导致请求延迟增大；

• 实现困难：中心化的scheduler调度器既要驱动业务状态流转又要管理资源调度往往会顾此失彼。

2.6.3 图引擎实现方案三：基于seda的图引擎驱动(thread-base-on-stage)

seda：staged event driven architecture

本质：将上面中心化的scheduler模块给拆分成多个子部件实现。

• 用多个事件队列将每个状态节点(stage)， 组成一张数据流动网络 (Directed Graph)；

• 每个stage都由事件队列(接收数据)、控制器(分配资源，驱动stage流转)、线程池(调节线程数)、事件处理器(业务处理handler)组成；

优势：

• 资源按流程stage拆分,粒度适当 （按request粒度过小，容易陷入内耗；按resource粒度过大，容易浪费）；

• 去除中心化模块，通过对事件队列的流速控制使得每个stage可以单独进行负载调节。

短板：

相比运行状态良好情况下的单线程处理一个请求的设计, 时延上会有增大 。

03 通用图引擎在智能体场景的实际应用

3.1 功能场景应用

3.1.1 根据大模型COT结果动态生成子workflow

• query：请预测下明年下周的天气情况

• 大模型将问题拆解成具备先后依赖关系的多个小步骤：

1. 计算下一周对应的时间范围

2. 查询本周天气情况

3. 查询历史上前n年对应时间范围的的天气情况，

4. 根据历史查询结合当前情况推测明年对应的时间范围的天气情况(结果保存到短期记忆)

5. 如样本范围太小或结果单一则重复前面过程3-4，直到给出预测结果的具体概率分布

• 大模型根据当前执行到的具体步骤将工作内容动态分解到子图并执行。

3.1.2 复杂场景的功能拆分解耦和精细化路径控制能力

• 用"多路复用"同时监听多值，支持任意数量路径分发，将 "路由和子功能调用" 算子进行拆分解耦；

• 用"可选边"将多处可能会触发到的公共逻辑"润色模型"模块拆分成独立算子；

• 用过"融合边"将各种不同类型的边融合汇聚到一个算子, 便于整体控制流程结束逻辑；

• 通过以上多种精细化路径控制功能，减少大量胶水代码的同时方便对流程图做快速修改，让用户专注于业务逻辑自身。

3.1.3 通用注入和循环增强

• 由侵入式改造转变成通用事件注入来统一控制算子内部的共性行为；

• 个性化功能增强也可以通过非侵入式方式注入算子内部；

• 在之前纯代码逻辑控制循环结束条件的同时增加了框架保护机制，避免响应不及时和资源长时间侵占。

3.2 小结

通过图引擎驱动workflow的开发模式提供了一个强大的基座，用户可以快速在其上通过插拔替换、顺序调整、串联汇聚、编辑出任意自己想要的流程，其强大的解耦和精细化路径控制能力从根本上解决传统ai开发模式带来的黑盒问题和相关不确定性问题，同时还能获得极佳的运行时效率(天然并发)；其自带的低代码、分层导航等特性减少了大量胶水代码，还有助于多人同时入场并行开发，降低开发、维护成本。

目前系统已经接入80w开发者，15w合作企业，超过10w个智能体。

————END————

推荐阅读

直播间互动框架性能优化与稳定性实践

百度网盘防雪崩架构实践

如何在百度百舸部署满血版DeepSeek-V3、DeepSeek-R1模型

首日调用客户破1.5万！DeepSeek-V3/R1上线背后的超低推理成本技术揭秘

唤醒 AI 算力，专有云 ABC Stack 面向企业级智算平台的 GPU 提效实践

导读

直播间互动体验框架技术实践，揭秘性能与稳定性优化之道，快来探索吧！在百度直播间歌会红包等活动中，我们创新性地将红包互动与高质内容深度融合，通过技术架构升级与系统性优化，打造了"音乐+红包"（边听歌边抢红包）的沉浸式体验。本次实践显著提升了直播间的并发承载能力、实时互动响应速度和用户参与满意度，同时沉淀出可复用的技术方案，为后续大型直播活动奠定坚实基础。

01 百度直播间歌会红包运营活动介绍

为提升直播内容质量和用户粘性，需注入多元化内容，增强直播间多样性和观赏性。同时，通过活动裂变扩大影响力，吸引特定用户群体，保持用户新鲜感和期待感，为平台长期发展奠定基础。

为落实直播歌会目标要求，需加快直播间互动体验框架建设，探索新型混合模式和沉淀通用能力，着力适配重点业务场景，打造"音乐+红包"的互动体验，提升直播间品质：

一是通用基础。主要包括组件复用、大图压缩等减少产物体积，页面异常、性能、白屏监控，BFF服务编排扩缩、稳定性监控等。

二是访问保障。主要包括页面多域名容灾、开启强缓存；字体、图片、CSS、JS等静态文件单独CDN强缓存域名，开启多级缓存等。

三是红包性能。主要包括页面预静态化、数据预加载、文档预取、资源预取、视图预渲染、动效降级等。

四是开发体验。主要基于直播前端一站式，建强队伍，确保项目开发流程规范统一，搭建增质增效的研发环境等。

02 体积

2.1 页面划分

在大型产品需求中，通过合理的页面划分策略，实现高效开发与维护。面对产品需求中罗列的多样玩法功能和19种以上的红包状态，研发团队面临的首要挑战是如何将这些功能合理的拆解成多个页面承载。合理的页面划分不仅关乎用户体验的流畅性，更是减小产物体积、提升跨页面资源缓存利用率的关键。通过深入分析业务逻辑与用户行为路径，我们精心设计了页面边界，确保每个页面和组件都承载着唯一元素，同时避免了冗余代码的产生。此外，这一策略还极大地促进了开发团队的协作效率，明确的页面划分减少了代码冲突的可能性，使得团队成员可以高效并行集成，从而加速了开发迭代周期。在直播间端能力的规范化构建上，同样遵循了通用化这一原则。

在页面划分时，我们非常注重跨页面资源的最优利用，通过策略性地缓存HTML、CSS和JavaScript等资源，确保一旦用户在任意时刻首次触发了红包弹出事件，这些资源即可被全面缓存，使用户在后续的页面切换过程中无需再次加载这些核心资源。

通过一系列设计举措，划分多页应用（MPA）10+个、单页应用（SPA）20+个、红包组件状态（Component）19+个、规范化直播间端能力（Scheme）30+个，每一项都经过精心设计，共同作用于提升应用的整体性能，为用户带来更加轻盈、快速且协同良好的使用体验。

2.2 性能优化

在直播歌会抢红包运营活动中，Web页占据了80%的比重，对于每一个依赖较多网络资源的玩法页面，在直播间中实现即时加载和快速展现确实面临较大挑战，尤其是在高并发、低延迟的场景下。

△页面展现过程

为了有效应对这些挑战，通过深入分析页面展现过程中的各个环节，直播间互动框架提炼出七种通用的优化方案。旨在提升用户交互体验、增强系统的整体性能。并确保直播间玩法在高并发场景下依然能够流畅运行。这些优化方案覆盖了从页面加载、资源获取到实时交互的各个方面，形成了一个全方位的性能提升样板，具体方案如下：

2.3 页面预静态化（SSG）

在直播歌会抢红包的场景中，所有不变的内容（如活动规则、活动主页框架等）使用SSG能够显著提高页面通用静态内容的加载速度，同时通过集成CSR可以实现部分动态内容的及时更新。

△框架原生SSG Webpack插件

△图1：活动规则 △图2：攒百元半屏页 △图3：支线攒碎片

2.4 页面静态化（SSR)

在直播歌会抢红包的场景中，节目单页作为用户获取歌曲节目信息的第一入口，其快速加载至关重要。SSR提供快速的节目单页初始加载，后续通过客户端的JavaScript动态增强功能（如进度提醒、节目回放等）获得更丰富的交互体验。

2.5 增量静态渲染（ISR）

在直播歌会抢红包的场景中，对于实时性要求极高的红包抢夺场景，ISR的动态更新和实时交互特性为活动的各个环节提供了实时回显的用户体验：

• 首先，在全屏红包弹窗页（如初始红包、任务红包和裂变红包）中，ISR使得页面无需刷新即可实时更新用户的红包状态。当用户参与活动或完成任务时，ISR的快速响应确保用户能即时获得任务状态和奖励领取情况，增强了用户的参与感与互动性。

• 对于实时轮次切换功能，ISR保障用户迅速在游戏阶段间切换，提升了同页面不同状态的连续性。当活动结束时，系统能够快速通知用户并更新活动状态为下线，避免误导用户继续参与。

• 在内容分享与社交互动方面，ISR处理高效的页面加载与实时显示，如微信邀请和海报分享，保证用户能快速刷新助力进度。在邀请分享页，主态用户能立即看到受邀好友的参与情况和贡献，进一步增强社交互动体验。

2.6 数据预取（Prefetch Data）

在直播歌会抢红包的场景中，通过NA与H5之间的有效数据预取和缓存衔接，实现了端数据的复用，有效减少与服务器的交互频率，消除了数据加载的等待时间，确保了在直播环境中用户能够高效参与活动：

• 预取皮肤元素配置，进入直播间后，NA会预取皮肤元素配置，预加载与活动相关的皮肤素材，并将这些信息进行缓存，包括页面主题色和红包动画等。同时，前端JavaScript能够在页面弹出时，通过端能力或全局变量直接获取相关数据，用户不需要等待皮肤配置加载，界面视觉能够立即呈现，从而实现在操作上的流畅体验。

• 攒百元红包的进度更新，在活动进行中，用户需要实时查看攒百元红包的进度，通过数据预取的方式，能够迅速更新至用户界面。在启动WebView的同时，NA实现数据的并行获取。这意味着在用户点击挂件后，相关的数据请求会立即开始，前端JavaScript则能够在执行时通过端能力直接获取这些已经预取的数据，降低了数据延迟加载等待时间，增强了用户参与活动的效率。

2.7 文档预取(Prefetch HTML)

在互动性较强的直播歌会抢红包的场景中，用户不仅可以观看演出，还能参与抢红包活动。为提供最佳的用户体验，确保用户在首次点击不同功能时能够快速上屏相关内容，采用文档预取能力在后台主动下载歌会相关HTML内容，如攒百元半屏页、节目单页等。当用户最终点击某个链接时，直接从内存中读取HTML文档内容，无需网络请求，从而显著提高页面加载速度，确保用户在直播间里的互动预期。

通过数据结果来看，文档预取的效果非常显著。在优化了节目单页的性能后，Android用户的首屏加载时间从3秒级减少到500毫秒级，iOS用户的首屏加载时间从2.5秒级减少到500毫秒级。这样的性能提升显然改善了用户体验，使得用户能够快速获取所需信息，进而积极参与到活动中，营造出活跃的直播间氛围。

△Prefetch SSR/CSR HTML

2.8 资源预取（Prefetch Resource）

在直播歌会的场景中，用户参与抢红包是一个关键的互动环节。在此过程中，确保红包弹出的多层动画和红包图能够迅速、完整地展示对于增强用户体验至关重要。为此，资源预取在这一场景中得到了有效应用，在正式直播活动开始前期，后台服务主动下载、缓存、更新关键资源，包括红包的动画文件和高质量的红包皮图像。以确保当红包正式弹出时，最新的文件已被准备妥当，用户能够立即看到完整的红包图和流畅的动画效果，避免了图片逐块加载造成的卡顿和不完整展示。

通过数据结果来看，资源预取的效果非常显著。Android用户资源加载耗时提升幅度约46.7%，iOS用户资源加载耗时提升幅度达86.1%，大幅提升了整体互动体验，使用户在关键时刻享受到快速且流畅的操作体验。

为了确保资源预取的有效性，需要注意以下几点：

• 预取的资源应以用户行为的合理预测为基础，避免过度预取，从而造成带宽浪费。

• 采用分模块的离线包设计，将每个模块的资源单独管理。

• 在活动结束后，应及时下线不再需要的资源，释放带宽和用户手机空间。

2.9 视图预渲染（Prerender WebView）

在直播歌会的场景中，观众们期待快速响应的抢红包互动体验，此时视图预渲染能力发挥了重要作用。当用户进入直播间后，提前在后台加载并渲染抢红包页面内容，并注册页面可见性监听器。即使用户专注于观看直播，红包页面也已准备妥当。用户点击按钮，抢红包页面便迅速显示，无需等待加载和渲染时间，同时触发监听器实时更新数据。这样的即时反馈使得用户几乎可以瞬间查看抢红包的结果，极大提升了参与的积极性和体验感，进一步增强了直播的互动乐趣。

在预渲染过程中，仅对用户频繁访问的页面进行预渲染，避免资源浪费，确保当前视图性能不受影响。由于预渲染占用内存资源，因此需要控制WebView的数量，防止内存泄漏。在实施时应关注内存管理、时机选择、兼容性和安全性，以灵活适应具体应用场景。

03 稳定性

3.1 弹窗稳定性

保障直播间红包弹层的进退场稳定性，防止透明弹层卡住以致用户无法互动，是一项关键挑战。在直播间中，红包弹层通过覆盖全屏透明WebView实现，且与动画控制密切相关，用户在拆红包动画播放过程中无法进行任何交互，关闭按钮在动画结束后才会显示。这要求我们确保红包动画的持续时间和效果稳定，以便在合适的时机正确显示关闭按钮。为确保红包弹窗正常退出，尤其是在H5页面渲染异常或网络不稳定的情况下，用户也能得到一个状态友好的反馈。保障直播间抢红包互动的稳定性，我们设计了“一次握手”和“双重兜底”策略：

• 一次握手，即Web内容健康检查：

• JavaScript通过WebContentLoaded端能力，表示H5成功接管用户交互，并通知Native端取消WebView的超时销毁策略，以确保全屏红包弹窗能够稳定展示。

• 如果H5接管未在规定时间内完成，Native端将销毁上层全屏透明的WebView。这一措施确保用户不会因弹窗问题而中断观看体验，从而能够持续与直播间进行交互。

• 双重兜底，即NA兜底页和H5兜底页：

• NA兜底页，当HTML入口文件请求异常时，展示Native兜底页面，确保用户有可见的替代内容。

• H5兜底页，在JS业务组件发生异常（例如接口请求异常、端能力调用失败、组件内部异常、重要资源缺失）时，展示H5兜底内容，为用户提供实质反馈。

   

△图1：NA兜底页 △图2：H5__兜底页 △图3：请求______兜底

3.2 动效降级

炫酷的动效的表现直接影响用户的体验，在直播歌会场景中，红包动效由复杂的元素组成，包括Lottie动画、AFX透明视频和CSS动画。炫酷的动效虽然可以增强视觉吸引力，但在低端手机上可能导致卡顿。为确保所有用户可以顺畅参与活动，我们实施了分级动效降级策略：

• 高性能设备（High）：在高性能设备上，展示完整的动画和丰富的动态效果，享受到丰富的视觉效果。

• 低性能设备（Low）：对于低端手机，复杂的动效将被简化为静态图像或低复杂度的CSS动画。例如，红包拆开时只展示基本的静态图形，替代激烈的动态效果，确保用户能够正常阅读红包金额，而不至于因动效卡顿而影响体验。

分级动效降级策略能够根据当前手机的实时性能情况，在用户点击拆红包时动态调整展示的动效级别，确保以最佳效果参与活。这种适应性有效地解决了不同设备用户在参与红包活动时可能遇到的性能问题，从而提升整体用户体验的品质。

3.3 组件响应

随着用户体验的不断优化，直播歌会抢红包活动中页面组件的运行环境日益复杂。特别是在复杂组件的开发中，组件开发者必须意识到各项适配工作的必要性，以确保用户体验与开发体验之间的平衡。为了有效满足用户需求并提升开发效率，我们需要综合考虑多个环境及其不同状态。至此，在一个组件的设计和实现过程中，需要针对以下五种状态进行响应和适配：

1. SSG环境（编译线环境）：组件在编译过程中，通过Node.js将公共的信息（如活动规则）提前生成静态内容，以提供快速响应时间。

2. SSR环境（服务端环境）：组件服务器集群上，通过Node.js根据用户请求动态生成相应的内容（如歌会节目单），减去客户端JavaScript加载执行时间，加快页面首屏展示速度。

3. ISR环境（客户端环境）：组件在浏览器中，通过JavaScript进行动态渲染、响应用户点击、滑动等操作，通过异步接口获取最新数据（如红包金额、助力信息）并即时更新界面，保证用户体验的实时性和互动性。

4. 页面可见（Visibility）：组件在浏览器中，通过JavaScript控制组件的渲染时机，仅在内容需要展示时才进行渲染（如播放红包动画），减少不必要的DOM操作，提升性能并降低资源消耗。

5. 动效级别（High / Low）：组件在浏览器中，通过Native端能力获取用户设备的性能，动态调整组件中的动效，在高性能设备上展示更炫酷的动效，在低性能设备上则展示更简单的动效，确保流畅体验。

04 总结

• 沉淀直播框架能力：通过优化直播间视图容器组件，并形成标准化的组合能力样板，拉升直播间活动页面的性能水准，这些方案具备良好复用性，适用于未来各种直播活动。

• 系统稳定性保障：组件复用、性能监控和容错机制，减少重复开发和维护成本，进行压力测试与优化，提升系统可靠性和用户体验，确保高峰流量下的稳定性。

• 强化互动性体验：在直播歌会中建立综合能力框架，特别是在抢红包等互动性强的活动中，确保用户在享受歌会演出的同时体验流畅的互动，鼓励积极参与

————END————

推荐阅读

百度网盘防雪崩架构实践

如何在百度百舸部署满血版DeepSeek-V3、DeepSeek-R1模型

首日调用客户破1.5万！DeepSeek-V3/R1上线背后的超低推理成本技术揭秘

唤醒 AI 算力，专有云 ABC Stack 面向企业级智算平台的 GPU 提效实践

百度APP iOS端磁盘优化实践（上）

导读 大模型在研发效能领域代码生成方面发挥了越来越大的作用 而大模型的预训练依赖大量的精标代码，这些精标数据必须是比较好的工程实践代码 这些比较好的工程实践代码，需要大量的技术沉淀，包括工程架构，代码

百度百舸·AI异构计算平台已支持快速部署DeepSeek-V3、DeepSeek-R1及其蒸馏的Llama、Qwen等小规模dense模型。您可以登录百度百舸平台快速部署DeepSeek系列模型体验模型效果。

01 开通轻量计算实例

开通一台H20（ebc.lgn7t.c208m2048.8h20.4d）规格的计算实例并添加到百度百舸·AI异构计算平台。

02 部署vLLM

在百度百舸平台的左侧导航中选择「工具市场」页面，部署工具vLLM。

03 模型推理

vLLM部署成功，登录实例下载模型并启动vLLM服务，安装WebUl客户端。

发送请求开始对话。

04 各系列模型的推荐配置清单

在完成满血版DeepSeek模型的快速部署后，百度百舸·AI异构计算平台还能为这些在线服务提供全生命周期管理、自研框架推理加速、推理资源碎片整理等能力。在保障服务稳定性的同时，有效降低推理成本并提升推理性能。

访问百度百舸页面cloud.baidu.com/product/aih…

————END————

推荐阅读

首日调用客户破1.5万！DeepSeek-V3/R1上线背后的超低推理成本技术揭秘

唤醒 AI 算力，专有云 ABC Stack 面向企业级智算平台的 GPU 提效实践

百度APP iOS端磁盘优化实践（上）

对话AI原生｜比帮你写代码更爽的是：让Agent来打工

0 Token 间间隔 100% GPU 利用率，百度百舸 AIAK 大模型推理引擎极限优化 TPS

2月3日，百度智能云千帆大模型平台正式上线了DeepSeek-R1与DeepSeek-V3模型，模型上线首日，已有超1.5万家客户通过千帆平台进行模型调用。百度智能云针对此次模型上线提供了行业领先的超

从「建好」到「用好」，企业级智算平台借助专有云 ABC Stack 的 GPU 提效服务，应对大模型业务挑战，唤醒 AI 算力，加速 AI 原生业务的落地。

01 难以一步到位的GPU效能

当企业的私有化智算平台项目上线一段时间后，用户普遍会反馈 GPU 效能相关的问题：

• 将全部资源分配给各个业务部门后，集群全部 GPU 资源的平均利用率在 30% 左右。这个指标处于什么水平，是否充分发挥 GPU 效能？

• 大模型训练的时候，我们会请技术专家排查 GPU 集群故障问题，有时居然要 2~3 个小时才能搞定，这个时间这么长，还能缩短吗？

• 新平台按照最高的硬件进行配置，但是常有业务线反馈，相比过去的老集群，智算平台上的任务速度并没有明显提升，这是为什么呢？

那么，企业遇上这些问题的原因是什么呢， GPU 效能可以一步到位吗？

先说结论。根据对不同的企业级智算平台类项目实践的总结：在平台落地后就处于 GPU 最佳效能的状态，这是几乎不可能的。

这些问题的出现和解决，正好体现了企业级智算平台和客户大模型业务落地磨合的过程。

这些问题的原因，有一部分来自于智算平台从无到有，再到大规模 AI 业务落地过程中，智算平台管理部门在不同阶段，关注的目标和业务运行环境的变化所致：

• 在 POC 阶段，通常是用若干个典型任务做功能、性能和稳定性测试。这些测试可以提前规划，可控性更大。整个过程关注的是平台自身能力的评估。

• 在大规模生产落地阶段平台开始承载所有部门的业务，需要考量的维度更加复杂，比如资源如何分配满足不同业务需要，平台如何正确使用确保业务能够高效运行等。

另外一部分原因，可能占更大比例，则是因为企业级客户，在过去已经习惯「小模型」和「老平台」后，面对「新平台」运行「大模型」中，需要有一段学习和适应的时间。

02 从资源管理到任务设置，唤醒AI算力

基于百度在大规模集群的技术积累和工程实践，在向企业交付智算平台后，专有云 ABC Stack 还为客户提供了一套面向整体 GPU 算力平均利用率、训推任务加速和稳定性等场景的 GPU 提效服务。

2.1 调整资源分配策略，提升GPU平均利用率

每个业务部门都期望能够获得/储备更多的 GPU 资源加速自己的 AI 任务速度，也可以免去申请更多资源的时间。不过，智算平台管理部门的目标稍有不同，会更多聚焦于在全局资源有限的情况下，能够实时按需分配资源，覆盖全部业务，使得资源利用效率最大化。

为了在「各个部门的业务效率」和「集团整体资源利用率」之间达到平衡，智算平台管理部门需要深入分析不同部门的业务模型，统计过往的任务类型和 GPU 资源使用量等情况，以便找到合适的资源分配策略。

比如，将过去统一把全部资源分发给业务部门的模式，变成把其中一部分资源作为保底资源分发给业务部门，剩余资源作为所有部门的共享按需调度的模式。其中，本周期内各个部门的保底资源额度，可以按照「上一个周期的统计数据」进行预测，适当进行缩减或者扩大。当通过监控数据发现资源总量不足时，及时进行扩容。

2.1.1 实践

传统车企 A 的自动驾驶平台，将智算平台的全部 GPU 资源固定划分给车辆视觉、雷达感知、数据处理、BEV 等 9 类业务。全部业务上线运行 2 个月后，整体 GPU 平均利用率在 30% 附近波动。

为探索 GPU 利用率是否有提升空间，车企 A 联合专有云 ABC Stack 共同对各个业务在过去 2 个月的使用情况进行了详尽的调研，发现全部的节点中：

• 20% 节点的 GPU 利用率长期不足 1%，这说明这些 GPU 资源几乎被浪费了；

• 20% 节点的 GPU 利用率较高，且多次超过 80%。这说明在未来这些资源有一定的超负荷风险；

• 另有 30% 的节点的 GPU 利用率大幅波动。这说明这些 GPU 存在一定的弹性调度空间。

因此，智算平台管理部门将预设的「整体资源按业务部门固定分配」管理方式，调整为「整体资源按调度方式灵活分配：保底 + 共享」的管理方式。

针对各个业务设置保底 GPU 资源，然后将未划分的 GPU 算力纳入集团公共资源池中，供各个业务方按需调用。同时，为了能够更好地管理资源，适应业务变化，车企 A 成立了 GPU 资源管理专委会，每两周对资源使用情况进行汇总分析，动态调整保底 GPU 资源，监控整体 GPU 资源水位。

通过以上资源管理措施的调整，车企 A 的 GPU  整体平均利用率从 30% 提升到了 45%。

2.2 系统性建设容错&稳定性能力，提升GPU有效训练时长

在小规模 GPU 场景下，通常只需要关注硬件异常引发的任务中断，快速替换故障节点并重新拉起训练任务进行故障恢复，就能解决大部分的问题。在千卡的大模型场景中，有很多问题并不会直接反映出硬件异常，例如训练进程 hang 死、训练降速、loss 跑飞（loss 值为 NaN/Inf）等等，这类问题可能跟用户代码、训练框架、硬件故障、操作系统、网络、存储都有关系。

此时，仅仅依赖专家经验人工处理故障，时长和结果都将是一件不可控的事情。

**我们需要更系统的方法，来实现感知异常、诊断定位及故障恢复。通过对训练进程、节点状态、网络流量和计算负载等多维度数据的监控与分析，快速识别异常行为，然后进行自动恢复，最终生成详细的故障报告，**缩短「感知–定位–重启–恢复」整个流程时间，提升有效训练时长。

2.2.1 实践

互联网企业 Z 经历了从小模型升级到大模型业务的转变。在小模型场景已经积累了足够的专家经验处理各类故障问题。在切换至大模型场景后，没有第一时间进行平台稳定性的建设，在故障感知、定位和恢复中投入了大量的人力成本，造成了资源的严重浪费。

借助百度百舸平台的稳定性&容错能力， 互联网企业 Z 在大模型训练任务中实现了显性故障和隐形故障的及时感知、精准定位、故障隔离和自动恢复，平均故障恢复时间从 3 小时缩短到 20 分钟，任务有效训练时长大幅提升，确保了大规模训练任务的持续稳定运行。

2.3 正确配置系统参数，释放GPU性能加速训练任务

大模型训练任务的效率，不仅仅和集群中 GPU 的性能和数量相关，还需要将计算、网络、存储各类资源进行合理配置，使得他们能够将任务各个环节进行无缝衔接，充分发挥整个平台的能力。

一个完整的业务流程，从数据采集开始，再到将预处理好的数据送入 GPU 进行训练，经过多轮迭代后，将最终结果写入存储完成训练。整个业务流程步骤非常多，每个环节的提速都能缩短大模型训练任务的时间。

尤其各类面向大规模 GPU 集群的全新高性能组件（并行文件存储 PFS、RDMA、模型训推加速库等）的引入，对于习惯了小模型业务场景，刚接触大模型和 GPU 集群的企业用户来说，如何才能用好这些能力加速模型任务呢？

为了全面地提升任务运行效率，需要对大模型训练过程中的各个环节进行梳理，给出理想的系统配置和关键指标，然后与智算平台的硬件配置和期望指标对比，以便找到潜在的优化点。

2.3.1 实践 1

传统能源企业 H 使用并行文件存储 PFS 提速从对象存储 BOS 到 GPU 的数据加载流程。运行一段时间后，业务部门发现模型训练速度虽有提升，但似乎离预期还有不小距离。

专有云 ABC Stack 对客户的整个数据流转过程和相应配置参数进行了梳理和分析，发现客户将 PFS 的工作模式设置为「仅加载元数据」，即仅将对象存储 BOS 的元数据进行了加速，导致在任务中未能充分发挥 PFS 的性能。

传统能源企业 H 的业务团队在将 PFS 的工作模式从「仅加载元数据」修改为「加载完整数据」后，任务训练速度提升了近 40 倍。

2.3.2 实践 2

互金企业 Y 将多机多卡的 AI 模型训练任务部署至拥有 RDMA 网卡的新 GPU 集群进行训练。但经过一段时间，发现新集群的训练速度，与未配置 RDMA 的老平台相比，并没有预期成比例提升。

专有云 ABC Stack 与客户深入沟通后发现，性能未达预期的原因在于 RDMA 未被正确配置。互金企业 Y 此前主要运行小模型训练任务，并不需要使用 RDMA。所以在大规模 GPU 集群的使用过程中，直接将老平台的使用经验复制过来，没有将 NCCL 中 RDMA 相关的环境变量配置到容器中。

互金企业 Y 在使能了 RDMA 网卡节点后，数据加载性能和 GPU 多卡训练性能明显提升，任务训练效率对比提高约 2 倍。

2.3.3 实践 3

在自动驾驶业务场景中，会经历「模型选型 - 模型训练 - 模型上车」等几个步骤，研发团队需要在不同模型中做实验选出最合适的模型，并完成模型训练，最后部署在量产车上。所以模型训练的速度越快，量产车获得最新 AI 能力的速度就越快，客户的体验就越好。

在与专有云 ABC Stack 的交流中，传统车企 C 了解到百度百舸的模型算法团队针对各类主流的自动驾驶模型都进行了极致优化，相比开源版本性能有大幅度提升，均已在 AI 加速套件 AIAK 中上线。

车企 C 的智算平台升级了最新的 AIAK 加速库，使得工程团队可以从 AIAK 中直接调用经过优化的模型，吞吐量最高提升 400% ，缩短 80% 的训练时间。

03 从「建好」到「用好」，加速 AI 原生业务的落地

当然，不止于上文提到的方法，GPU 效能的提高涉及到方方面面，比如合理划分故障域、为新的 AI 加速芯片开发监控指标、部署合适的任务资源调度策略、编写适用于大模型平台的管理手册等。

从「过去几块 GPU 跑小模型，业务逐步智能化」到「现在 GPU 集群跑大模型，业务全面智能化」业务场景的转变，这给企业的智算平台高效能运行带来了挑战。同时，由于 AI 原生应用、大模型、基础设施平台等相关技术正在快速演进，AI 算力提效将是一个长期存在的课题。

凭借着百度百舸 4.0 在大模型基础设施方向的领先技术，以及在不同企业级智算平台项目中积累的丰富经验，专有云 ABC Stack 将帮助企业成功应对最新的大模型业务挑战，「建好」和「用好」智算平台，加速 AI 原生业务的落地。

————END————

推荐阅读

百度APP iOS端磁盘优化实践（上）

对话AI原生｜比帮你写代码更爽的是：让Agent来打工

0 Token 间间隔 100% GPU 利用率，百度百舸 AIAK 大模型推理引擎极限优化 TPS

百度视频搜索架构演进

网页结构建模在低质采集站上的识别应用

01 概览 在APP的开发中，磁盘管理已成为不可忽视的部分。随着功能的复杂化和数据量的快速增长，如何高效管理磁盘空间直接关系到用户体验和APP性能。本文将结合磁盘管理的实践经验，详细介绍iOS沙盒环境

01 什么是大模型推理引擎

大模型推理引擎是生成式语言模型运转的发动机，是接受客户输入 prompt 和生成返回 response 的枢纽，也是拉起异构硬件，将物理电能转换为人类知识的变形金刚。

大模型推理引擎的基本工作模式可以概括为，接收包括输入 prompt 和采样参数的并发请求，分词并且组装成 batch 输入给引擎，调度 GPU 执行前向推理，处理计算结果并转为词元返回给用户。

• 和人类大脑处理语言的机制类似，大模型首先会把输入的 prompt 进行统一理解，形成具有记忆能力的上下文。这个阶段通常称为 Prefill 阶段。

• 在结束 Prefill 阶段之后，大模型引擎会根据生成的上下文不停地推断下一个可能出现的词语，如此往复循环，直到遇到停止符或者满足采样参数中的停止条件。这是一个自回归过程，通常称为 Decoder 阶段。

由于 Prefill 阶段和 Decoder 阶段所完成的任务不同，通常来讲，会从用户视角出发使用 SLO（Service Level Object）: TTFT（Time To First Token）和TPOT（Time Per Output Token）去评测引擎。

• TTFT 就是首 token 延迟，用于衡量 Prefill 阶段的性能。也就是用户发出请求之后，收到第一个词元返回的间隔，也就是系统的反应时间。对于客户来说，这个指标越低越好。

• TPOT 就是出字间隔，用于衡量 Decoder 阶段的性能。也就是每生成两个词元之间的间隔。通常需要比人眼阅读文字的速度要快，这个指标同样也是越低越好。

当然，只用这些 SLO 并不能完全评测推理引擎对资源的使用状态，所以，和其他使用异构资源的系统一样，会使用吞吐来评测引擎对资源的使用效率，常用的指标就是极限出字率。

极限出字率 TPS（Tokens Per Second ）就是系统在满载的情况下，使用所有可用的资源在 1s 内可以生成的词元的最大数量。这个指标越高，代表硬件的效率越高，可以支持的用户规模就越多。

目前市面上流行的推理引擎有很多，比如说 vLLM、SGLang、LMDeploy、TRT-LLM 等。其中 vLLM 是业界第一个完美解决了大模型不定长特性来各种问题的推理引擎，也是市面上使用最多，社区最活跃的推理引擎。

vLLM 的原创性高效显存管理、高吞吐、极易用、易拓展、模式众多、新特性支持快，社区活跃等特性是其受欢迎的原因。但是，vLLM 对复杂调度逻辑的处理没有做到极致，引入了大量的 CPU 操作，拉长了 TPOT。TPOT 的拉长会降低用户体验，降低了出字率，造成了 GPU 资源浪费。

02 影响 TPOT 的罪魁祸首 —— Token 间间隔

区别于小模型推理以 batch 为最小推理单位，大模型推理的最小单位是 step。这也是由大模型推理中自回归的特点所决定的。

每一次 step 会给 batch 内部的每个请求生成一个词元，如果有请求生成了结束符，那么这个请求将会提前结束，并且从下个 step 的 batch 中剔除，空余出来的资源将会被引擎动态的分配给其余正在排队的请求。用户可以感知到的观测指标 TPOT，就是每次 step 的执行时间。

每个 step 的执行逻辑可以简单的概括为一下两部分：前向推理和 Token 间间隔。

• 前向推理是调用 GPU 计算资源对 Transfomer 结构进行运算的过程，是一个典型的 GPU 密集计算型任务。

• Token 间间隔，则负责做词元拼接、结束检测、用户响应、请求调度、输入准备等工作，是典型的 CPU 逻辑密集型任务。

优化推理引擎的终极目标其实就是，极限提升前向推理的吞吐，同时极限压缩 Token 间间隔，最终提高极限出字率。****

然而，vLLM 的实现中，这两者天然存在着矛盾。极限提升前向推理的吞吐，（即充分发挥 GPU 算力）要求在适当范围内尽可能增加 batch 内的请求数。然而更多的请求数却拉长了 Token 间间隔，这样不仅会使 TPOT 拉长，还会导致 GPU 断流，出现空闲。在最差的情况下（比如 batch 为 256），Token 间间隔和前向推理时间几乎相同，GPU 的利用率只有 50%-60%。

为了提升极限出字率，同时确保高 GPU 利用率，优化 Token 间间隔成为了提升推理速度的关键。

03 百度百舸 AIAK 优化 Token 间间隔的方案

百度百舸的 AI 加速套件 AIAK 基于 vLLM ，在优化 TPOT 持续发力，并且始终保持着对社区在同周期的技术领先。

3.1 标解决方案1：多进程架构

这个方案的目标是尽可能缩短 Token 间间隔，将 detokenizer 所耗费的时间从 TPOT 中拿去。

我们发现在处理输入请求和生成返回的过程中，tokenize/detokenize 过程（token id 和字符串的转换）是完全可以独立于 GPU 推理运算的逻辑操作。

所以，我们借助 NVIDIA Triton 框架，将 tokenize/detokenize 的过程从推理流程中抽象出来作为单独的 Triton 模型部署，借助 Triton 的 ensemble 机制，把串行过程转变为 3 阶段（ 3 进程）流水，实现了 tokenize/detokenize 和 GPU 推理 overlap，有效缩短了 Token 间隔时间。尽管这个优化只把 Token 间间隔中一部分 CPU 操作消除了，但是依然有将近 10% 的收益。

3.2 解决方案 2：静态Slot方案

这个方案主要改造了 vLLM 的调度逻辑，全方位优化了词元拼接、结束检测、用户响应、请求调度、输入准备，提高了各个模块的并行效率，实现了对上一个方案中的「剩余部分」耗时的压缩**。**

我们发现 vLLM 的调度逻辑是面向全局视角的。也就是说每个 step 的调度都会从全局中进行重新筛选，相当于当前 step 结束之后，调度器会把当前 batch 中的句子「放回」全局请求池子中，然后在下一个 step 开始前，从这个全局池子中「取回」适当请求进行运算，这一放一取引入了额外的 overhead。

为了实现全局调度，vLLM 在词元拼接等其他环节引入了大量的 for 循环去串行的处理每个请求，由于这些操作都在发生在 CPU 上，导致在输入打包过程中，必须要引入耗时较长的 host to device 操作。

事实上，step 之间的很多信息是可以复用的（每次放回去的请求和取回来的请求很大一部分是重复的）。也正是基于这个洞见，百度百舸的 AIAK 把 GPU 每次可以迭代的 batch 当成一批固定的 slot，一旦某个请求被调度到某个 slot 后，在完成请求所有推理迭代之前，都不会被唤出，也正是有了这些固定 slot 抽象，AIAK 实现了：

• 将全局调度改造为局部调度。也就是在下一个 step 调度时，最大程度复用上一个 step 的信息，避免全局搜索，只做增量调度。

• 串行转并行。也正是有了 slot 的引入，词元拼接、结束检测等这些原本串行的操作可以用 CUDA Kernel 做并发处理，耗时从 ms 级别降低到 us 级别。

• 避开 host to device 操作。输入打包的工作得以复用前序的显存，有效避开了 host to device 操作。

3.3 方案 3：异步化执行

多进程架构将逻辑上容易独立的部分解耦到其他进程做流水并行，静态 Slot 方案则直面 token 间耗时问题，优化调度模式压榨各个环节的耗时。有了这两个方案，Token 间间隔已经从 35ms 降低到 14ms，GPU 的利用率已经从 50% 提升到了 75%，但是距离 100% 的 GPU 利用率和零耗时 Token 间间隔的目标还有不少距离。

百度百舸 AIAK 通过异步调度模式，将前一个方案中的「剩余部分」全部取出，最终实现了上述极限目标。

简单来讲，就是将 CPU 操作密集的 Token 间间隔和 GPU 计算密集的前向推理完全分开到两条流水线上做二级流水并行。

• 从逻辑上来讲，核心调度逻辑摆脱了对前向推理的同步依赖，实现异步化调度。

• 从效果上来说，GPU 避免 token 间同步导致的断流问题，处于一直繁忙状态，实现了推理过程中 100% 利用率和 0 Token 间间隔。

为了简化实现，我们将操作相对简单的前向推理当做一个任务放在后台线程中进行运行，主线程则运行核心的复杂的调度逻辑。两个线程通过一个队列进行交互，分别冲当生产者和消费者，通过线程信号量和 GPU 流上的事件进行信号同步，实现二级流互相 overlap。

和其他任何使用 GPU 类似的硬件作为加速器的系统一样，追求 100% 的利用率一直是所有工程师的终极目标。百度百舸的 AI 加速套件 AIAK 在优化 TPOT，同时打满 GPU 利用率这一目标上经历漫长而又艰辛的探索，最终才彻底实现了 0 Token 间间隔和 100% 利用率这一目标。

当然，除去在这个过程中使用的诸多巧妙的优化手段外，百度百舸的 AIAK 还在量化、投机式、服务化、分离式、多芯适配等领域做了大量工作，致力于实现一个适用于全场景、多芯片、高性能的推理引擎，助力用户在「降低推理成本，优化用户体验上」更上一层楼。

————END————

推荐阅读

百度视频搜索架构演进

网页结构建模在低质采集站上的识别应用

海量存储的批量计算框架

网页多模态建模思考

百度垂搜一站式研发平台演进实践

导读

随着信息技术的迅猛发展，搜索引擎作为人们获取信息的主要途径，其背后的技术架构也在不断演进。本文详细阐述了近年来视频搜索排序框架的重大变革，特别是在大模型技术需求驱动下，如何从传统的多阶段级联框架逐步演变为更加高效、灵活的端到端排序框架。

01 背景

过去近十年，搜索引擎的主流框架为多阶段级联框架，分为召回，粗排，精排几个阶段。在每个阶段中，系统会基于相关性、质量、时效性和点击率等维度独立建模，然后通过模型融合这些信号进行排序和截断，最终产出检索结果。随着以BERT、ERNIE和GPT为代表的预训练大模型技术的逐渐成熟，利用一套端到端框架解决信息检索问题变得越来越可行。同时，用户差异化，多样化，深层次信息需求越来越强烈， 为了满足这些需求，系统的算力需求也在不断增加。在这种技术及需求趋势的引导下，传统视频搜索排序架构如何演变，已经成为视频搜索最重要课题，同时也对排序架构提出了重大的挑战。

02 目标

以大模型技术为主线，打造高性能，扩展灵活的视频搜索排序框架，同时完成存量排序系统的熵减治理，从而来大幅度提升排序系统的系统能力，降级系统长期运营治理成本。

03 问题与挑战

• 架构功能如何解耦：视频搜索排序架构经历了多年的积累和发展，已经形成了策略、架构和产品逻辑高度耦合的局面。这种耦合导致排序模块承担了过多且复杂的功能，直接影响了研发效率，并频繁引发稳定性问题。此外，模块功能定位模糊，严重制约了新产品和业务的快速落地与迭代。面对这些挑战，我们亟需打破现有的陈旧框架，从更底层进行架构优化，以实现理想的业务和架构收益。

• 系统效能如何提升: 目前核心排序模块缺少灵活高效的并行计算框架，制约系统资源使用率的提升。与此同时，系统流量低峰时段会存在大量空闲资源，没有得到充分使用，如何充分，高效挖掘这部分空闲资源资源，来满足业务对资源大量需求。

• 端到端架构如何演进：在端到端大模型技术的引导下，排序策略的复杂性将逐步被模型内部化，现有策略实现可以得到极大的简化。传统多阶段级联排序架构如何演进升级，以适应这种新的排序模式，也是一个需要深入研究和探索的重要课题。

04 整体思路

对上述问题和挑战，我们采取了一系列综合措施来加以解决。首先，为了解决架构耦合与复杂性问题，我们对核心排序模块进行了深度重构，将原本集成在其中的召回处理与摘要计算功能独立出来，从而实现系统分层的合理化。其次，采用支持串行、并行和数据并行的灵活框架，提升视频排序流程的可视化管理和并行计算能力，并基于弹性算力分配控制中心，高效利用系统空闲资源，最大化搜索视频业务收益。最后，在大模型端到端排序模式下，推动多阶段级联框架向单阶段端到端框架转变升级。下面详细介绍以上解决方案的设计思想：

• 核心排序功能解耦：

• 视频核心排序模块是在线检索核心模块之一，之前承接排序和部分召回功能。累积了大量的视频独有的策略和业务逻辑，支持了视频搜索业务的不断发展。随着越来越多的策略、架构功能迭代，核心排序模块也越来越臃肿，接手、开发、维护等成本不断攀升。同时也面临例如不支持云原生、整体框架设计老旧、功能耦合严重等问题。

1. 将排序模块中召回处理阶段独立分拆，整体功能迁移至新的视频召回模块。

2. 利用图引擎将多Query串行执行升级至Query全并行执行，包含请求构建，Cache读取，结果解析。

3. 常用架构，策略功能组件化，插件化，易于理解、开发和维护。

△新召回模块

• 为满足用户差异化，多样化查询需求，每次请求都需要重新进行召回，排序计算，摘要处理等阶段。如果全量穿透系统缓存，会带来巨大的资源，耗时增长，系统成本无法承担，所以需要考虑目前视频搜系统分层设计是否合理，是否需要重新设计。为解决视频个性化带来的资源，速度问题，我们对视频搜索核心排序功能进行重新分层设计：

1. 核心排序系统结果返回和摘要获取解耦，视频排序系统有能力提供更多量结果集，弥补之前机制能力缺失的短板。

2. 新增个性化排序模块，优化传输协议，在核心排序模块返回更多结果基础上，同时穿透更多基础排序，供个性化排序使用。

3. 根据最终个性化排序结果集合，对Top N进行摘要处理计算，最后返回给上游模块。

   

△视频个性化排序演进

• 系统效能提升：

• 当前的视频搜索排序框架采用单线多策略管理器的串行执行模式。这种单线程串行处理方式在吞吐量和延迟方面表现不佳。此外，框架缺乏灵活的并行化配置能力，依靠人工经验引入各种omp，bthread等并行组件，并且存在历史遗留的冗余计算逻辑，架构组件较为陈旧。为了设计出能实际解决业务需求的现代引擎框架，我们对主流图引擎的特性进行了调研总结：

1. 驱动方式：排序层当有大量算子，上千维特征时，无论数据驱动，还是人工编排，可读性都很差。这种复杂性不仅增加了理解整个排序层架构的难度，还进一步影响了项目的研发效率。

2. 并行方式：目前主流job/processer算子并行方式，没有办法很好去支撑算子job内部并行，排序列队list/item-wise并行。排序数据通常含有多list, list内包含成百上千个item数据，这样数据处理模式需要job内部灵活的并行计算方案。

△驱动&并行方式

• 事实上，我们发现没有一套图引擎能够完全满足排序业务场景的需求。因此，我们提出了一种图框架引擎主张，灵活的支持搜索排序各个场景。

1. 除了支持serial，paralle模式，常见的job 间的串，并行模式，框架还支持data_parallel模式。召回返回数据通常包含多list队列，list队列间要做排序，list内有成百上千个item，同样需要排序，常见并行模式不能很好解决这种排序需求，所以我们在框架层做了data_paralllel模式设计，让它契我们当前排序模式，支持list+item的混合排序模式，同时能满足各种并行场景使用需求。

2. 对业务阶段进行清晰的stage，sub_stage抽象，相对传统图引擎算子推导，缺少很好可读的效果，我们做了stage抽象，配置可读性更好，配置即可读，排序全流程可视化管理易读易接手，这也就是我们做编排配置及推导的主要目的。

   

△Rankflow框架

• 我们不仅要提升现有系统的并行计算能力，还优化资源的分配和使用方式，因为搜索系统的输入流量、资源消耗、响应时间等系统状态存在着周期性的波峰-波谷变动，而系统资源已经预先分配好。在波谷期，由于用户输入流量的减少，系统资源不会得到充分利用；而波峰期，随着用户输入流量的增多，系统往往面临着资源紧缺甚至不足的情况。于此同时，搜索系统的业务链路复杂，时常还会遭受某一中间节点的故障甚至是外部流量徒增等稳定性问题。

• 架构方案：

• 构建全局视角的弹性算力分配控制中心。

• 通过对集群各种维度指标的获取、策略分析及周期性执行最适合当前机器负载状态的策略组合参数，实现其核心弹性算力分配决策。

• 业务应用：

• 目前支持视频搜索短小视频扩触发，高峰减载，系统异常处置等功能。

△智能弹性算力系统

• 端到端排序架构升级：

• 视频核心排序模块主要分为粗排，精排级联两阶段，排序策略是依据这两阶段排序模式进行迭代升级，如粗排阶段完成初步相关性计算用于初步筛选，减少精排阶段系统计算量，精排阶段少量优质结果进行复杂计算。以大模型排序为核心的排序框架打破了原来多阶段级联模式，端到端排序框架需要对计算和数据方案进行重新设计。

1. 精简精排前调权和挖掘队列策略，优化索引召回和模型计算选送逻辑，粗排和精排阶段统一为粗精排一体化排序阶段。

2. 由于缺少粗排模型提前初筛作用，端到端模型需要计算数量更多的候选结果集，计算候选集合从原来精排阶段的几十条增加到几百条。

3. 升级精排模块，利用Rankflow框架，高并发处理候选结果集数量增加带来的耗时问题。

△端到端排序架构

05 总结与展望

视频搜索排序框架通过系统分层优化、Rankflow框架引入及弹性资源复用等架构演进，显著提升了排序系统的性能与灵活性，提高研发效率，降低了长期运营成本。

• 在大模型技术趋势下，视频搜索系统如何更好提供RAG搜索增强功能。

• 如何使视频与通搜端到端融合，达到搜索端到端理想态，都是我们后续探索研究的方向。

————END————

推荐阅读

网页结构建模在低质采集站上的识别应用

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

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

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

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

导读 百度搜索是全球最大的中文搜索引擎，拥有着几十亿级的流量，作弊团伙通过各种各样的手段妄想从巨大的流量中不劳而获。搜索反作弊团队维护百度搜索生态安全和质量，经过不断探索并利用前沿技术过滤低质作弊网页