最近在折腾本地大模型推理发现一个让人眼前一亮的组合AMD Arc Pro B70 专业显卡 vLLM 推理引擎居然能让一个 26B 参数的大模型在单卡上跑出超过 300 Token/s 的推理速度。这个成绩对于追求高性价比、希望用消费级或入门专业卡跑大模型的开发者来说无疑是个重磅消息。本文将为你完整拆解这套方案的原理、部署步骤、性能调优技巧以及背后的技术细节无论你是想低成本搭建AI应用还是单纯对高性能推理优化感兴趣都能从中获得一套可直接复现的实战方案。1. 背景与核心概念为什么是 Arc Pro B70 和 vLLM在深入实操之前我们有必要理解几个关键概念这能帮你明白为什么这个组合能带来如此显著的性能提升。1.1 大模型本地推理的瓶颈与机遇随着 ChatGPT 等应用的普及越来越多的开发者和企业希望将大语言模型LLM部署在本地或私有环境中。然而大模型动辄数十亿甚至上百亿的参数规模对计算硬件尤其是 GPU 的显存和算力提出了极高要求。传统的部署方式往往面临两大难题显存瓶颈模型参数、KV Cache用于加速自回归生成会占用大量显存导致许多大模型无法在单张消费级显卡上运行。计算效率低下简单的模型加载和逐 Token 生成无法充分利用 GPU 的并行计算能力导致推理速度慢Token 生成速率Token/s低。1.2 vLLM高性能推理的“引擎”vLLM是一个专为大模型推理设计的高吞吐量、内存高效的服务引擎。它的核心创新在于PagedAttention算法灵感来源于操作系统的虚拟内存和分页机制。传统Attention为每个请求的序列预先分配一块连续的显存来存储 KV Cache。当处理变长序列或大量并发请求时会产生严重的显存碎片利用率低下。PagedAttention将 KV Cache 分割成固定大小的“块”blocks像操作系统管理内存页一样管理它们。不同请求的块可以非连续地存储在显存中并通过一个“块表”来记录逻辑关系。这带来了两大好处近乎零显存碎片显著提高了显存利用率可以在同一块 GPU 上运行更大的模型或服务更多的并发请求。高效共享对于提示Prompt相同或部分相同的请求其对应的 KV Cache 块可以在不同请求间共享避免了重复计算极大提升了吞吐量。简单说vLLM 让 GPU 显存的使用变得非常“经济”从而为在有限显存下运行大模型并保持高吞吐量提供了可能。1.3 AMD Arc Pro B70被低估的“性价比之选”AMD Arc Pro B70 是一款面向工作站的专业显卡。在此次大模型推理场景中它展现出惊人性价比的关键在于大显存通常配备 16GB GDDR6 显存。对于量化后的 26B 参数模型这个容量是足够的。对 BF16 数据类型的硬件支持BF16Brain Floating Point 16是一种半精度浮点数格式在保持足够数值范围的同时相比 FP32 减少了一半的存储和带宽占用。Arc 显卡对 BF16 有良好的硬件加速支持。软件生态改善随着 ROCmAMD 的 GPU 计算平台对 PyTorch 等框架支持的持续完善以及 vLLM 对 AMD GPU 后端通过 ROCm的集成使得在这张卡上运行优化后的推理引擎成为现实。核心逻辑链条vLLM 通过 PagedAttention 极致优化显存使用 - 使得 26B 模型能“塞进”B70的16G显存 - B70的硬件BF16支持与vLLM的高效计算调度结合 - 最终实现单卡高Token/s的推理性能。2. 环境准备与版本说明要复现这个高性能推理环境我们需要搭建一个支持 ROCm 的软件栈。以下环境是经过验证可用的配置。操作系统: Ubuntu 22.04 LTS 或 20.04 LTS。这是 ROCm 官方支持较好的系统版本。GPU: AMD Arc Pro B70 (或其他支持 ROCm 的 AMD GPU如 MI系列)。Python: 3.8 - 3.10。建议使用 3.9 或 3.10。关键软件版本ROCm: 5.7 或 6.0 版本。本文示例以 ROCm 6.0 为例。PyTorch: 必须安装支持 ROCm 的版本。vLLM: 0.3.3 或更高版本需支持 ROCm 后端。下面开始一步步搭建环境。2.1 安装 ROCm 6.0首先添加 ROCm 的官方仓库并安装核心组件。# 1. 添加 ROCm 仓库的 GPG 密钥 wget https://repo.radeon.com/rocm/rocm.gpg.key -O - | sudo gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/rocm.gpg /dev/null # 2. 添加 ROCm 6.0 仓库 echo deb [archamd64] https://repo.radeon.com/rocm/apt/6.0 jammy main | sudo tee /etc/apt/sources.list.d/rocm.list # 3. 更新软件包列表并安装 ROCm sudo apt update sudo apt install rocm-hip-sdk rocm-dev安装完成后将当前用户添加到render和video组并重启系统。sudo usermod -a -G render,video $USER echo export PATH$PATH:/opt/rocm/bin ~/.bashrc echo export LD_LIBRARY_PATH$LD_LIBRARY_PATH:/opt/rocm/lib ~/.bashrc source ~/.bashrc # 重启系统 sudo reboot重启后运行rocm-smi命令检查 GPU 是否被正确识别。rocm-smi你应该能看到 Arc Pro B70 显卡的信息。2.2 安装 PyTorch with ROCm前往 PyTorch 官网 选择对应的 ROCm 版本。例如对于 ROCm 6.0 和 Python 3.10安装命令如下pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.0安装后在 Python 中验证 PyTorch 是否能识别 AMD GPUimport torch print(fPyTorch version: {torch.__version__}) print(fIs ROCm available? {torch.cuda.is_available()}) # 注意在ROCm上torch.cuda.is_available() 也返回 True print(fDevice name: {torch.cuda.get_device_name(0)})2.3 安装 vLLM 及其 ROCm 依赖vLLM 的主干版本已支持 ROCm 后端。我们直接通过 pip 安装并确保安装正确的依赖。# 安装 vLLM pip install vllm # vLLM 的 ROCm 支持需要一些额外的内核依赖通常会在安装时自动处理。 # 为了确保无误可以安装 ninja用于编译 sudo apt install ninja-build安装完成后验证 vllm 是否成功安装python -c import vllm; print(vllm.__version__)3. 模型准备与量化让 26B 模型“住进”16G显存26B 参数的模型如果以 FP16半精度加载大约需要 52GB 显存每个参数2字节这远超 B70 的 16GB。因此量化Quantization是必不可少的一步。量化通过降低模型权重的数值精度来减少显存占用和计算量同时力求保持模型精度损失最小。目前最流行的量化格式是AWQ(Activation-aware Weight Quantization) 和GPTQ。vLLM 对这两种格式都有良好的支持。我们将以Qwen2.5-7B的 AWQ 量化版为例进行演示因为26B模型的AWQ/GPTQ版本更容易获取和验证原理与26B一致。你可以在 Hugging Face 模型库搜索类似Qwen2.5-32B-AWQ的模型。步骤找到并下载量化模型访问 Hugging Face 官网 (huggingface.co)。在搜索框输入模型名称例如 “Qwen2.5-32B-AWQ” 或 “Llama-3.1-8B-AWQ”。进入模型页面你会看到模型文件和配置文件。我们需要的是包含.safetensors权重文件和config.json的整个仓库。我们可以使用git-lfs来下载大模型文件或者使用huggingface-hub库的 Python 接口。这里使用git方式# 安装 git-lfs sudo apt install git-lfs git lfs install # 克隆模型仓库以 Qwen2.5-7B-Instruct-AWQ 为例实际请替换为你的目标26B模型 git clone https://huggingface.co/Qwen/Qwen2.5-7B-Instruct-AWQ这会下载模型到当前目录下的Qwen2.5-7B-Instruct-AWQ文件夹。请确保你的磁盘有足够空间一个7B的AWQ模型约4-5GB26B的会更大。4. 使用 vLLM 部署模型并测试性能环境与模型就绪后就是最激动人心的部署与性能测试环节。4.1 启动 vLLM 推理服务器vLLM 提供了一个高效的 OpenAI 兼容的 API 服务器。我们通过命令行启动它。# 基本启动命令 python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ # 替换为你的模型本地路径例如 ./Qwen2.5-7B-Instruct-AWQ --served-model-name qwen-awq \ # 服务标识名称 --tensor-parallel-size 1 \ # 张量并行大小单卡设为1 --gpu-memory-utilization 0.9 \ # GPU显存利用率目标0.9表示使用90%的显存 --max-model-len 8192 \ # 模型支持的最大上下文长度 --api-key token-abc123 \ # 可选的API密钥用于简单认证 --port 8000 # 服务端口关键参数详解--model: 模型本地路径必须指向包含config.json和.safetensors文件的文件夹。--tensor-parallel-size: 模型并行度。单卡推理设为1。如果你有多张卡可以设置为卡数以实现模型层在多个GPU上的切分。--gpu-memory-utilization: 非常重要的参数。它告诉 vLLM 可以计划使用多少比例的 GPU 显存。设置为 0.990%通常是一个安全且高效的选择为系统和其他进程留出空间。--max-model-len: 定义模型能处理的最大序列长度Prompt Completion。需要根据模型本身的能力和你的显存大小设置。设置过大可能导致OOM内存溢出。--dtype bf16: 指定加载模型的计算数据类型。对于支持 BF16 的 AMD 显卡使用bf16通常能获得最佳性能。如果模型已经是 AWQ/GPTQ 量化格式通常是 int4则无需指定vLLM 会自动识别。--enforce-eager: 这是一个调试或兼容性参数。默认为FalsevLLM 会使用自定义的高效内核。如果遇到某些算子不支持或运行错误可以尝试设置为True来强制使用 PyTorch 的 eager 模式但性能会下降。在 ROCm 环境下如果遇到内核不兼容的报错可以尝试启用此选项。对于我们的 Arc Pro B70 26B AWQ 模型场景一个更具体的启动命令可能如下python -m vllm.entrypoints.openai.api_server \ --model ./Qwen2.5-32B-AWQ \ --served-model-name qwen32b-awq \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.92 \ --max-model-len 4096 \ --dtype bf16 \ --port 8000启动成功后终端会输出日志显示模型加载进度最后提示服务已在http://localhost:8000启动。4.2 性能测试测量 Token/s服务启动后我们需要一个工具来测试推理速度。我们可以编写一个简单的 Python 测试脚本使用openai库兼容 vLLM 的 API来发送请求并计算 Token 生成速度。创建一个名为benchmark_vllm.py的文件import time import asyncio from openai import OpenAI # 初始化客户端指向本地 vLLM 服务器 client OpenAI( base_urlhttp://localhost:8000/v1, # vLLM OpenAI API 的端点 api_keytoken-abc123 # 与启动命令中的 --api-key 一致 ) async def generate_stream(): start_time time.time() first_token_time None completion_tokens 0 # 发起流式请求 stream client.chat.completions.create( modelqwen32b-awq, # 与 --served-model-name 一致 messages[{role: user, content: 请用中文介绍一下人工智能的发展历史要求500字左右。}], max_tokens512, # 限制生成的长度便于测试 temperature0.7, streamTrue # 启用流式输出以便计算首个 Token 延迟 (Time to First Token, TTFT) ) print(开始生成...) for chunk in stream: if chunk.choices[0].delta.content is not None: completion_tokens 1 if first_token_time is None: first_token_time time.time() ttft first_token_time - start_time print(f首个 Token 延迟 (TTFT): {ttft:.3f} 秒) # 可选实时打印生成内容 # print(chunk.choices[0].delta.content, end, flushTrue) end_time time.time() total_time end_time - start_time throughput completion_tokens / total_time print(f\n{*50}) print(f测试完成!) print(f总生成 Token 数: {completion_tokens}) print(f总耗时: {total_time:.3f} 秒) print(f生成吞吐量: {throughput:.2f} Token/s) print(f首个 Token 延迟: {ttft:.3f} 秒) print(*50) if __name__ __main__: asyncio.run(generate_stream())运行这个脚本python benchmark_vllm.py如何解读结果生成吞吐量 (Token/s)这是衡量推理速度的核心指标即每秒能生成多少个 Token。300 Token/s就是一个非常出色的成绩。这个值受 Prompt 长度、生成长度、模型大小、量化精度、GPU 算力等多方面影响。首个 Token 延迟 (TTFT)从发送请求到收到第一个 Token 的时间。这反映了模型处理 Prompt 并开始生成的速度对于交互式应用体验很重要。总耗时处理整个请求Prompt Completion的总时间。要获得更稳定、可信的性能数据建议进行多次测试取平均值。使用固定的、有代表性的 Prompt 和生成长度。在测试期间确保系统没有其他繁重任务干扰。4.3 进阶测试使用 vLLM 的基准测试工具vLLM 项目自带了一个更专业的基准测试工具benchmark_throughput.py。它可以模拟多个客户端并发请求更能反映服务器的实际吞吐能力。首先找到 vLLM 安装目录下的这个脚本或者从 GitHub 仓库下载。# 假设 vllm 安装在当前 Python 环境 find $(python -c import site; print(site.getsitepackages()[0])) -name benchmark_throughput.py 2/dev/null找到路径后运行类似以下命令python /path/to/benchmark_throughput.py \ --backend vllm \ --model ./Qwen2.5-32B-AWQ \ --input-len 512 \ # 输入提示词的长度 --output-len 128 \ # 要求生成的 Token 长度 --num-prompts 100 \ # 总共发送的请求数 --request-rate 1000 \ # 模拟的请求速率 (无穷大表示尽快发送) --dtype bf16这个工具会输出更详细的统计数据包括吞吐量、延迟分布等是进行性能对比和调优的利器。5. 性能优化深度调优指南要达到并超越“300 Token/s”的成绩除了硬件和基础部署深入的调优至关重要。5.1 量化格式选择AWQ vs GPTQAWQ (Activation-aware Weight Quantization)在量化权重时会考虑激活值的分布保护对模型输出影响最大的权重。通常能获得更好的精度保持并且与 vLLM 的 PagedAttention 兼容性极佳是当前 vLLM 部署的首选量化格式。GPTQ一种后训练量化方法需要对校准数据集进行一步压缩。在某些模型和任务上可能表现稍好但早期与 vLLM 的集成可能不如 AWQ 顺畅现在已大大改善。建议优先尝试模型官方发布的或社区评价较高的AWQ版本。你可以在 Hugging Face 上搜索模型名-AWQ。5.2 vLLM 关键参数调优--gpu-memory-utilization这是最重要的参数之一。提高它可以增加用于 KV Cache 的显存从而允许更长的上下文或更高的并发但设置过高如0.99可能导致内存不足错误。建议从 0.85 开始逐步上调直到系统稳定运行的临界值。--max-model-len根据你的应用场景设置。如果你只需要处理短文本将其设小如2048可以节省大量显存这些显存可以用于服务更多并发请求提升总体吞吐量。如果需要长上下文则必须设大但会牺牲并发能力。--block-sizePagedAttention 中块的大小。默认值16适用于大多数场景。对于非常长的序列可以适当增大如32可能会减少块表的管理开销但也会增加内部碎片。通常不需要调整。--enforce-eager如前所述这是一个“保底”选项。在 ROCm/AMD 环境下如果遇到类似RuntimeError: No kernel found的错误尝试添加--enforce-eager是首要的排查步骤。但这会显著降低性能。--dtype对于非量化模型使用bf16。对于 AWQ/GPTQ 模型本质是INT4vLLM 会自动处理无需指定。5.3 系统与驱动层优化ROCm 版本始终尝试使用最新的稳定版 ROCm。新版本通常会包含性能优化和更好的硬件支持。电源管理模式确保 GPU 运行在最高性能模式。对于 AMD 显卡可以使用rocm-smi命令设置。sudo rocm-smi --setperflevel highCPU 与内存确保 CPU 不是瓶颈。大模型的 Prompt 处理前向计算是 CPU 密集型的。同时充足的系统内存RAM对于模型加载和数据处理是必要的。PCIe 带宽确保显卡安装在主板支持的最高速 PCIe 插槽上如 PCIe 4.0 x16。5.4 并发请求处理vLLM 的强大之处在于其高并发吞吐能力。你的测试脚本是单线程的。在实际应用中可以使用异步客户端或多进程/多线程来模拟并发请求。benchmark_throughput.py工具就是做这个的。通过增加并发客户端数量观察吞吐量的变化可以找到当前硬件配置下的最优并发点。6. 常见问题与排查思路 (FAQ)在部署过程中你可能会遇到以下问题问题现象可能原因排查与解决思路启动失败No kernel found或HIP Error1. vLLM 的某些定制内核与当前 ROCm 版本不兼容。2. 模型量化格式与 vLLM 版本不匹配。1.首先尝试在启动命令中添加--enforce-eager参数。这能绕过自定义内核使用 PyTorch 原生算子。2. 检查 vLLM 和 ROCm 的版本兼容性考虑升级或降级。3. 确认模型是 vLLM 官方支持的格式如 AWQ, GPTQ。推理速度远低于预期1. 使用了--enforce-eager模式。2. 模型未量化以 FP16/BF16 运行显存不足导致频繁换页。3. CPU 成为瓶颈处理长Prompt。4. 电源模式未设置为高性能。1. 确保未使用--enforce-eager除非必须。2.必须使用量化模型如 AWQ-INT4才能在 16GB 显存下运行 26B 模型。3. 监控 CPU 使用率。考虑使用更快的 CPU 或优化 Prompt 长度。4. 运行sudo rocm-smi --setperflevel high。显存不足 (OOM)1.--gpu-memory-utilization设置过高。2.--max-model-len设置过大。3. 并发请求过多。1. 降低--gpu-memory-utilization如从 0.9 降到 0.85。2. 根据实际需求减小--max-model-len。3. 减少并发请求数或使用 vLLM 的速率限制功能。生成的文本乱码或不符合预期1. 模型文件损坏或下载不完整。2. 量化模型精度损失过大。1. 重新下载模型文件检查文件完整性。2. 尝试不同的量化模型如换一个提供者发布的 AWQ 版本或尝试更高精度的量化如 AWQ-INT8如果显存放得下。服务响应慢TTFT 很高1. Prompt 非常长。2. 首次请求需要编译计算图在非--enforce-eager模式下。1. 长 Prompt 的预处理是计算密集型的TTFT 高是正常现象。考虑对长 Prompt 进行缓存或摘要。2. 首次请求后的请求速度会变快这是正常的热身过程。7. 最佳实践与工程建议将高性能推理方案用于实际项目时需要考虑更多工程化因素。模型版本管理使用类似git-lfs或专门的模型存储服务来管理不同版本的量化模型。在config.json旁创建一个README.md记录量化方法、校准数据集和预期性能。服务化与监控不要仅仅在命令行运行。使用Docker容器化你的 vLLM 服务便于部署和扩展。在容器内集成监控通过 Prometheus 暴露指标vLLM 支持监控 GPU 使用率、吞吐量、延迟和错误率。# 简化的 Dockerfile 示例 FROM rocm/dev-ubuntu-22.04:6.0 # ... 安装步骤 ... CMD [python, -m, vllm.entrypoints.openai.api_server, --model, /app/model, --port, 8000]配置分离将 vLLM 的启动参数如端口、模型路径、最大长度通过环境变量或配置文件管理而不是写死在启动脚本中。安全与认证生产环境务必设置--api-key。考虑在前端使用 Nginx 等反向代理添加更复杂的认证、限流和 SSL 加密。多模型部署vLLM 支持多模型同时部署。你可以启动多个 API Server 进程监听不同端口或者使用更高级的模型调度器。持续性能测试建立自动化性能测试流水线。在每次模型更新、驱动更新或 vLLM 版本升级后运行固定的基准测试确保性能没有回退。备选方案vLLM 不是唯一选择。了解其他推理引擎如TGI(Text Generation Inference),LightLLM等。它们各有优劣在不同硬件或模型上表现可能不同。保持技术选型的开放性。AMD Arc Pro B70 与 vLLM 的组合为我们提供了一个极具性价比的大模型本地推理方案。它证明了通过极致的软件优化vLLM的PagedAttention和恰当的硬件选择支持BF16的大显存专业卡完全可以在有限的预算内获得惊人的推理性能。从环境搭建、模型量化、服务部署到深度调优整个过程涉及了现代AI工程化的多个关键环节。希望这篇详细的指南能帮助你成功复现这一性能表现并将其应用到你的AI项目中去。下一步你可以尝试部署更大的模型如72B探索多卡并行或者将其集成到你的Web应用、智能助手等实际产品中感受本地大模型带来的强大能力与数据隐私保障。 
长河君 · 2026/8/24 13:08:35 · 阅读 1.2k AMD Arc Pro B70 + vLLM：单卡实现26B大模型300+ Token/s推理实战
最近在折腾本地大模型推理发现一个让人眼前一亮的组合AMD Arc Pro B70 专业显卡 vLLM 推理引擎居然能让一个 26B 参数的大模型在单卡上跑出超过 300 Token/s 的推理速度。这个成绩对于追求高性价比、希望用消费级或入门专业卡跑大模型的开发者来说无疑是个重磅消息。本文将为你完整拆解这套方案的原理、部署步骤、性能调优技巧以及背后的技术细节无论你是想低成本搭建AI应用还是单纯对高性能推理优化感兴趣都能从中获得一套可直接复现的实战方案。1. 背景与核心概念为什么是 Arc Pro B70 和 vLLM在深入实操之前我们有必要理解几个关键概念这能帮你明白为什么这个组合能带来如此显著的性能提升。1.1 大模型本地推理的瓶颈与机遇随着 ChatGPT 等应用的普及越来越多的开发者和企业希望将大语言模型LLM部署在本地或私有环境中。然而大模型动辄数十亿甚至上百亿的参数规模对计算硬件尤其是 GPU 的显存和算力提出了极高要求。传统的部署方式往往面临两大难题显存瓶颈模型参数、KV Cache用于加速自回归生成会占用大量显存导致许多大模型无法在单张消费级显卡上运行。计算效率低下简单的模型加载和逐 Token 生成无法充分利用 GPU 的并行计算能力导致推理速度慢Token 生成速率Token/s低。1.2 vLLM高性能推理的“引擎”vLLM是一个专为大模型推理设计的高吞吐量、内存高效的服务引擎。它的核心创新在于PagedAttention算法灵感来源于操作系统的虚拟内存和分页机制。传统Attention为每个请求的序列预先分配一块连续的显存来存储 KV Cache。当处理变长序列或大量并发请求时会产生严重的显存碎片利用率低下。PagedAttention将 KV Cache 分割成固定大小的“块”blocks像操作系统管理内存页一样管理它们。不同请求的块可以非连续地存储在显存中并通过一个“块表”来记录逻辑关系。这带来了两大好处近乎零显存碎片显著提高了显存利用率可以在同一块 GPU 上运行更大的模型或服务更多的并发请求。高效共享对于提示Prompt相同或部分相同的请求其对应的 KV Cache 块可以在不同请求间共享避免了重复计算极大提升了吞吐量。简单说vLLM 让 GPU 显存的使用变得非常“经济”从而为在有限显存下运行大模型并保持高吞吐量提供了可能。1.3 AMD Arc Pro B70被低估的“性价比之选”AMD Arc Pro B70 是一款面向工作站的专业显卡。在此次大模型推理场景中它展现出惊人性价比的关键在于大显存通常配备 16GB GDDR6 显存。对于量化后的 26B 参数模型这个容量是足够的。对 BF16 数据类型的硬件支持BF16Brain Floating Point 16是一种半精度浮点数格式在保持足够数值范围的同时相比 FP32 减少了一半的存储和带宽占用。Arc 显卡对 BF16 有良好的硬件加速支持。软件生态改善随着 ROCmAMD 的 GPU 计算平台对 PyTorch 等框架支持的持续完善以及 vLLM 对 AMD GPU 后端通过 ROCm的集成使得在这张卡上运行优化后的推理引擎成为现实。核心逻辑链条vLLM 通过 PagedAttention 极致优化显存使用 - 使得 26B 模型能“塞进”B70的16G显存 - B70的硬件BF16支持与vLLM的高效计算调度结合 - 最终实现单卡高Token/s的推理性能。2. 环境准备与版本说明要复现这个高性能推理环境我们需要搭建一个支持 ROCm 的软件栈。以下环境是经过验证可用的配置。操作系统: Ubuntu 22.04 LTS 或 20.04 LTS。这是 ROCm 官方支持较好的系统版本。GPU: AMD Arc Pro B70 (或其他支持 ROCm 的 AMD GPU如 MI系列)。Python: 3.8 - 3.10。建议使用 3.9 或 3.10。关键软件版本ROCm: 5.7 或 6.0 版本。本文示例以 ROCm 6.0 为例。PyTorch: 必须安装支持 ROCm 的版本。vLLM: 0.3.3 或更高版本需支持 ROCm 后端。下面开始一步步搭建环境。2.1 安装 ROCm 6.0首先添加 ROCm 的官方仓库并安装核心组件。# 1. 添加 ROCm 仓库的 GPG 密钥 wget https://repo.radeon.com/rocm/rocm.gpg.key -O - | sudo gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/rocm.gpg /dev/null # 2. 添加 ROCm 6.0 仓库 echo deb [archamd64] https://repo.radeon.com/rocm/apt/6.0 jammy main | sudo tee /etc/apt/sources.list.d/rocm.list # 3. 更新软件包列表并安装 ROCm sudo apt update sudo apt install rocm-hip-sdk rocm-dev安装完成后将当前用户添加到render和video组并重启系统。sudo usermod -a -G render,video $USER echo export PATH$PATH:/opt/rocm/bin ~/.bashrc echo export LD_LIBRARY_PATH$LD_LIBRARY_PATH:/opt/rocm/lib ~/.bashrc source ~/.bashrc # 重启系统 sudo reboot重启后运行rocm-smi命令检查 GPU 是否被正确识别。rocm-smi你应该能看到 Arc Pro B70 显卡的信息。2.2 安装 PyTorch with ROCm前往 PyTorch 官网 选择对应的 ROCm 版本。例如对于 ROCm 6.0 和 Python 3.10安装命令如下pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.0安装后在 Python 中验证 PyTorch 是否能识别 AMD GPUimport torch print(fPyTorch version: {torch.__version__}) print(fIs ROCm available? {torch.cuda.is_available()}) # 注意在ROCm上torch.cuda.is_available() 也返回 True print(fDevice name: {torch.cuda.get_device_name(0)})2.3 安装 vLLM 及其 ROCm 依赖vLLM 的主干版本已支持 ROCm 后端。我们直接通过 pip 安装并确保安装正确的依赖。# 安装 vLLM pip install vllm # vLLM 的 ROCm 支持需要一些额外的内核依赖通常会在安装时自动处理。 # 为了确保无误可以安装 ninja用于编译 sudo apt install ninja-build安装完成后验证 vllm 是否成功安装python -c import vllm; print(vllm.__version__)3. 模型准备与量化让 26B 模型“住进”16G显存26B 参数的模型如果以 FP16半精度加载大约需要 52GB 显存每个参数2字节这远超 B70 的 16GB。因此量化Quantization是必不可少的一步。量化通过降低模型权重的数值精度来减少显存占用和计算量同时力求保持模型精度损失最小。目前最流行的量化格式是AWQ(Activation-aware Weight Quantization) 和GPTQ。vLLM 对这两种格式都有良好的支持。我们将以Qwen2.5-7B的 AWQ 量化版为例进行演示因为26B模型的AWQ/GPTQ版本更容易获取和验证原理与26B一致。你可以在 Hugging Face 模型库搜索类似Qwen2.5-32B-AWQ的模型。步骤找到并下载量化模型访问 Hugging Face 官网 (huggingface.co)。在搜索框输入模型名称例如 “Qwen2.5-32B-AWQ” 或 “Llama-3.1-8B-AWQ”。进入模型页面你会看到模型文件和配置文件。我们需要的是包含.safetensors权重文件和config.json的整个仓库。我们可以使用git-lfs来下载大模型文件或者使用huggingface-hub库的 Python 接口。这里使用git方式# 安装 git-lfs sudo apt install git-lfs git lfs install # 克隆模型仓库以 Qwen2.5-7B-Instruct-AWQ 为例实际请替换为你的目标26B模型 git clone https://huggingface.co/Qwen/Qwen2.5-7B-Instruct-AWQ这会下载模型到当前目录下的Qwen2.5-7B-Instruct-AWQ文件夹。请确保你的磁盘有足够空间一个7B的AWQ模型约4-5GB26B的会更大。4. 使用 vLLM 部署模型并测试性能环境与模型就绪后就是最激动人心的部署与性能测试环节。4.1 启动 vLLM 推理服务器vLLM 提供了一个高效的 OpenAI 兼容的 API 服务器。我们通过命令行启动它。# 基本启动命令 python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ # 替换为你的模型本地路径例如 ./Qwen2.5-7B-Instruct-AWQ --served-model-name qwen-awq \ # 服务标识名称 --tensor-parallel-size 1 \ # 张量并行大小单卡设为1 --gpu-memory-utilization 0.9 \ # GPU显存利用率目标0.9表示使用90%的显存 --max-model-len 8192 \ # 模型支持的最大上下文长度 --api-key token-abc123 \ # 可选的API密钥用于简单认证 --port 8000 # 服务端口关键参数详解--model: 模型本地路径必须指向包含config.json和.safetensors文件的文件夹。--tensor-parallel-size: 模型并行度。单卡推理设为1。如果你有多张卡可以设置为卡数以实现模型层在多个GPU上的切分。--gpu-memory-utilization: 非常重要的参数。它告诉 vLLM 可以计划使用多少比例的 GPU 显存。设置为 0.990%通常是一个安全且高效的选择为系统和其他进程留出空间。--max-model-len: 定义模型能处理的最大序列长度Prompt Completion。需要根据模型本身的能力和你的显存大小设置。设置过大可能导致OOM内存溢出。--dtype bf16: 指定加载模型的计算数据类型。对于支持 BF16 的 AMD 显卡使用bf16通常能获得最佳性能。如果模型已经是 AWQ/GPTQ 量化格式通常是 int4则无需指定vLLM 会自动识别。--enforce-eager: 这是一个调试或兼容性参数。默认为FalsevLLM 会使用自定义的高效内核。如果遇到某些算子不支持或运行错误可以尝试设置为True来强制使用 PyTorch 的 eager 模式但性能会下降。在 ROCm 环境下如果遇到内核不兼容的报错可以尝试启用此选项。对于我们的 Arc Pro B70 26B AWQ 模型场景一个更具体的启动命令可能如下python -m vllm.entrypoints.openai.api_server \ --model ./Qwen2.5-32B-AWQ \ --served-model-name qwen32b-awq \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.92 \ --max-model-len 4096 \ --dtype bf16 \ --port 8000启动成功后终端会输出日志显示模型加载进度最后提示服务已在http://localhost:8000启动。4.2 性能测试测量 Token/s服务启动后我们需要一个工具来测试推理速度。我们可以编写一个简单的 Python 测试脚本使用openai库兼容 vLLM 的 API来发送请求并计算 Token 生成速度。创建一个名为benchmark_vllm.py的文件import time import asyncio from openai import OpenAI # 初始化客户端指向本地 vLLM 服务器 client OpenAI( base_urlhttp://localhost:8000/v1, # vLLM OpenAI API 的端点 api_keytoken-abc123 # 与启动命令中的 --api-key 一致 ) async def generate_stream(): start_time time.time() first_token_time None completion_tokens 0 # 发起流式请求 stream client.chat.completions.create( modelqwen32b-awq, # 与 --served-model-name 一致 messages[{role: user, content: 请用中文介绍一下人工智能的发展历史要求500字左右。}], max_tokens512, # 限制生成的长度便于测试 temperature0.7, streamTrue # 启用流式输出以便计算首个 Token 延迟 (Time to First Token, TTFT) ) print(开始生成...) for chunk in stream: if chunk.choices[0].delta.content is not None: completion_tokens 1 if first_token_time is None: first_token_time time.time() ttft first_token_time - start_time print(f首个 Token 延迟 (TTFT): {ttft:.3f} 秒) # 可选实时打印生成内容 # print(chunk.choices[0].delta.content, end, flushTrue) end_time time.time() total_time end_time - start_time throughput completion_tokens / total_time print(f\n{*50}) print(f测试完成!) print(f总生成 Token 数: {completion_tokens}) print(f总耗时: {total_time:.3f} 秒) print(f生成吞吐量: {throughput:.2f} Token/s) print(f首个 Token 延迟: {ttft:.3f} 秒) print(*50) if __name__ __main__: asyncio.run(generate_stream())运行这个脚本python benchmark_vllm.py如何解读结果生成吞吐量 (Token/s)这是衡量推理速度的核心指标即每秒能生成多少个 Token。300 Token/s就是一个非常出色的成绩。这个值受 Prompt 长度、生成长度、模型大小、量化精度、GPU 算力等多方面影响。首个 Token 延迟 (TTFT)从发送请求到收到第一个 Token 的时间。这反映了模型处理 Prompt 并开始生成的速度对于交互式应用体验很重要。总耗时处理整个请求Prompt Completion的总时间。要获得更稳定、可信的性能数据建议进行多次测试取平均值。使用固定的、有代表性的 Prompt 和生成长度。在测试期间确保系统没有其他繁重任务干扰。4.3 进阶测试使用 vLLM 的基准测试工具vLLM 项目自带了一个更专业的基准测试工具benchmark_throughput.py。它可以模拟多个客户端并发请求更能反映服务器的实际吞吐能力。首先找到 vLLM 安装目录下的这个脚本或者从 GitHub 仓库下载。# 假设 vllm 安装在当前 Python 环境 find $(python -c import site; print(site.getsitepackages()[0])) -name benchmark_throughput.py 2/dev/null找到路径后运行类似以下命令python /path/to/benchmark_throughput.py \ --backend vllm \ --model ./Qwen2.5-32B-AWQ \ --input-len 512 \ # 输入提示词的长度 --output-len 128 \ # 要求生成的 Token 长度 --num-prompts 100 \ # 总共发送的请求数 --request-rate 1000 \ # 模拟的请求速率 (无穷大表示尽快发送) --dtype bf16这个工具会输出更详细的统计数据包括吞吐量、延迟分布等是进行性能对比和调优的利器。5. 性能优化深度调优指南要达到并超越“300 Token/s”的成绩除了硬件和基础部署深入的调优至关重要。5.1 量化格式选择AWQ vs GPTQAWQ (Activation-aware Weight Quantization)在量化权重时会考虑激活值的分布保护对模型输出影响最大的权重。通常能获得更好的精度保持并且与 vLLM 的 PagedAttention 兼容性极佳是当前 vLLM 部署的首选量化格式。GPTQ一种后训练量化方法需要对校准数据集进行一步压缩。在某些模型和任务上可能表现稍好但早期与 vLLM 的集成可能不如 AWQ 顺畅现在已大大改善。建议优先尝试模型官方发布的或社区评价较高的AWQ版本。你可以在 Hugging Face 上搜索模型名-AWQ。5.2 vLLM 关键参数调优--gpu-memory-utilization这是最重要的参数之一。提高它可以增加用于 KV Cache 的显存从而允许更长的上下文或更高的并发但设置过高如0.99可能导致内存不足错误。建议从 0.85 开始逐步上调直到系统稳定运行的临界值。--max-model-len根据你的应用场景设置。如果你只需要处理短文本将其设小如2048可以节省大量显存这些显存可以用于服务更多并发请求提升总体吞吐量。如果需要长上下文则必须设大但会牺牲并发能力。--block-sizePagedAttention 中块的大小。默认值16适用于大多数场景。对于非常长的序列可以适当增大如32可能会减少块表的管理开销但也会增加内部碎片。通常不需要调整。--enforce-eager如前所述这是一个“保底”选项。在 ROCm/AMD 环境下如果遇到类似RuntimeError: No kernel found的错误尝试添加--enforce-eager是首要的排查步骤。但这会显著降低性能。--dtype对于非量化模型使用bf16。对于 AWQ/GPTQ 模型本质是INT4vLLM 会自动处理无需指定。5.3 系统与驱动层优化ROCm 版本始终尝试使用最新的稳定版 ROCm。新版本通常会包含性能优化和更好的硬件支持。电源管理模式确保 GPU 运行在最高性能模式。对于 AMD 显卡可以使用rocm-smi命令设置。sudo rocm-smi --setperflevel highCPU 与内存确保 CPU 不是瓶颈。大模型的 Prompt 处理前向计算是 CPU 密集型的。同时充足的系统内存RAM对于模型加载和数据处理是必要的。PCIe 带宽确保显卡安装在主板支持的最高速 PCIe 插槽上如 PCIe 4.0 x16。5.4 并发请求处理vLLM 的强大之处在于其高并发吞吐能力。你的测试脚本是单线程的。在实际应用中可以使用异步客户端或多进程/多线程来模拟并发请求。benchmark_throughput.py工具就是做这个的。通过增加并发客户端数量观察吞吐量的变化可以找到当前硬件配置下的最优并发点。6. 常见问题与排查思路 (FAQ)在部署过程中你可能会遇到以下问题问题现象可能原因排查与解决思路启动失败No kernel found或HIP Error1. vLLM 的某些定制内核与当前 ROCm 版本不兼容。2. 模型量化格式与 vLLM 版本不匹配。1.首先尝试在启动命令中添加--enforce-eager参数。这能绕过自定义内核使用 PyTorch 原生算子。2. 检查 vLLM 和 ROCm 的版本兼容性考虑升级或降级。3. 确认模型是 vLLM 官方支持的格式如 AWQ, GPTQ。推理速度远低于预期1. 使用了--enforce-eager模式。2. 模型未量化以 FP16/BF16 运行显存不足导致频繁换页。3. CPU 成为瓶颈处理长Prompt。4. 电源模式未设置为高性能。1. 确保未使用--enforce-eager除非必须。2.必须使用量化模型如 AWQ-INT4才能在 16GB 显存下运行 26B 模型。3. 监控 CPU 使用率。考虑使用更快的 CPU 或优化 Prompt 长度。4. 运行sudo rocm-smi --setperflevel high。显存不足 (OOM)1.--gpu-memory-utilization设置过高。2.--max-model-len设置过大。3. 并发请求过多。1. 降低--gpu-memory-utilization如从 0.9 降到 0.85。2. 根据实际需求减小--max-model-len。3. 减少并发请求数或使用 vLLM 的速率限制功能。生成的文本乱码或不符合预期1. 模型文件损坏或下载不完整。2. 量化模型精度损失过大。1. 重新下载模型文件检查文件完整性。2. 尝试不同的量化模型如换一个提供者发布的 AWQ 版本或尝试更高精度的量化如 AWQ-INT8如果显存放得下。服务响应慢TTFT 很高1. Prompt 非常长。2. 首次请求需要编译计算图在非--enforce-eager模式下。1. 长 Prompt 的预处理是计算密集型的TTFT 高是正常现象。考虑对长 Prompt 进行缓存或摘要。2. 首次请求后的请求速度会变快这是正常的热身过程。7. 最佳实践与工程建议将高性能推理方案用于实际项目时需要考虑更多工程化因素。模型版本管理使用类似git-lfs或专门的模型存储服务来管理不同版本的量化模型。在config.json旁创建一个README.md记录量化方法、校准数据集和预期性能。服务化与监控不要仅仅在命令行运行。使用Docker容器化你的 vLLM 服务便于部署和扩展。在容器内集成监控通过 Prometheus 暴露指标vLLM 支持监控 GPU 使用率、吞吐量、延迟和错误率。# 简化的 Dockerfile 示例 FROM rocm/dev-ubuntu-22.04:6.0 # ... 安装步骤 ... CMD [python, -m, vllm.entrypoints.openai.api_server, --model, /app/model, --port, 8000]配置分离将 vLLM 的启动参数如端口、模型路径、最大长度通过环境变量或配置文件管理而不是写死在启动脚本中。安全与认证生产环境务必设置--api-key。考虑在前端使用 Nginx 等反向代理添加更复杂的认证、限流和 SSL 加密。多模型部署vLLM 支持多模型同时部署。你可以启动多个 API Server 进程监听不同端口或者使用更高级的模型调度器。持续性能测试建立自动化性能测试流水线。在每次模型更新、驱动更新或 vLLM 版本升级后运行固定的基准测试确保性能没有回退。备选方案vLLM 不是唯一选择。了解其他推理引擎如TGI(Text Generation Inference),LightLLM等。它们各有优劣在不同硬件或模型上表现可能不同。保持技术选型的开放性。AMD Arc Pro B70 与 vLLM 的组合为我们提供了一个极具性价比的大模型本地推理方案。它证明了通过极致的软件优化vLLM的PagedAttention和恰当的硬件选择支持BF16的大显存专业卡完全可以在有限的预算内获得惊人的推理性能。从环境搭建、模型量化、服务部署到深度调优整个过程涉及了现代AI工程化的多个关键环节。希望这篇详细的指南能帮助你成功复现这一性能表现并将其应用到你的AI项目中去。下一步你可以尝试部署更大的模型如72B探索多卡并行或者将其集成到你的Web应用、智能助手等实际产品中感受本地大模型带来的强大能力与数据隐私保障。