Transformer 系列写到这里已经是第 23 篇了。这次想聊聊 Q3.5 这个模型系列的架构设计。它最大的特点不是单纯把参数做大而是在注意力机制层面做了很明确的路线调整一部分层用线性注意力一部分层保留全注意力同时把 MoE 作为大模型版本的标配。换句话说Q3.5 解决的已经不是“能不能生成”的问题而是“在长文本场景下如何用同样的算力支撑更大的模型和更长的上下文”。这篇文章的内容对两类人最有用一类是做推理服务和长文本应用的工程师另一类是希望理解近几代开源模型架构演进方向的研究者。我会从总体架构、MoE 实现、演进脉络、部署收益几个角度展开尽量把每个设计选择背后的原因讲清楚。1. 混合线性/全注意力Q3.5 架构的第一块基石1.1 标准注意力的瓶颈在哪里标准 Transformer 的注意力计算可以简写成 softmax(QKᵀ / √d)V。这个公式本身很美但代价是每一步都要计算所有 token 两两之间的关系复杂度是 O(n²)n 是序列长度。上下文从 4K 涨到 1M计算量不是涨 256 倍而是涨 62500 倍这是任何一个工程团队都扛不住的。比计算量更麻烦的是 KV Cache。每个 token 的 K 和 V 都要保留下来生成阶段还要反复读取。长文本场景下KV 显存往往比模型权重占得还多。这里可以算一笔账假设一个 48 层、80 个 KV 头、头维度 128 的模型上下文 32KKV Cache 大约是 48 × 80 × 128 × 2 × 32768 × 2 字节算下来接近 64GB。这只是一个请求的量。并发几十个请求显存直接爆掉哪怕 A100 的 80GB 也撑不住。所以业界一直在找替代方案。一个很自然的想法是能不能不保存所有历史 token 的 K 和 V而是把历史信息压缩成一个固定大小的状态呢线性注意力就是沿着这个思路走出来的。1.2 线性注意力是怎么省掉这笔开销的线性注意力把注意力公式里的 softmax 核替换成可分解的形式让 Q 和 K 之间的依赖变成单独的特征映射。这样一来就能把 KᵀV 的加权累积当作一个固定大小的状态序列再长也不增加状态大小。用生活化的话说标准注意力等于每写一行都要重新翻一遍前面所有笔记线性注意力则是边写边做摘要后续只基于摘要继续写。摘要当然会丢信息但没有摘要的话长度一上来就写不动了。Q3.5 的做法不是一刀切全部换成线性注意力而是把两种注意力同时放在模型里。原因也很直接线性注意力省资源但有信息瓶颈全注意力准确但贵。既然不同层解决不同层次的问题那就不应该让所有层承担同样的计算模式。1.3 分层策略哪几层保留全注意力虽然具体分层比例可以调整但常见做法是底部的浅层更多用线性注意力因为这些层主要处理词法、句法等局部模式历史依赖不强中高层保留全注意力用来做全局信息整合因为越往上语义合成越依赖跨位置的交互。以一个 48 层模型为例比较典型的分层是前 16 层用线性注意力中间 16 层交替混合最后 16 层用全注意力。这是一个基于工程实践的假设配置实际发布版本可能有差异但思路一致在不显著影响质量的前提下把长文本计算成本压下来。这种设计和人的阅读习惯有点类似。读一篇长文章时开头几段你会逐字看但读到后面你会不自觉地依赖前面形成的“整体印象”只有遇到关键细节时才会回头翻原文。全注意力层就承担了那个“回头翻原文”的作用。2. MoE 在 Q3.5 里的实现思路参数多但计算稳2.1 总参数和激活参数先分清MoE 的核心是稀疏激活。常规的 FFN 层每个 token 都要过一遍全部权重MoE 则把 FFN 拆成很多个专家网络每个 token 通过路由只选择其中 k 个专家计算。于是就有了“总参数”和“激活参数”的区别。比如一个模型总参数 30B激活参数 3B意思是权重文件有 30B 规模但每个 token 前向只计算 3B 规模的 FFN。这个特性对部署很关键权重显存按总参数算计算量按激活参数算。也就是说MoE 模型在推理时并没有想象中那么慢慢的是权重读入显存和跨卡通信而不是算力本身。Q3.5 的大规模版本基本都走这条路。相比 dense 模型同样算力预算下可以把总参数做得更大模型容量更高相比小参数 dense 模型激活参数相近时MoE 的效果又明显更好。这是 MoE 能在大模型时代站稳脚跟的根本原因。2.2 路由怎么做才不容易失衡路由器一般就是一个线性层输入 token 的 hidden state输出每个专家的得分取前 k。最常见的是 top-2 路由也就是说每个 token 会同时送进两个专家结果再做加权融合。训练初期最大的问题叫“赢家通吃”最好的那个专家总被选中其他专家得不到梯度模型容量没有真正用起来。所以 Q3.5 这类模型都会在训练 loss 里加负载均衡项鼓励 token 尽量均匀地分布到专家上。同时还会设置共享专家让一部分高频通用知识集中在一个永远被激活的专家里路由专家则处理更精细的分工。推理阶段专家并行也会影响延迟不同 token 选择不同专家数据需要在多卡之间通信。网络带宽不够的话MoE 的推理延迟反而可能比 dense 更高。这也是很多团队用 MoE 模型做推理服务时第一个踩到的坑。2.3 混合注意力 MoE 为什么是天生一对把注意力部分和 MoE 部分结合起来看线性注意力解决了长上下文的显存问题MoE 解决了参数规模和计算量的矛盾。两者一起用之后长文本场景的瓶颈就从“注意力计算和 KV 缓存”转移到了“权重显存和跨卡通信”。在固定硬件条件下这意味着你可以部署更大的模型或者在同一模型下塞进更大的 batch。Q3.5 把这两块放在一个架构里本质上是在做资源预算规划显存留给权重计算留给激活注意力尽量不随序列增长。单独看其中任何一个都不算新东西难的是把两者放在同一套训练和推理流程里还能稳定工作。3. 从 Q1 到 Q3.5每一代到底改了什么3.1 Q1 时代把基础打稳Q1 这个阶段整体是标准的 decoder-only Transformer核心贡献更多在于训练数据清洗、稳定训练流程和 RoPE 位置编码的打磨。架构上没有特别激进的新东西主要解决的是“能不能训出来”“效果稳不稳”的问题。现在回看Q1 最重要的价值是验证了一条可复制的训练路径海量高质量数据、长稳定训练、标准化评估。这套东西后来成了整个系列的底座。如果没有 Q1 阶段的工程积累后续做混合注意力和 MoE 时训练稳定性问题会被放大到完全不可控。3.2 Q2 时代GQA 和上下文先走一步Q2 引入了 GQA让多个查询头共享一组 KV 头。KV Cache 从“每个查询头一份”变成了“按组共享”显存立刻省了一大块。同时上下文长度也从早期几千 token 扩展到了 32K 这个量级这靠的不仅是注意力改造还有训练数据里长文本比例的提升。这个阶段也开始尝试 MoE 路线。当时很多人对 MoE 的顾虑是训练不稳定、推理工程复杂但 Q2 的实践证明了在开源模型里做稀疏激活是可行的只是需要付出额外的路由稳定性和通信调度成本。3.3 Q3 时代混合注意力和可配置推理模式Q3 最关键的变化是在部分模型上引入了混合线性注意力而不只是用 GQA 压缩 KV。这是一个质的转变之前是在标准注意力的框架内省资源现在是直接换了注意力的计算范式。另一个重要变化是训练时引入 thinking 模式让模型在回答前可以生成一段内部推理过程。架构开始从“研究 demo”走向“产品功能”。这两个变化叠加在一起意味着 Q3 已经不再是一个“更大版本的 Q2”而是走了完全不同的技术路线。3.4 Q3.5 时代把选择收敛成默认Q3.5 的价值在于收敛混合线性/全注意力从实验配置变成默认架构MoE 成为大规模版本的标准设计thinking 模式也做成可开关的产品选项。演进的主线很清楚每一代都在做同一件事——在固定的算力预算下让模型把计算花在最需要的地方。Q1 在堆数据和训练稳定性Q2 在省 KV 显存Q3 在换注意力范式Q3.5 在做系统整合。每一步单独看都不是颠覆性的但连起来就形成了很明显的代际差异。理解了这条演进线再去看模型配置文件里的各种字段就不会觉得是一堆参数随机组合了。4. 线性注意力的实现细节和推理侧收益4.1 从公式看为什么线性注意力省资源标准注意力Attention(Q,K,V) softmax(QKᵀ / √d)V线性注意力把 softmax 做核分解得到近似形式Attention ≈ φ(Q)(Σφ(Kᵢ)Vᵢᵀ)括号里的 Σφ(Kᵢ)Vᵢᵀ 是一个固定大小的累积矩阵随着序列增长逐 token 累加但尺寸不变。推理时Q3.5 不再为每个 token 保留独立的 K 和 V而是持续更新这个固定大小的状态。这里要特别说明状态矩阵的尺寸取决于隐层维度 d而不是序列长度。所以复杂度主要取决于模型宽度和上下文长度的关系变成了线性甚至接近常数。这是混合注意力模型能撑起超长上下文的核心原因。4.2 层比例怎么配才合适线性注意力层放多了模型会变“健忘”长文档里的细节召回变差放少了长上下文成本又压不下来。从实际效果看1/3 到 1/2 的层用线性注意力是比较合理的起步范围。线性层占比显存收益质量风险适用场景约 1/4中等很低通用对话、短中长文本混合约 1/3明显可控长文档摘要、代码库问答约 1/2显著需要验证超长上下文、高并发推理超过 2/3极大高风险不推荐常规任务使用这个表不是固定标准但它给出了一个判断框架。如果你拿到的模型配置里线性层占比特别高就要留个心眼它的长文本能力可能偏向“能输出”而不是“能准确回忆”。4.3 训练稳定性在混合架构里更敏感线性注意力的梯度路径和标准注意力不一样尤其是在半精度训练下累积状态容易出现数值漂移。常见对策包括线性注意力层用较小初始化、增加学习率预热、在线性层单独调整梯度裁剪。推理侧也有一个容易被忽略的点线性注意力的状态缓存不能用 PagedAttention 那套按页管理的方式因为它的更新是连续矩阵累加不是逐 token 的 KV 缓存。现有推理框架要么把 state 放在独立显存区要么整段缓存处理不好长上下文收益会被显存碎片抵消掉。5. 部署视角显存、吞吐和长文本表现怎么评估5.1 先算一笔 KV Cache 账假设模型层数 L、KV 头数 H、头维度 D、序列长度 S。全注意力的 KV Cache 大小大约是 2 × L × H × D × S × 字节数。线性注意力状态大小大约是 L × H × D × D × 字节数。以 L48、H8、D128、S1M、半精度为例注意力类型单请求缓存大小对应关系全注意力 KV Cache约 196GB随序列长度线性增长线性注意力状态约 12MB与序列长度无关这个数量级差异非常直观同样是 1M 上下文全注意力把显存完全吃死线性注意力几乎可以忽略不计。实际模型里通常还会配合 GQA 和量化KV Cache 会小一些但和固定状态相比仍然是两个世界。5.2 长文本任务的质量观察混合注意力模型在长文本生成上不是“全都好”局部信息密集的任务比如代码补全、对话、摘要抽取表现不错因为线性层已经抓住主要上下文但需要跨长距离多跳推理的任务质量明显依赖全注意力层的比例。所以不要看到“支持 1M 上下文”就觉得所有任务都能吃得下。一个很常见的测试方法是扔给它一段 100K 的日志文本问里面某个具体错误码出现在哪一行。这种任务靠线性注意力不一定行必须靠全注意力层去跨位置精确匹配。如果你的业务全是这类需求选型时就要优先看全注意力层的数量而不是只看上下文上限。5.3 并发和吞吐显存反而成为第一约束部署时很多人盯着算力其实长文本并发场景下最先撞到的是显存。线性注意力让单请求 KV 状态变小后batch size 可以拉高吞吐自然上去。同时 prefill 阶段的计算量大降首 token 延迟会明显改善。但这部分收益在线性层占比低的模型上不明显。选型时最好先确认 config 里具体哪些层是线性注意力而不是只看“支持多长上下文”的营销数字。一个只加了一两层线性注意力的模型本质上还是全注意力模型长上下文该爆显存还是会爆。6. 开发者最容易踩的坑和选型经验6.1 别把总参数当作部署成本同样是 30B 模型dense 和 MoE 的推理差异巨大。看模型配置时先看几个字段num_experts、num_experts_per_tok、线性注意力层编号、kv_heads。这些才真正决定显存和计算量。很多团队在做成本评估时只拿总参数去套公式结果买回来一堆卡却跑不起应有的 batch。MoE 模型正确评估方式是权重显存按总参数算计算量按激活参数算通信开销按专家数量算。三者缺一不可。6.2 线性注意力对量化和精度更敏感很多人在 dense 模型上直接做 INT8 量化很顺利但混合模型里线性注意力层的累积状态对量化误差更敏感。建议先只量化全注意力层线性层保留 FP16或者使用逐层校准。否则长文本下状态误差累积输出质量会明显下降。具体表现是短文本测试没问题一旦上下文超过几万 token回答就开始变差。排查到最后发现是量化误差在状态矩阵里慢慢累积把关键信息给“磨平”了。这个坑很难从单条输出里发现最好用一组固定长度的长文本回归测试去盯。6.3 一个小经验先跑局部任务验证选模型时我会先用一个需要长上下文的简单任务做冒烟测试比如从 100K 文本里找某个精确数字。如果这个任务都过不了架构的其他优点都不用谈了。这个测试成本很低却能把“支持 1M 上下文”这种宣传拉回现实。有一个类似定位的模型官方演示里长文本表现很好但实际部署后发现只是前几千 token 里塞了关键信息长上下文部分是靠位置编码硬撑的。一测就露馅。最后再分享一点个人体会。最开始接触混合线性注意力时我担心的是信息丢失实际上手后才发现真正需要操心的往往是数值精度和推理框架的适配。Q3.5 把线性注意力、全注意力、MoE 整合进同一套架构方向上是把算力预算做得更精细。对普通使用者来说与其纠结总参数大小不如先看清激活参数、线性注意力层占比和 KV 状态大小这三个数据。架构演进说到底就是一句话把每一份算力花在最值得花的地方。