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