当前位置：首页 > news >正文

推理加速新范式：火山引擎高性能分布式 KVCache （EIC）核心技术解读

news 来源：原创 2025/7/18 4:46:05

资料来源：火山引擎-开发者社区

分布式 KVCache 的兴起
背景
在大模型领域，随着模型参数规模的扩大和上下文长度增加，算力消耗显著增长。在 LLM 推理过程中，如何减少算力消耗并提升推理吞吐已经成为关键性优化方向。以多轮对话场景为例，随着对话轮数增加，历史 token 重算占比持续增长。实验数据表明（如图1），当每轮输入为 8k tokens 时，运行 6 轮后，历史 token 重复计算占比超过 80%，直接导致了 GPU 算力的冗余消耗。在此背景下，构建高效的历史 token 计算结果缓存机制，理论上可以实现对重复计算过程的智能规避，从而显著提升计算资源的利用效率。

图1 对话轮数及重算率的变化
在应对上述技术挑战中，KVCache 技术应运而生。
作为现代推理框架的核心组件，KVCache 能显著优化系统性能。以 vLLM 为例，其通过 Prefix Cache 和 PageAttention 技术，构建了基于本地 HBM 的 Local KVCache 方案。该方案中，缓存重用率（Cache 可被重复使用的比例）作为核心指标，通常认为与缓存容量呈正相关关系，即空间越大重用率越高，然而 Local KVCache 受限于本地存储空间，容易遇到瓶颈。
从实验数据看出（如图2），在 H20 硬件平台运行 LLaMA-70B 模型时，每处理 1K token 需要 1.6GB 空间，导致 Prefill 在 20 分钟内即突破内存阈值。这一内存墙问题会引发 KVCache 频繁驱逐旧数据，导致重用率下降，进而严重影响 KVCache 记忆长度，最终导致大量 token 重计算。为验证内存墙问题的影响，我们在 LLaMA-70B 模型的长文本场景测试中发现（如图 3），随着文档规模的增长，系统会快速触及单机内存上限，导致 token 吞吐量骤降 70%，迫使系统陷入算力重复消耗的恶性循环。

图2 KVCache 内存占用

图3 Token 吞吐和 KVCache 重用率
Local KVCache 另一个关键局限于在于无法多机共享，主要影响以下典型场景：

多轮对话调度：多级推理通常需要通过复杂的调度来提升缓存重用率，如多轮对话中，同一会话需要尽可能调度至固定 GPU 以复用缓存，容易引发调度热点与负载不均衡问题，实际场景中难以实现性能与资源利用率的平衡。
PD 分离架构：系统将 Prefilling 和 Decoding 两阶段分离部署，需要通过高速网络直接传输 KVCache。这不仅要求 PD 节点间网络需要具备高吞吐能力以保证传输效率，还需避免传输过程中因调度问题触发缓存失败而引发重计算。同时，PD 分离中 Decoding 阶段 KVCache 也难以被之后的推理复用，导致 GPU 算力空耗。

图4 KVCache 不能共享的场景
需求
基于上述分析，我们构建了一个弹性高性能的分布式 KVCache 服务，来优化 Local KVCache 方案的内存墙和不能共享的问题。区别于传统分布式服务，分布式 KVCache 要求更高，对存储的核心挑战与需求如下：

更大的容量：构建分布式服务的初衷是为了解决传统方案内存墙问题，需具备海量容量用以支撑大规模推理的高命中率需要。
更低的访问时延：HBM 到分布式缓存之间存在网络开销，开销太大会影响 GPU 执行效率，提升 HBM 及分布式 Cache 之间的交换效率至关重要。
更高的吞吐：KVCache 通过多机间共享提升重用率，这是分布式 KVCache 的优势，然而随之而来的，需要KVCache 服务提供更加极致的吞吐以支撑大规模推理服务部署。

火山引擎推理 KVCache 解决方案
弹性极速缓存 EIC
弹性极速缓存 EIC（Elastic Instant Cache）是火山引擎存储团队面向大语言模型推理场景推出的高性能分布式 KVCache 缓存服务。随着互联网技术的演进与流量规模的激增，缓存技术逐渐成为系统架构的核心组件，火山引擎存储团队基于自身业务内部加速需求自主研发了 EIC，历经 4 年技术沉淀，该系统已支撑了公司内部存储、推理、广告推荐等大规模业务场景。
EIC KVCache 支持将内存和 SSD 组成一个分布式服务，构建多层缓存体系，实现显存容量的灵活扩展与计算资源的高效解耦。还支持和 GPU 混合部署，将 GPU 剩余显存、内存和磁盘统一池化管理，在提升计算效率的同时显著扩展上下文长度，成为加速推理框架的核心链路。基于通用模型和推理引擎，无缝兼容主流大语言模型架构，达成单客户端百 GB 级 KVCache 吞吐与亚毫秒级响应，满足高并发、低延迟的生成式 AI 场景需求。
EIC 核心特性
缓存池化：多级缓存、数据流动
EIC 通过整合 GPU 集群闲置内存和磁盘，构建分布式缓存池，突破单机内存墙限制。分布式内存池化的核心目标是基于统一的多级存储资源池化管理（GPU 显存、CPU 内存、SSD及其他缓存系统），实现显存容量的灵活扩展与计算资源的高效解耦。

图5 多级透明缓存
推理缓存 KVCache Offload 至分布式缓存后，具备以下优势：

去中心架构：采用去中心化 DHT 架构，实现数据与元数据面解耦，支撑高性能读写，支持在线扩缩容和数据迁移。
超大容量：支持灵活 Scale-out，通过云原生平台快速纳管 GPU 节点空闲资源，构建 10PB 级存储池，缓存命中率提升 10 倍以上。
多级缓存：兼顾容量与性能，支持 GPU-本地缓存-分布式缓存(RAM+SSD) 等多层级缓存系统，基于不同存储介质特性，构建大容量缓存池，并且支持缓存在各层级间高效流动，实现性能的最大化。
数据流动：支持缓存在不同层级间的流动，可基于用户需求，将冷数据下沉到低速存储，将热数据上升到高速缓存，支持包括基于时间的 TTL 策略、基于空间的 LRU/ARC/FIFO 等策略。
内存持久化：支持进程故障和在线热升级，写入内存缓存不丢失，支持毫秒级快速恢复，同时内存引擎支持 Hugepage、Numa Aware、全链路零拷贝、JumboFrame 等新特性。
热点均衡：支持热点缓存识别，同时支持热点缓存进行副本自动扩展和生命周期管理，通过多副本负载均衡，避免少量热点缓存和节点成为系统瓶颈，确保了热点场景的服务稳定性。

低时延：GPU Direct RDMA

GPU Direct：GPU Direct 是 NVIDIA 开发的一项技术，可实现 GPU 与其他设备（例如网络接口卡 GPU Direct RDMA和存储设备 GPU Direct Storage）之间绕过 CPU 的直接通信和数据传输。该技术允许 GPU 直接访问 RDMA 网络设备中的数据，无需通过主机内存或 CPU 的中介，能够显著减少传输时延提高传输带宽，尤其适用于高吞吐、低延迟的 AI 推理场景。
多协议兼容性：EIC 支持内核态TCP、用户态TCP、RDMA 及 GPU Direct RDMA 访问，适配各种硬件环境。
网络极致优化：在高带宽和推理 IO 突发场景下，通过深度优化投递模型、线程模型、网络传输等，大幅降低了网络传输（包括突发场景）长尾时延，从而提升推理体验。

GDR 可以实现全链路内存零拷贝，支持极低的访问时延。在不同 IO 大小的测试中，GDR 的表现良好（图 7），时延可以达到 TCP 或 RDMA 的十分之一。

图6 GDR 工作示意图

图7 GDR 性能对比
EIC 与 Local KVCache 在实际推理场景中的效果对比如下：

推理场景：使用两台 H20 部署 SGLang + Deepseek R1 做推理，设置 TTFT SLO 5 秒、8K Input 200 output 测试多轮对话。
实测数据对比：
吞吐提升：首轮无 KVCache 复用阶段，性能基本持平；次轮起 EIC 吞吐从 1.5K 增长至 5.5K，实现 3 倍以上性能提升（图 8）。
时延优化：首轮无 KVCache 复用阶段，性能基本持平；次轮起时延降至 1秒，降幅达 67%。
结论：得益于 EIC 低时延和大容量带来的缓存高复用，同等算力条件下，推理吞吐性能可提升 3 倍以上；若维持原有性能指标，算力需求可大幅缩减，实现性能与成本的双重优化。

图8 EIC KVCache 推理框架以存代算性能对比
高吞吐：多网卡、拓扑亲和、模型高速加载
模型分发场景中，推理冷启动对模型加载的速度要求较高，模型加载的速度决定了推理服务的弹性能力。随着模型的增长，传统存储服务的加载速度逐渐缓慢。EIC 通过分布式缓存，实现模型文件到推理框架的高速加载，显著提升推理服务弹性。我们对比了模型在 H20 机型上从 NVMe SSD （传统存储服务的性能基线）和从 EIC 的加载速度，测试数据显示（图9）：

DeepSeek-R1（642GB）：模型文件 IO 加载时间从 NVMe SSD 的 546 秒降至 13 秒，效率提升 42 倍。
DeepSeek-R1-Distill-Llama-70B （131GB）：模型文件 IO 加载时间从 84 秒压缩至 5 秒，加载速度提升 16 倍，加速效果十分显著。

图9 EIC KVCache 推理框架模型加载性能对比
为应对大模型高并发场景的 KVCache 吞吐需求，EIC 通过多网卡并行传输和负载均衡技术，大幅提升了系统性能上限；同时为了解决不同 GPU 间访问网卡的时延差异，EIC 支持感知 GPU 和网卡拓扑结构，基于亲和性来选择最优网卡传输数据，达到时延和吞吐的极致优化（如图 10）。GPU 机型的 Root Complex 是 Socket 级别，可转化为 NUMA 级别亲和，比如 Mem0 利用 R0 网卡和 R1 网卡发送延迟更低，GPU0 利用 R0 网卡发送延迟更低，我们测试多种配置场景，依赖多网卡、拓扑亲和等特性，单机可以轻松突破 100GB/s 带宽（图 11）。

图10 GPU 网络亲和示意图

图11 EIC 读带宽性能测试
高易用：Namespace 切分
EIC 支持多 Namespace 能力，可以实现数据分类，围绕 Namespace 支持以下特性：

适配多种介质：支持为 Namespace 设置不同存储介质，如内存、SSD 或组合模式，满足不同场景对容量和性能的需求。
数据流动策略：当选择内存 + SSD 混合模式时，支持选择不同数据流动和驱逐策略，如TTL、LRU、LFU、ARC 等。
空间配额：支持为单个 Namespace 设置空间大小，避免跨 Namespace 空间抢占。
QoS 策略：支持为单个 Namespace 设置不同的 IOPS 和带宽，避免跨 Namespace 吞吐抢占。
可观测性：基于 Namespace 监控吞吐/时延 /命中率/缓存数量/缓存容量等，方便用户细粒度观察系统。

图12 Namespace 特性及应用场景
在 LLM 场景中，Namespace 能力有以下应用，满足实际场景需求：

模型隔离：基于模型类型隔离，简化代码接入流程，支持不同模型的精细化调优。
模型调整：通过模型版本号的方式设置 Namespace，实现新模型无缝切换部署，旧版本 KVCache 自动失效并快速释放缓存资源。
场景隔离：在大规模模型冷启动场景中，系统对吞吐带宽的需求极高，且与模型规模呈正相关关系。在此场景下，模型加载过程可能会抢占 KVCache 的带宽资源。此时可将两种数据通过 Namespace 隔离划分，并针对模型加载对应的 Namespace 配置限流策略和优先级队列，实现相对公平的 WFQ (加权公平排队, Weighted Fair Queuing)，保障 KVCache 服务稳定性。

生态兼容：AI 云原生和开源生态集成
EIC 支持用户利用其 GPU 服务器的空闲内存和 SSD 资源，构建半托管或者全托管的高性能缓存池，目前， EIC 管控服务基于火山引擎托管，既能够依托火山引擎的 VKE 构建服务，也可基于开源的 K8S 构建服务。我们积极融入开源生态，已完成对 vLLM、SGLang 以及 Dynamo 等推理框架的适配，并将其集成至火山引擎 AI 相关重要业务中。
开源生态集成
我们基于 vLLM、SGLang 与 Dynamo 的开源实现，开发了 KV Transfer 缓存共享（Cache Reuse and Sharing）技术。该技术已成功在 PD 分离和模型并行架构下实现高效共享。与传统方案相比，在长文本场景中，推理吞吐提升 3 倍，首次 token 生成时间（TTFT）降低 67%。同时，我们优化了模型加载链路，支持模型通过多网卡从 EIC 进行高速直传，以 DeepSeek-R1（642GB）模型为例，其加载时间可缩减至 13 秒，显著提升模型部署效率。目前，我们已完成 EIC 集成的预制镜像制作，并计划将其贡献至开源社区，与社区开发者共同打造更高效、灵活的推理解决方案。
云原生开箱即用
在 EIC 集成方面，我们提供的预制镜像与白屏化集群管理平台深度协同，用户仅需在集群管理页面一键操作，即可将 VKE 和自建 K8S 推理集群集成 EIC 服务，并自动生成适配 SGLang、vLLM 和 Dynamo的 Helm Chart 包。借助该工具，推理框架的部署流程得到大幅简化，真正实现一键式快速启动。我们编制了详尽的最佳实践文档，围绕 VKE（容器服务）/Kubernetes Yaml 及 Helm 两种主流部署方式，完整展示从环境配置、参数优化到服务上线的全流程操作指南，帮助用户快速掌握高效部署方法，降低技术门槛，加速 EIC 与推理框架的深度融合应用。
展望
未来 EIC 将继续从以下维度持续演进，进一步提升产品能力和用户体验，敬请期待：

特性层面：深度结合大模型，支持推理算子下推、Sparse Attention，提供更易用的 AI 数据类型和接口，实现更加智能的数据流动，贴近开发者优化开箱即用等，提供更贴近 AI 云原生的使用方式和服务体验。
性能层面：随网络极限（200/400/800Gb）拓展 EIC 的单机极限上限，确保接近网络极限时始终保持高吞吐和低延迟稳定性；同时结合软件/网络多路径，优化推理长尾时延。
缓存层面：进一步优化内存 / SSD 等缓存使用效率，同时结合大模型 IO 特性进行智能化压缩，为用户节省成本；持续整合 VRAM、DRAM、SSD、UnderKV 等异构介质和服务器，形成统一大缓存池并实现高效利用和管理。
生态层面：快速跟进大模型技术演进，与社区合作深度合作，推进与 vLLM/SGLang/Dynamo 等框架在 PD 分离、推理调度、缓存多机共享等特性上的共同演进与深度融合。

图13 推理框架与 EIC 生态演进

相关文章：