DeepSeek 32B多卡推理的原理、硬件散热与性能实测

DeepSeek 32B多卡推理的原理、硬件散热与性能实测

引用

网易

1.

https://m.163.com/dy/article/JOAI6MH505387208.html

随着大语言模型参数规模的不断扩大，单卡显存已经难以支撑其完整运行。本文将以部署DeepSeek-Distilled-Qwen-32B为例，深入探讨多卡并行的原理、服务器多卡硬件部署的注意事项。此外，我们还将对32B模型的运行性能、推理能力进行评估，对该模型适合的场景进行分析和建议。

32B 模型部署所需显存评估

在部署32B模型时，不同的精度、上下文长度和batch size对显存和算力的需求有着显著影响。其核心影响因素我们在前文有过介绍，这里不再重复介绍而直接给出评估的值：

考虑到现在各种量化方法的复杂性（例如数据打包、FP8格式量化等等），写Int8、Int4已经不太准确，所以在这里简单用8位量化、4位量化来估计。此外可能还会因为不同层的量化策略、数据结构的精度、是否开启KV Cache量化，或者使用不同的推理框架也可能导致数据存在出入。

多卡推理的原理解析

根据前面的计算可以发现当使用很大的上下文、特别是精度比较高的数据精度时，单卡很难满足其显存需求。目前常见的民用卡显存普遍为24GB以内，常用的推理卡为48GB，少数较为高端的GPU可以达到64～141GB的显存。

因此，在32B及其以上参数的模型服务上，多卡推理基本上是必然选择，目前主要的多卡并行策略包括张量并行（Tensor Parallel）和流水线并行（Pipeline Parallel）。

1. 张量并行（Tensor Parallel）

将单个张量按维度拆分，跨多个GPU并行计算相同的操作。

• 优点：计算和通信可以重叠，提升效率。
• 缺点：实现复杂度高，对GPU间的通信带宽和延时要求较高，需要按2的整数次幂如2、4、8、16来拆分。

2. 流水线并行（Pipeline Parallel）

将模型的不同层分配到不同的GPU，上下游GPU按序传递激活值，类似生产线的方式。

• 优点：减少了同步通信的开销，对通信带宽和延迟要求更低。
• 缺点：可能出现流水线空泡，导致资源浪费。

根据上面的表格，可以理解为张量并行更有利于提升整体的吞吐，但是流水线并行实现相对简单也适合CPU、GPU混合推理的场景，因此llama.cpp（ollama所采用的推理引擎）使用了流水线并行，这也是llama.cpp的多卡性能相对比较弱的原因。

服务器硬件部署与GPU配置

1. 2U服务器安装多GPU的挑战

根据前面的内容，我们可以发现服务器安装GPU最好是2的整数次幂，例如2、4、8、16卡，这样可以通过张量并行最好发挥性能，然而对于当前用户常用的2U服务器来说，安装2张GPU一般是没太大问题的，但4张GPU可能就会存在挑战

如上图，我们常用的GPU为双宽尺寸，也就是要占用两个PCIe槽位，然而即使我们不考虑其他设备占用槽位的情况，也只能在常见的2U服务器上安装三张GPU，由于不符合2的整数次幂，因此只有两张能发挥最大作用。

2. 解决方案

• 减少前面板硬盘数量：为散热和空间腾出位置，使用大容量硬盘替代多个小容量硬盘。
• 采用针对安装多GPU模组：对于一些服务器厂商，其设计有专门的GPU模组，将整个上面1U空间留作GPU安装，此时可以最多并排放入4双宽张GPU。

此时，我们的前面板需要预留风道散热，因此前面板只能放8个3.5寸硬盘，需要采用较大容量的硬盘以确保容量充足。

如果希望还有更多的硬盘或者更好的散热的话则需要3U或4U或更高的服务器了，具体可以结合机柜供电、GPU功耗来确认最佳方案。

在AIOS智塔上一键部署DeepSeek-Distilled-Qwen-32B

1. 部署步骤

环境配置

部署步骤

1. 环境准备：安装ZStack AIOS智塔，确保系统满足运行要求
2. 一键部署：
3. 使用ZStack AIOS智塔选择模型并进行加载
4. 指定运行该模型的GPU规格和计算规格后即可部署
5. 测试运行：在体验对话框中可以尝试对话体验或者通过API接入到其他应用

2. 性能评估

借助ZStack AIOS智塔的性能评测，可以快速对模型在当前硬件上的性能进行评测，数据总结如下：

结合上述评测的结果我们可以对当前环境的情况进行一个分析。

吞吐量（TPS）与并发数的关系

• 并发数从1提升到16时，TPS呈现显著增长（23→256），但达到32并发时TPS增速大幅放缓（仅提升15%）
• 推荐并发区间：4-16并发可获得较好的吞吐收益
• 峰值拐点：当并发超过16时，系统接近性能瓶颈

响应延迟的关键发现

• TTFT（首响应时间）在32并发时剧增至25秒（对比1并发时的0.06秒）
• 总延迟在32并发时超过64秒，是低并发的2.7倍
• 实时性场景建议：对响应速度敏感的场景（如对话系统）应保持并发≤4

资源效率分析

• 单并发的会话吞吐为23.248，而32并发时降至9.198（降幅60%）
• 每个新增会话的边际效益在16并发后明显衰减
• 资源优化建议：建议通过16并发*多实例部署的方式扩展，而非单实例高并发

不同场景的推荐配置

结合ZStackAIOS智塔提供的模型评测功能，结合实际环境，更容易得出合适的业务规划和部署模式
注：测试数据显示系统在16并发时达到最佳吞吐/延迟平衡点，超过该阈值后性能劣化明显。实际部署时建议结合硬件资源配置进行压力测试验证。

能力评测 : MMLU、HumanEval 等基准测试

1. 测试指标

• 回答准确率：模型在专业知识问答（MMLU）上的表现，体现模型的综合知识能力。
• 代码生成能力：在HumanEval基准上评测模型的编程能力，代码需要通过编译并通过单元测试。
• 数学推理能力：在Math评测集进行数学推理，体现模型的数学问题理解与推理能力。

2. 评测结果

32B模型的应用场景与展望

32B模型在多个方面展现出卓越的能力：

• 推理速度：通过优化，在多卡并行环境下，推理速度得到大幅提升，属于成本与能力较为平衡的推理模型。
• 数学能力：在复杂计算和公式推导上表现优异。
• 逻辑推理：能够理解和推理复杂的逻辑关系。
• 代码生成：具备高质量的代码编写和修正能力，但直接生成大段的完整代码相比更大参数模型会略有不足，更适合代码审查和代码补全。

因此我们总结了DeepSeek-Distilled-Qwen-32B可能适合的几种场景：

• 教学辅助
• 利用模型的知识储备和理解能力，提供教学内容的辅助讲解、答疑解惑等功能。
• 代码评审
• 借助模型的代码理解和生成能力，自动化地对代码进行审查，发现潜在问题，提供优化建议。
• 特定专业领域应用
• 在法律、医疗、金融等专业领域，提供高质量的文本生成、知识检索和决策支持。

展望：更大参数模型的部署策略

通过本文的探讨，我们深入了解了DeepSeek-Distilled-Qwen-32B模型的多卡并行部署方式、硬件配置要求，以及在不同精度和并行策略下的性能表现。32B模型以其强大的能力，为企业级应用带来了新的可能性。未来，我们期待在更多的实际场景中，见证这类大型模型的价值和潜力。

在后续的文章中，我们将探讨：

• DeepSeek R1模型的量化部署：如何在有限资源下部署如671B规模的模型。
• DeepSeek R1模型的全精度部署：在高性能计算环境下，如何充分发挥大型模型的能力。

通过对比不同规模和精度的模型，我们希望为企业级应用提供更加全面和细致的部署方案，帮助更多行业快速落地大语言模型技术，实现商业价值。

注：本文中的部分数据为示例，实际情况可能有所不同，建议在具体实施过程中进行详细测试和验证。