AMD MI355X GPU与vLLM框架大模型推理部署实战指南

AMD MI355XvLLM大模型推理部署
于 2026-08-04 04:08:46 修改
·本内容遵循CC 4.0 BY-SA版权协议

在实际的大模型推理部署场景中，性能与成本是开发者最关心的两个核心指标。当NVIDIA的B200以其强大的算力成为行业标杆时，AMD MI355X的横空出世，凭借其在特定推理任务中超越B200的性能表现，为市场提供了一个极具吸引力的新选择。这不仅仅是硬件层面的竞争，更意味着在构建AI推理服务时，我们有了更灵活的架构选型空间和成本优化方案。

本文旨在为那些正在评估或计划使用AMD GPU进行大模型推理部署的工程师、架构师和研究者提供一个深度实践指南。我们将从MI355X的硬件特性出发，结合当前最流行的vLLM推理框架，手把手带你完成从环境准备、模型部署、性能测试到问题排查的完整链路。你将了解到如何将MI355X的理论性能转化为实际的生产力，并掌握在Ubuntu/Linux系统下围绕AMD GPU和vLLM进行开发和运维的关键技能。

1. 理解AMD MI355X与vLLM的协同优势

在深入部署之前，我们需要厘清两个核心概念：AMD MI355X GPU的架构特性，以及vLLM推理框架如何最大化利用这些特性。

1.1 AMD MI355X：为AI推理而生的计算卡

AMD MI355X并非传统的游戏或图形渲染显卡，它是AMD Instinct加速器家族中的一员，专为数据中心的高性能计算和人工智能工作负载设计。其超越B200推理性能的关键，主要源于几个方面的针对性优化：

  • 高带宽内存（HBM）：MI355X通常配备高带宽内存，这对于处理拥有数百亿甚至上千亿参数的大语言模型至关重要。巨大的模型参数和推理过程中的KV Cache（键值缓存）都需要在GPU内存中快速存取，高带宽能有效减少内存墙带来的延迟。
  • 矩阵计算单元优化：其计算核心针对矩阵乘加运算（MatMul）进行了深度优化，这是Transformer模型前向传播中最耗时的操作。更高的计算吞吐量直接转化为更快的Token生成速度。
  • 软件栈支持（ROCm）：AMD提供了对标CUDA的ROCm开源软件平台。虽然生态成熟度仍在追赶，但其对PyTorch、TensorFlow等主流框架以及vLLM等推理框架的支持已日趋完善，是发挥硬件性能的基石。

与B200对比，MI355X可能在绝对峰值算力上不占优，但其在特定模型、特定批次大小（Batch Size）下的每瓦性能或性价比可能更具优势，这也是“推理性能超越”这一说法的实际内涵。

1.2 vLLM：解锁大模型推理效率的钥匙

vLLM是一个专注于LLM推理和服务的高吞吐、低延迟框架。它的核心创新在于PagedAttention算法和高效的内存管理机制，这与MI355X的大内存特性形成了完美互补。

  • PagedAttention：传统Attention计算需要为每个请求连续分配KV Cache内存，导致内存碎片化。PagedAttention借鉴操作系统虚拟内存分页的思想，将KV Cache划分为固定大小的“块”，允许多个请求的非连续内存块高效共享物理内存。这极大地提高了MI355X高容量HBM的利用率，允许同时服务更多的并发请求。
  • 连续批处理（Continuous Batching）：vLLM能够动态地将不同时间到达、不同生成长度的请求组合成一个批次进行计算，而不是等待一个批次全部完成再处理下一个。这确保了MI355X的计算单元始终处于高负载状态，避免了空闲等待，提升了整体吞吐量。
  • 对AMD ROCm的支持：vLLM从较新版本开始积极集成对AMD GPU的支持。通过ROCm的HIP接口，vLLM的算子和内核能够在MI355X上运行，从而将框架的调度优势与硬件的计算优势结合起来。

因此，MI355X与vLLM的结合，目标是在高并发、动态负载的在线推理场景下，实现更高的总体服务吞吐量（Throughput）和更优的资源利用率，而不仅仅是追求单个请求的极致延迟。

2. 环境准备：构建稳定的AMD ROCm与vLLM基础

一个稳定且版本匹配的基础环境是后续所有工作的前提。AMD GPU上的深度学习环境搭建，核心是ROCm工具栈的安装与配置。

2.1 系统与硬件要求检查

首先，确认你的系统满足最低要求。以下是一个推荐的环境清单：

组件 要求 检查命令
操作系统 Ubuntu 22.04 LTS 或 20.04 LTS。这是ROCm官方支持最完善的系统。 cat /etc/os-release
内核版本 建议使用系统默认或ROCm推荐的内核。 uname -r
AMD GPU 确认MI355X或其他支持ROCm的显卡（如MI250X, MI300A/X）已正确安装。 lspci | grep -i amd
PCIe总线 建议使用PCIe 4.0 x16或更高，以确保足够的GPU与主机通信带宽。 lspci -v | grep -A 10 \"VGA\"
系统内存 至少64GB，建议128GB以上，用于处理模型加载和系统开销。 free -h
存储空间 / 或 /home 分区至少有100GB可用空间，用于安装ROCm、Python包和模型文件。 df -h

注意：避免在非官方支持的发行版（如某些Arch Linux滚动更新版本）上部署生产环境，可能会遇到驱动兼容性问题。网络搜索材料中提到的“archlinux amd显卡驱动”问题通常源于此。

2.2 安装AMD ROCm

我们将采用APT仓库的方式安装ROCm，这是最规范的方法。

  1. 添加ROCm仓库和密钥：

    BASH
    # 对于 Ubuntu 22.04
    wget https://repo.radeon.com/amdgpu-install/6.1/ubuntu/jammy/amdgpu-install_6.1.60100-1_all.deb
    sudo apt install ./amdgpu-install_6.1.60100-1_all.deb -y
    sudo apt update

    对于Ubuntu 20.04，请将URL中的jammy替换为focal。安装包版本（如6.1）请查阅ROCm官方文档获取最新。

  2. 安装ROCm核心组件：

    BASH
    # 安装ROCm运行时、开发工具和内核驱动
    sudo amdgpu-install --usecase=rocm,dkms --no-dkms
    # 或者，如果你需要完整的MIOpen（深度学习库）和编译器支持
    # sudo amdgpu-install --usecase=rocm,dkms,miopen --no-dkms

  3. 配置用户组和环境变量：

    BASH
    # 将当前用户添加到`render`和`video`组（有时也需要`kvm`）
    sudo usermod -a -G render,video $USER
    # 重新登录或重启使组生效
     
    # 将ROCm路径添加到环境变量（通常已自动添加，可验证）
    echo 'export PATH=$PATH:/opt/rocm/bin:/opt/rocm/profiler/bin:/opt/rocm/opencl/bin' >> ~/.bashrc
    echo 'export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/rocm/lib' >> ~/.bashrc
    source ~/.bashrc

  4. 验证安装：

    BASH
    # 检查ROCm命令行工具
    rocminfo
    # 检查GPU识别情况
    rocm-smi

    运行rocm-smi应该能看到你的MI355X显卡，显示其温度、功耗、显存占用等信息。

2.3 配置Python虚拟环境与PyTorch

为了避免系统Python环境混乱，强烈建议使用Conda或venv。

BASH
# 使用Conda（推荐）
conda create -n vllm-amd python=3.10 -y
conda activate vllm-amd
 
# 安装针对ROCm编译的PyTorch
# 访问 https://pytorch.org/get-started/locally/ 选择 ROCm 版本获取最新命令
# 例如，对于 ROCm 6.1 和 PyTorch 2.4
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.1
 
# 验证PyTorch能否识别AMD GPU
python -c "import torch; print(f'PyTorch version: {torch.__version__}'); print(f'Is ROCm available? {torch.cuda.is_available()}'); print(f'Device name: {torch.cuda.get_device_name(0) if torch.cuda.is_available() else \"CPU\"}')"

这里torch.cuda.is_available()在ROCm环境下也会返回True，因为PyTorch将ROCm设备统一映射到了CUDA API下。

3. 部署vLLM并运行第一个推理服务

环境就绪后，我们开始部署vLLM。由于vLLM对AMD的支持处于快速发展中，可能需要从源码编译或安装特定分支。

3.1 安装vLLM

最稳妥的方式是从vLLM的GitHub仓库安装，以确保获得对ROCm的最新支持。

BASH
# 确保在之前创建的虚拟环境中
conda activate vllm-amd
 
# 安装编译依赖
sudo apt-get update
sudo apt-get install -y cmake ninja-build
 
# 克隆vLLM仓库（建议使用稳定版本分支，如v0.6.x）
git clone https://github.com/vllm-project/vllm.git
cd vllm
# 查看支持ROCm的版本或分支，例如：
# git checkout v0.6.0 或 git checkout -b rocm-support origin/rocm
 
# 使用pip从源码安装，并指定ROCm后端
pip install -e . --verbose
# 或者，如果存在针对ROCm的预编译wheel（不常见）
# pip install vllm --index-url https://pypi.org/simple/ --extra-index-url https://rocm-pypi.org/simple/

安装过程可能会编译一些C++/HIP扩展，耗时较长。如果遇到关于flash-attn（FlashAttention）的编译错误（如网络热词中提到的“vllm怎么开flash-attn”），可以尝试先关闭它，因为其对ROCm的完全支持可能仍在开发中。

BASH
# 在安装vLLM时禁用flash-attn
pip install -e . --no-build-isolation --verbose
# 或者在安装后设置环境变量
export VLLM_ATTENTION_BACKEND=xformers # 或 auto, 但确保已安装xformers

3.2 准备模型文件

vLLM支持Hugging Face格式的模型。以Qwen2.5-7B-Instruct为例：

BASH
# 使用Hugging Face CLI下载（需先登录 huggingface-cli login）
huggingface-cli download Qwen/Qwen2.5-7B-Instruct --local-dir ./models/Qwen2.5-7B-Instruct --local-dir-use-symlinks False
 
# 或者，直接使用vLLM的引擎加载，它会自动处理下载（需网络）
# 我们将在代码中指定模型ID

对于网络搜索中提到的“qwen_image_edit_2511 量化 amd显卡 专用gpu内存496m 应该用哪个量化版本”这类问题，核心是显存不足。496MB显存远不足以加载7B模型。你必须：

  1. 使用量化模型：例如AWQ、GPTQ或GGUF量化版本。对于vLLM，推荐使用AWQ量化格式，因其与vLLM的PagedAttention集成较好。
    BASH
    # 例如，下载Qwen2.5-7B-Instruct的AWQ量化版
    huggingface-cli download Qwen/Qwen2.5-7B-Instruct-AWQ --local-dir ./models/Qwen2.5-7B-Instruct-AWQ
  2. 确认模型格式：vLLM通过--quantization awq参数来加载AWQ模型。确保你下载的是正确的格式。

3.3 启动离线推理与API服务

vLLm提供两种主要使用方式：离线批量推理和在线API服务。

方式一：离线批量推理脚本 创建一个Python脚本benchmark.py，用于测试基础性能：

PYTHON
from vllm import LLM, SamplingParams
import time
 
# 指定模型路径或Hugging Face ID
# 如果是量化模型，添加 quantization="awq"
model_path = "./models/Qwen2.5-7B-Instruct-AWQ" # 或 "Qwen/Qwen2.5-7B-Instruct-AWQ"
 
print(f"Loading model from {model_path}...")
llm = LLM(model=model_path,
quantization="awq", # 如果是AWQ量化模型则启用
tensor_parallel_size=1, # MI355X单卡设为1，多卡可增加
gpu_memory_utilization=0.9, # GPU显存利用率，根据情况调整
trust_remote_code=True) # 对于Qwen等需要信任代码的模型
 
sampling_params = SamplingParams(temperature=0.7, top_p=0.9, max_tokens=512)
 
prompts = [
"请用中文解释一下人工智能。",
"Translate the following English sentence to Chinese: 'The quick brown fox jumps over the lazy dog.'",
"生成一个关于太空探险的短故事开头。"
]
 
print("Starting inference...")
start_time = time.time()
outputs = llm.generate(prompts, sampling_params)
end_time = time.time()
 
for i, output in enumerate(outputs):
prompt = prompts[i]
generated_text = output.outputs[0].text
print(f"Prompt {i+1}: {prompt[:50]}...")
print(f"Generated: {generated_text[:100]}...")
print(f"Token count: {len(output.outputs[0].token_ids)}\n")
 
print(f"Total time for {len(prompts)} prompts: {end_time - start_time:.2f} seconds")

运行脚本：

BASH
python benchmark.py

方式二：启动OpenAI兼容的API服务 这是生产环境更常用的方式，便于集成。

BASH
# 启动API服务器，指定主机、端口和模型
python -m vllm.entrypoints.openai.api_server \
--model ./models/Qwen2.5-7B-Instruct-AWQ \
--quantization awq \
--served-model-name Qwen2.5-7B-Instruct \
--host 0.0.0.0 \
--port 8000 \
--tensor-parallel-size 1 \
--gpu-memory-utilization 0.9 \
--trust-remote-code

服务启动后，你可以通过curl或Python客户端进行调用：

BASH
# 测试聊天补全接口
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "Qwen2.5-7B-Instruct",
"messages": [
{"role": "user", "content": "你好，请介绍一下你自己。"}
],
"max_tokens": 100,
"temperature": 0.7
}'

4. 性能调优与关键参数解析

要让MI355X在vLLM上发挥出超越B200的潜力，必须理解并调整关键参数。性能调优本质上是吞吐量（Throughput）、延迟（Latency） 和显存利用率（Memory Utilization） 之间的权衡。

4.1 影响性能的核心vLLM参数

下表列出了在AMD MI355X上使用vLLM时最需要关注的参数：

参数 含义与影响 调优建议 (针对 MI355X)
--tensor-parallel-size 张量并行度。将模型层拆分到多个GPU上。 MI355X单卡设为1。如果有多张MI355X，可设置为卡数（如2，4），以加载更大模型或提升吞吐。
--gpu-memory-utilization GPU显存利用率目标（0~1）。vLLM会据此预留内存。 关键参数。建议从0.85开始尝试。设置过高（如0.99）可能导致OOM；过低则浪费显存，减少并发量。
--max-num-seqs 引擎中同时处理的最大请求序列数。 增加此值可提升吞吐，但会增加延迟和显存占用。根据gpu_memory_utilization和模型大小动态调整。通常设置为[64, 256]。
--max-model-len 模型支持的最大上下文长度（Token数）。 直接影响KV Cache内存占用。不要盲目设为模型宣称的最大值（如32768）。根据实际需求设置（如4096, 8192），能显著减少内存开销，增加并发。
--block-size PagedAttention中内存块的大小（Token数）。 默认16。对于长上下文，可以适当增大（如32），可能提升效率，但会减少调度的灵活性。建议先使用默认值。
--quantization 量化方法，如awq, gptq, squeezellm。 显存不足时的救命稻草。AWQ是vLLM首重量化支持，能在轻微精度损失下将显存占用降低至1/3或1/4。
--dtype 模型权重加载的数据类型。 auto（默认）或half（float16）。bfloat16在AMD GPU上可能不支持或性能不佳，优先使用float16。

4.2 针对吞吐量与延迟的配置策略

  • 追求高吞吐量（离线批量处理、高并发API）：

    • 适当增加--max-num-seqs（如128）。
    • 在显存允许范围内，增加--gpu-memory-utilization（如0.9）。
    • 使用--enable-prefix-caching（如果支持）来处理有共享前缀的提示词。
    • 使用连续批处理（vLLM默认），这是其最大优势。

  • 追求低延迟（交互式对话）：

    • 减少--max-num-seqs（如32），减少调度开销。
    • 确保--max-model-len接近实际平均对话长度，避免分配过多不必要的KV Cache内存。
    • 考虑使用更小的模型或更激进的量化。

4.3 使用vLLM Benchmark工具进行评估

vLLm内置了性能基准测试工具，这是量化比较MI355X与B200等硬件性能的客观方法。

BASH
# 基准测试：模拟高并发请求，测量吞吐和延迟
python -m vllm.entrypoints.benchmark \
--model ./models/Qwen2.5-7B-Instruct-AWQ \
--quantization awq \
--tokenizer ./models/Qwen2.5-7B-Instruct-AWQ \
--num-prompts 1000 \ # 总请求数
--request-rate 10 \ # 每秒注入的请求数（用于模拟并发）
--dataset sharegpt \ # 使用sharegpt格式的测试数据集，或自定义
--output-format json \
--save-result benchmark_mi355x.json

运行后，分析输出的JSON文件，重点关注：

  • completed_requests: 成功完成的请求数。
  • throughput_requests_per_second: 每秒处理的请求数（RPS）。
  • latency_mean, latency_p50, latency_p99: 平均、中位数、99分位延迟。 将MI355X的测试结果与在相同模型、相同vLLM版本和配置下B200的测试结果进行对比，才能得出“推理性能超越”的具体数据支撑。

5. 生产环境部署、监控与问题排查

将实验性服务转化为稳定的生产服务，需要额外的工程化工作。

5.1 部署架构建议

对于生产环境，不建议直接使用python -m命令运行。建议采用以下架构：

  1. 进程管理：使用systemd或supervisor来管理vLLM API服务器进程，实现开机自启、自动重启。
    INI
    # 示例 supervisor 配置 (/etc/supervisor/conf.d/vllm.conf)
    [program:vllm-api]
    command=/home/user/miniconda3/envs/vllm-amd/bin/python -m vllm.entrypoints.openai.api_server --model /path/to/model --host 0.0.0.0 --port 8000
    directory=/home/user
    user=user
    autostart=true
    autorestart=true
    stderr_logfile=/var/log/vllm.err.log
    stdout_logfile=/var/log/vllm.out.log
  2. 反向代理与负载均衡：使用Nginx或HAProxy作为vLLM API服务器的反向代理，提供SSL终止、负载均衡（如果有多台服务器）和基础的安全防护。
  3. 多实例部署：如果单张MI355X的吞吐仍不能满足需求，可以考虑部署多个vLLM实例（在不同端口），并通过负载均衡器分发请求。或者，使用vLLM的--tensor-parallel-size和--pipeline-parallel-size进行多卡模型并行（需要多张GPU）。

5.2 监控与日志

有效的监控是保障服务稳定的眼睛。

  • vLLM日志：启动时添加--log-level INFO或DEBUG。日志会输出到标准错误，通过进程管理器重定向到文件。关注日志中的INFO和WARNING信息。
  • GPU监控：使用rocm-smi定期采样或使用其日志模式。
    BASH
    # 每5秒采样一次GPU状态，输出到文件
    rocm-smi --showallinfo --loop 5 --output gpu_stats.log
    监控显存使用率、GPU利用率、温度和功耗。
  • 系统监控：使用htop, nvidia-smi（类比）、dstat等工具监控CPU、系统内存、网络和磁盘IO。
  • 应用层监控：在调用vLLM API的客户端或代理层记录每个请求的响应时间、状态码和Token数量，便于分析性能瓶颈。

5.3 常见问题排查清单

结合网络搜索材料中的高频问题，以下是AMD MI355X + vLLM部署的典型故障排查路径：

问题现象 可能原因 检查与解决步骤
模型加载失败，提示CUDA/ROCm错误 1. ROCm驱动未正确安装或版本不匹配。
2. PyTorch的ROCm版本与系统ROCm版本不一致。
3. 显存不足。		 1. 运行rocm-smi确认GPU被识别且驱动正常。
2. 运行python -c “import torch; print(torch.__version__)”确认PyTorch版本，并与ROCm版本对照官方兼容性列表。
3. 运行rocm-smi查看显存占用，尝试用更小的模型或量化模型。
vLLM服务启动时报错，提示flash-attn相关错误 FlashAttention算子对ROCm的支持不完全。 1. 安装vLLM时尝试禁用flash-attn（如前文所述）。
2. 设置环境变量export VLLM_ATTENTION_BACKEND=xformers，并确保已安装xformers（pip install xformers）。
3. 使用vLLM的--attention-backend参数指定xformers或auto。
推理速度极慢，GPU利用率低 1. 模型未完全加载到GPU。
2. 输入输出瓶颈（CPU预处理/后处理）。
3. --max-num-seqs设置过小，无法充分利用连续批处理。
4. 使用了不支持的dtype（如bfloat16）。		 1. 检查rocm-smi，确认模型加载后显存占用是否合理。
2. 使用性能分析工具（如PyTorch Profiler）查看热点。
3. 逐步增加--max-num-seqs，观察吞吐量变化。
4. 确保--dtype为auto或half。
服务运行一段时间后OOM（内存不足） 1. --gpu-memory-utilization设置过高。
2. --max-model-len设置过大，导致KV Cache爆炸。
3. 内存泄漏（相对少见）。		 1. 降低--gpu-memory-utilization（如从0.9调到0.85）。
2. 根据实际需求大幅降低--max-model-len。
3. 监控显存使用趋势，如果持续缓慢增长，排查自定义代码或考虑重启服务。
vLLM Serve输出不一致（网络热词提及） 1. 未设置随机种子，导致采样结果随机。
2. 使用了temperature=0但top_p不为1，仍有随机性。
3. 模型文件损坏或加载错误。		 1. 在请求中或SamplingParams中固定seed。
2. 对于确定性输出，设置temperature=0且top_p=1。
3. 重新下载模型文件，并验证哈希值。
无法达到预期并发性能 1. 系统瓶颈（CPU、内存、网络）。
2. vLLM配置未优化。
3. 客户端请求模式不合理（请求间隔不均匀）。		 1. 使用dstat等工具监控系统资源，排除非GPU瓶颈。
2. 使用vllm.entrypoints.benchmark进行基准测试，对比官方数据。
3. 模拟更符合真实场景的请求流进行测试。

6. 总结与进阶方向

通过以上步骤，你应该已经成功在AMD MI355X上部署并优化了一个基于vLLM的大模型推理服务。MI355X与vLLM的组合，其优势在于通过高效的PagedAttention内存管理和连续批处理调度，在高并发推理场景下最大化硬件利用率，从而在总体拥有成本（TCO）上可能展现出竞争力。

要真正将这套方案用于生产，还需要考虑以下几个进阶方向：

  1. 模型量化深度优化：探索更激进的量化方案（如INT4 GPTQ），在可接受的精度损失下，进一步降低显存占用，提升服务容量。关注vLLM对SqueezeLLM等新量化方法的支持。
  2. 多模型动态部署：研究使用vLLM的LLMEngine或类似框架（如Ray Serve），实现根据请求动态加载和卸载不同模型，灵活应对多样化的推理需求。
  3. 与云原生生态集成：将vLLM服务容器化（Docker），并集成到Kubernetes集群中，利用HPA（水平Pod自动伸缩）根据QPS或GPU利用率自动扩缩容实例。
  4. 构建完整的AI网关：在vLLM API之前，增加一层AI网关，用于处理认证、限流、计费、请求/响应格式化、多模型路由、故障熔断等非功能性需求。
  5. 持续性能剖析：定期使用ROCm Profiler（rocprof）等工具对推理过程进行性能剖析，定位从内核计算到内存拷贝的每一个潜在瓶颈，进行微观调优。

最终，硬件性能的对比数据需要在你的具体业务场景、模型和负载下进行实测。建议建立一套持续的基准测试流程，不仅比较MI355X与B200，也跟踪vLLM新版本、ROCm新驱动以及模型量化技术带来的性能变化，让推理服务的演进始终建立在数据驱动的基础之上。

AMD MI355X大模型推理实战：基于vLLM与Llama-3-70B的性能部署指南
本文聚焦AMD MI355X加速卡与vLLM框架协同部署Llama-3-70B的大模型推理实践，涵盖ROCm环境搭建、PagedAttention内存优化原理、关键参数调优（如--gpu-memory-utilization、--block-size）、BF16精度配置及性能测试方法。重点验证MI355X凭借192GB HBM3高带宽内存在大批次、长上下文场景下的吞吐优势，并提供量化策略、多卡张量并行等工程化部署建议。
瑶瑶宝
327
AMD MI355X在vLLM上推理性能实测：从环境搭建到调优的完整指南
本文系统阐述AMD MI355X在vLLM框架下的大模型推理全流程：涵盖ROCm环境搭建、vLLM源码编译（含FlashAttention-ROCm适配）、模型加载与API服务部署，并深入分析PagedAttention内存优化、HBM3e带宽优势对吞吐量的影响。重点解析性能调优关键参数（如max_model_len、gpu_memory_utilization）、监控工具（rocgpuutils、vLLM Prometheus指标）及常见兼容性问题（PyTorch/ROCm/vLLM版本矩阵）。强调其适用于中高Batch Size、FP16/BF16精度的开源模型吞吐型推理场景。
迟子real
306
AMD MI350X/MI355X实战指南：HBM3E带宽优化与ROCm 7推理落地
本文深入解析AMD MI350X/MI355X在AI推理场景下的工程落地实践，聚焦HBM3E带宽优化、ROCm 7软件栈成熟度、vLLM原生支持、UBB8集群组网与llm-d调度框架。重点涵盖HBM3E物理实现与带宽确定性设计、Scale-Out架构下MoE模型高效运行、FP6量化优势、ROCm 7 HIP内核重写及PyTorch CI硬件闭环验证，并提供从选型到TCO核算的七步部署避坑指南。
superXX07
414
vLLM部署指南：在AMD MI300系列上运行Kimi-K2.6-NVFP4的完整教程
本教程详细介绍了如何在AMD MI300系列GPU（MI300/MI350/MI355）上使用vLLM部署NVFP4量化的Kimi-K2.6-NVFP4多模态大模型。涵盖ROCm 7.2.2环境配置、PyTorch与vLLM安装、模型加载、HTTP API推理、KV缓存与多GPU优化、GSM8K/MMLU_PRO基准测试，以及Docker容器化和负载均衡等生产级部署实践。
鲍珍博Quinn
1115
基于AMD MI355X与ROCm 6.1低成本部署GLM 5.2大模型实战指南
本文详述基于AMD MI355X GPU与ROCm 6.1平台低成本部署GLM 5.2大模型的全流程，涵盖Ubuntu 22.04系统配置、ROCm驱动与PyTorch-ROCm安装、BF16精度加载、KV缓存优化、量化压缩及vLLM推理服务集成。重点验证了单卡下40GB显存占用、350ms首token延迟与45–50 token/s生成速度，证实ROCm生态已具备主流大模型生产级推理能力。
只有橘子
283
如何快速部署GLM-5.2-MXFP4：AMD MI350/MI355上的完整指南
本文详细介绍了在AMD MI350/MI355 GPU上快速部署GLM-5.2-MXFP4大语言模型的完整流程，涵盖ROCm 7.0.0环境配置、MXFP4量化模型下载与结构解析、SGLang和vLLM两种推理引擎部署方案、GSM8K基准测试结果、内存优化（显存降低75%）、多GPU张量并行配置，以及ROCm兼容性、模型加载失败和OOM等常见问题排查方法。
经梦鸽
632
GLM5.2大模型在AMD MI355X上的高性能推理部署指南
本文详细介绍了GLM5.2大语言模型在AMD MI355X加速卡上的高性能推理部署全流程，涵盖ROCm环境配置、vLLM/TGI框架选型、模型量化（FP16/INT8/INT4）、OpenAI兼容API服务启动、吞吐量与显存占用测试。实测单卡达2626 tok/s，成本低于NVIDIA Blackwell架构，适用于批量处理、高并发API及长文本推理等企业级场景。
Mu Tian
201
如何快速部署MiniMax-M2.7-NVFP4：AMD MI300/MI350/MI355平台实战教程
本文详解MiniMax-M2.7-NVFP4模型在AMD MI300/MI350/MI355平台的快速部署流程，涵盖ROCm 7.2.2环境配置、vLLM服务启动、NVFP4量化加载、GSM8K精度验证（92.20%）及API调用。重点解决ROCm兼容性、显存不足与量化层加载失败等关键问题，并支持张量并行与动态激活量化优化。
尤琦珺Bess
1060
AMD MI355X与GLM5.2：高性价比AI推理方案的成本效益分析
本文基于实测数据，分析AMD MI355X在GLM5.2模型上的AI推理性能与成本效益。结果显示，MI355X单节点吞吐量达2626 tok/s，每百万token成本仅$0.30，约为NVIDIA B200的一半。文章涵盖CDNA 4架构特性、ROCm生态适配、vLLM部署优化、FP8量化实践及混合架构选型建议，聚焦吞吐密集型中文推理场景的成本控制与性能平衡。
葛店小学张洪雨
310
AMD MI300系列GPU性能调优：最大化Qwen3-30B-FP8推理效率
本文聚焦AMD MI300系列GPU（含MI300X/MI325等）上Qwen3-30B-FP8大模型的高效推理调优，涵盖ROCm 7.0+环境部署、FP8E4M3量化配置（含对称量化与关键层BF16保留）、vLLM参数调优（吞吐量最大化）、生成参数设置及OOM缓解策略。实测显示显存降低50%、推理速度提升2倍，验证FP8与MI300硬件协同的高性能优势。
郎沙圣Sebastian
949
AMD GPU上部署Qwen3-Coder-Next：ROCm 7.0 + vLLM 实战指南
本文详解Qwen3-Coder-Next在AMD MI300X/MI325X/MI355X GPU上的生产级部署，基于ROCm 7.0与vLLM定制化适配。重点涵盖CDNA3架构特性（HBM3带宽优化、Infinity Fabric互联）、ROCm 7.0关键变更（AITer JIT、HIP内存序、glibc依赖）、vLLM AMD专用wheel构建与ABI兼容性要求，以及BF16/FP8模式的硬件选型逻辑、PagedAttention调优、监控告警与成本优化策略。
hitomo
293
AMD MI300硬件优化指南：MiniMax-M2.1-MXFP4最佳实践
本文详解MiniMax-M2.1-MXFP4在AMD MI300/MI350/MI355 GPU上的部署与优化实践，涵盖MXFP4量化技术（权重静态+激活动态量化）、ROCm 7.0环境配置、vLLM/SGLang推理引擎调优、多GPU负载均衡及PagedAttention启用等关键步骤，并通过gsm8k验证99.91%精度恢复率，突出硬件加速与低精度高保真推理的协同优化。
凤红令Nathania
1237
如何在AMD MI350/MI355上部署DeepSeek-R1-0528-MXFP4-v2？完整教程在此
本文详细介绍了在AMD MI350/MI355 GPU上部署DeepSeek-R1-0528-MXFP4-v2模型的完整流程，涵盖ROCm 7.0环境搭建、PyTorch 2.8.0与Transformers 4.53.0依赖配置、SGLang推理引擎集成、MXFP4量化模型加载及lm-evaluation-harness评估（含AIME24和GSM8K）。强调AMD-Quark V0.10优化工具与硬件协同适配，实现高效AI推理。
胡同琥Randolph
592
Gemma4在AMD GPU上的生产级部署实战指南
本文详细阐述Gemma4大模型在AMD MI系列GPU（如MI350X）上的生产级部署实践，聚焦ROCm 7.2.1、vLLM Nightly、Python 3.12及glibc ≥ 2.35等硬性技术约束，涵盖Docker容器化部署、OpenAI兼容API验证、多模态图像推理调优，以及OOM、设备序号错误等高频问题的底层归因与解决方案，强调PagedAttention、HIP Kernel编译、NUMA绑定、HBM3带宽适配等关键技术点。
weixin_33045961
290
如何快速部署AMD MI300优化的Qwen3-30B-FP8模型：5步快速开始教程
本文详细介绍了在AMD MI300系列GPU（含MI325/MI350/MI355）上快速部署Qwen3-30B-A3B-Thinking-2507-FP8模型的五步流程，涵盖ROCm 7.0+环境配置、vLLM推理引擎安装、FP8量化模型加载、API服务启动及性能调优。重点突出FP8量化带来的内存减半、推理提速30–50%及GSM8K 87.2%准确率等关键技术指标，并支持Docker容器化与批量推理生产部署。
凌朦慧Richard
840
GLM5.2在AMD MI355X上的AI推理性能突破：2626 tok/s吞吐量与50%成本优势
本文详述GLM5.2大语言模型在AMD MI355X加速器上的AI推理性能表现，实测单节点吞吐达2626 tok/s，每token成本较NVIDIA Blackwell低1%-6%。重点分析CDNA 4架构硬件优势、GLM5.2模型特性（744B参数、长上下文、量化支持）、ROCm软件栈适配、FP8/FP4量化策略、批处理与并发优化方法，以及TCO成本优势，为大规模低成本LLM推理提供可行技术路径。
王释易
357
AMD GLM-4.7-MXFP4生产环境部署：Docker容器化与监控方案终极指南
本文详述AMD GLM-4.7-MXFP4模型在生产环境中的Docker容器化部署方案，涵盖基于ROCm 7.0的环境准备、vLLM推理服务器配置、Docker Compose编排、MXFP4 4位量化参数调优；同时提供Prometheus+Grafana监控体系搭建、健康检查端点、日志收集及GPU资源自动扩缩容等运维实践，专为AMD MI350/MI355硬件优化。
凤霞音Endurance
941
AMD推出ROCm 7软件平台追赶英伟达CUDA性能优势
AMD推出ROCm 7软件平台，大幅提升MI300系列及MI355X在AI训练与推理方面的性能，支持FP4等低精度数据类型和AITER张量引擎，增强对PyTorch、TensorFlow等框架兼容性，并集成至vLLM和SGLang，助力对抗CUDA生态优势。
至顶科技
1456
vLLM推理优化完全指南：如何在AMD Instinct GPU上实现最高性能
本文系统阐述vLLM在AMD Instinct MI300X/MI350X等GPU上实现高性能推理的完整优化路径，涵盖ROCm环境配置、AITER架构深度调优、张量/数据/专家并行策略选择、FP8 KV缓存量化、批处理与CUDA图参数调优，以及TTFT/ITL/TPS多维性能基准验证方法，聚焦大语言模型推理场景下的吞吐量提升与延迟降低。
薛烈珑Una
403
5个步骤实现GLM-5.2-MXFP4高效推理：SGLang与vLLM对比指南
本文介绍在AMD MI350/MI355硬件上部署GLM-5.2-MXFP4量化模型的5步流程，涵盖ROCm 7.0、PyTorch 2.9等环境配置，SGLang与vLLM双引擎部署方法，并对比其吞吐量、内存管理及长上下文支持等核心推理性能指标，给出适用场景建议与量化兼容性、张量并行调优等关键技术要点。
范轩锦
965
AMD MI325X/MI355X代际升级：CDNA 4架构与OCP-FP8实战解析
Alabaaaa
AMD vLLM-ATOM插件：面向Instinct GPU的AI推理加速方案
凿船尸爷
GPT-4稀疏激活原理：揭秘2%参数如何实现亚秒级推理
筱小龙