制作網(wǎng)站需要錢嗎,小吃網(wǎng)站建設(shè)規(guī)劃書,建設(shè)項(xiàng)目信息查詢,個人網(wǎng)站怎么快速推廣小模型遷移到昇騰怎么才能比 NVIDIA 更快#xff1f;一次真實(shí)踩坑復(fù)盤告訴你答案 小模型遷移到昇騰#xff0c;可能遇到速度變慢的情況#xff0c;一般會以為是硬件差異導(dǎo)致的#xff0c;尤其是和 NVIDIA 的 4090、A100 這種 GPU 比。此次遷移一個不到 1B 的小模型后…小模型遷移到昇騰怎么才能比 NVIDIA 更快一次真實(shí)踩坑復(fù)盤告訴你答案小模型遷移到昇騰可能遇到速度變慢的情況一般會以為是硬件差異導(dǎo)致的尤其是和 NVIDIA 的 4090、A100 這種 GPU 比。此次遷移一個不到 1B 的小模型后才發(fā)現(xiàn)可能是因?yàn)闆]正確調(diào)優(yōu)。1. 遷移后推理從 1 秒變成 1.5 秒基于 LLM 框架在 NVIDIA 機(jī)器上推理該小模型時單次推理耗時約1 秒當(dāng)遷移到昇騰300I Duo后測出來推理 to(cpu)需要1.5s從打印出來看上去 to(cpu) 占了將近一半。觀察代碼進(jìn)行初步推測可能是HostBound 或者 NPU→CPU 的下發(fā)速度拖慢了。先試了異步 to(cpu)提前 sync和手動減少拷貝次數(shù)等方法嘗試解決問題……幾乎都沒有明顯改善只能采取更細(xì)致的方法。2. 使用Profile簡單的調(diào)整無法解決問題便轉(zhuǎn)向使用 Ascend PyTorch Profiler 進(jìn)行深入的性能分析。通過在代碼中插入 torch_npu.profiler.profile() 接口能夠采集推理過程中每個階段的時間數(shù)據(jù)。為我們提供了關(guān)于推理過程瓶頸的詳細(xì)視圖尤其是在NPU → CPU 數(shù)據(jù)傳輸這一環(huán)節(jié)。2.1 實(shí)際 Profiling 過程與結(jié)果驗(yàn)證Notebook 環(huán)境說明由于本地?zé)o昇騰硬件本次實(shí)驗(yàn)基于云電腦提供的 Ascend Notebook 環(huán)境完成。該環(huán)境中僅 Notebook 實(shí)例具備 NPU 訪問能力因此模型運(yùn)行與 Profiling 均在 Notebook 內(nèi)完成而 MindStudio Insight 用于離線分析 trace 文件。2.1.1 Ascend NPU 環(huán)境確認(rèn)在 Notebook 中通過torch_npu接口確認(rèn)當(dāng)前實(shí)例已成功識別 Ascend NPU 設(shè)備2.1.2 Profiler 數(shù)據(jù)采集在 Notebook 中使用torch_npu.profiler.profile對一次最小計(jì)算任務(wù)進(jìn)行 Profiling用于驗(yàn)證 CPU/NPU 調(diào)度與 Timeline 行為。這里有幾個需要注意的點(diǎn)當(dāng)只有一個 step 時調(diào)用prof.step()反而可能采集不到數(shù)據(jù)此時需要將其刪除必要時可在stop前額外插入一次同步torch_npu.npu.synchronize()讓 CPU/NPU 的 timeline 對齊否則會以為“Profiler 不工作”但實(shí)際上是采集策略沒踩對點(diǎn)。在 Profiling 結(jié)束后Notebook 中成功生成trace_view.json文件為后續(xù) Timeline 分析提供基礎(chǔ)數(shù)據(jù)。3. 把 trace_view.json 丟進(jìn) MindStudio查看先去昇騰社區(qū)下載MindStudioInsight社區(qū)版打開軟件后將生成的trace_view.jsonimport 進(jìn)入 有些人打開json文件時可能遇到直接在網(wǎng)頁打開的情況這是語言特性只需要按ctrls就可以保存了MindStudio Insight離線分析無需 NPU在 Timeline 視圖中觀察 CPU 與 NPU 的執(zhí)行關(guān)系。從 Timeline 中可以觀察到CPU 首先發(fā)起算子調(diào)度NPU 隨后異步開始執(zhí)行計(jì)算任務(wù)。在同步點(diǎn)處CPU 與 NPU 基本同時結(jié)束。而在輕量 workload 場景下由于算子數(shù)量與執(zhí)行時間有限AI Core 頻率與 Ascend Hardware 的活躍區(qū)間較短屬于正?，F(xiàn)象。需要說明的是該示例為最小計(jì)算任務(wù)并非完整大模型推理場景因此 Timeline 形態(tài)與真實(shí)模型存在差異但 CPU/NPU 的調(diào)度關(guān)系與等待行為具有一致的分析意義。可以發(fā)現(xiàn)to(cpu)本身只消耗了非常少的時間真正的耗時來自模型推理尚未結(jié)束這一階段。也就是說之前看到的to(cpu)是個假象。真正發(fā)生的是模型推理NPU 上尚未完成 → to(cpu) 必須等待未完成的推理結(jié)束 → 看起來像 to(cpu) 很慢在 Notebook 的最小 Profiling 示例中也可以觀察到類似的 CPU/NPU 異步行為CPU 的時間感知往往無法反映 NPU 上的真實(shí)執(zhí)行進(jìn)度只有通過 Timeline 才能確認(rèn)等待關(guān)系的真實(shí)來源。這也解釋了為什么前文提到的異步to(cpu)、提前sync以及減少拷貝次數(shù)等方法并未起作用。因?yàn)榇蛴r間是 CPU 層的感知而 NPU 的真實(shí)執(zhí)行進(jìn)度你看不到除非 profile。4. 優(yōu)化推理定位到問題后接下來就分成兩條路方案 A使用昇騰專門給小模型優(yōu)化過的框架對于小模型昇騰已經(jīng)有專門做過優(yōu)化的推理框架torchairhttps://gitee.com/ascend/torchair它主要是把小模型的 kernel 調(diào)度、流水線結(jié)構(gòu)、算子拆分做了深度優(yōu)化因?yàn)樾∧Ｐ蜎]有大模型那種巨量算子來填滿 NPU所以需要更細(xì)粒度的 pipeline 調(diào)度來減少碎片、減少 HostBound、減少 bubble。它的 latency 效率高于pytorch的默認(rèn)實(shí)現(xiàn)方式。方案 BPyTorch手工調(diào)優(yōu)這是此次主要路線,核心優(yōu)化項(xiàng)有兩個1避免npu等待cpu通過設(shè)置環(huán)境變量 TASK_QUEUE_ENABLE2優(yōu)化計(jì)算任務(wù)與調(diào)度之間的流水線減少 HostBound使 NPU 能夠連續(xù)執(zhí)行計(jì)算任務(wù)不會出現(xiàn)長時間的等待空洞。export TASK_QUEUE_ENABLE2它能優(yōu)化計(jì)算與調(diào)度的 pipeline減少 HostBound 讓 NPU 連續(xù)執(zhí)行 Kernel不出現(xiàn)等待執(zhí)行的空洞很像 CUDA Graph但作用機(jī)制不同這2個策略舊版本無效需要將驅(qū)動固件和cann包升級到較新的版本。2禁用在線算子編譯避免每次都重新編 JIT Kernel在 PyTorch 中JIT 編譯會導(dǎo)致首次執(zhí)行時推理延遲翻倍。禁用 JIT 編譯后所有推理任務(wù)的內(nèi)核將直接調(diào)用避免了每次執(zhí)行時都需要重新編譯的開銷。torch_npu.npu.set_compile_mode(jit_compileFalse) torch_npu.npu.config.allow_internal_format False如果你的模型有很多動態(tài) shape 或第一次執(zhí)行需要 JIT會導(dǎo)致延遲直接翻倍。禁掉之后全流程的 Kernel 調(diào)用穩(wěn)定很多。5. 演示結(jié)果完成以上優(yōu)化后重新測了一次平臺推理時延NVIDIA1B 小模型~1.0 sAscend遷移前~1.5 sAscend優(yōu)化后0.7 s可以看出在完成針對 HostBound 與在線編譯問題的調(diào)優(yōu)后整體推理性能得到明顯改善。盡管本文中的 Notebook 示例并未直接復(fù)現(xiàn)完整模型的端到端時延對比但通過 Profiler 與 Timeline 的分析可以確認(rèn)HostBound、流水線空洞以及在線算子編譯確實(shí)是小模型遷移到昇騰后常見的性能瓶頸來源。在實(shí)際項(xiàng)目中通過開啟 TASK_QUEUE 并禁用 JIT 編譯上述問題可以明顯緩解推理時延也能顯著下降。