GLM-5.3 稀疏注意力降低计算量，但 HBM 需求依然存在
GLM-5.3 的稀疏注意力减少了每次注意力运算需要读取的上下文量，但并不会自动消除模型对 HBM 容量的压力。9 月 28 日的一项分析发现，筛选相关 token 仍可能需要访问完整的上下文历史。这一结果挑战了一种颇具吸引力的假设：被关注的 token 更少，GPU 内存需求就必然按比例降低。
这一区别很重要，因为 GLM-5.3 面向长时间运行的编程与智能体任务；在这类任务中，上下文会随着工具调用、文件、测试结果和修改不断累积。稀疏注意力降低了主注意力计算内部的工作量。用于存储先前 token 可复用键和值表示的 KV cache，仍会随着完整序列持续增长。
DeepSeek Sparse Attention 提供了这一架构的参考点。其索引器会在模型执行主注意力计算前识别一组有限的有效 token。GLM-5.3 将这一方法与压缩缓存表示、跨层索引复用，以及可将非活跃缓存条目移入主机内存的服务软件结合起来。
因此，核心较量并不只是稀疏注意力与稠密注意力之争，而是算法稀疏性与保留长对话可用性的物理要求之间的较量。这一较量决定了内存节省会体现为更低的 HBM 容量、更低的带宽需求、更高的并发能力，还是仅仅体现为 GPU 与系统内存之间不同的平衡。
GLM-5.3 稀疏注意力实际改变了什么
GLM-5.3 降低了每个 token 所需的高成本注意力计算量，但模型仍需要一种方式，从其历史中定位相关信息。
GLM-5.3 属于 Z.ai 的 GLM-5 系列，该系列采用混合专家架构。混合专家模型会针对每个 token 仅激活其全部参数集中的一部分。根据 GLM-5 report，该系列将这种路由计算与源自 DeepSeek 工作的长上下文注意力设计结合起来。
Z.ai 表示，GLM-5.3 与 GLM-5.2 使用相同的基础模型。其报告的能力提升来自后训练，而非新一轮基础模型预训练。这一区别意味着，当前关于内存的讨论关乎既有架构在真实服务负载下的表现，而不是某个新发明的 GLM-5.3 注意力层。
相关机制是 DeepSeek Sparse Attention，即 DSA。稀疏注意力将完整注意力限制在一部分被选中的早期 token 上，而非以同等成本处理每一个此前 token。DeepSeek 在其 V3.2 research 中介绍了这一面向生产环境的设计。
DSA 首先运行一个名为 lightning indexer 的轻量组件。该索引器会为早期位置评分，并选择 top-k token，即被判断为与当前查询最相关的有限集合。随后，主 Multi-Head Latent Attention 计算仅在这些选中位置上运行。
Multi-Head Latent Attention，即 MLA，存储的是压缩后的潜在表示，而不是为每个注意力头分别存储完整的键和值向量。这种压缩减少了每个 token 所需存储的缓存。稀疏选择则减少了主注意力运算需读取的缓存位置数量。
这是两种不同的节省。MLA 针对的是每个 token 缓存状态的大小。DSA 针对的是高成本注意力计算所消耗的缓存位置数量。
这种组合显著改变了计算与带宽特征。核心注意力可以从处理完整上下文中的关系，转向处理固定的 top-k 选择。在长序列长度下，这能够抑制主注意力工作负载的增长。
不过，lightning indexer 仍需要足够的信息，才能为保留历史中的候选项评分。如果服务系统已经丢弃了某个旧 token 的所有可用表示，模型就无法选中它。
Semianalysis examination 将此视为关键限制。稀疏注意力降低了核心缩放点积注意力运算期间的内存流量，但未必会降低保存可供选择的上下文所需的总内存容量。
在稀疏阈值以下，这一限制会更为明显。在 SemiAnalysis 讨论的配置中，DSA 使用了 2,048 个位置的 top-k 设置。序列中若包含的位置更少，便没有更大的候选池可供裁剪，因此注意力仍保持稠密。
服务引擎也会根据序列长度和部署拓扑选择不同的执行模式。实现可以在较短上下文中偏向低计算模式，随后在内存流量占主导时转向低内存模式。因此，稀疏注意力并不会为每一个请求带来固定的加速幅度。
真正有意义的变化更为具体，也更实用。GLM-5.3 稀疏注意力降低了反复查阅长历史的成本，但并不会让这段历史不复存在。
为什么更低的注意力流量并不等于更低的 HBM 容量
HBM 压力来自被保留的上下文，而稀疏注意力主要改变的是 GPU 在每次运算中读取哪些已保留的条目。
高带宽内存，即 HBM，是直接连接到加速器上的高速内存。其带宽有助于 GPU 为大型矩阵运算供给数据，而其有限容量则限制了每台设备可容纳的模型和活跃请求数量。
在自回归生成过程中，模型会逐个生成 token。它通过 KV cache 复用为早期 token 计算出的键和值。没有这一缓存，服务器就必须反复重新计算此前的完整序列。
因此，每个活跃请求都会为其上下文预留内存。一次长时间的编程会话可能包含代码库文件、命令输出、补丁尝试、测试日志和此前的推理过程。智能体生成的 token 数量可能远超普通问答交流。
稀疏注意力改变的是读取模式。模型不再将每个历史位置加载到主注意力运算中，而是加载选中的 top-k 集合。这能够降低内存带宽消耗，以及选择完成后所执行的计算量。
容量遵循不同的规则。只要任何一个早期位置仍有资格被选中，它的表示就必须在某处保持可访问。传统的服务设计会将完整 KV 历史保留在 HBM 中，即使主注意力内核仅读取其中一小部分。
由此产生的系统可能在计算受限之前先受容量限制。每个请求执行的注意力计算可能更少，但其占用的内存仍与上下文长度成比例。提高并发量，便意味着在同一设备上放置更多完整历史。
这解释了为什么稀疏注意力并不会直接转化为 HBM 需求的等量下降。系统节省了活跃流量，却未必减少驻留状态。即使每一步注意力计算都是选择性的，模型对自身历史的逻辑视图仍然完整。
这种差异类似于拥有快速检索系统的大型档案库。更快的检索减少了人们为回答每个问题所阅读的文档数量，却不会缩小档案库本身，除非较旧文档被转移到别处或被删除。
GLM-5.3 的 KV cache 压缩仍然重要。更小的每 token 表示可让更多上下文容纳于既定内存预算中，也能减少选中条目进入注意力运算时的传输字节数。
不过，压缩状态仍会随序列长度累积。更小的线性内存曲线依然是线性内存曲线。长上下文和大量同时请求最终仍可能耗尽节省下来的容量。
并发会迅速暴露这一权衡。SemiAnalysis 报告的结果显示，当并发请求从 8 个增加到 16 个时，来自 GPU 内存的 prompt token 复用率下降。GPU 复用占比从 90.3% 降至 54.8%。
在同一对比中，主机内存复用率从 6.0% 上升至 40.3%。在所有报告的并发级别下，合并缓存命中率均保持在 95% 以上。这些结果表明，可用缓存容量可以扩展到加速器之外。
但这并不意味着主机内存能够匹配 HBM 的延迟。通过 CPU-GPU 连接移动数据会产生 I/O 成本，而缓存未命中可能打断原本高效的解码路径。服务系统必须在不让传输主导生成时间的前提下，预测、获取并驱逐数据。
对内存市场的影响也比需求简单下降更为复杂。稀疏注意力可降低每个注意力步骤的 HBM 流量。与此同时，更廉价的长上下文推理可能鼓励更长的会话和更高的请求并发量。
这种反弹效应对基础设施规划很重要。当处理每个请求的成本下降时，运营商往往会接纳更多同时进行的工作。节省的内存带宽可能转化为额外吞吐量，而非闲置硬件。
因此，即使注意力变得更具选择性，HBM 需求仍可能持续。主机 DRAM 需求也可能增加，因为完整历史被转移到更大但更慢的内存层级。在规模进一步扩大时，存储系统可能承载可复用前缀或非活跃缓存数据。
实际问题不再是稀疏注意力在抽象意义上是否节省内存，而是 GLM-5.3 KV cache 的各个部分由哪个内存层级承载，以及服务引擎以何种频率移动它们。
HiSparse 将完整历史移出 GPU
HiSparse 通过将逻辑缓存可用性与物理 GPU 驻留状态分离，把稀疏注意力的选择性读取转化为实际的 HBM 容量节省。
SGLang 团队将 HiSparse 设计为用于稀疏注意力服务的分层 KV cache。它在 GPU 上保留一个较小的工作集，同时将完整 KV 历史存储在锁页主机内存中。锁页内存是为可预测地传输至加速器而准备的 CPU 内存。
在这一设计下，旧缓存条目对 GLM-5.3 而言仍在逻辑上可用，但并非全部在物理上驻留于 HBM。索引器可以选择某个位置；当 GPU 缺少该位置时，服务系统便可将其取回。
HiSparse 为其设备缓存采用最近最少使用策略。当选中的 token 不在 HBM 中时，系统会从主机内存加载它们。它会驱逐较少使用的条目，以保持 GPU 工作集处于有界范围内。
这一架构将模型层面的属性转化为系统层面的节省。稀疏注意力识别当前运算所需的小型集合。HiSparse 则确保在解码期间，只有有限的选择结果和工作缓冲区必须占用 HBM。
HiSparse paper 将该系统描述为精确且与索引器无关。精确意味着，缓存放置发生变化时，并不会有意近似模型选定的注意力输出。与索引器无关意味着，内存管理器并不依赖某一种选择算法。
其评估涵盖 H200、B200 和 GH200 平台上的 DSA、Native Sparse Attention 与 Quest。作者报告称，在长上下文工作负载下，峰值生成吞吐量最高可提升 4.7 倍。
这是在测试配置下得出的系统结果，并非对 GLM-5.3 加速倍率的保证。工作负载长度、请求并发量、互连带宽、选择局部性和缓存未命中率都会影响结果。
HiSparse 还会将数据传输与有效计算重叠进行。当某一层执行时，系统可以为后续层准备选定的缓存条目。这种逐层重叠隐藏了部分由主机到设备数据移动带来的延迟。
跨层复用让这种调度更容易实现。如果相邻层选择了大量相同的位置，系统就能提前了解潜在的缓存需求。为某一层获取的条目，可能在后续层中仍然有用。
剩余的代价是 I/O。一次选择未命中要求数据从 CPU 内存传输到 HBM。频繁未命中、分散的选择，或有限的主机—设备带宽，都可能抵消部分吞吐提升。
这种风险将理论稀疏性与生产环境效率区分开来。稀疏内核在条目到达后或许读取更少的数据，但完整系统仍必须找到这些条目、传输它们、将其映射到可用页面，并协调其生命周期。
首个 token 的生成时间带来了另一项约束。处理初始提示词的预填充，与逐 token 解码具有不同特征。HiSparse 主要面向解码阶段：此时缓存已经存在，并会随着持续生成而增长。
SGLang 的实现将 HiSparse 与预填充—解码解耦相结合。该架构将提示词处理和 token 生成分配给不同的工作节点。这样，每个阶段都能采用更适合自身工作负载的内存布局与硬件资源分配。
这种设计也改变了基础设施需求。HBM 成为热缓存，而不再是活跃对话的唯一存储位置。主机 DRAM 保存更长的历史记录，而互连则成为关键路径的一部分。
这可以降低每个解码请求所需的 HBM 容量，但并不会消除表示对话内容所需的字节。它只是将其中许多字节迁移到别处，并增加负责让正确子集保持接近 GPU 的软件。
因此，对运营方而言，相关指标不只是模型规模或最大上下文长度。他们还需要在真实并发度下考察单请求 HBM 占用、主机内存分配、未命中率、传输量以及输出 token 延迟。
稀疏注意力使这种分层设计成为可能。HiSparse 则让它具备可运营性。两者都不会让内存管理变得毫无成本。
IndexShare 降低查找相关 Token 的成本
一旦全注意力变为稀疏，索引器本身就会成为显著瓶颈，因此 GLM 的下一项优化是在层间复用选择决策。
标准 DSA 层各自拥有一个 lightning indexer。主注意力计算在选择其 top-k 集合之前，该组件会对历史 token 进行评分。索引器比全注意力更轻量，但仍需遍历上下文。
随着上下文增长，在每一层中反复为每个历史位置评分会变得昂贵。主注意力路径已经得到缩减，因此过去看似次要的工作会占据更大的总延迟比例。
Z.ai 通过 IndexShare 来解决这一问题，该方案也被公开称为 IndexCache。它不再在每个稀疏注意力层中运行独立索引器，而是让多组层复用共享选择结果。
该方法依赖于一种已观察到的模式：相邻层往往会选择大量相同的历史 token。IndexCache 研究报告称，在其分析中，相邻层 top-k 选择之间的重叠率达到 70% 至 100%。
这种重叠带来了冗余。指定的完整层可以计算索引，而后续共享层复用选定的位置。围绕 GLM 讨论的生产模式，是让每四个 DSA 层共享一个索引器。
在一个 300 亿参数的 DSA 模型上，研究人员减少了最多 75% 的索引器计算，且报告的质量下降可以忽略不计。与标准 DSA 相比，他们测得预填充速度最高提升 1.82 倍，解码速度最高提升 1.48 倍。
论文还报告了初步的生产规模 GLM-5 结果。这些发现支持该机制，但不能替代针对 GLM-5.3 工作负载和服务栈开展的广泛独立测试。
选择复用也带来了自身的训练要求。共享索引器必须识别同时服务于多个层的 token，而不是仅匹配某一层的注意力分布。IndexCache 使用其所支持注意力分布的平均值来训练保留的索引器。
这一调整很重要，因为连续层彼此相关但并不完全相同。早期层可能优先处理词汇细节，而后期层可能更重视中间处理期间形成的依赖关系。如果复用移除了仅被组内某个成员需要的 token，就会产生负面影响。
因此，该方法揭示了第二项权衡。更多共享可以减少更多索引器工作；更少共享则能保留更多层特定的选择行为。
IndexShare 还会与 HiSparse 产生协同作用。当各层共享索引时，服务引擎可在这些层之间复用已获取的缓存条目。共享选择能够减少重复的 top-k 计算，并使主机到设备的数据获取更可预测。
这种组合针对三类不同成本发起优化：
MLA 压缩每个 token 所存储的表示。
DSA 将全注意力限制在选定的历史位置。
IndexShare 避免在每一层重复计算相似的选择结果。
HiSparse 将不活跃的 KV 条目从 HBM 迁移到主机内存。
这些组件不应被合并为单一的内存主张。压缩影响每个 token 的字节数；稀疏注意力影响活跃读取；索引共享影响选择开销；卸载影响物理存放位置。
每一层优化都可能将瓶颈转移到别处。更小的缓存可能暴露计算开销；更低成本的主注意力可能暴露索引器延迟；卸载可能暴露传输带宽；更高并发可能暴露主机内存容量。
硬件特性决定了哪种瓶颈最先出现。SemiAnalysis 估算的算术强度图谱表明，GLM 的注意力配置不同于 DeepSeek 面向 H800 的平衡方式。该机构还将 GLM 的设计与中国加速器供应商 Moore Threads 的支持联系起来。
这种硬件解读仍属推断，并非 Z.ai 披露的设计目标。GLM-5.3 支持多种服务框架和加速器平台，因此运营方应在自己的部署路径上测量该模型表现。
更广泛的教训是，不能通过单一 FLOP 计数来评估 GLM-5.3 的稀疏注意力。服务性能来自索引器、压缩缓存、内存层级、内核与工作负载的共同作用。
真正的考验是生产环境的内存效率
只有当运营方能在不将不可接受的成本转移到延迟、DRAM 或运维复杂度的前提下，维持长期 agent 会话时，GLM-5.3 才能证明其内存设计的价值。
第一个值得关注的信号，是在长上下文和高并发条件下对 GLM-5.3 进行独立基准测试。单请求峰值速度几乎无法说明一个同时处理大量持久化 agent 的服务表现。测试应同时报告 HBM 使用量、主机 DRAM 使用量、缓存未命中情况和延迟分布。
令人信服的结果应表明，GLM-5.3 的 KV 缓存卸载能够承载更多并发请求，同时保持每个 token 的延迟稳定。如果吞吐量仅在接受大幅延迟尖峰后才提升，那么这种内存节省对交互式编程 agent 的价值有限。
第二个信号，是 HiSparse 和类似内存管理器获得更广泛的部署支持。SGLang 已集成 HiSparse，vLLM 也记录了围绕该架构的相关工作。跨引擎的一致表现将强化这样一种观点：稀疏模型能够在生产环境中采用受限的 HBM 驻留。
碎片化的内核支持则会削弱这一观点。稀疏注意力依赖专用的选择、页面管理、缓存格式和注意力内核。一个模型即使开放权重，也可能难以在狭窄软件栈之外高效服务。
第三个信号，是关于长周期 agent 质量的证据。只有模型能够可靠检索先前的需求、代码决策和工具结果，内存优化才有意义。会话后期出现的选择错误可能很难诊断。
GLM-5.3 的后训练策略使这一点尤为相关。Z.ai 表示，该模型在其内部 Z.ai Code Bench 上的编程能力较 GLM-5.2 提升了 50%。这仍是一项由公司自行报告的对比。
Z.ai 还报告称，GLM-5.3 在 CyberGym 上获得 84.5%，而 GLM-5.2 为 77.2%。CyberGym 衡量模型能否从源代码中发现并验证软件漏洞。GLM-5.3 发布公告将这些提升视为 agent 能力和网络安全能力增强的证据。
这些能力同时增加了实用性和风险。更长的工具驱动会话可以支持代码仓库分析、测试和漏洞研究。同样的持久性也可能帮助自动化利用步骤，或在服务缓存中保留敏感材料。
因此，内存放置也具有安全维度。主机 DRAM、共享前缀缓存和分布式缓存层扩展了对话状态可能驻留的位置。运营方需要在每一层实施隔离、驱逐、访问控制和可观测性。
模型的 Single-Rollout Asynchronous Optimization 工作也属于这一背景，尽管它并不直接降低推理内存。SAO 针对每个提示词仅训练一次 rollout，并使用独立的价值模型来估计 token 级回报。
SAO 论文称，该方法旨在解决异步 agent 训练中的不稳定性和离策略效应。它已部署在 GLM-5.2 的 agent 训练流水线中，并为 GLM-5.3 背后的后训练谱系提供参考。
SAO 可以提升针对长且不均匀的 agent 轨迹的训练效率。由于价值模型与策略模型并行运行，它也会带来额外训练开销。这是又一个通过接受其他成本来减少某一瓶颈的例子。
对企业团队而言，眼下任务是进行严谨评估。在相同工作负载下，跟踪完整提示词、选定上下文、缓存放置、未命中行为、输出延迟和任务成功率。汇总的每秒 token 数指标掩盖了太多信息。
团队还需要保留模型配置和服务实验的长期记录。可搜索的知识库可以将基准测试结果与内核版本、缓存设置和部署事故关联起来。
GLM-5.3 的稀疏注意力改变了读取长上下文的成本结构，但并未废除保存它们的需求。该架构降低了活跃注意力流量，而 IndexShare 减少选择开销，HiSparse 则限制 GPU 驻留。
下一轮基准测试的问题很具体：GLM-5.3 能否将这些节省转化为持续并发能力，而不把瓶颈转移到主机传输或检索质量上？关注实测 HBM 占用、缓存未命中延迟和长周期 agent 准确性。这些信号共同将表明，稀疏注意力交付的是更好的服务系统，而不只是孤立情况下更好的内核。
