1. AI Max 395 是什么定位為什么值得折騰最近不少跑本地模型的群友都在聊 AMD AI Max 395微博、B站、X 上也經(jīng)常刷到 Strix Halo 的測試圖。作為已經(jīng)實機(jī)用了一段時間的人我先把這臺機(jī)器的定位說清楚它本質(zhì)上是一顆把高性能 CPU、大規(guī)模 GPU、NPU 打包進(jìn)同一個 chip 的旗艦級 APU而配套的軟件生態(tài)主力就是 ROCm——AMD 對標(biāo)的 CUDA 開源計算平臺。所以這篇資源匯總核心圍繞兩件事展開AI Max 395 的硬件到底強(qiáng)在哪以及 ROCm 上怎么把它變成一臺能跑大模型的工作站。為什么大家盯著它因為過去玩本地 AI要么需要一塊昂貴的獨立顯卡要么選擇蘋果的統(tǒng)一內(nèi)存 Mac。AI Max 395 把兩者思路揉在一起CPU、GPU 共享同一片高帶寬內(nèi)存整機(jī)功耗又比傳統(tǒng) CPU獨顯方案低不少。這意味著你花一份預(yù)算就能獲得一臺既能編譯代碼、又能跑 32B 甚至更大參數(shù)量模型的單機(jī)設(shè)備。當(dāng)然光有硬件還不行ROCm 生態(tài)近幾年追上來了不少PyTorch、vLLM、llama.cpp 這些主流組件在 gfx1151 這個架構(gòu)上有官方或半官方支持這才是它能進(jìn)入我得力工具箱的真正原因。這篇文章適合三類人看第一類已經(jīng)下單但還沒裝好環(huán)境的 AI Max 395 用戶這里給了完整啟動路徑第二類在挑選板子和迷你主機(jī)時猶豫“AMD 能不能跑 AI”的觀望者這里能幫你判斷軟件棧的實際成熟度第三類熟悉 CUDA 但沒碰過 ROCm 的開發(fā)者不少命令行和報錯在兩種平臺下完全不同看完能少走很多彎路。1.1 一顆芯片上的三件套CPU、GPU、NPU 都是什么水平AI Max 395 的規(guī)格簡單概括是“堆料不眨眼”。CPU 部分是 16 核 32 線程的 Zen 5 架構(gòu)基礎(chǔ)頻率 3.1GHz加速頻率能到 4.3GHz 左右日常當(dāng)工作主機(jī)用完全夠。GPU 部分更夸張內(nèi)置 40 個 RDNA 3.5 計算單元對應(yīng)到獨顯大約就是 Radeon 8060S 這個級別桌面小主機(jī)外接一臺顯示器做圖形輸出、做渲染加速都足夠。另有一塊基于 XDNA 2 的 NPU本地吞吐大約 50 TOPS當(dāng)前主要給 Windows 上的 AI 應(yīng)用調(diào)用Linux 下主要靠 GPU 跑模型。但真正讓 395 區(qū)別于普通 APU 的地方是它最高支持 128GB 的 LPDDR5X 內(nèi)存內(nèi)存位寬 256-bit峰值帶寬在早期測試中穩(wěn)定在 250GB/s 上下。這是什么概念對比一下桌面級 DDR5 雙通道一般是 60GB/s 左右主流獨立顯卡配的 GDDR6 顯存是 300GB/s 到 600GB/s 級別AI Max 395 的內(nèi)存帶寬比傳統(tǒng)桌面內(nèi)存高出四五倍又比獨顯低一個檔次正好落在“能裝大模型”和“能喂飽 GPU 計算單元”之間的甜點上。所以我特別建議把 AI Max 395 理解成一個“帶寬約束的系統(tǒng)”而不是傳統(tǒng)意義上的“有獨顯的電腦”。你在上面跑 AI 時GPU 計算單元往往還有余力但每一條指令都受制于內(nèi)存能吐出多少數(shù)據(jù)。這個特質(zhì)直接決定了模型選型、量化格式、推理框架的取舍后面實操段落我會專門展開。1.2 統(tǒng)一內(nèi)存才是殺手锏傳統(tǒng)獨顯的寫代碼流程是顯存 24GB模型放不下就換成更小量化如果主機(jī)內(nèi)存 64GB也沒法把模型塞進(jìn)顯存里跑。AI Max 395 和蘋果 M 系列一樣GPU 和 CPU 之間沒有嚴(yán)格物理上的“顯存/內(nèi)存”隔離PyTorch、llama.cpp 之類的框架都能默認(rèn)把整個統(tǒng)一內(nèi)存空間當(dāng)成可用顯存活來用。這一點帶來的實際好處非常直接假如你機(jī)器配了 64GB那 20GB 左右的 30B 級模型、28GB 左右的雙模態(tài)模型都能塞進(jìn)去跑配到 128GB 后單機(jī)跑帶量化的大參數(shù)模型成為可能。雖然帶寬不如 HBM但容量和價格優(yōu)勢太明顯了一個 ITX 主機(jī)就能干過去需要整臺 A6000 工作站的事。更別提系統(tǒng)里同時掛著瀏覽器、IDE、編譯任務(wù)統(tǒng)一內(nèi)存不會把顯存和系統(tǒng)內(nèi)存切死資源利用率更高。1.3 和誰對比別用 RTX 4090 的思路看待 AI Max 395很多人習(xí)慣問“AI Max 395 能打 RTX 4090 嗎”。我的看法是這個問法本身就失真。RTX 4090 計算吞吐確實高出一截顯存帶寬也多出不少但 24GB 顯存容量擺在那跑不動 40B 以上的模型就是跑不動。AI Max 395 優(yōu)勢在“容量換帶寬”、在“一顆處理器搞定全部”劣勢也很清楚跑小模型、高并發(fā)負(fù)載時吞吐比不過一塊中高端獨顯。更現(xiàn)實的參照是蘋果 M4 Max、M4 Pro 這類統(tǒng)一內(nèi)存平臺。AI Max 395 的優(yōu)點是開放生態(tài)可以自己裝 Linux、隨意跑容器、用標(biāo)準(zhǔn) ROCm 工具鏈缺點是軟件兼容性仍需要時間沉淀不是所有 CUDA 時代的工具都能開箱即用。拿它做推理、調(diào)參、跑本地 Agent 是非常合適的做大規(guī)模訓(xùn)練或超長上下文高性能服務(wù)建議還是考慮真正的專業(yè)級方案。2. ROCm 支持現(xiàn)狀gfx1151 到能跑 PyTorch中間差了點啥講完硬件該講軟件了。AMD 的 ROCm 是個開源計算棧架構(gòu)分幾層底層有內(nèi)核驅(qū)動amdgpu往上是一組運行時庫如rocm-smi、libamdhip64再往上就是 HIP 編程模型和 ROCm 生態(tài)庫。PyTorch 現(xiàn)在官方分發(fā) ROCm 版本vLLM 也有原生編譯包llama.cpp 通過 HIP 后端支持 Radeon 全系列。但每個套件對架構(gòu)的適配進(jìn)度不一樣這也是大家查資料最容易亂的地方。2.1 ROCm 和 CUDA 生態(tài)的差異先建立心理預(yù)期如果你之前只碰過 CUDA剛上手 ROCm 會有兩個不舒服的地方。第一CUDA 是英偉達(dá)一家維護(hù)驅(qū)動、庫、框架版本經(jīng)常是一套整體對應(yīng)而 ROCm 的各個組件升級節(jié)奏不同內(nèi)核模塊版本、HIP 版本、PyTorch wheel 里捆綁的 ROCm 版本時不時會錯開需要多一點耐心看好支持矩陣。第二啟動參數(shù)和報錯信息不同GPU 架構(gòu) ID 叫 gfx1151部分老工具會不識別需要手動設(shè)置HSA_OVERRIDE_GFX_VERSION之類環(huán)境變量這個后面會專門講。有了這兩個心理預(yù)期后面遇到問題就不容易慌。實際上現(xiàn)在的 ROCm 已經(jīng)比兩三年前成熟太多PyTorch 官方輪子能做到“裝完即用”絕大多數(shù)普通用戶不需要自己從源碼編譯 HIP 庫。只做推理的話一部分用戶甚至能繞開傳統(tǒng) ROCm 全量安裝直接跑 llama.cpp 的 HIP 版或 vLLM 的預(yù)編譯包省時省力。2.2 gfx1151 支持時間線哪些版本值得記牢AI Max 395 對應(yīng)的 GPU 架構(gòu)代號是 gfx1151完整名字叫 RDNA 3.5 的集顯變體。ROCm 正式支持這個 ID 是從 ROCm 6.4.x 開始在 6.5、6.6 系列里持續(xù)完善。也就是說如果你下載一個 6.3 甚至更老的 ROCm 安裝包系統(tǒng)大概率會拒絕識別這塊 GPU或者在rocminfo中看到一堆空白。這是很多剛?cè)胧侄值男值茏钊菀撞鹊目域?qū)動裝了一晚上最后發(fā)現(xiàn)版本太老。ROCm 6.3.x 及之前不原生支持 gfx1151不建議浪費時間折騰ROCm 6.4.x首次提供正式支持可用 PyTorch 推理但部分工具不穩(wěn)定ROCm 6.5.x目前我用下來最穩(wěn)的組合vLLM、llama.cpp 構(gòu)建都能跑ROCm 6.6.x / 6.7 RC更新了編譯器、算子庫容器也升級可以嘗鮮但注意回滾路徑記住這個時間線你在選擇 Docker 鏡像、PyTorch wheel、vLLM release 時就有依據(jù)了。我的原則很簡單這些組件都往 6.5 或 6.6 靠攏不要混用版本太散的包。2.3 官網(wǎng)支持矩陣怎么讀別只盯著 GPU 列表ROCm 官網(wǎng)有個 compatibility matrix里面列出了受支持的 GPU、操作系統(tǒng)、內(nèi)核組合。但拿 AI Max 395 去對照時你會發(fā)現(xiàn)列表主線還是 MI 系列和 Radeon 獨顯APU 和部分移動端 GPU 的顯示邏輯不太一樣。這時候就要看“是否標(biāo)了 gfx1151”或者發(fā)行說明里有沒有 Strix Halo 字樣而不是傻傻地搜“395”。另外要留意 ROCm 對 Linux 內(nèi)核版本的最低要求。新版驅(qū)動模塊跟較老的內(nèi)核容易出現(xiàn)頭文件不匹配所以 Ubuntu 24.04、Fedora 41 這些相對新一點的系統(tǒng)是更順滑的選擇。Windows 側(cè)ROCm 近兩年也開始了原生移植計劃但普通用戶暫時還是建議用 WSL2 或干脆裝雙系統(tǒng)Linux 下跑 AI 的省心程度目前依然遠(yuǎn)超 Windows。3. 資源匯總官方、社區(qū)、鏡像一篇拿齊這部分是純干貨列表我把接觸過的資源按照用途分了個類。每個類別里我都標(biāo)注了哪些是必看的、哪些是備胎、哪些適合進(jìn)階用戶。3.1 官方文檔與發(fā)布入口ROCm 官方文檔中心這是第一站包含安裝、庫介紹、內(nèi)核驅(qū)動說明本質(zhì)上的“最全地圖”。地址不復(fù)雜直接搜 ROCm docs 就能出來強(qiáng)烈建議裝完驅(qū)動后把“ROCm Installation”那一章通讀一遍PYTorch 官方安裝頁它生產(chǎn)標(biāo)準(zhǔn)命令我們敲pip install torch --index-url ...裝 ROCm 版 PyTorch 時用的鏈接就是它生成的HuggingFace / ONNX Runtime 等上游框架文檔ONNX Runtime 對 ROCm 的支持文檔其實寫得不錯推薦作為閱讀補(bǔ)充3.2 PyTorch ROCm wheel 和安裝命令PyTorch 官方從 ROCm 5.x 時代就開始發(fā)布預(yù)編譯 wheel現(xiàn)在的命令大概長這樣具體 index-url 以官方頁面為準(zhǔn)pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.5注意幾個容易出錯的地方第一Python 版本兼容性PyTorch 官方 wheel 一般需要 Python 3.9 到 3.12社區(qū)反饋 3.11 或 3.12 最穩(wěn)定第二需要先把系統(tǒng)里現(xiàn)有的 torch 卸干凈否則 pip 會保留舊版本導(dǎo)致沖突第三ROCm 環(huán)境變量如果對不上哪怕裝上了也會在導(dǎo)入時提示找不到 HIP 庫。更省事的方式是用uv或者 Conda 建獨立環(huán)境至少避免搞壞系統(tǒng) Python。3.3 vLLM 與推理框架vLLM 是當(dāng)前服務(wù)化推理的主流選擇滾動批處理、PagedAttention 這些特性對吞吐提升明顯。它支持 ROCm但安裝時得確認(rèn)你選的 release 是否編入了 gfx1151。官方 GitHub 的 release 說明里會寫rocm相關(guān)的預(yù)編譯包如果找不到對應(yīng)版本就老老實實從源碼編譯一次。llama.cpp 是另一個方向適合快速跑單機(jī)量化模型。它的 HIP 編譯目前是社區(qū)維護(hù)的熱門路徑只要環(huán)境里有 ROCm 工具鏈編譯參數(shù)指向-DGGML_HIPON再指定AMDGPU_TARGETSgfx1151即可。跑起來以后可以用llama-bench做快速性能測試這個比看評測文章直觀得多。3.4 容器鏡像匯總?cè)萜骰瘜π率肿钣押靡驗樗袔旌鸵蕾囈呀?jīng)打包好可以繞開大部分依賴地獄。我常用的鏡像來源rocm/pytorch 系列官方維護(hù)標(biāo)簽里有 ROCm 版本和 PyTorch 版本組合拉下來基本能直接跑vllm/vllm-openai 的 ROCm tag官方推薦有對應(yīng) ROCm 版本的鏡像社群鏡像Reddit 的 r/LocalLLaMA 和 AMD 開發(fā)者社區(qū)里經(jīng)常有人分享自己打好的鏡像最適合拿來當(dāng)“黑盒”快速試用鏡像雖好用但要注意一點容器內(nèi)組件版本對應(yīng)宿主機(jī)內(nèi)核模塊。通常 Docker 容器只裝用戶態(tài)庫內(nèi)核驅(qū)動還是依賴宿主機(jī)的amdgpu所以宿主機(jī) ROCm 版本太老容器里新的軟件棧照樣跑不起來。這個“內(nèi)核驅(qū)動在宿主、用戶態(tài)庫在容器”的心智模型最好先建立起來。3.5 社區(qū)站點與討論專區(qū)搞 AI 繞不開社區(qū)ROCm 相關(guān)的活躍陣地包括AMD ROCm GitHub 倉庫不是只看代碼issue 區(qū)有很多真實用戶的踩坑記錄搜索 gfx1151 能找到大量一手經(jīng)驗Reddit 的 r/LocalLLaMA、r/ROCm測速帖、裝機(jī)帖密度很高尤其是 Strix Halo 剛出的那幾周很多關(guān)鍵結(jié)論都出自這里AMD 社區(qū)論壇官方工程師偶爾出沒一些兼容性問題的最終回復(fù)會比普通社區(qū)準(zhǔn)確我的經(jīng)驗是遇到報錯先去 GitHub issue 搜報錯原文十有八九能找到別人提交過的解決方案搜不到再發(fā)帖提問提問時附上rocm-smi和rocminfo的輸出別人更容易幫你精準(zhǔn)定位。3.6 工具鏈和調(diào)優(yōu)能力如果只是跑跑現(xiàn)成模型裝個 PyTorch 就夠。一旦開始做量化、微調(diào)、實驗新算子就得補(bǔ)上這些底層工具ROCm 編譯器工具鏈hipcc、hipify、rocm-smi 等常見命令所在的包rocm-smi查看 GPU 狀態(tài)的核心工具類似于nvidia-smi可以用rocm-smi --showuse --showtemp實時觀察核心占用率和溫度rocBLAS / hipBLASLt / MIOpen矩陣運算、卷積運算的底層庫PyTorch 調(diào)用的就是它們。碰到算子報錯時需要確認(rèn)這些庫是否已隨 ROCm 安裝AMD 的內(nèi)存大頁 HugePage 工具對內(nèi)存密集型推理有幫助一般不需要普通用戶干預(yù)這部分我平時不是全裝而是哪個需求出現(xiàn)了再裝哪個。但rocm-smi和rocminfo建議第一批就裝它們是診斷一切問題的起點。4. 從零搭建在 AI Max 395 上跑通 Llama 的實操記錄光有資源清單不夠我把自己從全新系統(tǒng)到跑出第一個 token 的完整過程整理出來你照著走一遍應(yīng)該能省下好幾個小時。4.1 硬件與系統(tǒng)準(zhǔn)備我用的是一臺 AMD AI Max 395 平臺的 mini PC配了 128GB LPDDR5X 內(nèi)存系統(tǒng)盤是一塊 2TB NVMe。系統(tǒng)裝的 Ubuntu 24.04.2 LTS內(nèi)核版本 6.8 往上。為什么不選 22.04因為 ROCm 6.5 官方對 24.04 的覆蓋完整Linux 內(nèi)核也新USB4、Wi-Fi 這類周邊設(shè)備的兼容性也好很多。到手第一步先進(jìn) BIOS 確認(rèn)幾項內(nèi)存頻率是否識別到 8000MT/s 左右、啟用 SVMAMD 的虛擬化相關(guān)選項后面跑容器有用、電源管理模式別選省電檔。因為 AI Max 395 的內(nèi)存帶寬直接決定推理速度如果你發(fā)現(xiàn)內(nèi)存被設(shè)成了低功耗 5600MT/s跑模型的性能會差一大截。4.2 安裝驅(qū)動和運行時Ubuntu 下最保險的方式是用 AMD 源安裝 ROCm。大致流程是# 添加 ROCm 官方 apt 源以 6.5 為例具體以官網(wǎng)為準(zhǔn) wget https://repo.radeon.com/rocm/6.5.1/ubuntu/... # 或者用官方的一鍵腳本 sudo apt update sudo apt install rocm裝完必須用這兩條命令驗證rocm-smi # 應(yīng)該看到 4 個卡其實是 1 個 GPU 的 4 個調(diào)度分區(qū)或者 1 個 device rocminfo # 搜索 gfx1151確認(rèn)被識別新手最大的困惑點在這里AI Max 395 的核顯在 ROCm 視角下可能會顯示成幾個不同的agent代表不同功能塊。忽略額外信息你只需要關(guān)心 gfx1151 的那一行是否正常出現(xiàn)以及rocm-smi能不能讀到溫度、功耗。apt 裝完再把當(dāng)前用戶加入render或video組否則普通用戶訪問 GPU 設(shè)備節(jié)點會權(quán)限不足sudo usermod -aG render $USER sudo usermod -aG video $USER改完注銷重登再測權(quán)限問題在 ROCm 里非常常見幾乎每個人都會遇到一次。4.3 安裝 PyTorch ROCm 并自檢然后建一個干凈的虛擬環(huán)境裝 PyTorchpython -m venv ~/envs/rocm_env source ~/envs/rocm_env/bin/activate pip install torch --index-url https://download.pytorch.org/whl/rocm6.5如果只想快速測試可以先跑一段最小的 GPU 張量運算看能否調(diào)用 HIPimport torch x torch.randn(1024, 1024, devicecuda) y x x.T print(torch.cuda.is_available()) # 返回 True 才說明 PyTorch 已經(jīng)識別到 GPU這里有個 ROCm 生態(tài)特有的“迷惑行為”PyTorch 的devicecuda字符串在 ROCm 版本里也繼續(xù)沿用所以torch.cuda.is_available()返回 True 不代表你在用 NVIDIA 硬件它只是兼容層實際調(diào)的是 HIP。很多新用戶不知道這一點看到cuda字眼就會誤判。如果要確認(rèn)算力真的在跑看rocm-smi --showuse里的 GPU 利用率是否漲上來再配合watch -n 1 rocm-smi --showtemp觀察溫度曲線。如果遇到 HIP 相關(guān)的段錯誤或找不到庫文件多半是LD_LIBRARY_PATH的問題把 ROCm 安裝路徑下的lib目錄加進(jìn)去再試。4.4 跑 Llama 的實際命令與預(yù)期性能我用 llama.cpp 做說明因為編譯和運行最透明。先克隆倉庫再按 ROCm 配置編譯git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build cd build cmake .. -DGGML_HIPON -DAMDGPU_TARGETSgfx1151 cmake --build . --config Release -j 16編譯時間可能會比較長耐心等待。跑一個 8B 模型的命令大概是./llama-cli -m /models/llama-3.1-8b-instruct.Q4_K_M.gguf -p 介紹一下合肥 -n 128如果你不想源碼編譯其實也可以下載官方編譯的普通版 llama.cpp 跑 CPU但那樣沒法調(diào)用 GPU。協(xié)作開發(fā)時的建議是直接在構(gòu)建目錄里跑llama-bench它會把不同 block size 下的 prompt 處理速度和 token 生成速度一次性列出來比手動測準(zhǔn)確得多。關(guān)于性能預(yù)期我給出一個基于實測的粗略參考區(qū)間受溫度和電源策略影響會浮動8B 模型 Q4 量化prompt 處理約 800~1200 token/s生成約 40~55 token/s14B 模型 Q4 量化生成約 25~35 token/s32B 模型 Q4 量化生成約 15~25 token/s70B 模型 Q4 量化生成約 8~12 token/s勉強(qiáng)可用此時 128GB 內(nèi)存能裝下但帶寬已經(jīng)吃滿這個成績放到 128GB 統(tǒng)一內(nèi)存平臺上最大的意義是讓“大模型常駐內(nèi)存”成為可能。你不會有“顯存不夠先把其他程序關(guān)掉”的焦慮模型加載一次后面整個對話、任務(wù)調(diào)度都在幾十毫秒級完成。4.5 服務(wù)化部署vLLM 與 OpenAI 兼容接口單機(jī)命令行爽完了接下來大概率想接一個服務(wù)端口給各種客戶端用。vLLM 是更工業(yè)級的選擇安裝時如果不想從源碼編譯先看看是否已有匹配 ROCm 6.5 的預(yù)編譯輪子。跑起來的命令類似python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-32B-Instruct \ --dtype float16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.85--gpu-memory-utilization這個參數(shù)在統(tǒng)一內(nèi)存平臺上要格外小心。它表示允許 vLLM 使用多少比例的可用內(nèi)存但 AI Max 395 上沒有獨立的顯存GPU 會動態(tài)占用系統(tǒng)內(nèi)存。官方推薦的 0.9 往往會讓系統(tǒng)沒內(nèi)存跑推理進(jìn)程我實測 0.75 到 0.85 之間的體驗比較穩(wěn)。服務(wù)起來以后用標(biāo)準(zhǔn) OpenAI SDK 就能調(diào)用和跑在 CUDA 機(jī)器上的接口風(fēng)格完全一致。如果你更偏好輕量方案也可以選擇 LLaMA.cpp 自帶的 HTTP serverllama-server同樣提供 OpenAI 兼容 API適合個人知識庫或內(nèi)部小工具部署簡單依賴也少。5. 我實際踩過的坑和不建議做的操作這部分是血淚合集。環(huán)境搭多了以后我最大的體會是 ROCm 相關(guān)的報錯大部分不是死解不了的難題而是版本不匹配的變體。5.1 驅(qū)動和內(nèi)核版本暗坑我在 Ubuntu 24.04 上曾經(jīng)把內(nèi)核手動升級到 6.9結(jié)果 ROCm 模塊編譯失敗啟動時直接黑屏。后來查到 AMD 官方支持矩陣?yán)飳?nèi)核版本有明確驗證范圍新內(nèi)核不一定更好。正確的做法是官方支持什么內(nèi)核就用什么不要手賤升級。另一個高頻坑是同時裝了amdgpu-dkms和發(fā)行版自帶的amdgpu模塊沖突后rocminfo直接看不到設(shè)備。我后來的習(xí)慣是安裝 ROCm 之前先把系統(tǒng)里各種 fglrx、舊版驅(qū)動清除干凈裝完再重啟。如果你已經(jīng)遇到畫面崩壞、開機(jī)卡死進(jìn) recovery mode 卸載剛裝的 ROCm 包即可恢復(fù)。5.2 環(huán)境變量和 Python 環(huán)境匹配PyTorch wheel 和LD_LIBRARY_PATH有著奇妙的耦合關(guān)系。我給自己定了幾條規(guī)矩用 venv 或 conda 管理 Python 環(huán)境不在系統(tǒng) Python 全局裝庫每個項目單獨建環(huán)境避免 torch 和 vllm 互相覆蓋遇到 ImportError 先檢查rocminfo是否能正常輸出再檢查LD_LIBRARY_PATH是否指到正確的 ROCm lib 目錄跑 vLLM 時減少不必要的環(huán)境變量多變量疊加反而會干擾這四條規(guī)矩說起來平凡卻幫我避開過至少七八次“為什么我裝的 PyTorch 看不到 GPU”的崩潰瞬間。5.3 內(nèi)存、HugePages 和大模型加載統(tǒng)一內(nèi)存平臺的“內(nèi)存即顯存”模式有一個隱藏問題系統(tǒng)默認(rèn)的內(nèi)存頁管理會干擾大塊分配。推理超過 30B 模型時llama.cpp 或 vLLM 可能會提示分配失敗或性能異常這時可以考慮啟用 HugePages把模型駐留的內(nèi)存取成 2MB 大頁減少 TLB miss。不過這需要修改內(nèi)核參數(shù)和系統(tǒng)配置普通用戶可以先不開等真遇到性能瓶頸再調(diào)。另外AI Max 395 的內(nèi)存帶寬雖高但 LPDDR5X 和 HBM 的延遲特性不同。實測超過 70B 級別的模型時長上下文的 prefill 階段會變得很慢這個物理瓶頸暫時無解。所以模型規(guī)模在上限邊緣時別期望它能像 H100 那樣飛起合理預(yù)期更重要。5.4 編譯源碼時目標(biāo)架構(gòu)寫錯的教訓(xùn)我第一次編譯 llama.cpp 時沒寫AMDGPU_TARGETSgfx1151導(dǎo)致 GGML 編譯時只包含了通用目標(biāo)碼GPU 完全沒跑起來CPU 燒了半天也慢如老牛。后來才意識到ROCm 編譯工具會根據(jù)目標(biāo)架構(gòu)生成特定 ISA架構(gòu)沒寫對等于白編譯。vLLM 從源碼編譯更講究官方文檔會要求指定ROCM_TARGETgfx1151或類似參數(shù)并且需要較新版本的 ROCm 編譯器否則會在生成 miopen_kernels 時直接報錯。這些細(xì)節(jié)在官方文檔的AMD installation from source章節(jié)里都有只是字體不大、容易被跳過。我的建議是所有源碼編譯任務(wù)都集中固定在“ROCm 6.5 允許目標(biāo)架構(gòu) gfx1151”的組合能省很多無謂的時間。5.5 不建議做的三件事結(jié)合群友的反饋我額外列出三件不建議做的事第一不建議一上來就跑去改裝內(nèi)核參數(shù)做 ROCm 性能調(diào)優(yōu)比如強(qiáng)行改 GPU 頻率上限容易導(dǎo)致整機(jī)不穩(wěn)定。先把自帶配置跑通再逐步調(diào)。第二不建議在 Windows 上硬跑 ROCm 原生推理。雖然 AMD 一直在推進(jìn) Windows 支持但生態(tài)完善度、算子覆蓋、容器兼容都遠(yuǎn)不如 Linux折騰的性價比很低。第三不建議拿 128GB 內(nèi)存去一次性并發(fā)跑很多個 70B 模型。容量雖夠但帶寬會迅速耗盡多個模型同時 prefill 時系統(tǒng)的響應(yīng)延遲會指數(shù)級惡化還不如排隊逐個推理。6. 資源速查表與后續(xù)路線建議最后把高頻資源收攏成一張表方便你存下來慢慢查。我沒有列密密麻麻的 URL更建議按“功能目標(biāo)”去記憶這些位置因為網(wǎng)址會隨著版本調(diào)整而變動。資源用途獲取方式ROCm 官方文檔安裝說明、兼容矩陣、API 參考搜rocm docs amdPyTorch 官方安裝頁生成 pip 安裝命令打開 pytorch.org 的 get-started 頁面選 ROCmROCm GitHub 組織源碼、issue、社區(qū)修復(fù)方案GitHub 搜ROCm組織rocm/pytorch 鏡像Docker 快速啟動環(huán)境Docker Hub 搜rocm/pytorchvLLM 官方文檔服務(wù)化部署、源碼編譯指引搜vllm amd installationllama.cpp 倉庫GGUF 模型推理、benchmarkGitHub 搜llama.cppAMD 社區(qū)論壇遇到疑難雜癥時求助搜AMD community ROCmr/LocalLLaMA性能測試、模型推薦、使用分享Reddit 對應(yīng)分區(qū)6.1 如果打算搭建我建議的路線第一步確定系統(tǒng)。優(yōu)先 Ubuntu 24.04 或 Fedora 41內(nèi)核保持官方默認(rèn)。第二步按官方文檔裝好 ROCm 6.5 系列跑通rocminfo。第三步建 Python 虛擬環(huán)境裝 PyTorch ROCm wheel跑一個矩陣乘法確認(rèn)算力可用。第四步從 Hugging Face 下載一個 8B 量化模型用 llama.cpp 或 loader 跑通生成。第五步如果要做服務(wù)安裝 vLLM 或 llama-server 啟動 OpenAI 兼容接口。這條路線循序漸進(jìn)每個階段都有明確的驗證點不會讓你陷入“裝了一堆東西但不知道是不是真的成功”的迷茫。整體時間大約半天到一天有一個懂 Linux 的朋友在旁邊的話速度會再快一點。6.2 后續(xù)還能擴(kuò)展哪些玩法把基礎(chǔ)推理跑通之后AI Max 395 可以繼續(xù)往幾個方向深耕本地 RAG 知識庫用嵌入模型 向量庫 LLM 組成、多模態(tài)模型推理、基于 vLLM 給局域網(wǎng)內(nèi)其他設(shè)備提供 API 服務(wù)、甚至用 ROCm 做小規(guī)模微調(diào)和 LoRA 實驗。這些方向的共同點都是依賴統(tǒng)一內(nèi)存的容量優(yōu)勢而缺點則集中在帶寬對 prefill 階段的限制。眼下 AI Max 395 還很新ROCm 的每個版本發(fā)布都會帶來新的算子支持和性能優(yōu)化。如果你像我一樣打算長線使用我建議把 ROCm 版本固定在某個穩(wěn)定序列同時對 releases 頁面保持關(guān)注看到明顯性能提升的新版本再系統(tǒng)性升級不要每次發(fā)布都沖到最前線。畢竟這套東西的樂趣在于把本地 AI 變成真正能日常使用的生產(chǎn)力工具穩(wěn)定壓倒一切。