近年来，大型语言模型 (LLM) 广受欢迎，已成为人工智能应用的基石技术。LLM 的应用领域非常广泛，从聊天机器人和虚拟助手，到数据分析和创意写作。随着 Hugging Face 等平台上可用模型的激增，为你的应用选择合适的模型可能会变得非常困难。
在本文中，我们将分析三款领先的开源 LLM——Llama、Mistral 和 DeepSeek——并比较它们在以下几个方面的性能：
(1) 计算需求
(2) 内存占用
(3) 延迟与吞吐量的权衡
(4) 生产部署考量
(5) 安全行为
6) 基准性能。
无论您是初学者还是 AI 工程师，我们都将以通俗易懂的术语和深入的技术讲解关键概念。
1. Llama、Mistral 和 DeepSeek 的计算要求
1.1. 模型大小和 FLOP
每个系列都提供不同参数大小的模型（7B、13B，最多约 65-70B 个参数）。参数数量直接影响每次推理所需的计算量（FLOP）。例如，Llama 和 Mistral 的 7B 模型拥有约 70 亿个参数，相当于生成的每个 token 大约需要 140 亿次浮点运算（前向传播的 FLOP 约为 2P，其中 P 是模型中的参数数量）。像 Llama-2-70B 这样更大的 70B 模型，每个 token 大约需要 1400 亿次 FLOP——每个输出 token 的计算量大约是 7B 模型的 10 倍。DeepSeek 的开放模型有 7B 版本和更大的 67B 版本（类似于 Llama 的 65-70B 范围）。运行 67B DeepSeek 模型所需的计算量几乎与 70B Llama 相同，即每个令牌生成大约 1e11 FLOPs。
1.2. 典型的推理硬件
较小的模型（7B-13B）可以在单个现代 GPU 上运行，而最大的模型则需要多 GPU 或专用硬件。实际上，Llama-3-8B 或 Mistral 7B（旧版）模型可以在配备约 12-16GB VRAM 的消费级 GPU 上运行。例如，Mistral 7B（7.3B 个参数）需要约 15GB 的 GPU 内存才能以全精度加载。Llama-2-13B（13B 个参数）的需求大约是该需求的两倍——建议使用约 24GB 的 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 显存）。如果只有 16 GB 显存，则可能需要内存优化或使用多 GPU 架构。
65B–70B 模型（Llama-3.1–70B、DeepSeek-67B）：需要 2–4 个 GPU 或专用加速器。这些模型在 FP16 中权重约为 130–140 GB，因此无法在单个 GPU 上运行。实际应用中会使用多 GPU 推理或服务器级加速器。
2. 推理和微调的内存要求
2.1. 基本内存需求
所需的原始内存会随着模型大小而增长。对于推理，经验法则是 FP16 模型每个参数占用约 2 字节内存（另加一些开销）。因此，7B 模型大约占用 14-16 GB 内存，而 FP16 的 13B 模型占用约 26-30 GB 内存。实际上，Llama-2 7B 在半精度下占用约 14 GB 内存，并且可以轻松装入 16 GB 的存储卡中。如上所述，65B 及以上模型的内存超过 130 GB，因此需要多个设备。
2.2. 微调记忆
微调需要额外的内存来存储优化器状态和梯度。由于梯度和优化器矩通常也使用 16 位或 32 位精度，FP16 中的完全微调需要大约 2-3 倍的内存来容纳模型大小。例如，如果不使用梯度检查点或低秩自适应等策略，在 24 GB GPU 上微调 13B 模型很可能会运行 OOM（内存不足）。这就是LoRA/QLoRA等技术流行的原因——它们冻结大部分权重并训练少量额外参数，从而大幅减少内存使用量。使用 QLoRA（4 位量化 + 低秩适配器），可以将内存需求减少到全尺寸的一小部分，从而在单个 GPU 上微调 7B 和 13B 模型。查看 LoRA 和 QLoRA 论文，了解有关微调低秩自适应的更多信息。
2.3. 上下文长度和运行时内存
内存的另一个方面是注意力机制的KV 缓存，它会随着上下文中 token 数量的增加而增长。长提示可能会增加内存使用量，因为模型需要为每一层存储键 / 值。Mistral 7B 的滑动窗口注意力机制通过以固定大小的段（例如，4096 个 token 的窗口）处理长上下文来解决这个问题，只需适度增加内存（它不会一次将 整个 长上下文保存在内存中），就可以高效地处理最多约 131k 个 token 的上下文。DeepSeek 版本引入了多头潜在注意力 (MLA)，这是一项压缩注意力键值缓存的新技术，可减少每个 token 的计算量和内存占用。简而言之，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 模型。这意味着您可以使用常用库（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 虚拟机上。为了提高效率，可以使用 TensorRT 或 vLLM 对模型进行容器化。
CPU 和边缘计算：7B 模型（尤其是采用 4 位量化的模型）足够轻量，可以在高端 CPU 上运行。Llama.cpp 等项目通过针对 AVX2/AVX512 指令集进行优化，使得 Llama 7B 能够在笔记本电脑或手机上运行。例如，Mistral 7B 由于其较小的体积和优化，已经在 CPU 上以合理的速度运行，这使其在 GPU 不可用的离线或边缘用例中颇具吸引力。
4.2. 量化和框架支持总结
所有这些模型都支持 Hugging Face Transformers 等库中的 8 位和 4 位量化（通过 Bitsandbytes 或 GPTQ 集成）。它们还可以与服务框架集成：
Transformers + Accelerate：简单灵活，适合制作原型。
vLLM：通过 LLM 完整批处理对吞吐量进行了高度优化（Mistral 为此提供了示例）。
TensorRT-LLM：利用 NVIDIA Tensor Cores 提高速度，支持 Llama 和类似的架构。
Habana Gaudi：GPU 的加速器替代品，Optimum 库中对 Llama 系列模型的支持日益增强（有关更多信息请参阅 Gaudi 部分）。
在实践中，部署开放模型可能涉及权重转换（如果需要）、专用硬件的加载，以及确保拥有良好的监控和防护措施（尤其考虑到这些开放模型默认不具备 OpenAI 式的监控机制）。这就引出了下一个话题：安全考量。
5. 安全考虑
开源模型通常不具备专有模型（例如 OpenAI 的 ChatGPT 或 Anthropic 的 Claude）所具备的强大的安全强化学习和内容过滤器。如果您计划在产品中部署这些开放模型，则必须在其上实现安全层。这可能包括：
内容过滤系统：使用库或较小的模型来检测输出中的仇恨言论、自残等内容，并拒绝或进行后期处理。
及时审核和注入扫描：确保用户输入不包含隐藏指令。
速率限制和使用策略可防止自动利用模型进行恶意目的。
社区正在研究开放模型的对齐技术。例如，有些项目正在对 Llama-2 进行安全指令微调，或使用 GPT-4 来判断和过滤输出（创建“裁判”模型）。但截至 2025 年，开源 LLM 在安全性方面仍明显落后于封闭模型。如果您计划部署这些模型，请注意，它们可能会生成一些不被允许的内容，您有责任根据需要处理这些问题。另一方面是灵活性——有些用户特别希望模型的过滤程度最低（用于研究或创作自由），而开放模型正好满足了这一需求。但请注意，如果存在滥用风险，请勿在没有防护措施的情况下直接将它们部署给最终用户。
6. 基准性能比较
尽管这些模型规模较小且开放，但它们在标准基准测试中表现出色。让我们比较一下 Llama-3、Mistral 和 DeepSeek。它们各自代表了其家族中目前最好的模型，其规模大约为 70 到 80 亿（适用于单个高端 GPU）。我们重点关注它们在知识与推理 (MMLU)、数学问题解决 (GSM8K) 和编码能力 (HumanEval) 等标准基准测试中的表现。下表总结了结果：
表格：约 80 亿个顶级开源模型在知识（MMLU）、数学（GSM8K）和编码（HumanEval）方面的基准准确率/通过率。分数越高越好。每个模型的得分反映了基准测试的准确率（MMLU 和 GSM8K）或通过率（HumanEval）。尽管规模较小，但这些模型取得了优异的成绩，在某些领域缩小了与更大规模模型的差距。
6.1. Llama 3–8B 通用模型
Meta 的 Llama-3-8B 是一款功能全面的通用开放模型，在推理、数学和编码方面均表现出色，同时保持了足够的紧凑性，可在单 GPU 上运行。它在 MMLU 上达到了约 68% 的准确率，在 GSM8K 上达到了约 80% 的准确率，在 HumanEval 上达到了约 62% 的准确率，使其成为同级别中性能最强的基础模型之一。它是一个均衡的模型，能够在各种任务中可靠地执行，且无需特别专门化。对于那些寻求多功能、指令遵循的 LLM 进行聊天、问答和轻量 级编码且无需牺牲性能或多 GPU 设置的开发者来说，它是理想之选。
6.2. Mistral 7B — 高效基础，扎实基础
Mistral 7B 是首个真正挑战更强大竞争对手的开放模型，凭借其高效的架构选择（例如分组查询和滑动窗口注意力机制），它在大多数基准测试中均优于 Llama-2-13B。它在 MMLU 上的得分约为 60%，在 GSM8K 上的得分约为 50%，编码能力一般（HumanEval 约为 26%），但其出色的性能重量比脱颖而出。Mistral 针对速度和更低的内存占用进行了优化，对于资源受限的部署或长上下文应用而言，它仍然是一个强大的基础模型。尽管较新的模型已经超越了它的原始性能，但它仍然是快速推理和可扩展性的热门选择。
6.3. DeepSeek——针对推理和代码优化的 8B 精简模型
DeepSeek 精简后的 8B 模型在同等规模的开源模型中表现最佳，尤其是在数学和代码方面。它在 MMLU 上的得分约为 78%，在 GSM8K 上的得分约为 85.5%，在 HumanEval 上的得分约为 71%，在这些领域中，它的性能堪比甚至超越了之前的 30B+ 模型。这得益于精心设计的训练流程，该流程涵盖了以推理为中心的数据集、思路链提示和强化学习。虽然 DeepSeek 的平衡性不如 Llama 3，但在复杂推理或程序合成中，当用例对精度要求较高时，它表现出色。对于那些正确性高于速度或通用性的应用来说，它是最佳选择。
6.4. 性能与模型大小
即使规模较小，这些约 80 亿参数的模型在极具挑战性的基准测试中也表现出色，令人惊喜。相比之下，像 GPT-4 这样的专有模型得分仍然更高（GPT-4 在 MMLU 上的得分超过 85%），但差距已显著缩小。Llama-3-8B 和 DeepSeek-8B 的表现更是超出预期。Llama 3 的 MMLU 得分高达 60 多分，这曾经是 300-700 亿模型的水平，而 DeepSeek 在 GSM8K 数学上的得分约为 85%，接近更大规模模型的性能。此外，这些模型能够在单个 GPU 上运行，这证明了该领域模型设计和训练技术的快速进步。
总而言之，每种模式都有其独特的优势：
Llama-3–8B是最好的通用小型 LLM，具有知识、推理和代码方面的全面能力。
Mistral 7B性能高效，由于其占用空间小，在理解和推理任务中保持了强大的基础。
DeepSeek 8B（精简版）高度专业化，推动了 8B 模型的数学推理和编码的最新水平
这三款产品都表明，2025 年中期的开放式 8B 规模模型可以提供令人印象深刻的结果，通常可与旧的 13B-30B 模型相媲美或更好，同时保持轻便性和易于使用。
本文来自微信公众号“数据驱动智能”（ID：Data_0101），作者：晓晓，36氪经授权发布。
