第 7 章 多 GPU 与 MoE：TP / DP / EP / PP 的落地组合（含参数手册与实验方案）

目标：从工程视角吃透 vLLM 在多 GPU/多节点场景下的并行策略与部署参数，涵盖 Tensor Parallel（TP）/ Data Parallel（DP）/ Expert Parallel（EP，MoE）/ Pipeline Parallel（PP） 的含义、适用边界、启动形态、拓扑注意点、常见坑与优化路径，并给出按机型与模型大小的决策表与完整 Runbook（单机多卡 / 多机多卡），最后以 2–8 GPU 的可复现实验设计量化吞吐、显存占用与网络成本。

7.1 四种并行的“工程定义”与互补关系

  • TP（Tensor Parallelism）：把同一层的权重与计算按维度切分到多张卡上，适用于模型太大/单卡放不下或希望在不牺牲 KV 容量的前提增大批量。vLLM 提供 --tensor-parallel-size/-tp 直接启用。(docs.redhat.com)
  • DP（Data Parallelism）：复制权重形成多个副本并行处理不同请求，以线性扩展吞吐为主（权重/优化器同步在训练侧；推理时更多是请求路由与少量 RPC 协调）。vLLM 提供专门的 Data Parallel Deployment 指引，亦支持内建负载均衡或外置 LB。(rocm.docs.amd.com)
  • EP（Expert Parallelism, MoE 专用）：把 MoE 的专家（experts）跨 GPU/节点分布，token 按路由仅发送到命中的专家所在卡，减少全局数据移动；vLLM 以 --enable-expert-parallel 开关控制，配合 TP/DP 组合。(GitHub)
  • PP（Pipeline Parallelism）：按层切分，把模型分段放在不同 GPU/节点，形成流水线；常用于超大模型/跨节点（例如 Llama 405B），vLLM 以 --pipeline-parallel-size/-pp 指定。(docs.lxp.lu)

vLLM 官方与多方指南明确：四者可组合（如单节点内 TP，跨节点用 PP，横向复制做 DP，MoE 层再用 EP），并针对 MoE/MLA 等架构做了持续优化（如减少 MoE all-reduce、引入 DP Attention 等）。(GitHub)

7.2 启动参数最小全家桶（随版本演进略有差异）

以下列举 vLLM Serve 的关键并行参数（示例以 Red Hat AI Inference Server 3.x 对应 vLLM 的参数为准，同名参数在原生 vLLM 中语义一致）。(docs.redhat.com)

参数 作用 典型值/备注
--tensor-parallel-size, -tp 启用/设置 TP 团队规模 单机 2/4/8；需高速互联更佳
--pipeline-parallel-size, -pp 启用/设置 PP 阶段数 多节点 2/4/8（按节点数/层数划分）
--enable-expert-parallel 对 MoE 层用 EP（非 MoE 层仍走 TP） MoE 模型建议优先考虑 EP
--distributed-executor-backend 分布式执行后端 mp（单机多卡）/ ray（跨节点）等
--data-parallel-size（部分版本/平台文档） DP 副本个数或 DP Attention 规模（架构相关） DP 副本路由或 MLA 的 DP Attention
--gpu-memory-utilization 显存利用率目标（KV 预留） 0.90–0.95 常用，配 MBT 调优
--max-parallel-loading-workers 分批加载大权重以避开主机内存 OOM 大 TP/PP/超大模型建议设定

上述字段的官方解释、默认值与可选项见 Red Hat 的“完整参数清单”（涵盖 -tp/-pp/--enable-expert-parallel/--distributed-executor-backend 等），并与 vLLM 近期版本保持同步。(docs.redhat.com)

7.3 何时用哪一种？——决策树与经验法则

密集模型（非 MoE）

  1. 单卡能放下：优先 单卡多实例（无 TP、无 PP），按需加 外部 LB 或内建 DP；总吞吐常优于把同一实例拉成 -tp N。(rocm.docs.amd.com)
  2. 单卡放不下：首选 单节点内 TP；若跨节点或TP>单节点互联能力，再上 PP。(rocm.docs.amd.com)

MoE 模型

  • 单节点/高速互联：先用 TP（或 TP+EP），看 MoE 层实现与内核组合（fused MoE 时 EP 性能突出；非 MoE 层仍 TP）。(rocm.docs.amd.com)
  • 跨节点/大规模 MoE：EP 优先（token 仅去目标专家所在的少量 EP rank，通信集合小于全 TP），必要时 EP+TP+PP 叠加。(GitHub)

MLA（DeepSeek V2/V3/R1 等）

  • 使用 Data Parallel Attention 可避免 TP 下 KV 的跨卡复制，提升大窗口吞吐；与 EP 可协同（官方 RFC/指南均已说明）。(rocm.docs.amd.com)

经验法则（来自厂商优化文档，适配 NVIDIA/AMD）

  • TP：优先放在单节点、单 NVLink/NVSwitch/XGMI 岛内；
  • PP：超大模型跨节点时使用；
  • DP：模型副本扩吞吐，或在 MLA 用 DP Attention；
  • EP：MoE 首选，跨节点时优势更明显。(rocm.docs.amd.com)

7.4 拓扑与通信：NVLink/NVSwitch/PCIe/IB 与 NCCL/RCCL 要点

  • 单节点优先把 TP 组约束在同一高速岛（NVLink/NVSwitch；AMD 则是 XGMI），跨 CPU NUMA/仅 PCIe 往往拉高 all-reduce/all-to-all 时延。(rocm.docs.amd.com)

  • 多节点建议 PP 跨节点、TP 局部（每节点内），并为 EP/DP Attention 准备充足 IB 带宽。(docs.lxp.lu)

  • 排障与调优：

    • 打开 NCCL_DEBUG=INFO 观察环与算法选择；
    • NCCL_ALGO / NCCL_PROTO 在超大节点数时可显式限制；
    • RoCE/IB 环境可调 NCCL_NET_GDR_LEVEL、NCCL_IB_TIMEOUT 等，上云/虚拟化网络可调整 NCCL_NSOCKS_PERTHREAD 等。(NVIDIA Docs)

  • 已知问题参考：NCCL/驱动/PCIe ACS 等配置导致的初始化/通信异常在社区中屡见（排除 vLLM 本身后，定位为 NCCL/环境组合）。(GitHub)

7.5 vLLM 的并行“语义”与实现差异（要点折叠）

  • TP 作用于线性/注意力等算子的分片与归并；

  • PP 以层/Block为粒度切分，形成流水线（vLLM 近期版本在变长隐藏维与 PP 的混合 allocator、图捕获等方面持续增强）。(GitHub)

  • EP 仅在 MoE 层启用专家并行，非 MoE 层继续 TP；EP 的优势在于token 只需发给命中的专家那几个 EP rank，降低无谓通信；vLLM 近几个 release 也专门优化了 MoE 的 all-reduce/top-k 内核。(GitHub)

  • DP 两条路径：

    1. 普通 DP（权重副本 + 内建/外部 LB）；
    2. Data Parallel Attention（MLA 专属），在 DeepSeek 等架构里显著降低 KV 复制。(rocm.docs.amd.com)

7.6 按机型与模型大小的策略决策表

注：表格面向“推理/服务”而非训练；默认具备 NVLink/NVSwitch（NVIDIA）或 XGMI（AMD）等高速互联；仅供落地选型起点，具体需以你的链路带宽/时延与调度负载微调。

环境/模型 7B–13B 70B 8×7B/8×22B MoE（Mixtral 类） 405B 级巨型
单节点 4–8 GPU（高速互联） 单卡多实例（无 TP）、或 TP=2（大 KV） TP=4/8；无 PP；（MoE=否） TP 或 EP（MoE 层）；尝试 EP+TP；观察 all-to-all TP=8 + PP=1（若权重仍超出，考虑 PP）
单节点 4–8 GPU（仅 PCIe） 单卡多实例；谨慎 TP>1 TP=2/4，评估 PCIe 瓶颈 EP 优于高阶 TP（减少全局通信） PP 优先，跨节点时再组合 TP
多节点（IB/RoCE） 横向 DP 提吞吐 节点内 TP，跨节点 PP EP 优先；EP+TP+PP 组合 TP×PP 为主；带宽足可叠 EP
MLA（DeepSeek） DP Attention + 多实例 DP Attention + 节点内 TP DP Attention + EP PP + DP Attention（极端大模型）

上述取舍与厂商优化页/教程给出的建议一致（例如：TP 尽量留在一个高速岛；PP 用于跨节点；EP 对 MoE 层更高效；DP Attention消除 MLA 下 KV 重复）。(rocm.docs.amd.com)

7.7 Runbook：从单机多卡到多机多卡（NVIDIA/AMD 通用）

7.7.1 单机多卡（TP）

# 目标：Llama 3 70B（示例），单机 8×GPU（NVLink/NVSwitch）
# 用 TP 吃下权重与 KV；禁用跨节点
export CUDA_VISIBLE_DEVICES=0,1,2,3,4,5,6,7
vllm serve meta-llama/Llama-3-70B-Instruct \
  --tensor-parallel-size 8 \
  --distributed-executor-backend mp \
  --gpu-memory-utilization 0.92 \
  --max-num-batched-tokens 16384

要点：

  • 单机优先 mp 后端（多进程）避免 Ray 依赖；
  • 监控 TTFT / ITL / TPS 与 KV 使用率，围绕 --max-num-batched-tokens 与 --gpu-memory-utilization 做一次一维扫描。参数释义与默认值见 Red Hat 文档。(docs.redhat.com)

7.7.2 多机多卡（TP+PP）

适配 Llama 405B 等巨型模型：节点内 TP、跨节点 PP。HPC 教程提供了 Slurm + Ray 的标准脚本（以 405B FP8 为例）。(docs.lxp.lu)

核心命令（简化自教程）：

# 2 节点 × 8 GPU = 16 GPU，总体 TP=8（每节点），PP=2（跨2节点）
vllm serve meta-llama/Llama-3.1-405B-FP8 \
  --tensor-parallel-size 8 \
  --pipeline-parallel-size 2 \
  --distributed-executor-backend ray

7.7.3 MoE（EP + TP，必要时叠 DP/PP）

# DeepSeek / Mixtral 一类 MoE，单节点 8×GPU
vllm serve deepseek-ai/DeepSeek-R1 \
  --tensor-parallel-size 8 \
  --enable-expert-parallel \
  --gpu-memory-utilization 0.92
  • EP 打开后：MoE 层走 EP，非 MoE 层仍走 TP；硬件/版本不同可能使用融合 MoE 内核 + 分组 TopK，减少 all-reduce。近期 release 还针对 Qwen3/GLM MoE 做了冗余 all-reduce 移除/融合核等优化。(GitHub)
  • 若跨节点扩张：EP 更具优势（token 只需去相应专家），与 PP/DP 叠加；注意 IB 带宽与路由。(GitHub)

7.8 OpenAI 兼容服务下的并行组合上线清单

  1. 版本与参数对齐：不同版本对 -tp/-pp/--enable-expert-parallel/--distributed-executor-backend 的默认/约束可能不同；以你部署镜像的参数清单为准（官方/Red Hat 文档均列出详尽表）。(docs.redhat.com)

  2. 多进程/多节点后端：

    • 单机多卡直选 mp；
    • 跨节点首选 ray；HPC 场景用 Slurm+Ray 参考教程脚本。(docs.redhat.com)

  3. 端口/路由：DP 内建 LB 时客户端只连一个服务端口；多实例/无 DP 时请使用外部 LB（Nginx/K8s Service）。(rocm.docs.amd.com)

  4. 容器/驱动：注意匹配 CUDA/ROCm 与 NCCL/RCCL 版本；遇到连通/超时问题先以 NCCL_DEBUG=INFO 排障，再调 NCCL_ALGO/NCCL_PROTO 等。(NVIDIA Docs)

7.9 常见坑与调优：从“能跑”到“跑得对/跑得快”

（1）“TP=多”但吞吐反而变差

  • 可能的原因：PCIe-only 拓扑、NVLink 带宽不足、请求长度分布导致 all-reduce 低效。对策：

    • 保持 TP 组在同一高速岛；
    • 改为单卡多实例（无 TP）+ 外部 LB；
    • 必要时考虑 EP（MoE）或 PP（跨节点）。(rocm.docs.amd.com)

（2）跨节点 PP/TP 初始化失败或时延大

  • 首先检查 NCCL 设置（拓扑 XML、RDMA/GDR、IB Timeout 等）；
  • 调小 --max-num-batched-tokens 与 --gpu-memory-utilization，降低首轮图捕获与 KV 预留压力。(NVIDIA Docs)

（3）MoE + EP 报错或性能不稳

  • 关注当前版本的 EP/内核组合（例如 Wide-EP/DeepEP 的模式兼容）；
  • 跟进 release 说明中关于 MoE 的冗余 all-reduce 清理/核优化；
  • 有些模型（如个别 Qwen 变体）需要降低 TP 等级或配合 EP 才能满足量化/分块约束。(GitHub)

（4）405B 级巨型模型：PP 切分比预估节点数更大

  • 教程指出实测需要更多节点（权重/激活/KV 不均衡、片段边界造成峰值高于均值），实际部署以经验与监控为准，逐步放量。(docs.lxp.lu)

7.10 可复现实验：2–8 GPU 下 TP/DP/EP/PP 的吞吐-显存-网络带宽曲线

目标：在同一机房与模型上，对比不同并行策略的 QPS/TPS、TTFT/ITL、GPU 显存占用、网络吞吐，给出MoE 场景的收益与注意点。

7.10.1 实验矩阵

  • 模型 A（密集）：Llama 3/3.1-70B；

  • 模型 B（MoE）：Mixtral-8×7B 或 DeepSeek-R1；

  • 硬件：A100/H100/MI300X 单节点 8 卡；多节点 2×8 卡（IB 200G+）；

  • 策略：

    1. TP=1/2/4/8（单节点）；
    2. TP=8 + PP=2（跨节点）；
    3. MoE：TP=8 vs TP=8+EP（单节点），以及 EP(+TP) 跨节点；
    4. DP（副本）：2/4 副本（或 MLA 的 DP Attention）；

  • 负载生成：vllm bench throughput（固定输入/输出长度或数据集 ShareGPT），收集 TPS/TTFT/ITL；另以 nvidia-smi dmon/rocm-smi + 网卡监控记录 HBM/PCIe/IB。(rocm.docs.amd.com)

vLLM/ROCm 指南提供了 bench 子命令与性能测量清单（TTFT/ITL/TPS 组合），并对 MBT（max-num-batched-tokens） 的选择给出范围（交互 ≤8k–16k；离线 ≥32k）。(rocm.docs.amd.com)

7.10.2 标准化脚本片段

密集模型：TP 扫描

for TP in 1 2 4 8; do
  CUDA_VISIBLE_DEVICES=0,1,2,3,4,5,6,7 \
  vllm serve meta-llama/Llama-3-70B-Instruct -tp $TP \
    --gpu-memory-utilization 0.92 --max-num-batched-tokens 16384 \
    --distributed-executor-backend mp --port $((8000+TP)) &
done

# 压测（示例）
vllm bench throughput --endpoint http://127.0.0.1:8008/v1 \
  --input-len 1024 --output-len 256 --duration 120

MoE：EP 对比

# 组1：TP=8（无 EP）
vllm serve mistralai/Mixtral-8x7B-Instruct -tp 8 --port 8100 &

# 组2：TP=8 + EP
vllm serve mistralai/Mixtral-8x7B-Instruct -tp 8 --enable-expert-parallel --port 8101 &

多节点：TP×PP

# 每节点 8 卡，2 节点
vllm serve meta-llama/Llama-3.1-405B-FP8 \
  -tp 8 -pp 2 --distributed-executor-backend ray

7.10.3 记录与预期

  • 密集模型（单节点）：

    • TP 从 1→2→4 带来容量与并行提升，但当互联/同步成为瓶颈时，TPS 增益递减甚至下降；
    • 单卡多实例在 7B/13B 场景通常更高总 TPS。(rocm.docs.amd.com)

  • MoE（单节点）：

    • EP 相比“纯 TP”对 MoE 层通信更友好，TTFT/ITL 有机会下降，尤其大 batch/多并发时；
    • 观测 all-to-all 峰值带宽与专家均衡（不均衡导致尾延）。(GitHub)

  • 跨节点（TP×PP）：

    • 由于 PP 把层分布到不同节点，激活流跨节点传输；标准做法是节点内 TP、跨节点 PP；
    • NCCL 参数调优能显著影响首 token 与长尾稳定性。(docs.lxp.lu)

7.11 细节清单：参数与后端选择的坑

  1. --distributed-executor-backend

    • 单机：mp；多机：ray（HPC 参考 Slurm 脚本）；部分平台还提供 uni/external_launcher。(docs.redhat.com)

  2. --enable-expert-parallel

    • EP 只针对 MoE 层；非 MoE 层继续 TP；新版内核逐步减少冗余 all-reduce/融合 grouped TopK。发布页多次提到 MoE 优化条目。(GitHub)

  3. -pp 的使用

    • 当模型层数与节点/卡数不整除时，PP 的切分可能不均衡，需结合实际观测放大节点数或调整分段（HPC 教程中的 405B 经验非常具有参考价值）。(docs.lxp.lu)

  4. DP 策略

    • 非 MoE 场景可以完全独立实例 + 外部 LB（避免 RPC 协调）；MLA 模型则考虑 DP Attention 替代权重副本路线。(rocm.docs.amd.com)

  5. NCCL/RCCL

    • 初始化失败/随机卡死优先检查 NCCL_DEBUG、GDR、IB 参数、拓扑 XML；上云环境注意 NCCL_NSOCKS_PERTHREAD/NCCL_NTHREADS。(NVIDIA Docs)

7.12 MoE：为什么 EP 更香？（原理直观解释）

  • TP（MoE 层）：把每个专家的矩阵再切成多片，每步都要在 TP 组做 all-reduce/concat；当专家数多、batch 大、TP 级别高时，通信放大。
  • EP：把完整专家放在不同 EP rank；一个 token 只被路由到命中的少数专家（top-k=2 常见），所以只需与那几个 EP rank 通信，总通信量随实际路由缩减，并且分组 GEMM 形状更友好。这是 vLLM 社区 RFC 与官方页面给出的 EP 相对 TP 的关键优势。(GitHub)

7.13 按场景的启动参数“模板库”

7.13.1 单节点 | 密集 70B | 高并发服务

vllm serve meta-llama/Llama-3-70B-Instruct \
  -tp 8 --distributed-executor-backend mp \
  --gpu-memory-utilization 0.94 --max-num-batched-tokens 24576 \
  --swap-space 8

目的：吞吐优先；把 MBT 推到 20k+，用 swap-space 兜底意外峰值。参数定义与默认见官方/Red Hat 列表。(docs.redhat.com)

7.13.2 单节点 | MoE | EP+TP

vllm serve mistralai/Mixtral-8x7B-Instruct \
  -tp 8 --enable-expert-parallel \
  --gpu-memory-utilization 0.92 --max-num-batched-tokens 16384

目的：EP 在 MoE 层减少跨卡数据；非 MoE 层维持 TP。(docs.redhat.com)

7.13.3 多节点 | 巨型 405B | TP×PP

# 节点内 TP=8，跨节点 PP=2（共16卡）
vllm serve meta-llama/Llama-3.1-405B-FP8 \
  -tp 8 -pp 2 --distributed-executor-backend ray

目的：层级切分跨节点，权重/激活分布更均衡；参考 HPC 教程的 Slurm+Ray 启动脚本。(docs.lxp.lu)

7.13.4 MLA（DeepSeek R1）| DP Attention + EP（进阶）

#（示例来自平台优化建议，需结合你的版本/硬件）
VLLM_ALL2ALL_BACKEND=allgather_reducescatter \
vllm serve deepseek-ai/DeepSeek-R1 \
  --data-parallel-size 8 \
  --enable-expert-parallel \
  --disable-nccl-for-dp-synchronization

目的：在 MLA 架构中使用 DP Attention 避免 KV 重复，与 EP 叠加提升大窗口/大并发吞吐。(rocm.docs.amd.com)

7.14 监控与验证：你需要盯住哪些指标？

  • TTFT（首 token）与 ITL（步进时延）：受 PP 初始化/图捕获/NCCL Setup 影响；
  • TPS/QPS：在 MBT 扫描中找到拐点（常在 8k–32k）；
  • KV 使用率 / HBM 占用 / 交换空间命中率；
  • 网络吞吐：TP（all-reduce）/EP（all-to-all）/PP（激活传输）的峰值与平稳性；
  • 专家命中分布与尾延（MoE）；
  • 失败率（初始化/连接/超时/报错栈）。

这些指标与采样方法在平台/厂商优化文档中均有建议与示例。(rocm.docs.amd.com)

7.15 版本演进与“兼容性意识”

  • vLLM 的 release notes 持续写到 MoE/EP、PP、分布式执行器与硬件后端优化（如去除 Qwen3 MoE 冗余 all-reduce、ROCm PP with Ray 等），升级前后务必重测。(GitHub)
  • Red Hat 的参数手册会列出当前版本支持的可选值与默认（例如 --distributed-executor-backend 可取 mp/ray/...，-tp/-pp 的默认分别为 1），便于与你的镜像/轮子版本对齐。(docs.redhat.com)

7.16 “贴墙版”——并行策略速查表（一页收纳）

项 定义 何时用 关键参数 警示/坑
TP 层内张量切分 单卡放不下/要扩 KV 批量 -tp N 限制在同一 NVLink/XGMI 岛；PCIe-only 慎重
PP 层间流水线 超大模型跨节点 -pp N 层数/节点不整除会不均衡；首 token 受图捕获影响
DP 权重副本或 DP Attention（MLA） 扩吞吐/大窗口 MLA --data-parallel-size（或平台专参） 普通 DP 带 RPC 协调；无 DP 路线=多实例+外部 LB
EP 专家并行（MoE 层） MoE 模型优先选 --enable-expert-parallel 非 MoE 层仍 TP；跨节点时更显优势；关注内核兼容

详细参数、默认值与最新支持矩阵：参见 vLLM 官方/Red Hat 文档；多机 Slurm+Ray 脚本可直接复用。(docs.redhat.com)

7.17 小结（落地八条）

  1. 先锁定拓扑：TP 尽量单节点高速岛内；跨节点用 PP。(docs.lxp.lu)
  2. MoE 首选 EP：token 只去命中专家，通信显著下降；非 MoE 层继续 TP。(GitHub)
  3. 密集模型小到中等：单卡多实例 + 外部 LB，常比 -tp N 更高总吞吐。(rocm.docs.amd.com)
  4. MLA：优先 DP Attention；可与 EP 叠加。(rocm.docs.amd.com)
  5. 405B+：TP×PP 组合是常态，节点数按实测放大（不均衡/峰值开销）。(docs.lxp.lu)
  6. 参数定位：从 -tp/-pp/--enable-expert-parallel/--distributed-executor-backend 起手，配合 --gpu-memory-utilization 与 MBT 做一维扫描。(docs.redhat.com)
  7. 网络调优：NCCL 打开 INFO，必要时指定 算法/协议/GDR，大规模集群关注 IB Timeout/队列参数。(NVIDIA Docs)
  8. 追新但可控：关注 release 中 MoE/PP/分布式优化项，升级后重测。(GitHub)

参考资料（精选）

  • 参数与并行手册：Red Hat《vLLM server arguments》（含 -tp/-pp/--enable-expert-parallel/--distributed-executor-backend、默认与可选）。(docs.redhat.com)
  • MoE/EP 原理与优势：vLLM RFC「Data Parallel Attention & Expert Parallel MoEs」。(GitHub)
  • 多节点教程：MeluXina《Multi-node & Multi-GPU inference with vLLM》（Slurm+Ray，405B/FP8）。(docs.lxp.lu)
  • NCCL 环境变量与调优：NVIDIA NCCL Developer Guide（ALGO/PROTO/GDR/IB Timeout 等）。(NVIDIA Docs)
  • 版本演进/性能优化（MoE/PP 等）：vLLM Releases（MoE all-reduce 优化、ROCm PP with Ray 等）。(GitHub)
  • 厂商优化指南（ROCm 示例，同样适用于思路参考）：并行策略选择与示例命令，含 TP/PP/DP/EP 的适配与建议。(rocm.docs.amd.com)

到这里，你已具备把 vLLM 跑稳、跑快、跑大的关键拼图。下一章，我们将进入“第 8 章：未支持新模型的适配与注册”，把“并行策略”与“模型工程化”结合起来，形成从权重映射到并行落地的一套标准化上线路径。

# 学习
Logo
加入AMD AI开发者计划！

免费领 200 小时云算力，进群参与显卡、AI PC 幸运抽奖

更多推荐

cover

TokenSpeed：专门为 Agentic Workloads 设计的大模型推理框架

avatar AMD开发者中国社区
cover

海光DCU BW1100多实例大模型实测：144GB大显存如何碾压多任务！！

avatar AMD开发者中国社区
cover

一文搞明白 hipBLAS：ROCm 里的 BLAS 加速核心

avatar AMD开发者中国社区