教AI如何在“客人”突然暴增时，通过内部“瘦身”和“团队协作”，保证响应速度，避免“宕机”

sourcehttps://mp.weixin.qq.com/s/8qHbhNQu184lpBZBHkpVSgKUNSERVE的系统它专门解决大模型在线服务时“GPU 显存被 KVCache 撑爆、排队严重”的问题。核心思路是既然多张卡上本来就有重复的模型参数那在内存吃紧时可以临时丢掉一部分冗余参数把显存让给 KVCache再用多卡流水线协作来保持推理正常进行。这样在流量突发时可以把“首字延迟TTFT”的尖峰压下来P99 最多快 72.2 倍代价是每字延迟TPOT略变长一点。问题背景AI服务器的“记忆力”危机想象一个大语言模型比如ChatGPT是一个24小时营业的超级图书馆。它需要在极短时间内回答各种问题。这个“超级图书馆”的“实时记忆”都储存在GPU的高带宽内存HBM里。我们可以把HBM想象成图书馆员面前那张价值连城的“多功能智能办公桌”它需要同时处理两件事放置“参考书”模型参数这是馆员的“大脑”和“知识库”是AI做出判断和推理的基础。充当“草稿纸”KV Cache馆员在回答问题时会把理解、推理的过程飞快地记在“草稿纸”上以便随时查阅避免重复思考。当提问的用户突然暴增比如某热点事件发生后每个人都想立刻得到回答。这时巨大的工作量会让HBM这张“办公桌”瞬间被“草稿纸”堆满这就是内存过载Memory Overloading。在过去馆员只能用一些笨办法把部分草稿纸直接扔掉Drop等有空了再重写。把草稿纸搬到远处的柜子里Swap需要时再跑过去拿回来。把草稿纸交给隔壁忙不过来的同事Migrate问题转移到别人桌上。这些方法都治标不治本要么浪费之前的工作要么引入新的搬运时间导致用户等很久才拿到第一个字这就是首字延迟TTFT飙升。 核心思想从“单人作战”到“团队协作”的“瘦身”计划这正是KUNSERVE的聪明之处。它换了个思路以前总想着怎么折腾“草稿纸”为什么不从占地方的“参考书”模型参数上想想办法呢它发现为了保证服务稳定图书馆通常会部署多个一模一样的馆员多副本集群他们桌上的“参考书”模型参数都是一样的。所以KUNSERVE的核心思想是在业务高峰期大家没必要人手一套“参考书”硬撑。可以临时组成一个“互助小组”Cooperative Group每人只保留一部分“参考书”把空出的桌面空间让给“草稿纸”。这样既不耽误回答问题又完美解决了空间不够的问题。这就像一支F1车队在预算有限的情况下不一定每辆车都配备最全的工具箱而是通过团队协作共享资源和信息共同完成比赛。 如何实现一次精密的“协同作战”这个“瘦身协作”计划执行起来主要分为三步 定计划Drop PlanKUNSERVE的“总调度中心”会快速评估哪些馆员的“办公桌”最紧张并计算出最优的“瘦身”方案——决定让谁放弃哪部分的“参考书”从而释放出足够空间。 巧搬家GPU Virtual Memory参数被移除后腾出的空间不会闲置。系统会使用一项名为“CUDA虚拟内存管理CUDA Virtual Memory Management”的技术将新空间无缝地“拼”到“草稿纸”区域。这就像用魔法扩展了桌子的草稿区但从馆员的视角看草稿纸还是完整的一大张用起来和以前一样方便。 无缝协作Lookahead Batch Formulation参数被拆分到不同馆员那里后一个请求就像一个“流水线”Pipeline Parallelism需要在不同馆员之间传递。这会产生等待时间即“流水线气泡Pipeline Bubble”。KUNSERVE会“预判”任务的复杂程度智能地拆分成一个个“微型任务”Microbatch尽可能让每个人手上的工作量均衡让流水线持续运转减少等待。 最终效果快72倍的响应代价在可接受范围实验证明这个“瘦身协作”方案成效显著速度飙升在模拟的真实流量冲击下KUNSERVE将用户等待响应的时间P99 TTFT最高降低了72.2倍。代价可控虽然“协作”会带来一点点额外的内部沟通成本导致处理每个字的平均时间TPOT有约16%-23%的轻微上升但这远好过让用户干等好几秒。 总结一次思维方式的转变KUNSERVE的精髓在于它完成了一次从“以计算为中心”到“以参数为中心”的内存管理思维转变。它证明了在多副本的AI服务集群中某张GPU上的参数副本并非神圣不可侵犯通过巧妙的调度和协作可以把它变成应对流量高峰的宝贵缓冲区。当然它也有局限性比如释放的内存上限就是参数本身的大小并且对调度和网络要求更高。但无论如何它为解决大型AI服务的瞬时拥堵问题提供了一个极具启发性和开创性的新思路。