679 字
2 分钟
Mixtral 与稀疏专家混合:Mistral AI 的开源之路
2023 年 12 月,成立仅 7 个月的法国初创公司 Mistral AI 发布了 Mixtral 8x7B。
这是一个稀疏专家混合(Mixture of Experts, MoE)模型,总参数 47B,但每个 token 只激活 13B 参数。它在多数基准上超越了 LLaMA 2 70B,甚至超越了 GPT-3.5。
更重要的是,它是完全开源的。
Mixtral 证明了 MoE 架构在大语言模型中的巨大潜力。
本文要点
- Mistral AI 与 Mixtral 背景
- 稀疏 MoE 架构详解
- Expert FFN 设计
- Sliding Window Attention
- 性能与效率分析
- 对开源社区的影响
一、Mistral AI 与 Mixtral 背景
1.1 公司简介
flowchart TB
subgraph Mistral AI简介
A[成立时间]
A --> A1[2023 年 5 月]
B[创始团队]
B --> B1[Arthur Mensch(前 DeepMind)]
B --> B2[Timothée Lacroix(前 Meta)]
B --> B3[Guillaume Lample(前 Meta)]
C[融资]
C --> C1[种子轮:1.13 亿美元(欧洲史上最大)]
C --> C2[A 轮:4.87 亿美元]
D[模型发布]
D --> D1[2023.9:Mistral 7B]
D --> D2[2023.12:Mixtral 8x7B]
D --> D3[2024.2:Mistral Large]
E[定位]
E --> E1[欧洲版 OpenAI,坚持开源]
end
1.2 Mixtral 核心数据
flowchart TB
subgraph Mixtral 8x7B规格
A[架构]
A --> A1[稀疏专家混合(Sparse MoE)]
B[参数量]
B --> B1[总参数:47B]
B --> B2[每个 token 激活:13B(约 28%)]
C[专家配置]
C --> C1[专家数量:8 个]
C --> C2[每层激活:2 个]
D[其他规格]
D --> D1[层数:32]
D --> D2[隐藏维度:4096]
D --> D3[注意力头:32]
D --> D4[上下文长度:32K(滑动窗口)]
D --> D5[词表大小:32K]
E[许可证]
E --> E1[Apache 2.0(完全开源)]
end
二、稀疏 MoE 架构详解
2.1 什么是 MoE?
flowchart TB
subgraph 稠密模型
A1[输入 Token] --> B1[所有参数参与计算]
B1 --> C1[输出]
end
subgraph MoE 模型
A2[输入 Token] --> B2[路由器选择专家]
B2 --> C2[Expert 1]
B2 --> D2[Expert 2]
B2 --> E2["..."]
C2 --> F2[加权组合]
D2 --> F2
E2 --> F2
F2 --> G2[输出]
end
style B2 fill:#4caf50,color:#fff
flowchart TB
subgraph MoE核心概念
A[基本思想]
A --> A1[将模型的某些层(通常是 FFN)替换为多个「专家」]
A --> A2[每个 token 只激活部分专家]
A --> A3[实现更大的模型容量,同时保持较低的计算成本]
B[关键组件]
B --> B1[专家网络(Experts):多个独立的 FFN,每个专家学习处理不同类型的 token]
B --> B2[路由器(Router):决定每个 token 应该由哪些专家处理]
B --> B3[稀疏激活:每个 token 只激活 top-k 个专家,Mixtral 选择 top-2]
C[优势]
C --> C1[更大的模型容量]
C --> C2[更低的推理成本]
C --> C3[更好的性能/效率比]
end
2.2 Mixtral 的 MoE 实现
flowchart TB
subgraph Mixtral MoE 层
A[输入 Token x] --> B[路由器 Router]
B --> C{选择 Top-2 专家}
C --> D[Expert 0]
C --> E[Expert 1]
C --> F["..."]
C --> G[Expert 7]
D --> H["w₀ × Expert₀(x)"]
E --> I["w₁ × Expert₁(x)"]
H --> J[加权求和]
I --> J
J --> K[输出]
end
style B fill:#2196f3,color:#fff
import torchimport torch.nn as nnimport torch.nn.functional as F
class MixtralMoE(nn.Module): """Mixtral 的稀疏 MoE 实现"""
def __init__(self, hidden_dim, intermediate_dim, num_experts=8, top_k=2): super().__init__() self.num_experts = num_experts self.top_k = top_k
# 路由器:决定 token 分配给哪个专家 self.router = nn.Linear(hidden_dim, num_experts, bias=False)
# 专家网络:每个专家是一个 FFN self.experts = nn.ModuleList([ FeedForward(hidden_dim, intermediate_dim) for _ in range(num_experts) ])
def forward(self, x): """ Args: x: [batch_size, seq_len, hidden_dim] """ batch_size, seq_len, hidden_dim = x.shape
# 1. 路由计算 router_logits = self.router(x) # [batch, seq, num_experts]
# 2. 选择 Top-K 专家 router_probs = F.softmax(router_logits, dim=-1) top_k_probs, top_k_indices = torch.topk(router_probs, self.top_k, dim=-1)
# 3. 归一化选中的概率 top_k_probs = top_k_probs / top_k_probs.sum(dim=-1, keepdim=True)
# 4. 计算每个专家的输出并加权求和 output = torch.zeros_like(x)
for i in range(self.top_k): expert_idx = top_k_indices[:, :, i] # [batch, seq] expert_weight = top_k_probs[:, :, i:i+1] # [batch, seq, 1]
# 对每个位置,用选中的专家计算 for e in range(self.num_experts): mask = (expert_idx == e) # [batch, seq] if mask.any(): # 获取需要用这个专家的 token expert_input = x[mask] # [num_tokens, hidden] expert_output = self.experts[e](expert_input)
# 加权累加 output[mask] += expert_weight[mask] * expert_output
return output
class FeedForward(nn.Module): """单个专家的 FFN""" def __init__(self, hidden_dim, intermediate_dim): super().__init__() self.w1 = nn.Linear(hidden_dim, intermediate_dim, bias=False) self.w2 = nn.Linear(intermediate_dim, hidden_dim, bias=False) self.w3 = nn.Linear(hidden_dim, intermediate_dim, bias=False)
def forward(self, x): # SwiGLU 激活 return self.w2(F.silu(self.w1(x)) * self.w3(x))2.3 专家特化现象
flowchart TB
subgraph 专家特化分析
A[研究发现]
A --> A1[不同专家倾向于处理不同类型的 token]
B[示例观察]
B --> B1[专家 0:更常处理数学和数字相关内容]
B --> B2[专家 1:更常处理代码语法]
B --> B3[专家 2:更常处理自然语言描述]
B --> B4[专家 3:更常处理多语言内容]
C[这说明]
C --> C1[专家确实学习到了不同的「专长」]
C --> C2[MoE 不只是简单的参数复制]
C --> C3[稀疏激活有理论依据]
D[注意]
D --> D1[特化不是完全隔离的]
D --> D2[专家之间有重叠]
D --> D3[具体「学到了什么」仍是研究热点]
end
三、Sliding Window Attention
3.1 设计动机
flowchart TB
subgraph 长上下文的挑战
A[标准自注意力的问题]
A --> A1[计算复杂度:O(n²)]
A --> A2[上下文长度翻倍,计算量翻四倍]
A --> A3[32K 上下文需要巨大的计算资源]
B[Sliding Window 的解决]
B --> B1[每个 token 只关注窗口内的 token]
B --> B2[计算复杂度降为 O(n × w)]
B --> B3[窗口大小 w 远小于 n]
C[Mixtral 配置]
C --> C1[窗口大小:4096]
C --> C2[支持上下文:32K]
C --> C3[通过缓存机制实现超长上下文]
end
3.2 工作原理
flowchart LR
subgraph 标准注意力
A1["Token 1"] --> B1["关注所有"]
A2["Token 2"] --> B2["关注所有"]
A3["Token 3"] --> B3["关注所有"]
end
subgraph 滑动窗口注意力
C1["Token 1"] --> D1["窗口内"]
C2["Token 2"] --> D2["窗口内"]
C3["Token 3"] --> D3["窗口内"]
end
def sliding_window_attention(Q, K, V, window_size): """ 滑动窗口注意力
Args: Q, K, V: [batch, heads, seq_len, head_dim] window_size: 窗口大小 """ batch, heads, seq_len, head_dim = Q.shape
# 计算注意力分数 scores = torch.matmul(Q, K.transpose(-2, -1)) / math.sqrt(head_dim)
# 创建滑动窗口掩码 mask = torch.ones(seq_len, seq_len, dtype=torch.bool) for i in range(seq_len): # 每个 token 只能看到窗口内的 token start = max(0, i - window_size + 1) mask[i, :start] = False # 窗口外的位置设为 False
# 应用掩码 scores = scores.masked_fill(~mask, float('-inf'))
# Softmax 和加权求和 attention = F.softmax(scores, dim=-1) output = torch.matmul(attention, V)
return output3.3 与标准注意力对比
| 维度 | 标准注意力 | 滑动窗口注意力 ||---------------|------------------|---------------------------|| 计算复杂度 | O(n²) | O(n × w) || 内存占用 | O(n²) | O(n × w) || 长序列支持 | 差 | 好 || 远距离依赖 | 直接建模 | 通过多层间接建模 || 实现复杂度 | 简单 | 中等 |
Mixtral 的配置:• 窗口大小 w = 4096• 支持序列长度 n = 32768• 计算量减少约 8 倍四、性能与效率分析
4.1 基准测试对比
xychart-beta
title "MMLU 基准测试对比"
x-axis ["LLaMA 2 7B", "Mistral 7B", "LLaMA 2 13B", "Mixtral 8x7B", "LLaMA 2 70B"]
y-axis "准确率 %" 0 --> 80
bar [46, 62, 55, 70, 69]
| 模型 | 参数/激活 | MMLU | HumanEval ||---------------|-------------|-------------|------------------|| LLaMA 2 7B | 7B / 7B | 45.3% | 12.8% || Mistral 7B | 7B / 7B | 62.5% | 26.2% || LLaMA 2 13B | 13B / 13B | 54.8% | 18.9% || LLaMA 2 34B | 34B / 34B | 62.6% | 27.8% || LLaMA 2 70B | 70B / 70B | 69.8% | 32.3% || Mixtral 8x7B | 47B / 13B | 70.6% | 40.2% || GPT-3.5 | - | 70.0% | 48.1% |
关键发现:• Mixtral 在 MMLU 上超越 LLaMA 2 70B• 在代码任务(HumanEval)上表现优异• 推理成本仅为 LLaMA 2 70B 的约 1/54.2 效率分析
| 模型 | 总参数 | 激活参数 | 相对推理成本 ||---------------|-------------|-------------|------------------|| LLaMA 2 70B | 70B | 70B | 5.4x || Mixtral 8x7B | 47B | 13B | 1x(基准) || LLaMA 2 13B | 13B | 13B | 1x || Mistral 7B | 7B | 7B | 0.54x |
MoE 的效率优势:• 47B 总参数,但只激活 13B• 推理成本接近 13B 稠密模型• 性能却接近 70B 稠密模型• 性价比极高4.3 多语言能力
| 语言 | LLaMA 2 70B | Mixtral | 提升 ||---------------|-------------|-------------|------------------|| 英语 | 69.8% | 70.6% | +0.8% || 法语 | 63.4% | 69.2% | +5.8% || 德语 | 62.7% | 68.4% | +5.7% || 西班牙语 | 64.1% | 69.8% | +5.7% || 意大利语 | 61.8% | 68.1% | +6.3% |
Mixtral 在非英语语言上表现更优,可能因为:• 更大的模型容量• 专家可以专门处理不同语言• 训练数据包含更多多语言内容五、与稠密模型的对比
5.1 MoE vs 稠密模型
flowchart TB
subgraph 稠密模型
A1["每层固定参数量"]
A1 --> B1["所有参数参与计算"]
B1 --> C1["计算量随模型线性增长"]
end
subgraph MoE 模型
A2["每层多个专家"]
A2 --> B2["稀疏激活"]
B2 --> C2["计算量与激活参数相关"]
end
D["权衡"] --> E["存储:MoE 需要更多"]
D --> F["计算:MoE 更高效"]
D --> G["性能:MoE 更高性价比"]
| 维度 | 稠密模型 | MoE 模型 ||---------------|------------------|---------------------------|| 参数效率 | 线性 | 更高(容量大) || 计算效率 | 随参数增长 | 随激活参数增长 || 内存占用 | 随参数增长 | 需要存储所有专家 || 训练稳定性 | 稳定 | 需要负载均衡 || 推理延迟 | 随参数增长 | 接近激活参数规模 || 硬件友好度 | 高 | 中(需要优化) |5.2 何时选择 MoE?
flowchart TB
subgraph MoE适用场景分析
A[适合 MoE]
A --> A1[需要高性价比(性能/成本)]
A --> A2[推理资源有限但需要大模型能力]
A --> A3[多任务、多语言场景]
A --> A4[可以接受更复杂的部署]
B[不适合 MoE]
B --> B1[存储资源极其有限]
B --> B2[需要极致的推理延迟]
B --> B3[单一任务场景]
B --> B4[部署环境简单]
C[决策建议]
C --> C1[追求性价比 → MoE]
C --> C2[追求简单稳定 → 稠密模型]
C --> C3[资源充足 → 两者都可]
end
六、对开源社区的影响
6.1 MoE 开源生态
flowchart TB
A[Mixtral 8x7B] --> B[验证 MoE 开源可行性]
B --> C[DeepSeek-MoE]
B --> D[Qwen-MoE]
B --> E[PhiMoE]
B --> F[更多开源 MoE]
G[影响] --> H[降低 MoE 门槛]
G --> I[推动研究进展]
G --> J[商业应用加速]
flowchart TB
subgraph Mixtral的开源影响
A[技术影响]
A --> A1[证明了 MoE 在开源模型中的可行性]
A --> A2[提供了 MoE 实现的参考]
A --> A3[推动了 MoE 相关研究]
B[生态影响]
B --> B1[Hugging Face 上 MoE 模型增多]
B --> B2[vLLM 等推理框架支持 MoE]
B --> B3[量化工具支持 MoE]
C[商业影响]
C --> C1[企业可以在本地部署高性能 MoE 模型]
C --> C2[降低了对闭源 API 的依赖]
C --> C3[推动了 MoE 的商业化应用]
D[后续 MoE 模型]
D --> D1[DeepSeek-MoE:更高效的 MoE]
D --> D2[Qwen-MoE:中文优化的 MoE]
D --> D3[Grok-1:314B 参数的巨型 MoE]
end
6.2 Mixtral 8x22B
flowchart TB
subgraph Mixtral 8x22B规格
A[发布时间]
A --> A1[2024 年 4 月]
B[规格]
B --> B1[总参数:141B]
B --> B2[激活参数:39B]
B --> B3[专家数量:8 个]
B --> B4[每层激活:2 个]
B --> B5[上下文长度:64K]
C[性能]
C --> C1[接近 GPT-4 级别]
C --> C2[多语言能力更强]
C --> C3[代码能力显著提升]
D[许可证]
D --> D1[Apache 2.0]
end
常见问题 FAQ
Q1:MoE 模型的推理速度如何?
A:MoE 模型的推理速度取决于激活参数量,而非总参数量。Mixtral 8x7B 的推理速度接近 13B 稠密模型。
Q2:MoE 模型需要更多显存吗?
A:是的。MoE 需要存储所有专家的参数,即使不激活。Mixtral 8x7B 需要约 90GB 显存存储参数(FP16),但推理时激活计算量很小。
Q3:如何量化 MoE 模型?
A:可以使用标准的量化方法(如 INT8、INT4),但需要注意专家选择的精度。llama.cpp、vLLM 等工具已支持 Mixtral 量化。
Q4:MoE 模型训练更难吗?
A:是的。MoE 训练需要处理负载均衡问题,确保所有专家都被有效利用。还需要特殊的并行策略来处理专家分布。
Q5:Mixtral 可以商用吗?
A:可以。Mixtral 使用 Apache 2.0 许可证,完全开源,可以自由商用、修改和分发。
小结
Mixtral 证明了稀疏 MoE 架构在大语言模型中的巨大价值。
核心贡献:
flowchart TB
subgraph Mixtral核心总结
A[MoE架构] --> A1[47B 总参数,13B 激活,高性价比]
B[性能突破] --> B1[超越 LLaMA 2 70B,接近 GPT-3.5]
C[技术创新] --> C1[Sliding Window Attention,高效长上下文]
D[开源贡献] --> D1[Apache 2.0,推动 MoE 普及]
E[行业影响] --> E1[证明 MoE 是大模型的重要方向]
end
MoE 让大模型在性能和效率之间找到了最佳平衡。
参考资料
- Mixtral of Experts - Jiang et al. 2024
- Mistral 7B - Jiang et al. 2023
- Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer - Shazeer et al. 2017
- GShard: Scaling Giant Models with Conditional Computation - Lepikhin et al. 2020
- Switch Transformers - Fedus et al. 2021
支持与分享
如果这篇文章对你有帮助,欢迎支持作者或分享给更多人
Mixtral 与稀疏专家混合:Mistral AI 的开源之路
https://blog.souloss.com/posts/machine-learning/llm-paper-history/mixtral-and-moe-architecture/ 部分信息可能已经过时
相关文章 智能推荐
1
LLaMA 与开源大模型革命:Meta 的开放之路
AI 深度解读 Meta LLaMA 论文(2023)——7B-65B 参数规模、公开数据集训练、Chinchilla Scaling Law 验证,以及 LLaMA 2 的开源协议演进。
2
Mistral 7B:小而美的开源模型
AI 深度解读 Mistral 7B 论文(2023)——滑动窗口注意力、GQA、Rolling Buffer Cache 等架构创新,Mixtral 8x7B MoE 架构,以及 Mistral 从开源到商业的发展路径。
3
LLaMA 2:Meta 开源模型的里程碑
AI 深度解读 Meta LLaMA 2 论文(2023)——开源大模型、RLHF、ChatGPT 竞争对手
4
GLaM 论文解读:混合专家模型的高效扩展
AI 深度解读 GLaM 论文——Google 如何通过混合专家架构,以三分之一的训练成本实现更好的零样本性能。
5
RWKV:线性注意力的开源替代
AI 深度解读 RWKV——线性注意力机制、时间衰减、Token Shift 与 Transformer 替代架构






