admin管理员组

文章数量:1037775

月之暗面：存储换算，倍增LLM推理效率

在AI大模型时代，用户对实时交互体验的要求与日俱增。大型语言模型（LLM）的推理延迟成为制约用户体验的核心痛点，其关键参数TTFT（首Token时延）和TBT（令牌间时延）直接决定着对话流畅度。传统系统在处理长上下文查询时面临三大困境：GPU算力不足、缓存复用率低、存储带宽瓶颈。

本文聚焦Moonshot AI提出的Mooncake架构，通过存储资源重构实现计算效率跃迁。该方案以KV缓存为中心，构建分布式存储池，将缓存容量从GPU HBM的3M令牌扩展至全集群级别，配合零拷贝传输引擎和LRU淘汰策略，成功将A800集群的请求处理能力提升115%。这项创新不仅重新定义了LLM服务架构范式，更揭示了存储与计算资源动态平衡的底层逻辑。

Moonshot：存储换算，倍增LLM推理效率-2.png

阅读收获

  1. 掌握LLM推理延迟的量化评估体系（TTFT/TBT指标）
  2. 理解存储-计算资源动态平衡的工程实现路径
  3. 获取分布式KV缓存池设计的三大关键技术：哈希分片、LRU淘汰、零拷贝传输
  4. 看懂Mooncake架构如何突破GPU显存容量限制
20250312-1837-3.png

LLM 的推理机制

图片展示了大型语言模型（LLM）在处理用户查询时的推理过程。整个过程分为两个主要阶段：预填充和解码。

预填充阶段 ： 用户提出问题：“今天是星期几？”。 LLM 进行第一次迭代，准备开始生成回答。

解码阶段 ： LLM 进行多次迭代，每次迭代都会从 KV 缓存中获取信息并生成一个词。 第二次迭代输出“Today”。 第三次迭代输出“is”。 第四次迭代输出“Friday”，完成回答。 最后，迭代结束，生成完整的回答：“Today is Friday”。

这个过程展示了 LLM 如何逐步构建答案，并通过缓存机制提高效率。

这其中有两个表征模型输出体验的参数：首Token时延（TTFT，Time To First Token） 和 Token 输出时延（TBT，Time Between Tokens）

参数意义

平衡性能与用户体验 ：

  • TTFT 和 TBT 共同决定了用户从提问到获得完整回答的整体体验。优化这两个参数可以提升系统的响应速度和流畅性。
  • 例如，在聊天机器人中，短 TTFT 让用户快速看到第一个词，而短 TBT 则确保后续内容迅速跟上，避免卡顿感。 硬件与算法优化的目标 ：
  • 硬件加速（如 GPU/TPU）和算法优化（如 KV 缓存、并行计算）通常会针对 TTFT 和 TBT 进行专门设计，以提高推理效率。
  • 通过分析 TTFT 和 TBT，开发者可以识别性能瓶颈并进行针对性优化。
20250312-1837-4.png

LLM 推理：延迟

任务

TTFT（首令牌时延）

TBT（令牌之间的时延）

程序（约1k个令牌）

低（~100ms）

非常低（~50ms）

网络搜索（约8k个令牌）

高（~1s）

匹配读取速度（~100ms）

多文档摘要（约128k个令牌）

非常高（>5s）

匹配读取速度（~100ms）

图片展示了不同任务在使用大型语言模型（LLM）进行推理时的延迟情况，主要关注两个关键时间参数：TTFT（到第一个令牌的时间）和TBT（令牌之间的时间）。

通过对比不同任务的TTFT和TBT，可以看出任务的复杂度和令牌数量对延迟的影响。对于简单的任务如程序生成，延迟较低；而对于复杂的任务如多文档摘要，延迟显著增加。这表明在实际应用中，需要根据任务的特点来优化LLM的性能，以提高用户体验和效率。

TBT时延在不同场景中差距不明显，而TTFT表现出显著差异。

20250312-1837-5.png

在线 LLM 服务系统

图片展示了在线大型语言模型（LLM）服务系统的架构。整个系统分为两个主要部分：指挥器（Conductor）和多个模型实例（Model Instance）。

  1. 指挥器（Conductor） ：
    • 网关（Gateway） ：负责接收外部的 API 请求。
    • 分发器（Dispatcher） ：将请求分发到合适的模型实例进行处理。
    • 监控器（Monitor） ：监控系统的运行状态，确保服务的稳定性和性能。
  2. 模型实例（Model Instance） ：
    • 每个模型实例包含一个或多个 GPU，用于并行处理任务。
    • 批处理过程（Batch process） ：每个模型实例执行批处理操作，分为两个阶段：
      • 预填充（Prefill） ：准备模型的初始状态，为生成响应做准备。
      • 解码（Decode） ：逐步生成响应，直到完成。
  3. 数据流 ：
    • API 请求 ：从外部进入系统，通过网关传递给指挥器。
    • 流式输出 ：模型实例生成的响应以流式方式返回给用户。

这个架构设计旨在高效地处理大量并发请求，通过批处理和并行计算提高性能，并通过指挥器实现请求的合理调度和系统监控，确保服务的稳定性和可靠性。

理解模型推理过程的 预填充和 解码

在模型推理过程中，通常可以分为两个主要阶段：预填充（Pre-filling）和解码（Decoding）。

1. 预填充（Pre-filling）

预填充阶段是指在生成模型进行推理之前，对模型的输入进行一定的处理。通常，这一过程涉及将输入数据传递给模型，模型通过执行一部分计算来初始化必要的状态或缓存，以便后续生成。具体来说，预填充过程可能包括：

  • 输入准备：将输入数据（如文本、图像等）转换为模型可以处理的格式。例如，在自然语言处理模型中，这包括将文本转换为token（如字或子词）并生成嵌入表示。
  • 缓存构建：对于一些依赖历史数据的模型（如自回归模型或Transformer），预填充还可能包括计算并缓存中间结果或隐藏状态（例如KVCache），以便快速地在解码过程中调用，减少重复计算。
  • 模型状态初始化：对于循环神经网络（RNN）、Transformer等模型，预填充阶段通常涉及初始化模型内部状态，以便能够根据输入进行后续的推理。

2. 解码（Decoding）

解码阶段是指模型在接收到输入并初始化状态之后，根据模型内部的状态和先前生成的输出（如果有）逐步生成最终结果。解码通常是一个逐步的过程，可能涉及以下几个步骤：

  • 生成输出：在每个时间步，模型根据当前的输入、历史上下文以及内部状态生成当前的输出。这个过程通常是递归的（即每次生成一个token后，会将其作为下一个步骤的输入）。
  • 采样策略：解码过程中，模型通常会使用某种采样策略来选择输出。常见的策略包括：
    • 贪婪解码（Greedy Decoding）：每一步选择概率最高的token作为输出。
    • 束搜索（Beam Search）：保持多个候选解，并选择最优的组合。
    • 温度采样（Temperature Sampling）：通过调整概率分布的“温度”来控制输出的多样性。
    • Top-k采样：从概率最高的k个token中随机选择。
  • 生成结束标志：解码通常会持续进行，直到生成一个结束标志（如[EOS]标记），表示输出已完成。

总结来说，预填充阶段侧重于处理和准备输入数据，并初始化模型状态或缓存，而解码阶段则是模型根据准备好的信息生成最终输出的过程。两者共同作用，以实现高效且准确的推理。

20250312-1837-6.png

图片介绍了由 Moonshot AI 提供的名为 Kimi 的在线大型语言模型（LLM）服务系统。该系统具有以下特点：

  1. 高处理能力 ：每日能够处理超过 1000 亿个令牌，表明其强大的计算和处理能力。
  2. 实时响应 ：系统能够提供实时响应，确保用户在短时间内获得结果，适用于需要快速反馈的应用场景。
  3. 长上下文支持 ：支持最多 100 万个令牌的上下文，这意味着系统可以理解和处理非常长的文本序列，这对于需要深入理解复杂信息的任务非常重要。

此外，图片还强调了“更多数据 + 更大模型 + 更长上下文 = 更高智能”的理念，说明通过增加数据量、扩大模型规模和延长上下文长度，可以显著提升系统的智能水平和性能。

20250312-1837-7.png

图片讨论了在线大型语言模型（LLM）服务系统在追求更高智能时所面临的挑战。

  1. 追求更高智能 ：
    • 通过增加更多的数据、使用更大的模型和处理更长的上下文，可以显著提升系统的智能水平。这通常意味着更好的理解和生成能力，能够处理更复杂和多样化的任务。
  2. 面临的挑战 ：
    • GPU 供应不足 ：高性能 GPU 是运行大型语言模型的关键资源，但目前市场上可能存在供应不足的问题，限制了系统的扩展和应用。
    • 更高的推理成本 ：随着模型规模的增大和数据量的增加，推理过程所需的计算资源和成本也会相应提高，增加了运营成本。
    • 更长的响应时间 ：处理大量数据和复杂模型需要更多的时间，导致响应时间变长，可能影响用户体验和实时性要求较高的应用场景。
20250312-1837-8.png

Question

如何降低超长文本 LLM 推理过程的成本？

20250312-1837-17.png

LLM 推理优化：KV缓存复用

图片展示了大型语言模型（LLM）推理过程中的一种优化技术——前缀缓存（Prefix Caching），并具体说明了如何通过 KV 缓存重用来减少计算量。

  1. 请求 I 的预填充 ：
    • 用户询问：“今天是星期几？”。
    • 系统需要计算并存储每个词（What, day, is, it, today）对应的 KV 缓存值，共计算了5个令牌。
  2. KV 缓存重用 ：
    • 当用户再次询问类似的问题时，如果前缀部分相同，则可以重用之前计算好的 KV 缓存。
    • 例如，当用户询问“明天是星期几？”时，前缀部分“What day is it”与之前的请求相同。
  3. 请求 II 的预填充 ：
    • 由于前缀部分已经存在于缓存中，系统只需要计算新的部分（tomorrow），因此只计算了1个令牌。

通过这种方式，前缀缓存技术显著减少了重复计算，提高了 LLM 在处理相似请求时的效率和响应速度。这种优化方法特别适用于需要频繁处理大量相似查询的场景，能够有效提升系统的整体性能。

20250312-1837-10.png

图片展示了对前缀缓存技术在不同场景下的效果进行的轨迹分析。图表显示了不同类型的请求（会话、工具&代理、合成和全部）在不同缓存容量下的缓存命中率。

  1. 数据来源 ：
    • 会话 ：从真实世界的在线会话请求中收集。
    • 工具&代理 ：从包含工具使用的现实世界在线请求中收集。
    • 合成 ：从公开可用的长上下文数据集中合成。
  2. 缓存命中率 ：
    • 随着缓存容量的增加，各种类型请求的缓存命中率逐渐上升。
    • 在缓存容量达到一定规模后，缓存命中率趋于稳定。
    • 具体数值如下：
      • 会话 ：最高可达 41%。
      • 工具&代理 ：最高可达 48%。
      • 合成 ：最高可达 75%。
      • 全部 ：最高可达 46%。
  3. 结论 ：
    • 约 50% 的实际工作负载中的令牌 KV 缓存可以被重用，表明前缀缓存技术在实际应用中有较高的效率和潜力。
    • 不同类型的请求在缓存命中率上存在差异，需要根据具体场景进行优化。

通过这些分析，可以看出前缀缓存虽然不是万能的解决方案，但在特定条件下能够显著提高缓存利用率，减少计算开销，提升系统性能。

20250312-1837-11.png

如果仅依赖本地缓存（约 3M 个令牌），缓存命中率将显著下降，说明需要结合其他缓存策略来进一步提升性能。

对本地缓存的思考与认识

这里的“本地缓存”更可能指的是 GPU 的 HBM ，而不是 CPU 的 DRAM。原因是：

  • GPU 的 HBM 是 LLM 推理中存储 KV 缓存的主要位置。
  • GPU 的 HBM 容量有限（通常在 40GB 到 80GB 之间），可能导致只能缓存约 3M 个令牌。
  • 使用 CPU 的 DRAM 会导致访问延迟过高，不符合 LLM 推理对高性能的需求。

不过，需要注意的是，实际系统设计中可能会结合 GPU HBM 和 CPU DRAM 来实现分层缓存策略。例如：

  • 高频访问的缓存数据存储在 GPU 的 HBM 中。
  • 较低频访问的缓存数据存储在 CPU 的 DRAM 或其他存储设备中（如 NVMe SSD）。

这种分层策略可以在容量和性能之间取得平衡，但核心瓶颈仍然在于 GPU 的 HBM。

20250312-1837-12.png

KVCache：对存储系统的巨大挑战

图片展示了大型语言模型（LLM）中 KV 缓存（Key-Value Cache）对存储系统带来的巨大挑战。

  1. KV 缓存的大小 ：
    • 每个令牌的 KV 缓存大小非常大，通常为数十 KB。
    • 这意味着在处理长序列时，缓存所需的总存储空间会迅速增加。
  2. 具体示例 ：
    • 图中以 LLaMA3-70B 模型为例，展示了不同序列长度对应的 KV 缓存大小。
    • 随着序列长度的增加，KV 缓存所需的空间呈线性增长，这对存储系统提出了极高的要求。

这种巨大的存储需求不仅增加了硬件成本，还可能限制了模型在实际应用中的性能和扩展性。因此，如何有效管理和优化 KV 缓存成为了一个重要的研究方向。

20250312-1837-13.png

图片强调了 KV 缓存（Key-Value Cache）在大型语言模型（LLM）推理过程中对存储系统带来的巨大挑战，特别是对传输带宽的要求。

  1. 高传输带宽需求 ：
    • 为了确保 GPU 不会因为数据传输延迟而停滞，需要提供足够的传输带宽。
    • 具体要求如下：
      • 对于 A800 GPU，需要至少 6 GB/s 的传输带宽。
      • 对于 H800 GPU，需要至少 19 GB/s 的传输带宽。
  2. 重要性 ：
    • 如果传输带宽不足，GPU 可能会因为等待数据而停滞，导致整体性能下降。
    • 因此，设计高效的存储和传输系统是提升 LLM 推理性能的关键。
20250312-1837-14.png

用存储资源降低计算需求

图片展示了在大型语言模型（LLM）推理过程中，通过增加存储资源来减少计算资源的需求，从而优化系统性能的三个关键要求。

  1. 大容量 KV 缓存存储 ：
    • 需要足够的存储空间来存放大量的 KV 缓存数据。由于每个令牌的 KV 缓存大小较大，并且随着序列长度线性增加，因此需要大容量的存储系统来满足需求。
  2. 低延迟和高带宽的 KV 缓存传输 ：
    • 在处理大规模 KV 缓存时，需要确保数据传输的低延迟和高带宽，以避免 GPU 因等待数据而停滞。例如，A800 GPU 需要至少 6 GB/s 的传输带宽，而 H800 GPU 需要至少 19 GB/s 的传输带宽。
  3. KV 缓存感知调度 ：
    • 为了进一步优化系统性能，需要设计一种 KV 缓存感知的调度策略。这种策略可以根据缓存的使用情况动态调整任务的执行顺序和资源分配，以提高整体效率和响应速度。

通过满足这三个要求，可以在不牺牲性能的前提下，用更多的存储资源换取更少的计算资源，从而实现系统的高效运行。

20250312-1837-15.png

提出：以 KV缓存为核心的 推理优化架构。

20250312-1837-16.png

以KV缓存为中心的解耦架构

图片展示了 Mooncake，一种以 KV 缓存为中心的解耦架构，旨在通过分布式 KV 缓存池（Mooncake Store）来优化大型语言模型（LLM）推理过程中的性能和资源利用。

  1. 架构概述 ：
    • KV 缓存中心调度器（KVCache-centric Conductor） ：
      • 包含缓存感知预填充调度器、KV 缓存平衡调度器和负载均衡解码调度器。
    • 预填充实例（Prefill Instance） 和 解码实例（Decoding Instance） ：
      • 每个实例包含 GPU/VRAM、本地分块预填充调度器、分页 KV 缓存和 CPU/DRAM/SSD。
    • 分布式 KV 缓存池（Distributed KVCache Pool） ：
      • 存储在 CPU/DRAM/SSD 中，通过 RDMA 进行高速数据传输。
  2. 预填充阶段优化目标 ：
    • 通过最大化缓存重用，减少计算开销和延迟。
    • 约束条件包括 TTFT SLO、MFU 下限和确保 KV 缓存占用小于 DRAM 容量。
  3. 解码阶段优化目标 ：
    • 通过最大化吞吐量，提高系统的处理能力。
    • 约束条件包括 TBT SLO 和确保 KV 缓存占用小于 VRAM 容量。
  4. KV 缓存传输引擎（KVCache Transfer Engine） ：
    • 通过 RDMA 技术实现高效的数据传输，确保预填充和解码阶段之间的数据交换快速且低延迟。

这种架构设计通过将 KV 缓存作为核心组件进行解耦和优化，能够有效应对大规模 LLM 推理中的存储和计算挑战，提升整体系统性能和资源利用率。

20250312-1837-18.png

预填充&解码（P&D） 解耦推理

图片介绍了 P&D 解耦推理方法，旨在优化大型语言模型（LLM）的推理过程，通过避免预填充和解码之间的干扰，并解耦资源和并行性来提高模型浮点利用率（MFU）。

  1. 避免干扰 ：
    • 在混合批次中，预填充和解码操作可能会相互干扰，导致性能下降。P&D 解耦方法通过将这两个阶段分开处理，避免了这种干扰。
  2. 提高 MFU ：
    • 通过解耦资源和并行性，可以更有效地利用计算资源，提高模型浮点利用率（MFU），从而提升整体性能。
  3. TBT vs. MFU 取舍 ：（左图）
    • 图中展示了不同策略对 TBT（令牌之间的时间）和 MFU 的影响。
      • 分块预填充 ：TBT 较高，MFU 较低。
      • 预填充优先 ：TBT 较高，MFU 较低。
      • 解码优先 ：TBT 较低，MFU 较高。
      • P&D 解耦 ：TBT 和 MFU 均表现较好。
  4. 具体实现 ：（右图）
    • 预填充实例 ：
      • s1: KV 缓存重用，减少重复计算。
      • s2: 增量预填充，逐步构建缓存。
      • s3: KV 缓存传输，确保数据在不同组件间高效传递。
      • 层级加载和存储，优化内存访问模式。
    • 解码实例 ：
      • s4: 解码，生成最终结果。
      • 异步加载，提高数据读取效率。

通过这些优化措施，P&D 解耦推理方法能够在保证低延迟的同时，最大化计算资源的利用率，适用于大规模 LLM 推理场景。

20250312-1837-20.png

Mooncake Store - 分布式多层KV缓存池

图片介绍了 Mooncake 存储系统，这是一种用于大型语言模型（LLM）推理的分布式多层 KV 缓存池。

  1. 大容量和带宽 ：
    • 分布式 KV 缓存池 ：在所有推理节点之间分布 KV 缓存，以提供足够的存储空间。
    • 高性能连接 ：利用 GPUDirect、RDMA 和存储等技术，确保高速数据传输。
    • 多 NIC 场景优化 ：针对多网络接口卡（NIC）场景进行优化，提高系统的整体性能。
  2. 设计特点 ：
    • 高可扩展性和容错性 ：系统设计支持大规模扩展，并具备良好的容错能力，确保在节点故障时仍能正常运行。
    • 独立于特定推理引擎 ：不依赖于特定的推理引擎，具有较强的通用性和灵活性。
    • 灵活的 API ：提供了灵活的 API 接口，已被 vLLM 项目采用，方便与其他系统集成和使用。

通过这些设计特点，Mooncake 存储系统能够有效应对 LLM 推理过程中对存储和带宽的高要求，提升系统的整体性能和可靠性。

Note

预填充和解码是推理过程的两个重要环节，处理的都是用户即时提问的热数据，这些数据在完成推理后，并不会立即丢弃，而是半持久化保留在KV缓存池中。

20250312-1837.gif

KV缓存管理机制

图片介绍了 Mooncake 存储系统中的 KV 缓存管理机制，主要包括以下内容：

  1. 前缀哈希 KV 缓存对象存储 ：
    • 使用哈希函数对预填充数据进行处理，生成哈希值作为缓存键。
    • 例如，对于序列 "a, b, c, d, e, f"，生成的哈希值为 A=Hash(a), B=Hash(A+b), C=Hash(B+c) 等。
  2. LRU 淘汰策略 ：
    • 当缓存空间不足时，采用 LRU（最近最少使用）策略淘汰最久未使用的缓存项，以释放空间。
  3. 缓存块类型 ：
    • 前缀缓存块 ：存储预填充的缓存数据。
    • 增量缓存块 ：存储新增部分的缓存数据。
    • 未分配缓存块 ：尚未分配给任何数据的缓存空间。
  4. 操作流程 ：
    • Put() ：将新数据放入缓存，并根据哈希值确定存储位置。
    • Get() ：从缓存中获取数据，通过哈希值快速定位。
    • Transfer ：在预填充实例和解码实例之间传输数据，确保数据的一致性和高效利用。

通过这些机制，Mooncake 存储系统能够高效地管理和利用缓存资源，提升大型语言模型（LLM）推理过程中的性能和效率。

20250312-1837-21.png

传输引擎

图片介绍了 Mooncake 存储系统中的传输引擎及其关键技术。

  1. 关键技术 ：
    • 零拷贝 ：减少数据在内存中的复制次数，提高传输效率。
    • 多 NIC ：支持最多 8 个 400Gbps 的网络接口卡（NIC），提供高达 3.2Tbps 的聚合带宽。
    • 拓扑感知 ：根据网络拓扑结构优化数据传输路径。
    • 故障恢复 ：具备故障检测和自动恢复机制，确保系统的高可用性。
    • 负载均衡 ：动态调整数据流，避免单点过载。
    • 多传输支持 ：兼容多种传输协议，提供灵活的通信方式。
  2. 性能对比 ：
    • 在不同缓存大小下，传输引擎相比 TCP 和 Gloo 显示出显著的性能优势。例如，在使用 4 个 200Gbps NIC 时，传输引擎比 TCP 快 7.5 倍；在使用 8 个 400Gbps NIC 时，传输引擎比 TCP 快 16.2 倍。
    • 更大出口的交换机网络，表现出更优时延效果。
  3. 系统架构 ：
    • 从推理引擎到裸金属层，传输引擎在整个数据传输过程中起到关键作用，通过 BatchTransfer API 实现高效的数据读写操作。
  4. 优势 ：
    • 更好地利用多个高性能 NIC ：充分发挥多 NIC 的带宽优势，提升整体传输性能。
    • 更灵活，无需构建进程组 ：简化了系统设计，提高了灵活性和可扩展性。

通过这些技术和优化措施，Mooncake 存储系统能够实现高效、可靠的数据传输，满足大规模 LLM 推理场景的需求。

关于 Gloo 高性能通信库

“Gloo”是指 Facebook 开源的一个高性能通信库，主要用于分布式机器学习和深度学习任务中的数据传输和同步。它被设计用于高效地处理大规模并行计算中的通信需求。

Gloo 的主要特点

  1. 多传输协议支持 ：
    • Gloo 支持多种底层传输协议，包括 TCP、UDP、RDMA 等，可以根据不同的网络环境和硬件配置选择最合适的传输方式。
    • 这使得 Gloo 能够在不同类型的网络拓扑和硬件平台上提供一致且高效的通信性能。
  2. 集体通信原语 ：
    • Gloo 提供了丰富的集体通信原语（如 AllReduce、Broadcast、AllGather 等），这些原语是分布式训练中常用的操作。
    • 通过优化这些原语的实现，Gloo 可以显著提高分布式训练的效率和速度。
  3. 灵活的组管理 ：
    • Gloo 允许用户动态创建和管理进程组，方便进行细粒度的通信控制。
    • 用户可以根据实际需求灵活地组织和调整进程组，以适应不同的应用场景。
  4. 高可扩展性 ：
    • Gloo 被设计为高度可扩展的通信库，能够支持大规模分布式系统的通信需求。
    • 它可以有效地管理大量的节点和进程，确保在大规模集群中也能保持良好的通信性能。
  5. 易于集成 ：
    • Gloo 提供了简单易用的 API 接口，方便与其他框架和系统进行集成。
    • 许多流行的深度学习框架（如 PyTorch）已经集成了 Gloo，用户可以直接使用其提供的通信功能。

值得一提的是：图中Gloo 通信库的时延较TCP明显高出，与高性能通信库不太匹配，可能是Gloo本身在特定场景就表现出低性能，也有可能是与TCP的时延数据颠倒了。

20250312-1837-22.png

Mooncake 与南北向的集成

图片展示了 Mooncake 存储系统如何与外部组件进行集成，以支持大型语言模型（LLM）的推理和训练。

  1. LLM 引擎 ：
    • 支持 vLLM 和其他推理引擎。
    • 支持 Megatron 等训练框架。
  2. Mooncake 存储 ：
    • Managed Store（主从模式） ：提供零拷贝对象存取功能，用于高效的数据读写操作。
    • P2P Store（仅客户端） ：支持点对点数据传输，适用于特定场景下的数据交换。
  3. Mooncake 存储批处理传输 API ：
    • 通过 Mooncake Transfer Engine 实现高效的数据传输和管理。
  4. 存储资源 ：
    • 裸金属存储资源 ：包括 NUMA 节点、本地内存、远程内存（远程 SSD）、RDMA、NVMe over Fabrics 和 CXL 计算 Express 链接等，提供高性能的存储和计算能力。
    • 第三方内存存储 ：支持与其他第三方内存存储系统的集成，扩展存储容量和灵活性。

通过这些组件的协同工作，Mooncake 存储系统能够为 LLM 的推理和训练提供高效、灵活和可扩展的存储解决方案。

关于 Megatron 训练框架

什么是 Megatron？

Megatron[1] 是由 NVIDIA 开发的一个开源深度学习框架，专门用于训练超大规模的语言模型（LLM）。它以高效、可扩展的方式支持分布式训练，能够处理数十亿甚至数千亿参数的模型。

Megatron 的核心特点包括：

  • 模型并行化 ：将模型拆分为多个部分，分配到不同的 GPU 上进行计算。
    • 张量并行（Tensor Parallelism） ：将矩阵运算分解为更小的部分，在多个 GPU 上并行执行。
    • 流水线并行（Pipeline Parallelism） ：将模型的不同层分配到不同的 GPU 上，形成流水线式计算。
    • 数据并行（Data Parallelism） ：将输入数据分片，分配到不同的 GPU 上进行独立计算。
  • 高效的通信机制 ：通过优化的通信原语（如 AllReduce、Broadcast 等），减少分布式训练中的通信开销。
  • 混合精度训练 ：利用 FP16 或 BF16 数据格式进行计算，以提高训练速度和显存利用率。
  • 灵活的扩展性 ：支持从单节点多 GPU 到多节点集群的大规模扩展。

Megatron 是目前训练超大规模语言模型的核心工具之一，被广泛应用于学术界和工业界。

20250312-1837-23.png

评估目标

  1. Mooncake是否在实际场景中优于现有的LLM推理系统？
  2. 与传统的预填充缓存方法相比，Mooncake Store的设计是否显著提高了Mooncake的性能？

Kimi的在线统计数据

  • Mooncake使Kimi在A800和H800集群上分别能够处理比我们基于vLLM的先前系统多出115%和107%的请求。
20250312-1837-24.png

评估方法

  • 使用 Dummy LLaMA3-70B 模型进行测试。
  • 配置 16 个节点，每个节点配备 8 个 A800 GPU 和 4 个 200 Gbps RDMA NICs。
  • 以 vLLM 为基准线，采用前缀缓存和分块预填充策略。
  • 使用三种真实或合成轨迹作为工作负载，模拟在线服务的实际请求分布。
  • 通过有效请求容量和 GPU 成本两个指标进行评估。
20250312-1837-25.png

评估结果

图片展示了用于评估 Mooncake 系统性能的三种不同类型的工作负载，包括对话、工具&代理和合成数据。每种类型的数据具有不同的特征，具体如下：

  1. 对话 ：
    • 平均输入长度 ：12035 个令牌
    • 平均输出长度 ：343 个令牌
    • 缓存比率 ：40%
    • 到达模式 ：基于时间戳
    • 请求数量 ：12031 个
  2. 工具&代理 ：
    • 平均输入长度 ：8596 个令牌
    • 平均输出长度 ：182 个令牌
    • 缓存比率 ：59%
    • 到达模式 ：基于时间戳
    • 请求数量 ：23608 个
  3. 合成 ：
    • 平均输入长度 ：15325 个令牌
    • 平均输出长度 ：149 个令牌
    • 缓存比率 ：66%
    • 到达模式 ：泊松分布
    • 请求数量 ：3993 个

这些数据集涵盖了不同场景下的实际请求和合成请求，能够全面评估 Mooncake 系统在不同条件下的性能表现。通过对比不同数据集的特征，可以更准确地分析系统的优劣和适用范围。

20250312-1837-26.png

关键发现

  • 缓存命中率 ：全局缓存（global cache）的命中率高于本地缓存（local cache）。
  • 节省 GPU 计算成本 ：在不同场景下，Mooncake 能够节省 29% 到 61% 的 GPU 计算成本。
图表分析

图表展示了四种方法在三种不同工作负载（对话、工具&代理、合成）下的预填充 GPU 时间对比：

  1. Mooncake （蓝色条形图）
    • 在所有场景中表现最优，显著减少了 GPU 计算时间。
    • 相比其他方法，能够更有效地利用缓存，降低计算开销。
  2. vLLM Prefix Caching （红色条形图）
    • 使用前缀缓存技术，相比 vLLM 基线有明显改进，但在某些场景下仍不如 Mooncake。
  3. vLLM （绿色条形图）
    • 基准线方法，没有使用任何缓存优化策略，计算时间最长。
  4. vLLM Chunked Prefill （黄色条形图）
    • 使用分块预填充技术，比 vLLM 恶化，性能最差。
20250312-1837-27.png

与vLLM集成的路标

图片展示了 Mooncake Store 与 vLLM 集成的路线图，分为两个阶段：

  1. 第一阶段 ：实现了对单个预填充和解码实例的支持，并已成功合并到 vLLM 项目中。
  2. 第二阶段 ：正在开发中，目标是支持任意数量的预填充和解码实例，利用 Mooncake 的分布式 KV 缓存池实现更灵活和高效的解耦推理。

通过这些步骤，Mooncake Store 将能够更好地支持大规模 LLM 推理任务，提升系统的性能和可扩展性。

20250312-1837-28.png

总结

部署系统：Mooncake

  • 用更多存储换取更少计算 ：通过增加存储资源，减少计算开销，提高整体效率。
  • 以 KV 缓存为中心的 LLM 服务架构 ：设计了一种以 KV 缓存为核心的架构，旨在提升大型语言模型（LLM）服务的吞吐量。

基础设施：Mooncake 存储

  • 快速、可扩展且容错的 KV 缓存存储和传输引擎 ：Mooncake 存储提供高效、灵活和可靠的 KV 缓存管理能力，支持大规模 LLM 推理任务。

Mooncake 存储的优势

  • 高效的 P&D 解耦 ：通过解耦预填充和解码阶段，避免两者之间的干扰，提高系统的并行处理能力和性能。
  • 更多的 KV 缓存重用 ：通过优化缓存策略，提高 KV 缓存的利用率，减少重复计算，进一步提升推理效率。
  • 灵活的 KV 缓存调度 ：支持灵活的缓存调度机制，能够根据实际需求动态调整缓存分配，确保资源的有效利用。

延伸思考

这次分享的内容就到这里了，或许以下几个问题，能够启发你更多的思考，欢迎留言，说说你的想法~

  1. 当KV缓存命中率超过50%后，继续提升存储容量的边际效益会呈现何种变化趋势？
  2. 在量子计算时代，现有基于RDMA的缓存传输架构需要哪些根本性改造？
  3. 如何设计自适应的缓存分层策略，使系统在对话场景与工具场景间自动切换最优配置？

原文标题：Trading More Storage for Less Computation –A KVCache-centric Architecture for Serving LLM Chatbot

本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。原始发表：2025-03-14，如有侵权请联系 cloudcommunity@tencent 删除模型效率LLM存储缓存

月之暗面：存储换算，倍增LLM推理效率

在AI大模型时代，用户对实时交互体验的要求与日俱增。大型语言模型（LLM）的推理延迟成为制约用户体验的核心痛点，其关键参数TTFT（首Token时延）和TBT（令牌间时延）直接决定着对话流畅度。传统系统在处理长上下文查询时面临三大困境：GPU算力不足、缓存复用率低、存储带宽瓶颈。

本文聚焦Moonshot AI提出的Mooncake架构，通过存储资源重构实现计算效率跃迁。该方案以KV缓存为中心，构建分布式存储池，将缓存容量从GPU HBM的3M令牌扩展至全集群级别，配合零拷贝传输引擎和LRU淘汰策略，成功将A800集群的请求处理能力提升115%。这项创新不仅重新定义了LLM服务架构范式，更揭示了存储与计算资源动态平衡的底层逻辑。

Moonshot：存储换算，倍增LLM推理效率-2.png

阅读收获

  1. 掌握LLM推理延迟的量化评估体系（TTFT/TBT指标）
  2. 理解存储-计算资源动态平衡的工程实现路径
  3. 获取分布式KV缓存池设计的三大关键技术：哈希分片、LRU淘汰、零拷贝传输
  4. 看懂Mooncake架构如何突破GPU显存容量限制
20250312-1837-3.png

LLM 的推理机制

图片展示了大型语言模型（LLM）在处理用户查询时的推理过程。整个过程分为两个主要阶段：预填充和解码。

预填充阶段 ： 用户提出问题：“今天是星期几？”。 LLM 进行第一次迭代，准备开始生成回答。

解码阶段 ： LLM 进行多次迭代，每次迭代都会从 KV 缓存中获取信息并生成一个词。 第二次迭代输出“Today”。 第三次迭代输出“is”。 第四次迭代输出“Friday”，完成回答。 最后，迭代结束，生成完整的回答：“Today is Friday”。

这个过程展示了 LLM 如何逐步构建答案，并通过缓存机制提高效率。

这其中有两个表征模型输出体验的参数：首Token时延（TTFT，Time To First Token） 和 Token 输出时延（TBT，Time Between Tokens）

参数意义

平衡性能与用户体验 ：

  • TTFT 和 TBT 共同决定了用户从提问到获得完整回答的整体体验。优化这两个参数可以提升系统的响应速度和流畅性。
  • 例如，在聊天机器人中，短 TTFT 让用户快速看到第一个词，而短 TBT 则确保后续内容迅速跟上，避免卡顿感。 硬件与算法优化的目标 ：
  • 硬件加速（如 GPU/TPU）和算法优化（如 KV 缓存、并行计算）通常会针对 TTFT 和 TBT 进行专门设计，以提高推理效率。
  • 通过分析 TTFT 和 TBT，开发者可以识别性能瓶颈并进行针对性优化。
20250312-1837-4.png

LLM 推理：延迟

任务

TTFT（首令牌时延）

TBT（令牌之间的时延）

程序（约1k个令牌）

低（~100ms）

非常低（~50ms）

网络搜索（约8k个令牌）

高（~1s）

匹配读取速度（~100ms）

多文档摘要（约128k个令牌）

非常高（>5s）

匹配读取速度（~100ms）

图片展示了不同任务在使用大型语言模型（LLM）进行推理时的延迟情况，主要关注两个关键时间参数：TTFT（到第一个令牌的时间）和TBT（令牌之间的时间）。

通过对比不同任务的TTFT和TBT，可以看出任务的复杂度和令牌数量对延迟的影响。对于简单的任务如程序生成，延迟较低；而对于复杂的任务如多文档摘要，延迟显著增加。这表明在实际应用中，需要根据任务的特点来优化LLM的性能，以提高用户体验和效率。

TBT时延在不同场景中差距不明显，而TTFT表现出显著差异。

20250312-1837-5.png

在线 LLM 服务系统

图片展示了在线大型语言模型（LLM）服务系统的架构。整个系统分为两个主要部分：指挥器（Conductor）和多个模型实例（Model Instance）。

  1. 指挥器（Conductor） ：
    • 网关（Gateway） ：负责接收外部的 API 请求。
    • 分发器（Dispatcher） ：将请求分发到合适的模型实例进行处理。
    • 监控器（Monitor） ：监控系统的运行状态，确保服务的稳定性和性能。
  2. 模型实例（Model Instance） ：
    • 每个模型实例包含一个或多个 GPU，用于并行处理任务。
    • 批处理过程（Batch process） ：每个模型实例执行批处理操作，分为两个阶段：
      • 预填充（Prefill） ：准备模型的初始状态，为生成响应做准备。
      • 解码（Decode） ：逐步生成响应，直到完成。
  3. 数据流 ：
    • API 请求 ：从外部进入系统，通过网关传递给指挥器。
    • 流式输出 ：模型实例生成的响应以流式方式返回给用户。

这个架构设计旨在高效地处理大量并发请求，通过批处理和并行计算提高性能，并通过指挥器实现请求的合理调度和系统监控，确保服务的稳定性和可靠性。

理解模型推理过程的 预填充和 解码

在模型推理过程中，通常可以分为两个主要阶段：预填充（Pre-filling）和解码（Decoding）。

1. 预填充（Pre-filling）

预填充阶段是指在生成模型进行推理之前，对模型的输入进行一定的处理。通常，这一过程涉及将输入数据传递给模型，模型通过执行一部分计算来初始化必要的状态或缓存，以便后续生成。具体来说，预填充过程可能包括：

  • 输入准备：将输入数据（如文本、图像等）转换为模型可以处理的格式。例如，在自然语言处理模型中，这包括将文本转换为token（如字或子词）并生成嵌入表示。
  • 缓存构建：对于一些依赖历史数据的模型（如自回归模型或Transformer），预填充还可能包括计算并缓存中间结果或隐藏状态（例如KVCache），以便快速地在解码过程中调用，减少重复计算。
  • 模型状态初始化：对于循环神经网络（RNN）、Transformer等模型，预填充阶段通常涉及初始化模型内部状态，以便能够根据输入进行后续的推理。

2. 解码（Decoding）

解码阶段是指模型在接收到输入并初始化状态之后，根据模型内部的状态和先前生成的输出（如果有）逐步生成最终结果。解码通常是一个逐步的过程，可能涉及以下几个步骤：

  • 生成输出：在每个时间步，模型根据当前的输入、历史上下文以及内部状态生成当前的输出。这个过程通常是递归的（即每次生成一个token后，会将其作为下一个步骤的输入）。
  • 采样策略：解码过程中，模型通常会使用某种采样策略来选择输出。常见的策略包括：
    • 贪婪解码（Greedy Decoding）：每一步选择概率最高的token作为输出。
    • 束搜索（Beam Search）：保持多个候选解，并选择最优的组合。
    • 温度采样（Temperature Sampling）：通过调整概率分布的“温度”来控制输出的多样性。
    • Top-k采样：从概率最高的k个token中随机选择。
  • 生成结束标志：解码通常会持续进行，直到生成一个结束标志（如[EOS]标记），表示输出已完成。

总结来说，预填充阶段侧重于处理和准备输入数据，并初始化模型状态或缓存，而解码阶段则是模型根据准备好的信息生成最终输出的过程。两者共同作用，以实现高效且准确的推理。

20250312-1837-6.png

图片介绍了由 Moonshot AI 提供的名为 Kimi 的在线大型语言模型（LLM）服务系统。该系统具有以下特点：

  1. 高处理能力 ：每日能够处理超过 1000 亿个令牌，表明其强大的计算和处理能力。
  2. 实时响应 ：系统能够提供实时响应，确保用户在短时间内获得结果，适用于需要快速反馈的应用场景。
  3. 长上下文支持 ：支持最多 100 万个令牌的上下文，这意味着系统可以理解和处理非常长的文本序列，这对于需要深入理解复杂信息的任务非常重要。

此外，图片还强调了“更多数据 + 更大模型 + 更长上下文 = 更高智能”的理念，说明通过增加数据量、扩大模型规模和延长上下文长度，可以显著提升系统的智能水平和性能。

20250312-1837-7.png

图片讨论了在线大型语言模型（LLM）服务系统在追求更高智能时所面临的挑战。

  1. 追求更高智能 ：
    • 通过增加更多的数据、使用更大的模型和处理更长的上下文，可以显著提升系统的智能水平。这通常意味着更好的理解和生成能力，能够处理更复杂和多样化的任务。
  2. 面临的挑战 ：
    • GPU 供应不足 ：高性能 GPU 是运行大型语言模型的关键资源，但目前市场上可能存在供应不足的问题，限制了系统的扩展和应用。
    • 更高的推理成本 ：随着模型规模的增大和数据量的增加，推理过程所需的计算资源和成本也会相应提高，增加了运营成本。
    • 更长的响应时间 ：处理大量数据和复杂模型需要更多的时间，导致响应时间变长，可能影响用户体验和实时性要求较高的应用场景。
20250312-1837-8.png

Question

如何降低超长文本 LLM 推理过程的成本？

20250312-1837-17.png

LLM 推理优化：KV缓存复用

图片展示了大型语言模型（LLM）推理过程中的一种优化技术——前缀缓存（Prefix Caching），并具体说明了如何通过 KV 缓存重用来减少计算量。

  1. 请求 I 的预填充 ：
    • 用户询问：“今天是星期几？”。
    • 系统需要计算并存储每个词（What, day, is, it, today）对应的 KV 缓存值，共计算了5个令牌。
  2. KV 缓存重用 ：
    • 当用户再次询问类似的问题时，如果前缀部分相同，则可以重用之前计算好的 KV 缓存。
    • 例如，当用户询问“明天是星期几？”时，前缀部分“What day is it”与之前的请求相同。
  3. 请求 II 的预填充 ：
    • 由于前缀部分已经存在于缓存中，系统只需要计算新的部分（tomorrow），因此只计算了1个令牌。

通过这种方式，前缀缓存技术显著减少了重复计算，提高了 LLM 在处理相似请求时的效率和响应速度。这种优化方法特别适用于需要频繁处理大量相似查询的场景，能够有效提升系统的整体性能。

20250312-1837-10.png

图片展示了对前缀缓存技术在不同场景下的效果进行的轨迹分析。图表显示了不同类型的请求（会话、工具&代理、合成和全部）在不同缓存容量下的缓存命中率。

  1. 数据来源 ：
    • 会话 ：从真实世界的在线会话请求中收集。
    • 工具&代理 ：从包含工具使用的现实世界在线请求中收集。
    • 合成 ：从公开可用的长上下文数据集中合成。
  2. 缓存命中率 ：
    • 随着缓存容量的增加，各种类型请求的缓存命中率逐渐上升。
    • 在缓存容量达到一定规模后，缓存命中率趋于稳定。
    • 具体数值如下：
      • 会话 ：最高可达 41%。
      • 工具&代理 ：最高可达 48%。
      • 合成 ：最高可达 75%。
      • 全部 ：最高可达 46%。
  3. 结论 ：
    • 约 50% 的实际工作负载中的令牌 KV 缓存可以被重用，表明前缀缓存技术在实际应用中有较高的效率和潜力。
    • 不同类型的请求在缓存命中率上存在差异，需要根据具体场景进行优化。

通过这些分析，可以看出前缀缓存虽然不是万能的解决方案，但在特定条件下能够显著提高缓存利用率，减少计算开销，提升系统性能。

20250312-1837-11.png

如果仅依赖本地缓存（约 3M 个令牌），缓存命中率将显著下降，说明需要结合其他缓存策略来进一步提升性能。

对本地缓存的思考与认识

这里的“本地缓存”更可能指的是 GPU 的 HBM ，而不是 CPU 的 DRAM。原因是：

  • GPU 的 HBM 是 LLM 推理中存储 KV 缓存的主要位置。
  • GPU 的 HBM 容量有限（通常在 40GB 到 80GB 之间），可能导致只能缓存约 3M 个令牌。
  • 使用 CPU 的 DRAM 会导致访问延迟过高，不符合 LLM 推理对高性能的需求。

不过，需要注意的是，实际系统设计中可能会结合 GPU HBM 和 CPU DRAM 来实现分层缓存策略。例如：

  • 高频访问的缓存数据存储在 GPU 的 HBM 中。
  • 较低频访问的缓存数据存储在 CPU 的 DRAM 或其他存储设备中（如 NVMe SSD）。

这种分层策略可以在容量和性能之间取得平衡，但核心瓶颈仍然在于 GPU 的 HBM。

20250312-1837-12.png

KVCache：对存储系统的巨大挑战

图片展示了大型语言模型（LLM）中 KV 缓存（Key-Value Cache）对存储系统带来的巨大挑战。

  1. KV 缓存的大小 ：
    • 每个令牌的 KV 缓存大小非常大，通常为数十 KB。
    • 这意味着在处理长序列时，缓存所需的总存储空间会迅速增加。
  2. 具体示例 ：
    • 图中以 LLaMA3-70B 模型为例，展示了不同序列长度对应的 KV 缓存大小。
    • 随着序列长度的增加，KV 缓存所需的空间呈线性增长，这对存储系统提出了极高的要求。

这种巨大的存储需求不仅增加了硬件成本，还可能限制了模型在实际应用中的性能和扩展性。因此，如何有效管理和优化 KV 缓存成为了一个重要的研究方向。

20250312-1837-13.png

图片强调了 KV 缓存（Key-Value Cache）在大型语言模型（LLM）推理过程中对存储系统带来的巨大挑战，特别是对传输带宽的要求。

  1. 高传输带宽需求 ：
    • 为了确保 GPU 不会因为数据传输延迟而停滞，需要提供足够的传输带宽。
    • 具体要求如下：
      • 对于 A800 GPU，需要至少 6 GB/s 的传输带宽。
      • 对于 H800 GPU，需要至少 19 GB/s 的传输带宽。
  2. 重要性 ：
    • 如果传输带宽不足，GPU 可能会因为等待数据而停滞，导致整体性能下降。
    • 因此，设计高效的存储和传输系统是提升 LLM 推理性能的关键。
20250312-1837-14.png

用存储资源降低计算需求

图片展示了在大型语言模型（LLM）推理过程中，通过增加存储资源来减少计算资源的需求，从而优化系统性能的三个关键要求。

  1. 大容量 KV 缓存存储 ：
    • 需要足够的存储空间来存放大量的 KV 缓存数据。由于每个令牌的 KV 缓存大小较大，并且随着序列长度线性增加，因此需要大容量的存储系统来满足需求。
  2. 低延迟和高带宽的 KV 缓存传输 ：
    • 在处理大规模 KV 缓存时，需要确保数据传输的低延迟和高带宽，以避免 GPU 因等待数据而停滞。例如，A800 GPU 需要至少 6 GB/s 的传输带宽，而 H800 GPU 需要至少 19 GB/s 的传输带宽。
  3. KV 缓存感知调度 ：
    • 为了进一步优化系统性能，需要设计一种 KV 缓存感知的调度策略。这种策略可以根据缓存的使用情况动态调整任务的执行顺序和资源分配，以提高整体效率和响应速度。

通过满足这三个要求，可以在不牺牲性能的前提下，用更多的存储资源换取更少的计算资源，从而实现系统的高效运行。

20250312-1837-15.png

提出：以 KV缓存为核心的 推理优化架构。

20250312-1837-16.png

以KV缓存为中心的解耦架构

图片展示了 Mooncake，一种以 KV 缓存为中心的解耦架构，旨在通过分布式 KV 缓存池（Mooncake Store）来优化大型语言模型（LLM）推理过程中的性能和资源利用。

  1. 架构概述 ：
    • KV 缓存中心调度器（KVCache-centric Conductor） ：
      • 包含缓存感知预填充调度器、KV 缓存平衡调度器和负载均衡解码调度器。
    • 预填充实例（Prefill Instance） 和 解码实例（Decoding Instance） ：
      • 每个实例包含 GPU/VRAM、本地分块预填充调度器、分页 KV 缓存和 CPU/DRAM/SSD。
    • 分布式 KV 缓存池（Distributed KVCache Pool） ：
      • 存储在 CPU/DRAM/SSD 中，通过 RDMA 进行高速数据传输。
  2. 预填充阶段优化目标 ：
    • 通过最大化缓存重用，减少计算开销和延迟。
    • 约束条件包括 TTFT SLO、MFU 下限和确保 KV 缓存占用小于 DRAM 容量。
  3. 解码阶段优化目标 ：
    • 通过最大化吞吐量，提高系统的处理能力。
    • 约束条件包括 TBT SLO 和确保 KV 缓存占用小于 VRAM 容量。
  4. KV 缓存传输引擎（KVCache Transfer Engine） ：
    • 通过 RDMA 技术实现高效的数据传输，确保预填充和解码阶段之间的数据交换快速且低延迟。

这种架构设计通过将 KV 缓存作为核心组件进行解耦和优化，能够有效应对大规模 LLM 推理中的存储和计算挑战，提升整体系统性能和资源利用率。

20250312-1837-18.png

预填充&解码（P&D） 解耦推理

图片介绍了 P&D 解耦推理方法，旨在优化大型语言模型（LLM）的推理过程，通过避免预填充和解码之间的干扰，并解耦资源和并行性来提高模型浮点利用率（MFU）。

  1. 避免干扰 ：
    • 在混合批次中，预填充和解码操作可能会相互干扰，导致性能下降。P&D 解耦方法通过将这两个阶段分开处理，避免了这种干扰。
  2. 提高 MFU ：
    • 通过解耦资源和并行性，可以更有效地利用计算资源，提高模型浮点利用率（MFU），从而提升整体性能。
  3. TBT vs. MFU 取舍 ：（左图）
    • 图中展示了不同策略对 TBT（令牌之间的时间）和 MFU 的影响。
      • 分块预填充 ：TBT 较高，MFU 较低。
      • 预填充优先 ：TBT 较高，MFU 较低。
      • 解码优先 ：TBT 较低，MFU 较高。
      • P&D 解耦 ：TBT 和 MFU 均表现较好。
  4. 具体实现 ：（右图）
    • 预填充实例 ：
      • s1: KV 缓存重用，减少重复计算。
      • s2: 增量预填充，逐步构建缓存。
      • s3: KV 缓存传输，确保数据在不同组件间高效传递。
      • 层级加载和存储，优化内存访问模式。
    • 解码实例 ：
      • s4: 解码，生成最终结果。
      • 异步加载，提高数据读取效率。

通过这些优化措施，P&D 解耦推理方法能够在保证低延迟的同时，最大化计算资源的利用率，适用于大规模 LLM 推理场景。

20250312-1837-20.png

Mooncake Store - 分布式多层KV缓存池

图片介绍了 Mooncake 存储系统，这是一种用于大型语言模型（LLM）推理的分布式多层 KV 缓存池。

  1. 大容量和带宽 ：
    • 分布式 KV 缓存池 ：在所有推理节点之间分布 KV 缓存，以提供足够的存储空间。
    • 高性能连接 ：利用 GPUDirect、RDMA 和存储等技术，确保高速数据传输。
    • 多 NIC 场景优化 ：针对多网络接口卡（NIC）场景进行优化，提高系统的整体性能。
  2. 设计特点 ：
    • 高可扩展性和容错性 ：系统设计支持大规模扩展，并具备良好的容错能力，确保在节点故障时仍能正常运行。
    • 独立于特定推理引擎 ：不依赖于特定的推理引擎，具有较强的通用性和灵活性。
    • 灵活的 API ：提供了灵活的 API 接口，已被 vLLM 项目采用，方便与其他系统集成和使用。

通过这些设计特点，Mooncake 存储系统能够有效应对 LLM 推理过程中对存储和带宽的高要求，提升系统的整体性能和可靠性。

Note

预填充和解码是推理过程的两个重要环节，处理的都是用户即时提问的热数据，这些数据在完成推理后，并不会立即丢弃，而是半持久化保留在KV缓存池中。

20250312-1837.gif

KV缓存管理机制

图片介绍了 Mooncake 存储系统中的 KV 缓存管理机制，主要包括以下内容：

  1. 前缀哈希 KV 缓存对象存储 ：
    • 使用哈希函数对预填充数据进行处理，生成哈希值作为缓存键。
    • 例如，对于序列 "a, b, c, d, e, f"，生成的哈希值为 A=Hash(a), B=Hash(A+b), C=Hash(B+c) 等。
  2. LRU 淘汰策略 ：
    • 当缓存空间不足时，采用 LRU（最近最少使用）策略淘汰最久未使用的缓存项，以释放空间。
  3. 缓存块类型 ：
    • 前缀缓存块 ：存储预填充的缓存数据。
    • 增量缓存块 ：存储新增部分的缓存数据。
    • 未分配缓存块 ：尚未分配给任何数据的缓存空间。
  4. 操作流程 ：
    • Put() ：将新数据放入缓存，并根据哈希值确定存储位置。
    • Get() ：从缓存中获取数据，通过哈希值快速定位。
    • Transfer ：在预填充实例和解码实例之间传输数据，确保数据的一致性和高效利用。

通过这些机制，Mooncake 存储系统能够高效地管理和利用缓存资源，提升大型语言模型（LLM）推理过程中的性能和效率。

20250312-1837-21.png

传输引擎

图片介绍了 Mooncake 存储系统中的传输引擎及其关键技术。

  1. 关键技术 ：
    • 零拷贝 ：减少数据在内存中的复制次数，提高传输效率。
    • 多 NIC ：支持最多 8 个 400Gbps 的网络接口卡（NIC），提供高达 3.2Tbps 的聚合带宽。
    • 拓扑感知 ：根据网络拓扑结构优化数据传输路径。
    • 故障恢复 ：具备故障检测和自动恢复机制，确保系统的高可用性。
    • 负载均衡 ：动态调整数据流，避免单点过载。
    • 多传输支持 ：兼容多种传输协议，提供灵活的通信方式。
  2. 性能对比 ：
    • 在不同缓存大小下，传输引擎相比 TCP 和 Gloo 显示出显著的性能优势。例如，在使用 4 个 200Gbps NIC 时，传输引擎比 TCP 快 7.5 倍；在使用 8 个 400Gbps NIC 时，传输引擎比 TCP 快 16.2 倍。
    • 更大出口的交换机网络，表现出更优时延效果。
  3. 系统架构 ：
    • 从推理引擎到裸金属层，传输引擎在整个数据传输过程中起到关键作用，通过 BatchTransfer API 实现高效的数据读写操作。
  4. 优势 ：
    • 更好地利用多个高性能 NIC ：充分发挥多 NIC 的带宽优势，提升整体传输性能。
    • 更灵活，无需构建进程组 ：简化了系统设计，提高了灵活性和可扩展性。

通过这些技术和优化措施，Mooncake 存储系统能够实现高效、可靠的数据传输，满足大规模 LLM 推理场景的需求。

关于 Gloo 高性能通信库

“Gloo”是指 Facebook 开源的一个高性能通信库，主要用于分布式机器学习和深度学习任务中的数据传输和同步。它被设计用于高效地处理大规模并行计算中的通信需求。

Gloo 的主要特点

  1. 多传输协议支持 ：
    • Gloo 支持多种底层传输协议，包括 TCP、UDP、RDMA 等，可以根据不同的网络环境和硬件配置选择最合适的传输方式。
    • 这使得 Gloo 能够在不同类型的网络拓扑和硬件平台上提供一致且高效的通信性能。
  2. 集体通信原语 ：
    • Gloo 提供了丰富的集体通信原语（如 AllReduce、Broadcast、AllGather 等），这些原语是分布式训练中常用的操作。
    • 通过优化这些原语的实现，Gloo 可以显著提高分布式训练的效率和速度。
  3. 灵活的组管理 ：
    • Gloo 允许用户动态创建和管理进程组，方便进行细粒度的通信控制。
    • 用户可以根据实际需求灵活地组织和调整进程组，以适应不同的应用场景。
  4. 高可扩展性 ：
    • Gloo 被设计为高度可扩展的通信库，能够支持大规模分布式系统的通信需求。
    • 它可以有效地管理大量的节点和进程，确保在大规模集群中也能保持良好的通信性能。
  5. 易于集成 ：
    • Gloo 提供了简单易用的 API 接口，方便与其他框架和系统进行集成。
    • 许多流行的深度学习框架（如 PyTorch）已经集成了 Gloo，用户可以直接使用其提供的通信功能。

值得一提的是：图中Gloo 通信库的时延较TCP明显高出，与高性能通信库不太匹配，可能是Gloo本身在特定场景就表现出低性能，也有可能是与TCP的时延数据颠倒了。

20250312-1837-22.png

Mooncake 与南北向的集成

图片展示了 Mooncake 存储系统如何与外部组件进行集成，以支持大型语言模型（LLM）的推理和训练。

  1. LLM 引擎 ：
    • 支持 vLLM 和其他推理引擎。
    • 支持 Megatron 等训练框架。
  2. Mooncake 存储 ：
    • Managed Store（主从模式） ：提供零拷贝对象存取功能，用于高效的数据读写操作。
    • P2P Store（仅客户端） ：支持点对点数据传输，适用于特定场景下的数据交换。
  3. Mooncake 存储批处理传输 API ：
    • 通过 Mooncake Transfer Engine 实现高效的数据传输和管理。
  4. 存储资源 ：
    • 裸金属存储资源 ：包括 NUMA 节点、本地内存、远程内存（远程 SSD）、RDMA、NVMe over Fabrics 和 CXL 计算 Express 链接等，提供高性能的存储和计算能力。
    • 第三方内存存储 ：支持与其他第三方内存存储系统的集成，扩展存储容量和灵活性。

通过这些组件的协同工作，Mooncake 存储系统能够为 LLM 的推理和训练提供高效、灵活和可扩展的存储解决方案。

关于 Megatron 训练框架

什么是 Megatron？

Megatron[1] 是由 NVIDIA 开发的一个开源深度学习框架，专门用于训练超大规模的语言模型（LLM）。它以高效、可扩展的方式支持分布式训练，能够处理数十亿甚至数千亿参数的模型。

Megatron 的核心特点包括：

  • 模型并行化 ：将模型拆分为多个部分，分配到不同的 GPU 上进行计算。
    • 张量并行（Tensor Parallelism） ：将矩阵运算分解为更小的部分，在多个 GPU 上并行执行。
    • 流水线并行（Pipeline Parallelism） ：将模型的不同层分配到不同的 GPU 上，形成流水线式计算。
    • 数据并行（Data Parallelism） ：将输入数据分片，分配到不同的 GPU 上进行独立计算。
  • 高效的通信机制 ：通过优化的通信原语（如 AllReduce、Broadcast 等），减少分布式训练中的通信开销。
  • 混合精度训练 ：利用 FP16 或 BF16 数据格式进行计算，以提高训练速度和显存利用率。
  • 灵活的扩展性 ：支持从单节点多 GPU 到多节点集群的大规模扩展。

Megatron 是目前训练超大规模语言模型的核心工具之一，被广泛应用于学术界和工业界。

20250312-1837-23.png

评估目标

  1. Mooncake是否在实际场景中优于现有的LLM推理系统？
  2. 与传统的预填充缓存方法相比，Mooncake Store的设计是否显著提高了Mooncake的性能？

Kimi的在线统计数据

  • Mooncake使Kimi在A800和H800集群上分别能够处理比我们基于vLLM的先前系统多出115%和107%的请求。
20250312-1837-24.png

评估方法

  • 使用 Dummy LLaMA3-70B 模型进行测试。
  • 配置 16 个节点，每个节点配备 8 个 A800 GPU 和 4 个 200 Gbps RDMA NICs。
  • 以 vLLM 为基准线，采用前缀缓存和分块预填充策略。
  • 使用三种真实或合成轨迹作为工作负载，模拟在线服务的实际请求分布。
  • 通过有效请求容量和 GPU 成本两个指标进行评估。
20250312-1837-25.png

评估结果

图片展示了用于评估 Mooncake 系统性能的三种不同类型的工作负载，包括对话、工具&代理和合成数据。每种类型的数据具有不同的特征，具体如下：

  1. 对话 ：
    • 平均输入长度 ：12035 个令牌
    • 平均输出长度 ：343 个令牌
    • 缓存比率 ：40%
    • 到达模式 ：基于时间戳
    • 请求数量 ：12031 个
  2. 工具&代理 ：
    • 平均输入长度 ：8596 个令牌
    • 平均输出长度 ：182 个令牌
    • 缓存比率 ：59%
    • 到达模式 ：基于时间戳
    • 请求数量 ：23608 个
  3. 合成 ：
    • 平均输入长度 ：15325 个令牌
    • 平均输出长度 ：149 个令牌
    • 缓存比率 ：66%
    • 到达模式 ：泊松分布
    • 请求数量 ：3993 个

这些数据集涵盖了不同场景下的实际请求和合成请求，能够全面评估 Mooncake 系统在不同条件下的性能表现。通过对比不同数据集的特征，可以更准确地分析系统的优劣和适用范围。

20250312-1837-26.png

关键发现

  • 缓存命中率 ：全局缓存（global cache）的命中率高于本地缓存（local cache）。
  • 节省 GPU 计算成本 ：在不同场景下，Mooncake 能够节省 29% 到 61% 的 GPU 计算成本。
图表分析

图表展示了四种方法在三种不同工作负载（对话、工具&代理、合成）下的预填充 GPU 时间对比：

  1. Mooncake （蓝色条形图）
    • 在所有场景中表现最优，显著减少了 GPU 计算时间。
    • 相比其他方法，能够更有效地利用缓存，降低计算开销。
  2. vLLM Prefix Caching （红色条形图）
    • 使用前缀缓存技术，相比 vLLM 基线有明显改进，但在某些场景下仍不如 Mooncake。
  3. vLLM （绿色条形图）
    • 基准线方法，没有使用任何缓存优化策略，计算时间最长。
  4. vLLM Chunked Prefill （黄色条形图）
    • 使用分块预填充技术，比 vLLM 恶化，性能最差。
20250312-1837-27.png

与vLLM集成的路标

图片展示了 Mooncake Store 与 vLLM 集成的路线图，分为两个阶段：

  1. 第一阶段 ：实现了对单个预填充和解码实例的支持，并已成功合并到 vLLM 项目中。
  2. 第二阶段 ：正在开发中，目标是支持任意数量的预填充和解码实例，利用 Mooncake 的分布式 KV 缓存池实现更灵活和高效的解耦推理。

通过这些步骤，Mooncake Store 将能够更好地支持大规模 LLM 推理任务，提升系统的性能和可扩展性。

20250312-1837-28.png

总结

部署系统：Mooncake

  • 用更多存储换取更少计算 ：通过增加存储资源，减少计算开销，提高整体效率。
  • 以 KV 缓存为中心的 LLM 服务架构 ：设计了一种以 KV 缓存为核心的架构，旨在提升大型语言模型（LLM）服务的吞吐量。

基础设施：Mooncake 存储

  • 快速、可扩展且容错的 KV 缓存存储和传输引擎 ：Mooncake 存储提供高效、灵活和可靠的 KV 缓存管理能力，支持大规模 LLM 推理任务。

Mooncake 存储的优势

  • 高效的 P&D 解耦 ：通过解耦预填充和解码阶段，避免两者之间的干扰，提高系统的并行处理能力和性能。
  • 更多的 KV 缓存重用 ：通过优化缓存策略，提高 KV 缓存的利用率，减少重复计算，进一步提升推理效率。
  • 灵活的 KV 缓存调度 ：支持灵活的缓存调度机制，能够根据实际需求动态调整缓存分配，确保资源的有效利用。

延伸思考

这次分享的内容就到这里了，或许以下几个问题，能够启发你更多的思考，欢迎留言，说说你的想法~

  1. 当KV缓存命中率超过50%后，继续提升存储容量的边际效益会呈现何种变化趋势？
  2. 在量子计算时代，现有基于RDMA的缓存传输架构需要哪些根本性改造？
  3. 如何设计自适应的缓存分层策略，使系统在对话场景与工具场景间自动切换最优配置？

原文标题：Trading More Storage for Less Computation –A KVCache-centric Architecture for Serving LLM Chatbot

本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。原始发表：2025-03-14，如有侵权请联系 cloudcommunity@tencent 删除模型效率LLM存储缓存

本文标签： 月之暗面存储换算，倍增LLM推理效率

版权声明：本文标题：月之暗面：存储换算，倍增LLM推理效率 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://it.en369.cn/jiaocheng/1748252579a2275569.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。