火山引擎 EIC 解析：构建以 KVCache 为中心的推理新基建

EIC 作为火山引擎的分布式 KVCache 方案，通过存储-计算解耦、资源池化、分层优化三大能力，解决了大模型推理中的内存瓶颈、高并发延迟、跨节点协同等问题，其应用场景可覆盖广告推荐、文本及多模态模型等基础推理生态，通过以存代算重构大模型的算力效率体系，推动 AI 规模化应用的成本优化与性能升级。

本文将全面剖析推理框架技术原理，介绍 EIC 如何突破原生推理框架限制。

背景：推理爆发引起推理框架快速迭代

近年来，豆包、Kimi、DeepSeek 等大型语言模型（LLM）技术有了巨大进步，并大范围、深入地影响着各行业。在智能客服、代码编写、内容创作以及企业知识管理等方面，LLM 正在改变各类应用的服务方式。同时，AI Agent 的快速发展，更加丰富了应用场景，对线上推理服务的需求急剧增加。需求增长使底层 AI 基础设施面临更大的压力和挑战。如何高效、稳定又省钱地提供推理服务，成了业界研究重点。在此情况下，先进的推理框架和高性能的 KVCache 受到了更多关注。

大模型推理框架核心原理

为应对推理挑战，社区出现了一些优秀的推理框架，如 vLLM、SGLang、TensorRT-LLM、TGI 等。这些框架的主要目的是通过系统层面的优化，实现大语言模型推理服务的低延迟、高吞吐和低成本。

在众多优化技术中，键值缓存（KV Cache）是加快自回归模型生成过程的关键机制。模型在生成每个新 Token 时，需要依靠之前所有 Token 的注意力计算结果（Key 和 Value）。通过缓存并利用中间结果，就无需在每一步生成时都重新计算历史序列，这样能大大提高推理效率，是现在 LLM 推理框架的核心技术。社区常见的大模型推理框架，vLLM、SGLang、TensorRT-LLM 情况如下：

• vLLM：运用 PagedAttention 技术，提高了注意力机制的内存使用效率，能在有限的硬件资源上运行大规模模型。通过连续批处理技术提升 GPU 利用率，它的吞吐量和响应速度在业界处于领先水平，并发处理能力强大。同时，它和 OpenAI API 兼容，和 Hugging Face 生态深度融合，支持多种主流的开源模型，架构适应性好。

• SGLang：从底层对 LLM 推理效率进行优化，是高性能的推理运行时（Runtime）。它提供了高级且易用的 API，有强大的分布式部署能力。同时内置了高性能的 JSON 解析模块，方便构建面向结构化的数据查询 API 服务，适合复杂的自动化工作流，在高并发场景下表现优秀。特别是在 Deepseek 爆火之后，SGLang 也受到更广泛的关注和应用。

• TensorRT-LLM：以 NVIDIA 的 TensorRT 平台为基础，在硬件层面进行深度优化以加快推理速度，尤其使用 NVIDIA GPU 时性能优势明显。它支持 INT8 和 FP8 等低精度计算，可以减少内存占用并提高推理速度，它的 In-Flight Batching 和 Paged KV Caching 技术也可以进一步提高 GPU 利用率。

在大模型商业化过程中，推理服务是否成熟直接影响着技术落地的速度和效果。这一章会从常见推理服务的运行原理和核心技术方面，带大家了解推理框架的内部细节和常见的部署方式。

推理框架

EIC 目前对接的推理框架有 SGLang 和 vLLM，这两个框架在架构设计上会有互相参考，而且都和 NVIDIA Dynamo 框架相适配。接下来重点以 SGLang 框架为例进行讲解。

SGLang 是专门为大语言模型（LLM）和视觉语言模型（VLM）设计的高性能服务框架。它通过同时设计后端运行程序和前端语言，提高用户和模型交互的效率，让交互过程更方便控制。前端可以用形式化语言快速搭建 LLM Agent，部署大模型时主要用后端运行程序。SGLang 后端集成了很多先进的推理优化技术，比如基数注意力（RadixAttention）前缀缓存、零开销 CPU 调度器、预填充（Prefill） - 解码（Decode）分离、推测解码、连续批处理、分页注意力、张量并行（TP）、流水线并行（PP）、专家并行（EP）、结构化输出、分块预填充、量化（FP8/INT4/AWQ/GPTQ）以及多 LoRA 批处理等。

SGLang 的整体架构很清晰，从请求执行流程来看，大致能分为服务接口层、调度层和执行层：

• 服务接口层（Serving Interface）：核心组件有 API Server、Tokenizer（分词器）、Detokenizer（去分词器），主要负责接收请求、下发请求，以及处理简单的编解码逻辑。

• 调度层（Scheduler）：核心是 Scheduler 类，它集成了组 Batch 策略（Scheduler Policy）、Disaggregation（PD 分离）、Overlap 以及输出处理等特性（以 Mixin 方式嵌入，代码文件是独立的）；Radix Cache（前缀 KV 缓存管理）、Prefill Adder（请求组 Batch）等功能模块是单独实现的。

• 执行层（Executor）：以 TPWorker 作为核心入口，接收调度层的指令，支持张量并行（TP）和流水线并行（PP）。TPWorker 会协同管理 Model Runner，集成了多种计算后端、 Memory Pool 和 NCCL Group（通信组），一起完成模型推理计算。

其简化的请求流程如下图所示：

SGLang 请求处理流程图

推理调度

推理调度分为单实例任务调度（单实例请求动态组 Batch）和 集群全局调度（集群间实例级请求分发），我们将借助 SGLang 和 Dynamo 两个框架分别阐述两种调度的原理。

单实例任务调度

SGLang 推理请求级调度的两大核心优化技术为 Zero-Overhead Batch（零开销批处理）和 Continuous Batching（连续批处理）：

• Zero-Overhead Batch: 其核心是通过充分利用 CPU 与 GPU 的计算资源，将推理过程划分为多个阶段，采用流水线方式在 GPU 与 CPU 上重叠执行（即 Overlap）。此设计实现了 GPU 与 CPU 同时运行不同批次任务，通过资源错峰使用提升机器计算效率。根据官方 benchmark，该优化对比非 Overlap 调度方案，最高可提升 30% 的吞吐量。

Zero-Overhead Schedule

• Continuous Batching：作为大多数大语言模型（LLM）推理框架采用的动态批处理技术，其核心机制是：当批次中任意请求完成计算后，即可立即向该批次添加新请求，无需等待整批请求全部完成。相较于传统批处理方案，该技术能在序列终止（输出结束）时立即调度新序列，避免 GPU 空闲。通常，请求输出长度分布越广泛（即长短差异越大），Continuous Batching 带来的性能收益越显著。如下图所示，浅橙色代表处理 input，浅绿色代表处理 output，浅蓝色为终止，传统方案在序列输出停止后就不再处理，而 Continuous Batching 则会将新序列拼接在完成的序列后面继续处理。

集群全局调度

尽管 SGLang 在单实例任务调度方面表现出色，但当前大模型推理服务的生产环境通常采用多实例部署模式，且存在 PD 分离这类异构部署情形。因此，需考虑实例间的任务分发，以确保集群整体负载均衡，并充分利用 Prefix KVCache 来最大化集群吞吐量，而这正是 Dynamo 这种上层调度框架需要考量的问题。

Dynamo 架构图

Dynamo 作为 NVIDIA 公司发布的生产级推理框架，具备以下关键特性：

• 高效的 PD 分离架构：Dynamo 项目对 NIXL 通信库进行了专门封装，用于在大模型 PD 分离架构下实现 Prefill 实例与 Decode 实例的 KVCache 传输，最大程度降低因 Prefill 实例和 Decode 实例分开部署所产生的开销。作为一个独立的基础组件，它能够便捷地与 vLLM、SGLang 等开源推理框架进行集成。

• KVCache Aware 机制：借助 KVCache Event 来感知各机器上的 KVCache 状况，实例在缓存或驱逐请求的 KVCache 时会发布相应的 KVCache Event，Router 可依据实例的 KVCache Event 进行请求亲和调度，尽可能避免请求重计算带来的开销。

作为一个生产级推理解决方案，Dynamo 并不聚焦于推理的计算本身，而是从实例部署架构和 KVCache 感知机制入手，与现有的其他推理框架相结合进行集群请求调度，进而提升集群计算吞吐，这也从侧面反映出 KVCache 在大模型计算中的重要程度。

PD 分离

在大型语言模型（LLM）推理中，存在预填充（Prefill）和解码（Decode）两个不同阶段。其中，预填充阶段属于计算密集型，需对整个输入序列进行处理；解码阶段则是内存密集型，主要负责管理用于生成令牌的键值（KV）缓存。传统上，这两个阶段由一个统一的引擎处理，然而预填充批次与解码批次的联合调度会导致效率低下。为解决这些挑战，SGLang 引入了预填充与解码分离（PD Disaggregation）技术。该技术通过将计算密集型的预填充阶段和内存密集型的解码阶段分离到不同的服务器池，实现了资源的更优分配与利用，有效提升了 LLM 推理的效率。

SGLang 引入了 NIXL 作为一个可选的高性能传输后端。NIXL 是一个专门为分布式 AI 场景设计的通信库，旨在实现跨节点的高速数据交换。

• 控制平面 (ZMQ)：在数据传输开始之前，两个服务需要通过一个低带宽的控制通道进行“握手”和协调。SGLang 使用 ZMQ (ZeroMQ) 来实现这一步。Decode 服务会将其 NIXL Agent 的信息和用于接收 KV 缓存的目标 GPU 显存地址等元数据，通过 ZMQ 发送给 Prefill 服务。这一步是为后续的高速数据传输做准备。

• 数据平面 (NIXL)：一旦 Prefill 服务完成了对输入提示的计算，并从控制平面获取了目标地址，真正的数据传输便开始了。Prefill 服务端的 NixlKVSender 会调用 NIXL 库的 register_memory 和 transfer 等核心函数。NIXL 接管后续工作，直接将源端 GPU 显存中的 KV 缓存数据块，通过高速网络（如 InfiniBand）写入到目标端 GPU 的指定显存地址，整个过程绕过了 CPU，实现了“零拷贝 (Zero-Copy)”，从而确保了极高的传输效率。

KVCache 设计

vLLM 和 SGLang 都会在模型加载时根据用户指定的显存阈值来初始化显存池，并且会有专门的组件去管理 PrefixCache，但在管理方法上有所不同：

• SGLang 使用的是 RadixAttention，PrefixCache 是通过 Radix 树（一种压缩字典树）来管理。

RadixAttention 示例 https://lmsys.org/blog/2024-01-17-sglang/

暂时无法在飞书文档外展示此内容

• vLLM 采用 PageAttention，通过计算前缀 Hash，再借助 Hash 表管理固定大小的 KVCache 分块。这些分块会记录自身的上一个节点（即对应 token 的前缀），形式上与前缀树较为相似。

vLLM PrefixCache 示例 https://github.com/vllm-project/vllm/blob/main/docs/design/v1/prefix\_caching.md

目前 SGLang 和 vLLM 对外部 KVCache 接入方案不同，导致两者对接 EIC 的方案有所差异：

• SGLang: 官方包含有 HiCache（Hierarchical Cache） 本地 Offload 方案，主要改写 Radix 树的请求 Cache 方法来实现 KVCache Offload，不过该方案只支持单机粒度的 CPU offload；针对该缺陷，EIC 扩展了 SGLang 能力，支持了外部 KVCache，并通过计算前缀 hash 的方法来支持多推理实例间共享。

• vLLM：官方通过 KV Transfer 方案对接外部 KVCache，不暴露自身的 GPU pool。在模型推理前向计算前后，vLLM 的 model_runner 会尝试通过 KV Transfer Connector 获取 / 发送 KVCache，整体设计更模块化；此外，KV Transfer 本身还可用于 PD 分离场景。

不同的推理框架与 KVCache 存在不同的交互方式，但均遵循一个基本流程：针对外部 KVCache，Swap Out（从 GPU KVCache 到 remote KVCache）需以异步方式执行，以避免对后续计算流程的运行产生影响；Swap In（从 remote KVCache 到 GPU KVCache）则为同步操作，且最迟需在计算前完成 IO。EIC Client 具备自身的内存池，可在将 GPU KVCache 拷贝至 EIC 内存池后进行异步发送，从而最大程度地减少阻塞时间。

模型加载

在推理服务启动阶段，依赖框架会提前加载模型权重文件，此阶段的加载速度决定了推理服务的整体效率。模型加载存在多种方式，以下介绍这些方式的流程和主要特点：

• safetensors：采用 posix 文件读取方式，以 DeepSeek、Llama 为代表的主流开源模型均使用 safetensors 格式文件存储模型参数。一个大型模型可能包含多个 safetensors 文件，用于存储不同部分的参数。

• sharded ckpt：同样采用 posix 文件读取方式，原生 sharded checkpoint 的实现会将 state_dict 的键值对直接按 rank 分解，然后以 safetensor 格式写入本地的多个文件，默认按 rank 进行划分。在加载模型时，每个 rank 会通过正则匹配找到对应 rank 的所有文件并加载（目录为 {self.model_name}/keys/rank_{rank}/）。

常见的 SGLang、vLLM 等框架通过调用 safetensors 库保存和加载 safetensors 权重文件，会依次按 key 序返回 tensor 对象。框架读取文件会通过 mmap 方式加载，但这种使用方式下，返回的 tensor 仅在首次被访问或 page cache 被淘汰时，才会触发从磁盘拉取数据，可能会存在重复小块读取的情况。同时，由于不同的 GPU 仅加载自身所需部分，读取过程看似连续，实际存在跳读情况。

• EIC sharded：将模型文件加载完成后，直接将 state_dict 的键值对存储至缓存。如此操作的优势在于无需关注模型文件的存储格式，能够通过 KV 接口自然地存放模型参数。因此，EIC 适配会依照上述 sharded 方案所描述的格式（root->meta->data），把 rank 拆分为多个数据集进行存储，同时对 data 实施大块聚合，加载时每个 rank 仅需加载与之匹配的数据集，转变为顺序大块 IO 读取。

暂时无法在飞书文档外展示此内容

EIC 模型加载对比图

剖析：推理服务的三重枷锁

随着大型语言模型（LLM）朝着千亿乃至万亿参数的规模发展，其强大能力背后，是底层基础设施负担的日益加重。在追求极致性能与成本效益的在线推理服务中，三个核心瓶颈——推理缓存（KVCache）管理、弹性调度、模型加载——犹如新的三重枷锁，严重制约了服务的并发能力、弹性能力和启动速度，成为下一代 AI 基础设施亟需攻克的难题。接下来，我们将从推理痛点场景入手，结合推理框架的瓶颈分析，探讨 KVCache 面临的挑战与机遇。

痛点场景：解析推理的重重迷雾

1.模型规模膨胀与分布式部署挑战

• 模型规模变大：以 DeepSeek R1 为例，其 FP8 精度下存储容量需求达 700G，对于 400MBps/TiB 性能密度的存储来说，冷启动拉取文件耗时约 30 分钟。

• 分布式部署：超 100B 参数的模型在 FP8 精度下需 100G 显存，需多卡分布式推理；大语言模型分离出 Prefill（预填充）/Decode（解码）角色，多模态模型进一步扩展出 Vision Encoder（视觉语言模型）、Audio Encoder（语音生成模型）、Video Encoder（视频多模态模型）等角色，部署复杂度显著提升。

2.推理成本高昂与资源效率问题

• 单机 QPS 低：在模型 DeepSeek - R1 TP = 16 的推理场景中，当 Input/Output 为 8000/200 tokens，且 TTFT（首字输出时间）≤2s 时，两台 H20 可响应的 QPS 约为 3K。若业务需求的 QPS 为 30K，则需要 20 台 H20 提供支持。每增加 3K QPS 大约需增配 2 台 H20，且此计算未包含 IDC 运维、GPU 空置、容灾备份等隐性成本。

• 单机吞吐提升：当采用 H20 8 卡整机部署 DeepSeek R1/V3 时，推理吞吐成为主要瓶颈。因此，基于现有存量资源提升整机吞吐是必然选择，例如采用高性能 KVCache 以存代算、优化 CUDA 算子等方式。若能实现 KVCache 缓存复用，使推理吞吐提升至 3 倍，那么提供 30K QPS 仅需 10 台设备。

3.多并行方式与多模型协作的调度复杂性

• PD 分离解耦：在 PD 分离场景下，除基础的 TP（张量并行）外，PP（流水线并行）、SP（序列并行）、EP（专家并行）等并行方式在推理侧进行拓展，因此需要 KVCache 来卸载复杂的部署模式。

• 多模型调度：在 Agent AI 多模型协作（如豆包搜索的规划者、反思者、总结者模式）时，需要进行多模型组合部署，同样需要多模型请求以满足混合流量的需求，使用统一的 KVCache 可使多模型部署更为简便。

4.流量动态性与弹性调度压力

• 流量潮汐调度：业务存在早晚高峰、节假日、营销活动等潮汐流量，资源跨集群 / Region / 多云调度复杂，模型冷启动延迟高，导致资源利用率低下。依赖高性能弹性 KVCache 简化动态扩缩容、SLA 管理等；在混池场景中，不同输入输出的请求并发会相互干扰，影响 TTFT、TPOT 和吞吐，对峰值压力承受能力提出考验。

• 本地亲和性解耦：推理场景中常见的多轮会话 (session) 会基于 Hash 进行亲和性调度，由于存在有状态服务依赖，仅能对机器进行横向扩展，从而导致机器成本与 GPU 利用率之间产生矛盾。构建存算分离的解耦方式在 GPU 故障处理和横向能力拓展方面具备显著优势。

瓶颈解析：压垮效率的三座大山

KVCache 之困：显存的“吞金兽”与重复的计算

KVCache 是大语言模型实现高效自回归推理的关键，其通过缓存注意力机制中的键（Key）和值（Value）矩阵，避免了对历史 token 的重复计算。然而，这一机制也带来了新的、同样严峻的挑战。

• 显存占用巨大，限制并发与上下文：KVCache 的规模与请求的上下文长度和并发数（批量大小，Batch Size）成正比。在处理长序列或高并发请求时，KVCache 会迅速耗尽宝贵的 GPU 显存。这不仅严重限制了单个 GPU 能够承载的并发请求数量，也制约了模型能够处理的最大上下文长度。

• 生命周期绑定，无法跨请求复用：在传统架构中，KVCache 的生命周期与单个推理请求绑定，请求结束后即被释放。这意味着，即使成千上万的请求都包含相同的提示词或前缀，系统也必须为每个请求独立生成和存储一份几乎完全相同的 KVCache，造成了大量的重复计算和显存浪费。这种“以算代存”的模式，严重影响了服务的 TTFT 和整体吞吐量。

• 缓存换出/换入开销高昂：当显存不足时，一种常见的策略是将 KVCache 换出到 CPU 内存或外部存储。然而，当需要将其换入 GPU 时，这个同步 IO 操作会阻塞后续的计算流程，引入显著的延迟，对性能造成直接影响。

KVCache 之难：灵活的动态调度与存算分离

对于云厂商而言，AI Agent 等新型推理范式需具备良好的多模型流量调度支持能力，简化推理迭代中的推理框架。

• 卸载推理集群对流量的动态调度：在 PD 分离架构中，会采用多种并行调度方式，结合上层的 AI Agent 的多模型协作模式，针对跨机房同步、跨 Region 同步、故障迁移冷启动、潮汐调度等场景，EIC 的全局 KVCache 可实现推理服务压力的无缝卸载，同时也会面临挑战，我们正在逐一解决：

• 异构部署：简化推理在异构环境及模型参数差异化的 PD 分离下动态调度

• 混合流量：在混合 IO Pattern 下的混合流量与突发流量对 QoS 更高的要求

• 极限成本与存算分离的抉择：随着 NVIDIA 显卡供应受限，未来存量的 GPU 以及增量的其他显卡必然会在成本控制方面全力而为。在此情形下，GPU 的弹性调度将成为关键制约因素，存储的有状态服务必然与 GPU 的无状态特性产生冲突，存算分离是必然选择，常规的 KVCache 已经无法满足，因此也给 EIC 带来了新的挑战：

• 整体流量剧增：GPU 内存和磁盘拉远导致单机存储读写流量增加，磁盘读写流量放大对 DWPD 影响增大

• IO 模型和网络拓扑变化：存算分离后，读写的 IO Size 大幅增大，从 MB 级到几十 GB 级不等。另外由于组网变化，存在多打一场景，交换机压力更大，全链路网络丢包和请求间碰撞对长尾延迟影响更大

因此，引发了对低延迟、高带宽、大容量的 KVCache 需求。

模型加载之痛：启动慢、扩容难、资源空占

大模型推理服务的启动过程远非“即插即用”，其背后是缓慢而笨重的模型加载流程，这一痛点在需要快速响应业务峰值的弹性扩缩容场景中尤为突出。

• 模型文件巨大，启动耗时惊人：当前主流模型的尺寸动辄百 GB 起步，例如 DeepSeek R1 的 FP8 模型就需要 700GB 存储空间。从远端存储拉取如此庞大的文件，可能导致服务冷启动时间长达数十分钟，这对于需要秒级响应的在线服务而言是不可接受的。

• I/O 与计算开销叠加：模型加载不仅是简单的文件拷贝，还涉及到从网络存储到主存、再到 GPU 显存的多次数据传输，每一次都可能成为 I/O 瓶颈。此外，模型参数的预处理、计算图编译等初始化计算也进一步加剧了时间和资源的消耗。

• 弹性能力受限，资源利用率低：缓慢的加载速度使得 GPU 资源在启动过程中被长时间占用却无法执行有效计算，造成了严重的资源浪费。更重要的是，它让服务的弹性伸缩能力形同虚设，无法在业务高峰期快速扩容实例，也无法在低谷期迅速缩容以节约成本。

这三座大山共同导致了当前大模型推理服务成本高昂、效率低下、弱灵活性的困境。要打破这一僵局，亟需一种全新的基础设施解决方案。

破局：EIC 分布式 KVCache，构建 AI Infra 关键基础设施

面对上述瓶颈，传统的单点优化问题也越发显现。破局的关键在于引入全新的基础设施组件，从根本上改变数据的存储和访问模式。这正是 EIC（Elastic Instant Cache）作为自研分布式缓存系统的用武之地。EIC 通过提供统一的、在线低延迟、高吞吐的多级缓存能力，深度结合推理框架，为 KVCache 和模型加载提供了优秀的的解决方案。

分布式 KVCache：开启跨请求复用新姿势

针对 KVCache 的困境，EIC 的核心价值在于其作为具备大型、共享、高性能的 KV 缓存能力，它将 KVCache 从单个 GPU 的“私有财产”转变为整个集群共享的“公共资源”，并且与推理框架深度融合。

SGLang + EIC 适配示意图

• 突破单卡显存限制：将 GPU 上生成的 KVCache 通过 GDR 以极低的延迟实时换出（Offload）到 EIC 中，可以极大地释放宝贵的 GPU 显存。这使得服务能够支持更长的上下文、处理更大的并发批次（Batch Size），从而直接提升了模型的服务能力和性价比。

• 实现跨请求、跨节点的高效复用：当大量请求共享相同前缀（例如，共同的系统级 Prompt 或多轮对话的历史记录）时，其对应的 KVCache 仅需计算一次并存储于 EIC 中。后续的所有请求，SGLang 等推理框架可依据请求明文的前缀哈希值从 EIC 进行批量查询匹配，匹配成功后进行批量读取，并实现跨机共享缓存，从而彻底消除重复计算的开销。这种“以存代算”的模式，能够显著降低首次令牌生成时间（TTFT），大幅提高系统的整体吞吐量。

核心逻辑转变：

• 传统模式： 每个请求独立计算和存储 KVCache -> 资源浪费，计算冗余。

• EIC 模式： 计算一次，存入共享中心 -> 所有请求按需读取，高效复用 -> “以存代算”。

下面我将从功能，性能，成本，生态适配等多个面来介绍下 EIC 在这方面的关键手段。

功能方面：

• 缓存池化：分布式多级缓存结合数据流动，整合 GPU 集群闲置内存与磁盘，突破单机内存墙限制。

• 内存持久化：支持进程故障和在线热升级，写入内存缓存数据不丢失，支持毫秒级快速恢复。

• 热点均衡：支持热点缓存识别，同时支持对热点缓存进行副本自动扩展和生命周期管理。

• Namespace 分区：满足不同场景推理诉求，包括数据流动策略，空间配额，优先级 QoS 策略。

性能方面：

• 低时延高带宽：利用 GPU Direct RDMA ，实现端到端的零拷贝，显著减少传输时延提高传输带宽。

• 网络模型优化：在高带宽和推理 IO 突发场景下，深度优化投递模型、线程模型、网络传输及丢包算法，优先级 QoS 等，显著降低长尾延迟。

• 单机引擎优化：支持磁盘路径全链路零拷贝，可显著减少内存带宽，使磁盘可写带宽近乎翻倍增长。

• 多网卡拓扑亲和：推理框架支持内存/设备/网卡亲和性，使单 TP 的写带宽提升数倍。

• 写缓存开销优化：通过对多流同步、多流并发复制、异步后台写、网卡写亲和等多个关键环节进行优化，确保 EIC 在 SGLang 框架推理时的写开销始终控制在 5% 以内。同时在持续的读写操作中，随着命中率的不断提高，实现了吞吐量的成倍提升以及 TTFT 的显著下降。

成本方面：

• 单机引擎优化：通过软硬件结合解压缩，内存索引压缩，磁盘视图，磁盘 GC 等优化显著提高了单机引擎的缓存空间。

• 推理 MLA 优化：通过对框架层 MLA 机制优化，显著减少 KVCache 空间占用，提升命中率。

生态适配：

• 多种框架开箱即用：完成了 vLLM、SGLang、Dynamo、LMCache、AIBrix 等多个推理框架的适配，同时实现了多实例及 PD 分离场景下的缓存共享。

• PD 分离方案：完成了适配 vLLM KVTransfer，SGLang NIXL，大 EP 等多种 PD 分离传输方案。

模型缓存层：实现秒级加载与弹性伸缩

针对模型加载的痛点，EIC 可以作为前置的高速模型缓存层，彻底颠覆传统的加载模式。

• 变“拉”为“读”：推理服务不再需要从远端存储（如 HDFS/S3）缓慢拉取庞大的模型文件。取而代之的是，模型权重被预先加载到 EIC 的分布式内存或硬盘中。当推理节点启动或扩容时，它可以直接从高速的 EIC 缓存网络中近乎实时地读取模型参数，将原本数十分钟的加载时间缩短至秒级。

• GPU 资源解耦：通过将耗时的模型加载任务从 GPU 节点剥离，GPU 可以专注于其最擅长的计算任务。这不仅极大地提升了昂贵 GPU 资源的利用率，也使得服务的弹性伸缩变得轻快而高效，能够真正做到按需分配、瞬时响应。

• 初始化计算开销大：通过初始化计算过程，如位置编码、参数分片，Graph 等预处理操作耗时，加快了框架启动

DeepSeek-R1 / DeepSeek-V3 模型总参数量为 671B，原始为 FP8 数据类型，总大小约 640GB，火山引擎 EIC 弹性缓存团队基于 SGLang 和 vLLM 框架，通过多流并行、零拷贝、GDR 分发，预热 &Lazyload 结合等技术手段，结合模型 preshard 和 w4 量化，实现最快 13 秒内完成模型读取，另外通过预编译模型，提前优化计算图，预融合算子，减少运行时初始化，极大地缩短了服务启动时间，显著提高系统弹性。

EIC 模型加载速度对比示意图

EIC 的开花结果：令人惊喜的场景收益

案例 1: 加速 SGLang AI Coding

在客户 AI Coding 智能体场景中，应用 SGLang + DeepSeek V3 执行推理，有典型的的多轮问答，平均输入长度为 30k，输出为 1k-2k，如何在相同算力下，更多更快的执行推理请求成为最迫切的需求。如下图在两台 H20 96G 环境下，实际业务运行读吞吐非常高，承接了很多 KVCache 读命中，峰值在 50GB/s 按照单 KVCache 1088KB 计算，每秒有 48,188.23 Token 的重用，以存代算效应显著。

读吞吐

写吞吐

场景收益

我们统计了 2000 个请求，对比纯 GPU 及 EIC + GPU 的效果，Total 运行耗时降低非常明显，从 4232 秒降低到 2065 秒，运行时间降低了一半，如下图分析各个精细指标，性能提升分布在 30% 到 70% 间，相同算力下能够更多更快的承接推理请求。

推理性能对比 (百分比越大效果越显著)

案例 2: 增强推理服务弹性

在构建推理服务的时候，由于 GPU 资源成本高昂，大规模推理服务对弹性的要求更为苛刻。这要求系统具备在高峰期迅速扩容的能力，以应对突发请求；同时，在模型升级时，需支持模型快速重启，从而缩短升级窗口。推理服务启动时，相当一部分时间耗费在模型冷加载阶段，因此，缩短模型加载时间成为提升推理服务弹性的关键举措。EIC 对模型加载进行了深度优化，能够显著提升模型加载速度。

不同弹性粒度下推理服务启动速度

场景收益

我们针对不同粒度，测试了滚动重启 100 个 DeepSeek R1 满血版推理节点的场景，以观测 EIC 所能提供的弹性能力。

如上图所示：

• 第一轮测试中每次重启 5 个节点，EIC 平均带宽为 200GB/s，完成整体重启耗时 1 个多小时；

• 第二轮每次重启 10 个节点，EIC 平均带宽为 400GB/s，整体重启用时 30 多分钟；

• 第三轮每次重启 20 个节点，EIC 平均带宽为 800GB/s，整体重启用时 15 多分钟。

从测试结果可知，在模型加载场景下，EIC 可在保持性能不衰减的情况下，适配不同的弹性粒度，其弹性能力近乎实现线性扩展。与 NVMe SSD 磁盘进行模型加载的方式相比，该方式重启一次至少需要 10 多 分钟，对应上述三种不同的弹性粒度，完成服务滚动重启分别需要 200 分钟、100 分钟和 50 分钟，基于 EIC 实现模型加载推理服务弹性能力能够提升 3 倍以上，使其能够更有效地应对请求突发和例行滚动升级。

展望：持续进化，成为 AI Infra 重要基石

大型语言模型推理服务的性能瓶颈本质上源于计算与存储的矛盾：模型加载的核心挑战在于存储与 GPU 之间的数据搬运效率欠佳，而 KVCache 的瓶颈则在于 GPU 本地存储容量受限。EIC（火山引擎分布式 KVCache 方案）通过构建高速、共享且具备弹性的分布式 KVCache 层，深度融合推理框架与存储系统，有效解决了数据冷启动（从冷到热）问题，实现了冷/温/热数据在计算节点间的共享与复用。

分布式 KVCache 不仅是现有推理架构的重要补充，更是未来技术演进的核心趋势。除推理场景外，同时，EIC 还作为统一缓存层加速了火山引擎内部多产品的数据流动并已规模化，涵盖高性能文件客户端 FSX 加速、EBS 镜像加速等场景。未来，EIC 将持续发力：

• 场景扩展：拓展 LLM 模型推理、扩散语言模型（DiT）近似 KVCache、多模态、广告推荐等 KVCache 场景，以及计算和计算、计算与存储、存储和存储产品间的数据加速，以满足 AI 各场景对高速存储的需求。

• 推理技术：适配并集成社区先进推理技术（如 SGLang/vLLM/Dynamo 框架、MoE、大 EP、xPyD 等），结合字节跳动闭源推理框架进一步提升性能、降低成本。

• 训推一体：推动训练与推理架构融合，实现一套资源同时支撑训练与推理，并高效支持强化学习（RL）场景。

• 性能与 QoS：优化大规模超高吞吐网络及网络亲和性，基于软硬件协同进行引擎优化；通过权重温度分级与多级透明缓存优化存储；基于 QoS 实现流量容量的复用与隔离，支撑前端推理与模型加载的协同服务。

• 容灾与安全：增强跨机房 KVCache 同步能力支持业务容灾；强化审计、鉴权保障数据安全。

未来我们将持续深入剖析 EIC 弹性极速缓存的底层技术，帮助大家更好了解和使用 EIC 产品！