StreamSparkAI

speaker 1: 大家好，我叫谢立广。 呃，很荣幸跟大家那个聊聊我们最新的air bridge开源项目。 那个我们主要是想分享一下我们呃为什么那个开源这个项目，同时呢关于大语言模型推理的一些思考，还有生产的实践，对今天的这个演讲会比较呃低调，会涉及很多的技术细节。 对，开始之前那个自我介绍一下，我是谢立广，来自字节跳动的take inf就是基础架构团队，我是负责service computer infra，我的base在西雅图，同时呢我也是AI break开源项目的发起人跟负责人。 首先呢我们会对air做一个整体的介绍，包括就是大云模型lm英法遇到的一些技术瓶颈，还有架构的挑战，呃，air呢需要解决哪些问题，以及针对这些问题我们做出的一些呃解决方案。 然后同时呢我们会聚焦于推理，就大云模型推理的两个核心议题，一个是成本，一个是食延。 今天早上的那个圆桌会议，我们也呃反复呃讨论了这个问题。 就是说在呃AI呃GenAI的系统里面，这个实延会是一个很大的挑战。 呃，同时对系统的就system buil来说也是一个很大的机遇。 我们会分享我们在AI break里面针对这两个topic，就是一个是成本，一个是时延做出做出的一些优化手段，包括是如何通过自动伸缩mullaa的机制，已经cash away routing来有效的降低成本。 同时借助kv cac的呃loading就卸载，还有pd分离呃preview呃呢来优化，进一步的优化呃推理的延迟，使整体的系统呢更快也更具性价比。 最后呢如果时间允许的话呢，我会给一个小的demo，然后介绍一下air break接下来的一个路线图。 首先呢我们回顾一下过去一年半的开源模型跟闭源模型的技术趋势。 从24年呃一月份开始，差不多一年半时间吧，以deep si为首的这个开源模型是底下这条线呃，跟以open I谷歌为首的闭源模型之间，它的性能差距是在急剧的减小的。 大家可以看的看的比较清楚，整体A模型的性能是在快速的趋进。 然后随着性能高性能模型的成长，不管是开源也好，闭源也好，呃，推理的整体成本是在急剧的下降的。 这里会导致一种结果就是AI在开发者中，还有在企业中，它的应用，它的采用是呃正在加速的肉眼可见的这个速度在加速。 左图中呢是过去16个月gihu上整体的AI开发者代码仓库，它的数量整体是增长了175%。 右图呢是呃过去一个月谷歌在它的谷io大会上披露的。 呃，大家可以看去年5月份24年5月份，谷歌各类的产品跟api上他每个月处理的这个token的总数目呢差不多是10万亿个token，但是就就呃只有一年时间。 今年5月份谷歌披露的是数字呢是已经飙升到480万亿个token，就一年时间整整增长了50倍。 所以说在整整个一系列的趋势下面，对于一个呃企业的呃开用户来说，他其实面临的一个关键的问题是什么呢？ 如果想构建一个大规模的自托管呃，大于模型的推理服务是该应该怎么做对吧？ 这个是如何构建的问题？ 它的目的呢是实现数据的安全可控，显著的降低呃推理的成本，还有进一步提高呃推理的性能。 这在一系列的那个应用中，包括aggentic AI对吧AI呃agent这些都非常的呃呃关键。 行，下面我们就讨论一下呃lm的呃就是air整体的一个呃status。 包括呢刚才提到了lm正在快速的改变应用的这个构建方式。 但是如果你呃开始构建一个大规模的想部署大规模的lm的话呢，还是到目前为止还是充满挑战的。 可能大家尝试过用vm用去部署一个单点模型指的是什么？ 你部署一个小的几十B的一个模型在一个单机上，对吧？ 这个是ok的。 但如果你开始想部署一个跨机，部署一个比较大的模型，像deep P C R one呃6敲呃671B的这种满血版的模型就需要跨机了。 这个时候呢你会发现问题就开始变得复杂了。 如果呢你想更进一步，对吧？ 在一个大规模的生产集群GPU集群上呢部署大量的模型，复杂度呢是会急剧的增大的。 呃，传统的这个分布式系统会遇到的问题在这里也会遇到，而且是更加的棘手，包括什么呢？ 自动伸缩你如何做路由，路由到不仅是路由到一个po你, 还是得路由到特定的一个模型，甚至甚至不是base模型，是一个呃呃laa的一个adapter对吧？ 然后呢同时呢容错怎么做，服务呃就S O怎么做，成本效率怎么做，这些都是非常棘手的问题。 这个讲座主要会聚焦于这些问题，给出我们的开源呃方案。 然后呢AI break呢就是针对这些问题呃，是由字节呃字节跳动呃呃开发的一个云生的呃针对V 1M的一个服务站。 我们比较坚决的走原生的路线，而且是基于库K 8设计了AI break，提供了一整套的lm的生产部署。 从生产部署也好，从管理到自动伸缩的一整套方案。 我们的目标呢是简化部署流程，降低成本，并且提供端对端的极致性能、易用性、可拓展性跟性能呢是我们的呃主要的一些focus，也是同时也是呃外部的开发人员考虑采用AI boo的主要原因。 这里呢我展示的AI bri的一一个概念图，这是一个概念概念图，不是一个实际的一个部署图，我这里澄清一下，从上往下呢差不多有五层。 呃，最上面呢是一个比较呃标准的一个standard的一个兼容open api的一个入口。 它提供的是一个统一的且可拓展的入口，处理所有的呃lm的推理请求。 底下呢是一个api网关，它这里呢我们是基于envogateway去做拓展的。 然后呢呃可以优化实例路由，并支持不同的路由策略。 这里是比较重要的，你可以用这个我们的api网呃网关呢去定义你自己的路由策略，它是可拓展的。 一会我会详细的讲到。 第三层呢是我们的模型服务层。 它是我们这里是支持高密的loa管理，能够动态的去注册loa并在vm中呢追踪其来源，简化整体的这个管理流程，降低它的呃维护成本。 再往下呢是我们的一个编排调度层。 这里头我们是在多种的生产场景中呢去支持l的自动扩缩的策略。 一会儿呢我会就这个呃auto scaling就是自动扩缩的策略，呃，给出我们的遇到的一些生产实践，遇到呃生产中遇到的一些问题，跟我们的一些呃呃分享出我们一些经验。 然后最后底下呢是一个分布式的解呃分布式解耦的一个kv cash ac我们是我混呃引入一个分布式的kb支持高容量且是跨引擎的kv cash ac的复用，并且呢能优化网络跟内存的效率。 同时呢我们也支持了一系列比较高端的一些工具，也好像呃还有些像统一的run time GPU的流式加载器，统一呃混合的编排模型，还有呃诊断故障模拟的工具，基准呃测试的工具。 今天我就不展开了，大家可以到我们的那个呃就是giup上面去仔细，都有很多的document。 对ok刚才呢给大家展示的是一个概念图，这里是一个呃这个图呢是一个具体的部署图，实际上它的这个架构air boosh的架构是复杂的多的，它是由众多的原生组件构成的，具有呃真正的生产可用性。 我这里不呃仔细讲每一个组件，大家都可以在我们的giup上面找到详细的介绍。 好的，行，那个这一这一页呢我讲的是a break从今年20 2025年2月21号呃发布以来的一些开源状态，给大家汇报一下。 就说我们是第一那一天呢我们是由V 1M的这个官方渠道发布了，就宣布了V 1呃这个air break项目的开源。 在发布的第一周呢，air表现比较亮眼，呃，我们迅速呃一度登上了呃Githu热门项目排行榜的第一名，差不多呃持续了一周左右吧。 然后air base呢也同时呢获得社区的关注跟支持，我们已经累计超过有3600个star，同时也收获了五十多个呃社区的开源贡呃开开源的贡献者参与项目的发展。 同时呢我们主要的目标呢，尤其今天我在这其实也想宣传air Brea想, 我们是想把air建成一个社区来驱动的这么一个项目，而不只是字节呃的一个项目。 然后我们想吸引众多来自学术界、工业界的一些呃合作团队，对吧？ 然后现在的话跟大家汇报一下，就是我们已经是在呃，不好意思，就是我们已经在库Berne迪社区跟谷歌还有rehead开展合作，呃，共同推动这个AI推理负载在kuberne生态的一些部署优化。 同时呢我们也跟aws的团队呃合作，是aws主动提出的，主要是希望将AI部署到呃aws那呃库迪的服务是呃aws eks，大家也知道aws eks是全世界最大规模的ku布ne托管服务。 然后呢在今年呃呃呃euro在荷兰举办的这个会议上呢，呃air跟aws已经联合展示了如何把air部署到1K上面，部署了一个deep sick R one的满血版模型，同时呢是跑在aws的跟enti的这个芯片上。 And this this is big deal, 就因为这个证明了air bi是可以在mv的这个G P U上跑的。 下面这个是我们是持续呃收到了那个业界的一些endorsement。 包括谷歌的distinguished engineer呃呃Clayton Coleman，他给的评价，还有呃像any sk的cofounder read cocre呃Robert nichela给的一些评价。 像呃Clayton给的评价是非常高的。 这个说by dance has been a phenomenal partners in helping Google driving standardization of lm serving in。 呃，到目前为止，AI已经发布了三个版本。 从去年10月份的第一版本，今年2月份的0.2版本，呃呃五月份刚发布的0.3，还有这个月会即将会发布的0.4。 然后第一版中就0.1呢，我们是专注于构建一个基础，就是如何构建lm服务的云原生的基础。 包括g pu的流式加载器来降低冷启动的时延，引入了自动伸缩。 刚才我反复提到自动伸缩，以及如何高密的部署这个Lora adapter来降低推理的成本。 0.2的话我们是新增了对分布式kb cash ac的这个支持是而且是配了deep sick R one的这种跨节点的编排跟异构硬件的这种服务能力。 同时呢我们也向分布式跟解耦的架构迈进了一步。 0.3呢是刚刚发布的，我们推出了应该是业界的soda，就是最先进的一个kcash异步卸载方案，非常显著的提提升了手token的响应时间，就T的时间呃，一会我也讲讲呃，具体讲到数字降低了80%。 同时呢我们也引入了preficash ac感知跟公平性的这种调度策略等高级的调度能呃路由能力来提供一个完呃并且提供了一个完整的这种benchmark的to。 在马上要呃发布的这个就六月的0.4版本，我们会聚焦于呃pd分离，就preview呃decodisaegregation我们会在后面的这个页面中呃详细的介绍。 Ok现在我们开始讲成本，就说呃刚才提到了这个推理的成本是非常关键的。 尤其是你如果是在一个大规模的生产系统，对吧？ 假设你要部署很多的这种AI的agent，不只是一个简单的Q&A那每一个AI的agent它又是呃有多个agent对吧？ 每个agent涉及到多个work flow，这些work flow呢后端的一个呃咱们说个大的引擎吧，就是一个这种呃大于模型的推理。 然后呢我们会在三个方面来着力这个推理成本的优化，呃，基于异构资源的自动扩缩容的决策，laa的管理，还有呃还有routing的管理，就是那个路由的管理。 呃，这里我先提到就传统的K 8在遇到呃大圆模型推理场景的时候，它的自动伸缩的机制呢，就现有的这呃自动伸缩机制呢是会遇到很多的挑战的。 你包括如如你想如果想挑选一个扩缩容的指标，对吧？ 现在可能很多都呃去挑选qps，但这个指标在大云模型推理是不管用的。 而且你还得如何处理生产环境中的GPU的异构，假如你有呃A 100，你有呃L 20对吧，你怎么去做这个异构，并且如何的呃做出扩缩容的决策。 在满足业业务soo的情况下呢，成本做到最低，这是一个关键。 而且同时呢大云模型他推理他对计算资源，对GPU的计算资源的要求是非常高的。 如果你呃你的英法做的不好，那你面对突发流量的时候呢，你整体的这个系统是会受到很大的挑战。 这里就强调了弹性伸缩能力，后面我会呃呃聚焦这个问题来展开。 我们在设计这个自动扩缩成系统的时候，我们其实也遇到很大的挑战。 我这里跟大家分享我们遇到的三个挑战。 第一个挑战是说就是刚才提到了扩缩容指标的选择。 这里的话是一些我们生产的实践吧，就是说在传统的微服务中，刚才提到q ps s呃，通常是指导这种扩缩容决策的一个主要指标。 在这里有一张图，第一张图你可可以看到呃黄线代表的qps在这个时间段呢qps呢是完全是平的，但是呢呃蓝线呢代表着时延，时延呢是呃变得很厉害。 也就是说在大圆模型的推理中，你不能简单的用qps去做auto scaling的一个判断。 主要的原因是因为不同长度的lm的请求在资源消耗上是有非常大的差异，而且是不可预测的。 在接下来的两张图底下，这两张图我们想进一步说明的是，在即使你想使用sm activity这些常用的GPU指标，这这是一些比较常用的衡量GPU利率的办法。 在大圆模型推理也不是百分之百靠谱的。 我们追踪了几个例子吧，就说有一些例子s an activity几乎是没有变化的，但是在实际的推理中呢，他的推理请求其实增加了不少的。 所以说针对这些挑战，我们是提出了lm呃推理的air的方案。 主要是我们提出了一些专用的扩缩容指标，包括t ft手token的时延，tpot temper output token这些更精细化的指标呢是可以帮助我们更准确的去判断业务的压力，资源的压力，从而呢实现更合理的自动扩缩容的这个判断。 第二个挑战是生产环境中的GPU异构性。 呃，在呃在座的各位，包括字节，我们都在很多商业化的平台中都有部部署多种不同类型的G P U作为一个呃系统的开发者，我们当然希望所有的g pu都能利呃得到合理的利用，充分的利用。 但问题是我们是怎么去兼顾利用率，就GPU的利用率，还有那个soo的，这是我们想解的一个问题。 我们中呃这篇文章中呢得到一个非常有趣的一个观察。 就是说便宜的g pu其其实是比较适合去处理小的request小的请求的，而且高端的GPU是可以处理更合适去处理大一点的，比较呃heavy的请求的。 左边这张图大家可以看到啊，就是说展示的是A 100跟H100它的性能对比，它的指标它对比对比的指标呢是token per dollar，也就是说就是说呢生成一个token一个m token所需要的美元的成本。 就说大家可以看到就是说每一种不同的g pu类型啊，它都有自己上传处理的这个request的范围。 在小的request范呃的场景下呢，A 100就在这里个对比中是相对低端的，它的性价比呢可以是提升40%。 Air break主要就利用了这个观察，设计了一套基异构GPU的自动扩缩容的方案。 最后呢我们讨论一下扩缩能决策，在这里呢我们把扩缩能主要的算法主要分为两类，这比较呃倒是比较好理解。 第一类呢是呃reactive base的，就基于响应的自动扩缩容的方法，它主要是根据当前的请求模式的变化来做扩缩容的决策的。 第二类呢是prediction based的，就是preactibased的，他是通过预测未来的请求模式，提前做提前量去做这种扩缩容的调整。 我们近期呢也准备引入一些基于预测的扩缩容的这个策略。 整体的话呢，AI bri呢是将呃使用模型整合到一个在线的自术呃自动扩缩的解决方案中。 我们提供了两个关键的能力吧，一个是怎么有效的监控请求的负载，另一个是怎么把请求的路由呃ro到合适类型的GPU中去呃利用到的。 就刚才提到的几个呃能力，我们把这些呃能力整合在整合起来，真正实现了一个线上可用的自动扩缩容的系统。 好了，讲完呃auto scaling，我们讲讲multi呃Lara Lara的话呃给呃先讲一讲一些呃基本的背景吧。 是一种呃高效的微调呃预训练模型的一个技术核心的思想。 其实比较简单的就是说你其实并不需要每次都去训整个大模型，你可劝一个大的模型非常贵，对吧？ 你只需要去调优一小部分的参数，这里就是这里所谓的Lora adapter就是这个适配器的概念。 这些adapt呢在生产中呢是比较好用的。 为什么？ 它的存储，它的内存的开销，如果跟呃pretr的模型相比呢，它只占pre模型大小的约1%，也就是说呢你其实可以把大量的Lora adapt部署在同一个po里面，你达到这种呃高密的部署。 降低生产呃成本，字节跳动在生产环境中是支持了大量的lower adapt，而且我们发现它的流量模型是差异巨大的，有一些是关键的这个高流量的生产模型，但大部分呢是低流量的实验性模型，在这种情况下la拉是比较管用的。 我们可以希望将laa adapter呢刚才提到合并部署在同一个base model就基基础的模型实例上来提升部署的密度。 而且相对比为每个adapter来单独部署一个副本。 也就是说单独呃就是分配呃一张gp U或者是多张G P U，如果将他们打包在一起是能显著的降低G P U的成本的。 总之而言就是说我们是觉我们是认为提高部署密度是应对这种呃微调模型数量越来越多的这么一种呃一个关键技术。 好，这里我我们讲一讲实际在运用laa的这个应用落地的时候呢，遇到了一些挑战。 就说虽然这个laa呃听起来很美好，但是他在生产落到这个K 8上是有很大的挑战的。 呃，主要是因为什么呢？ 因为laa模型呢必须跟基础就是laa的adapter必须跟基础模型一起加载，你是不能分开加载的。 这就打破了ku的一个传统的假设，就是说每一个模型或者服务都有一个非常干净的one on one的mapping，就是一的应试关系。 默认的服务机制就kuberne的服务机制没有办法帮助你去发现哪个loa adapter它的负载是最低的，这是现在的Kuber是做不到的。 也就说呢你会出现多个laa的adapter在同一个po里面增强pu资源，而且呢你的路由呢也非常的棘手。 你讲讲。 举个例子，假如你想定一个呃routing的，说我要把某一个request route到这种最低负载的adap里面。 这个在现有的K 8中是很难做到的。 所以说呢虽然Lara呃简化了模型的交付，提升了效率，就是说GPU的利用率，但是呢它给编排调度就是这一层呢，K 8的编排调度这一层，还有请求路由这一层呢呃提出了新的挑战。 这个就是我们呃呃提出的一个方案，就为了解决这个问题。 Air bri呢是跟V M社区联合，呃，air bri的在vm的这个社区里面贡献了一个非常关键的能力，mullaa的能力来提升生产环境中对的的这个管理能力。 首先呢我们是引入了动态模型的适配器管理，就dynamic model adapter management。 这个这个呃management呢是可以允许我们平台根据需求来动态加载跟卸载这个loa的适配器，而不是在容器启动的时候就固定的加载，这个还是比较重要的。 在这之前你必须在容器启动的时候硬性的说我要哪些laa这个在生产环境中呢是不是非常的efficient？ 第二呢我们也加入了先进的调度算法。 这个schedule algorithm能根据当前的负载GPU的可用性，还有适配器的亲和性能，智能的将laa部署在合适的pod里面。 目的呢是呃减少适配器就adapt之间的干扰，整整体的推呃推理性能能最大化。 最后呢我们是那个实现了基于库呃M的一个laa专用路由控制平面，可以将每个adapter作为独立的这个路由目标暴露出来。 这样就解了刚才说的你怎么把你的traffic ro到一个特定的adapt去的这个问题。 可以将这个traffic精确的呃路由到最合适的pod还有adapt里面。 这整个三项技术结合起来呢，我们为K 8基于这个laa的服务带来更精细的控制，并且是呃性能上还有扩展能力上是能更优的。 好，讲完lo拉之后呢，我们说说看呃lo拉在生产中的一个实际性能跟呃成本的对比。 就是说我们发现左边这张图，我们发现在吸疏流量的场景下呢，借助a bri我们可以把整体的资源成本降低呃高达呃4.7倍。 呃，传统呢在的部署在这种情况下呢可会浪费大量的GPU资源，即使是在高负载的情况下呢呃呃依你依赖vm还有基于tr统的高性能laa内核。 呃，这么对比的话，呃air base依然能保持大大约1.5倍的资源节省。 其次呢也通过这种高密度的laa部署，并且合理的调节batch的这个大小。 我们观测到成本上呢，我们能取得大大约8%到2.1%倍的这种成本的下降。 这里呃主要是没法给出一个非常具体的数，因为又呃涉及到具体的负载的这个呃pattern。 Ok好讲完laa之后，我们讲最后一个成本的呃技术是这个routing。 这里给一个preface routing的一个11就是说呃在大语模型推理中，为了命中这个kv cash对吧请求的路由呢是需要把你需要把请求路由到持有相关kv cash的实例中，就这个pot里面。 并且呢你要求路由器呢这个route，你是知道说哪个po拥有哪些前缀就prefix，从而呢你能正确的发放这个request。 这里给一个例子，呃，第一个第一第一个request是说呃I like apple。 这这个时候呢所有的节点都是空的，所以说你可以任意选取一个节点，no one no two都没问题。 但如果是第二个请求，依然是I like apple。 这个时候呢，假如假设第一个request是ro到no one，而且呢已经在no one建立了kv cac这个时候，你把它ro到no one request，2 ro到no one是make sense的。 这个时候呢你能百分之百hit这个路呃，这个kb cash。 但假假设这个时候呢来了一个新的这个呃request request three对吧？ 呃，I like apple very much. 这个时候呢你如何做路由？ 这个时候呢一个决策点是什么？ 你如何权衡延迟跟负载？ 呃，我们可以看一下，就是说假设你把这个request ro到no one去，你能取得50%的match。 但是呢no one假设这个时候呢它的负载是比较高的，50%，呃，no two呢只有30%。 所以说你未必把呃request Rono one能取得很大的这个性能收益。 所以说呢这里你需要衡整体的衡量呃延迟跟负载，这样的话让整体的这个路由决策变得就比较复杂了。 为了探索这个问题，air呃我们在air bi中是实现了一个前缀可感知的这个路由算法pr呃prinples来帮助air bri动态的决定的cash。 在cash ache环境下呢，请求应该发到哪个po里面来平从而来平衡负载跟实验之间的关系。 我们看一看这里air的话的这个route的架构是这样子的，第一呢是说请求是将会发到en的gway，我们在en呃gateway之外呢，我们用了它的这个extension的这个呃service。 我们呢把请求先转发到AI的router，然后在router这边呢会根据呃定制好的规则呢，在这里实现这个routing。 然后呢配置好的这个计算出目标po的ip之后呢，我们会把请求的这个呃呃ro到对应的合适的port区面。 在这个设计中，AI bridge是作为eny的一个external service存在的，它跟其他的部分是一个完全解耦的。 所以说如果你想定义一个呃适用你生产的一个这么一个路由规矩呃规则，你是可以在air的路由里面去做的。 这个给生产就提供了一个比较好的一个时间。 好，讲完了那个成本，我们讲性能，就说呃我们为什么要关注性能呢？ 这个呃大家这个比较好解释，但是怎么解决，我们是提出了两个，一个是kb cash ac的卸载动态卸载，还有pd的这种呃disagregation。 就说在l的实践中呢呃kv cash ac是非常可复用的。 简单来说，如果是lm因为它是基于transfor的模型，在每次推理中呢都会遗留一些中间计算的结果。 刚才提到了I like apple，它会在no one留存它的kb cash，这个可以被后面的request复用对吧？ 这就是一个比较简单的一个呃呃一个例子。 如果后续的请求跟前面的请求有前缀的重叠的话呢，你是可以通过复用kb cash来加速呃计算的，就是以纯代算。 然后这个呢在很多的生产场景，像这种聊天机器人对吧，多轮对话呃，AI agent这些都能观察到很多重复的前缀序列。 像你system pro就是很多，而且你多轮对话的话呢，你有很多的system pro是会一直被那个呃复用的。 但问题是kb cash ac本身呢是会消耗大量的GPU的显存的，而且这个消耗呢随着你的模型规模的呃增大，还有你的呃上下文就conttest window的增大呢是急剧的增增加的。 这里举个例子，一个不大的中型的模型，70B的模型，你如果想支持一个hundred k呃十万的这个上下文的话，仅仅是kb cash这一项缓存呢就可以占几百个G B。 这个在那个现有的这个呃就是GPU的显存的框架下呢是不可接受的。 而且你一达到上线的时候呢，你的引擎的推理引擎就需要把一些token的kcactensor从缓存中清除掉。 但是呢如果你这个时候request又来了，但是缓存已经没有了，那你就只能重新算一遍。 这样的话呢你又浪费了一堆的GPU的算力，对吧？ 这是受限的这个g pu缓存带来的第一个挑战。 第二个挑战我这里呃快速通呃过一下就是kb cash的迁移。 就是说呃大家知道呃在分布式系统中呃出故障是很正常的。 然后推理引擎同样也会遇到呃故障的问题。 当你引擎出现问题的时候，你怎么把kv cac就是具有容错能力，呃，migr到其他的呃node里面去。 最后呢是一个硬件呃平台带来的限制。 我这里呃简单的讲一讲，就是说很多的云厂商还有这个公司会部署一些比较低端的G P U实力对吧？ 这些实力本身是没有mb link的，就是那种高速互联的技术了呃，或者没有呃R D M。 你如果是说哦，像这里有一个例子，就说你一个实例里面，你多个G P U共用一个V P C的网卡。 这个网卡在高峰的时候呢是很容易出现，也呃成为一个瓶颈的。 会因为网络的堵塞呢严重的卡住，导致导致了你整体的这个服务时延大幅的飙升。 然后呢，为了解决这个问题，我们是提出了一个减少不必要的数据传输，同时呢最大化利用网络的带宽。 这些具体的方案大家都可以在我们的giup rep上看到具体的这个呃这个code，还有我们的具体的一些呃performance的comparison。 然后呢，我们这里想出的一个具体的方法是说什么呢？ 选择性的进行kv cash的缓存卸载，只卸载部分选定的K V一的张量。 然后我们把刚才提到的三个挑战一起整合，就是形成了我们一个全新的kv的缓存卸载的框架。 这里呢这个框架呢是一个比较可拓展的一个框架，大家可以用来测试各种K V缓存的优化策略，呃，把它当成一个实验的平台。 首先呢是一个淘汰的策略evision sion policy。 我们通过可插拔的这种策略引擎，你可以设计并呃尝试各种不同的淘汰策略。 从经典的L U到基于呃attention的的这种分数的感知淘汰，来实现高效的可选择性的kv的缓存卸载。 接下来的是呢可插拔的序列化引擎，你可以用来研究kv感知的压缩，还有量化的算法对你的性能的影响。 所以说这是一个非常呃呃extenable的一个framework。 下面一张图我们展示的是air bridge如何在云原生编排下的这场景下呃，编排一个分布式的kv集群，kv cash ache的集群。 每一个每一个vm的这个po里面呢，就容器内部我们都会集成一个air bri的kv cash acconnec而. 且这个模块呢这个模块是通过一致性的哈希来访问一组分布式的K V cash的server。 这些呃底层的这些服务节点呢是由in finstore，这是by dance的另外一个开源项目呃提供的。 然后呢，它的缓存的卸载是通过rdma来进行直接进行了。 然后呢air base的控制面的设计也比较轻量化。 我们做的这个比较呃呃straight forward，就说而且是模块化的。 我们是通过read的存储后端来存储这个原数据，还有slot的映射数据。 呃，客户端呢是通可以通过ready是直接去查询说哪个后端节点有你所右的kb cache呃，还有slot分布，从而实现这种高效可拓展的访问途径。 在呃讲完kv cash acuploading，我们最后呃几分钟讲讲这个pd分离吧。 就说在传统的架构中，呃，preview跟deco大家应该都比较熟悉对吧？ 是大于模型推理的两个阶段，一个是计算呃计算那个密集型的对吧？ 另外是一个是那个memory io的，然后他在这两个阶段是共用一个GPU的。 这样会造成了彼此之间的这种资源的干扰，尤其在处理比较大的这种呃pro的时候呢，会拖慢原本非常轻亮的decode的请求。 也就是说pre会占用大量的计算资源，延迟了其他request。 Deco请呃decodecode。 所以说呢pd分离呃业界是就专门针对这个问题而提出来，现在已经有非常多的呃实践了。 一会我们会给大家一个图，就说现在业界的呃几种实践方法是通过主要是它的原理是通过P跟D分别交由不同的work节点去处理，并且针对各自的负载呢进行优化。 呃，这种角色的分离呢可以确保抵扣阶段的时延的高并发。 还有prom在prom很heavy的情况下呢保持稳定。 在AI bricks的呃测试中，我们启动了pd分离，马上这个月又发布0.4版本，就有这个呃实践。 这呃就是呃首十延这个token呢我们是能他的P95我们是能测通过测试它能降低至多80%左右。 而且是在特别是在deep stick这种R one这种大模型中呢，当你的推理这种reasoning能力被开启，它的而且它的O呃输出比较长的时候呢，呃deco的很容易就成为性能瓶颈，这个时候呢优化的效果是非常显著的。 然后air bi的话呢呃常就说刚才提到了业界其实已经有非常多的这种实践了。 在air中我们是实现了pd分离，有两种不同的架构方式，一种是那个集中式的kb的存储架构，centralized kb cash ac的architecture。 这个architecture比较好呃理解，就说在preview完成阶段完成之后呢，这个K V的数据是会写到一个共享的K V存储服务的。 然后呢，随后呢deco的work呢是会从这个中心级的存储服务拉取所需要的数据来进行deco这个processing。 这种架构在moon cake中是被采用了，而且具有比较好的横向拓展能力，比较适应多节点的大规模部署。 另外一个架构呢是那个就点对点的P2P architecture。 在这个模式中呢，worker是直接从原始的preview节点拉取kcache，省去中间一跳，呃，这样的话时延是比较好的，但是呢同时它的节点的耦合性呢是比较强了。 拓展性呢相对受限。 随着霹雳分离呢逐渐成为整个行业的常态，每一个推理的服务单元也不再是一个单一的port，而是由多个不具有不同值责责的组件呢组成的一个小型分布式系统。 包括decode preview，还有可可选的一些本地调度去等等等角色。 为了简化这一整套的这个P D的disagregation，我们呃引入了一个新的抽象概念叫做row group角色组。 通过row group的AI break可以将preview deco还有本地的调度器作为一个逻辑单元，一个逻辑整体进行统一的调度跟生命周期的管理，从而有效的简化每一个实例内部的复杂度。 好，下面我们讲一讲呃air base本月马上要发布的0.4的一些呃romap呃，我们会对编排人做进一步的增强，呃，包括这种支持呃跨角色组的呃rolling upgrade滚动升级，确保服务高可用。 同时呢也引入了这个网络的亲和性network fini还有呃刚scheduling，保证了这个协作组件之间的性能协同，还有低延迟。 从技术的角度呢，虽然air base会重点推自身的一些解决方案，但是作为一个开源项目，也是一个控制面平台。 我们呢是想保存一个有高度的开放性的，可以跟moon cake啊还有的dyable x这些推理项目呢做呃实现一个无缝的集成，来灵活适配用户的一个技术站。 好，最后可能我们没有时间做那个呃demo，但是我这里掌呃先快速掌望一下我们在本就是本月底要发布的一些组件吧。 包括这种呃pd的解耦的架构，基于V M V one connect的这种呃kv cash异步的卸载机制，还有包括kv cash的智能路由机制，以及包括呃呃我们有一个呃Intel提出的一个一个scenario是对多租户的这种场景的支持，也会在0.4中全面支持。 就说我们陆续会推出呃在字节内部的一些多个技术方向的研究成果，还有实战的经呃经验并呃陆续的开源，也敬请大家呢多关注多支持。 呃，ok我们这个有一个demo是呃看一下怎么用一键部署air，从从而实现这种呃dee p 8万的部署和还有pd分离的。 呃，可能时间不够了我就略过了。 呃，最后呃谢谢大家，就说这是air的项目的githurepo，还有一些呃呃air呃社区的微信交流群。 那个感谢大家的支持，我们后续会呃听取社区的一些呃反馈，然后来不断的迭代改进我们的这个呃社区。 呃，好，多谢大家。