北京
过去一年，如果你用过任何大语言模型产品，就一定会撞上一套大多数人从未留意过的后台系统——那个把你的输入变成一串串文字的服务引擎。很长一段时间里，这套系统的运作方式与规模大小无关：一块GPU，或一小簇GPU，会接收你给出的指令，处理它，然后逐个符号地生成回应，整个过程都在同一套硬件、同一个进程里完成。
但这套做法正在悄然崩塌。上下文窗口已经突破了十万个符号的大关，请求量的增长跨越了好几个数量级，而跑推理的成本，已经成了大多数AI公司董事会桌上的议题。一个已经浮出水面的解法，并且正在全球一些最大的大模型供应商那里实际运转着的，叫做“拆解式预填充与解码服务”。这听起来像是个狭窄的基建细节，但它其实是当下生产环境里比较有意思的分布式系统难题之一，而且关于它的讨论，远比缓存或负载均衡要少得多。
问题的根源在于，预填充和解码这两件事，天生就不想待在一块儿。每个大模型推理请求都包含两个截然不同的阶段。预填充，是模型读取你的整段提示，并为你输入的每一个符号，逐层构建其内部表征的过程。这一步是计算密集型的，极度消耗GPU的原始算力，并且每个请求只要运行一次，与最终回应的长度无关。解码则是之后的事：模型一次一个符号地生成回复，每个新符号都依赖之前生成的所有内容。这一步变成了内存带宽密集型，GPU大部分时间不是在跑繁重的运算，而是把键值缓存（KV缓存，也就是存储着模型对对话过程的“运行记忆”）搬进搬出内存。
这两种阶段对硬件的要求几乎截然相反。预填充渴望的是纯粹的算力，解码渴求的是内存带宽和对KV缓存的低延迟访问。当两者在同一块GPU上、在同一个批次里同时运行时，它们就会争抢相同的资源，彼此干扰。一个很长的提示突然进入预填充阶段，就可能让那些已经处于解码中途的请求，其符号生成过程陷入停滞，而这在最终用户那里，就会表现为一次突如其来的延迟飙升。
围绕这个问题的学术研究，包括DistServe和Splitwise等论文，以及像Mooncake这样的生产系统，都汇聚到了同一个结论上：把这两个阶段拆到不同的硬件上去，让它们各自被独立地调度和伸缩。在高层次上看，拆解式服务引入了一个在单体架构中不存在的全新组件：一个负责把KV缓存，从执行预填充的机器迁移到执行解码的机器上的对接层。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
