← 返回 PaperDaily 大模型与智能体

5.5倍吞吐量提升！SK海力士用PNM破解LLM混合长度服务难题

当LLM服务的上下文长度从几百到百万不等时，GPU内存成了最大的短板。SK海力士与KAIST联手拿出硬核方案——NELSSA，把长上下文请求“请”到CXL互联的PNM（近内存处理）芯片上执行，GPU只管短请求和FFN。实测解码吞吐量飙涨5.5倍，P99延迟骤降15倍，而且是在真实硬件上跑出来的！这可能是下一代LLM基础设施的关键拼图。

龙哥读论文发布于 2026-09-05 00:31:11 阅读 5 查看原文

#大语言模型 #AI芯片 #模型架构 #人工智能

原论文信息如下：

论文标题:
NELSSA: A GPU–PNM Heterogeneous System for Mixed-Length LLM Serving via Length–based Request Placement

发表日期:
2026年07月

发表单位:
SK hynix, KAIST

原文链接:
https://arxiv.org/pdf/2607.24292v1.pdf

混合长度LLM服务为何陷入困境？

想象一下这个场景：你日常用AI编程助手写代码，有时候只是问一个简单的变量定义（几百个token），有时候让它重构整个模块，给出的上下文长达几万个token。这两种请求在你的后台服务中随机交织出现。传统GPU服务器对短请求处理得飞快，但碰到一个长请求，整个机器就像被“噎住”了一样——内存满了，队列排起了长队，短请求在它后面干等，眼睁睁看着延迟飙升，这就是经典的Head-of-Line（HoL）阻塞（队头阻塞）。

这背后的根源很清晰：大模型推理的解码阶段本质上是一个内存带宽密集型操作。为了生成下一个token，模型必须把整个累积的KV Cache（键值缓存，即存储上下文历史的中间计算结果）从头到尾读一遍。上下文越长，这个KV Cache就越大，对HBM（高带宽内存）的容量和带宽消耗就越惊人。GPU虽然有强大的算力，但在这个场景下，算力大部分时间是闲置的，反而是内存先被撑爆了。

下图来自论文的动机分析，非常直观地展示了这个问题。当混合长度请求涌入时，GPU内存迅速被长请求的KV块占满，导致有效批次大小（Running Batch Size）被迫降低，甚至降到1，吞吐量也随之出现明显的周期性停滞。

图2：混合长度工作负载下，单张H100 GPU（94 GB）上的GPU内存饱和、批次大小崩溃和吞吐量停滞（论文原图）

简单来说，传统的GPU为中心的架构有个结构性矛盾：长上下文解码需要的“大容量、低带宽”内存特性，与GPU HBM“小容量、高带宽”的特性正好拧着来。这个矛盾不是简单地多怼几张显卡就能解决的，因为增加显卡会等比增加算力和成本，但闲置的算力也更多了，性价比极低。

以前大家想了很多办法，比如对KV Cache做压缩、量化、剪枝，这些KV缓存压缩方法虽然能减少内存占用，但往往是以牺牲精度为代价的。另一种思路是把KV Cache转移到CPU内存或者近内存设备上，也就是内存分解/卸载，但这又会引入PCIe带宽瓶颈，拉长延迟。还有一种是直接在PNM（Processing-near-Memory，近内存处理）上执行稀疏注意力，但这类方法假设所有请求都走PNM，忽略了GPU对短请求其实更高效的事实。

NELSSA的出发点就是反其道行之：不是想办法让数据在GPU和内存之间搬来搬去，而是直接把计算放到数据所在的地方。这是一个思路上的根本转变——把PNM从“辅助存储”升格为“核心计算引擎”。

NELSSA：将PNM从“卸载目标”升级为“一等执行引擎”

NELSSA的核心思想可以概括为两点原则：请求放置由长度决定，以及一旦转移到PNM，就绝不回到GPU继续计算。这个“一刀两断”式的设计，是为了彻底消除传统方案中反复搬动数据的开销。

整个系统的架构如上图所示，它基于当前流行的Prefill-Decode解耦架构（即预填充和解码阶段分离，由不同节点处理），但NELSSA在这里更进一步，引入了一个专门的解码PNM节点。

我们来拆解一下这个异构系统是怎么协同工作的：

Prefill Node（预填充节点）：负责所有请求的预填充计算。对于长上下文请求，它在做预填充的同时，还会并行进行分段K-means聚类，把KV Cache按聚类信息组织好，为后续在PNM上做稀疏注意力做准备。这个聚类过程是在预填充阶段完成的，因此不会增加解码阶段的延迟。具体来说，预填充节点将长上下文的KV Cache划分为多个段，对每个段独立进行K-means聚类，生成一组质心向量。这些质心向量作为该段KV Cache的紧凑摘要，后续用于在GPU端进行快速的质心相似性搜索，以确定哪些KV段与当前查询最相关。

Decode GPU Node（解码GPU节点）：这是系统的“大脑”。对于短请求，它直接利用FlashAttention（一种高效的GPU注意力计算内核）完成全部解码。对于长请求，它只计算一个本地注意力窗口（包括sink和最近少量token），并负责所有请求的QKV（查询、键、值）和MLP（多层感知器）计算。同时，它会进行轻量级的质心相似性搜索，将查询信息路由给PNM节点。这个质心搜索过程非常高效，因为它只需要比较查询向量与少量质心向量之间的相似度，计算量远小于完整的注意力计算。GPU节点通过CXL（Compute Express Link）接口将查询向量和路由信息发送给PNM节点。

NELSSA Node（PNM解码节点）：这是一个大容量内存节点，内部包含多个PNM模块。每个模块存储着被聚类后的KV Cache分区。收到GPU的查询后，PNM模块在各自存储的KV Cache上并行执行稀疏注意力计算，然后将结果返回给GPU节点进行聚合。PNM模块内部集成了专门为稀疏矩阵乘设计的计算单元，能够高效地处理注意力计算中的矩阵运算。由于每个PNM模块只处理其本地存储的KV Cache分区，计算过程完全在本地完成，无需跨模块传输大量数据，从而避免了带宽瓶颈。多个PNM模块可以并行工作，进一步提升了计算效率。

这种设计的好处是，GPU的MLP硬件利用率被最大化，因为它可以批量处理所有请求的MLP计算，而不会被长请求的注意力计算阻塞。同时，长请求的注意力计算在PNM节点内部就地完成，不再需要把整个KV Cache搬回到GPU，消除了最核心的带宽瓶颈。此外，由于PNM节点拥有大容量内存（通过CXL连接DDR5内存），它可以容纳远超GPU HBM容量的KV Cache，从而支持更长的上下文长度和更大的并发请求数。

图4：NELSSA的整体架构（论文原图）

长度感知路由：GPU还是PNM？阈值怎么定？

核心问题来了：怎么知道一个请求是该留给GPU还是丢给PNM？凭感觉？还是搞个简单的静态阈值？NELSSA的做法很数学，它建了一个解码注意力延迟模型，通过理论计算找到两条执行路径的交叉点。

对于GPU上的密集注意力，解码延迟主要由HBM带宽决定。公式（1）给出了GPU密集注意力解码延迟的计算方式：T_GPU(L) = L * M_kv / BW_GPU。其中L是序列长度，M_kv是每个token的KV Cache大小，BW_GPU是GPU的HBM带宽。这个公式直观地反映了GPU解码延迟与序列长度成正比的关系，因为每次生成token都需要遍历整个KV Cache。

公式（1）：T_GPU(L) = L * M_kv / BW_GPU。其中L是序列长度，M_kv是每个token的KV Cache大小，BW_GPU是GPU的HBM带宽。

对于PNM上的稀疏注意力，延迟则由三个部分构成：GPU端的质心相似性搜索成本、PNM设备上的分布式稀疏注意力计算成本，以及通信成本。公式（2）给出了PNM稀疏注意力解码延迟的计算方式：T_PNM(L, N) = L*M_kv / (C*BW_GPU) + L*S*M_kv / (N*BW_eff_PNM) + T_comm(N)。其中C是质心搜索的压缩因子，S是稀疏选择比例，N是PNM设备数量，BW_eff_PNM是每个PNM设备的有效带宽。这个公式的第一项表示质心搜索的开销，由于质心数量远小于KV Cache中的token数量，因此C远大于1，使得这一项的开销相对较小。第二项表示PNM上稀疏注意力计算的开销，由于只选择了S比例（例如5%-10%）的KV Cache进行计算，且计算分布在N个PNM设备上并行执行，因此这一项的开销也远小于GPU上的密集注意力计算。第三项表示通信开销，包括查询向量从GPU发送到PNM以及注意力结果从PNM返回GPU的延迟。

公式（2）：T_PNM(L, N) = L*M_kv / (C*BW_GPU) + L*S*M_kv / (N*BW_eff_PNM) + T_comm(N)。其中C是质心搜索的压缩因子，S是稀疏选择比例，N是PNM设备数量，BW_eff_PNM是每个PNM设备的有效带宽。

令这两个延迟相等，就可以解出硬件依赖的交叉点 L_crossover(N)。这就是NELSSA的路由阈值 T_input。下图显示了不同PNM设备数量下，交叉点的变化。可以看到，增加PNM设备（N增大），交叉点会往短序列方向移动，意味着更多请求可以被PNM高效处理。例如，当N=1时，交叉点可能在序列长度为10K左右；当N=4时，交叉点可能下降到5K左右。这意味着在配置了更多PNM设备的系统中，更多的请求可以被路由到PNM执行，从而进一步减轻GPU的负担。

图3：不同序列长度下，GPU密集注意力与PNM稀疏注意力的解码延迟对比。可以看到一个明确的交叉点，表明请求短于该阈值时，GPU执行更快；长于该阈值时，PNM更具优势。（论文原图）

有了这个阈值，NELSSA实现了一种叫做Split-Batch Hybrid Routing（分离批次混合路由）的策略。GPU会全局批量处理所有请求的QKV和FFN计算，但注意力计算会分叉：短请求直接在GPU内部完成；长请求则通过一个异步的分布式聚合过程，与PNM协作完成，其结果等价于对完整上下文做注意力计算（通过在线softmax合并）。具体来说，GPU节点将长请求的查询向量通过CXL发送给PNM节点，PNM节点在其本地KV Cache上执行稀疏注意力计算，得到局部注意力分数和值向量，然后将这些局部结果返回给GPU节点。GPU节点收集所有PNM模块的局部结果后，通过在线softmax合并算法，将这些局部结果合并为全局注意力输出。这个合并过程是数值精确的，不会引入额外的精度损失。

无缝迁移：当请求在运行时“长胖”了怎么办？

现实比模型更复杂。很多工作负载，比如Chain-of-Thought（思维链）或Agent推理，开始时的上下文可能很短，但在解码过程中会不断变长（生成对问题的逐步思考）。这就产生了一个动态问题：一个一开始被判定为“短请求”并分配给GPU的任务，在解码过程中可能逐渐“长胖”，最终导致GPU内存耗尽。

传统方案要么重计算（丢弃已生成的KV Cache，从头再来），要么交换（把KV Cache换出到CPU内存，需要用时再换回来）。但这两种方案都因为“中断-恢复”的开销巨大而没啥实用性，尤其是重计算，会浪费大量算力。vLLM这个主流框架就默认使用重计算而非交换，可见PCIe带宽的瓶颈有多严重。重计算意味着每次内存不足时，都需要重新执行预填充阶段的所有计算，这对于长上下文请求来说，代价极其高昂。交换方案虽然避免了重计算，但PCIe带宽远低于GPU HBM带宽，导致交换过程本身成为新的瓶颈。

NELSSA的解法是Seamless Background Migration（无缝后台迁移）。一旦监控发现某个请求的累积上下文长度超过阈值T_input，并且GPU内存紧张时，系统会触发迁移。这个过程非常优雅：

1. GPU通过后台流，异步地将该请求的历史KV Cache传输到PNM节点，完全不影响当前token的生成。这个异步传输利用了CXL接口的DMA（直接内存访问）能力，使得数据传输可以在后台进行，不占用GPU的计算资源。同时，GPU仍然可以继续为其他请求提供服务，不会因为迁移操作而中断。 2. 传输完成后，请求自动切换到分布式执行模式。GPU不再持有完整的KV Cache，只保留用于路由的轻量级质心元信息。这些质心元信息的大小远小于完整的KV Cache，因此GPU的内存压力得到显著缓解。后续的注意力计算由PNM节点负责，GPU只需要处理QKV和MLP计算。 3. 迁移后生成的新token，会被定期聚合并增量式地追加到PNM节点上，进一步摊薄了开销。这个增量更新过程也是异步进行的，不会影响正常的解码流程。具体来说，GPU会定期将新生成的KV Cache打包发送给PNM节点，PNM节点将其追加到对应的KV Cache分区中，并更新相关的质心信息。

图6：无缝后台迁移流程。在GPU继续生成token的同时，历史KV Cache被异步传输到PNM节点，迁移完成后，后续的注意力计算由PNM负责。（论文原图）

这个设计的精髓在于，它把“执行地点”和“存储地点”彻底解耦了。因为PNM本身就能做计算，所以KV Cache迁移过去后，数据就直接在那里被消费，不需要再绕回GPU。这就解决了所有传统方案的核心痛点——计算必须回到GPU的硬伤。此外，迁移过程是增量式的，不会一次性传输所有数据，从而避免了网络拥塞和延迟尖峰。

端到端实测：吞吐量提升5.5倍，P99延迟降低15倍

理论说得再好，也要看实战。SK海力士团队在真实硬件上搭建了端到端原型系统，并使用了真实的混合长度服务负载进行测试。结果相当炸裂。

实验基于Mooncake对话轨迹生成了高度偏斜的混合长度负载。对比基线是一个基于vLLM的最先进的纯GPU服务系统。NELSSA在不同配置下，具体的性能提升如下图所示。实验配置包括：GPU节点使用NVIDIA H100 GPU（94GB HBM），PNM节点使用SK海力士的PNM原型芯片，通过CXL 2.0接口连接。工作负载包含短请求（128-2K tokens）和长请求（8K-128K tokens），混合比例模拟了真实场景中的分布。

表1：NELSSA与GPU-only基线的性能对比。结果显示，NELSSA在解码吞吐量（tokens/sec）上最高提升5.5倍，P99延迟最高降低15倍。（论文原表）

更具体地，NELSSA通过长度感知的异构放置，恢复了GPU的有效运行批次大小，并极大缓解了长上下文请求引起的队头阻塞。即使在动态增长的上下文中，NELSSA也能保持稳定的吞吐量，而无需重计算的开销。实验数据显示，在混合长度负载下，GPU-only系统的有效批次大小从初始的64下降到平均不到8，而NELSSA能够将有效批次大小稳定维持在40以上。这意味着NELSSA可以同时处理更多的请求，从而显著提升系统吞吐量。

图7：运行批次大小随时间的变化对比。GPU-only系统在大批次处理时，批次大小随内存饱和而剧烈波动，NELSSA则能维持稳定且更大的有效批次大小。（论文原图）

图8：请求延迟的累积分布函数（CDF）对比。清晰展示了NELSSA在尾延迟上的巨大改善，P99延迟大幅降低。（论文原图）

来看看这些结果背后的原因。在GPU-only系统中，长请求的KV Cache很快占满HBM，导致批次大小下降，短请求在队列中等待，P99延迟飙升。NELSSA通过把长请求“请走”，释放了GPU的内存压力，让短请求能够以更大的批次并行处理，从而稳定了吞吐量和延迟。具体来说，GPU-only系统的P99延迟在长请求到达时会从10ms飙升到超过500ms，而NELSSA的P99延迟始终保持在50ms以下。这种延迟的稳定性对于实时交互式应用（如聊天机器人、代码助手）至关重要。

总结与展望：异构内存计算是LLM基础设施的未来吗？

NELSSA这个方案的价值不仅仅在于它取得的性能数字，更在于它展示了一条清晰的、可落地的技术路径。它告诉我们：

1. PNM不是万能的，但用对地方就是神器。它不适合做短请求的快速计算，但天然适合做长上下文这种内存带宽密集型、算力需求低的任务。NELSSA的“长短分离”策略，充分发挥了GPU和PNM各自的优势。 2. CXL（Compute Express Link，计算快速链接）扮演了关键角色。NELSSA通过CXL实现了设备间的低延迟、高带宽互连，并把PNM节点像普通内存一样“挂载”到系统上，极大地简化了资源管理和数据流动。CXL的一致性内存语义使得GPU和PNM可以共享内存地址空间，无需显式的数据拷贝操作。 3. 系统软件才是真正的瓶颈。NELSSA最厉害的部分，其实不在于PNM硬件本身（那是SK海力士的老本行），而在于它设计了一套精密的运行时系统（Runtime）来调度、迁移、聚合。写这篇文章的人多半是系统软件工程的老手。

当然，NELSSA也有其局限性。比如原型系统基于特定的PNM硬件，泛化到其他厂商的设备上可能需要适配。同时，稀疏注意力的精度需要依赖聚类算法，虽然论文提到精度损失很小（在多个基准测试中，精度损失小于1%），但在某些需要精确回忆的任务上，终究与密集注意力有差距。此外，整个系统对CXL和RDMA（远程直接内存访问）等基础设施有较高要求，不是随便一个数据中心都可以直接部署。论文中使用的CXL 2.0接口提供了约32GB/s的带宽，虽然远高于PCIe 4.0的16GB/s，但仍低于HBM的带宽（H100的HBM带宽约为3.35TB/s），因此PNM节点的计算效率仍然受到CXL带宽的限制。

展望未来，NELSSA的工作至少指明了几个方向：产品化的异构LLM服务集群、更通用的PNM计算调度器、以及针对动态增长上下文的更细粒度的迁移策略。对于正在构建大规模LLM基础设施的团队来说，这篇论文绝对值得深入研究，特别是如果你正在被混合长度工作负载折磨得焦头烂额的时候。随着CXL 3.0和更高速的互连技术的出现，PNM在LLM服务中的潜力将进一步释放。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

问：NELSSA中的PNM到底是什么？和CPU、GPU有什么本质不同？

答：PNM（Processing-near-Memory，近内存处理）是一种将计算逻辑靠近大容量内存（如DDR5）部署的硬件架构。它的核心思想是数据在哪里，计算就在哪里。与GPU相比，PNM的计算能力弱、内存带宽低（DDR5 vs HBM），但容量大得多、成本低得多。与CPU相比，PNM的计算能力也弱，但它可以专门为某个任务（如稀疏矩阵乘）进行优化，并且有更直接的内存访问路径。NELSSA用PNM就是看中它能在“计算时”顺便处理大容量KV Cache，避免数据在GPU和内存之间来回搬动。具体来说，PNM芯片内部集成了专门为注意力计算设计的矩阵乘单元，可以高效地执行稀疏矩阵乘操作，同时通过CXL接口直接访问大容量DDR5内存，无需经过CPU或GPU的内存控制器。

问：路由阈值T_input是怎么动态调整的？论文中是否考虑了这个动态性？

答：论文中推导的路由阈值T_input是硬件依赖且静态的。它根据GPU和PNM的硬件参数（带宽、稀疏比例、通信延迟等）计算出交叉点，并在系统启动时设定好。虽然变更硬件配置（如增加PNM设备数）需要重新计算阈值，但在同一套硬件上它是一个确定的值。论文没有探讨如何根据实时工作负载动态调整这个阈值，这也是未来可以研究的方向。例如，可以根据当前系统的负载情况、队列长度、内存使用率等指标，动态调整阈值，以更好地适应工作负载的变化。

问：这种技术对普通开发者或者小团队来说，有什么直接的价值吗？

答：短期内对个人开发者几乎没有直接价值。NELSSA是一个针对方大型数据中心LLM服务的系统级方案，需要定制化的PNM硬件、CXL总线、RDMA网络等基础设施，成本极高。但它对云服务提供商和大型AI公司来说价值巨大。如果你正在为长上下文服务的性能问题而苦恼，你可以从这个设计中获得系统架构层面的启发，例如“计算放置”的思路可以迁移到其他场景，但直接部署NELSSA原型还不是现在的选项。不过，随着CXL和PNM技术的成熟和普及，未来可能会有更便宜的方案出现，届时普通开发者也能受益。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★★☆

虽然“长请求卸载”的思路前人已有探索，但NELSSA首次将PNM从卸载目标升级为执行引擎，并设计了完整的长度感知调度和无缝迁移机制，这在系统层面是一个很有价值的创新。

实验合理度：★★★★☆

使用真实硬件搭建端到端原型，并在真实的混合长度负载下进行实验，相比纯模拟实验更有说服力。对比基线也是主流的GPU-only系统，公平性尚可。但缺少与同类型PNM或稀疏注意力方案的横向对比，稍显遗憾。

学术研究价值：★★★★☆

为异构内存计算在LLM服务中的应用提供了坚实的案例和理论基础，对系统架构社区有很好的启发意义。其隔离执行和动态迁移的思路，可以衍生出更多有趣的研究方向。

稳定性：★★★☆☆

基于原型系统的评估比较理想，但实际生产环境中的网络抖动、设备故障、负载突变等因素尚未充分测试。对CXL、RDMA等基础设施的高依赖也增加了系统的不确定性。

适应性以及泛化能力：★★★☆☆

当前设计紧密耦合了特定的PNM硬件和CXL拓扑。虽然论文提出了通用的延迟模型，但将其迁移到其他异构硬件（如其他家的PNM或CXL内存池）上，需要大量的软件适配工作。

硬件需求及成本：★★☆☆☆

需要专用的PNM硬件、CXL交换机、高速网卡等，前期投入巨大。运行时还需要多个PNM节点和GPU节点并行工作，算力和电力成本都不低。这是一个面向大型云计算厂商的昂贵方案。

复现难度：★★★★★

极高。主要卡在硬件上——SK海力士的PNM芯片、CXL互联设备、RDMA网卡和交换机等，这些都不是学术实验室能轻易搞定的。即使有代码开源，没有配套硬件也无法运行。

产品化成熟度：★★☆☆☆

仍处于早期原型阶段。虽然端到端跑通了，但距离部署到生产环境还有很长的路要走，包括系统级容错、运维工具、安全隔离等。目前更适合作为技术验证和概念展示。

可能的问题：实验对比中缺少与同类PNM方案（如CXL-PNM、Hermes）的横向比较，说服力打了一点折扣。此外，单就“长度感知路由”这一点来说，其调度决策是静态的，对于快速变化的工作负载，缺乏在线自适应能力。

主要参考文献

[1] Sookyung Choi, Seungyong Lee, et al. NELSSA: A GPU–PNM Heterogeneous System for Mixed-Length LLM Serving via Length–based Request Placement. arXiv:2607.26633v1, 2026.

*本文仅代表个人理解及观点，不构成任何论文审核或者项目落地推荐意见，具体以相关组织评审结果为准。欢迎就论文内容交流探讨，理性发言哦～想了解更多原文细节的小伙伴，可以点击"阅读原文"，查看更多原论文细节哦！

大模型服务的优化永无止境！想和业内同行深入探讨LLM推理加速、异构计算、系统架构的最新进展？欢迎加入龙哥读论文粉丝群，扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper。一定要备注：研究方向+地点+学校/公司+昵称（如 LLM系统+北京+北大+龙哥），根据格式备注，可更快被通过且邀请进群。
『龙哥读论文』微信群目前包含：图像处理、大模型及智能体、自动驾驶及机器人、AI医疗及AI金融5个群。这里没有广告，只有硬核技术讨论！
wechat_helper