1. 從“atlas”這個詞說起它到底指什么第一次看到“atlas”這個項目標(biāo)題很多人腦子里會同時冒出好幾個不相干的畫面有人想到地圖冊有人想到希臘神話里扛著天球的泰坦神還有人想到數(shù)據(jù)庫里那張存著核心元數(shù)據(jù)的系統(tǒng)表。但在我們做AI工程和異構(gòu)計算這一行里提到“atlas”十有八九說的是昇騰Ascend系列里的 Atlas 產(chǎn)品線——它既包括 Atlas 300I / 300V 這類推理加速卡也包括 Atlas 200 DK、Atlas 500 這類邊緣小站和開發(fā)者套件還包括 Atlas 800 訓(xùn)練服務(wù)器這種機(jī)架式的大塊頭。這個標(biāo)題給得很寬就一個詞“atlas”沒有限定是硬件、是軟件棧、還是某個具體型號。所以我在拆解的時候干脆把它當(dāng)成一個“入口”來處理圍繞 Atlas 這條產(chǎn)品線把從選型、部署到跑通 YOLO 的完整鏈路講清楚。熱搜詞里那兩個特別有意思——“atlas部署yolo”和“atlas 300v 24g 是運算加速卡嗎”前者是典型的落地需求后者是典型的選型困惑。這兩個問題恰好覆蓋了新手從“認(rèn)識硬件”到“跑通模型”的全過程我就順著這條線往下寫。先給一個最直白的定位Atlas 300V 24G 是一塊推理加速卡不是顯卡也不是通用計算卡。它用的是昇騰 310P 芯片24GB 的顯存準(zhǔn)確說是片上內(nèi)存主要干的事是把訓(xùn)練好的模型拿過來做前向推理。你不能拿它去打游戲也不能拿它當(dāng)普通 GPU 跑 CUDA 代碼它的價值在于在同樣功耗下把推理吞吐拉上去并且支持多路視頻解碼。這一點如果一開始沒搞明白后面裝驅(qū)動、配環(huán)境、轉(zhuǎn)模型的時候會處處碰壁。這篇文章適合誰看如果你是剛拿到一張 Atlas 卡、或者公司剛采購了一臺 Atlas 服務(wù)器需要把 YOLO 系列模型部署上去跑起來的工程師那這篇就是給你寫的。如果你還在選型階段糾結(jié)到底買 300I Duo 還是 300V我也會把兩者的差異和適用場景講清楚。哪怕你只是聽說過 Atlas 想了解一下前面幾節(jié)的基礎(chǔ)拆解也能讓你少走彎路。2. 硬件選型Atlas 300V 24G 到底是不是運算加速卡2.1 先把“運算加速卡”這個概念掰開“運算加速卡”這個詞其實是個籠統(tǒng)的叫法。廣義上講任何插在服務(wù)器上、專門替 CPU 分擔(dān)計算任務(wù)的板卡都能叫加速卡GPU 是FPGA 是ASIC 也是。但在這個圈子里大家說“加速卡”的時候通常默認(rèn)指的是面向 AI 推理或訓(xùn)練的專用加速硬件而不是圖形卡。Atlas 300V 24G 的定位非常明確推理加速卡。它基于昇騰 310P 處理器這顆芯片的設(shè)計目標(biāo)就是高能效推理。它沒有視頻輸出接口你插上顯示器是點不亮的它也不支持 CUDA你寫torch.cuda.is_available()永遠(yuǎn)返回 False。它的正確打開方式是裝好驅(qū)動和固件裝好 CANN 工具包然后用昇騰的推理引擎去加載 om 模型。那它和 Atlas 300I Duo 有什么區(qū)別這是選型時問得最多的問題。我整理了一張對照表把關(guān)鍵參數(shù)擺出來對比項Atlas 300I DuoAtlas 300V 24G芯片昇騰 310P昇騰 310P顯存96GB LPDDR4X雙芯各48G24GB典型功耗150W72W視頻解碼支持路數(shù)多支持路數(shù)相對少適用場景高密度推理、多路視頻分析中等密度推理、單卡部署形態(tài)半高半長半高半長從表里能看出來300V 24G 更像是 300I Duo 的“精簡版”功耗低了一半顯存也少了不少。如果你的業(yè)務(wù)是幾十路視頻流做目標(biāo)檢測300I Duo 更合適如果只是幾路視頻或者單模型推理300V 24G 完全夠用而且功耗低意味著散熱壓力小放在 2U 服務(wù)器里更從容。注意買卡之前一定要確認(rèn)服務(wù)器的主板 BIOS 和電源能不能帶得動。300V 24G 雖然功耗只有 72W但它需要額外的供電接口而且對 PCIe 插槽的版本有要求。我見過有人把卡插到老服務(wù)器上結(jié)果 BIOS 里根本認(rèn)不到設(shè)備折騰半天才發(fā)現(xiàn)是 PCIe 版本不兼容。2.2 為什么選 Atlas 而不是別的方案這個問題很現(xiàn)實。市面上做推理加速的方案不少為什么偏偏選 Atlas我自己的體會是三個原因能效比、國產(chǎn)化需求、以及視頻解碼能力。能效比這塊昇騰 310P 在 INT8 精度下的算力表現(xiàn)相當(dāng)能打而功耗控制得又比較好。對于需要 7x24 小時跑推理的業(yè)務(wù)來說電費是實打?qū)嵉某杀竟牡鸵话胍荒晗聛硎〉碾娰M不是小數(shù)目。視頻解碼能力是另一個容易被忽略的點。Atlas 300V 內(nèi)置了硬件解碼單元支持 H.264 和 H.265 的硬解。這意味著你可以直接把 RTSP 流丟給卡讓卡自己解碼不用 CPU 先軟解再送進(jìn)去。CPU 軟解幾十路 1080P 是很吃力的而硬解幾乎不占 CPU。這一點在做視頻分析類項目時特別關(guān)鍵。至于國產(chǎn)化需求這個不用多解釋很多項目在選型階段就有明確的傾向性要求Atlas 系列在這方面的生態(tài)成熟度是比較高的。2.3 選型時容易踩的坑第一個坑是只看算力不看顯存。有人覺得算力夠就行結(jié)果模型稍微大一點就 OOM。YOLOv5s 這種小模型 24G 綽綽有余但如果你要跑 YOLOv8x 或者更大的模型還要同時跑多個實例24G 就可能緊張。選型時一定要把模型大小、batch size、并發(fā)路數(shù)一起算進(jìn)去。第二個坑是忽略 CPU 和內(nèi)存的配套。加速卡再強(qiáng)數(shù)據(jù)預(yù)處理還是要在 CPU 上做。如果 CPU 太弱預(yù)處理成了瓶頸卡再快也白搭。我的經(jīng)驗是配 Atlas 卡的服務(wù)器CPU 至少要是中端以上的型號內(nèi)存建議 64G 起步。第三個坑是沒確認(rèn)固件版本。Atlas 卡對驅(qū)動和固件版本有匹配要求驅(qū)動版本和 CANN 版本之間也有對應(yīng)關(guān)系。版本不匹配會導(dǎo)致各種奇怪的問題比如設(shè)備識別不到、模型加載失敗、推理結(jié)果異常。裝之前一定要去官方文檔查版本配套表。3. 環(huán)境搭建從裸機(jī)到能跑推理的完整過程3.1 驅(qū)動和固件的安裝順序這一步是很多新手卡住的地方。正確的順序是先裝驅(qū)動再裝固件最后裝 CANN。順序錯了后面全是坑。裝驅(qū)動之前先確認(rèn)系統(tǒng)版本。Atlas 對操作系統(tǒng)有明確的支持列表Ubuntu 18.04、20.04、CentOS 7.6 這些是常見的支持版本。如果你用的是比較新的系統(tǒng)比如 Ubuntu 22.04可能會遇到兼容性問題需要提前查一下。驅(qū)動安裝包一般是個.run文件執(zhí)行的時候要加--install參數(shù)。安裝過程中會提示你確認(rèn)一些選項比如是否安裝 DKMS 模塊建議選是這樣內(nèi)核升級后驅(qū)動能自動重新編譯。固件安裝包通常是.hpm格式用hpm工具來刷。刷固件的時候卡不能處于使用狀態(tài)最好重啟到干凈狀態(tài)再刷。刷完固件要重啟服務(wù)器讓固件生效。提示裝完驅(qū)動后用npu-smi info命令檢查卡是否被識別。如果能看到卡的型號、溫度、功耗等信息說明驅(qū)動裝好了。如果報錯說找不到設(shè)備先檢查卡有沒有插緊再看 BIOS 里 PCIe 設(shè)備有沒有被識別。3.2 CANN 工具包的安裝與配置CANN 是昇騰的計算架構(gòu)相當(dāng)于 CUDA 在英偉達(dá)生態(tài)里的位置。它包含了算子庫、運行時、編譯器等一系列組件。裝 CANN 的時候建議用--install參數(shù)跑安裝腳本它會引導(dǎo)你選擇安裝路徑和組件。裝完之后要配置環(huán)境變量。主要是把 CANN 的庫路徑加到LD_LIBRARY_PATH里把工具鏈路徑加到PATH里。這些在安裝腳本的最后會提示你照著做就行。配置完記得source一下配置文件或者重新登錄終端。驗證 CANN 是否裝好可以跑一下自帶的樣例。CANN 安裝包里一般會有一些 sample編譯運行一下如果能正常輸出結(jié)果說明環(huán)境沒問題。3.3 Python 環(huán)境和推理框架的選擇Atlas 上跑推理Python 環(huán)境建議用 3.7 到 3.9 之間的版本。太新的版本可能有些依賴包還不支持。我一般用 conda 建一個獨立環(huán)境避免和系統(tǒng) Python 混在一起。推理框架這塊主要有兩個選擇MindSpore Lite和AscendCL。MindSpore Lite 更偏向端側(cè)和輕量級部署AscendCL 是更底層的接口靈活性更高但寫起來更麻煩。對于 YOLO 部署來說我推薦用MindX SDK它封裝了 AscendCL 的很多細(xì)節(jié)提供了更上層的 API開發(fā)效率高很多。MindX SDK 里有個mxpi系列插件專門做視頻解碼、推理、后處理這些事。用插件搭 pipeline 的方式比手寫 AscendCL 代碼要快得多。當(dāng)然如果你需要深度定制還是得回到 AscendCL 層面去改。4. 把 YOLO 部署到 Atlas 上的完整實操4.1 模型轉(zhuǎn)換從 PyTorch 到 omYOLO 模型訓(xùn)練出來一般是 PyTorch 的.pt文件Atlas 不能直接跑需要轉(zhuǎn)成.om格式。轉(zhuǎn)換的路徑是PyTorch - ONNX - om。第一步把.pt轉(zhuǎn)成.onnx。這一步在普通的 x86 機(jī)器上就能做用torch.onnx.export函數(shù)。需要注意的是導(dǎo)出的時候要指定opset_version建議用 11 或以上。輸入尺寸要和后面推理時保持一致比如1x3x640x640。第二步用 ATC 工具把 ONNX 轉(zhuǎn)成 om。ATC 是 CANN 自帶的模型轉(zhuǎn)換工具命令大概長這樣atc --modelyolov5s.onnx \ --framework5 \ --outputyolov5s \ --input_formatNCHW \ --input_shapeimages:1,3,640,640 \ --soc_versionAscend310P3 \ --output_typeFP16這里有幾個參數(shù)要特別注意。--soc_version要填對300V 24G 用的是 Ascend310P3填錯了轉(zhuǎn)出來的模型跑不了。--output_type可以選 FP16 或 INT8FP16 精度更高但速度稍慢INT8 更快但需要做量化校準(zhǔn)。第一次跑建議先用 FP16跑通了再考慮 INT8。注意ATC 轉(zhuǎn)換過程中如果報錯說某個算子不支持需要查一下昇騰的算子支持列表。YOLO 里常見的算子像 Focus、SiLU 這些新版本的 CANN 一般都支持了但老版本可能沒有。遇到不支持的算子要么升級 CANN要么改模型結(jié)構(gòu)。4.2 用 MindX SDK 搭推理 pipeline模型轉(zhuǎn)好之后就可以搭推理 pipeline 了。MindX SDK 的 pipeline 是用 JSON 文件描述的里面定義了數(shù)據(jù)從輸入到輸出的流轉(zhuǎn)過程。一個典型的 YOLO 推理 pipeline 大概包含這幾個插件mxpi_videodecoder做視頻解碼mxpi_imageresize做尺寸縮放mxpi_tensorinfer做推理mxpi_objectpostprocessor做后處理。每個插件在 JSON 里配置好參數(shù)串起來就是一條完整的流水線。配置mxpi_tensorinfer的時候要指定 om 模型的路徑、推理的 batch size、以及輸入輸出的 tensor 名稱。這些信息在轉(zhuǎn)模型的時候就能看到ATC 轉(zhuǎn)換完會輸出一個.json文件里面記錄了模型的輸入輸出信息。后處理插件mxpi_objectpostprocessor需要配置 YOLO 的類別數(shù)、置信度閾值、NMS 閾值這些參數(shù)。這些參數(shù)要和訓(xùn)練時保持一致否則檢測結(jié)果會不對。4.3 跑通第一個推理任務(wù)pipeline 配好之后寫一個簡單的 Python 腳本來啟動它。MindX SDK 提供了 Python 接口用StreamManager加載 pipeline 配置文件然后往輸入端口送數(shù)據(jù)從輸出端口取結(jié)果。第一次跑的時候建議先用一張靜態(tài)圖片測試不要一上來就懟視頻流。圖片測試能排除掉解碼和流媒體相關(guān)的問題把焦點放在推理本身。如果圖片能正常檢測出目標(biāo)說明模型轉(zhuǎn)換和 pipeline 配置都沒問題。圖片跑通之后再換成視頻文件測試。視頻文件測試能驗證解碼插件是否正常工作。最后再換成 RTSP 流這一步可能會遇到網(wǎng)絡(luò)延遲、丟包等問題需要調(diào)整解碼插件的緩沖參數(shù)。我自己的習(xí)慣是每換一種輸入源都先用ffprobe或者vlc確認(rèn)一下源本身是正常的排除掉源的問題再查 pipeline。5. 性能調(diào)優(yōu)讓 Atlas 跑得更快更穩(wěn)5.1 模型層面的優(yōu)化模型層面的優(yōu)化是最直接的。量化是首選手段把 FP16 轉(zhuǎn)成 INT8推理速度通常能提升 30% 到 50%。量化需要用校準(zhǔn)數(shù)據(jù)集一般從訓(xùn)練集里抽幾百張圖就夠了。校準(zhǔn)做得好精度損失可以控制在 1% 以內(nèi)。算子融合是另一個手段。ATC 轉(zhuǎn)換的時候會自動做一些融合但有些融合需要手動開啟。比如把 Conv BN ReLU 融合成一個算子能減少內(nèi)存訪問次數(shù)提升速度。輸入尺寸也要權(quán)衡。640x640 是 YOLO 的默認(rèn)尺寸但如果你的目標(biāo)比較大用 416x416 也能檢測出來速度會快不少。反過來如果目標(biāo)很小可能需要 1280x1280速度會慢下來。這個要根據(jù)實際場景去調(diào)。5.2 推理配置的調(diào)優(yōu)batch size 的設(shè)置很關(guān)鍵。batch size 太小卡的算力用不滿batch size 太大顯存可能不夠。我的經(jīng)驗是300V 24G 跑 YOLOv5sbatch size 設(shè) 4 到 8 比較合適。具體設(shè)多少要跑 benchmark 測一下看吞吐和延遲的平衡點在哪里。多實例推理是提升吞吐的另一個辦法。一張卡上可以同時跑多個模型實例每個實例處理一路視頻流。MindX SDK 支持配置多個mxpi_tensorinfer插件每個插件加載同一個模型但用不同的設(shè)備 ID。這樣能充分利用卡的并行能力。線程數(shù)的配置也要注意。解碼、預(yù)處理、推理、后處理這些環(huán)節(jié)如果都用單線程很容易出現(xiàn)某個環(huán)節(jié)成為瓶頸。MindX SDK 的插件可以配置線程數(shù)一般建議解碼和預(yù)處理多配幾個線程推理環(huán)節(jié)根據(jù)卡的實際情況來。5.3 系統(tǒng)層面的調(diào)優(yōu)CPU 頻率策略會影響預(yù)處理速度。把 CPU governor 設(shè)成 performance 模式能避免 CPU 降頻導(dǎo)致的預(yù)處理延遲。內(nèi)存帶寬也是瓶頸之一。如果服務(wù)器內(nèi)存通道沒插滿帶寬上不去數(shù)據(jù)搬運會成為瓶頸。建議把內(nèi)存通道插滿并且用高頻率的內(nèi)存條。PCIe 帶寬在某些場景下也會成為瓶頸尤其是多卡場景。如果卡插在 PCIe 3.0 x8 的插槽上帶寬只有 x16 的一半數(shù)據(jù)搬運速度會受影響。盡量把卡插在 x16 的插槽上。提示調(diào)優(yōu)的時候一定要有基準(zhǔn)測試。每次只改一個參數(shù)測完記錄數(shù)據(jù)再改下一個。同時改多個參數(shù)出了問題都不知道是哪個參數(shù)導(dǎo)致的。6. 常見問題與排查技巧實錄6.1 設(shè)備識別類問題問題npu-smi info報錯說找不到設(shè)備。排查思路先看lspci | grep -i ascend能不能看到卡。如果看不到說明是硬件層面沒識別到檢查卡是否插緊、BIOS 里 PCIe 設(shè)備是否啟用、電源供電是否足夠。如果lspci能看到但npu-smi看不到說明是驅(qū)動問題檢查驅(qū)動版本和固件版本是否匹配。問題驅(qū)動裝完但重啟后設(shè)備又不見了。這通常是 DKMS 模塊沒裝好。檢查/lib/modules/$(uname -r)/下面有沒有昇騰的驅(qū)動模塊。如果沒有重新裝驅(qū)動并確保 DKMS 選項被選中。6.2 模型轉(zhuǎn)換類問題問題ATC 轉(zhuǎn)換報錯提示算子不支持。先查昇騰的算子支持列表確認(rèn)這個算子在當(dāng)前 CANN 版本里是否支持。如果不支持考慮升級 CANN或者修改模型結(jié)構(gòu)用支持的算子替換掉不支持的。問題轉(zhuǎn)換成功但推理結(jié)果不對。檢查輸入輸出的 tensor 名稱和順序是否和 pipeline 里配置的一致。ATC 轉(zhuǎn)換完會生成一個.json文件里面記錄了輸入輸出的詳細(xì)信息對照著檢查。另外檢查預(yù)處理是否和訓(xùn)練時一致比如歸一化的均值方差、通道順序這些。6.3 推理運行類問題問題推理速度比預(yù)期慢很多。先看npu-smi info里的利用率如果利用率很低說明卡在等數(shù)據(jù)瓶頸在預(yù)處理或數(shù)據(jù)傳輸。如果利用率很高但速度還是慢可能是模型本身的問題考慮量化或換更小的模型。問題跑一段時間后報顯存不足。檢查是否有內(nèi)存泄漏比如每次推理都創(chuàng)建新的 tensor 而沒有釋放。另外檢查 batch size 和并發(fā)路數(shù)是否超過了卡的承載能力。6.4 常見問題速查表現(xiàn)象可能原因排查方向設(shè)備識別不到硬件未插緊、BIOS未啟用、驅(qū)動未裝lspci、BIOS設(shè)置、驅(qū)動版本模型轉(zhuǎn)換失敗算子不支持、參數(shù)填錯算子支持列表、soc_version推理結(jié)果異常預(yù)處理不一致、tensor名稱錯對照json文件、檢查歸一化速度慢預(yù)處理瓶頸、batch太小npu-smi利用率、benchmark測試顯存不足batch太大、內(nèi)存泄漏減小batch、檢查釋放邏輯7. 一些實操心得和后續(xù)擴(kuò)展方向踩過幾次坑之后我最大的體會是Atlas 部署這件事難的不是推理本身而是環(huán)境搭建和模型轉(zhuǎn)換。推理 pipeline 一旦跑通后面就是調(diào)參的事。但環(huán)境搭建和模型轉(zhuǎn)換這兩個環(huán)節(jié)版本匹配、參數(shù)配置、算子支持每一個細(xì)節(jié)都可能讓你卡半天。我的建議是拿到卡之后不要急著上業(yè)務(wù)模型先用官方提供的樣例跑一遍。樣例跑通了說明環(huán)境沒問題再換自己的模型。換模型的時候先用最簡單的模型比如 ResNet50測試確認(rèn)轉(zhuǎn)換和推理鏈路沒問題再上 YOLO 這種復(fù)雜的模型。另外文檔一定要看官方的最新版。昇騰的生態(tài)更新很快很多老教程里的命令和參數(shù)在新版本里已經(jīng)變了。我見過有人照著兩年前的博客裝驅(qū)動結(jié)果版本對不上折騰了一整天。后續(xù)如果要把這套東西用到生產(chǎn)環(huán)境還有幾個方向可以擴(kuò)展。一是多卡并行把多張卡組成一個推理集群用 MindX SDK 的分布式能力做負(fù)載均衡。二是模型熱更新在不重啟服務(wù)的情況下替換 om 模型這對業(yè)務(wù)連續(xù)性很重要。三是監(jiān)控告警把卡的利用率、溫度、顯存占用這些指標(biāo)接入監(jiān)控系統(tǒng)出問題能第一時間發(fā)現(xiàn)。最后分享一個小技巧如果你不確定某個參數(shù)該怎么設(shè)先用默認(rèn)值跑一遍然后用npu-smi和top觀察資源占用根據(jù)瓶頸去調(diào)。調(diào)優(yōu)這件事沒有銀彈都是測出來的。