选择正确的法学硕士：Llama vs Mistral vs DeepSeek

Large 语言模型近年来广受欢迎，已成为人工智能应用程序的基石技术。法学硕士以多种不同的方式使用，从聊天机器人和虚拟助手到数据分析和创意写作。随着 Hugging Face 等平台上可用模型的爆炸式增长，为您的应用选择合适的模型可能会让人不知所措。

在本文中，我们将分解三个领先的开源 LLM——Llama、Mistral 和 DeepSeek——并比较它们在 （1） 计算要求、（2） 内存占用、（3） 延迟与吞吐量权衡、（4） 生产部署注意事项、（5） 安全行为和 （6） 基准性能方面的性能。无论您是初学者还是人工智能工程师，我们都会以通俗易懂的术语和技术深度解释关键概念。

1. Llama、Mistral 和 DeepSeek 的计算需求

1.1. 模型大小和 FLOP

每个系列提供不同参数大小（7B、13B、高达 ~65–70B 参数）的型号。参数数量直接影响每次推理所需的计算 （FLOP）。例如，Llama 和 Mistral 的 7B 模型大约有 70 亿个参数，这意味着每个生成的 token 大约有 ~140 亿个浮点运算（前向传递的 FLOP 为 ≈2P，其中 P 是模型中的参数数量）[1]。像 Llama-2–70B 这样更大的 70B 模型需要每个代币大约 1400 亿个 FLOP——每个输出代币的计算量大约是 7B 模型的 10 倍。DeepSeek 的开放式模型有 7B 变体和更大的 67B 变体（类似于 Llama 的 65-70B 范围）[2]。运行 67B DeepSeek 模型将需要与 70B Llama 几乎相同的计算，即每个代币生成大约 1e11 FLOP。

1.2. 典型的推理硬件

较小的型号 （7B-13B） 可以在单个现代 GPU 上运行，而最大的型号需要多 GPU 或专用硬件。在实践中，Llama-3–8B 或 Mistral 7B（传统）型号可以在具有 ~12–16GB VRAM 的消费类 GPU 上提供服务。例如，Mistral 7B（7.3B 参数）需要 ~15GB 的 GPU 内存才能以全精度加载 [3]。Llama-2–13B（13B 参数）大约是该要求的两倍——建议使用 24 GB 左右的 VRAM。较大的型号（Llama 65B/70B 或 DeepSeek 67B）要求要高得多：以 16 位精度运行 Llama-2 70B 至少需要两个高内存 GPU。总结一下：

• 7B/8B 模型（Llama-2–7B、Llama3.1–8B、Mistral-7B、DeepSeek-R1-Distill-Llama-8B）：1 个 GPU（≈15 GB VRAM）足以进行 FP16 推理。这些甚至可以在某些笔记本电脑 GPU 或适度的云实例上运行。
• 13B 型号 （Llama2–13B）：需要 1 个高端 GPU （≈24 GB VRAM）。如果只有 16 GB GPU 可用，则可能需要内存优化或多 GPU。
• 65B–70B 型号（Llama-3.1–70B、DeepSeek-67B）：需要 2–4 个 GPU 或专用加速器。这些模型在 FP130 中具有 ~140–16 GB 的权重，因此它们不适合单个 GPU。实践中使用多 GPU 推理或服务器级加速器（如英特尔的 Gaudi 加速器）。

2. 推理和微调的内存需求

2.1. 基本内存需求

所需的原始内存随着模型大小的增长而增长。对于推理，对于 FP16 模型，经验法则是每个参数 ~2 字节（加上一些开销）。因此，7B 型号的内存约为 14-16 GB，而 13B 型号的 FP16 内存约为 ~26-30 GB。在实践中，Llama-2 7B 可以占用 ~14 GB 的半精度，并且可以轻松安装在 16 GB 卡上。如前所述，65B+ 型号超过 130 GB，因此需要多个设备。

2.2. 用于微调的内存

微调需要额外的内存来处理优化器状态和梯度。FP16 中的完全微调需要内存中大约 2-3 倍的模型大小，因为梯度和优化器矩通常也使用 16 位或 32 位精度。例如，在 24 GB GPU 上微调 13B 模型可能会运行 OOM（内存不足），而无需梯度检查点或低秩适应等策略。这就是为什么像 LoRA/QLoRA [4][5] 这样的技术很受欢迎——它们冻结了大多数权重并训练了少量额外的参数，从而大大减少了内存使用。借助 QLoRA（4 位量化 + 低秩适配器），可以通过将内存需求降低到全尺寸的一小部分来在单个 GPU 上微调 7B 和 13B 模型。查看 LoRA 和 QLoRA 论文，了解有关微调的低秩适应的更多信息 [4][5]。

2.3. 上下文长度和运行时内存

内存的另一个方面是注意力机制的 KV 缓存，它随着上下文中令牌数量的增加而增长。长提示可能会增加内存使用量，因为模型需要存储每一层的键/值。Mistral 7B 的滑动窗口注意力通过处理固定大小段中的长上下文（例如，4096 个标记的窗口）[6]来解决这个问题，允许多达 ~131k 个标记的高效上下文，而内存仅适度增加（它不会同时将整个长上下文保留在内存中）。DeepSeek版本引入了多头潜在注意力（MLA），这是一种压缩注意力键值缓存以减少每个token的计算量和内存量的新技术[7]。简而言之，Mistral 和 DeepSeek 利用架构改进（滑动窗口、MLA 等）来降低所需的计算能力，这意味着相对于原始 Llama 设计，您可以在这些模型中获得更高的每 FLOP 性能。

3. 延迟/吞吐量：了解权衡

在生产环境中提供模型时，延迟和吞吐量之间需要权衡：

• 延迟是为单个输入生成结果所需的时间（聊天机器人响应一个用户问题的速度）。
• 吞吐量是当系统充分利用时，每单位时间可以生成多少个结果（或令牌）（服务器每秒可以生成的令牌总数，或者如果批处理请求，则为每秒响应数）。

这两者经常不和。如果尝试通过同时处理多个请求或长批处理来最大化吞吐量，则每个单独的请求可能会看到更高的延迟（等待批处理中的其他请求）。另一方面，为了为一个用户获得绝对最低的延迟，您可以单独为该用户运行模型，从而充分利用硬件，从而降低总吞吐量。

3.1. 为什么它对不同的用例很重要

对于聊天机器人等交互式应用程序，延迟为王，因为用户希望得到及时响应。0.5 秒和 2 秒之间的差异很明显。因此，您将以有利于快速生成单流的模式运行模型。对于大规模批处理（翻译一百万个文档或分析大型数据集），吞吐量（每秒处理的令牌）比任何单个项目的实时延迟更重要。在这些情况下，向模型提供尽可能大的批次（或并行流）以保持 GPU 100% 忙碌，将提供最快的整体作业完成，即使任何给定文档在队列中等待了一段时间。较小的模型（7B、13B）的每个令牌延迟低于 70B 模型。例如，在同一个 GPU 上，7B 模型每秒可以生成数十个令牌，而 70B 模型每秒可能只生成几个令牌，因为每个步骤的计算量都更大。

3.2. 延迟/吞吐量和用例调整

在生产部署中，系统通常根据用例进行配置。对于聊天机器人或交互式代理，您将在没有（或最少）批处理的情况下运行，优先考虑每个请求的速度。对于非实时批处理作业（如夜间数据处理），可以将数十个输入批处理在一起，以充分利用硬件。现代推理框架甚至允许动态批处理——在短时间内自动对传入请求进行分组，以提高 GPU 利用率（提高吞吐量），而不会增加太多延迟。这可以提供一个中间立场，延迟略有增加，以换取吞吐量的大幅跃升。

总而言之，聊天和交互式应用程序受益于低延迟，而大规模自动化任务则有利于高吞吐量。模型本身不会改变，但运行它们的方式会改变。较小的 Mistral 和 Llama 模型在每个请求中将比大型 DeepSeek 模型更快，但如果您需要最大的准确性并且可以容忍一些延迟（或使用更多硬件进行并行化），那么较大的模型可能值得权衡。

4. 生产部署

将这些模型投入生产涉及软件支持、优化（量化）和服务基础设施等考虑因素。好消息是，Llama、Mistral 和 DeepSeek 模型都与流行的开源工具兼容，并且每个模型都有一个活跃的社区。

4.1. 框架兼容性

这三个模型系列都使用类似 Llama 的 Transformer 架构，因此它们得到了开箱即用的 Hugging Face Transformers 等框架的支持。例如，可以像 Llama 一样使用 AutoModelForCausalLM 加载 DeepSeek 7B 或 67B 模型 [8]。这意味着您可以使用通用库（Transformers、Accelerate 等）来运行推理或微调这些模型，只需进行最少的更改。此外，所有产品都通过 Hugging Face Hub 或直接下载提供模型权重。

部署示例：以下是部署这些模型的一些常见模式：

• 本地 GPU 服务器：许多模型使用 Hugging Face 的 TextGenerationInference 服务器或 API 包装器在单个 GPU 盒（或几个 GPU）上运行这些模型。这对于单个 GPU 上高达 13B 的模型或多 GPU 上更大的模型是可行的。
• 云推理：这三种模型都可以部署在云GPU实例上。例如，AWS Bedrock 提供 Mistral 模型，IBM 的 watsonx.ai 于 2024 年初提供 Mistral 的 8×7B 混合模型（利用 IBM 的 GPU/加速器基础设施）。DeepSeek 模型是开放的，同样可以托管在具有 A100/H100 GPU 的 AWS、GCP 或 Azure VM 上。可以使用 TensorRT 或 vLLM 容器化模型以提高效率。
• CPU 和边缘：7B 型号（尤其是 4 位量化）足够轻，可以在高端 CPU 上运行。像 Llama.cpp 这样的项目通过针对 AVX7/AVX2 指令进行优化，可以在笔记本电脑或手机上运行 Llama 512B。例如，Mistral 7B 由于其较小的尺寸和优化，已在 CPU 上以合理的速度运行，这使其对于 GPU 不可用的离线或边缘用例具有吸引力。

4.2. 量化和框架支持总结

所有这些模型都支持 Hugging Face Transformers 等库中的 8 位和 4 位量化（通过 bitsandbytes 或 GPTQ 集成）。它们还与服务框架集成：

• Transformers + Accelerate：简单灵活，适合原型制作。
• vLLM：针对 LLM 完整批处理的吞吐量进行了高度优化（Mistral 为此提供了示例）。
• TensorRT-LLM：利用 NVIDIA Tensor Core 提高速度，支持 Llama 和类似架构。
• Habana Gaudi：GPU 的替代加速器，在 Optimum 库中越来越多地支持 Llama 家族模型（更多内容见 Gaudi 部分）。

在实践中，部署开放模型可能涉及转换权重（如果需要）、加载专用硬件以及确保拥有良好的监控和护栏（特别是因为这些开放模型默认不附带 OpenAI 风格的监控）。这就引出了下一个话题：安全考虑。

5. 安全考虑

开源模型通常不配备专有模型（如 OpenAI 的 ChatGPT 或 Anthropic 的 Claude）所具有的强大的安全强化学习和内容过滤器。如果计划在产品中部署这些开放模型，则必须在顶部实现安全层。这可能包括：

• 内容过滤系统：使用库或较小的模型来检测输出中的仇恨言论、自残等，并拒绝或后处理它们。
• 提示审核和注入扫描：确保用户输入不包含隐藏指令。
• 速率限制和使用策略，以防止自动利用模型进行恶意目的。

社区正在研究开放模型的对齐技术。例如，有项目根据安全说明对 Llama-2 进行微调，或者使用 GPT-4 来判断和过滤输出（创建“裁判”模型）。但截至 2025 年，开源法学硕士在安全性方面仍明显落后于封闭模型。如果您计划部署这些模型，请注意，它们将生成可能不允许的内容，并且您有责任根据需要解决该问题。另一方面是灵活性——一些用户特别想要过滤最少的模型（为了研究或创作自由），而开放模型填补了这一空白。只是要小心，如果存在滥用的风险，不要将它们直接部署到最终用户，而没有护栏。

6. 基准性能比较

尽管这些模型更小且开放，但它们在标准基准测试中表现出了令人印象深刻的性能。让我们比较一下 Llama-3、Mistral 和 DeepSeek。每个都代表其系列中最好的当前模型，大约在 7-8B 比例上（适合单个高端 GPU）。我们专注于他们在知识与推理 （MMLU）、数学问题解决 （GSM8K） 和编码能力 （HumanEval） 标准基准测试中的表现。下表总结了结果：

表：顶级开源 ~8B 模型在知识 （MMLU）、数学 （GSM8K） 和编码 （HumanEval） 方面的基准准确率/通过率。越高越好。每个模型的分数反映了基准测试的准确率（对于 MMLU、GSM8K）或pass@1率（对于 HumanEval）。尽管尺寸很小，但这些模型取得了强劲的效果，缩小了在某些领域与更大模型的差距。

6.1. Llama 3–8B 通用模型

Meta 的 Llama-3–8B 被证明是一个全面的通用开放模型，在推理、数学和编码方面提供强大的性能，同时保持足够的紧凑性以在单个 GPU 上运行。它在 MMLU 上达到 ~68%，在 GSM80K 上达到 ~8%，在 HumanEval 上达到 ~62%，使其成为同尺寸级别中功能最强大的基本型号之一。这是一个平衡良好的模型，可以在不同的任务中可靠地执行，而无需特别专业化。它非常适合寻求多功能、遵循指令的 LLM 来进行聊天、问答和轻量级编码的开发人员，而不会影响性能或需要多 GPU 设置。

6.2. Mistral 7B — 具有坚实基础的高效基础

Mistral 7B 是第一个真正挑战大型竞争对手的开放模型，由于其高效的架构选择（如分组查询和滑动窗口注意力）而在大多数基准测试中优于 Llama-2–13B。它在 MMLU 上得分为 ~60%，在 GSM50K 上得分为 ~8%，具有适度的编码能力（~26% HumanEval），但以其出色的性能重量比而脱颖而出。Mistral 针对速度和较低的内存使用进行了优化，仍然是资源受限部署或长上下文应用程序的强大基础模型。虽然较新的模型已经超越了其原始性能，但它仍然是快速推理和可扩展性的最爱。

6.3. DeepSeek — 针对推理和代码优化的 8B 蒸馏模型

DeepSeek 的精炼 8B 模型是这种规模的开源模型中表现最好的，尤其是在数学和代码方面。它在 MMLU 上得分为 ~78%，在 GSM85.5K 上得分为 ~8%，在 HumanEval 上得分为 ~71%，在这些领域可与旧的 30B+ 模型的性能相媲美或超过。这是精心设计的训练管道的结果，涉及以推理为中心的数据集、思维链提示和强化学习。虽然不如 Llama 3 平衡，但当用例需要复杂推理或程序合成的高精度时，DeepSeek 表现出色。对于正确性胜过速度或通用性的应用来说，它是顶级选择。

6.4. 性能与模型尺寸

即使尺寸很小，这些 ~8B 参数模型在具有挑战性的基准测试中也能提供令人惊讶的高性能。就上下文而言，像 GPT-4 这样的专有模型仍然得分更高（GPT-4 在 MMLU 上超过 85%），但差距已经大大缩小。Llama-3–8B 和 DeepSeek-8B 的拳头超出了他们的重量（双关语）。Llama 3 的 MMLU 分数在 60 多分左右，曾经是 30-70B 模型的领域，而 DeepSeek 在 GSM85K 数学上的 ~8% 接近更大模型的性能。此外，您可以在单个 GPU 上托管这些模型这一事实证明了该领域模型设计和训练技术的快速进步。

综上所述，每种型号都有其独特的优势：

• Llama-3–8B 是最好的通用小型 LLM，在知识、推理和代码方面具有全面的能力。
• Mistral 7B 提供高效的性能，由于占地面积很小，在理解和推理任务方面保持了强大的基线。
• DeepSeek 8B（蒸馏）高度专业化，推动了 8B 模型数学推理和编码的最新技术

这三款车型都表明，2025 年中期的开放式 8B 比例模型可以提供令人印象深刻的结果，通常与旧的 13B-30B 模型相当或更好，同时保持轻量级和易于使用。

英特尔 Gaudi：在 Gaudi 加速器上运行 LLM

英特尔的 Gaudi 3 AI 加速器专为深度学习工作负载而设计。

对于那些考虑基础设施的人来说，最后要注意的是：所有这些模型都可以在英特尔®台伯™ AI 云上托管的英特尔 Gaudi AI 加速器（如 Gaudi2 和最新的 Gaudi3）上使用。Gaudi 加速器为 NVIDIA GPU 提供了一种替代方案，具有具有竞争力的性价比，用于 LLM 的训练和推理。事实上，英特尔已经优化了对Gaudi上Llama系列模型的支持，例如，Gaudi2使用Optimum Habana库[9]显示，Gaudi2可以运行Llama-2 7B、13B和70B，性能很强。一些早期结果甚至显示，在某些情况下，Gaudi3 在 LLM 吞吐量上略优于 NVIDIA 的 H100 [10]。

要点是，您可以使用 Gaudi 加速器（由 AWS DL1 实例提供）在云实例上部署 Llama、Mistral 或 DeepSeek，通常成本较低。Gaudi 的架构（大型板载内存和高内存带宽）非常适合这些模型，并且随着软件堆栈的不断增长，您可能会看到将 Gaudi 用于开源模型来节省成本和提高性能。我们讨论的所有模型都可以使用 Hugging Face Optimum 等库在 Gaudi 上转换和运行，只需最少的代码更改。这提供了更大的灵活性，并在生产中扩展这些模型时可能具有更高的每美元吞吐量。