2026 年 LLM 架构的新主线：长上下文成本正在被重新设计

type

status

date

summary

2026 年 LLM 架构的新主线：长上下文成本正在被重新设计

Sebastian Raschka 在 2026 年 5 月 16 日发布的文章 Recent Developments in LLM Architectures: KV Sharing, mHC, and Compressed Attention 很值得看。它表面上是在拆 Gemma 4、Laguna XS.2、ZAYA1-8B 和 DeepSeek V4 的新结构，真正的主线却更清楚：大模型架构竞争正在从“谁参数更多”转向“谁能更便宜地处理更长上下文”。

这不是一个小优化问题。推理模型、代码智能体、浏览器智能体、长文档分析系统都会把越来越多 token 留在上下文里。上下文一长，注意力计算、KV cache、显存带宽和缓存读写就会成为真实瓶颈。Raschka 这篇文章的价值在于，它把几个看起来分散的结构变化放到了一条线里：模型没有抛弃 Transformer，但 Transformer block 里面越来越多部件开始被专门改造。

先说结论

如果只用一句话概括这篇文章：2026 年开源权重 LLM 的架构创新，大量集中在降低长上下文成本，而不是发明一个全新的基础范式。

几个代表性方向是：

Gemma 4 用跨层 KV sharing 减少 KV cache，并用 per-layer embeddings 给小模型补容量。

Laguna XS.2 不再让每一层拥有同样的注意力预算，而是按层分配 query head。

ZAYA1-8B 把注意力放进压缩后的 latent space 里计算，用 Compressed Convolutional Attention 同时压缓存和算力。

DeepSeek V4 一边用 mHC 改造残差路径，一边用 CSA/HCA 进行更激进的长上下文压缩。

我读完后的判断是：LLM 架构没有变简单，反而在变得更工程化。基础骨架仍然是 decoder-only Transformer，但每一个高成本部件都在被拆开重做。

为什么长上下文会逼出这些设计

很多产品层面的 AI 体验看起来只是“能读更长文件”“能保持更长对话”“智能体能连续操作更多步骤”。但在模型内部，这些能力会放大两个成本。

第一是注意力计算。标准注意力需要让当前 token 和历史 token 建立关系。上下文越长，可见历史越多，计算量越难控制。

第二是 KV cache。自回归生成时，模型会缓存过去 token 的 key/value 表示，避免每生成一个新 token 都从头算历史。这个缓存随上下文长度、层数、KV 头数和隐藏维度增长。长上下文模型真正昂贵的地方，常常不是参数本身，而是每次服务请求都要搬动和读取的大量缓存。

所以 Raschka 文章里出现的几个机制，本质上都在回答同一个问题：如何保留长上下文能力，同时少存一点、少算一点、少搬一点。

Gemma 4：跨层复用 KV，把缓存直接砍掉一块

Gemma 4 的小型 E2B/E4B 版本里，有一个非常直接的想法：不是每一层都重新计算自己的 K 和 V，而是后面的某些层复用前面同类型注意力层已经算出的 KV。

这和 GQA/MQA 的方向类似，但复用维度不同。GQA 是多个 query head 共享更少的 KV head；跨层 KV sharing 是多个层共享前面层的 KV。它们都在减少 KV cache，只是一个在 head 维度省，一个在 layer 维度省。

Raschka 提到的关键细节是：Gemma 4 E2B 有 35 层，但只有前 15 层计算自己的 KV，后 20 层复用最近的、同类型注意力层的 KV。E4B 是 42 层，其中 24 层计算自己的 KV，后 18 层复用。这样在长上下文下能省下一大块显存，文章里给出的例子是 E2B 在 128K context、bfloat16 下约节省 2.7GB，E4B 约节省 6GB。

这里有个很实用的理解方式：每一层仍然有自己的 query，所以它还能形成自己的注意力模式；但 key/value 不再每层都独立生成。代价是模型容量会下降一点，因为你放弃了一部分层级独立性。收益是长上下文推理时缓存压力明显下降。

这类设计很适合小模型和端侧模型。小模型的瓶颈常常不是“参数能不能放下”，而是长上下文时缓存和内存带宽能不能撑住。

Per-layer embeddings：小模型不只靠缩小 Transformer

Gemma 4 E2B/E4B 另一个有意思的设计是 per-layer embeddings，简称 PLE。它和 KV sharing 解决的是不同问题。

KV sharing 是省运行时缓存。PLE 是在参数效率上做文章：主 Transformer stack 保持较小计算规模，但通过每层可用的 token-specific embedding slice 增加表达能力。

Gemma 4 里的 “E” 表示 effective。比如 E2B 被标为 2.3B effective parameters，但如果把 embedding 也算进去是 5.1B。E4B 类似，effective 是 4.5B，算上 embedding 是 8B。这里的意思不是模型偷偷变大了，而是主要计算路径接近较小数字，额外容量更多放在 lookup-style 的 embedding 里。

可以这样理解：普通缩小模型会减少层数、隐藏维度或 FFN 宽度，这会直接砍掉核心计算能力。PLE 则保留一个较便宜的主干，再给每一层额外喂一点和 token 相关的局部信息。它不是免费午餐，也会增加实现复杂度和一些计算，但它比把整个 Transformer stack 放大更省。

Raschka 对这个点也比较谨慎：PLE 是否总比普通 2.3B 或普通 5.1B dense model 更优，还需要更直接的对照实验。但作为工程设计，它说明小模型扩容不一定只有“整体加宽加深”这一条路。

Laguna XS.2：注意力预算不再平均分给每一层

Laguna XS.2 的架构乍看很普通，但它的注意力预算分配很有代表性。它一共有 40 层，其中 30 层是 sliding-window attention，10 层是 global/full attention。

这种局部层和全局层混合的设计已经不新鲜。真正值得注意的是，Laguna XS.2 在不同层使用不同数量的 query head。Raschka 提到，配置里有 num_attention_heads_per_layer，所以每一层 query head 数量可以不同，同时保持 KV cache 形状兼容。

简单说：全局注意力层更贵，因为它要看整个上下文；局部滑窗层更便宜，因为它只看附近窗口。Laguna 给更贵的全局层少一点 query head，给更便宜的滑窗层多一点 query head。这样不是平均撒预算，而是按层的成本和职责重新分配。

这个思路很像真实系统里的资源调度。不是所有模块都值得同样预算，也不是所有层都需要同样宽度。模型结构开始变得更像一个被 profile 过的系统：哪里贵，哪里就要压；哪里便宜且有收益，才多给一点容量。

ZAYA1-8B：在压缩空间里直接做注意力

ZAYA1-8B 的关键机制是 Compressed Convolutional Attention，简称 CCA。这个设计和 DeepSeek 之前的 MLA 有一点相似，因为它们都引入压缩表示；但二者使用压缩表示的方式不同。

MLA 更像是把 KV cache 存成更紧凑的 latent 表示，需要时再投影到注意力头空间进行计算。CCA 更激进：它压缩 Q、K、V，并且直接在压缩后的 latent space 里做注意力计算，再把结果投影回去。

这带来两个潜在收益：

KV cache 可以更小。

prefill 和训练阶段的 attention FLOPs 也能下降，因为注意力计算本身发生在更窄的空间里。

为什么还要加 convolutional？因为压缩会损失表达能力。CCA 在压缩后的 Q 和 K 上做卷积混合，让它们在进入注意力打分前带一点局部上下文。注意它主要作用在 Q/K，而不是 V，因为 Q/K 决定“看哪里”，V 负责“取什么内容”。

我觉得 ZAYA1-8B 的价值在于，它不是只把 cache 存得更小，而是把注意力计算路径也一起重写了。这类方法如果能稳定扩展，意义会很大，因为长上下文的成本不只在 decode 时的 cache，也在 prefill 阶段的海量 prompt 处理。

DeepSeek V4：一边扩残差路径，一边压长上下文注意力

DeepSeek V4 是 Raschka 文中最复杂的一部分。为了不迷失在名词里，可以把它拆成两条线。

第一条线是 mHC，也就是 manifold-constrained hyper-connections。它改的是 residual pathway。

传统 Transformer block 里通常可以理解为一个主 residual stream。Hyper-connections 的想法是把它扩成多个并行 residual stream，并学习它们之间的读写和混合。mHC 在这个基础上加了约束，让混合矩阵更稳定，比如映射到 doubly stochastic matrix 的流形上，避免信号在多层堆叠中不可控地放大或抵消。

这个设计有意思，因为最近很多架构创新都集中在 attention、MoE、norm 和 routing 上，而 mHC 动的是残差连接。它的目标不是让 attention 本身更复杂，而是让层与层之间的信息流更有表达力，同时不把 attention 或 MoE 的隐藏维度整体加宽。

第二条线是 CSA/HCA，也就是 Compressed Sparse Attention 和 Heavily Compressed Attention。它改的是长上下文注意力和 cache。

这里要区分它和 MLA 的压缩方式。MLA 主要压缩每个 token 的 KV 表示，但仍然基本保留每个历史 token 的条目。CSA/HCA 则是沿 sequence dimension 压缩：不是每个 token 都保留一个历史条目，而是把一组 token 压成更少的 compressed KV entries。也就是说，它把 cache 变短了。

CSA 压缩较温和，并结合 sparse top-k selection；HCA 压缩更重，例如把 128 个 token 压成一个条目，然后可以在更短的压缩历史上做 dense attention。两者都保留局部 sliding-window 分支，用于最近 token 的未压缩信息。

Raschka 引用 DeepSeek V4 论文中的数字：在 1M-token context 下，DeepSeek V4-Pro 相比使用 MLA 和 DSA 的 DeepSeek V3.2，只使用 27% 的 single-token inference FLOPs 和 10% 的 KV cache；V4-Flash 则是 10% FLOPs 和 7% KV cache。这个数字很激进，但也要注意，它来自完整模型配方，不代表单独某个机制的纯 ablation。

我更倾向把 CSA/HCA 理解为一种长上下文工程路线：它不一定在所有场景都比 MLA “更好”，但当目标是 1M token 级别上下文时，沿序列维度压缩几乎不可避免。

这些设计共同说明了什么

把这几个模型放在一起看，会看到一个很明确的趋势：Transformer 还在，但它越来越不像教科书里的那个简洁 block。

过去我们讲 Transformer，核心是 embedding、multi-head attention、MLP、residual、norm。现在真实前沿模型里，多了 GQA/MQA、MLA、sliding window、sparse attention、cross-layer KV sharing、per-layer embeddings、layer-wise head budgeting、compressed latent attention、sequence-level cache compression、MoE routing、residual stream mixing 等等。

这会带来两个后果。

第一，模型推理成本会继续下降，尤其是长上下文和 agent 场景。用户看到的是更便宜、更长、更快；工程师面对的是更复杂的 kernel、更复杂的 cache layout、更复杂的推理引擎适配。

第二，理解 LLM 架构不能再只停留在“参数量”和“benchmark 分数”。同样大小的模型，因为 KV cache 设计、attention pattern、active parameters、routing 和 residual path 不同，真实部署成本可能差很多。

这也是我觉得 Raschka 文章最值得转述的一点：很多重要竞争并不发生在聊天界面上，而发生在模型内部那些不显眼的数据流和缓存结构上。

给开发者和产品团队的几个判断

如果你做 AI 应用，尤其是长文档、代码库、知识库、智能体相关产品，我建议从这篇文章里拿走三个判断。

第一，长上下文不是单纯的“最大 token 数”指标。真正要看的是模型在长上下文下的吞吐、延迟、KV cache 占用、prefill 成本和质量衰减。

第二，开源权重模型会越来越分化。一个模型可能适合本地短上下文推理，另一个模型适合长上下文检索，还有一个模型适合高并发 agent。架构细节会直接影响选型。

第三，推理框架会越来越重要。模型结构越复杂，能不能高效支持这些注意力变体、cache layout 和 MoE 路由，就越决定实际成本。未来选模型，不只是下载权重，还要看运行时生态是否跟得上。

我对原文的简短评价

Raschka 这篇文章的优点是结构非常清楚，并且图很多，适合把零散的新模型结构串起来看。它没有把重点放在排行榜，而是放在“Transformer block 到底哪里变了”。这对真正要理解模型成本的人很有帮助。

我会稍微补充一个产品视角：这些架构创新最终会让长上下文能力从少数昂贵模型的卖点，变成更多模型的默认能力。但代价是底层复杂度继续上升。对应用开发者来说，最好的策略不是追每个名词，而是抓住成本来源：KV cache、attention FLOPs、memory traffic、prefill 和 decode。

总结

这篇文章写的是 LLM 架构，背后讲的是 AI 系统的成本结构。

Gemma 4 在层与层之间共享 KV，Laguna 按层分配注意力预算，ZAYA1 在压缩 latent space 里做注意力，DeepSeek V4 则把残差路径和长上下文压缩都推得更复杂。它们方向不同，但目标一致：让模型在长上下文时代还能跑得动、跑得便宜。

所以我的一句话 takeaway 是：Transformer 没有被替代，但正在被系统性地“工程化”。未来几年，LLM 的竞争不只是谁更聪明，也是谁能在百万 token、智能体工作流和高并发服务里，用更少缓存和更少计算完成同样的事情。