選擇合適的大型語言模型：Llama、Mistral 和 DeepSeek

近年來，大型語言模型 (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氪經授權發佈。