Mixtral 是由 Mistral AI 发布的一系列开放权重稀疏专家混合 (MoE) 语言模型。最著名的检查点是 Mixtral 8x7B 和 Mixtral 8x22B,每个检查点都可用作预训练的基本模型和指令调整的变体。他们的 Apache 2.0 许可证允许广泛的商业使用、修改和重新分发,但须遵守许可证条款。
“8x”这个名字并不意味着八个独立的模型可以回答每个问题。在每个变压器块中,路由器为每个令牌选择八个前馈专家中的两个。注意力和其他组件仍然是共享的。这产生了一个重要的区别:模型必须存储所有专家权重,但只有一个子集参与令牌的前向传递。计算可以类似于较小的密集模型,而内存和分布要求仍然更接近完整的参数足迹。

稀疏专家路由的工作原理
代币表示
|
v
路由器分数
E1 E2 E3 E4 E5 E6 E7 E8
\ /
前2名专家
/\
专家输出 专家输出
\ /
加权合并
|
共享注意力+下一层
路由在每一层和令牌上独立发生,因此提示不会永久选择两个专家。路由器对所选输出进行加权。相对于运行所有专家,稀疏激活减少了前馈计算,但服务效率取决于内核支持、专家放置、批量大小和通信。糟糕的专家并行性可能会消除理论上的节省。
Mixtral 模型变体
| 检查站 | 总参数 | 大约。活跃/令牌 | 已发布的上下文 | 目的 |
|---|---|---|---|---|
| Mixtral 8x7B v0.1 | 约46.7B | 约12.9B | 32K 代币 | 用于完成/微调的预训练基础 |
| Mixtral 8x7B 指令 v0.1 | 约46.7B | 约12.9B | 32K 代币 | 遵循指令和聊天 |
| Mixtral 8x22B v0.1 | 关于141B | 约39B | 64K 代币 | 更大的预训练基础 |
| Mixtral 8x22B 指令 v0.1 | 关于141B | 约39B | 64K 代币 | 更大的指令调整模型 |
值是近似值,因为参数计算在共享组件、词汇和实现之间可能有所不同。始终检查所选存储库的配置,而不是从营销名称中获取容量。最初的 8x7B 报告强调了与 Llama 2 70B 和 GPT-3.5 时代系统相比的强劲结果;这些比较在历史上是有用的,但并不能确定与 2026 年车型的竞争力。
基础与指导
| 变体 | 用它来 | 不要假设 |
|---|---|---|
| 基地 | 研究、持续预训练、领域适应和受控完成 | 可靠的聊天格式、拒绝行为或指令层次结构 |
| 指导 | 使用记录的模板进行助理/聊天任务 | 生产安全、事实或政策合规性,无需外部控制 |
Mistral 的模型卡明确警告预训练的 8x7B 检查点没有审核机制。指令调整提高了可用性,但不保证安全性。对 Instruct 模型使用准确的分词器和聊天模板;临时的提示格式可以极大地改变行为和基准结果。
重量内存:活动参数不要求 VRAM
权重存储的粗略下限是总参数乘以每个参数的字节数。它不包括 KV 缓存、激活、路由缓冲区、量化元数据、框架开销和临时工作区。它还不能保证量化格式在所选加速器上具有优化的内核。
| 型号 | BF16/FP16 配重 | 8位权重 | 4位理论权重 | 实际意义 |
|---|---|---|---|---|
| 8x7B (~46.7B) | 〜93GB | 〜47GB | 〜23GB | 通常是全精度多 GPU;充足的 RAM/VRAM 可以实现量化本地使用 |
| 8x22B(~141B) | 〜282GB | 〜141GB | 〜71GB | 专为大量多加速器基础设施而设计,即使在量化时也是如此 |
这些是算术估计,而不是部署承诺。添加净空并测量实际工件。某些运行时将层或专家卸载到 CPU,以容量换取延迟。统一内存可以使模型加载,同时每秒产生不可接受的令牌。
KV缓存和长上下文成本
KV 缓存随着并发序列、层和缓存令牌的增长而增长。 MoE 稀疏性不会删除共享注意力缓存。 32K 或 64K 最大上下文是能力上限,而不是满足每个请求的指令。长提示会增加预填充延迟并降低批量容量;检索或总结可以更便宜且更准确。
| 负载率 | 效果 | 控制 |
|---|---|---|
| 提示长度 | 更高的预填充时间和 KV 记忆 | 按路线限制上下文;仅检索相关证据 |
| 并发序列 | 乘以实时缓存 | 准入控制、连续批处理和队列限制 |
| 输出长度 | 解码时间和缓存持续增长 | 明确的最大令牌和停止条件 |
| 精度/缓存数据类型 | 改变记忆力和潜在的质量 | 基准支持目标任务的缓存量化 |
| 专家分布 | 跨设备通信可能成为瓶颈 | 使用 MoE 感知张量/专家并行布局 |
服务选项
官方 米斯特拉尔推理 存储库为 Mistral 系列模型提供参考工具。 Hugging Face Transformers 支持 Mixtral 架构,而 vLLM 和其他推理引擎提供生产功能,例如连续批处理和 OpenAI 兼容端点。 llama.cpp/GGUF 生态系统对于量化 CPU/GPU 本地使用很常见,但第三方转换必须追溯到规范检查点并进行测试。
| 运行时 | 很合身 | 领养前检查 |
|---|---|---|
| 米斯特拉尔推理 | 参考行为和 Mistral-本机实验 | 生产调度、可观察性和支持的检查点版本 |
| 变形金刚 | 研究、微调和生态系统灵活性 | 设备映射、注意力后端和 MoE 内核性能 |
| vLLM | GPU 服务具有批处理和 API 兼容性 | 版本特定的 Mixtral 支持、量化和并行拓扑 |
| TensorRT-LLM/TGI | 优化的托管或 NVIDIA 密集型部署 | 构建复杂性、支持的精度和专家并行性 |
| llama.cpp / GGUF | 量化本地、工作站或 CPU 辅助使用 | 转换器来源、RAM 带宽和长上下文延迟 |
量化选择
| 方法 | 效益 | 风险 | 测试 |
|---|---|---|---|
| BF16/FP16 | 最接近参考质量和广泛的内核 | 非常高的内存/成本 | 参考基线 |
| 8位 | 体重记忆大约减半 | 内核/运行时依赖 | 延迟、吞吐量和精确的任务质量 |
| AWQ/GPTQ 4 位 | 大量减少 GPU 内存 | 校准和 MoE 层灵敏度 | 每种语言和长答案的降级 |
| GGUF 量化 | 灵活的 CPU/GPU 卸载 | 转换变体和带宽瓶颈 | 预期卸载时的提示/解码速度 |
永远不要仅仅因为困惑而选择量化。评估工具调用 JSON、代码编译、多语言指令、安全分类、检索基础和长上下文行为。专家路由可能会以不同的方式放大不同输入的错误,因此请使用足够的示例并重复运行。
基准 Mixtral 用于工作量,而不是怀旧
Mixtral 具有影响力,因为它结合了开放许可、2023-2024 年的强大质量和稀疏计算。到 2026 年 7 月,许多较新的密集检查点和 MoE 检查点可提供更好的每内存质量、更长的上下文或本机工具使用。正确的问题是 Mixtral 是否在您的限制下获胜:已拥有的硬件、许可证、可重复性、微调、语言混合和可接受的延迟。
- 创建 100-500 个具有黄金标准和禁止失败的代表性提示。
- 固定检查点修订、分词器、聊天模板、运行时、量化和采样。
- 在相同的上下文和输出限制下进行比较,而不是在供应商默认值下进行比较。
- 测量第一个令牌延迟、每秒解码令牌、并发吞吐量、GPU 内存和总能源/云成本。
- 分别对事实支持、指令遵守、结构化输出、安全性和弃权进行评分。
- 在实际并发情况下重复; MoE 性能可能会随着批次和拓扑的变化而急剧变化。
| 公制 | 为什么这很重要 | 常见的误导性快捷方式 |
|---|---|---|
| 任务成功 | 直接衡量用户结果 | 使用通用排行榜作为代理 |
| p95 首次标记时间 | 互动响应能力 | 仅报告平均解码速度 |
| 并发时的令牌数/秒 | 服务能力 | 单流实验室吞吐量 |
| 总成本/成功率 | 结合硬件和质量 | 比较活动参数计数 |
| 峰值内存 | 确定可行的拓扑 | 仅计算量化权重字节 |
| 故障严重程度 | 区分装饰错误和不安全错误 | 一项总准确度得分 |
安全和生产控制
开放权重使得行为可以在私有基础设施上进行检查和部署,但不提供审核。基础检查点可能会发出不安全的内容;指令检查点可以被越狱、产生幻觉并跟随恶意检索的文本。构建分层系统:
- 使用适合域的策略对请求和输出进行分类。
- Keep retrieved documents untrusted and separate data from system instructions.
- 使用许可名单、架构、超时、配额和人工确认来约束工具。
- 验证模型外部生成的代码和结构化输出。
- 记录模型/检查点/模板版本并保留评估痕迹,而不存储不必要的个人数据。
- 红队多语言和长上下文攻击;该模型的历史语言声明不是覆盖范围保证。
许可和出处
规范的 Mistral AI Mixtral 存储库将检查点标识为 Apache 2.0。这是允许的,但下游微调、量化、数据集和服务可能会引入不同的术语。记录准确的模型修订和哈希值、读取模型卡、保留通知、扫描序列化工件并记录第三方数据义务。 “开源 LLM”并不精确:权重和推理代码可以公开许可,而无需提供完整的训练数据和训练管道。
当 Mixtral 仍然有意义时
| 情况 | 适合 | 原因 |
|---|---|---|
| 现有经过验证的 Mixtral 微调 | 强 | 迁移风险可能超过新基准收益 |
| Apache-2.0 要求 | 强 | 明确的许可检查站许可证 |
| 稀疏MoE路由研究 | 强 | 知名架构和生态系统 |
| 单个小GPU | 弱 | 专家总权重仍然很大;较小的密集模型更简单 |
| 2026年最佳前沿品质 | 弱 | Mixtral 现在是历史一代,而不是 Mistral 的前沿 |
| 无需 MoE 专业知识的高并发服务 | 有条件的 | 拓扑和内核决定稀疏计算是否能真正节省成本 |
替代方案
将 Mixtral 与当前 Mistral 开放模型、当前 Qwen 和 Llama 系列、DeepSeek MoE 检查点、DBRX 和较小的密集指令模型进行比较。不要冻结“最佳”替代方案列表,因为版本发布速度很快。从满足许可证、语言、上下文、硬件和安全要求的检查点创建候选集,然后运行相同的工作负载评估。
| 候选人类型 | 选择它时 | 权衡 |
|---|---|---|
| 较新的密集型 7B–32B | 单节点简单性和内存效率很重要 | 可能提供较少的容量,但通常更好的现代调整/工具使用 |
| 较新的稀疏 MoE | 您可以利用专家并行性并需要质量/计算扩展 | 具有不同许可和生态系统的相同复杂性级别 |
| 托管专有API | 运营和前沿质量比重量控制更重要 | 数据边界、经常性成本和供应商依赖性 |
| 域微调小模型 | 任务范围窄,评估数据强 | 成本较低但通用性有限 |
常见问题解答
Mixtral 8x7B 是一个 80 亿参数模型吗?
不会。它的总参数大约为 46.7B,每个代币激活大约 12.9B。总权重驱动存储和大部分内存需求。
每个代币是否使用全部八位专家?
不会。路由器在每个 MoE 层中为每个令牌选择两名专家,并组合他们的输出。
Mixtral 8x7B 可以安装在 24 GB GPU 上吗?
全精度重量不能。一些激进的 4 位转换接近原始重量预算,但开销和 KV 缓存通常需要额外的 RAM/卸载或更多的 VRAM。测试确切的运行时间。
Mixtral 可以免费用于商业用途吗?
规范检查点在 Apache 2.0 下发布。与顾问核实确切的工件和任何微调、数据集或托管条款。
指导模型是否包括安全调节?
不要将指令调优视为安全层。添加输入/输出策略、工具约束和特定领域的评估。
2026 年 Mixtral 仍然是一个好的默认值吗?
不是自动的。它对于许可许可、已建立的部署和 MoE 研究仍然有价值,但应根据实际硬件和工作负载的当前模型进行基准测试。
来源与验证
- Mistral AI:专家发布的 Mixtral
- Mistral AI:Mixtral 8x22B 版本
- 专家技术论文的 Mixtral
- Canonical Mixtral 8x7B 基本模型卡
- Canonical Mixtral 8x7B 指令模型卡
- Canonical Mixtral 8x22B 基本模型卡
- Canonical Mixtral 8x22B 指令模型卡
- 官方 Mistral 推理存储库
- vLLM 支持的模型文档
上次审核日期为 2026 年 7 月 26 日。运行时支持、模型可用性和比较质量变化。在部署之前固定每个工件并重新运行工作负载评估。