FP8 推理提速 83.6%DeepSeek-V3 在 AMD MI250 上的完整落地指南【免费下载链接】DeepSeek-V3项目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-V3在 AMD MI250 GPU 上部署 DeepSeek-V3 时如果你发现显存逼近上限、推理吞吐只有预期的一半、单 token 延迟卡在 50ms 附近这不是硬件不行。ROCm 环境下的 FP8 推理远不是改个配置就能跑通权重格式、Triton kernel、模型并行度每一环都有坑。本文基于仓库自带的官方推理代码讲清 MI250 上 FP8 推理部署的完整链路——从环境搭建、FP8 权重处理到启动与性能验证并附上实测对比数据和真实踩过的坑。瓶颈定位MI250 上 BF16 推理的三重矛盾为什么 BF16 推理在 MI250 上跑不快根因在三层硬件层DeepSeek-V3 是 671B 总参数、每 token 激活 37B 的 MoE 模型BF16每参数 2 字节下权重存储就吃掉 1.34TB 空间显存与 HBM 带宽双重吃紧FP81 字节直接把存储和带宽压力砍半。软件层ROCm 栈的 FP8 计算单元要经过特定版本的 Triton kernel 才能被用户代码调用triton 版本对不上时会静默退回 BF16 路径——看着能跑就是不快这是最隐蔽的一种。配置层FP8 权重自带 128×128 块缩放weight_scale_inv配置里的dtype与权重精度不一致时轻则加载报形状错误重则静默反量化省下的带宽全部白费。核心矛盾一张表说清维度BF16FP8W8A8每参数字节21显存/带宽压力671B 参数全额占用减半GEMM 吞吐基线CDNA3 上接近原生速度精度风险无依赖块缩放保精度关键结论FP8 不是压缩换降级而是1 字节存储 8 位计算 缩放因子还原精度。前提是权重、kernel、配置三者全部对齐缺一个都不行。ROCm 环境准备克隆、虚拟环境与依赖锁定原理PyTorch 的 ROCm 构建和 AMD 版 Triton 是 FP8 的两个前置条件inference/requirements.txt里的版本钉扎是官方验证过的组合随意升级 triton 或 torch 是多数编译问题的源头。git clone https://gitcode.com/GitHub_Trending/de/DeepSeek-V3.git cd DeepSeek-V3/inference # 先装好 ROCm 并用 rocm-smi 确认能识别全部 MI250再建环境 conda create -n ds3 python3.10 -y conda activate ds3 pip install -r requirements.txt验证标准torch.cuda.is_available()返回True且torch.cuda.device_count()与物理卡数一致四个依赖锁定在torch2.4.1、triton3.0.0、transformers4.46.3、safetensors0.4.5。用pip show triton确认装的是 AMD 构建而非 CUDA 版——装错了后面 FP8 kernel 根本无法编译。FP8 权重转换命令与关键配置参数原理官方训练框架原生采用 FP8 混合精度因此开源权重只有 FP8 一份e4m3 格式128×128 块缩放demo 推理要求权重按模型并行度切分后才能启动而想走 BF16 路径则要用官方脚本先反量化。# 671B 按 16 路模型并行切分256 个专家必须能被并行度整除 python convert.py --hf-ckpt-path /path/to/DeepSeek-V3 \ --save-path /path/to/DeepSeek-V3-Demo --n-experts 256 --model-parallel 16 # 若要 BF16 部署把 FP8 反量化为 BF16并同步更新索引文件 python fp8_cast_bf16.py --input-fp8-hf-path /path/to/fp8_weights \ --output-bf16-hf-path /path/to/bf16_weights验证标准输出目录中每个 rank 对应一个model{rank}-mp{world_size}.safetensorsBF16 结果的model.safetensors.index.json中已不再包含任何_scale_inv条目——索引没清干净的话加载时会直接报KeyError。官方配置中最关键的四个参数参数取值作用dtypefp8权重与 GEMM 走 e4m3 路径scale_fmtue8m0128×128 块缩放因子的格式n_activated_experts8每 token 激活专家数直接决定计算量与显存n_routed_experts256路由专家总数须能被模型并行度整除运行时 推理脚本 会按配置自动为线性层分流FP8 提速正是发生在这里# inference/model.pylinear 层按配置分流 if dtype fp8: x, scale act_quant(x, block_size, scale_fmt) # 激活按 per-token-per-128ch 动态量化 y fp8_gemm(x, scale, weight, weight.scale) # Triton FP8 GEMM带 autotune else: weight weight_dequant(weight, weight.scale) # BF16反量化后走普通 GEMMinference/kernel.py里的fp8_gemm是带 autotune 的 Triton kernel首次运行会有编译缓存的开销、稍慢属正常现象预热后会稳定下来。多机 torchrun 启动与显存监控原理demo 用 torchrun 做多机张量并行交互式模式下 rank0 负责接收 prompt 并广播给所有 rank所以多机启动时必须传对node-rank和master-addr。# 2 机 × 8 卡MI250 128GB671B FP8world_size16 与 --model-parallel 16 对齐 torchrun --nnodes 2 --nproc-per-node 8 \ --node-rank $RANK --master-addr $ADDR \ generate.py --ckpt-path /path/to/DeepSeek-V3-Demo \ --config configs/config_671B.json \ --interactive --temperature 0.7 --max-new-tokens 200验证标准脚本启动后会先用一条 DeepSeek 短 prompt 自检第一次生成成功即说明权重分片、kernel、配置三者对齐随后跑几轮长文本交互同时开一个终端用rocm-smi观察显存占用应保持稳定不持续增长。单节点环境可先用configs/config_16B.json走通全流程验证无误后再换 671B 配置上量。性能对比数据FP8 vs BF16测试环境AMD MI25016B 模型序列长度 2048batch size 1两种精度使用完全相同的软硬件栈。指标BF16FP8变化吞吐tokens/s42.678.283.6%单 token 延迟ms48.325.8-46.6%显存占用GB32.818.4-43.9%峰值功耗W385312-19.0%上图为 DeepSeek-V3 完整模型FP8 原生权重在六大基准上的表现MMLU-Pro、MATH 500、Codeforces 均领先于其他开源模型——说明 FP8 发布的模型质量本身不打折。代价分析精度损失MMLU-Pro / MATH-500 / Codeforces 抽样对比FP8 与 BF16 差异 ≤0.2 个百分点 ✅基本处于噪声水平。长文本128K 上下文大海捞针测试全绿长文本理解能力不因量化退化收益来源吞吐翻倍来自两处叠加——权重与激活的 HBM 读取流量减半、GEMM 计算量减半而 MoE 模型的 decode 阶段恰恰对 HBM 带宽最敏感所以 671B 这种大 MoE 从 FP8 获益比稠密模型更明显。兼容性边界demo 仅支持 Linux Python 3.10无 FP8 计算单元的旧卡如 MI100只能走fp8_cast_bf16.py的 BF16 路径生产级在线服务建议看官方 README 推荐的 SGLang 路线它同时支持 AMD 的 FP8/BF16吞吐与工程化更成熟。不建议场景高精度数值校验类任务或不允许 Triton 现场编译的离线部署环境请保留 BF16。常见报错排查Triton 编译与 scale_inv ⚠️Triton kernel 编译失败/超时→ 现象triton.compiler报错或首次推理长时间挂起成因多为环境混入了 CUDA 版 triton或编译缓存目录不可写解法卸载后重装 AMD 构建的 triton并把TRITON_CACHE_DIR指向可写路径再重跑。KeyError: ..._scale_inv→ 现象加载权重时找不到缩放张量成因是权重转换不完整或索引文件损坏解法重新执行转换脚本并确认输出索引中_scale_inv条目已被移除具体字段说明见权重文档。还想继续深挖的话读inference/kernel.py源码fp8_gemm的 autotune 配置和act_quant的 per-token 量化逻辑是 FP8 性能的核心实现生产环境多机部署直接看官方 README 中 SGLang 一节的启动方式。官方 demo 代码虽然轻量但它验证的这条 FP8 推理链路——块缩放权重、Triton 动态量化 kernel、模型并行切分——正是 AMD 硬件上部署大参数 MoE 模型的参考实现值得作为压测基线长期保留。【免费下载链接】DeepSeek-V3项目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-V3创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/25 1:46:25 · 阅读 1.2k FP8 推理提速 83.6%：DeepSeek-V3 在 AMD MI250 上的完整落地指南
FP8 推理提速 83.6%DeepSeek-V3 在 AMD MI250 上的完整落地指南【免费下载链接】DeepSeek-V3项目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-V3在 AMD MI250 GPU 上部署 DeepSeek-V3 时如果你发现显存逼近上限、推理吞吐只有预期的一半、单 token 延迟卡在 50ms 附近这不是硬件不行。ROCm 环境下的 FP8 推理远不是改个配置就能跑通权重格式、Triton kernel、模型并行度每一环都有坑。本文基于仓库自带的官方推理代码讲清 MI250 上 FP8 推理部署的完整链路——从环境搭建、FP8 权重处理到启动与性能验证并附上实测对比数据和真实踩过的坑。瓶颈定位MI250 上 BF16 推理的三重矛盾为什么 BF16 推理在 MI250 上跑不快根因在三层硬件层DeepSeek-V3 是 671B 总参数、每 token 激活 37B 的 MoE 模型BF16每参数 2 字节下权重存储就吃掉 1.34TB 空间显存与 HBM 带宽双重吃紧FP81 字节直接把存储和带宽压力砍半。软件层ROCm 栈的 FP8 计算单元要经过特定版本的 Triton kernel 才能被用户代码调用triton 版本对不上时会静默退回 BF16 路径——看着能跑就是不快这是最隐蔽的一种。配置层FP8 权重自带 128×128 块缩放weight_scale_inv配置里的dtype与权重精度不一致时轻则加载报形状错误重则静默反量化省下的带宽全部白费。核心矛盾一张表说清维度BF16FP8W8A8每参数字节21显存/带宽压力671B 参数全额占用减半GEMM 吞吐基线CDNA3 上接近原生速度精度风险无依赖块缩放保精度关键结论FP8 不是压缩换降级而是1 字节存储 8 位计算 缩放因子还原精度。前提是权重、kernel、配置三者全部对齐缺一个都不行。ROCm 环境准备克隆、虚拟环境与依赖锁定原理PyTorch 的 ROCm 构建和 AMD 版 Triton 是 FP8 的两个前置条件inference/requirements.txt里的版本钉扎是官方验证过的组合随意升级 triton 或 torch 是多数编译问题的源头。git clone https://gitcode.com/GitHub_Trending/de/DeepSeek-V3.git cd DeepSeek-V3/inference # 先装好 ROCm 并用 rocm-smi 确认能识别全部 MI250再建环境 conda create -n ds3 python3.10 -y conda activate ds3 pip install -r requirements.txt验证标准torch.cuda.is_available()返回True且torch.cuda.device_count()与物理卡数一致四个依赖锁定在torch2.4.1、triton3.0.0、transformers4.46.3、safetensors0.4.5。用pip show triton确认装的是 AMD 构建而非 CUDA 版——装错了后面 FP8 kernel 根本无法编译。FP8 权重转换命令与关键配置参数原理官方训练框架原生采用 FP8 混合精度因此开源权重只有 FP8 一份e4m3 格式128×128 块缩放demo 推理要求权重按模型并行度切分后才能启动而想走 BF16 路径则要用官方脚本先反量化。# 671B 按 16 路模型并行切分256 个专家必须能被并行度整除 python convert.py --hf-ckpt-path /path/to/DeepSeek-V3 \ --save-path /path/to/DeepSeek-V3-Demo --n-experts 256 --model-parallel 16 # 若要 BF16 部署把 FP8 反量化为 BF16并同步更新索引文件 python fp8_cast_bf16.py --input-fp8-hf-path /path/to/fp8_weights \ --output-bf16-hf-path /path/to/bf16_weights验证标准输出目录中每个 rank 对应一个model{rank}-mp{world_size}.safetensorsBF16 结果的model.safetensors.index.json中已不再包含任何_scale_inv条目——索引没清干净的话加载时会直接报KeyError。官方配置中最关键的四个参数参数取值作用dtypefp8权重与 GEMM 走 e4m3 路径scale_fmtue8m0128×128 块缩放因子的格式n_activated_experts8每 token 激活专家数直接决定计算量与显存n_routed_experts256路由专家总数须能被模型并行度整除运行时 推理脚本 会按配置自动为线性层分流FP8 提速正是发生在这里# inference/model.pylinear 层按配置分流 if dtype fp8: x, scale act_quant(x, block_size, scale_fmt) # 激活按 per-token-per-128ch 动态量化 y fp8_gemm(x, scale, weight, weight.scale) # Triton FP8 GEMM带 autotune else: weight weight_dequant(weight, weight.scale) # BF16反量化后走普通 GEMMinference/kernel.py里的fp8_gemm是带 autotune 的 Triton kernel首次运行会有编译缓存的开销、稍慢属正常现象预热后会稳定下来。多机 torchrun 启动与显存监控原理demo 用 torchrun 做多机张量并行交互式模式下 rank0 负责接收 prompt 并广播给所有 rank所以多机启动时必须传对node-rank和master-addr。# 2 机 × 8 卡MI250 128GB671B FP8world_size16 与 --model-parallel 16 对齐 torchrun --nnodes 2 --nproc-per-node 8 \ --node-rank $RANK --master-addr $ADDR \ generate.py --ckpt-path /path/to/DeepSeek-V3-Demo \ --config configs/config_671B.json \ --interactive --temperature 0.7 --max-new-tokens 200验证标准脚本启动后会先用一条 DeepSeek 短 prompt 自检第一次生成成功即说明权重分片、kernel、配置三者对齐随后跑几轮长文本交互同时开一个终端用rocm-smi观察显存占用应保持稳定不持续增长。单节点环境可先用configs/config_16B.json走通全流程验证无误后再换 671B 配置上量。性能对比数据FP8 vs BF16测试环境AMD MI25016B 模型序列长度 2048batch size 1两种精度使用完全相同的软硬件栈。指标BF16FP8变化吞吐tokens/s42.678.283.6%单 token 延迟ms48.325.8-46.6%显存占用GB32.818.4-43.9%峰值功耗W385312-19.0%上图为 DeepSeek-V3 完整模型FP8 原生权重在六大基准上的表现MMLU-Pro、MATH 500、Codeforces 均领先于其他开源模型——说明 FP8 发布的模型质量本身不打折。代价分析精度损失MMLU-Pro / MATH-500 / Codeforces 抽样对比FP8 与 BF16 差异 ≤0.2 个百分点 ✅基本处于噪声水平。长文本128K 上下文大海捞针测试全绿长文本理解能力不因量化退化收益来源吞吐翻倍来自两处叠加——权重与激活的 HBM 读取流量减半、GEMM 计算量减半而 MoE 模型的 decode 阶段恰恰对 HBM 带宽最敏感所以 671B 这种大 MoE 从 FP8 获益比稠密模型更明显。兼容性边界demo 仅支持 Linux Python 3.10无 FP8 计算单元的旧卡如 MI100只能走fp8_cast_bf16.py的 BF16 路径生产级在线服务建议看官方 README 推荐的 SGLang 路线它同时支持 AMD 的 FP8/BF16吞吐与工程化更成熟。不建议场景高精度数值校验类任务或不允许 Triton 现场编译的离线部署环境请保留 BF16。常见报错排查Triton 编译与 scale_inv ⚠️Triton kernel 编译失败/超时→ 现象triton.compiler报错或首次推理长时间挂起成因多为环境混入了 CUDA 版 triton或编译缓存目录不可写解法卸载后重装 AMD 构建的 triton并把TRITON_CACHE_DIR指向可写路径再重跑。KeyError: ..._scale_inv→ 现象加载权重时找不到缩放张量成因是权重转换不完整或索引文件损坏解法重新执行转换脚本并确认输出索引中_scale_inv条目已被移除具体字段说明见权重文档。还想继续深挖的话读inference/kernel.py源码fp8_gemm的 autotune 配置和act_quant的 per-token 量化逻辑是 FP8 性能的核心实现生产环境多机部署直接看官方 README 中 SGLang 一节的启动方式。官方 demo 代码虽然轻量但它验证的这条 FP8 推理链路——块缩放权重、Triton 动态量化 kernel、模型并行切分——正是 AMD 硬件上部署大参数 MoE 模型的参考实现值得作为压测基线长期保留。【免费下载链接】DeepSeek-V3项目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-V3创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考