深入理解 DeepSeek 与企业实践（三）：671B 超低成本部署方法与效果评测

前言

在《深入理解 DeepSeek 与企业实践（一）：蒸馏、部署与评测》、《深入理解DeepSeek与企业实践（二）：32B多卡推理的原理、硬件散热与性能实测》的系列文章中，我们分别介绍了 DeepSeek R1 不同模型的关系、核心指标，并在 ZStack AIOS 智塔上完成了几种蒸馏模型的部署和评测。根据我们的评测，蒸馏后的版本在数学、代码等能力方面往往较原模型有提升，但如果涉及较复杂的任务（例如完整编写上百行的代码）其效果可能不尽如人意。此时我们需要考虑使用 DeepSeek-R1 671B 模型，也就是网上常说的“满血版”。

但是 671B 参数量太大，如果设备不支持 FP8 的话，仅是模型权重就有 1.3TB，成本非常高昂，因此本文将聚焦于如何以最低成本部署DeepSeek-R1 671B 这一近万亿参数级大模型、量化版本的实际表现如何、量化版本相比未量化版本损失有多少、不同硬件配置的综合性价比和适合场景。

本文目录

一、DeepSeek-R1 671B 量化版本解析

二、极限压缩方案：DeepSeek-R1 671B 1.58-bit 部署实践

三、多机扩展方案：3090 集群部署 671B-1.58b 评测

四、高性能方案：H20×8 + AWQ 量化部署

五、实战案例：Flappy Bird 代码生成

六、成本效益分析和结论

七、展望：全精度未量化模型的部署策略

一、DeepSeek-R1 671B 

量化版本解析

当前，针对 DeepSeek R1 671B 的量化方案有很多，这里不再详细介绍 IQ_1_S、AWQ 等量化方法是什么具体含义，直接选取几种典型方案和显存需求对比如下：

（注：显存需求包含了最小的 KV 缓存与系统开销，且为最低需求，实际需要根据上下文窗口大小、KV 缓存精度等准确估算。GGUF 格式与 safetensor 格式由于推理引擎和并行方法不同，因此显存占用不能直接比较）

二、极限压缩方案：

DeepSeek-R1 671B 1.58-bit 部署实践

根据前面的表格，我们不难发现一台 3090 8 卡服务器正好就可以满足 671B-1.58b 的最低要求！而且可以将全部权重放到 GPU 里，推理速度是比较有保障的，不过要注意的是因为格式为 GGUF 格式，因此需要使用 llama.cpp 推理框架，在 ZStack AIOS 智塔里，支持多种推理框架，方便用户根据实际需求使用。