AMD MI355X大模型推理实战：基于vLLM与Llama-3-70B的性能部署指南

最近在部署大模型推理服务时，很多开发者都面临一个核心痛点：如何在有限的预算下，获得最佳的推理吞吐量和延迟？尤其是在面对动辄数十亿参数的大模型时，硬件选择往往决定了项目的成败。过去，NVIDIA的GPU几乎是唯一选择，但如今，随着AMD Instinct系列加速卡的持续发力，特别是MI300系列，市场格局正在悄然改变。本文将深入探讨AMD MI355X（Instinct MI300X OAM模组）在LLM推理场景下的性能表现，并与NVIDIA B200进行横向对比。更重要的是，我们将结合vLLM这一当前最流行的大模型推理框架，提供一套从环境搭建、驱动配置到性能测试的完整实战指南。无论你是正在评估硬件选型的架构师，还是需要亲手部署服务的工程师，这篇文章都能为你提供直接的参考和可复现的代码。

1. 背景与核心概念：为什么关注AMD MI300X与推理性能？

在深入实战之前，我们有必要厘清几个关键概念，理解这场性能竞赛背后的技术驱动力。

大模型推理（LLM Inference）指的是将训练好的大型语言模型（如Llama、Qwen、ChatGLM）部署上线，处理用户输入并生成文本的过程。与训练阶段不同，推理阶段对硬件的需求核心在于低延迟（Latency）和高吞吐量（Throughput）。延迟影响单次请求的响应速度，吞吐量决定单位时间内能处理的请求总数。

vLLM（Vectorized Large Language Model serving）是一个专为高效LLM推理和服务而设计的高吞吐量、低延迟推理引擎。它的核心创新在于PagedAttention算法和高效的内存管理机制，能够显著减少KV Cache的内存浪费，从而在相同硬件上支持更大的批次（batch size）和更长的序列长度，直接提升吞吐量。目前，vLLM已成为业界部署LLM服务的首选框架之一。

AMD Instinct MI300X是AMD推出的专为AI和HPC工作负载设计的加速器。MI355X是其OAM（OCP Accelerator Module）封装形式。它基于先进的CDNA 3架构，集成了高达192GB的HBM3内存，内存带宽达到5.3TB/s。巨大的内存容量和带宽对于需要加载庞大参数和存储KV Cache的大模型推理至关重要。

NVIDIA B200是NVIDIA基于Blackwell架构的最新旗舰GPU，同样针对AI计算进行了深度优化。它和MI300X是当前AI加速器市场最顶尖的竞争对手。

那么，为什么MI355X的推理性能值得关注？传统上，NVIDIA凭借其CUDA生态建立了极高的壁垒。然而，AMD通过ROCm开源软件栈，正在快速追赶。对于推理场景，尤其是vLLM这类高度优化的引擎，硬件的内存容量、内存带宽和计算单元效率是决定性因素。MI355X在内存规格上的优势，使其在处理超大规模模型（如700B参数）或需要极长上下文时，具备了理论上的优势。本文将验证这一理论优势在实际vLLM部署中能转化为多少实际性能提升。

2. 环境准备：搭建AMD ROCm与vLLM测试平台

性能测试的前提是一个稳定、配置正确的软件环境。本节将详细说明在Ubuntu系统上，为AMD MI355X配置ROCm驱动和vLLM的完整步骤。

2.1 硬件与操作系统要求

• 加速卡：AMD Instinct MI355X (MI300X OAM) 或 MI300A。本文指令主要针对MI300系列。
• 主机系统：推荐使用Ubuntu 22.04.3 LTS或Ubuntu 20.04.5 LTS。这是ROCm官方支持最完善的系统版本。
• 系统要求：
  • CPU需支持PCIe Gen4或更高。
  • 系统内存建议不少于512GB，以应对模型加载和数据处理。
  • 确保主板BIOS中已启用Above 4G Decoding和SR-IOV（如果使用虚拟化）。
• 网络：如需从Hugging Face下载模型，需保证网络通畅。

2.2 安装AMD ROCm驱动与工具链

ROCm是AMD的开放软件平台，相当于NVIDIA的CUDA Toolkit。以下步骤在Ubuntu 22.04上进行。

1. 添加ROCm仓库并安装内核驱动： 首先，添加ROCm的APT仓库并安装必要的内核模块和用户态驱动。

   # 1. 添加ROCm官方GPG密钥 wget -q -O - https://repo.radeon.com/rocm/rocm.gpg.key | sudo apt-key add - # 2. 添加ROCm APT仓库 (针对Ubuntu 22.04) echo 'deb [arch=amd64] https://repo.radeon.com/rocm/apt/6.1.2 jammy main' | sudo tee /etc/apt/sources.list.d/rocm.list # 3. 更新软件包列表并安装 sudo apt update sudo apt install rocm-hip-sdk rocm-dkms

   注意：6.1.2是ROCm的版本号，请根据你使用的MI355X卡和vLLM兼容性要求，查阅 ROCm官方文档 选择合适版本。MI300系列需要ROCm 6.0及以上版本。

2. 将用户添加到render和video组： 这一步是为了让非root用户有权访问GPU设备。

   sudo usermod -a -G render,video $LOGNAME

   执行后需要注销并重新登录，或重启系统使组变更生效。

3. 验证ROCm安装： 安装完成后，使用rocminfo和rocm-smi命令验证GPU是否被正确识别。

   # 查看ROCm设备信息 rocminfo # 查看GPU状态，类似nvidia-smi rocm-smi

   如果安装成功，rocm-smi会显示MI355X的设备信息、温度、功耗和内存使用情况。

2.3 配置Python环境与安装vLLM

为了避免系统Python环境混乱，强烈建议使用Conda或venv创建独立的虚拟环境。

1. 创建并激活Conda环境：

   # 安装Miniconda (如果未安装) # wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh # bash Miniconda3-latest-Linux-x86_64.sh # 创建名为`vllm_amd`的Python 3.10环境 conda create -n vllm_amd python=3.10 -y conda activate vllm_amd

2. 安装PyTorch with ROCm： vLLM依赖于PyTorch。必须安装与ROCm版本对应的PyTorch。

   # 示例：为ROCm 6.1安装PyTorch。请访问 https://pytorch.org/get-started/locally/ 获取最新命令。 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.1

3. 安装vLLM： 安装支持AMD GPU的vLLM版本。推荐从源码安装以获得最新特性和更好的兼容性。

   # 克隆vLLM仓库 git clone https://github.com/vllm-project/vllm.git cd vllm # 安装vLLM及其依赖 (使用`--no-deps`避免覆盖刚安装的PyTorch) pip install -e . --no-deps # 或者，直接安装预编译的wheel包 (版本可能滞后) # pip install vllm

4. 验证vLLM能否识别AMD GPU： 运行一个简单的Python脚本进行验证。

   # 文件：test_gpu.py import torch from vllm import LLM print(f"PyTorch version: {torch.__version__}") print(f"PyTorch ROCm support: {torch.cuda.is_available()}") # 在ROCm上，这个函数也可能返回True print(f"Available devices: {torch.cuda.device_count()}") # 尝试初始化一个微型模型来测试vLLM try: # 使用一个非常小的模型进行测试，例如`tiny-random/Llama-2-7b`（需要先huggingface-cli login） # 或者直接测试设备 llm = LLM(model="facebook/opt-125m", tokenizer="facebook/opt-125m", device="cuda") # vLLM 会自动使用ROCm print("vLLM initialization successful!") except Exception as e: print(f"vLLM initialization failed: {e}")

   执行python test_gpu.py。如果成功输出设备信息且没有报错，说明环境基本配置成功。

3. 核心原理与配置调优：理解vLLM在AMD GPU上的工作方式

要让vLLM在MI355X上发挥最佳性能，需要理解其关键机制并进行针对性配置。

3.1 vLLM的核心：PagedAttention与内存管理

vLLM性能飞跃的关键在于PagedAttention。传统Attention计算时，每个序列的KV Cache需要连续内存，导致内存碎片化，无法充分利用GPU内存。PagedAttention借鉴操作系统虚拟内存分页的思想，将KV Cache划分为固定大小的块（pages），这些块可以非连续地存储在物理内存中。

对于MI355X这类拥有超大HBM容量（192GB）的加速卡，PagedAttention的优势更加明显：

1. 更高的内存利用率：几乎可以消除内存碎片，将模型参数和KV Cache几乎填满整个192GB内存，从而支持更大的批处理大小（batch size）或更长的上下文长度。
2. 高效的共享：对于提示词（prompt）相同的大量请求，vLLM可以跨多个序列共享其KV Cache页面，极大减少重复计算。

3.2 vLLM关键启动参数解析

通过vllm.LLM或命令行vllm serve启动服务时，以下参数对性能影响巨大：

• --tensor-parallel-size： 张量并行度。对于MI355X，通常设置为物理GPU卡的数量。例如，单卡设为1。
• --block-size： PagedAttention中块的大小。默认是16。对于长上下文，可以适当增大（如32）以减少块表开销，但会增加内存浪费。需要根据模型和序列长度权衡。
• --gpu-memory-utilization： 允许vLLM使用的GPU内存比例。对于MI355X，可以设置得较高（如0.95），以充分利用192GB内存。但需为系统和其它进程预留少量空间。
• --max-num-batched-tokens： 调度器一次处理的最大token数。这是控制吞吐量和延迟的关键。增加此值可以提高吞吐，但可能增加单个请求的延迟。需要根据实际负载测试找到平衡点。
• --dtype： 模型加载的数据类型。auto（默认）会尝试使用half（FP16）。为了在MI355X上获得最佳性能，可以尝试使用bfloat16（如果模型支持），因为它在MI300系列上有更好的硬件支持。
• --quantization： 量化方法。如awq,gptq,squeezellm。量化可以显著减少内存占用，从而运行更大的模型或更大的批次，但可能会轻微损失精度。MI355X的大内存使其在不量化的情况下运行70B模型成为可能，这是其相对B200的一个优势场景。

3.3 AMD ROCm特定优化点

• FlashAttention-2： vLLM支持FlashAttention-2，它能大幅加速Attention计算。确保在源码编译vLLM时启用了FlashAttention-2支持。ROCm对FlashAttention-2有持续优化。
• HipGraphs： ROCm的图形捕获功能，类似于CUDA Graphs，可以减少内核启动开销。vLLM在某些版本中开始实验性支持。
• 使用HSA_OVERRIDE_GFX_VERSION： 对于MI300系列，可能需要设置此环境变量来确保编译器针对正确的GPU架构生成代码。

  export HSA_OVERRIDE_GFX_VERSION=11.0.0

4. 完整实战：部署并测试Llama-3-70B模型

我们以Meta最新开源的Llama-3-70B-Instruct模型为例，演示如何在MI355X单卡上部署，并与假想的B200环境进行性能对比测试。

4.1 准备模型权重

1. 访问Hugging Face Model Hub的 Meta-Llama-3-70B-Instruct 页面。

2. 接受许可协议。

3. 使用Hugging Face CLI登录并下载模型（确保你有足够的磁盘空间，约140GB）。

   huggingface-cli login huggingface-cli download meta-llama/Meta-Llama-3-70B-Instruct --local-dir ./models/Meta-Llama-3-70B-Instruct --local-dir-use-symlinks False

4.2 启动vLLM离线推理API服务器

我们将使用vLLM内置的高性能API服务器，它兼容OpenAI API协议。

# 在vllm虚拟环境中执行 conda activate vllm_amd # 启动服务器，关键参数针对MI355X优化 python -m vllm.entrypoints.openai.api_server \ --model ./models/Meta-Llama-3-70B-Instruct \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.93 \ --max-num-batched-tokens 16384 \ --block-size 32 \ --dtype bfloat16 \ --served-model-name llama-3-70b \ --port 8000

参数解释：

• --model: 指定本地模型路径。
• --tensor-parallel-size 1: 单卡运行。
• --gpu-memory-utilization 0.93: 使用约179GB的GPU内存，为系统预留空间。
• --max-num-batched-tokens 16384: 调度器每轮处理最多16384个token，平衡吞吐与延迟。
• --block-size 32: 针对70B大模型和可能的长上下文，使用稍大的块大小。
• --dtype bfloat16: 使用BF16精度，在MI355X上性能更好且内存占用仅为FP16的一半。

服务器启动后，会加载模型至GPU内存。对于70B模型，加载时间可能较长。

4.3 编写性能测试脚本

我们编写一个Python客户端脚本，模拟并发请求，测试吞吐量（Tokens/Second）和延迟（Time to First Token, TTFT）。

# 文件：benchmark_mi355x.py import asyncio import aiohttp import time import statistics from typing import List, Dict async def send_request(session: aiohttp.ClientSession, prompt: str, request_id: int): """发送单个请求到vLLM服务器""" url = "http://localhost:8000/v1/completions" headers = {"Content-Type": "application/json"} payload = { "model": "llama-3-70b", "prompt": prompt, "max_tokens": 128, # 每个请求生成128个token "temperature": 0.0, "stream": False # 非流式，便于计算总时间 } start_time = time.perf_counter() try: async with session.post(url, json=payload, headers=headers) as response: result = await response.json() end_time = time.perf_counter() latency = end_time - start_time if "choices" in result: generated_text = result["choices"][0]["text"] token_count = len(generated_text.split()) # 粗略估算token数 return {"id": request_id, "latency": latency, "tokens": token_count, "success": True} else: print(f"Request {request_id} failed: {result}") return {"id": request_id, "latency": latency, "tokens": 0, "success": False} except Exception as e: print(f"Request {request_id} exception: {e}") return {"id": request_id, "latency": 0, "tokens": 0, "success": False} async def benchmark(concurrent_clients: int, total_requests: int, prompt: str): """执行基准测试""" connector = aiohttp.TCPConnector(limit=0) # 不限制连接数 async with aiohttp.ClientSession(connector=connector) as session: tasks = [] request_id = 0 # 创建第一批并发任务 for _ in range(min(concurrent_clients, total_requests)): tasks.append(send_request(session, prompt, request_id)) request_id += 1 results = [] start_test_time = time.perf_counter() while tasks: done, pending = await asyncio.wait(tasks, return_when=asyncio.FIRST_COMPLETED) for task in done: result = await task results.append(result) # 如果还有请求需要发送，则补充一个新任务 if request_id < total_requests: new_task = send_request(session, prompt, request_id) pending.add(new_task) request_id += 1 tasks = pending end_test_time = time.perf_counter() total_test_duration = end_test_time - start_test_time # 分析结果 successful_results = [r for r in results if r["success"]] latencies = [r["latency"] for r in successful_results] total_tokens = sum([r["tokens"] for r in successful_results]) print(f"\n=== Benchmark Results (Concurrent={concurrent_clients}, Requests={total_requests}) ===") print(f"Successful requests: {len(successful_results)}/{len(results)}") print(f"Total test duration: {total_test_duration:.2f} seconds") print(f"Total tokens generated: {total_tokens}") print(f"Throughput: {total_tokens / total_test_duration:.2f} tokens/second") if latencies: print(f"Average latency: {statistics.mean(latencies):.2f} seconds") print(f"P95 latency: {np.percentile(latencies, 95):.2f} seconds") if len(latencies) > 1 else "" print(f"Max latency: {max(latencies):.2f} seconds") if __name__ == "__main__": # 测试参数 CONCURRENT_CLIENTS = 8 # 并发用户数 TOTAL_REQUESTS = 100 # 总请求数 TEST_PROMPT = "请用中文解释一下量子计算的基本原理。" # 测试提示词 asyncio.run(benchmark(CONCURRENT_CLIENTS, TOTAL_REQUESTS, TEST_PROMPT))

4.4 运行测试并解读结果

1. 确保vLLM服务器正在运行。
2. 在另一个终端，运行基准测试脚本：

   python benchmark_mi355x.py

3. 观察输出结果。关键指标是Throughput (tokens/second)和Average latency。

性能对比分析思路（模拟）： 假设我们在AMD MI355X（单卡）和NVIDIA B200（单卡）上，使用完全相同的vLLM版本、模型（Llama-3-70B）、参数配置和测试脚本进行测试。

• 场景一：内存容量受限下的最大批次处理

  • MI355X (192GB HBM3)： 可能在不启用量化的情况下，直接以BF16精度加载70B模型（约140GB），并留有约50GB空间用于KV Cache。这允许它设置一个非常大的--max-num-batched-tokens，从而在高吞吐量场景下（如批量处理大量用户查询）表现优异。
  • B200 (假设配置高显存版本)： 如果其显存小于192GB，则可能需要对70B模型进行量化（如AWQ/GPTQ）才能运行，或者无法支持同样大的批处理大小。量化会引入轻微精度损失，并可能增加计算开销。

• 场景二：长上下文推理

  • 当请求的上下文长度极长（如128K tokens）时，KV Cache占用内存巨大。
  • MI355X的大内存可以容纳更多的PagedAttention块，减少换入换出，从而在处理超长文本时保持更稳定的延迟和更高的吞吐。

• 实际性能数据（需实测）：

  • 吞吐量： 在并发请求下，MI355X凭借大内存支持的大批次，可能取得更高的总体吞吐量（tokens/sec）。
  • 首Token延迟（TTFT）： 受内存带宽和计算单元效率影响。MI355X的5.3TB/s超高内存带宽有助于快速加载参数和Cache，可能带来极具竞争力的TTFT。
  • 每Token延迟： 生成阶段的速度，更依赖于计算核心的效率和软件优化。

结论： 根据网络上的相关测试与讨论（参考“AMD MI355X 推理性能超越 B200”这一主题），MI355X在部分LLM推理基准测试中，尤其是需要大内存容量或大批次处理的场景下，其性能表现已经达到甚至超越了同期的顶级竞品。其核心优势在于巨大的HBM3内存容量和带宽与vLLM的PagedAttention内存管理形成了完美互补。

5. 常见问题与排查思路

在AMD GPU上部署vLLM可能会遇到一些特有问题，以下是常见问题的排查指南。

6. 最佳实践与工程建议

基于MI355X和vLLM的部署经验，总结以下工程实践要点：

1. 版本固化与环境隔离：

   • AI软件栈迭代迅速，生产环境务必严格记录所有组件的版本：ROCm版本、PyTorch版本、vLLM commit哈希、Python版本、模型版本。
   • 使用Conda或Docker将整个环境打包，确保可复现性。AMD官方提供包含ROCm的Docker镜像。

2. 监控与告警：

   • 使用rocm-smi定期监控GPU利用率、内存使用、温度和功耗。
   • 集成Prometheus+Grafana，利用vLLM的指标端点（--metrics-port）收集推理延迟、吞吐量、队列长度等业务指标。
   • 为GPU内存使用率、温度设置告警阈值。

3. 模型量化策略：

   • MI355X优势场景： 由于其大内存，对于70B及以下模型，可以优先考虑不量化，以保持最佳精度和简化部署流程。
   • 追求极致吞吐： 如果需要运行更大的模型（如未来可能的140B+）或追求极致的并发能力，可以采用GPTQ/AWQ INT4量化，能在精度损失极小的情况下，将内存占用减半，从而将吞吐量提升近一倍。

4. 多卡部署与推理优化：

   • 张量并行（Tensor Parallelism）： 对于单卡无法装载的巨型模型（如Llama-3-405B），可以使用多张MI355X通过--tensor-parallel-size进行张量并行推理。vLLM对此有良好支持。
   • 流水线并行与模型分片： 对于超大规模模型，可研究结合vLLM与DeepSpeed或Megatron-LM进行更复杂的分布式推理。

5. 生产环境服务化：

   • 使用vllm.entrypoints.openai.api_server作为后端，搭配Nginx进行负载均衡和反向代理。
   • 考虑使用vLLM的离线批处理功能对大量静态提示词进行预处理，生成KV Cache并缓存，可极大提升在线推理效率。
   • 制定模型更新和回滚策略，利用vLLM的--model参数可以快速切换模型版本。

AMD MI355X凭借其卓越的硬件规格，结合vLLM这类高度优化的推理引擎，正在为大模型推理赛道提供一个新的高性能选择。对于受限于GPU内存的推理任务，它是一个强有力的竞争者。成功的部署离不开细致的环境配置、深入理解的参数调优以及系统的工程化实践。建议读者在评估时，务必基于自身的实际模型、流量模式和延迟要求进行全面的基准测试。