在近期由 PyTorchKR 和 XCENA 联合主办的 KVCache Meetup Korea 上，来自 XCENA、SK hynix、FuriosaAI 和 LMCache 的讲者深入探讨了支撑大语言模型服务的架构权衡。

演讲涵盖了使用 Maru 实现 CXL 内存池化、预填充和解码阶段 GPU 算力与 HBM 带宽的 Roofline 分析、RNGD 上的批处理调度，以及使用 LMCache MP Mode 实现进程隔离的缓存服务。

实际场景中的优化需要技术栈各层协同合作，从加速器和内存架构到运行时引擎。感谢 PyTorch 基金会大使 Junghwan Park、联合主办方 XCENA，以及赞助商 @tensormesh，让本地开发者社区齐聚一堂。

点击此处阅读完整活动回顾：https://bit.ly/4sLT8bG

KVCache Meetup Korea 2026：活动回顾 - PyTorch

来源：https://pytorch.org/blog/kvcache-meetup-korea-2026-event-recap/

特色项目

• PyTorch 标志 (https://pytorch.org/projects/pytorch/)

2026 年 9 月 30 日晚，PyTorchKR (https://pytorch.kr/) 和 XCENA (https://xcena.com/) 联合主办了 KVCache Meetup Korea。PyTorchKR 是韩国主要的 AI/ML 社区，XCENA 是一家专注于 CXL（Compute Express Link，计算快速链路）的初创公司。LMCache 背后的公司 Tensormesh 也赞助了本次活动。来自 XCENA、SK hynix、FuriosaAI 和 LMCache 的讲者分享了他们在大语言模型（LLM）推理和 KV 缓存优化方面的工作。LLM 推理通过运行语言模型来生成输出。KV 缓存存储注意力数据，以便在推理过程中重复使用。

** KVCache Meetup Korea 2026 的参会者。

演讲涵盖了 CXL 内存扩展、GPU 和高带宽内存（HBM）瓶颈、RNGD 上的请求调度，以及 LMCache MP Mode。各场分享展示了硬件和服务软件处理 KV 缓存的不同方式。服务软件负责处理运行模型的请求。

签到与开场

活动将技术演讲与参会者交流的机会相结合。希望参与交流的参会者在签到时最多可以选择两张兴趣贴纸。五个类别分别为模型、服务、基础设施、硬件和内存。

** 参会者在签到时选择兴趣贴纸。

PyTorchKR 组织者 Junghwan Park 和 XCENA 首席产品官 Juhyun Kim 为活动致开场辞。讲者包括 XCENA 的 Jooho Lee、SK hynix 的 Sejin Oh、FuriosaAI 的 Donghun Lee，以及 LMCache 的 Baoloong Mao。他们分享了各自的经验和方法。

** PyTorchKR 的 Junghwan Park（左）和 XCENA 首席产品官 Juhyun Kim（右）欢迎参会者。

CXL 与 KV 缓存存储：XCENA 的 Jooho Lee

“面向 KVCache 的 CXL”这一分享从 CXL 和内存扩展的基础知识开始。Jooho Lee 解释了 CXL 如何扩展 CPU 可通过加载/存储指令访问的内存空间。他还介绍了多台主机使用同一个内存池的配置，并介绍了 Maru (https://github.com/xcena-dev/maru)。Maru 是 XCENA 以开源项目形式发布的高性能 KV 缓存存储引擎。它帮助 LLM 推理高效使用共享 CXL 内存。

** XCENA 的 Jooho Lee 带来了“面向 KVCache 的 CXL”分享。

该 KV 缓存设计在 CXL 内存池中结合了 DRAM 和 SSD 存储。它将常用缓存保存在 DRAM 中，将较少使用的缓存保存在 SSD 上。Maru 将推理引擎与这些存储层连接起来。优化 LLM 推理需要考虑的不仅是存储大量缓存。将缓存传输到 GPU 的路径和成本也同样重要。

演讲还介绍了如何将混合专家（MoE）模型中专家的计算分配到 GPU 和 MX1 上。专家是模型中具有专门功能的部分。该设计将部分权重放置在 MX1 附近的内存中，并就地处理。它传输称为激活值的中间值和计算结果，而不是完整权重。这场分享从 KV 缓存存储出发，还涵盖了权重放置和减少数据移动的方法。

GPU 算力与 HBM 带宽：SK hynix 的 Sejin Oh

Sejin Oh 带来了“分析 LLM 服务系统中的 GPU 和 HBM 利用率”分享。演讲探讨了预填充和解码如何使用系统资源。预填充负责处理提示词，解码负责生成输出词元。分享结合实际运行系统的测量结果，介绍了 Roofline 分析。Roofline 分析用于比较计算能力和内存带宽的限制。

** SK hynix 的 Sejin Oh 介绍了 GPU 算力与 HBM 带宽的分析。

实验使用了两块 H100 GPU、Llama 3.1 8B 和 vLLM。在预填充阶段的主要投影运算中，GPU 算力利用率较高。在解码阶段，HBM 带宽利用率较高。实验还解释了 TTFT 和 TPOT 之间的区别。TTFT 衡量生成首个输出词元所需的时间。TPOT 衡量每个输出词元所需的时间。

复用 KV 缓存可以减少预填充阶段的计算量。计算量减少后，内存带宽可能成为瓶颈。服务需要更大的内存容量还是更高的带宽，取决于输入和输出长度、批次大小以及其他运行条件。

RNGD 上的调度与 KV 缓存：FuriosaAI 的 Donghun Lee

FuriosaAI (https://furiosa.ai/) 正在开发 Furiosa-LLM，这是其用于在 RNGD 上运行 LLM 的自研推理引擎。在“面向 RNGD 的 LLM 推理引擎”分享中，Donghun Lee 介绍了构建引擎时遇到的工程问题，包括请求调度和 KV 缓存管理。他沿着每个请求从到达到执行的流程展开讲解。他解释了用于 KV 缓存块的 PagedAttention、用于活跃请求的连续批处理，以及将提示词分成较小片段的分块预填充。他还介绍了桶，即执行前编译好的张量形状。

** FuriosaAI 的 Donghun Lee 解释了如何在节点外共享 KV 缓存。

将请求合并到同一个批次可以提高吞吐量，即单位时间内处理的请求数量。更大的批次可能需要更大的桶，并增加延迟，即响应等待时间。Furiosa-LLM 会测量实际硬件上的执行成本。当合并后的成本低于分别处理的成本时，它会合并两个批次。决策还会考虑每个请求的上下文长度和填充成本。填充是指补齐固定张量形状中未使用的位置。

演讲比较了缓存复用的收益与传输缓存的成本。幻灯片使用了一个包含 12,370 个词元的提示词，每次处理一个请求，并对每种条件进行三次测量。读取主机缓存并生成首个词元耗时约 92 毫秒。重新计算缓存耗时约 900 毫秒。在这些测试条件下，读取主机缓存更快。他还解释了如何在每一层将缓存传输与计算重叠执行。

收益取决于传输的数据量和可用带宽。实验性功能包括网络共享缓存，以及在独立资源上运行预填充和解码。他还讨论了未来的扩展计划。

“LMCache：采用多平台架构的统一 KV 缓存管理层”：LMCache 的 Baoloong Mao

LMCache (https://lmcache.ai/) 维护者兼核心架构师 Baoloong Mao 带来了“采用多平台架构的统一 KV 缓存管理层”分享。LMCache 是由创立 Tensormesh (https://tensormesh.ai/about/) 的团队创建的开源 KV 缓存项目。他解释了 LMCache 如何将不同的推理引擎与存储系统和硬件连接起来。他重点介绍了 MP Mode，该模式将缓存管理从推理引擎内部移至独立进程。

** LMCache 的 Baoloong Mao 介绍了统一 KV 缓存层和 MP Mode。

在 MP Mode 中，CUDA IPC 允许进程共享 GPU 内存。IPC 指进程间通信。这些进程交换块 ID 等控制信息。它们使用节点内的共享 CPU 内存池来减少重复存储。MP Mode 还会并行读取和加载多个存储层的数据。这种设计将推理计算与缓存 I/O（即数据传输）分离，以减少资源竞争。

分享还涵盖了部署和运维。话题包括在 Kubernetes 上部署，以及监控缓存命中率和缓存存活时间。缓存命中意味着所请求的数据可用。演讲还介绍了如何隔离推理进程和缓存进程之间的故障。外部插件支持连接更多存储系统和设备。

问答与交流

在问答环节，讲者们重返舞台，回答参会者的问题。问题包括预填充与解码分离和混合批处理之间的比较。混合批处理会同时处理预填充和解码任务。参会者还询问了 LMCache 与 vLLM 内置缓存功能各自的作用。另一个话题是将 MP Mode 扩展到多个节点的计划。

** 演讲结束后，讲者们一起回答现场提问。

问答结束后，来自不同领域的参会者组成小组进行交流。兴趣贴纸帮助他们找到兴趣相近的人。讲者和参会者交流想法，聆听不同观点。

交流也在现场 XCENA 的 CXL 服务器周围继续展开。参会者近距离查看硬件并提出问题。他们将演讲中的内存扩展技术与展示的硬件联系起来。

** 参会者在交流环节交谈。

来自 72 份问卷答复的反馈

以下总结基于 72 份问卷答复。下面所有数字和百分比均以这些问卷答复为基数。部分问题允许多选。

基于 72 份问卷答复的活动满意度和按岗位划分的工作经验。

在反馈问题中，48 名受访者将活动议程选为优点（66.7%）。场地和设施获得了 30 次选择（41.7%）。交流氛围和活动时间安排各获得了 22 次选择（30.6%）。该问题允许多选。受访者对演讲以及结识其他参会者的机会给予了积极评价。

多次出现的意见涉及麦克风音质和音量、后排观看屏幕的清晰度，以及空间有限。一些受访者还希望提供口译或笔译，帮助他们理解英文演讲。另有一些受访者希望设置专门环节，让同一领域的开发者交流。对未来活动的期望包括真实生产案例、vLLM 和 SGLang 内部机制、神经网络处理器（NPU）编译器、近期推理优化技术，以及演示。受访者希望了解实际部署中遇到的问题、试错过程和解决方案。他们希望讲者在介绍产品的同时，也讲解这些经验。

** KVCache Meetup Korea 合影。

PyTorchKR (https://pytorch.kr/) 将利用这些反馈来策划和举办未来的活动。感谢所有在工作日晚间参加活动的人。组织者也感谢各位讲者分享知识和经验。感谢 PyTorchKR 和 XCENA 组织本次活动，并感谢 Tensormesh 的支持。