企业官网建设流程全解析

1. 智能体负载为什么盯上了 AMD 软件栈

过去的两年，AI 应用的主战场正从“单次问答”快速转向“智能体（Agent）自动化任务”。不管是基于大模型做销售线索跟进、文档自动整理，还是企业内部跑多智能体协作系统，背后都有一个共同点：负载模型变了。

传统的大模型推理负载偏重“短请求、高吞吐”，用户问一句，模型回一句，GPU 算完就空闲。智能体负载却完全不同，它有明显的三高特征：高并发工具调用、长上下文持续累积、多模型实例并存。一个智能体任务，可能要在几分钟内反复调用 LLM 完成“理解意图、检索资料、生成工具参数、解析返回值、再次推理”的循环。这意味着 GPU 不只跑一次前向推理，而是一直处于“满载、间歇、再满载”的波动状态。

这种负载模型，恰好暴露了单靠 CUDA 生态的局限性。NVIDIA 在做高密度推理时依然强悍，但智能体场景强调的是多路并发、异构调度、频繁启停，对软件栈的弹性要求更高。AMD 这几年在 ROCm、推理框架适配、开源生态上的投入明显加大，加上 CPU+GPU 统一内存架构的优势，让 AMD 软件栈逐渐成为承接智能体负载的重要突破口。

本文不讨论“谁比谁强”的阵营之争，而是从工程视角拆解：智能体负载到底吃掉了哪些计算资源，AMD 软件栈提供了哪些应对手段，以及我们实际搭建和压测时可以怎么落地。

2. AMD 软件栈的核心构成与工作边界

很多同学对 AMD 软件栈的第一印象是“能跑 PyTorch 吗”。其实 AMD 软件栈现在的覆盖面已经很广，至少包含下面几层。

2.1 驱动层与应用运行环境

AMD 在 Linux 和 Windows 下分别提供不同的 GPU 驱动路径。

• Linux 下主流是 ROCm（Radeon Open Compute），它是一整套 GPU 计算平台，包含编译器、运行时、数学库和通信库。
• Windows 下除了官方驱动，也逐步支持 DirectML 和部分推理框架的 ROCm 移植版本。
• 消费级显卡（如 Radeon RX 系列）在 ROCm 的官方支持列表上越来越常见，但不同版本之间有差异，安装前必须核对型号和支持矩阵。

2.2 推理与训练框架适配层

智能体负载中，推理任务占大头。目前常见的路径有：

• PyTorch + ROCm：直接安装torch的 ROCm 版本，大多数模型可以无缝迁移。
• vLLM / SGLang 等推理引擎：部分版本增加了 ROCm 后端支持，是跑长上下文和并发推理的高效选择。
• ONNX Runtime 的 ROCm EP：适合把模型导出为 ONNX 后用统一运行时部署。
• Ollama / LM Studio 这类本地化工具：底层已支持 AMD GPU 加速，适合快速验证。

2.3 CPU 与 GPU 协同层

智能体负载不只吃 GPU，也吃 CPU。工具调用、上下文拼接、向量检索、任务调度这些逻辑大多在 CPU 上执行。AMD 的 EPYC 或 Ryzen 系列在多核性能上有优势，配合 ROCm 可以做到 CPU 负责控制流、GPU 负责张量计算的分工。再加上 AMD 在部分平台上支持统一内存寻址，可以减少 CPU 与 GPU 之间的数据拷贝开销。

搞清楚了软件栈的构成，下面就可以从智能体负载的视角来分析它真正需要的是什么。

3. 智能体负载模型拆解：瓶颈不在“算得快”，而在“调度稳”

很多团队在评估 AMD 平台时，习惯沿用“跑 Benchmark 看 FLOPS”的思路。但智能体负载的真正瓶颈往往不是峰值算力，而是下面的几个维度。

3.1 高并发请求下的显存波动

智能体服务通常以 HTTP 或 gRPC 方式暴露接口，每个请求会创建一次会话上下文。当多个用户同时发起任务时，显存中要同时驻留多个上下文。AMD GPU 的显存容量往往比同价位的 NVIDIA 产品更大，这让它在并发场景下更有余量。

但显存大不代表不会爆。长上下文智能体的 KV Cache 会随对话轮次增长，如果没有做上下文裁剪或显存池化，并发一高就会出现 OOM。

3.2 间歇性负载带来的功耗与散热压力

智能体的请求不是匀速的，而是突发的。比如早上 9 点大批销售开始使用智能体，或者某一轮数据抓取任务触发了 100 个并发子任务。这种间歇性高负载对 GPU 的功耗管理、温控策略、驱动稳定性要求很高。

有同学反馈“AMD 显卡跑 AI 掉驱动”，很大一部分原因就是在间歇负载场景下，驱动对电源状态切换的响应不够平滑。这个问题在 Windows 平台更明显，Linux 下相对稳定。

3.3 CPU-GPU 之间的数据搬运

智能体服务中，GPU 需要处理的是模型推理，但工具调用的参数、检索到的文档片段、历史对话记录，都是先经过 CPU 处理再送到 GPU 的。如果 CPU-GPU 之间的 PCIe 带宽不足，或者驱动没有启用统一内存优化，数据搬运就会成为隐性瓶颈。

3.4 多智能体实例的资源隔离

当你在同一台服务器上部署多个智能体（比如一个负责客服、一个负责内容生成、一个负责数据分析），就需要在软件层做资源隔离。AMD 的 MIG 类似功能在消费卡上不可用，但可以通过容器、进程绑定、显存限制等方式做软隔离。

4. 环境准备：AMD 平台跑智能体负载的软硬件基线

不管你是想本地跑一个 Ollama 智能体，还是在服务器上部署正式服务，环境准备都是最容易踩坑的环节。下面给出一个相对通用的参考。

4.1 硬件基线

4.2 Linux 环境（推荐）

智能体服务建议跑在 Linux 上，驱动稳定性和 ROCm 兼容性都更好。以 Ubuntu 为例，安装 ROCm 的核心步骤是添加 AMD 官方仓库。需要说明的是，具体版本号变化较快，以下命令是通用思路，请根据实际系统版本调整。

# 添加 ROCm 软件源（此处以 Ubuntu 为例，具体参考官方文档） sudo apt update sudo apt install rocm

安装后检查 GPU 是否能被识别：

rocm-smi

如果输出中能看到显卡名称、温度、显存使用率，说明驱动已经正常工作。

然后是安装 PyTorch 的 ROCm 版本。这一步最容易出错，因为 PyTorch 版本与 ROCm 版本存在一一对应关系。建议直接去 PyTorch 官网获取对应环境的安装命令，而不是随意 pip install。

# 示例命令，具体版本以官方 Install 页面为准 pip install torch --index-url https://download.pytorch.org/whl/rocm6.0

安装完成后，用 Python 验证 GPU 是否对 PyTorch 可见。

import torch print(torch.cuda.is_available()) print(torch.version.hip)

看到类似torch.version.hip输出，并且cuda.is_available()返回True，就说明 PyTorch 已经能在 AMD GPU 上跑了。需要提醒的是，这里返回 True 是 ROCm 做了 CUDA 兼容层，并不是真的有 NVIDIA CUDA。

4.3 Windows 环境

Windows 下跑 AMD 智能体相对麻烦一点。常见用法是：

• 使用 DirectML 跑 ONNX 模型。
• 使用 LM Studio 等封装好的工具，自动调用 AMD GPU 加速。
• 在 WSL2 中安装 ROCm 或使用 Docker 镜像跑 Linux 环境。

如果你听到“AMD 显卡 Win11 禁止更新”这类说法，通常是因为驱动更新导致系统强制重启，或者 Windows Update 自动替换了显卡驱动。解决思路是关闭自动驱动更新，使用 AMD 官方 Adrenalin 驱动手动更新。

5. 实战：搭建一个 AMD 平台上的智能体服务并压测

下面我们用一个完整的示例，演示如何在 AMD GPU 上搭建一个最简智能体服务，并对它做负载压测。这个例子使用 FastAPI + Ollama 做推理服务，模拟“用户请求 → 模型推理 → 工具调用结果返回”的流程。

5.1 创建项目结构

agent-benchmark/ ├── agent_server.py # FastAPI 智能体服务 ├── requirements.txt # Python 依赖 ├── load_test.py # 并发压测脚本 └── README.md

5.2 安装依赖

fastapi==0.111.0 uvicorn==0.30.1 requests==2.32.3

5.3 编写智能体服务

# 文件路径：agent-benchmark/agent_server.py import time from fastapi import FastAPI, Request from pydantic import BaseModel app = FastAPI() class AgentRequest(BaseModel): user_id: str prompt: str history: list[str] = [] class AgentResponse(BaseModel): user_id: str reply: str inference_time_ms: float tool_call_simulated: bool def simulate_tool_call(prompt: str) -> str: """模拟智能体调用外部工具的过程。 实际项目中，这里可能是检索数据库、查天气、发邮件等操作。 我们用一个简单规则模拟耗时，便于压测观察瓶颈。 """ if "查询" in prompt or "search" in prompt.lower(): time.sleep(0.3) return "工具返回结果：找到 3 条匹配记录" if "计算" in prompt or "calc" in prompt.lower(): time.sleep(0.2) return "工具返回结果：计算结果为 42" return "工具返回结果：无需调用外部工具" def run_llm_inference(prompt: str, history: list[str]) -> str: """模拟 LLM 推理。 真实项目中，这里会调用 Ollama / vLLM / 本地模型 API。 为了确保本示例在无 GPU 的环境也能运行，这里用固定逻辑代替。 在 AMD GPU 环境中，可以替换为 ollama.chat 等真实调用。 """ context = "\n".join(history[-5:]) combined = f"{context}\n用户提问：{prompt}" reply = f"模型回复：我已收到你的问题（前文长度 {len(combined)} 字），回答内容略。" return reply @app.post("/agent", response_model=AgentResponse) async def agent_endpoint(req: AgentRequest): start = time.time() # 第一步：把请求交给 LLM 理解 llm_output = run_llm_inference(req.prompt, req.history) # 第二步：判断是否调用工具 tool_result = simulate_tool_call(req.prompt) # 第三步：把工具结果拼回上下文，生成最终回复 final_reply = f"{llm_output} | {tool_result}" elapsed_ms = (time.time() - start) * 1000 return AgentResponse( user_id=req.user_id, reply=final_reply, inference_time_ms=round(elapsed_ms, 2), tool_call_simulated=True, ) if __name__ == "__main__": import uvicorn uvicorn.run(app, host="0.0.0.0", port=8000)

这里用模拟的方式代替真实模型调用，目的是让你先理解智能体服务的整体结构。真实场景中，run_llm_inference需要替换为对本地 Ollama 服务或云端 API 的调用，simulate_tool_call需要替换为真实的工具函数。

5.4 编写压测脚本

# 文件路径：agent-benchmark/load_test.py import argparse import time import requests from concurrent.futures import ThreadPoolExecutor def send_request(user_id: int, prompt: str): url = "http://127.0.0.1:8000/agent" payload = { "user_id": f"user_{user_id}", "prompt": prompt, "history": ["你好，帮我处理一下今天的任务", "请先查询相关数据"], } resp = requests.post(url, json=payload, timeout=30) return resp.status_code, resp.json().get("inference_time_ms") def main(): parser = argparse.ArgumentParser(description="智能体服务并发压测") parser.add_argument("--concurrency", type=int, default=20) parser.add_argument("--requests", type=int, default=100) args = parser.parse_args() start = time.time() success = 0 total_time = 0.0 with ThreadPoolExecutor(max_workers=args.concurrency) as executor: futures = [] for i in range(args.requests): prompt = f"查询并计算任务编号 {i} 的执行结果" futures.append(executor.submit(send_request, i, prompt)) for future in futures: status_code, latency_ms = future.result() if status_code == 200: success += 1 total_time += latency_ms duration = time.time() - start avg_latency = total_time / success if success else 0 qps = success / duration if duration > 0 else 0 print(f"总请求: {args.requests}") print(f"成功请求: {success}") print(f"总耗时: {duration:.2f} 秒") print(f"平均单请求耗时: {avg_latency:.2f} ms") print(f"QPS: {qps:.2f}") if __name__ == "__main__": main()

5.5 运行与验证

启动服务：

cd agent-benchmark pip install -r requirements.txt python agent_server.py

新的终端窗口运行压测：

python load_test.py --concurrency 20 --requests 100

预期输出类似：

总请求: 100 成功请求: 100 总耗时: 12.35 秒 平均单请求耗时: 460.12 ms QPS: 8.10

这个基准值没有 GPU 也能跑通，适合先验证流程。真实替换为 AMD GPU + Ollama 后，你会观察到平均耗时大幅下降，而这时再用rocm-smi观察 GPU 显存和利用率，就是评估 AMD 软件栈是否充分发挥的关键。

5.6 接入真实本地模型

如果你的机器上已经装好了 Ollama，并且已经拉取了一个支持 AMD GPU 的模型，可以把run_llm_inference改写为真实调用。

import ollama def run_llm_inference(prompt: str, history: list[str]) -> str: messages = [{"role": "user", "content": prompt}] for h in history[-5:]: messages.append({"role": "user", "content": h}) response = ollama.chat(model="qwen2.5:7b", messages=messages) return response["message"]["content"]

注意：Ollama 是否启用 AMD GPU 加速，取决于安装时是否识别到了 ROCm 环境。你可以在 Ollama 的日志中确认。

6. AMD 平台跑智能体服务的高频问题排查

根据社区反馈和实际经验，AMD 平台跑 AI 负载时最常遇到的问题集中在驱动稳定性和性能方面。下面整理成表格，方便直接查。

6.1 关于“驱动超时”的进一步排查

如果你在 Windows 上遇到“AMD 系统上的驱动程序超时”，不要急着换显卡。按下面的顺序排查：

1. 查看 Windows 事件查看器，定位是amdwddmg还是RadeonSoftware.exe报错。
2. 关闭浏览器硬件加速，排除视频解码干扰。
3. 卸载当前驱动，用 AMD Cleanup Utility 清理后重装。
4. 设置 TdrDelay 注册表值为 10 或更高，延长系统对驱动的响应超时时间。

这个方法针对智能体负载下的长时间 GPU 计算非常有效，因为默认的 2 秒超时对于大模型推理来说太短了。

6.2 关于 WSL2 与 AMD GPU

如果你在 Windows 下开发，想用 WSL2 跑智能体，需要注意：

• WSL2 内需要单独安装 ROCm 相关组件。
• 部分 AMD 消费级显卡在 WSL2 下的支持不如 Linux 原生环境完整。
• 建议直接使用 WSL2 的 Docker 镜像，参考官方提供的 ROCm 容器。

docker run -it --device=/dev/kfd --device=/dev/dri rocm/pytorch:latest

如果设备节点不存在，说明 WSL2 环境没有正确透传 GPU，需要更新 Windows 版本并启用 GPU 加速。

7. 从实验到生产：AMD 软件栈的最佳实践

跑通一个 demo 只是第一步。如果要让 AMD 软件栈真正成为智能体负载的关键支撑，下面几个工程建议值得重视。

7.1 上下文化与缓存管理

智能体负载中，上下文拼接会消耗大量显存和带宽。最佳实践是：

• 限制历史消息轮数，超出部分做摘要压缩。
• 对高频知识片段做向量化缓存，避免重复推理。
• 使用 KV Cache 量化技术，降低显存占用。

7.2 充分调用 CPU 与 GPU 的协同能力

AMD 的优势在于 CPU 和 GPU 同平台协同。实际部署时，建议把工具调用、向量检索、路由分发放在 CPU 侧，GPU 只负责模型推理。可以利用多进程或多线程模型让 CPU 侧任务并行处理，避免 GPU 空闲等待。

# 示例思路：用 ThreadPoolExecutor 并发发起多个工具调用 from concurrent.futures import ThreadPoolExecutor def parallel_tool_calls(tool_requests): with ThreadPoolExecutor(max_workers=4) as executor: results = executor.map(lambda x: simulate_tool_call(x), tool_requests) return list(results)

7.3 监控显存和电源状态

推荐在服务旁边跑一个监控脚本，周期记录 GPU 状态。

while true; do rocm-smi >> gpu_log.txt; sleep 5; done

压测结束后，检查 gpu_log.txt 中显存变化曲线。如果显存持续增长而没有回落，说明存在显存泄漏；如果 GPU 利用率长期低于 50%，说明 CPU-GPU 数据搬运或调度逻辑是瓶颈。

7.4 权限与安全边界

如果你把智能体服务暴露到内网或公网，必须注意：

• 对/agent接口加认证，避免被滥用为免费算力。
• 工具调用必须做参数白名单校验，防止恶意请求触发危险操作。
• 生产环境建议使用容器隔离，并为每个智能体实例设置独立资源限额。

# docker-compose 示例片段，限定容器对 GPU 的访问 services: agent: image: agent-benchmark:latest devices: - /dev/kfd - /dev/dri group_add: - video shm_size: 8g deploy: resources: limits: memory: 16g

7.5 日志与可观测性

智能体负载与传统 API 服务不同，一个请求会触发多次模型调用和工具调用。建议为每个请求生成 trace_id，并记录每次模型调用的耗时和 token 数。这样在排查“响应慢”时，能快速定位是模型推理慢、工具调用慢，还是上下文拼接慢。

import logging import uuid logger = logging.getLogger("agent") trace_id = str(uuid.uuid4()) logger.info(f"trace_id={trace_id} prompt={req.prompt} history_len={len(req.history)}")

8. 总结：智能体负载与 AMD 软件栈的未来趋势

回到标题来看，AMD 软件栈之所以被视为智能体负载的关键突破口，原因可以归结为三点：

第一，智能体负载的瓶颈已经从“单次推理速度”转向“并发调度效率和显存容量”，AMD GPU 的显存优势和 CPU-GPU 协同设计正好对上这个需求。

第二，ROCm 生态在过去两年快速补齐了 PyTorch、推理引擎、容器镜像等关键环节，开发者已经可以用接近 CUDA 的体验完成部署。

第三，智能体负载天然带有高波动性，对成本敏感。AMD 在性价比方面的优势，让中小团队有能力把智能体从云端大模型切换到本地部署，降低单次调用成本。

如果你正在评估 AMD 平台，建议从一个小型智能体服务入手，先跑通 Ollama + FastAPI 的组合，然后用压测脚本观察 GPU 利用率、显存变化和驱动稳定性。只有在真实负载下才能判断软件栈是否满足业务需求。

下一步可以深入的方向包括：ROCm 的底层调优、vLLM 在 ROCm 上的并发推理表现、多智能体框架与 AMD CPU 的亲和性配置，以及 Kubernetes + AMD GPU 的调度方案。硬件只是起点，软件栈的成熟度才是决定智能体负载能否稳定落地的真正关键。