精选项目
2026年9月30日晚， PyTorchKR 与 XCENA 联合举办了 KVCache Meetup Korea。PyTorchKR 是韩国主要的 AI/ML 社区，XCENA 是一家专注于 CXL（Compute Express Link）的初创公司。LMCache 背后的公司 Tensormesh 也赞助了本次活动。来自 XCENA、SK hynix、FuriosaAI 和 LMCache 的讲者分享了他们在大语言模型（LLM）推理和 KV Cache 优化方面的工作。LLM 推理运行语言模型以生成输出。KV Cache 存储注意力数据，以便在推理期间复用。
KVCache Meetup Korea 2026 的参会者。
演讲涵盖了 CXL 内存扩展、GPU 与高带宽内存（HBM）瓶颈、RNGD 上的请求调度以及 LMCache MP 模式。这些环节展示了硬件和服务软件如何以不同方式处理 KV Cache。服务软件负责处理运行模型的请求。
签到与开场
活动将技术演讲与参会者交流的机会相结合。希望参与交流的参会者在签到时最多可选择两张兴趣贴纸。五个类别分别是模型、服务、基础设施、硬件和内存。
参会者在签到时选择自己的兴趣贴纸。
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 Cache 存储：Jooho Lee，XCENA
“CXL for KVCache”环节从 CXL 和内存扩展的基础知识开始。Jooho Lee 解释了 CXL 如何通过加载/存储指令扩展 CPU 可访问的内存空间。他还描述了多个主机使用内存池的配置，并介绍了 Maru。Maru 是 XCENA 作为开源项目发布的高性能 KV Cache 存储引擎。它帮助 LLM 推理高效地使用共享 CXL 内存。
来自 XCENA 的 Jooho Lee 发表了“CXL for KVCache”演讲。
该 KV Cache 设计在 CXL 内存池中结合了 DRAM 和 SSD 存储。它将频繁使用的缓存保留在 DRAM 中，将较少使用的缓存放在 SSD 上。Maru 将推理引擎连接到这些存储层。优化 LLM 推理不仅仅需要存储大量缓存。将缓存移动到 GPU 的路径和成本也很重要。
该演讲还涵盖了在 GPU 和 MX1 之间拆分混合专家（MoE）模型中专家的计算。专家是模型的专门组成部分。该设计将部分权重放在 MX1 附近的内存中并在那里处理。它传输称为激活的中间值和计算结果，而不是完整的权重。该环节从 KV Cache 存储开始，还涵盖了权重放置以及减少数据移动的方法。
GPU 计算与 HBM 带宽：Sejin Oh，SK hynix
Sejin Oh 发表了“Analyzing Utilization of GPU and HBM in LLM Serving Systems”演讲。该演讲考察了 prefill 和 decode 如何使用系统资源。Prefill 处理提示词，decode 生成输出 token。该环节展示了 Roofline 分析以及来自运行系统的测量结果。Roofline 分析比较计算和内存带宽限制。
来自 SK hynix 的 Sejin Oh 介绍了 GPU 计算和 HBM 带宽分析。
实验使用了两张 H100 GPU、Llama 3.1 8B 和 vLLM。在 prefill 的主要投影操作期间，GPU 计算使用率很高。在 decode 期间，HBM 带宽使用率很高。实验还解释了 TTFT 和 TPOT 之间的区别。TTFT 衡量生成第一个输出 token 的时间。TPOT 衡量每个输出 token 的时间。
复用 KV Cache 可减少 prefill 期间的计算。在此减少之后，内存带宽可能成为瓶颈。服务需要更多内存容量还是带宽，取决于其输入和输出长度、批大小以及其他运行条件。
RNGD 上的调度与 KV Cache：Donghun Lee，FuriosaAI
FuriosaAI 正在构建 Furiosa-LLM，这是其自有的推理引擎，用于在 RNGD 上运行 LLM。在“LLM Inference Engine for RNGD”中，Donghun Lee 分享了构建该引擎时遇到的工程问题，包括请求调度和 KV Cache 管理。他跟踪了每个请求从到达至执行的整个过程。他解释了用于 KV Cache 块的 PagedAttention、用于活动请求的 Continuous batching，以及用于较小提示词片段的 Chunked prefill。他还介绍了 buckets，即在执行前编译的张量形状。
来自 FuriosaAI 的 Donghun Lee 解释了如何在节点外共享 KV Cache。
将请求合并为一个批次可提高吞吐量，即随时间处理的请求数量。更大的批次可能需要更大的 buckets 并增加延迟，即响应延迟。Furiosa-LLM 在实际硬件上测量执行成本。当合并成本低于分别处理时，它会合并两个批次。该决策还考虑每个请求的上下文长度和填充成本。填充会填充固定张量形状中的未使用位置。
该演讲比较了缓存复用的收益与传输缓存的成本。幻灯片使用了一个 12,370 token 的提示词，一次一个请求，每种条件进行三次测量。取回主机缓存并生成第一个 token 耗时约 92 ms。重新计算缓存耗时约 900 ms。在这些测试条件下，取回主机缓存更快。他还解释了如何在每一层将缓存传输与计算重叠。
收益取决于传输的数据量和可用带宽。实验性功能包括网络共享缓存以及在单独资源上运行 prefill 和 decode。他还讨论了未来扩展的计划。
“LMCache：具有多平台架构的统一 KV Cache 管理层的”：Baoloong Mao，LMCache
LMCache 维护者兼核心架构师 Baoloong Mao 发表了题为“具有多平台架构的统一 KV Cache 管理层”的演讲。LMCache 是一个开源的 KV Cache 项目，由创立了 Tensormesh他解释了 LMCache 如何将不同的推理引擎与存储系统和硬件连接起来。他重点介绍了 MP 模式，该模式将缓存管理从推理引擎内部移到一个单独的进程中。
来自 LMCache 的 Baoloong Mao 介绍了统一 KV Cache 层和 MP 模式。
在 MP 模式下，CUDA IPC 允许进程共享 GPU 内存。IPC 指的是进程间通信。这些进程交换块 ID 等控制信息。它们在节点内使用共享的 CPU 内存池，以减少重复存储。MP 模式还会并行地从多个存储层读取和加载数据。这种设计将推理计算与缓存 I/O（即数据传输）分离，以减少资源竞争。
本次会议还涵盖了部署与运维。主题包括在 Kubernetes 上部署，以及监控缓存命中率和缓存生命周期。缓存命中意味着所请求的数据可用。演讲还涵盖了在推理进程与缓存进程之间隔离故障。外部插件允许连接到更多存储系统和设备。
问答与交流环节
在问答环节中，讲者们回到台上回答参会者的提问。问题包括将 prefill 与 decode 分离，并与混合批处理进行对比。混合批处理会将 prefill 和 decode 工作一起处理。参会者还询问了 LMCache 的作用以及 vLLM 内置的缓存功能。另一个话题是将 MP 模式扩展到多个节点的计划。
讲者们在演讲结束后一起回答了现场提问。
问答环节结束后，来自不同领域的参会者三五成群地聚在一起交谈。他们的兴趣贴纸帮助他们找到志趣相投的人。讲者与参会者交流想法，并听取了不同的观点。
会场内，围绕 XCENA 的 CXL 服务器的交流也在继续。参会者近距离查看了硬件并提出了问题。他们将演讲中提到的内存扩展技术与展出的硬件联系起来。
参会者在交流环节中进行了交谈。
72 份调查问卷的反馈
以下总结基于 72 份调查问卷的反馈。下文中的所有数字和百分比均以调查问卷反馈为基数。部分问题允许多选。
基于 72 份调查反馈，按角色划分的活动满意度与工作体验。
在反馈问题中，48名受访者将活动项目选为优点（66.7%）。场地和设施获得30次选择（41.7%）。交流氛围和活动时间安排各获得22次选择（30.6%）。该问题允许多选。受访者对演讲以及结识其他参会者的机会给予了正面反馈。
重复出现的评论提到了麦克风质量和音量、后排的屏幕可见性以及空间有限。一些受访者还要求提供口译或翻译，以帮助他们跟上英文演讲。一些受访者还要求举办一个让同一领域的开发者可以交流的专门环节。对未来活动的请求包括真实生产案例、vLLM 和 SGLang 内部机制、神经处理单元（NPU）编译器、近期推理优化技术以及演示。受访者希望了解真实部署中的问题、试错和解决方案的细节。他们请讲者解释这些经验以及他们的产品。
KVCache Meetup Korea 活动合影。
PyTorchKR 我们将利用这些反馈来规划和举办未来的活动。感谢每一位在工作日晚上参加活动的朋友。主办方也感谢分享知识与经验的各位讲者。感谢 PyTorchKR 和 XCENA 组织本次活动，也感谢 Tensormesh 的支持。
/row /row