想象一家大型连锁餐厅的中央厨房。每天成千上万张订单涌进来，按老规矩，每位厨师做菜前都得把从开门到现在所有的历史订单从头读一遍——订单越多，回看的工作量呈平方级爆炸。这就是标准 Transformer 的困境：每个新词都要“回看”所有旧词，上下文一长，计算量就像滚雪球一样失控，墙上的“记忆台账”（缓存）也越贴越满。 Mistral 这家“新派餐厅”做了两处改革：第一，给每位厨师戴上“近窗玻璃”，只需看清最近几十张订单就能掌勺——滑动窗口注意力；第二，让多个服务员共享同一本菜单和台账——分组查询注意力。这两招让“台账”占用和计算开销大幅下降。随后，Mixtral 走得更远：后厨请了 8 位各怀绝技的大厨（专家），但每张订单只由派单员（路由器）挑最擅长的 2 位掌勺，其余 6 位待命。于是餐厅虽然签了 8 份合同（总参数庞大），每道菜却只付 2 个人的工钱（激活参数小），上菜又快又省。 这篇文章，我们就跟着这家中央厨房的进化史，看懂 Mistral 与 Mixtral 如何在不牺牲能力的前提下，把长文本推理的效率推向新高度。

岗位关联

理解 Mistral/Mixtral 的架构权衡，能帮你在模型选型、训练资源分配与推理成本控制上做出更聪明的决策，这是当前开源大模型工程化的核心议题。

目录
  1. 可视化演示
  2. 演进背景：旧厨房为什么撑不住
  3. 滑动窗口注意力：只读最近的订单
  4. 分组查询注意力：服务员共享菜单
  5. 混合专家架构：八位大厨只有两位掌勺
  6. 路由门控机制：派单员的智慧
  7. 工程实践价值：厨房的账本与启示
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

本节配有交互动效（进入视口后自动加载，约 3KB）。

系统可视化 处理流程：输入→处理→模型→输出 性能监控：实时指标 P=L×T

演进背景：旧厨房为什么撑不住

想象那家中央厨房生意最火爆的下午。旧规矩是：每来一张新订单，厨师都得把从开门到现在所有的历史订单从头到尾重新读一遍，才能确定口味和火候。订单张数 n 越多，要读的次数是 n 的平方级别——上午只有 10 张订单时还好，下午到了 10000 张，工作量暴涨 100 万倍。这就是标准 Transformer 的处境：每个新词要“回看”所有旧词（全量自注意力），输入一长，计算量就像滚雪球一样失控。

更头疼的是“记忆台账”。旧厨房为了快速复述，把每张订单的要点（键 Key 和值 Value）都誊抄在墙上。序列越长、注意力头越多，这面墙（KV 缓存）就越大，显卡内存根本装不下。于是 Mistral 团队开始琢磨：这些历史订单真的每一张都值得重新读吗？每个服务员都需要一份专属台账吗？开源社区的竞赛也日趋激烈，谁能把推理效率做上去，谁就能支撑更长的上下文和更低的部署成本。

在技术层面，标准自注意力让第 i 个 token 与前面所有 token 计算两两点积，时间与空间复杂度都是 O(n²)。当上下文从 2K 涨到 32K，计算量和缓存量膨胀约 256 倍，推理延迟和显存双双告急。这直接催生了 Mistral 的两板斧——滑动窗口注意力（SWA）与分组查询注意力（GQA），以及后续 Mixtral 的稀疏混合专家（MoE）架构。

旧厨房的困境，根源在于“一视同仁”：新订单从来不想想，自己真正需要的可能只是最近几张订单的信息。看清了这一点，Mistral 的第一板斧就来了——给每位厨师装上“近窗”。

Attention(Q,K,V)=softmax(QKTdk)V,计算量=O(n2d)\displaystyle \text{Attention}(Q,K,V)=\text{softmax}\left(\frac{QK^{\mathsf{T}}}{\sqrt{d_k}}\right)V, \qquad \text{计算量}=O(n^{2}d)
通俗说：标准注意力让每个词和所有旧词两两“打招呼”，打招呼的次数随词数平方增长，所以文本一长就吃不消。
  1. 点积打分每个查询 Q 与所有键 K 做点积，得到 n×n 的相似度矩阵，这一步让配对次数随序列长度平方增长。
    QKT∈Rn×nQK^{\mathsf{T}} \in \mathbb{R}^{n \times n}
  2. 缩放稳定除以 \sqrt{d_k} 防止数值过大，让 softmax 的梯度更稳定。
    1dk\frac{1}{\sqrt{d_k}}
  3. 概率加权softmax 把分数变成概率，再对 V 加权求和，得到当前词的上下文表示。
    softmax(⋅)V\text{softmax}(\cdot)V
  4. 复杂度来源序列长度 n 翻倍，计算量变成 4 倍，这就是“平方级”的雪球效应。
    O(n2d)O(n^{2}d)

滑动窗口注意力：只读最近的订单

给厨师戴上一块“近窗玻璃”，规定：做菜时只需看最近 w 张订单（比如 20 张），更早的订单一律不读。刚开始厨师们很慌：“万一客户点了今早的隐藏菜单怎么办？”经理笑了笑：“没关系，你上头的厨师手里还有上一段窗口的菜样，信息会一层层传上来。”

Mistral 7B 把窗口设为 4096 个 token。每个位置只与前面 4096 个位置计算注意力，其余位置在掩码中直接屏蔽。这样单层复杂度从 O(n²) 降到 O(n×w)，w 是常数时，就是随序列长度线性增长，长文本能力因此大幅增强。

实现上，滑动窗口注意力用一个掩码矩阵 M 实现：窗口内为 0，窗口外为 -∞，softmax 之后窗口外权重趋近于 0。Mistral 还用了一个“滚动缓存”（rolling buffer）技巧：每层只保留最近的 w 组 K/V，新的进来旧的丢弃，缓存占用与序列长度解耦。值得注意的是，虽然单层只见 4096，但 32 层堆叠后，第 L 层的窗口信息来自第 L-1 层窗口再向前延伸 4096，感受野近似 L×w，约 13 万 token——这就是“多层堆叠视野”的精妙之处。

于是，近窗玻璃并没有让厨房失忆：信息像传菜铃一样一层层往后传递。每个厨师只低头看自己窗口内的订单，但整条流水线拼起来，最后掌勺的大厨能品味到整天的风味。这就是滑动窗口的巧妙——局部视线，全局视野。

Mij={0,i−j≤w−∞,i−j>w,Attnswa(Q,K,V)=softmax(QKTdk+M)V\displaystyle M_{ij}=\begin{cases} 0, & i-j\le w \\ -\infty, & i-j>w \end{cases}, \qquad \text{Attn}_{\text{swa}}(Q,K,V)=\text{softmax}\left(\frac{QK^{\mathsf{T}}}{\sqrt{d_k}}+M\right)V
通俗说：滑动窗口给每个词发了一张“近窗卡”，只能和窗口内的邻居打招呼，窗口外一律免打扰，计算量因此线性增长。
  1. 窗口掩码 M矩阵第 i 行第 j 列表示第 i 个位置能否看第 j 个位置，距离超过 w 就屏蔽。
    Mij={0,i−j≤w−∞,i−j>wM_{ij}=\begin{cases} 0, & i-j\le w \\ -\infty, & i-j>w \end{cases}
  2. 屏蔽生效-∞ 经过 softmax 后概率趋近 0，等于告诉模型“这些旧订单不用看”。
    e−∞→0e^{-\infty}\to 0
  3. 复杂度降低每行只计算 w 次，总计算量 O(n×w)，序列再长也只线性增长。
    O(n2d)→O(nwd)O(n^{2}d)\to O(nwd)
  4. 感受野累积多层窗口叠加，第 L 层可达约 L×w 的范围，长文本仍能间接看到全局。
    receptive field≈L×w\text{receptive field} \approx L \times w

分组查询注意力：服务员共享菜单

注意力机制里，每位服务员（查询头 Q）都要对照菜单（键 K）查价格，再记住配料（值 V）。旧厨房财大气粗，给 32 个服务员每人配了一本完整菜单和一份台账——结果墙上的台账（KV 缓存）贴了满满一面。新经理说：菜单和台账本来就可以共享，四个服务员看同一页不就行了？

这就是分组查询注意力（Grouped Query Attention, GQA）：把 h_q 个查询头分成 h_kv 组，每组共享一份 K/V。Mistral 7B 有 32 个查询头、8 个 KV 头，正好 4 个查询头共享 1 组键值。相比标准多头注意力（MHA），KV 缓存直接除以 4，推理吞吐显著提升。

KV 缓存是推理时每个 token 都要存储的 K、V 向量。它的大小 = 2（K 和 V 两份）× 序列长度 n × KV 头数 h_kv × 每头维度 d_h × 2 字节（半精度）。GQA 让 h_kv 远小于 h_q，缓存占用大幅缩小，显存省下来就能支撑更长的上下文和更高的并发。MQA 是极端版（h_kv=1），省得多但质量下降明显；GQA 是折中的甜点位置，质量接近 MHA——这就是“质量效率权衡”。

服务员们共享菜单后，厨房墙面一下子清爽了。更重要的是，同样大小的厨房（显存）现在能招待更多客人（更高并发、更长对话）。Mistral 的两板斧——近窗加共享菜单——让推理效率大幅提升。而它的姐妹店 Mixtral 则走得更远：不再让所有厨师同时开工。

KV 缓存=2×n×hkv×dh×2 字节\displaystyle \text{KV 缓存} = 2 \times n \times h_{kv} \times d_h \times 2\ \text{字节}
通俗说：KV 缓存就像墙上的订单台账，GQA 让多个服务员共享同一本台账，台账数量少了，墙上的空间自然省出来。
  1. K 与 V 各一份缓存要同时存键和值，所以第一个系数是 2。
    2×n×hkv×dh2 \times n \times h_{kv} \times d_h
  2. 序列长度 n每个 token 的位置都要存一份，上下文越长缓存越大。
    n=4096⇒缓存随 n 线性增长n=4096 \Rightarrow \text{缓存随 n 线性增长}
  3. KV 头数 h_kvGQA 只按共享的 KV 头数计算，头越少缓存越小。
    hkv=8 vs hq=32h_{kv}=8 \ \text{vs}\ h_q=32
  4. 精度系数fp16 下每个数占 2 字节；若用 fp32 则再翻倍。
    ×2 bytes\times 2\ \text{bytes}

混合专家架构：八位大厨只有两位掌勺

Mixtral 的后厨有 8 位各怀绝技的大厨：川菜师傅、粤菜师傅、甜品师傅……如果每道菜都让 8 个人同时上手，厨房挤不下、工资付不起。于是店里立下规矩：每张订单先由派单员判断菜系，只喊最擅长的 2 位大厨掌勺，其余 6 位原地待命。合同上 8 个人的工资照发（总参数量庞大），但每一道菜实际只付 2 个人的工钱（激活参数少），计算成本大幅降低。

在模型结构上，Mixtral 8×7B 把 Transformer 每一层的前馈网络（FFN）替换成“稀疏混合专家”（Sparse MoE）：8 个并行的专家 FFN，外加一个路由器。每个 token 只经过路由器挑选的 2 个专家。整模型总参数量约 46.7B，但每个 token 实际计算只涉及约 12.9B 参数。

设共享注意力部分参数为 N_shared，每个专家参数为 N_exp。总参数 = N_shared + 8N_exp，激活参数 = N_shared + 2N_exp。每个 token 的推理算力约等于 2×激活参数，因此 Mixtral 的推理速度接近同规模稠密 13B 模型，而模型容量与质量却向 47B 稠密模型看齐——这就是“稀疏激活思想”带来的总参大、激活小的革命。

8 位大厨签长约、部分上岗，这招让 Mixtral 在单张 80GB 显卡上就能“开店营业”，上菜速度却接近小厨房。开源社区第一次看到：原来大模型的“雇人”和“干活”可以是两笔账。当然，这一切的前提是派单员足够聪明——这就轮到路由门控机制登场。

Ntotal=Nshared+8Nexp,Nactive=Nshared+2Nexp\displaystyle N_{\text{total}}=N_{\text{shared}}+8N_{\text{exp}}, \qquad N_{\text{active}}=N_{\text{shared}}+2N_{\text{exp}}
通俗说：总参数像餐厅的签约厨师数，激活参数像每道菜真正开工的厨师数；签约 8 位、开工 2 位，成本降为四分之一。
  1. 总参数8 个专家全部存在显存里，一个不能少。
    Ntotal=Nshared+8NexpN_{\text{total}}=N_{\text{shared}}+8N_{\text{exp}}
  2. 激活参数每个 token 只有 2 个专家真正向前计算。
    Nactive=Nshared+2NexpN_{\text{active}}=N_{\text{shared}}+2N_{\text{exp}}
  3. 算力估算前向传播一个 token 的乘加次数约等于 2 倍激活参数。
    FLOPstoken≈2Nactive\text{FLOPs}_{\text{token}}\approx 2N_{\text{active}}
  4. 比例关系8 个专家只激活 2 个，等于把每 token 的 FFN 算力压到 1/4。
    28=14\frac{2}{8}=\frac{1}{4}

路由门控机制：派单员的智慧

派单员是整间厨房的大脑。每张订单进来，他要先读一遍菜品特征（token 的表征），在心里给 8 位大厨打分：“川菜 9 分、粤菜 3 分、甜品 2 分……”，然后请得分最高的 2 位大厨掌勺，最后按分数比例调配两位大厨的出品。如果派单员偏心，天天只喊川菜师傅，其他 7 位就得干等——厨房资源就浪费了。

技术上，路由器是一个线性层 W_r，把 token 表示 x 映射成 8 维分数，再经 softmax 变成概率 p_i。模型选择概率最大的 2 个专家（Top-2 选择），各自的 FFN 输出按概率加权求和。训练时还会加一个负载均衡辅助损失，鼓励路由分布尽量均匀，避免个别专家过载、其他人闲置。

由于路由是逐 token 动态决定的，不同 token 会被分到不同专家。研究发现，Mixtral 的专家会自发专业化（专家专业化）：有的擅长代码和数学符号，有的擅长语法词，有的擅长常识知识。这种“自动分工”正是稀疏混合模型表达能力强的来源。负载均衡损失虽然轻微拉低单个 token 的最优匹配，但显著提高了整体吞吐和并行训练效率。

派单员越公平，厨房的 8 位大厨就越能人尽其才、才尽其用。负载均衡损失就像绩效考核——既鼓励每位大厨钻研自己的绝活，也保证没有人闲得发慌。正是“按需派单 + 均衡考核”的设计，让稀疏模型在训练和推理时都稳稳当当。

pi(x)=e(Wrx)i∑j=18e(Wrx)j,y=∑i∈Top2(p)pi⋅FFNi(x)\displaystyle p_i(x)=\frac{e^{(W_r x)_i}}{\sum_{j=1}^{8}e^{(W_r x)_j}}, \qquad y=\sum_{i\in \mathrm{Top}_2(p)}p_i\cdot \mathrm{FFN}_i(x)
通俗说：路由器先给 8 位专家打分，再请分数最高的 2 位掌勺，最后按比例混合两位大厨的出品。
  1. 门控打分W_r x 把 token 变成 8 个专家的偏好分数。
    (Wrx)i, i=1,…,8(W_r x)_i,\ i=1,\dots,8
  2. softmax 归一化分数变成加起来等于 1 的概率分布。
    pi(x)=esi∑j=18esjp_i(x)=\frac{e^{s_i}}{\sum_{j=1}^{8}e^{s_j}}
  3. Top-2 截取只保留概率最高的 2 个专家参与计算。
    Top2(p)\mathrm{Top}_2(p)
  4. 加权输出两位专家的输出按各自概率加权求和，形成最终结果。
    y=∑i∈Top2(p)pi⋅FFNi(x)y=\sum_{i\in \mathrm{Top}_2(p)}p_i\cdot \mathrm{FFN}_i(x)

工程实践价值：厨房的账本与启示

回到厨房经理的办公室，账本上有两行大字：一行的成本是“雇人”（总参数，决定显存），另一行是“每道菜实际开工的师傅”（激活参数，决定算力）。Mixtral 的聪明之处，就是把这两行账彻底分开算。这对所有想开分店（部署模型）的团队都是福音：雇 8 个人的钱不能省，但每张订单的算力成本已经悄悄降到了 1/4。

从训练策略看，MoE 模型仍然需要把全部专家装入显存做前向/反向传播，所以训练时显存开销按总参数规划，多卡并行是常态；但从推理看，每生成一个 token 的算力只与激活参数成正比。这意味着同样的 GPU 预算，你可以部署一个“容量接近 47B、速度接近 13B”的模型——推理成本控制从此有了新思路。

这一特性直接塑造了开源大模型的工程范式：Mixtral 8×7B 的 46.7B 参数量化后可装入单张 80GB A100，配合 vLLM 等推理框架的 PagedAttention 与专家并行，能以远低于稠密 47B 的成本提供接近的质量。对团队来说，选型时要同时看两个数字——总参数决定存储与带宽需求，激活参数决定每 token 的算力成本；训练资源分配与部署策略都要围绕这两本账来规划，这正是开源 MoE 范式开创的意义。

这家中央厨房的账本，如今成了开源社区的“开店指南”：Mistral 教我们精打细算（窗口 + 共享），Mixtral 教我们人尽其才（稀疏专家 + 均衡路由）。理解这套架构权衡，你就能在模型选型、训练资源分配和推理成本控制上做出更聪明的决策——这正是 Mistral/Mixtral 留给 AI 工程化的最大遗产。

推理算力≈2Nactive,显存占用∝Ntotal\displaystyle \text{推理算力}\approx 2N_{\text{active}}, \qquad \text{显存占用}\propto N_{\text{total}}
通俗说：显存按“签约总人数”备料，算力按“每道菜开工人数”计费——两本账分开算，部署账就清爽了。
  1. 推理算力看激活参数每生成一个 token，只有激活的专家参与计算。
    FLOPstoken≈2Nactive\text{FLOPs}_{\text{token}}\approx 2N_{\text{active}}
  2. 显存看总参数所有专家权重必须驻留显存，否则推理时频繁换页。
    memory∝Ntotal\text{memory}\propto N_{\text{total}}
  3. 资源分配启示训练按总参规划多卡，推理按激活参估算吞吐与成本。
    per-token cost∝Nactive\text{per-token cost}\propto N_{\text{active}}

AI 应用场景

场景一：长对话服务的并发提升

阶段：推理部署与性能优化

解决的问题：传统多头注意力在长上下文下 KV 缓存巨大，显存被大量占用，服务并发量上不去、单用户成本高。Mistral 的滑动窗口 + 分组查询注意力让缓存缩到约 1/4，配合滚动缓存，单卡能承载更多用户和更长对话。

具体案例：某客服机器人从 API 大模型切换到微调的 Mistral-7B，上下文从 2K 提升到 16K，同规格 A100 上并发数反而提升约 3 倍，月度推理账单下降 60%。

场景二：单卡部署“准 47B”开源模型

阶段：模型选型与部署

解决的问题：中小团队预算有限，买不起多卡跑 47B 稠密模型。Mixtral 8×7B 总参 47B、激活仅 13B，单张 80GB 显卡即可推理，质量接近 47B 稠密、速度接近 13B 稠密——“总参大激活小”直接变成账本上的优势。

具体案例：一家创业公司用单张 A100 部署 Mixtral-8x7B 做代码生成助手，配合 vLLM 的专家并行和连续批处理，日请求量达 50 万次，单 token 成本比同等质量稠密模型低约 60%。

场景三：专家路由分析辅助领域适配

阶段：模型分析与定向微调

解决的问题：面对 47B 参数的“黑盒”，团队不知道模型擅长什么、短板在哪。路由门控暴露了内部的“分工表”：统计每个专家被哪些类型的 token 激活，就能定位代码、数学、对话等专门模块。

具体案例：研究团队分析 Mixtral 路由矩阵，发现代码类 token 高度集中在 2 个专家上，于是只微调这两个专家模块，用 1/10 的显存和 1/20 的训练成本，让模型在代码任务上追平了全量微调的效果。

Python 演示

python51 行
import numpy as np  def sliding_window_mask(n, window=3):    # 生成滑动窗口注意力掩码: mask[i,j]=1 表示位置 i 可以看位置 j    mask = np.zeros((n, n), dtype=int)    for i in range(n):        for j in range(max(0, i - window), i + 1):            mask[i, j] = 1    return mask  class MiniMoE:    # 迷你版 Mixtral 稀疏混合专家层: 8 个专家, 每个 token 激活 top-2    def __init__(self, dim=8, n_experts=8, top_k=2, seed=0):        rng = np.random.default_rng(seed)        self.dim = dim        self.n_experts = n_experts        self.top_k = top_k        # 每个专家是一个两层的 MLP        self.w1 = rng.normal(0, 0.15, (n_experts, dim, dim * 2))        self.w2 = rng.normal(0, 0.15, (n_experts, dim * 2, dim))        # 路由器线性层        self.router_w = rng.normal(0, 0.15, (n_experts, dim))     def forward(self, x):        # x: (n_tokens, dim)        scores = x @ self.router_w.T          # 门控打分        probs = np.exp(scores - scores.max(axis=1, keepdims=True))        probs = probs / probs.sum(axis=1, keepdims=True)   # softmax 归一化        top_idx = np.argsort(probs, axis=1)[:, -self.top_k:]  # Top-2 选择        out = np.zeros_like(x)        for t in range(x.shape[0]):            for e in top_idx[t]:                h = np.maximum(x[t] @ self.w1[e], 0)   # ReLU 激活                out[t] += probs[t, e] * (h @ self.w2[e])  # 概率加权求和        return out, top_idx  if __name__ == "__main__":    print("滑动窗口掩码 (窗口=3):")    print(sliding_window_mask(6, 3))     rng = np.random.default_rng(1)    demo = MiniMoE()    tokens = rng.normal(0, 1, (8, demo.dim))   # 8 个 token    out, used = demo.forward(tokens)    print("\n输出形状:", out.shape)    print("每个 token 激活的专家:", used)    counts = np.bincount(used.flatten(), minlength=demo.n_experts)    print("专家被激活频次:", counts)
目的：用 NumPy 从零实现滑动窗口掩码和一个迷你版 Mixtral（8 专家 Top-2 路由），演示 SWA 与稀疏 MoE 的核心逻辑。
  1. mask[i, j] = 1只允许每个位置看自己往前 window 个位置，窗口外保持 0，对应“近窗玻璃”。
  2. scores = x @ self.router_w.T派单员对每个 token 给 8 位专家打分，分数越高越匹配。
  3. probs = probs / probs.sum(axis=1, keepdims=True)softmax 归一化，把分数变成概率。
  4. top_idx = np.argsort(probs, axis=1)[:, -self.top_k:]只挑概率最大的 2 位专家，对应 Top-2 路由。
  5. out[t] += probs[t, e] * (h @ self.w2[e])两位专家的输出按概率加权求和，合成最终结果。

常见误区

误区Mistral 的窗口只有 4096，那它处理不了超过 4096 的长文档，长文本能力肯定很弱。

正解4096 是单层窗口。Mistral 有 32 层，每层的窗口都会在上层的基础上再向前延伸 4096，有效感受野近似 32×4096≈13 万 token。就像传菜铃一层层接力，每个厨师只看眼前 20 张订单，但站在流水线末端的大厨能尝出整天的味道。实测 Mistral 处理 16K~32K 上下文依然游刃有余。

为何常见：把“单层的局部视线”和“整条流水线的全局视野”混为一谈，忽略了多层堆叠的放大效应。

误区Mixtral 有 46.7B 参数，那跑一次推理就得付出 46.7B 参数的计算量，普通显卡根本玩不动。

正解算力要看“激活参数”。Mixtral 每个 token 只激活 2/8 的专家 FFN，激活参数约 12.9B，单 token 算力接近 13B 稠密模型。但注意：显存仍要装下全部 46.7B 参数，这是存储问题。所以“总参管显存、激活参管算力”要分开记。

为何常见：把模型的“存储账本”和“单次计算的工钱”混成一本账，看到 47B 就以为处处都要乘以 47B。

误区8 个专家就相当于 8 个独立小模型，最后大家投票或平均，所以 Mixtral 像是集成了 8 个模型。

正解MoE 不是集成。8 个专家共享同一套注意力层，每个 token 由路由器动态选择 2 个专家并做加权混合，整体是端到端联合训练的。专家只是 FFN 的分工模块，自动形成代码、语法、常识等专业化分工，而不是独立决策的投票者。

为何常见：“8×7B“的名字和”多个专家”的说法，容易让人联想到 bagging/boosting 式的模型集成。

误区共享 KV 头就是信息压缩，压缩必有损失，所以用 GQA 的模型肯定比标准多头注意力差很多。

正解GQA（如 32 个 Q 头配 8 个 KV 头）的质量非常接近 MHA。共享的是 K/V 投影，查询头仍然各算各的，表达能力损失很小；MQA（全部 Q 头共享 1 个 KV）质量下降才明显。GQA 是在 MHA 和 MQA 之间取了一个甜点位置，换来 4 倍缓存节省。

为何常见：把 GQA 和 MQA 混为一谈，或者只看到“共享”两个字，没看到共享粒度的差异。

面试题

Q1. 标准 Transformer 自注意力中，序列长度 n 翻倍，计算量大致变为多少倍？

单选题 · easy

  • A.2 倍，随长度线性增长
  • B.4 倍，随长度平方增长← 正确答案
  • C.8 倍，随长度立方增长
  • D.不变，长度与复杂度无关

答案：B。自注意力需要对 n 个位置两两计算相似度，复杂度 O(n²)。n 翻倍时 n² 变成 4 倍，就像订单从 100 涨到 200，需要回看的历史订单组合不是翻倍而是翻两番。

Q2. Mistral 7B 单层滑动窗口为 4096，堆叠 32 层后有效感受野理论上约为？

单选题 · mid

  • A.仍只有 4096 个上下文位置
  • B.约 13 万 token 的有效视野← 正确答案
  • C.约 128 个 token 的最小窗口
  • D.无限长且完全不受任何限制

答案：B。4096 是单层视线，32 层每层接力延伸，有效感受野约 32×4096≈13 万。正如每个厨师只看眼前订单，信息却沿流水线层层传递，末端大厨仍能掌握全局风味。

Q3. 关于分组查询注意力（GQA），下列说法正确的是？

多选题 · mid

  • A.多个查询头共享同一组键值头← 正确答案
  • B.KV 缓存只按键值头数量计算← 正确答案
  • C.每个查询头都要独享 KV 缓存
  • D.查询头越多 KV 缓存就越大

答案：AB。GQA 把 h_q 个查询头分成 h_kv 组共享 K/V，缓存只与 h_kv 相关，查询头增加不会让缓存变大。C 与 D 描述的正是标准 MHA 的老路，所以错误。

Q4. Mixtral 8×7B 有 8 位专家，每个 token 实际激活的专家数是？

单选题 · easy

  • A.8 位专家全部参与计算
  • B.只有 1 位专家单独计算
  • C.2 位专家参与加权混合← 正确答案
  • D.随机挑选 4 位专家计算

答案：C。Mixtral 每层 8 个专家，路由器对每个 token 只挑选 top-2 专家参与加权计算，其余 6 位待命。若 8 个全参与就退化成了稠密模型，失去了稀疏激活的意义。

Q5. 关于 MoE 模型的显存与算力，正确的说法是？

单选题 · mid

  • A.显存按激活参、算力按总参数
  • B.显存按总参数、算力按激活参← 正确答案
  • C.显存算力都只按激活参数算
  • D.显存算力都按总参数来计算

答案：B。推理时所有专家权重必须装入显存，显存按总参数 46.7B 规划；但每个 token 只有 2 个专家参与计算，算力按激活参数约 12.9B 估算。存储与算力的账要分开记。

Q6. 路由器输出 8 维分数并经 softmax 得到概率，选择专家的标准是？

单选题 · hard

  • A.概率最小的两位专家上场
  • B.概率最大的两位专家上场← 正确答案
  • C.分数低于阈值的专家上场
  • D.固定编号的前两位专家上场

答案：B。路由器对 8 位专家打分后，取概率最大的两位作为激活者，这就是 Top-2 路由。最小概率、阈值截断或固定编号都不符合门控网络的动态派单设计。

Q7. GQA 能把 KV 缓存压缩到原来的 1/4（Mistral 7B），核心原因是什么？

单选题 · mid

  • A.减少了键值头总数 h_kv← 正确答案
  • B.增加了查询头总数 h_q
  • C.增大了每个头维度 d_h
  • D.把浮点精度提升到 fp32

答案：A。GQA 缓存大小是 2×n×h_kv×d_h，只有降低 h_kv 才能直接缩小缓存。Mistral 用 32 个查询头配 8 个 KV 头，缓存缩到 MHA 的 1/4；增加查询头或维度只会增加计算，不会省钱。

Q8. 滑动窗口注意力中，掩码矩阵把窗口外位置的值设为？

单选题 · easy

  • A.负无穷，softmax 后权重趋近零← 正确答案
  • B.正无穷，强化远距离位置信息
  • C.零，表示窗口外也正常参与
  • D.一，让所有位置权重完全相等

答案：A。掩码把窗口外位置设为 -∞，e^{-∞}→0，softmax 后权重趋近零，等于告诉模型“这些旧订单不用看”。设为 0 或正数都无法屏蔽窗口外的多余信息。

Q9. 下列哪些属于 Mixtral 相对于传统密集模型的设计？

多选题 · hard

  • A.稀疏混合专家替换稠密前馈层← 正确答案
  • B.路由器按 token 动态选择专家← 正确答案
  • C.每个 token 固定激活全部专家
  • D.专家输出按门控概率加权求和← 正确答案

答案：ABD。Mixtral 用 8 个专家的稀疏 MoE 替换稠密 FFN，路由器逐 token 选 2 个专家，输出按概率加权求和。C 说固定激活全部专家，与稀疏激活的设计相悖，所以不选。

Q10. 关于 MoE 训练中的负载均衡，下列说法正确的有？

多选题 · extreme

  • A.避免个别专家过载而其他人闲置← 正确答案
  • B.通过辅助损失鼓励路由分布均匀← 正确答案
  • C.负载均衡会显著降低模型表达力
  • D.专家专业化与负载均衡可以并存← 正确答案

答案：ABD。负载均衡通过辅助损失让路由分布均匀，避免个别专家过载、他人闲置，同时专家仍可自发专业化，二者可共存。说它显著降低表达力属于夸大其词——实际收益远大于轻微的最优匹配偏差。