如果你過去兩年一直在用顯卡跑大模型或 Agent 應用大概率已經感受到一個趨勢討論的焦點正在從“單輪問答的推理速度”轉向“多輪、帶工具調用、帶長上下文的智能體負載”。這類負載的特征是它不再像傳統 Benchmark 那樣跑一個 prompt 就結束而是需要模型在長時間內穩定輸出、反復推理、不斷調用工具并且要保持推理狀態的一致性和低延遲。在這種負載下算力硬件的“峰值數字”反而不是最關鍵的真正決定體驗的是軟硬件協同的效率。這正好是 AMD 軟件棧的機會窗口也是它最需要補課的地方。這篇文章想聊清楚一個判斷在智能體負載成為 AI 應用主線之后AMD 的軟件棧不再只是“CUDA 的替代品”而更可能成為整個 AI 基礎設施層的關鍵突破口。我會從智能體負載到底難在哪開始拆解 AMD 在 CPU、GPU、統一內存和開源軟件層的布局然后給出一套可落地的 ROCm 環境搭建、推理示例和常見問題排查思路。讀完你至少能判斷自己的 Agent 項目要不要考慮 AMD 路線以及如果要用第一步該做什么。1. 智能體負載與傳統推理負載有什么本質區別很多人對 AI 推理的理解還停留在“輸入一句話GPU 算一次輸出一段文字”。這是傳統 LLM 推理的基本形態也是各大評測 Benchmark 的測試方式。但智能體負載不是這樣的。智能體Agent負載的核心特征是多輪、多步、有狀態。一個典型的 Agent 工作流可能是用戶提出任務 → 模型理解意圖 → 調用一個搜索工具 → 拿到搜索結果 → 繼續推理 → 調用代碼執行器 → 驗證結果 → 最后生成回答。整個過程往往要持續幾十輪甚至上百輪的模型推理每一輪都會引入新的上下文模型需要在越來越長的上下文窗口中保持對歷史信息的跟蹤。這和傳統推理的差別非常明顯對比維度傳統推理負載智能體負載單次請求時長短幾百毫秒到幾秒長可能持續幾分鐘上下文長度固定或較短持續增長可能達到數萬 token顯存占用模式峰值固定可預估動態增長隨對話輪次累積對延遲的敏感性單次響應延遲長時間內的 P99 延遲穩定性失敗恢復能力單次失敗可重試狀態丟失會導致整個任務失敗對工具調用的支持不涉及需要穩定的結構化輸出持續調用外部工具這意味著智能體負載對硬件的要求不是“峰值算力有多強”而是長時間運行下的穩定性、顯存管理效率、算力調度能力。一個顯卡單次推理速度再快如果跑 30 分鐘的 Agent 任務時驅動不穩定或者顯存溢出整個任務照樣失敗。這也是為什么很多開發者在實際部署 Agent 應用時寧愿選擇顯存更大、軟件生態更成熟的方案而不只盯著單次推理的毫秒級數字。在這個背景下AMD 的位置很特殊硬件規格不差但軟件棧的成熟度決定了它能否真正接住智能體負載這個新場景。2. AMD 軟件棧的完整版圖不止是 ROCm聊 AMD 軟件棧很多人第一反應是 ROCm。但要在智能體負載這個場景里理解 AMD 的機會必須把軟件棧的視野放寬到整個平臺。AMD 當前能夠支撐智能體負載的技術棧大致可以分為四層第一層是 CPU 計算基座。AMD 的 EPYC 服務器處理器和 Ryzen 消費級處理器在核心數、內存帶寬和性價比上都有優勢。對智能體負載來說CPU 不只是“跑系統”的還承擔著 tokenize、解碼調度、工具調用邏輯編排等大量非 GPU 計算。一個智能體任務里GPU 負責推理CPU 負責流程控制兩者的配合效率直接影響整體延遲。第二層是 GPU 計算平臺 ROCm。ROCm 是 AMD 對標的 CUDA 的 GPU 計算平臺包含 HIP 編程模型、ROCm 運行時庫、編譯器、數學庫和通信庫。對開發者最直接的影響是PyTorch、TensorFlow、vLLM 等主流框架能否在 AMD 顯卡上穩定運行取決于 ROCm 的適配程度。第三層是統一內存與異構架構。AMD 在 CPUGPU 融合上有長期積累。服務器端的 MI300A 系列把 CPU 和 GPU 封裝在同一基板上共享統一內存池消費端的 Ryzen AI 處理器則集成了 XDNA AI 引擎。這種“統一內存”架構對智能體負載尤其有意義因為長上下文和工具調用結果需要頻繁在 CPU 和 GPU 之間搬運數據統一內存可以直接減少拷貝開銷。第四層是開源的軟件生態。AMD 在 LLM 推理生態上做了大量適配工作包括支持 Flash Attention 優化、接入主流推理引擎、提供模型量化工具等。對于 Agent 開發者來說更關鍵的是 Hugging Face Transformers、vLLM 等框架對 ROCm 的原生支持程度。理解這四層之后再回頭看標題里的“突破口”就清晰了AMD 的機會不在于某個單一的軟件工具而在于整套軟硬件協同的能力正在從“能跑”走向“跑得好”而智能體負載恰好是對“跑得好”要求最高的場景。3. 為什么說智能體負載是 AMD 軟件棧的突破口先給一個明確判斷智能體負載是這個階段最容易讓 AMD 軟件棧發揮比較優勢的場景同時也是促使 AMD 軟件?？焖俪墒斓拇呋鳌Ｏ日f為什么是“容易發揮優勢的場景”。智能體負載和傳統訓練負載有本質區別。大模型訓練拼的是絕對算力、互聯帶寬和分布式訓練框架的成熟度這些恰好是 NVIDIA 的護城河最深的領域CUDA 生態幾十年的積累不是短期能撼動的。但智能體負載是推理密集型任務它對硬件的要求更多集中在顯存容量、帶寬利用率和長時間穩定性上而這正好是 AMD 硬件規格上的強項。舉一個具體的場景。一個 Agent 應用需要同時處理 20 個并發會話每個會話都有上萬 token 的上下文。這種負載最需要的是大顯存和高內存帶寬。AMD 的 MI300X 在顯存容量上有明顯優勢對于推理場景來說大顯存直接意味著可以少做模型切分、降低通信開銷、提高吞吐。在性價比層面AMD 方案通常也有競爭力。再說為什么它也是“催化器”。這里要誠實面對一個事實AMD 的消費級顯卡在 AI 負載下確實存在驅動和軟件兼容性的痛點。從網上大量的反饋來看AMD 顯卡跑 AI 時掉驅動、驅動程序超時、閉源驅動在 Linux 下安裝困難等問題并不少見。這些問題的本質不是硬件不行而是軟件棧在消費級產品上的打磨還不夠。但智能體負載會改變這個局面。因為智能體負載的場景非常明確不像通用計算那樣需要軟件棧面面俱到。AMD 可以把有限的力量集中適配幾個主流推理框架保證 PyTorch、vLLM 等在 ROCm 上穩定運行。只要這些核心路徑被打通絕大多數 Agent 應用就能直接跑起來。這個判斷也意味著一種新的生態策略AMD 不需要在每一個細分領域都和 CUDA 硬碰硬只需要把智能體負載這個核心場景做到足夠好用就能打開局面。4. 在 AMD 平臺運行智能體負載的環境準備說了這么多背景現在進入實操。這一節的目標是幫你理解在 AMD 平臺上跑一個能支撐智能體應用的推理環境需要哪些組件先后順序是什么哪些環節最容易出問題。4.1 硬件選型思路如果你是個人開發者想先用本地 AMD 顯卡跑 Agent 應用比較現實的路徑是使用支持 ROCm 的 AMD 顯卡搭配 Linux 系統。消費級顯卡在 Windows 下的 ROCm 支持目前仍然有限很多 AI 框架的 ROCm 版本只提供 Linux 支持。如果你是團隊負責基礎設施選型要部署正式的 Agent 服務那大概率需要看 AMD 的服務器產品線。這類產品在顯存容量和內存帶寬上的優勢對多會話、長上下文的智能體負載非常有用。需要注意的是具體哪些顯卡型號受支持、支持到什么程度最好以 ROCm 官方文檔的兼容性列表為準。這里不寫死具體型號因為版本演進很快寫死了反而容易誤導。4.2 操作系統與驅動安裝思路我強烈建議在 Linux 下部署。原因是目前主流的推理框架PyTorch、vLLM、Transformers在 ROCm 版本上的支持幾乎都以 Linux 為第一優先。安裝的大致步驟如下安裝一個受支持的 Linux 發行版Ubuntu 的 LTS 版本通常是兼容性最好的選擇。安裝 AMD 閉源驅動。如果你關注過相關熱詞會發現“Ubuntu 安裝 AMD 閉源驅動”是出現頻率很高的問題。這一步確實容易踩坑不同內核版本、不同顯卡型號安裝路徑可能都不一樣。安裝 ROCm 軟件棧核心組件。安裝帶 ROCm 支持的 PyTorch。先看一個環境檢查命令確認系統能識別 AMD 顯卡設備# 檢查顯卡設備是否被系統識別 lspci | grep -i amd # 檢查內核是否加載了 amdgpu 驅動 lsmod | grep amdgpu # 查看 ROCm 是否安裝成功 rocm-smi如果輸出中能看到顯卡型號和溫度、功耗、顯存占用等信息說明 AMD 驅動和 ROCm 基礎層已經正常工作。4.3 安裝帶 ROCm 支持的 PyTorchPyTorch 是跑 Agent 應用最常用的框架之一。安裝帶 ROCm 支持的版本時核心是使用 AMD 提供的軟件源并選擇正確的 index-url。# 創建虛擬環境可選但推薦 python -m venv ~/agent_env source ~/agent_env/bin/activate # 安裝 PyTorch 的 ROCm 版本 # 注意具體的 ROCm 版本號以實際安裝的 ROCm 版本為準 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm安裝完成后驗證 PyTorch 能否調用 AMD GPU# 文件路徑check_device.py import torch print(PyTorch 版本:, torch.__version__) print(CUDA 是否可用:, torch.cuda.is_available()) print(ROCm 是否可用:, hasattr(torch.version, hip)) if hasattr(torch.version, hip): hip_version torch.version.hip print(HIP 版本:, hip_version) print(GPU 數量:, torch.cuda.device_count()) if torch.cuda.device_count() 0: print(GPU 名稱:, torch.cuda.get_device_name(0))運行方式python check_device.py這里有一點需要特別說明在 PyTorch 的 ROCm 版本中torch.cuda.is_available()返回True是正常的這是一個歷史遺留的兼容性設計底層實際走的是 HIP/ROCm不是 NVIDIA CUDA?？吹竭@個輸出不必困惑。5. 用最小示例驗證 AMD 平臺上的推理鏈路環境裝好之后不要急著上完整 Agent 框架。先用一個最小示例驗證AMD GPU 能不能真正跑起一個模型的 forward 推理。這一步能把“環境問題”和“業務問題”隔離開。下面的示例使用 Hugging Face Transformers 加載一個小模型在 AMD GPU 上跑一次文本生成# 文件路徑minimal_infer.py from transformers import AutoTokenizer, AutoModelForCausalLM import torch # 使用一個小模型驗證鏈路避免首次下載和加載時間過長 model_name sshleifer/tiny-gpt2 print(加載分詞器...) tokenizer AutoTokenizer.from_pretrained(model_name) tokenizer.pad_token tokenizer.eos_token print(加載模型...) model AutoModelForCausalLM.from_pretrained(model_name) # 將模型放到 AMD GPU 上 device cuda if torch.cuda.is_available() else cpu print(f使用設備: {device}) model.to(device) # 構造輸入 prompt The key to building a reliable AI agent is inputs tokenizer(prompt, return_tensorspt).to(device) # 推理 model.eval() with torch.no_grad(): outputs model.generate( **inputs, max_new_tokens32, do_sampleTrue, temperature0.7, ) # 解碼輸出 generated_text tokenizer.decode(outputs[0], skip_special_tokensTrue) print(生成結果:) print(generated_text) # 報告顯存占用 if torch.cuda.is_available(): allocated torch.cuda.memory_allocated() / 1024**2 reserved torch.cuda.memory_reserved() / 1024**2 print(f顯存占用: 已分配 {allocated:.1f} MB, 已預留 {reserved:.1f} MB)這段代碼的核心意義有三個第一它驗證了 ROCm 環境下 PyTorch 的推理鏈路是否完整包括張量運算是否真正落到了 GPU 上。第二它驗證了顯存管理是否正常。如果驅動有問題或者 ROCm 運行時有問題最容易出現的現象是程序崩潰、顯存溢出報錯或進程直接退出。第三它給出了一個極小的基線后續跑真正的 Agent 負載時可以先把這個最小示例跑通再逐步疊加復雜度。運行命令python minimal_infer.py如果輸出里能看到“使用設備: cuda”并且能打印出一段生成文本說明環境鏈路已經通了。如果在這里就失敗不要急著調業務代碼先回頭檢查驅動和 ROCm 安裝。6. 理解智能體負載在 AMD 平臺上的關鍵優化點最小示例跑通之后可以想一想真正的 Agent 負載在哪里會遇到瓶頸。下面這些點不是理論推演而是實際部署 Agent 服務時最常見的性能瓶頸。6.1 KV Cache 的顯存占用Agent 負載的上下文是持續增長的。每一輪對話模型都要把歷史 token 的 KV Cache 保存在顯存里。會話越長KV Cache 越大顯存占用越高。在 AMD 平臺上這對應的優化方向是優先選擇顯存容量大的 GPU 方案以及使用支持 PagedAttention 的推理引擎。PagedAttention 是一種顯存管理技術它像操作系統的虛擬內存一樣把 KV Cache 分成小塊管理可以大幅減少顯存碎片提高顯存利用率。目前主流推理引擎都實現了這種機制在 Agent 多會話場景下收益非常明顯。6.2 連續批處理Agent 場景下同一個模型可能同時服務幾十個會話但每個會話的推理進度不一樣。傳統的批處理方式需要等所有請求都到達后才能開始推理延遲高且浪費算力。連續批處理Continuous Batching的思路是只要有請求在排隊就開始新一輪推理不需要等整個 batch 齊了再開始。從框架角度看vLLM、SGLang 等推理引擎都支持連續批處理這些引擎目前都有 ROCm 適配版本。在 AMD 平臺上跑 Agent 負載建議直接使用這些引擎而不是自己寫推理調度邏輯。6.3 工具調用的穩定性智能體負載的一個特點是需要模型輸出結構化的工具調用參數。如果推理引擎的采樣參數不穩定或者量化精度損失過大模型可能輸出非法 JSON導致工具調用失敗。在 AMD 平臺上這意味著要多做量化方案的穩定性測試。常見的做法是準備一組工具調用測試用例分別在 FP16、INT8、INT4 下運行對比工具調用成功率。不要只看生成文本是否流暢要重點關注結構化輸出的準確性。6.4 CPU 與 GPU 的負載均衡很多人想當然地認為推理負載全部在 GPU 上CPU 不重要。但實際上Agent 的流程編排、tokenizer、HTTP 請求解析、工具執行、日志記錄都在 CPU 上執行。如果 CPU 核心數不夠或者 CPU 內存帶寬不足GPU 再快也會被“喂不飽”。AMD 的服務器處理器核心數多、內存通道多這個優勢在 Agent 負載下比在純訓練負載下更明顯。合理分配 CPU 核心給前端服務和推理引擎往往能帶來幾倍的端到端吞吐提升。7. 在 AMD 平臺部署 Agent 服務的完整示例跑通了最小推理示例理解了瓶頸點接下來可以看一個更接近生產形態的 Agent 服務示例。這里不涉及完整的 Agent 框架代碼而是展示一個核心思路如何把“模型推理”和“工具調用”組合起來形成一個最小可用的 Agent 循環。# 文件路徑simple_agent.py import json import torch from transformers import AutoTokenizer, AutoModelForCausalLM class SimpleAgent: def __init__(self, model_name): self.device cuda if torch.cuda.is_available() else cpu print(f加載模型到 {self.device} 設備) self.tokenizer AutoTokenizer.from_pretrained(model_name) if self.tokenizer.pad_token is None: self.tokenizer.pad_token self.tokenizer.eos_token self.model AutoModelForCausalLM.from_pretrained(model_name) self.model.to(self.device) self.model.eval() # system prompt告訴模型在需要查詢時輸出特定格式 self.system_prompt ( 你是一個智能助手。如果需要查詢外部信息 請嚴格輸出 JSON 格式{\tool\: \search\, \query\: \關鍵詞\} ) self.history [{role: system, content: self.system_prompt}] def chat(self, user_message): self.history.append({role: user, content: user_message}) # 將對話歷史拼成 prompt prompt_parts [f{item[role]}: {item[content]}\n for item in self.history] prompt .join(prompt_parts) assistant: inputs self.tokenizer(prompt, return_tensorspt).to(self.device) with torch.no_grad(): outputs self.model.generate( **inputs, max_new_tokens128, do_sampleFalse, ) response self.tokenizer.decode(outputs[0][inputs[input_ids].shape[1]:], skip_special_tokensTrue) self.history.append({role: assistant, content: response}) return self._parse_response(response) def _parse_response(self, response): 解析模型輸出。如果是工具調用格式則返回結構化指令否則返回普通文本。 response response.strip() if response.startswith({): try: return json.loads(response) except json.JSONDecodeError: return {type: text, content: response} return {type: text, content: response} def search_tool(query): 模擬一個搜索結果查詢工具。 return {result: f關于 {query} 的模擬搜索結果} def main(): agent SimpleAgent(sshleifer/tiny-gpt2) # 用戶提問觸發工具調用 while True: user_input input(用戶: ) if user_input in (exit, quit): break response agent.chat(user_input) print(助手: , response) # 如果模型希望調用工具則執行工具并把結果回傳給模型 if tool in response: tool_result search_tool(response.get(query, )) print(工具結果: , tool_result) agent.history.append({ role: system, content: f工具返回結果: {json.dumps(tool_result, ensure_asciiFalse)} }) if __name__ __main__: main()運行python simple_agent.py這段代碼展示了智能體負載的核心循環模型輸出 → 解析出工具調用意圖 → 執行工具 → 把結果寫回上下文 → 繼續下一輪推理。生產環境的 Agent 框架會比這復雜很多但本質就是這個循環。這個示例在 AMD 平臺上的意義在于整個循環中每一步都涉及 CPU 與 GPU 的交互。模型推理在 GPU 上而 JSON 解析、工具執行、歷史管理都在 CPU 上。如果 ROCm 軟件棧的底層通信效率不高這個循環的每一步都可能被額外延遲拖慢。所以這個最小循環實際上也在測試 AMD 軟件棧的端到端能力。8. AMD 平臺智能體負載的常見問題與排查方法在 AMD 平臺上跑智能體負載尤其是剛開始接觸 ROCm 的時候會碰到一些比較典型的問題。這里列一個排查清單覆蓋從環境到運行的常見故障。問題現象可能原因排查方式解決方案rocm-smi命令找不到ROCm 未安裝或 PATH 未配置檢查安裝目錄和 PATH重新安裝 ROCm或將 ROCm 的 bin 目錄加入 PATH運行 PyTorch 時提示 GPU 不可用驅動與 ROCm 版本不匹配查看rocminfo輸出根據顯卡型號安裝匹配版本的驅動和 ROCm模型推理時驅動崩潰或系統重啟AMD 驅動在特定負載下的穩定性問題查看/var/log/Xorg.0.log或dmesg升級驅動版本或降低顯存占用避免一次性分配過大顯存推理速度明顯低于預期沒有正確使用 GPU模型仍在 CPU 上跑檢查torch.cuda.is_available()和設備名稱確保模型調用.to(cuda)生成過程中顯存溢出OOM上下文過長KV Cache 占用過大監控rocm-smi的顯存占用使用支持 PagedAttention 的推理引擎或減少同時服務的會話數模型輸出 JSON 格式不穩定量化精度損失或采樣參數不當對比 FP16 和量化后的輸出調整 temperature/top_p或在關鍵任務中保持 FP16先說最常見的啟動失敗問題。如果你在 Ubuntu 上安裝了 AMD 閉源驅動之后系統無法正常進入桌面或者amdgpu內核模塊沒有自動加載優先檢查內核版本和驅動版本的兼容性。Linux 內核更新后舊版 AMD 驅動往往需要重新編譯或重新安裝。再說一個很容易被忽略的問題torch.cuda.is_available()返回 True但實際程序運行在 CPU 上。這個現象在 ROCm 環境下并不少見原因可能是 PyTorch 檢測到了 GPU 設備但某個算子的 ROCm 實現缺失導致計算回調到 CPU。判斷方法是查看設備運行時的耗時和顯存占用如果顯存占用不增長說明計算沒有真正落到 GPU。驅動超時也是高頻問題。AMD 顯卡在長時間高負載運行時如果驅動超時機制設置得太激進可能會中止正在執行的任務。這在 Agent 長時間運行的場景下非常致命因為一個幾十分鐘的 Agent 任務可能因為一次驅動超時就前功盡棄。建議在部署生產服務前先做一段時間的壓力測試觀察驅動穩定性。右鍵菜單里出現 AMD 相關選項、AMD External Events Utility 進程等問題更多是 AMD 顯卡軟件在 Windows 上留下的組件。如果你在 Windows 下只做日常使用和游戲不跑 AI可以直接通過 AMD Software 卸載這些組件如果你要在 Linux 下跑 AI建議從一開始就使用干凈的 Linux 環境避免 Windows 驅動殘留干擾判斷。9. 在 AMD 平臺構建智能體應用的最佳實踐與工程建議做了這么多拆解和示例最后給出幾條工程建議。這些建議不是泛泛而談而是針對 AMD 平臺 智能體負載這個具體組合踩過不少坑之后才值得總結的實踐經驗。9.1 先用小模型打通全鏈路再上大模型在 AMD 平臺上的第一課是不要一開始就加載一個 70B 的模型。先用幾百 MB 的小模型把驅動、ROCm、PyTorch、推理引擎這條鏈路全部打通確認每一個環節都正常再逐步上更大的模型。這樣排查問題時可以快速定位是模型的問題還是環境的問題。9.2 鎖定版本鎖定配置AMD 的軟件棧迭代非?？霷OCm 版本、PyTorch 版本、驅動版本、操作系統內核版本之間存在明顯的兼容矩陣。最穩妥的做法是選定一組經過測試的版本組合寫在項目的 README 或部署文檔里所有環境都按這個組合來。不要在一臺機器上隨意升級單個組件這可能引發連鎖兼容問題。9.3 監控顯存和驅動的長時間穩定性Agent 負載是長時間運行的負載對穩定性的要求遠超短時推理。建議在部署 Agent 服務的機器上配置監控重點觀察顯存占用趨勢和驅動狀態。一旦發現顯存占用持續增長不釋放或者驅動在某個時間段出現超時要盡快定位。9.4 為 Agent 的長時間運行設置檢查點和自動恢復Agent 任務可能持續幾十分鐘甚至幾小時中間任何一個環節失敗都可能導致整個任務失敗。在設計 Agent 服務時建議把任務狀態持久化到一個外部存儲中讓服務在重啟后能夠從最近一次成功的位置恢復。這個建議在任何平臺上都適用但在 AMD 平臺上尤為重要因為目前軟件棧的穩定性仍需更多打磨自動恢復機制是兜底。9.5 在采購或選型前做一次真實負載測試不要只看廠商提供的規格參數也不要在采購前只跑標準 Benchmark。Agent 負載和標準 Benchmark 的行為差異非常大一定要準備一批真實的 Agent 測試用例包含長對話、工具調用、并發會話在目標硬件上運行幾個小時觀察吞吐、延遲和穩定性。如果供應商提供測試環境一定要用真實負載去驗證而不是簡單跑一個模型生成速度測試。10. 總結與后續學習方向這篇文章的核心不是替 AMD 做宣傳而是想說明一個技術判斷智能體負載從計算特征上改變了 AI 應用的底層需求讓顯存容量、長上下文穩定性、軟硬件協同效率變得比單純峰值算力更重要。這個變化恰好把 AMD 的硬件優勢推到了前臺也讓 AMD 軟件棧的成熟度變成了真正的關鍵變量。如果把 AI 基礎設施比作一個城市NVIDIA 的 CUDA 生態像是已經建設了幾十年的成熟城區路網密集、配套設施齊全AMD 的 ROCm 軟件棧則更像一片正在開發的區域硬件道路很寬但部分基礎設施還在施工中。智能體負載的火爆就像一股新的產業潮涌入這座城市新的需求不再只集中在老城區而是大量涌向新城——這給 AMD 的軟件棧帶來了前所未有的壓力也帶來了前所未有的機會。對開發者來說現在是一個值得關注 AMD 軟件棧的時間窗口。不需要立刻把所有業務遷移過來但至少可以準備一套 AMD 的測試環境用小模型跑通 Agent 的全鏈路持續關注 ROCm 對主流推理框架的適配進度。等軟件棧在穩定性和兼容性上再進一步你已經有了一手經驗而不是站在旁觀者的位置紙上談兵。如果繼續深入學習下一步建議按這個順序先熟悉 ROCm 的架構和 HIP 編程模型再研究 vLLM 等推理引擎在 ROCm 上的部署方式然后深入理解 PagedAttention、連續批處理等推理優化技術最后結合你自己的 Agent 業務場景做針對性壓測。這條路走通之后你會對“AI 基礎設施選型”這件事有完全不一樣的理解。