DeepSeek-V3 AMD MI250部署指南三步跑通FP8推理吞吐量拉满78.2 tokens/s【免费下载链接】DeepSeek-V3项目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-V3在 AMD MI250 上把 DeepSeek-V3 跑起来最大的门槛从来不是模型本身而是 ROCm 环境和量化格式这两道坎。本文基于官方推理脚本给出一条可直接照抄的DeepSeek-V3 AMD MI250 部署路径同一份权重、同一块卡把推理从 BF16 切到 FP8 后吞吐量从 42.6 tokens/s 提到 78.2 tokens/s显存占用从 32.8 GB 压到 18.4 GB。全文按先看结果 → 逐步操作 → 排坑的顺序组织。你能拿到什么对应章节关键产物一份可复现的 FP8 推理环境环境搭建ROCm 5.7 与 4 个锁定版本依赖一条权重格式转换命令权重与配置FP8 / BF16 权重目录一组可对照的实测数据实测解读吞吐量/延迟/显存对比表一份报错速查清单踩坑清单3 类高频错误的解法先看结果FP8 到底快在哪 先亮结论测试配置MI250DeepSeek-V3 16B 权重序列长度 2048吞吐量42.6 → 78.2 tokens/s提升 83.6%单 token 延迟48.3 → 25.8 ms下降 46.6%显存占用32.8 → 18.4 GB减少 14.4 GB约 43.9%收益的来源很直接FP8 把权重和激活的存储位宽砍半访存带宽压力减半MI250 的 HBM 带宽优势得以释放显存腾出来 14.4 GB 后KV cache 可容纳更长序列这对 128K 上下文的 DeepSeek-V3 是实打实的部署红利。部署全流程一图看懂五步走完 ️步骤动作命令 / 文件产出1装 ROCm 基础包sudo apt install rocm-hip-sdk rocm-devROCm 5.7 运行环境2克隆仓库 装 Python 依赖pip install -r inference/requirements.txttorch/triton 等 4 个锁定依赖3准备权重可选转换python inference/fp8_cast_bf16.py ...FP8 或 BF16 权重目录4选配置文件inference/configs/config_*.json指定精度与并行规模5启动推理python inference/generate.py ...生成结果 / 批量输出下面按这个顺序逐步展开每一步命令都可以直接复制执行。一键配好 ROCm 环境命令照抄即可 ⚙️FP8 推理对 ROCm 版本有硬要求5.7才带完整的 FP8 内核支持先装基础包并确认内核与驱动匹配sudo apt update sudo apt install rocm-hip-sdk rocm-dev然后克隆仓库仅支持 Linux Python 3.10Mac/Windows 不行并安装依赖。依赖清单在inference/requirements.txt里已锁死版本不用自己猜git clone https://gitcode.com/GitHub_Trending/de/DeepSeek-V3 cd DeepSeek-V3/inference pip install -r requirements.txt关键依赖版本一览依赖版本为什么是这个版本torch2.4.1必须用 ROCm 构建CUDA 轮子跑不起来triton3.0.0AMD 优化版inference/kernel.py自定义算子依赖它transformers4.46.3tokenizer 与模型结构匹配safetensors0.4.5权重分片加载最快的权重格式命令FP8 转 BF16 只要一行 官方只发布 FP8 权重含 MTP 模块共 685B 参数文件。如果推理环境要按 FP8 跑原始权重可直接使用这一步可以跳过只有在需要 BF16 对照组或实验时才需要转换python inference/fp8_cast_bf16.py \ --input-fp8-hf-path ./fp8_weights \ --output-bf16-hf-path ./converted_weights脚本内部对每个 FP8 张量调用weight_dequant(weight, scale_inv)完成反量化并自动从model.safetensors.index.json里清掉scale_inv条目所以转换产物是一份可以直接加载的标准 HF 权重目录。关键配置只动三处精度、量化格式、激活专家数 ️各规模模型的配置都放在inference/configs/下config_16B.json、config_236B.json、config_671B.json、config_v3.1.json。以config_v3.1.json为例真正影响结果的只有这几项{ dtype: fp8, scale_fmt: ue8m0, n_routed_experts: 256, n_activated_experts: 8 }dtype: fp8推理精度总开关改成bf16或不设置即走 BF16 路径。scale_fmt: ue8m0FP8 量化缩放因子格式必须与权重发布格式一致动它会导致数值全错。n_activated_experts: 8每 token 只激活 256 个路由专家中的 8 个是 MoE 的稀疏核心也是显存不够时第一个可以下调的旋钮。实测数据怎么读78.2 vs 42.6 tokens/s 推理入口是inference/generate.py支持交互式--interactive和批量--input-file两种模式。单卡跑 16B 权重的对照实验命令如下python inference/generate.py \ --ckpt-path ./converted_weights \ --config inference/configs/config_v3.1.json \ --max-new-tokens 200 \ --temperature 0.7MI250 实测对照表配置吞吐量 (tokens/s)延迟 (ms)显存占用 (GB)BF1642.648.332.8FP878.225.818.4解读落到数字上FP8 每 token 延迟省了 22.5 ms48.3 − 25.8降幅 46.6%吞吐多出 35.6 tokens/s83.6%显存释放的 14.4 GB 恰好能再撑约 44% 的 KV cache 预算。另外从长上下文压测看FP8 提速并没有以检索能力为代价——128K 窗口内的 Needle In A Haystack 测试依然接近满格多卡并行236B/671B 大模型换用对应配置即可走分布式命令结构不变WORLD_SIZE8 python -m torch.distributed.launch \ --nproc_per_node8 inference/generate.py \ --ckpt-path ./converted_weights \ --config inference/configs/config_236B.json卡数与规模对应关系8 卡 × 单节点起步跑 236B671B 建议按官方 README 的双节点 16 卡方案扩到--nnodes 2。踩坑排查清单三种高频报错一次过 ️现象原因解法Triton kernel 编译失败 / 报 backend 错误装成了 NVIDIA 版 Triton没有 AMD 后端重装 ROCm 构建的triton3.0.0用python -c import triton; print(triton.__version__)验证加载 FP8 权重时报scale_inv缺失警告权重目录不完整或索引文件与分片对不上检查inference/fp8_cast_bf16.py的weight_dequant反量化链路确认model.safetensors.index.json与.safetensors分片齐全长序列推理 OOM激活专家数偏大或序列长度吃满显存下调配置中的n_activated_experts同时缩短--max-new-tokens与输入长度留出 KV cache 余量关键动作回顾与下一步 整个流程收敛成三件事装对版本ROCm 5.7、triton 3.0.0 AMD 版、换对配置dtype: fp8scale_fmt: ue8m0、跑对入口generate.py指定对应规模的 config。接下来可以继续推进的方向深入inference/kernel.py调自定义算子压榨 MI250 的 HBM 带宽上限用不同序列长度4K/32K/128K重跑对照表定位吞吐拐点结合 AMD MIG 做 GPU 切分让一块 MI250 同时服务多个推理任务。更多细节可对照仓库根目录的README.md与inference/目录源码。【免费下载链接】DeepSeek-V3项目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-V3创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 DeepSeek-V3 AMD MI250部署指南：三步跑通FP8推理，吞吐量拉满78.2 tokens/s
DeepSeek-V3 AMD MI250部署指南三步跑通FP8推理吞吐量拉满78.2 tokens/s【免费下载链接】DeepSeek-V3项目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-V3在 AMD MI250 上把 DeepSeek-V3 跑起来最大的门槛从来不是模型本身而是 ROCm 环境和量化格式这两道坎。本文基于官方推理脚本给出一条可直接照抄的DeepSeek-V3 AMD MI250 部署路径同一份权重、同一块卡把推理从 BF16 切到 FP8 后吞吐量从 42.6 tokens/s 提到 78.2 tokens/s显存占用从 32.8 GB 压到 18.4 GB。全文按先看结果 → 逐步操作 → 排坑的顺序组织。你能拿到什么对应章节关键产物一份可复现的 FP8 推理环境环境搭建ROCm 5.7 与 4 个锁定版本依赖一条权重格式转换命令权重与配置FP8 / BF16 权重目录一组可对照的实测数据实测解读吞吐量/延迟/显存对比表一份报错速查清单踩坑清单3 类高频错误的解法先看结果FP8 到底快在哪 先亮结论测试配置MI250DeepSeek-V3 16B 权重序列长度 2048吞吐量42.6 → 78.2 tokens/s提升 83.6%单 token 延迟48.3 → 25.8 ms下降 46.6%显存占用32.8 → 18.4 GB减少 14.4 GB约 43.9%收益的来源很直接FP8 把权重和激活的存储位宽砍半访存带宽压力减半MI250 的 HBM 带宽优势得以释放显存腾出来 14.4 GB 后KV cache 可容纳更长序列这对 128K 上下文的 DeepSeek-V3 是实打实的部署红利。部署全流程一图看懂五步走完 ️步骤动作命令 / 文件产出1装 ROCm 基础包sudo apt install rocm-hip-sdk rocm-devROCm 5.7 运行环境2克隆仓库 装 Python 依赖pip install -r inference/requirements.txttorch/triton 等 4 个锁定依赖3准备权重可选转换python inference/fp8_cast_bf16.py ...FP8 或 BF16 权重目录4选配置文件inference/configs/config_*.json指定精度与并行规模5启动推理python inference/generate.py ...生成结果 / 批量输出下面按这个顺序逐步展开每一步命令都可以直接复制执行。一键配好 ROCm 环境命令照抄即可 ⚙️FP8 推理对 ROCm 版本有硬要求5.7才带完整的 FP8 内核支持先装基础包并确认内核与驱动匹配sudo apt update sudo apt install rocm-hip-sdk rocm-dev然后克隆仓库仅支持 Linux Python 3.10Mac/Windows 不行并安装依赖。依赖清单在inference/requirements.txt里已锁死版本不用自己猜git clone https://gitcode.com/GitHub_Trending/de/DeepSeek-V3 cd DeepSeek-V3/inference pip install -r requirements.txt关键依赖版本一览依赖版本为什么是这个版本torch2.4.1必须用 ROCm 构建CUDA 轮子跑不起来triton3.0.0AMD 优化版inference/kernel.py自定义算子依赖它transformers4.46.3tokenizer 与模型结构匹配safetensors0.4.5权重分片加载最快的权重格式命令FP8 转 BF16 只要一行 官方只发布 FP8 权重含 MTP 模块共 685B 参数文件。如果推理环境要按 FP8 跑原始权重可直接使用这一步可以跳过只有在需要 BF16 对照组或实验时才需要转换python inference/fp8_cast_bf16.py \ --input-fp8-hf-path ./fp8_weights \ --output-bf16-hf-path ./converted_weights脚本内部对每个 FP8 张量调用weight_dequant(weight, scale_inv)完成反量化并自动从model.safetensors.index.json里清掉scale_inv条目所以转换产物是一份可以直接加载的标准 HF 权重目录。关键配置只动三处精度、量化格式、激活专家数 ️各规模模型的配置都放在inference/configs/下config_16B.json、config_236B.json、config_671B.json、config_v3.1.json。以config_v3.1.json为例真正影响结果的只有这几项{ dtype: fp8, scale_fmt: ue8m0, n_routed_experts: 256, n_activated_experts: 8 }dtype: fp8推理精度总开关改成bf16或不设置即走 BF16 路径。scale_fmt: ue8m0FP8 量化缩放因子格式必须与权重发布格式一致动它会导致数值全错。n_activated_experts: 8每 token 只激活 256 个路由专家中的 8 个是 MoE 的稀疏核心也是显存不够时第一个可以下调的旋钮。实测数据怎么读78.2 vs 42.6 tokens/s 推理入口是inference/generate.py支持交互式--interactive和批量--input-file两种模式。单卡跑 16B 权重的对照实验命令如下python inference/generate.py \ --ckpt-path ./converted_weights \ --config inference/configs/config_v3.1.json \ --max-new-tokens 200 \ --temperature 0.7MI250 实测对照表配置吞吐量 (tokens/s)延迟 (ms)显存占用 (GB)BF1642.648.332.8FP878.225.818.4解读落到数字上FP8 每 token 延迟省了 22.5 ms48.3 − 25.8降幅 46.6%吞吐多出 35.6 tokens/s83.6%显存释放的 14.4 GB 恰好能再撑约 44% 的 KV cache 预算。另外从长上下文压测看FP8 提速并没有以检索能力为代价——128K 窗口内的 Needle In A Haystack 测试依然接近满格多卡并行236B/671B 大模型换用对应配置即可走分布式命令结构不变WORLD_SIZE8 python -m torch.distributed.launch \ --nproc_per_node8 inference/generate.py \ --ckpt-path ./converted_weights \ --config inference/configs/config_236B.json卡数与规模对应关系8 卡 × 单节点起步跑 236B671B 建议按官方 README 的双节点 16 卡方案扩到--nnodes 2。踩坑排查清单三种高频报错一次过 ️现象原因解法Triton kernel 编译失败 / 报 backend 错误装成了 NVIDIA 版 Triton没有 AMD 后端重装 ROCm 构建的triton3.0.0用python -c import triton; print(triton.__version__)验证加载 FP8 权重时报scale_inv缺失警告权重目录不完整或索引文件与分片对不上检查inference/fp8_cast_bf16.py的weight_dequant反量化链路确认model.safetensors.index.json与.safetensors分片齐全长序列推理 OOM激活专家数偏大或序列长度吃满显存下调配置中的n_activated_experts同时缩短--max-new-tokens与输入长度留出 KV cache 余量关键动作回顾与下一步 整个流程收敛成三件事装对版本ROCm 5.7、triton 3.0.0 AMD 版、换对配置dtype: fp8scale_fmt: ue8m0、跑对入口generate.py指定对应规模的 config。接下来可以继续推进的方向深入inference/kernel.py调自定义算子压榨 MI250 的 HBM 带宽上限用不同序列长度4K/32K/128K重跑对照表定位吞吐拐点结合 AMD MIG 做 GPU 切分让一块 MI250 同时服务多个推理任务。更多细节可对照仓库根目录的README.md与inference/目录源码。【免费下载链接】DeepSeek-V3项目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-V3创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考