老显卡福音!美团开源首发INT8无损满血版DeepSeek R1
DeepSeek R1模型权重原生为FP8类型,仅能被英伟达新型GPU支持。美团技术团队进行了INT8精度量化的尝试,量化后模型精度基本无损,可部署到A100等其他型号GPU,从而解锁了芯片限制;相比BF16实现了50%的吞吐提升,降低了推理成本。相关技术已在Hugging Face上开源:
- 背景
DeepSeek R1横空出世后,吸引了众多公司和个人用户尝试其满血版本部署。然而原生版本的模型权重为FP8数据格式,对GPU芯片类型有严格限制,仅能被英伟达新型GPU支持(如Ada、Hopper架构芯片),其他型号GPU(如A100)无法直接部署。尽管我们可以将FP8权重反量化为BF16权重后,在A100等GPU上进行推理,但是这对显存的要求提升了一倍,推理吞吐也会下降。
为了解决这些难题,美团搜索和推荐平台部对DeepSeek R1模型进行了INT8精度量化尝试,发现使用INT8量化后模型精度基本无损。基于INT8量化,DeepSeek R1模型解锁了芯片限制,可以部署到A100等其他型号GPU;并且相比BF16实现了50%的吞吐提升,进一步降低了推理成本。量化代码已经发布在了开源LLM推理框架SGLang上,量化模型已经发布到了Hugging Face社区,方便用户使用。
本文将分享基于SGLang框架的DeepSeek R1模型INT8量化推理实践经验,欢迎大家多多交流,相互学习,共同成长。
- INT8量化推理实践
2.1 量化的基本原理
模型量化是将模型的权重和激活值等数据从高精度(如BF16)转化为低精度(如INT8),并尽可能保证转化前后模型效果一致的过程。以常见的INT8对称量化为例,量化过程如下所示:
2.2 DeepSeek R1的量化简介
根据DeepSeek最新发布的技术报告,V3/R1突破性的训练成本控制主要依托FP8精度训练方案。FP8是一种典型的模型量化技术,相较于业界常用的BF16精度,FP8精度通过将数据位宽减半显著降低了单次计算开销,但也会带来一定的精度损失。在实践中,DeepSeek R1采用了混合精度训练机制有效缓解了精度损失问题。
由于DeepSeek R1采用FP8精度训练,所以开源的原生权重就是FP8精度。在推理时,为了尽可能地降低模型精度损失,同时保持和FP8类似的推理吞吐,我们自然想到使用和FP8精度等位宽的INT8精度进行平替。同时,INT8精度被广泛硬件原生支持,基于INT8精度可以极大拓展DeepSeek模型的硬件部署范围。因此,我们开始探索INT8量化在DeepSeek R1上的可行性。
2.3 量化方法设计
我们在综合考虑量化后模型的精度和推理性能后,选择了分块量化(Block-wise Quantization)和通道量化(Channel-wise Quantization)两种方案。
分块量化:分块量化是DeepSeek V3/R1降低量化损失的关键技术之一。分块量化通过对权重矩阵的细粒度切分,将量化操作的范围控制在[128, 128]的矩阵内,减少了分布分散的出现概率,从而很好地控制了每次量化过程中的损失。为了尽可能地减少量化后模型的精度损失,我们延续了DeepSeek训练的量化策略,同样在[128, 128]的矩阵内对权重进行分块量化操作,保证训练和推理的一致性。但是需要注意的是,由于分块量化的不同块之间的量化缩放因子不同,因此需要在INT8的矩阵乘法过程中进行多次反量化操作,而反量化操作是在计算吞吐较低的CUDA Core上进行的,这在一定程度上会降低矩阵乘法的效率。在实践中,由于DeepSeek官方并没有提供半精度浮点型(BF16)的权重,因此首先需要将原生的FP8模型权重反量化成BF16,再分块量化成INT8精度。为了匹配权重的分块量化,激活值采用在线逐token-group的量化方式,即每个token的嵌入向量分为多个组,逐组进行量化。分块量化的激活值和权重的乘法过程如下左图所示。
通道量化:除了上述的分块量化外,我们还探索了更高效的通道量化,即权重的每列为一组进行量化。通道量化在执行完INT8的矩阵乘法后,只需进行一次反量化计算,计算开销相比分块量化更低。但是由于通道量化在量化一列元素时,更容易遇到离群值(Outlier),因此相比分块量化会有更多的精度损失。在具体实践中,同样地先将原生FP8的模型权重反量化成BF16,之后逐通道量化成INT8类型。同时,对激活值采用在线逐token量化,最大程度地减少activation的量化损失。通道量化的激活值和权重的乘法过程如下右图所示。
目前,两种INT8量化权重均已开源到Hugging Face。
2.4 量化模型评估
2.4.1 精度
我们分别应用上述两种量化方法,对开源的DeepSeek R1模型进行了INT8量化处理,并在GSM8K和MMLU两个数据集上对量化后的模型进行了精度评估。评估结果如下表所示,相比基线的BF16和FP8模型,两种INT8量化模型的精度基本无损。
注:表中的精度结果是多次测试的均值。
2.4.2 推理吞吐
我们在知名开源推理框架SGLang上,对上述两种INT8量化方法进行了推理支持(分块量化、通道量化)。SGLang是当前SOTA的开源LLM推理框架,在DeepSeek系列模型上有着最优的推理性能,被业界广泛使用。
以BF16模型为Baseline,我们在A100-80G GPU上对两种INT8模型进行了推理吞吐评估。得益于更低的显存要求,INT8量化模型仅需要16张A100 GPU即可推理,但是BF16模型需要32张A100 GPU。为了比较的公平性,我们统一在32张A100 GPU上进行吞吐测试。结果如下表所示,分块量化的INT8推理相比BF16可以提升33%的吞吐;通道量化的INT8推理得益于更低的反量化开销,可以进一步达到50%的吞吐提升。
2.5 量化模型部署
以双节点各8张A100 GPU为例,开发者需要在双部署节点安装最新版本的SGLang,然后分别执行下面命令:
# 分块量化INT8推理 # 主节点 python3 -m sglang.launch_server \ --model meituan/DeepSeek-R1-Block-INT8 --tp 16 --dist-init-addr \ HEAD_IP:5000 --nnodes 2 --node-rank 0 --trust-remote --enable-torch-compile --torch-compile-max-bs 8 # 副节点 python3 -m sglang.launch_server \ --model meituan/DeepSeek-R1-Block-INT8 --tp 16 --dist-init-addr \ HEAD_IP:5000 --nnodes 2 --node-rank 1 --trust-remote --enable-torch-compile --torch-compile-max-bs 8 # 通道量化INT8推理 # 主节点 python3 -m sglang.launch_server \ --model meituan/DeepSeek-R1-Channel-INT8 --tp 16 --dist-init-addr \ HEAD_IP:5000 --nnodes 2 --node-rank 0 --trust-remote --enable-torch-compile --torch-compile-max-bs 8 \ --quantization w8a8_int8 # 副节点 python3 -m sglang.launch_server \ --model meituan/DeepSeek-R1-Channel-INT8 --tp 16 --dist-init-addr \ HEAD_IP:5000 --nnodes 2 --node-rank 1 --trust-remote --enable-torch-compile --torch-compile-max-bs 8 \ --quantization w8a8_int8
下面是一些有趣的Case:
深度思考能力展示
这里以curl为例发送一条请求:
curl -X POST 'http://HEAD_IP:5000/v1/chat/completions' \ --header 'Content-Type: application/json' \ -d '{ "model": "deepseek-r1", "messages": [{"role": "user", "content": "下列选项中,找出与众不同的一个:1.铝 2.锡 3.钢 4.铁 5.铜" } ] }'
在INT8 R1的回答中,能看到其风格独特的反思:
不过,我需要确认这一点是否正确。比如,有没有可能其他选项中也有合金?比如,锡有时候会和其他金属混合使用,但锡本身是纯金属。同样,铝、铁、铜都是纯金属。所以钢作为合金,应该是一个关键的不同点。另外,可以考虑其他属性,比如它们的用途、物理性质或化学性质。例如,导电性:银是最好的导体,但这里没有银,而铜的导电性也很好,铝也不错,铁和钢的导电性相对差一些。但这样分类的话,可能难以确定哪一个不同。......不过回到最初的分类,钢是唯一的合金,而其他都是纯金属,这一点可能更为基础。因此答案应该是3.钢。不过需要再验证一下这个结论是否正确。
最终答案也是正确的:
答案:3.钢
模拟海量小球运动
参考其他LLM测试的Prompts作为输入,我们对比了INT8和FP8输出代码的运行效果,INT8完全不逊于FP8。
write a script for 100 bouncing balls within a sphere, make sure to handle collision detection properly. make the sphere slowly rotate. make sure balls stays within the sphere. implement it in p5.js
|INT8|FP8| |:---:|:---:| ||
|
- 总结与展望
综上,我们在DeepSeek R1上进行了INT8量化技术的探索,并基于SGLang框架进行了推理能力的支持,在保证量化后模型精度的前提下,让DeepSeek R1可以在如A100等老型号GPU上进行部署,并且提升了推理吞吐。我们希望开源的代码和权重可以让更多用户和业务方受益,也欢迎大家积极交流相关技术,共同建设、回馈开源社区。
我们团队主要负责搜索和推荐业务、AIGC应用的模型训练、推理等工作,长期和SGLang社区紧密合作,如DeepSeek V2 MLA支持、DeepSeek V3/R1 Block-wise FP8支持,除INT8量化外,目前还在进行多项其他优化,欢迎感兴趣的同学联系我们交流。
阅读更多
| 关注「美团技术团队」微信公众号,在公众号菜单栏对话框回复【2024 年货】、【2023 年货】、【2023 年货】、【2022 年货】、【2021 年货】、【2020 年货】、【2019 年货】、【2018 年货】、【2017 年货】等关键词,可查看美团技术团队历年技术文章合集。
| 本文系美团技术团队出品,著作权归属美团。欢迎出于分享和交流等非商业目的转载或使用本文内容,敬请注明 "内容转载自美团技术团队"。本文未经许可,不得进行商业性转载或者使用。任何商用行为,请发送邮件至 tech@meituan.com 申请授权。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Docker 太简单,K8s 太复杂?w7panel 让容器管理更轻松!
在众多开源项目中,高颜值、功能强大且部署简单的项目往往更能俘获开发者的心。然而,实际部署 Web 应用时,面对数据库、缓存、消息队列等复杂的依赖关系,常常令人头疼。Docker 的开源为我们普及了容器化技术,能够快速打包和部署 Web 应用,让一切变得轻松简单。 但当你从开发环境迈入生产环境,面对高可用、多节点部署、自动恢复和资源管理等更高需求时,Docker Compose 就显得力不从心。此时,Kubernetes(K8s)作为容器编排领域的王者脱颖而出,提供了强大的容器自动化编排能力,解决了生产环境中的各种难题。 然而,K8s 的强大却伴随着复杂性,使得很多开发者望而却步。即使开源社区中涌现了许多工具和平台来降低 K8s 门槛,但这些工具往往过于复杂、功能繁多、配置繁琐。有的时候,你可能只是想吃碗面,却上了一桌满汉全席,让人无从下筷🥢。 有没有一款 K8s 运维面板,拥有高颜值和易用性,又能满足生产环境需求?今天的主角微擎面板(w7panel)就是为此而生! 它将繁杂的容器运维变得简单直观,让开发者轻松上手,告别繁琐配置,专注于核心业务。 一、介绍 微擎面板(w7panel)是...
- 下一篇
GreatSQL5.7 与 8.0 对 DATE 非法值处理方式不同
GreatSQL5.7 与 8.0 对 DATE 非法值处理方式不同 一、问题描述 1. 问题现象 当分别通过LOAD DATA LOCAL INFILE和INSERT导入非法的 DATE 字段数据时,在5.7.21和 8.0.25使用LOAD DATA LOCAL会报一个Warning,数据异常但可以插入成功,而且实际插入的数据跟用户计划插入的不同,具体是0000-00-00;而使用LOAD DATA INFILE方式导入和INSERT非法值则直接报错,表里不会插入数据。 二、问题分析 1、LOAD DATA INFILE的使用模式 有普通模式和 LOCAL 模式。普通模式要求数据文件放在数据库服务器上,基于行内数据库容器化的情况,目前统一使用 LOCAL 模式。 2、LOAD DATA LOCAL INFILE方式导入的处理机制 LOAD DATA LOCAL INFILE的特殊处理机制,相当于自动置上IGNORE,官方文档有明确说明。 LOCAL also affects error handling. With LOAD DATA INFILE,Data interpretat...
相关文章
文章评论
共有0条评论来说两句吧...