AMD Hello-ROCm 环境配置（一）

10WTW01

773人浏览 · 2026-06-12 18:12:53

10WTW01 · 2026-06-12 18:12:53 发布

#下载的时候不用着急，可能网络速度比较慢所以要等待的时间比较长（我体验下来基本上挺快的，不像自己电脑用校园网下载很不稳定，还会出现因网络波动导致下载失败的情况）

云环境注册与启动

注册登录AMD AI 开发者计划后，在Radeon Cloud启动Hello ROCm Bate的云环境：

打开云环境，选择Terminal方式，输入amd-smi查看GPU：

输入一段Python程序查看GPU能否使用：

python -c "import torch; print('PyTorch:', torch.__version__); print('ROCm available:', torch.cuda.is_available()); print('Device:', torch.cuda.get_device_name(0) if torch.cuda.is_available() else 'N/A')"

正常输出：

ROCm available: True

Device: AMD Radeon Graphics

下载 Gemma4 模型

切换国内镜像源：

pip config set global.index-url Simple Index

安装魔搭 ModelScope用于下载 Gemma4 模型

pip install modelscope

modelscope download --model google/gemma-4-E4B-it --cache_dir "./models"

ls -lh ./models/google/gemma-4-E4B-it/

此时gemma-4-E4B-it下载成功

启动 vLLM 服务

先卸载torchvision再连同vllm一起安装：

uv pip uninstall torchvision

uv pip install vllm torchvision \

--no-cache \

--index-url https://mirrors.aliyun.com/pypi/simple/ \

--extra-index-url https://wheels.vllm.ai/rocm/ \

-U

下载完就可以启动

vllm serve ./models/google/gemma-4-E4B-it/ --served-model-name gemma-4-E4B-it

字段 / 术语	含义	示例值（来自日志）
model / model_tag	模型文件或 Hugging Face 模型路径	./models/google/gemma-4-E4B-it/
dtype	模型推理使用的浮点数据类型	torch.bfloat16
max_seq_len	模型支持的最大上下文长度（token 数）	131072
tensor_parallel_size	张量并行使用的 GPU 数量	1
pipeline_parallel_size	流水线并行级数	1
data_parallel_size	数据并行副本数	1
enable_prefix_caching	是否开启前缀缓存，复用相同前缀的 KV 缓存	True
enable_chunked_prefill	是否将长 prompt 拆分为多个块进行预填充	True
trust_remote_code	是否信任 Hugging Face 仓库中的自定义模型代码	False
quantization	模型量化方法（None 表示未量化）	None
seed	随机种子	0
kv_cache_dtype	KV 缓存的数据类型，auto 为自动选择	auto
compilation_config.mode	编译模式，3 表示使用 vLLM 的 torch.compile 优化	3（VLLM_COMPILE）
Attention backend	注意力计算后端，此处因模型异构头维度强制使用 Triton	TRITON_ATTN
Resolved architecture	自动识别的模型架构类	Gemma4ForConditionalGeneration
Asynchronous scheduling	是否启用异步调度	enabled
Available KV cache memory	GPU 显存中可分配给 KV 缓存的容量	27.25 GiB
GPU KV cache size	KV 缓存最多能容纳的 token 总数	1,701,816 tokens
Maximum concurrency	在最大上下文长度下的理论最大并发请求数	12.98x
Model loading memory	加载模型权重占用的 GPU 显存	15.16 GiB
Model loading time	加载权重耗时	7.96 seconds
torch.compile time	torch.compile 总耗时（含图捕获前的编译）	54.60 s
Compiling a graph for compile range	为指定 token 范围编译计算图，并缓存该图	(1, 2048) 耗时 44.75 s
Graph capturing time	捕获 CUDA 图所花费的时间	19 secs
Graph capturing memory	捕获 CUDA 图额外占用的 GPU 显存	3.28 GiB
Avg prompt throughput	平均 prompt 处理吞吐量	7.3 tokens/s
Avg generation throughput	平均 token 生成吞吐量	24.3 tokens/s
Prefix cache hit rate	前缀缓存命中率	79.8%
Triton kernel JIT compilation	推理时发生 Triton 内核即时编译，导致延迟抖动（警告）	_compute_slot_mapping_kernel, kernel_unified_attention
Generation config override	模型自带的 generation_config.json 覆盖了默认采样参数	temperature=1.0, top_k=64, top_p=0.95
Multi-modal warmup failed	多模态预热失败（通常因缺少多模态输入数据）	警告信息
Auto-prefetch disabled	由于文件系统为 EXT4，非网络文件系统，自动预取被禁用	提示信息
APIServer / EngineCore	组件名：API 服务器进程 / 引擎核心进程	APIServer pid=567, EngineCore pid=1103
world_size=1 rank=0 local_rank=0	分布式训练/推理的总进程数、当前进程编号及本地 GPU 编号。这里是单卡，所以都是 0。	world_size=1 rank=0 local_rank=0
distributed_init_method=tcp://...	分布式初始化方式，通过 TCP 地址同步进程。	tcp://10.232.23.51:52651
backend=nccl	分布式通信后端，NCCL 用于 GPU 间通信。	nccl
DP rank, PP rank, PCP rank, TP rank, EP rank, EPLB rank	多维并行策略中各个维度的编号：数据并行 (DP)、流水线并行 (PP)、流水线块并行 (PCP)、张量并行 (TP)、专家并行 (EP)、专家负载均衡并行 (EPLB)。均为 0 表示未启用对应并行。	DP rank 0, PP rank 0, PCP rank 0, TP rank 0, EP rank N/A, EPLB rank N/A
Starting to load model	开始从磁盘加载模型权重到 GPU。	./models/google/gemma-4-E4B-it/
Asynchronous scheduling is enabled	启用异步调度，允许 CPU 调度与 GPU 计算重叠执行。	Asynchronous scheduling is enabled.
Final IR op priority	中间表示层的算子优先级配置，指定哪些算子优先使用原生实现。这里 rms_norm 和 fused_add_rms_norm 使用 native 内核。	IrOpPriorityConfig(rms_norm=['native'], fused_add_rms_norm=['native'])
Using TRITON_ATTN backend	注意力计算后端选用 Triton，因为模型存在异构头维度，强制使用该后端以避免混合后端的数值差异。	Using TRITON_ATTN backend (selected via --attention-backend).
sparse_attn_indexer	自定义稀疏注意力索引算子。模型中没有该算子，强制启用它没有效果。	Op 'sparse_attn_indexer' not present in model, enabling with '+sparse_attn_indexer' has no effect
Filesystem type for checkpoints: EXT4	存放模型检查点的文件系统类型为 EXT4（本地磁盘）。	EXT4
Checkpoint size: 14.89 GiB	模型权重文件的总大小。	14.89 GiB
Available RAM: 473.50 GiB	系统可用内存大小。	473.50 GiB
Loading safetensors checkpoint shards	加载 safetensors 格式的权重分片，这里只有 1 个分片。	1/1 [00:06<00:00, 6.21s/it]
Loading weights took 7.17 seconds	加载模型权重到内存/显存实际耗时。	7.17 seconds
Model loading took 15.16 GiB memory and 7.959798 seconds	模型加载完成后占用的 GPU 显存以及总加载时间。	15.16 GiB memory and 7.959798 seconds
Encoder cache will be initialized with a budget of 2496 tokens	为多模态编码器缓存预分配 2496 个 token 的空间，并计划以 1 个最大特征尺寸的视频进行性能分析。	budget of 2496 tokens, and profiled with 1 video items of the maximum feature size.
Using cache directory: ... for vLLM's torch.compile	torch.compile 编译缓存存放目录。	/root/.cache/vllm/torch_compile_cache/...
Dynamo bytecode transform time: 7.93 s	TorchDynamo 将模型字节码转换为 FX 图所花费的时间。	7.93 s
Cache the graph of compile range (1, 2048) for later use	对 token 范围 (1, 2048) 编译好的计算图进行缓存，后续复用。	(1, 2048)
Compiling a graph for compile range (1, 2048) takes 44.75 s	具体编译该范围计算图耗时。	44.75 s
saved AOT compiled function to ...	Ahead-Of-Time 编译生成的函数被保存到磁盘缓存路径。	/root/.cache/vllm/torch_compile_cache/torch_aot_compile/.../model
torch.compile took 54.60 s in total	从开始编译到结束总共花费 54.60 秒。	54.60 s
Initial profiling/warmup run took 0.83 s	预热运行（profiling 阶段）耗时。	0.83 s
Available KV cache memory: 27.25 GiB	可用于存储 KV 缓存的 GPU 显存大小。	27.25 GiB
GPU KV cache size: 1,701,816 tokens	KV 缓存最多可容纳的 token 总数。	1,701,816 tokens
Maximum concurrency for 131,072 tokens per request: 12.98x	当每个请求占用最大上下文长度（131072 tokens）时，理论上最多可同时处理约 12.98 个请求。	12.98x
Kernel JIT monitor activated	内核即时编译监控已启动，推理过程中发生的 Triton JIT 编译将以警告形式记录。	Kernel JIT monitor activated — Triton JIT compilations during inference will be logged as warnings.
Supported tasks: ['generate']	该模型 API 支持的任务类型为文本生成。	['generate']
Default vLLM sampling parameters have been overridden...	模型自带的 generation_config.json 覆盖了 vLLM 默认采样参数（温度 1.0, top_k 64, top_p 0.95）。	{'temperature': 1.0, 'top_k': 64, 'top_p': 0.95}
Detected the chat template content format to be 'openai'	检测到对话模板内容格式为 OpenAI 格式。	'openai'
Starting vLLM server on http://0.0.0.0:8000	vLLM API 服务启动，监听所有网络接口的 8000 端口。	http://0.0.0.0:8000
Route: /v1/chat/completions, Methods: POST	可用的 API 路由及其 HTTP 方法，例如 OpenAI 兼容的聊天补全接口。	列表中的多个路由，如 /v1/chat/completions

启动所需时间比较长，我是06-11 12:30:56 启动到06-11 12:33:32才加载成功

这时候不要关闭terminal窗口，因为此时vllm程序相当于一个后端程序在跑了，为我们提供模型服务。

启动成功后，我们不妨用amd-smi看一下用vllm运行16GB的gemma4要占用多少资源

可以看到GPU 目前计算负载很低（GFX-Uti即图形/计算核心利用率 0%、功耗仅 8W），而已用显存 / 总显存达到了47272/49136 MB，都被PID=812129进程就是我们运行的AI推理任务所占用（换算下就知道了47272 MB = 46.1640625 GB约等于46.1GB）。也就是为什么后面要结束推理进程释放显存空间用于微调。

#Mem-Uti 是显存带宽利用率，而 Mem-Usage 是容量占用，两者不同

打开新终端进行对话测试

vllm chat --url http://localhost:8000/v1 --model gemma-4-E4B-it

然后看到Please enter a message for the chat model:就说明已经连接上就可以对话了，

这里我输入了回车，教程里给的示例是经典的“你是谁，你能做什么”。

然后在用vllm运行gemma-4模型的terminal下可以看到：

因为上面我在客户端输入了3次请求（一次回车+一次“你是谁，你能做什么”+一次回车），所以服务器端生成了3次回复：

日志行片段 / 字段	含义	示例（来自日志）
127.0.0.1:35910 - "POST /v1/chat/completions HTTP/1.1" 200 OK	API 服务器收到来自本地的聊天补全请求，并成功返回 200 状态码。	来源 IP 127.0.0.1，端口 35910，接口 /v1/chat/completions
Triton kernel JIT compilation during inference: _compute_slot_mapping_kernel	推理过程中触发 Triton 内核的即时编译（JIT），引起单次请求的延迟增加（延迟尖峰）。建议扩展预热范围以覆盖此形状/配置。	内核名：_compute_slot_mapping_kernel
Avg prompt throughput	过去一段时间内平均 prompt 处理吞吐量（token/秒）。	7.3 tokens/s、6.4 tokens/s、0.0 tokens/s
Avg generation throughput	过去一段时间内平均 token 生成吞吐量（token/秒）。	24.3 tokens/s、25.8 tokens/s、3.4 tokens/s、0.0 tokens/s
Running: 0 reqs / Running: 1 reqs	当前正在引擎中执行（生成 token）的请求数量。	0 reqs、1 reqs
Waiting: 0 reqs	当前排队等待调度的请求数量。	0 reqs（始终为 0，说明没有排队）
GPU KV cache usage	GPU 上 KV 缓存的使用率（百分比）。	0.0%、0.1%
Prefix cache hit rate	前缀缓存命中率，即新请求的前缀 token 中有多大比例复用了已缓存的 KV 计算。	79.8%、88.5%
Engine 000	日志来源引擎编号，000 表示第一个（也是唯一）推理引擎。	Engine 000
loggers.py:271	打印统计信息的代码位置，方便定位源码。	文件 loggers.py，行号 271

这里面就可以很直观的看到一些生成的参数比如POST /v1/chat/completions出现了三次，即请求了三次服务。然后我对使用LLM API服务时也经常会看到的字段GPU KV cache和Prefix Cache展开了调研：

什么是 GPU KV cache？（内存）

在 Transformer 自回归生成中，模型每预测一个新 token，都需要对所有历史 token 计算注意力。为避免每次都重新计算，会把每个位置的 Key（K）和 Value（V）矩阵缓存下来，这就是 KV cache。GPU KV cache 特指这些缓存存储在 GPU 显存（VRAM）中，是推理吞吐和显存占用的核心瓶颈。

没有 KV cache：生成第 N 个 token 要算 N 次注意力，复杂度 O(n²)
有 KV cache：只需要用新 token 的 Q 去查之前缓存的 K、V，复杂度降到 O(n)

代价：随着序列变长，KV cache 线性增长，塞满显存。

PagedAttention

传统做法是给每个序列预留一整块连续显存，导致显存碎片化、利用率低（比如预留了 2048 但只用 100，跟操作系统中的内存分配类似）。vLLM 把 KV cache 切成无数个小的物理块（Block），就像操作系统的虚拟内存分页一样：

逻辑上连续的 KV cache 可以分散在显存的不同地方，几乎零浪费，同一个 Block 还能在不同请求间共享（例如相同的系统提示）

PagedAttention 通过上述方式相比传统方式，能在相同的GPU 上支持更大 batch（服务的请求数）、更长context（上下文）。

什么是 Prefix Cache？（内存复用）

在 LLM 服务中，很多请求的开头完全一样，比如：

相同的系统提示（system prompt）
相同的 few-shot 示例
相同的对话历史前缀

传统做法下，每个请求都要独立地对这段前缀计算一次自注意力、生成完整 KV cache，哪怕内容一模一样。

Prefix Cache 的思路：既然前缀相同，算出来的 K、V 也就相同，那就算一次，缓存起来，让后续所有请求直接复用这段 KV cache 块。

vLLM 中的自动前缀缓存（Automatic Prefix Caching, APC）
vLLM 基于 PagedAttention 的块（Block）级管理实现自动前缀缓存：

当新请求到来，vLLM 会检查其 prompt token 序列中，是否有某个物理块里的内容跟之前已缓存的块完全匹配。匹配上的块，直接映射到该请求的逻辑 KV cache 中，物理上零拷贝共享。只有前缀后面不同的部分才需要新算和分配新块。

这样带来的好处：

- 节省预填充（prefill）时间：前缀计算只需做一次，后续请求秒级跳过。
- 节省 GPU 显存：N 个请求共享同一套系统提示的 KV cache，显存只占 1 份，而不是 N 份。

特别适合聊天机器人：系统提示可能几千个 token，在每轮对话中都出现，有了前缀缓存，显存压力骤降。

关闭 vLLM 服务

经典Ctrl +C即可快速撤离.

参考资料

Gemma 4 现已发布: 同等规模下性能最强的开放模型

15分钟部署&运行 Gemma4 大模型- Datawhale AI学习中心

加入AMD AI开发者计划！

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

更多推荐

VLLMService Operator 开发第五篇：部署 Operator 并验证模型服务

存储准备完成后，就可以创建 VLLMService 资源了。metadata:spec:labels:port: 8000resources:requests:cpu: "2"limits:cpu: "4"storage:这里需要明确一点：VLLMService 本身只是用户声明的期望状态，它并不会直接运行模型。真正运行模型的是 Operator 根据这个 VLLMService 自动创建出来的

AMD开发者中国社区

VLLMService Operator 开发第六篇：给模型服务增加 Service 自动创建能力

做到这里，VLLMService Operator 已经不只是创建 Deployment 了，它开始具备完整服务编排的雏形。-> Pod-> Pod-> Service这一步非常关键，因为 Service 是后续接入流量入口的基础。没有 Service，HTTPRoute 就没有稳定的后端目标；-> Pod-> Service-> Gateway也就是说，Service 是从“模型 Pod 能跑起