博客

前言
在“深度理解DeepSeek与企业实践（第一部分）：蒸馏、部署与评估”和“深度理解DeepSeek与企业实践（第二部分）：原理、硬件冷却与32B多GPU推理性能测试”系列文章中，我们介绍了不同DeepSeek R1模型之间的关系、核心指标，并完成了在ZStack AIOS上部署和评估几个蒸馏模型的工作。根据我们的测试，蒸馏版本在数学和编码等领域的表现往往优于原始模型。然而，对于更复杂的任务（例如，编写数百行代码），它们的性能可能不足。此时，我们需要考虑使用DeepSeek-R1 671B模型，通常在网上被称为“全力版本”。
然而，拥有671B参数的模型非常庞大。如果硬件不支持FP8，仅模型权重就需要1.3TB，使得成本高得令人望而却步。因此，本文重点介绍以最低成本部署近万亿参数的DeepSeek-R1 671B模型，评估量化版本的实际性能，比较与未量化版本的损失，并分析不同硬件配置的成本效益和适用场景。
1. DeepSeek-R1 671B量化版本分析
目前，DeepSeek R1 671B有许多量化方案。我们不会深入探讨IQ_1_S或AWQ等方法的具体含义。相反，我们直接比较几种典型的方案及其VRAM需求如下：
（注：VRAM需求包括最低KV缓存和系统开销，代表最低需求。实际需求取决于上下文窗口大小、KV缓存精度等，需要准确估算。GGUF和safetensor格式由于推理引擎和并行方法不同，VRAM使用情况不同，因此不能直接比较。）
2. 极端压缩解决方案：DeepSeek-R1 671B 1.58位部署实践
从上表中可以清楚地看出，单个3090 8-GPU服务器完全符合671B-1.58b的最低要求！此外，所有权重都可以加载到GPU上，确保了不错的推理速度。但请注意，由于格式是GGUF，需要llama.cpp推理框架。在ZStack AIOS中，支持多个推理框架，允许用户根据自己的需求进行选择。
环境设置
部署过程
1. 环境准备：安装ZStack AIOS，确保系统满足运行要求。
2. 一键部署：
a. 使用ZStack AIOS选择模型，并将其链接到适当的推理模板（llama.cpp）和图像。
b. 指定运行模型的GPU和计算规格，然后部署。
3. 测试运行：在交互窗口中尝试对话体验，或通过API集成到其他应用程序中。
性能评估
我们成功运行了671B-1.58b！不幸的是，由于llama.cpp的分层GPU加载方法，每个层都需要完整的上下文大小才能运行，我们被限制在4K上下文中。此外，由于llama.cpp的推理机制，增加并发性并不能提高总吞吐量，甚至减少了每个会话的上下文大小。因此，我们没有追求更高的并发性。
然而，4K上下文对于DeepSeek-R1来说太小了。响应容易被截断，无法完成MMLU或C-EVAL等标准评估。为了增加上下文大小，我们测试了多机部署DeepSeek-R1-671B-1.58b。
3. 多机扩展解决方案：3090集群部署671B-1.58b评估
由于单个3090上的上下文过于有限，我们通过集群扩展了671B-1.58b模型的上下文。通过在16张卡上分配权重，我们理论上获得了近14GB的空间用于KV缓存，相当于约14K上下文空间。（注：不推荐在生产中使用llama.cpp进行多机并行推理；这仅用于测试。）
环境设置
性能结果
瓶颈分析
长上下文场景显示模型吞吐量略有增加。
由于llama.cpp的架构和3090的带宽限制，更高的并发性并没有有效地提高GPU利用率。
模型能力评估
使用ZStack AIOS的服务评估功能，我们在MMLU、C-Eval、HumanEval等方面测试了DeepSeek-R1-671B-1.58b，比较了其量化性能的各个维度，并与蒸馏版本进行了比较。
由于运行时间过长，一些评估进行了抽样。结果总结如下：
*数据标记为在ZStack实验环境中测试，不是官方论文数据。
**仅有14K上下文，AIME24测试无法正常完成。
从数据来看，1.58量化对性能有一定影响，但影响程度比预期要小。它在英语理解、中文理解和编码能力方面仍然比GPT-4o和Claude-3.5有显著优势。
测试了“识别全力模型”的在线提示，显示出一定的区分能力：
4. 高性能解决方案：H