Mistral vs Mixtral: Comparing the 7B, 8x7B, and 8x22B Large Language Models-深圳市維司達科技有限公司

原文：towardsdatascience.com/mistral-vs-mixtral-comparing-the-7b-8x7b-and-8x22b-large-language-models-58ab5b2cc8ee

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/c786479c0681aca9bea89472b44f05f8.png

Image by Img IX, Unsplash

不久前，所有 IT 新闻频道都在报道新的开源 Mixtral 8x22B 模型，该模型在 MMLU（大规模多任务语言理解）或 WinoGrande（常识推理）等基准测试中优于 ChatGPT 3.5。这对于开源模型的世界来说是一个巨大的成就。当然，学术基准测试很有趣，但这个模型在实际中是如何工作的呢？它有什么系统要求，它真的比之前的语言模型更好吗？在本文中，我将测试四种不同的模型（7B、8x7B、22B 和 8x22B，包括和不包括“专家混合”架构），我们将看到结果。

让我们开始吧！

作为一个附带说明，我与 Mistral AI 没有任何商业关系，这里的所有测试都是我自己进行的。

稀疏专家混合（SMoE）

在 LLM 时代初期，就已经知道，一般来说，更大的模型更聪明，知识更多，可以达到更好的结果。但更大的模型也更耗费计算资源。如果聊天机器人需要 5 分钟才能回复，没有人会等待。专家混合背后的直观想法很简单——让我们取几个模型，并添加一个特殊的层，将不同的问题转发到不同的模型：

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/f2b3bba4a461d08be30e0a3f0b60b976.png

Image from the paper (Shazeer et al 2017)

如我们所见，这个想法并不新鲜。关于 MoE 的论文于 2017 年发表，但直到 5-7 年后，当模型的使用从学术转向商业视角时，它才变得重要。MoE 方法给我们带来了显著的改进：我们可以拥有一个知识丰富的语言模型，同时它的工作速度像较小的模型一样快。例如，Mixtral 8x7B 模型有 47B 个参数，但任何给定时间只有 13B 个参数是活跃的。Mixtral 8x22B 模型有 141B 个参数，但只有 39B 个是活跃的。

现在，当我们对它有一个大致的了解后，是时候看看它实际上是如何工作的了。在这里，我将测试 4 个模型：

一个 Mistral 7B 模型，该模型于 2023 年 10 月发布。
一个 Mixtral 8x7B，该模型于 2024 年 1 月发布。
一个 Mixtral 8x22B，该模型于 2024 年 4 月发布。
一个由爱好者从 8x22B 模型制作的“非官方” Mistral 22B 模型。我将只使用这个模型来比较速度和 RAM 要求。

我将在 Google Colab Pro 上运行所有测试，在撰写此帖子的时，这个订阅每月花费我 11.2 欧元。这个订阅每月提供 100 个所谓的“计算单元”。对于这个测试，我将使用 “TPU v2” 实例，它有 334 GB 的 RAM – Colab 中唯一能够运行 8x22B 模型的虚拟机。这个虚拟机的价格是每小时 1.76 个“计算单元”，这对于这种测试来说是足够的。作为额外的好处，我还会对 7B 和 8x7B 模型进行测试，使用 40 GB 的 A100 GPU。

代码

在测试模型之前，让我们准备一些代码。首先，我们需要下载所有模型：

!pip3 install huggingface-hub hf-transfer# 7B Model!export HF_HUB_ENABLE_HF_TRANSFER="1"&amp;&amp;huggingface-cli download TheBloke/Mistral-7B-Instruct-v0.1-GGUF mistral-7b-instruct-v0.1.Q4_K_M.gguf--local-dir/content--local-dir-use-symlinksFalse# 8x7B Model!export HF_HUB_ENABLE_HF_TRANSFER="1"&amp;&amp;huggingface-cli download TheBloke/Mixtral-8x7B-Instruct-v0.1-GGUF mixtral-8x7b-instruct-v0.1.Q4_K_M.gguf--local-dir/content--local-dir-use-symlinksFalse# 22B Model!export HF_HUB_ENABLE_HF_TRANSFER="1"&amp;&amp;huggingface-cli download bartowski/Mistral-22B-v0.2-GGUF Mistral-22B-v0.2-Q4_K_M.gguf--local-dir/content--local-dir-use-symlinksFalse# 8x22B Model!export HF_HUB_ENABLE_HF_TRANSFER="1"&amp;&amp;huggingface-cli download MaziyarPanahi/Mixtral-8x22B-Instruct-v0.1-GGUF Mixtral-8x22B-Instruct-v0.1.Q4_K_M-00001-of-00002.gguf--local-dir/content--local-dir-use-symlinksFalse!export HF_HUB_ENABLE_HF_TRANSFER="1"&amp;&amp;huggingface-cli download MaziyarPanahi/Mixtral-8x22B-Instruct-v0.1-GGUF Mixtral-8x22B-Instruct-v0.1.Q4_K_M-00002-of-00002.gguf--local-dir/content--local-dir-use-symlinksFalse

它不快，下载可能需要大约一个小时。最小的 7B 模型大约有 4 GB 的大小，最大的 8x22B 模型大约有 90 GB。至少这些模型已经转换成了 4 位格式；否则，文件大小可能是 4 倍。

作为下一步，让我们创建一个辅助函数来加载模型。我将使用 llama-cpp：

fromllama_cppimportLlamadefload_model(model_file:str):""" Load the model from file """returnLlama(model_path=model_file,n_ctx=4096,# The max sequence length to useuse_mmap=False,# Don't use nmap (load full model in RAM))

在这里，我将 “use_mmap” 设置为 False。默认情况下，llama-cpp 使用一个内存映射文件来加载模型。这很好，允许我们使用实际上比可用 RAM 大的模型（作为一个有趣的测试，我甚至能在我的智能手机上运行一个 70B 的模型在 Android 手机上运行 llama 和 gemma AI 模型）。但这对基准测试可能不是很好，因为很难知道完整的 RAM 使用情况，并且在使用内存映射模型的情况下，我们实际上是在测试磁盘的速度，而不是实际推理的速度。

现在，让我们准备一个测试。从理论上讲，我们可以使用 lm-eval Python 库运行一个完整的 GSM8K 或 TriviaQA 基准测试，但这些测试包含数百个问题。这将花费数小时，而且实际上没有意义；所有公开模型的“官方”基准结果已经在线上发布。只是为了看看模型是如何工作的，我创建了一个包含六个问题和辅助方法的测试列表：

questions=["Who was the next British Prime Minister after Arthur Balfour?",# A: Sir Henry Campbell-Bannerman"In which decade did stereo records first go on sale?",# A: "1950's"Which Lloyd Webber musical premiered in the US on 10th December 1993?",# A: "Sunset Boulevard""James decides to run 3 sprints 3 times a week. He runs 60 meters each sprint. How many total meters does he run a week?",# A: 540 meters"In a danceclassof40students,20%enrolledincontemporary dance,25%of the remaining enrolledinjazz dance,andthe rest enrolledinhip-hop dance.What percentage of the entire students enrolledinhip-hop dance?",# A: 60% of the entire students"John has 110 coins. There are 30 more gold coins than silver coins. How many gold coins does John have?",# A: 70 coins]defmake_request(model:Llama,question:str)->str:""" Make request to a model """prompt=f"You are an expert. Make an answer to the following question:{question}"output=model(f"<s>[INST]{prompt}[/INST]",# Promptmax_tokens=4096,# Generate up to 4096 tokenstemperature=0.0,# We don't need randomnessecho=False,# Whether to echo the promptstream=True# Use streaming)forchunkinoutput:print(chunk["choices"][0]["text"],end='')sys.stdout.flush()print("n------")

现在，我们准备好进行有趣的部分了！

实验

到目前为止，我们有了加载模型和提出几个问题的代码。让我们将这些部分组合起来：

ram_start=psutil.virtual_memory().used model_file="..."llm=load_model(model_file)# A warm-up question to initialize the modelmake_request(llm,"Hello")ram_end=psutil.virtual_memory().usedprint("RAM:",ram_end-ram_start)# Startt_start=time.monotonic()forq_strinquestions:make_request(llm,q_str)t_diff=time.monotonic()-t_startprint(f"Total time:{t_diff:.2f}s ({t_diff/len(questions):.2f}s/request)")

在这里，我还使用了 “psutil” 库来获取内存消耗；其他代码部分是自解释的。

现在，让我们运行测试。

Mistral 7B

模型的 RAM 使用量：4,930,879,488 字节。

总时间：133.79 秒（每个请求 22.30 秒）。根据 Llama-cpp 日志，平均速度约为 7.87 个标记/秒（提醒一下，模型在 CPU 上运行，并不快）。

正确答案：1: -, 2: +, 3: -, 4: -. 5: +, 6: +。

如我们所见，7B 模型是可行的，但它无法回答一半的问题。尽管如此，答案还是足够好的；例如，这是模型对最后一个问题的回答：

Let's use algebra to solve this problem:Let G be the number of gold coinsandS be the number of silver coins.We know that the total number of coinsis110,so we can write our first equationas:G+S=110We also know that there are30more gold coins than silver coins,so we can write our second equationas:G=S+30Substitute this expressionforG into the first equation:(S+30)+S=110SimplifyandsolveforS:2S+30=1102S=80S=40Now that we know there are40silver coins,we can use the second equation to find the number of gold coins:G=S+30G=40+30G=70So John has70gold coins.

对于一个只有 4 GB 大小且几乎可以在任何硬件上本地运行的模型来说，这是一个很好的响应。但显然，这么大小的模型有其局限性。

Mixtral 8x7B

模型的 RAM 使用量：26,997,256,192 字节（比 7B 模型高 5.5 倍）。

总时间：338.44 秒（每次请求 56.41 秒）。根据 Llama-cpp 日志，生成速度约为每秒 5.05 个标记，这仅略慢一些。但与 7B 模型相比，总处理时间几乎长了一倍。原因是什么？我不知道。生成的标记数量可能不同，因此可能需要更好的提示才能获得更准确的结果。

正确答案：1: -, 2: +, 3: +, 4: +, 5: +, 6: +。

如我们所见，与较小的模型相比，8x7B 模型明显更好。

“Mistral”（非官方）22B

模型的 RAM 使用量：14,307,201,024 字节。

正确答案：无。

该模型的生成速度为每秒 3.1 个标记，但总时间未知，因为我停止了测试。模型根本无法正常工作；它产生了像这样的胡言乱语：

mermaid quadrantChart code syntax example.DONT USE QUOTO IN CODE.title Reachandengagement of campaigns,"Campaign: A":[0.3,0.6]"Campaign B":[0.7,0.4]## Product Goals```python

如文章开头所述，此模型仅用于比较 RAM 和处理速度。

Mistral 8x22B

模型的 RAM 使用量：86,716,272,640 字节。

总时间：710.54 秒（每次请求 118.42 秒）。根据日志，生成速度为每秒 1.82 个标记。

正确答案：1: +, 2: +, 3: +, 4: +, 5: +, 6: +。

的确，该模型做得很好，所有答案都是正确的。但它也有其代价：正如我们从测试中看到的那样，8x22B 模型比 7B 模型慢 5.3 倍，比 7x8B 模型慢 2.1 倍。至于 RAM 要求，8x22B 模型比 8x7B 模型多 3.3 倍，比 7B 模型多 17.7 倍。

奖励

在之前的测试中，我使用 CPU 推理，因为这是在 Google Colab 上运行 8x22B 模型的唯一选项。但作为对读者的一个小奖励，我可以比较 7B 和 8x7B 模型在40 GB A100 GPU上的表现。这使我们能够看到更真实且“生产就绪”的性能比较。

搭载 A100 GPU 的机器在 Google Colab 上可用，但其价格要高得多（每小时 11.7 个“计算单元”），而且这类机器的数量并不多。实际上，A100 很少可用，大约在 90% 的尝试中，我只收到“所选 GPU 不可用”的消息。无论如何，在一天中尝试了 5-10 次之后，我最终能够连接上了。

结果看起来是这样的：

对于 7B 模型，总测试时间为 10.70 秒（每次请求 1.78 秒）。
对于相同硬件上的 8x7B 模型，总时间为 24.2 秒（每次请求 4.03 秒）。

如我们所见，即使在顶级的 A100 GPU 上，8x7B 模型也比 7B 模型慢 2.2 倍。有趣的是，两种模型在 CPU 和 GPU 运行中的比例几乎相同。

结论

在这篇文章中，我测试了一个基于稀疏混合专家（SMoE）架构的 8x22B Mixtral 模型，结果很有趣。

从测试中我们可以看出，SMoE 仅略微提高了 RAM 效率，完整模型及其“专家”子模型仍然需要加载到 RAM 中。以柱状图的形式，它看起来是这样的：

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/2d539516b0cfcd73066ac801d05fc4c4.png

RAM 需求，图片由作者提供

速度提升更为显著：8x7B 模型比 7B 模型慢 2.5 倍，而 8x22B 模型慢 5.33 倍：

https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/8992426fa591c2d74c4beaf9015cf2b9.png

CPU 推理秒数，图片由作者提供

无论如何，SMoE 不是一个“万能药”，更大的模型仍然需要更多的资源。但一个 141B 参数的模型与一个小的 7B 模型相比，“仅”慢 5.3 倍，这是一个很好的改进。最后但同样重要的是，运行优于 GPT 3.5 的模型的可能性真的很令人兴奋。

从实际的角度来看，8x22B 模型对于许多应用来说仍然“沉重”。至少在 2024 年，不是很多人能访问到拥有 90GB GPU RAM 的计算机。根据基准测试结果，8x7B 模型在 TriviaQA（基于文本的问答数据集）上的得分为 78.4%，而 8x22B 模型的得分为 82.2%。从商业角度来看，这 4%有意义吗？考虑到硬件成本的不同，这显然取决于用例；至少，有一个选择是好的。

感谢阅读。如果您喜欢这个故事，请随意订阅Medium，您将收到我新文章发布的通知，以及访问来自其他作者成千上万故事的完整权限。您也可以通过LinkedIn与我建立联系。如果您想获取这篇文章和其他文章的完整源代码，请随意访问我的Patreon 页面。

对那些对使用语言模型和自然语言处理感兴趣的人来说，也欢迎阅读其他文章：