微調(diào)在昇騰與CUDA的實(shí)戰(zhàn))
1. 項(xiàng)目背景為什么要折騰多模態(tài)微調(diào)最近這半年多模態(tài)大模型的應(yīng)用需求暴漲尤其是像Qwen2.5-VL這種既能看圖又能理解文本的模型幾乎成了很多業(yè)務(wù)場景的標(biāo)配底座。我所在的團(tuán)隊(duì)也接到一個具體需求需要讓模型在某一類特定風(fēng)格的圖片上做細(xì)粒度的圖文理解比如工業(yè)圖紙上的標(biāo)注識別、特定產(chǎn)品圖上的屬性抽取這類場景用通用底座模型直接推理效果總差那么一截所以微調(diào)是繞不開的路徑。一開始我們理所當(dāng)然想用LoRA畢竟生態(tài)成熟、資料多、踩坑的人也多遇到問題容易搜到答案。但在實(shí)際推進(jìn)過程中LoRA在昇騰910B上暴露出一些讓人頭疼的兼容性問題反倒是后來切換到的OFTOrthogonal Finetuning方案在昇騰上跑得意外順暢最終效果也更好。這篇文章就把這段從LoRA到OFT的遷移過程、兩個硬件平臺的適配差異、以及過程中積累的踩坑經(jīng)驗(yàn)完整記錄下來給準(zhǔn)備做Qwen2.5-VL微調(diào)、尤其是需要跨GPU平臺CUDA和CANN折騰的朋友一個參考。閱讀這篇內(nèi)容之前默認(rèn)你已經(jīng)了解什么是LoRA、什么是Qwen2.5-VL、也大概知道transformers和peft庫的基本用法。如果你還沒接觸過這些建議先跑通一遍推理流程再來看微調(diào)否則部分術(shù)語和參數(shù)解釋會顯得比較跳躍。文章會覆蓋從環(huán)境配置到訓(xùn)練調(diào)優(yōu)再到問題排查的完整鏈路適合正在準(zhǔn)備做多模態(tài)微調(diào)、或者已經(jīng)在微調(diào)路上被平臺兼容性折磨的工程師閱讀。2. 方案選型LoRA、OFT與多模態(tài)模型的適配邏輯2.1 LoRA為什么成為首選以及它到底改了什么LoRA的核心邏輯是通過低秩分解來模擬權(quán)重更新。原始權(quán)重矩陣W是d×d的規(guī)模LoRA把它拆成一個d×r的矩陣A和一個r×d的矩陣B訓(xùn)練時只更新A和B原始權(quán)重完全凍結(jié)。當(dāng)r遠(yuǎn)小于d時可訓(xùn)練參數(shù)量就從d2縮減到2×d×r通常只有原來的0.1%到1%。這個思路在大語言模型上被驗(yàn)證得非常好原因是語言模型的權(quán)重矩陣本身存在著較低的內(nèi)在秩用低秩擾動去適配新任務(wù)完全夠用。但在多模態(tài)模型上情況稍微復(fù)雜一些。Qwen2.5-VL這類模型除了文本的attention層和FFN層還有視覺編碼器vision encoder和跨模態(tài)連接模塊這些模塊的權(quán)重特性各不相同。視覺編碼器提取的是圖像的底層視覺特征它對任務(wù)適配的敏感度和文本層不一樣如果直接套用語言模型的LoRA策略往往會出現(xiàn)視覺特征適配不足的問題。我剛開始做的時候就是按慣性把LoRA加在所有的query、key、value和output投影層上結(jié)果在昇騰上跑了兩輪loss降得倒是快但驗(yàn)證集上的指標(biāo)提升非常有限。后來仔細(xì)分析才發(fā)現(xiàn)視覺編碼器部分我根本沒加LoRA模塊模型微調(diào)的實(shí)際上是文本側(cè)對視覺特征的“解讀方式”而不是視覺特征本身。這解釋了為什么在涉及細(xì)粒度視覺理解的任務(wù)上表現(xiàn)不佳。這是LoRA方案第一個需要注意的地方多模態(tài)模型微調(diào)必須考慮視覺和文本兩側(cè)的適配范圍。2.2 OFT是什么為什么它能解決LoRA的局限性O(shè)FT的全稱是Orthogonal Finetuning它和LoRA的底層思路不同。LoRA是在原始權(quán)重上加一個低秩增量相當(dāng)于允許權(quán)重向量在任意方向上發(fā)生偏移。而OFT做的事情是學(xué)習(xí)一組正交變換矩陣保持特征向量的范數(shù)和相互之間的夾角不變的前提下旋轉(zhuǎn)特征空間。專業(yè)術(shù)語可能不好直接理解我用人話解釋一下LoRA把特征空間的形狀改了OFT只是把特征空間轉(zhuǎn)了個角度。從數(shù)學(xué)性質(zhì)上講OFT對特征分布的擾動更小特別適合視覺編碼器這類需要保持特征語義穩(wěn)定性的模塊。這是因?yàn)檎蛔儞Q不會改變特征之間的相對位置模型在預(yù)訓(xùn)練階段學(xué)到的知識不會被破壞得太狠對于需要高精度語義對齊的多模態(tài)任務(wù)來說這種“溫和”的特性反而更有價值。在Qwen2.5-VL上OFT的一個經(jīng)典用法是只對視覺編碼器的attention層做正交微調(diào)文本部分保持凍結(jié)。這樣一來模型的文本理解能力完全不動只調(diào)整視覺特征的空間排布以適配目標(biāo)任務(wù)。在我實(shí)際測試的業(yè)務(wù)場景里OFT在視覺側(cè)的效果普遍比LoRA高2到3個點(diǎn)尤其是在細(xì)粒度屬性識別任務(wù)上優(yōu)勢更明顯。但OFT也有代價計(jì)算量比LoRA大。正交約束的更新過程需要額外做矩陣正交化前向和反向的計(jì)算量都會增加。在4090上跑的時候體感不明顯但在昇騰910B上由于CANN和CUDA的算子實(shí)現(xiàn)差異OFT的準(zhǔn)備階段多花了將近兩倍的工程適配時間。這部分后面詳細(xì)講。2.3 兩個平臺的選型決策團(tuán)隊(duì)手頭的算力資源比較特殊一臺GPU服務(wù)器用的是RTX 4090另一臺是國產(chǎn)加速卡的昇騰910B。這兩臺機(jī)器都要充分利用所以從項(xiàng)目一開始就要考慮代碼能否在兩套環(huán)境上無縫切換。4090的優(yōu)勢非常明顯CUDA生態(tài)成熟PyTorch的GPU支持開箱即用無論是transformers還是peft庫都能直接跑通。昇騰910B則麻煩得多雖然算力指標(biāo)不差但它的底層計(jì)算架構(gòu)是達(dá)·芬奇架構(gòu)通過CANNCompute Architecture for Neural Networks開發(fā)套件來提供PyTorch適配層。PyTorch生態(tài)中的很多算子昇騰上不一定有高效的實(shí)現(xiàn)甚至某些操作需要手動改寫為昇騰支持的算子才能運(yùn)行。當(dāng)時選型時的策略是先讓LoRA在4090上驗(yàn)證業(yè)務(wù)效果確認(rèn)微調(diào)路線的可行性再遷移到昇騰上做生產(chǎn)環(huán)境的規(guī)?；?xùn)練。事實(shí)證明這個策略是正確的因?yàn)長oRA在CUDA上跑通只需要一天而昇騰環(huán)境上的環(huán)境適配就花掉了四天時間期間還踩了不少算子兼容性的坑。3. 硬件環(huán)境與依賴配置昇騰910B和4090的差異化適配3.1 4090環(huán)境搭建4090的環(huán)境相對無腦找個干凈的Ubuntu 20.04系統(tǒng)裝好NVIDIA驅(qū)動和CUDA 12.x然后創(chuàng)建conda環(huán)境裝PyTorch 2.x和對應(yīng)的tensorflow、transformers、peft、accelerate庫就能直接開始跑。唯一要注意的是4090的顯存是24GBQwen2.5-VL的微調(diào)如果帶上視覺編碼器的梯度batch size稍微大一點(diǎn)就容易爆顯存這一點(diǎn)后面細(xì)說。4090環(huán)境我推薦直接用官方預(yù)編譯的PyTorch wheel包省去源碼編譯的時間。CUDA版本最好鎖定12.1或12.4因?yàn)樾掳娴腜yTorch對CUDA版本有一定要求裝錯了版本輕則跑不了GPU算子重則整個環(huán)境都容易出問題。確認(rèn)一切都裝好之后可以用一行簡單的代碼驗(yàn)證GPU可用性import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))輸出都是True和GeForce RTX 4090就說明環(huán)境沒問題。還有一個容易被忽略的細(xì)節(jié)是要確認(rèn)cuDNN的版本和PyTorch編譯時使用的版本兼容否則某些卷積類的算子在推理時會拋出奇怪的錯誤信息。3.2 昇騰910B環(huán)境搭建昇騰環(huán)境的搭建就麻煩多了。首先要確認(rèn)設(shè)備型號昇騰910B有不同規(guī)格算力差異很大需要先檢查NPU信息。然后安裝昇騰的固件和驅(qū)動版本號需要和硬件匹配否則后邊創(chuàng)建context就會報錯。接下來是CANN工具包這個是最核心的部分它包含算子庫、編譯器、運(yùn)行環(huán)境以及PyTorch適配插件。昇騰上跑PyTorch的核心是torch_npu這個插件它通過PyTorch的插件機(jī)制將算子轉(zhuǎn)發(fā)到CANN實(shí)現(xiàn)上使大部分PyTorch代碼可以無縫運(yùn)行在昇騰NPU上。安裝方式是用pip安裝torch-npu包但需要注意版本必須和PyTorch嚴(yán)格對應(yīng)比如PyTorch 2.1.0對應(yīng)torch_npu某個特定版本版本不匹配會導(dǎo)致import時報錯。裝完之后用以下命令驗(yàn)證環(huán)境python -c import torch, torch_npu; print(torch.npu.is_available()) python -c import torch; print(torch.npu.get_device_name(0))如果輸出True和類似Ascend910B的字符串說明NPU環(huán)境可以正常使用。但這里要提醒一句能import不代表所有算子都能跑。Qwen2.5-VL的模型中包含很多復(fù)雜的attention實(shí)現(xiàn)某些算子比如某些flash attention的實(shí)現(xiàn)在昇騰上可能不存在直接對應(yīng)的高效算子需要回退到慢速的普通實(shí)現(xiàn)甚至某些情況下需要手動改代碼。這個是昇騰適配中最耗時的地方后面會有專門的小節(jié)講。3.3 代碼層面的雙平臺兼容技巧為了讓同一份代碼既能在4090上跑又能在昇騰上跑我在項(xiàng)目里加了一個設(shè)備檢測模塊思路很簡單先嘗試import torch_npu如果成功就使用AscendNPU設(shè)備否則回退到CUDA。def get_device(): import torch try: import torch_npu if torch.npu.is_available(): return npu except ImportError: pass if torch.cuda.is_available(): return cuda return cpu有了這個設(shè)備判斷之后所有涉及device的操作都需要改為動態(tài)獲取比如model.to(device)、inputs.to(device)等。還有一個細(xì)節(jié)是數(shù)據(jù)加載器的pin_memory參數(shù)在昇騰上并不一定被支持如果寫上容易導(dǎo)致打數(shù)據(jù)時崩潰所以要根據(jù)平臺動態(tài)設(shè)置。卡在昇騰上的一個常見錯誤就是pin_memoryTrue導(dǎo)致Dataloader在取數(shù)據(jù)時拋錯改成pin_memoryFalse后問題消失。還有一個比較隱蔽的問題是隨機(jī)數(shù)種子。昇騰NPU的隨機(jī)數(shù)生成機(jī)制和CUDA不完全一樣同樣的seed在不同平臺上生成的隨機(jī)序列可能不同。為了做跨平臺的對比實(shí)驗(yàn)最好在訓(xùn)練腳本里同時固定Python、NumPy以及框架層面的隨機(jī)種子并且把數(shù)據(jù)加載的shuffle邏輯也控制住否則兩個平臺的實(shí)驗(yàn)起點(diǎn)不同效果對比就失真了。我在做效果對比時因?yàn)檫@個問題吃過暗虧重跑了幾輪實(shí)驗(yàn)才意識到。4. LoRA微調(diào)實(shí)戰(zhàn)參數(shù)設(shè)置、訓(xùn)練流程與4090上的效果驗(yàn)證4.1 數(shù)據(jù)集準(zhǔn)備這次微調(diào)任務(wù)用的數(shù)據(jù)是某工業(yè)場景下的一批產(chǎn)品圖片每張圖片對應(yīng)一條文本描述描述中包含產(chǎn)品編號、顏色、瑕疵類型三個屬性。數(shù)據(jù)總量大約是2萬條訓(xùn)練集1.6萬、驗(yàn)證集4000。圖片分辨率統(tǒng)一resize到448×448對應(yīng)Qwen2.5-VL的視覺塔輸入尺寸。數(shù)據(jù)格式上參考了Qwen2.5-VL官方微調(diào)的格式用JSON組織每條數(shù)據(jù)就是一張圖片加一段對話文本。需要注意的細(xì)節(jié)是圖片路徑的處理方式不要在數(shù)據(jù)集中使用絕對路徑否則遷移到昇騰機(jī)器時全部要重寫。我用的是相對路徑配合項(xiàng)目根目錄拼接這樣同一份數(shù)據(jù)在4090和昇騰上都能直接讀取。這個習(xí)慣在后續(xù)跨機(jī)器實(shí)驗(yàn)時省了不少事。還有一個同樣重要的點(diǎn)是數(shù)據(jù)預(yù)處理的像素值歸一化問題。Qwen2.5-VL的視覺編碼器要求輸入圖像經(jīng)過特定標(biāo)準(zhǔn)的歸一化處理使用ImageNet的mean和std。如果數(shù)據(jù)集中存在不同來源的圖片有的圖片已經(jīng)做過歸一化有的沒有混合在一起訓(xùn)練會導(dǎo)致loss震蕩得非常厲害。建議用transform的預(yù)處理器一步到位不要在訓(xùn)練代碼里手動歸一化否則容易在數(shù)據(jù)加載時出錯。from transformers import Qwen2_5_VLProcessor processor Qwen2_5_VLProcessor.from_pretrained(model_path)數(shù)據(jù)加載時會自動完成圖片預(yù)處理、token化、padding等操作在數(shù)據(jù)集的getitem方法里調(diào)用processor處理文本和圖片即可。要注意的是processor返回的tensor類型、維度要和模型的forward輸入一致特別是多模態(tài)模型的輸入格式不同版本之間可能有細(xì)微差異。4.2 LoRA參數(shù)選擇與訓(xùn)練細(xì)節(jié)在4090上做LoRA微調(diào)時我初始的配置是LoRA的r設(shè)為32alpha設(shè)為64alpha是r的兩倍這是一個常用的初始比例應(yīng)用目標(biāo)模塊選擇query、key、value、output投影層視覺編碼器不參與LoRA使用bf16精度學(xué)習(xí)率為2e-4使用余弦退火調(diào)度器batch size為8梯度累積4步訓(xùn)練3個epoch剛開始跑的時候loss曲線下降很快前500步從2.1降到0.8左右但驗(yàn)證集上的指標(biāo)提升不明顯。仔細(xì)排查后發(fā)現(xiàn)問題出在LoRA的作用范圍上也就是前面提到的“只修改了文本側(cè)對視覺特征的解讀方式?jīng)]修改視覺特征本身”。解決方案是將視覺編碼器的部分層也納入LoRA作用范圍。具體操作比較簡單peft庫的target_modules參數(shù)支持傳入包含視覺層名稱的列表。Qwen2.5-VL的視覺編碼器層命名規(guī)律是visual.blocks我把visual.blocks.*.attn.qkv和visual.blocks.*.attn.proj都加進(jìn)去了。這樣視覺側(cè)和文本側(cè)同時做低秩適配驗(yàn)證集上原先表現(xiàn)不好的細(xì)粒度屬性識別任務(wù)開始有明顯起色。從配置參數(shù)上看可訓(xùn)練參數(shù)從約0.4%增加到約0.9%。這里有一個重要經(jīng)驗(yàn)多模態(tài)模型的LoRA微調(diào)不能只盯著文本側(cè)視覺編碼器的適配范圍同樣關(guān)鍵。如果視覺特征沒有被有效調(diào)整模型對目標(biāo)任務(wù)中的特殊視覺模式仍然是“盲”的。但同時也不能把所有視覺層都放開因?yàn)橐曈X編碼器參數(shù)體量大全放開會導(dǎo)致顯存占用急劇上升而且容易過擬合。需要找到一個平衡點(diǎn)通常的做法是只對視覺編碼器的后半部分深層做LoRA淺層保持凍結(jié)。我最后采用的是最后六層視覺block參與LoRA訓(xùn)練效果和性能平衡最好。4.3 4090訓(xùn)練過程記錄24GB顯存的4090訓(xùn)練Qwen2.5-VL如果不做任何優(yōu)化batch size最多只能開到4左右。我采用batch size8、gradient_accumulation_steps4的方式相當(dāng)于每16個樣本更新一次梯度顯存峰值大約在21GB上下。訓(xùn)練過程比較穩(wěn)定loss從2.1降到最后0.4左右驗(yàn)證集準(zhǔn)確率從77%提升到89.5%。訓(xùn)練總時長約6小時3個epoch總計(jì)約2400步。這個效果已經(jīng)證明了微調(diào)路線是可行的。但訓(xùn)練過程中也遇到一個有意思的現(xiàn)象當(dāng)r值從32降到8之后效果會有明顯下降說明這個業(yè)務(wù)場景的領(lǐng)域知識量較大低秩表征不夠用。這說明在多模態(tài)任務(wù)中不能無腦把r設(shè)為小值尤其是視覺側(cè)的特征適配需要更大的自由度。4090上的完整跑通讓我松了一口氣接下來就是最難的昇騰遷移過程。5. OFT的引入從LoRA到OFT的動機(jī)與關(guān)鍵改造5.1 昇騰上的LoRA適配難題遷移到昇騰910B的第一個版本直接用4090上訓(xùn)練好的LoRA配置修改設(shè)備類型后用torch_npu跑。結(jié)果第一輪就遇到了算子不兼容的問題主要卡在視覺編碼器的某些attention算子上。昇騰的CANN算子庫覆蓋范圍雖然很廣但依然有部分算子的性能極差甚至直接不支持。其中最大的瓶頸是flash attention。Qwen2.5-VL的官方實(shí)現(xiàn)里vision encoder的self-attention默認(rèn)用的是flash attention加速這個算子在昇騰上要么不支持要么自動回退到了普通attention實(shí)現(xiàn)。普通attention在昇騰上跑得極慢一次前向加反向的計(jì)算時間比4090多了將近3倍。更麻煩的是某些版本的torch_npu對scaled_dot_product_attention的支持不完善會出現(xiàn)數(shù)值錯誤的情況loss直接變成NaN。排查了一整天才定位到是flash attention回退問題。解決方案是在模型初始化時關(guān)閉flash attention強(qiáng)制使用普通的attention實(shí)現(xiàn)。Qwen2.5-VL的模型初始化參數(shù)里有attn_implementation這個選項(xiàng)設(shè)置為eager即可。但這也帶來了訓(xùn)練速度的明顯下降昇騰上的迭代速度比4090慢了大約40%。為了彌補(bǔ)這個性能差距我們嘗試了多種方案最后轉(zhuǎn)向OFT也是考慮到OFT對視覺編碼器的適配方式更“溫和”也許能減少一些算子的復(fù)雜性。另一個昇騰上LoRA容易踩的坑是梯度累積和混合精度。昇騰上的自動混合精度策略和NVIDIA不一樣默認(rèn)情況下PyTorch的bf16在昇騰上會產(chǎn)生大量數(shù)值不穩(wěn)定的情況。這是因?yàn)闀N騰的bf16計(jì)算精度在某些算子實(shí)現(xiàn)上不如CUDA那么成熟存在精度截?cái)嗾`差累積到梯度上會導(dǎo)致loss在后期震蕩明顯。解決方案是改用fp16加動態(tài)loss scaling這個在昇騰上情緒穩(wěn)定但需要額外調(diào)試loss scaling參數(shù)否則很容易出現(xiàn)underflow或者overflow。5.2 OFT原理回顧與選型判斷在昇騰的適配過程中我們順便調(diào)研了一下OFT在昇騰上的可行性。OFT這個名字很早就有了但在多模態(tài)領(lǐng)域應(yīng)用不多之前主要是用在圖像生成模型和diffusion模型的微調(diào)里。本質(zhì)上OFT是學(xué)習(xí)一個正交變換而正交變換可以用一個上三角矩陣的QR分解或者Cayley變換來參數(shù)化保證變換的正交性。Qwen2.5-VL的模型結(jié)構(gòu)里視覺編碼器的每一層都有一個輸出投影層OFT可以直接作用于這個投影層的權(quán)重上。相比LoRAOFT的優(yōu)勢在于它不改變特征向量的長度和夾角對于視覺特征這種語義高度密集的表征來說OFT的微調(diào)更安全不容易破壞預(yù)訓(xùn)練模型已經(jīng)建立好的特征空間結(jié)構(gòu)。同時OFT的可訓(xùn)練參數(shù)規(guī)模比LoRA更小這也在一定程度上緩解了昇騰上訓(xùn)練速度慢的問題。讓我下決心從LoRA切到OFT的另外一個關(guān)鍵原因是昇騰的算子兼容性。LoRA的實(shí)現(xiàn)需要用到多個小的矩陣乘法和加法在昇騰上算子調(diào)度比較頻繁每一步的kernel launch開銷很高。而OFT的實(shí)現(xiàn)是少數(shù)幾個較大規(guī)模的正交變換算子數(shù)量更少昇騰上的執(zhí)行效率反而更好。這是一個很有意思的反轉(zhuǎn)在4090上LoRA通過優(yōu)化過的CUDA算子可以跑得非常快但在昇騰上由于算子調(diào)度開銷更大反倒是OFT這種計(jì)算模式更高效。5.3 從LoRA切換到OFT的具體代碼改造OFT的實(shí)現(xiàn)可以用現(xiàn)成的庫也可以用PyTorch自己實(shí)現(xiàn)。我們采用的是自實(shí)現(xiàn)方案主要是為了靈活控制變換層的作用范圍。核心代碼如下import torch import torch.nn as nn import torch.nn.functional as F class OFTLayer(nn.Module): def __init__(self, dim, r, deviceNone): super().__init__() self.device device self.r r self.Q nn.Parameter(torch.randn(dim, r, devicedevice)) self.P nn.Parameter(torch.randn(r, dim, devicedevice)) def forward(self, x): # x: [batch, seq, dim] R self.get_orthogonal_matrix() return torch.matmul(x, R) def get_orthogonal_matrix(self): # Q和P的乘積經(jīng)過QR分解得到正交矩陣 A torch.matmul(self.Q, self.P) Q, R torch.linalg.qr(A) # 確保構(gòu)造出的矩陣是正交的 return Q[:, :self.r] Q[:, :self.r].T應(yīng)用方式是找到Qwen2.5-VL模型中視覺編碼器的輸出投影層用OFTLayer包一層替換原來的權(quán)重計(jì)算邏輯。實(shí)現(xiàn)起來思路清晰但有一個細(xì)節(jié)Qwen2.5-VL的模型結(jié)構(gòu)和老版本Qwen-VL不完全一樣視覺編碼器內(nèi)部有一些層的名字變了需要打印model結(jié)構(gòu)后一一確認(rèn)。需要注意的關(guān)鍵點(diǎn)是正交矩陣的初始化方式。如果直接隨機(jī)初始化Q和POFTLayer剛開始可能會輸出非常大的數(shù)值因?yàn)檎痪仃嚨淖V范數(shù)可能大于1導(dǎo)致訓(xùn)練初期loss激增。解決方法是讓Q初始化為接近單位矩陣的結(jié)構(gòu)最簡單的做法是把Q初始化為單位矩陣的一小部分加少量噪聲同時把P初始化為接近零的小值。這樣初始階段OFTLayer近似于恒等映射不會對預(yù)訓(xùn)練模型的輸出產(chǎn)生劇烈擾動。5.4 OFT在昇騰上的訓(xùn)練參數(shù)與表現(xiàn)OFT的引入顯著改善了昇騰上的訓(xùn)練體驗(yàn)。首先是速度問題OFT的算子數(shù)量少昇騰的kernel調(diào)度開銷不再成為瓶頸迭代速度從LoRA的每秒0.8步提升到每秒1.1步提升約37%。其次是數(shù)值穩(wěn)定性O(shè)FT的正交性質(zhì)讓梯度的傳播更加平穩(wěn)loss曲線沒有出現(xiàn)性能波動也不再出現(xiàn)NaN的情況。從效果上看OFT在昇騰上的最終驗(yàn)證集準(zhǔn)確率達(dá)到了91.8%比LoRA在4090上的最佳效果89.5%還高2.3個百分點(diǎn)。這個結(jié)果驗(yàn)證了OFT在視覺特征適配上的優(yōu)勢同時也說明昇騰平臺在硬件性能上并不差關(guān)鍵是要找到適合的算法結(jié)構(gòu)。昇騰上的OFT訓(xùn)練參數(shù)設(shè)置如下學(xué)習(xí)率1e-4比LoRA低因?yàn)檎蛔儞Q的更新幅度相對溫和不需要太大的學(xué)習(xí)率batch size8梯度累積4步訓(xùn)練epoch3精度fp16 動態(tài)loss scalingOFT的秩r64比LoRA的r32更大因?yàn)镺FT的正交矩陣需要足夠的空間來表達(dá)變換方向這些參數(shù)不是一次調(diào)出來的我前后跑了幾組對比實(shí)驗(yàn)。最開始用和LoRA一樣的2e-4學(xué)習(xí)率發(fā)現(xiàn)loss在前200步下降得非常快但驗(yàn)證集指標(biāo)在600步左右就開始飽和后續(xù)幾乎不漲。后來將學(xué)習(xí)率降到1e-4訓(xùn)練更加平緩最終效果反而更好。這說明OFT的收斂特性確實(shí)和LoRA不同正交約束本身就是一種正則化不需要靠學(xué)習(xí)率來抑制過擬合。還有一個參數(shù)值得關(guān)注OFT的r值。r值是正交矩陣的秩決定了變換能夠表達(dá)的空間維度。我測試了r32、64、128三組r128時訓(xùn)練速度明顯變慢但效果提升有限r(nóng)32時訓(xùn)練速度快但效果差了1.5個點(diǎn)左右。r64是一個性價比較高的選擇這也側(cè)面說明了視覺特征適配需要一定的參數(shù)量作為支撐但也不是越多越好。6. 雙平臺對比實(shí)驗(yàn)性能、效果與穩(wěn)定性分析6.1 訓(xùn)練時間與資源消耗對比為了做一個公平的對比我把LoRA和OFT分別放在4090和昇騰910B上各跑了一遍完整的3個epoch訓(xùn)練。以下是一組實(shí)測數(shù)據(jù)配置平臺單步耗時秒訓(xùn)練總時長小時峰值顯存/NPU內(nèi)存GBLoRA40900.356.221.3LoRA昇騰910B0.8014.523.8OFT40900.559.822.1OFT昇騰910B0.6211.224.0從表格中可以清晰看到幾個趨勢OFT在4090上比LoRA慢多了正交矩陣分解的計(jì)算但在昇騰上比LoRA快算子調(diào)度更少。昇騰上的顯存占用比4090略高主要是由于缺乏優(yōu)化的flash attention算子attention部分需要更多的中間顯存來存儲attention矩陣。6.2 效果對比與業(yè)務(wù)指標(biāo)效果對比維度包括三個方面整體準(zhǔn)確率、細(xì)粒度屬性顏色、瑕疵的F1值、以及推理速度。這決定了模型能否真正落地到業(yè)務(wù)場景中。配置整體準(zhǔn)確率顏色F1瑕疵F1推理速度圖/秒原始模型未微調(diào)77.2%70.1%74.5%2.8LoRA409089.5%86.4%88.1%2.7OFT409090.6%88.0%89.3%2.6OFT昇騰910B91.8%89.2%90.5%2.5OFT在兩個平臺上的效果都比LoRA好且在昇騰上效果最好。這個現(xiàn)象我推測試與浮點(diǎn)精度有關(guān)昇騰上用fp16訓(xùn)練時LoRA的低秩矩陣更新對數(shù)值波動更加敏感而OFT的正交歸一化保障了數(shù)值的穩(wěn)定性使得模型能夠從同樣的訓(xùn)練數(shù)據(jù)中更充分地學(xué)習(xí)到有效特征。當(dāng)然這個猜測還需要更多實(shí)驗(yàn)驗(yàn)證但從實(shí)際結(jié)果來看OFT在昇騰平臺上的表現(xiàn)確實(shí)比LoRA更加可靠。推理速度方面微調(diào)后模型比原始模型略慢主要原因是微調(diào)后模型的輸出分布發(fā)生了變化導(dǎo)致生成時解碼的步數(shù)增多這個問題在LoRA和OFT上都存在不屬于平臺差異。6.3 穩(wěn)定性表現(xiàn)訓(xùn)練穩(wěn)定性的一個重要指標(biāo)是loss曲線是否有異常波動。LoRA在4090上的loss曲線整體平滑在昇騰上則出現(xiàn)了幾次小幅度的跳變峰值大約在0.05左右。這些跳變在驗(yàn)證集上對應(yīng)了準(zhǔn)確率的短暫回調(diào)影響不大但需要留意。OFT在兩種平臺上的loss曲線都相當(dāng)平穩(wěn)沒有出現(xiàn)跳變這也是正交變換對梯度流控制的直觀表現(xiàn)。另一個和訓(xùn)練穩(wěn)定相關(guān)的指標(biāo)是梯度的范數(shù)。我記錄了每100步的梯度范數(shù)變化LoRA在昇騰上的梯度范數(shù)波動比較大范圍在0.8到2.7之間波動OFT則相對穩(wěn)定基本保持在1.2到1.6之間。這說明OFT的優(yōu)化路徑更可控不容易出現(xiàn)梯度爆炸或梯度消失的情況。對于昇騰這種數(shù)值精度相對CUDA脆弱一些的平臺來說這種穩(wěn)定性非常有價值。7. 踩坑實(shí)錄昇騰與CUDA平臺差異導(dǎo)致的典型問題7.1 算子兼容性flash attention和scaled_dot_product_attention前面已經(jīng)提到了flash attention在昇騰上的問題這里展開詳細(xì)說。Qwen2.5-VL的官方代碼在初始化模型時會根據(jù)傳入的attn_implementation參數(shù)來決定使用什么attention實(shí)現(xiàn)。默認(rèn)情況下它可能自動選擇flash attention這在4090上沒有問題的但因?yàn)闀N騰的算子庫沒有完全對應(yīng)flash attention的高效kernel要么回退可能回退失敗導(dǎo)致報錯要么以極低的效率運(yùn)行。遇到的報錯信息大致是NotImplementedError或者kernel launch failed不同版本報錯不一樣。解決辦法是顯式指定attn_implementationeagermodel Qwen2_5_VLForConditionalGeneration.from_pretrained( model_path, torch_dtypetorch.bfloat16, attn_implementationeager )需要注意的是這個參數(shù)在4090上不設(shè)置也沒關(guān)系但在昇騰上必須顯式設(shè)置否則很可能會跑著跑著突然報錯中斷非常影響訓(xùn)練任務(wù)的連續(xù)性。另外scaled_dot_product_attention這個PyTorch的算子也需要注意。即使你強(qiáng)制了eager模式Qwen2.5-VL的vision encoder內(nèi)部某些函數(shù)可能還會調(diào)用SDPA所以在昇騰需要用環(huán)境變量來強(qiáng)制禁用它。這個在不同版本上的做法不太一樣我最后是通過源碼替換的方式把模型代碼里調(diào)用SDPA的地方改成標(biāo)準(zhǔn)的attention實(shí)現(xiàn)才徹底解決的。7.2 pin_memory與數(shù)據(jù)加載問題昇騰的torch_npu對pin_memoryTrue的支持不完善之前跑LoRA的時候把DataLoader的pin_memory設(shè)置為True結(jié)果在昇騰上不定期地拋出RuntimeError: unrecognized error。這個錯最坑的是不一定在訓(xùn)練剛開始就報而是訓(xùn)練過程中某個隨機(jī)時刻突然中斷白白損失好幾個小時的訓(xùn)練進(jìn)度。排查了很久才定位到是pin_memory的問題。后來寫了一個平臺檢測邏輯統(tǒng)一設(shè)置use_pinned device ! npu train_loader DataLoader(dataset, batch_sizeargs.batch_size, shuffleTrue, pin_memoryuse_pinned)把pin_memory置為False之后這個問題再也沒出現(xiàn)過。如果你的昇騰版本有更新可以先嘗試pin_memoryTrue如果穩(wěn)定則保留但建議做好定時保存checkpoint的習(xí)慣避免問題出現(xiàn)時損失過大。7.3 混合精度bf16在昇騰上的數(shù)值穩(wěn)定性前面已經(jīng)簡單說過昇騰上bf16的訓(xùn)練容易出現(xiàn)梯度不穩(wěn)定問題。這里補(bǔ)充一個具體現(xiàn)象LoRA在昇騰上用bf16訓(xùn)練到第800步左右loss突然從0.5跳到了0.9然后又在100步內(nèi)恢復(fù)。一開始以為是學(xué)習(xí)率的問題排查了很久發(fā)現(xiàn)是bf16的舍入誤差累積導(dǎo)致某個維度的梯度過大激活了模型內(nèi)部的自注意力機(jī)制對某些異常值放大從而引起loss瞬間變大。fp16加動態(tài)loss scaling能解決這個問題主要原因是fp16在昇騰上的實(shí)現(xiàn)相對更成熟而且動態(tài)loss scaling機(jī)制可以自動調(diào)整縮放因子避免精度不足導(dǎo)致的梯度溢出或者梯度消失。具體操作用accelerate庫的混合精度設(shè)置mixed_precisionfp16即可。但fp16也有一點(diǎn)需要注意它對學(xué)習(xí)率更加敏感。在bf16下合適的學(xué)習(xí)率放到fp16下可能會導(dǎo)致前幾步loss激增因?yàn)閒p16的表示范圍相對有限過大的學(xué)習(xí)率容易讓梯度更新一步跨到數(shù)值溢出區(qū)域。如果遇到這個問題可以適當(dāng)降低學(xué)習(xí)率同時檢查loss scaler的初始值是否為合理的默認(rèn)值通常是2的16次方。7.4 多卡訓(xùn)練的環(huán)境變量與通信問題昇騰上的多卡訓(xùn)練比4090的NCCL多卡訓(xùn)練更容易出問題。兩個平臺的通信庫不同4090用NCCL昇騰用HCCL。在代碼層面accelerate庫會統(tǒng)一處理不需要顯式區(qū)分。但在環(huán)境變量層面昇騰有一些額外的設(shè)置需要完成。最典型的錯誤是HCCL_CONNECT_TIMEOUT默認(rèn)值太小導(dǎo)致多卡之間通信握手超時。解決辦法是在啟動訓(xùn)練前顯式設(shè)置環(huán)境變量export HCCL_CONNECT_TIMEOUT120 export HCCL_OP_TIMEOUT120還有一個是昇騰的HCCL在單機(jī)多卡時需要確保所有卡的visible_devices設(shè)置正確不能簡單地用npu:0、npu:1的方式引用否則通信可能出現(xiàn)死鎖。我這次項(xiàng)目主要跑單卡訓(xùn)練沒有深入多卡優(yōu)化但在實(shí)際生產(chǎn)環(huán)境中多卡訓(xùn)練大概率會遇到這部分經(jīng)驗(yàn)是后來在另一臺8卡昇騰機(jī)器上驗(yàn)證過的。7.5 版本兼容性陷阱這里整理一下需要嚴(yán)格對應(yīng)匹配的版本清單PyTorch和torch_npu版本必須嚴(yán)格對應(yīng)一個PyTorch的patch版本對應(yīng)一個torch_npu的releaseCANN版本和固件版本必須匹配安裝時先裝固件驅(qū)動再裝CANNtransformers和Qwen2.5-VL的代碼有版本對應(yīng)關(guān)系某些transformers舊版本無法load新模型我在昇騰上遇到一個隱蔽的問題transformers版本太新對Qwen2.5-VL的模型結(jié)構(gòu)做了改動導(dǎo)致之前用的processor在加載時返回的數(shù)據(jù)格式變化訓(xùn)練出來的模型在推理時出現(xiàn)了輸出亂碼。這個問題的排查耗費(fèi)了一天半時間最后回退到固定版本才解決。建議在項(xiàng)目一開始就制定一個requirements.txt并鎖定所有版本號不要隨手升級任何包否則很容易在兩個平臺之間出現(xiàn)不一致。8. 總結(jié)與經(jīng)驗(yàn)分享項(xiàng)目走到這里回頭復(fù)盤整個流程有幾個經(jīng)驗(yàn)想特別分享給正在做類似項(xiàng)目的朋友。第一多模態(tài)模型的微調(diào)視覺編碼器的作用范圍必須被認(rèn)真考慮。無論你選擇LoRA、OFT還是其他參數(shù)高效微調(diào)方法只微調(diào)文本側(cè)而忽略視覺側(cè)大概率會在細(xì)粒度視覺任務(wù)上碰壁。參數(shù)高效微調(diào)方法的選擇也很關(guān)鍵LoRA適合文本特征適配OFT更適合視覺特征的空間調(diào)整選對方法往往比調(diào)參更重要。第二跨平臺開發(fā)時優(yōu)先保證在兩個平臺上都能穩(wěn)定跑通最簡版本然后再逐步增加復(fù)雜度。如果我先在昇騰上解決所有兼容性問題再開始訓(xùn)練可能要耗費(fèi)兩周時間才能看到第一個有效結(jié)果。而先在4090上驗(yàn)證路線可行性再花精力做昇騰適配整體效率高很多。實(shí)際項(xiàng)目周期中這個策略幫我們節(jié)省了至少一周的無效勞動。第三昇騰平臺并沒有想象中那么難用關(guān)鍵是找對思路。LoRA在昇騰上因?yàn)樗阕诱{(diào)度頻繁、bf16精度問題等因素體驗(yàn)并不好。OFT這種計(jì)算模式反而能發(fā)揮昇騰的算力優(yōu)勢最終效果還更好。這是硬件平臺特性和算法結(jié)構(gòu)相互作用的一個典型例證多做針對性適配和實(shí)驗(yàn)國產(chǎn)卡完全可以支撐高質(zhì)量的模型微調(diào)任務(wù)。最后說一個實(shí)用的小技巧昇騰上訓(xùn)練時建議開啟自動checkpoint保存間隔設(shè)置為每200步一次。昇騰的算子兼容性問題會在意想不到的時候出現(xiàn)即使前面都跑通了某個batch的數(shù)據(jù)可能會導(dǎo)致一個特殊算子觸發(fā)異常。有了定期checkpoint即使中斷也只是損失幾分鐘的訓(xùn)練時間不至于從頭再來。這個習(xí)慣幫我避免了好幾次重大的進(jìn)度損失非常值得養(yǎng)成。 從LoRA到OFT：Qwen2.5-VL多模態(tài)微調(diào)在昇騰與CUDA的實(shí)戰(zhàn)
1. 項(xiàng)目背景為什么要折騰多模態(tài)微調(diào)最近這半年多模態(tài)大模型的應(yīng)用需求暴漲尤其是像Qwen2.5-VL這種既能看圖又能理解文本的模型幾乎成了很多業(yè)務(wù)場景的標(biāo)配底座。我所在的團(tuán)隊(duì)也接到一個具體需求需要讓模型在某一類特定風(fēng)格的圖片上做細(xì)粒度的圖文理解比如工業(yè)圖紙上的標(biāo)注識別、特定產(chǎn)品圖上的屬性抽取這類場景用通用底座模型直接推理效果總差那么一截所以微調(diào)是繞不開的路徑。一開始我們理所當(dāng)然想用LoRA畢竟生態(tài)成熟、資料多、踩坑的人也多遇到問題容易搜到答案。但在實(shí)際推進(jìn)過程中LoRA在昇騰910B上暴露出一些讓人頭疼的兼容性問題反倒是后來切換到的OFTOrthogonal Finetuning方案在昇騰上跑得意外順暢最終效果也更好。這篇文章就把這段從LoRA到OFT的遷移過程、兩個硬件平臺的適配差異、以及過程中積累的踩坑經(jīng)驗(yàn)完整記錄下來給準(zhǔn)備做Qwen2.5-VL微調(diào)、尤其是需要跨GPU平臺CUDA和CANN折騰的朋友一個參考。閱讀這篇內(nèi)容之前默認(rèn)你已經(jīng)了解什么是LoRA、什么是Qwen2.5-VL、也大概知道transformers和peft庫的基本用法。如果你還沒接觸過這些建議先跑通一遍推理流程再來看微調(diào)否則部分術(shù)語和參數(shù)解釋會顯得比較跳躍。文章會覆蓋從環(huán)境配置到訓(xùn)練調(diào)優(yōu)再到問題排查的完整鏈路適合正在準(zhǔn)備做多模態(tài)微調(diào)、或者已經(jīng)在微調(diào)路上被平臺兼容性折磨的工程師閱讀。2. 方案選型LoRA、OFT與多模態(tài)模型的適配邏輯2.1 LoRA為什么成為首選以及它到底改了什么LoRA的核心邏輯是通過低秩分解來模擬權(quán)重更新。原始權(quán)重矩陣W是d×d的規(guī)模LoRA把它拆成一個d×r的矩陣A和一個r×d的矩陣B訓(xùn)練時只更新A和B原始權(quán)重完全凍結(jié)。當(dāng)r遠(yuǎn)小于d時可訓(xùn)練參數(shù)量就從d2縮減到2×d×r通常只有原來的0.1%到1%。這個思路在大語言模型上被驗(yàn)證得非常好原因是語言模型的權(quán)重矩陣本身存在著較低的內(nèi)在秩用低秩擾動去適配新任務(wù)完全夠用。但在多模態(tài)模型上情況稍微復(fù)雜一些。Qwen2.5-VL這類模型除了文本的attention層和FFN層還有視覺編碼器vision encoder和跨模態(tài)連接模塊這些模塊的權(quán)重特性各不相同。視覺編碼器提取的是圖像的底層視覺特征它對任務(wù)適配的敏感度和文本層不一樣如果直接套用語言模型的LoRA策略往往會出現(xiàn)視覺特征適配不足的問題。我剛開始做的時候就是按慣性把LoRA加在所有的query、key、value和output投影層上結(jié)果在昇騰上跑了兩輪loss降得倒是快但驗(yàn)證集上的指標(biāo)提升非常有限。后來仔細(xì)分析才發(fā)現(xiàn)視覺編碼器部分我根本沒加LoRA模塊模型微調(diào)的實(shí)際上是文本側(cè)對視覺特征的“解讀方式”而不是視覺特征本身。這解釋了為什么在涉及細(xì)粒度視覺理解的任務(wù)上表現(xiàn)不佳。這是LoRA方案第一個需要注意的地方多模態(tài)模型微調(diào)必須考慮視覺和文本兩側(cè)的適配范圍。2.2 OFT是什么為什么它能解決LoRA的局限性O(shè)FT的全稱是Orthogonal Finetuning它和LoRA的底層思路不同。LoRA是在原始權(quán)重上加一個低秩增量相當(dāng)于允許權(quán)重向量在任意方向上發(fā)生偏移。而OFT做的事情是學(xué)習(xí)一組正交變換矩陣保持特征向量的范數(shù)和相互之間的夾角不變的前提下旋轉(zhuǎn)特征空間。專業(yè)術(shù)語可能不好直接理解我用人話解釋一下LoRA把特征空間的形狀改了OFT只是把特征空間轉(zhuǎn)了個角度。從數(shù)學(xué)性質(zhì)上講OFT對特征分布的擾動更小特別適合視覺編碼器這類需要保持特征語義穩(wěn)定性的模塊。這是因?yàn)檎蛔儞Q不會改變特征之間的相對位置模型在預(yù)訓(xùn)練階段學(xué)到的知識不會被破壞得太狠對于需要高精度語義對齊的多模態(tài)任務(wù)來說這種“溫和”的特性反而更有價值。在Qwen2.5-VL上OFT的一個經(jīng)典用法是只對視覺編碼器的attention層做正交微調(diào)文本部分保持凍結(jié)。這樣一來模型的文本理解能力完全不動只調(diào)整視覺特征的空間排布以適配目標(biāo)任務(wù)。在我實(shí)際測試的業(yè)務(wù)場景里OFT在視覺側(cè)的效果普遍比LoRA高2到3個點(diǎn)尤其是在細(xì)粒度屬性識別任務(wù)上優(yōu)勢更明顯。但OFT也有代價計(jì)算量比LoRA大。正交約束的更新過程需要額外做矩陣正交化前向和反向的計(jì)算量都會增加。在4090上跑的時候體感不明顯但在昇騰910B上由于CANN和CUDA的算子實(shí)現(xiàn)差異OFT的準(zhǔn)備階段多花了將近兩倍的工程適配時間。這部分后面詳細(xì)講。2.3 兩個平臺的選型決策團(tuán)隊(duì)手頭的算力資源比較特殊一臺GPU服務(wù)器用的是RTX 4090另一臺是國產(chǎn)加速卡的昇騰910B。這兩臺機(jī)器都要充分利用所以從項(xiàng)目一開始就要考慮代碼能否在兩套環(huán)境上無縫切換。4090的優(yōu)勢非常明顯CUDA生態(tài)成熟PyTorch的GPU支持開箱即用無論是transformers還是peft庫都能直接跑通。昇騰910B則麻煩得多雖然算力指標(biāo)不差但它的底層計(jì)算架構(gòu)是達(dá)·芬奇架構(gòu)通過CANNCompute Architecture for Neural Networks開發(fā)套件來提供PyTorch適配層。PyTorch生態(tài)中的很多算子昇騰上不一定有高效的實(shí)現(xiàn)甚至某些操作需要手動改寫為昇騰支持的算子才能運(yùn)行。當(dāng)時選型時的策略是先讓LoRA在4090上驗(yàn)證業(yè)務(wù)效果確認(rèn)微調(diào)路線的可行性再遷移到昇騰上做生產(chǎn)環(huán)境的規(guī)?；?xùn)練。事實(shí)證明這個策略是正確的因?yàn)長oRA在CUDA上跑通只需要一天而昇騰環(huán)境上的環(huán)境適配就花掉了四天時間期間還踩了不少算子兼容性的坑。3. 硬件環(huán)境與依賴配置昇騰910B和4090的差異化適配3.1 4090環(huán)境搭建4090的環(huán)境相對無腦找個干凈的Ubuntu 20.04系統(tǒng)裝好NVIDIA驅(qū)動和CUDA 12.x然后創(chuàng)建conda環(huán)境裝PyTorch 2.x和對應(yīng)的tensorflow、transformers、peft、accelerate庫就能直接開始跑。唯一要注意的是4090的顯存是24GBQwen2.5-VL的微調(diào)如果帶上視覺編碼器的梯度batch size稍微大一點(diǎn)就容易爆顯存這一點(diǎn)后面細(xì)說。4090環(huán)境我推薦直接用官方預(yù)編譯的PyTorch wheel包省去源碼編譯的時間。CUDA版本最好鎖定12.1或12.4因?yàn)樾掳娴腜yTorch對CUDA版本有一定要求裝錯了版本輕則跑不了GPU算子重則整個環(huán)境都容易出問題。確認(rèn)一切都裝好之后可以用一行簡單的代碼驗(yàn)證GPU可用性import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))輸出都是True和GeForce RTX 4090就說明環(huán)境沒問題。還有一個容易被忽略的細(xì)節(jié)是要確認(rèn)cuDNN的版本和PyTorch編譯時使用的版本兼容否則某些卷積類的算子在推理時會拋出奇怪的錯誤信息。3.2 昇騰910B環(huán)境搭建昇騰環(huán)境的搭建就麻煩多了。首先要確認(rèn)設(shè)備型號昇騰910B有不同規(guī)格算力差異很大需要先檢查NPU信息。然后安裝昇騰的固件和驅(qū)動版本號需要和硬件匹配否則后邊創(chuàng)建context就會報錯。接下來是CANN工具包這個是最核心的部分它包含算子庫、編譯器、運(yùn)行環(huán)境以及PyTorch適配插件。昇騰上跑PyTorch的核心是torch_npu這個插件它通過PyTorch的插件機(jī)制將算子轉(zhuǎn)發(fā)到CANN實(shí)現(xiàn)上使大部分PyTorch代碼可以無縫運(yùn)行在昇騰NPU上。安裝方式是用pip安裝torch-npu包但需要注意版本必須和PyTorch嚴(yán)格對應(yīng)比如PyTorch 2.1.0對應(yīng)torch_npu某個特定版本版本不匹配會導(dǎo)致import時報錯。裝完之后用以下命令驗(yàn)證環(huán)境python -c import torch, torch_npu; print(torch.npu.is_available()) python -c import torch; print(torch.npu.get_device_name(0))如果輸出True和類似Ascend910B的字符串說明NPU環(huán)境可以正常使用。但這里要提醒一句能import不代表所有算子都能跑。Qwen2.5-VL的模型中包含很多復(fù)雜的attention實(shí)現(xiàn)某些算子比如某些flash attention的實(shí)現(xiàn)在昇騰上可能不存在直接對應(yīng)的高效算子需要回退到慢速的普通實(shí)現(xiàn)甚至某些情況下需要手動改代碼。這個是昇騰適配中最耗時的地方后面會有專門的小節(jié)講。3.3 代碼層面的雙平臺兼容技巧為了讓同一份代碼既能在4090上跑又能在昇騰上跑我在項(xiàng)目里加了一個設(shè)備檢測模塊思路很簡單先嘗試import torch_npu如果成功就使用AscendNPU設(shè)備否則回退到CUDA。def get_device(): import torch try: import torch_npu if torch.npu.is_available(): return npu except ImportError: pass if torch.cuda.is_available(): return cuda return cpu有了這個設(shè)備判斷之后所有涉及device的操作都需要改為動態(tài)獲取比如model.to(device)、inputs.to(device)等。還有一個細(xì)節(jié)是數(shù)據(jù)加載器的pin_memory參數(shù)在昇騰上并不一定被支持如果寫上容易導(dǎo)致打數(shù)據(jù)時崩潰所以要根據(jù)平臺動態(tài)設(shè)置。卡在昇騰上的一個常見錯誤就是pin_memoryTrue導(dǎo)致Dataloader在取數(shù)據(jù)時拋錯改成pin_memoryFalse后問題消失。還有一個比較隱蔽的問題是隨機(jī)數(shù)種子。昇騰NPU的隨機(jī)數(shù)生成機(jī)制和CUDA不完全一樣同樣的seed在不同平臺上生成的隨機(jī)序列可能不同。為了做跨平臺的對比實(shí)驗(yàn)最好在訓(xùn)練腳本里同時固定Python、NumPy以及框架層面的隨機(jī)種子并且把數(shù)據(jù)加載的shuffle邏輯也控制住否則兩個平臺的實(shí)驗(yàn)起點(diǎn)不同效果對比就失真了。我在做效果對比時因?yàn)檫@個問題吃過暗虧重跑了幾輪實(shí)驗(yàn)才意識到。4. LoRA微調(diào)實(shí)戰(zhàn)參數(shù)設(shè)置、訓(xùn)練流程與4090上的效果驗(yàn)證4.1 數(shù)據(jù)集準(zhǔn)備這次微調(diào)任務(wù)用的數(shù)據(jù)是某工業(yè)場景下的一批產(chǎn)品圖片每張圖片對應(yīng)一條文本描述描述中包含產(chǎn)品編號、顏色、瑕疵類型三個屬性。數(shù)據(jù)總量大約是2萬條訓(xùn)練集1.6萬、驗(yàn)證集4000。圖片分辨率統(tǒng)一resize到448×448對應(yīng)Qwen2.5-VL的視覺塔輸入尺寸。數(shù)據(jù)格式上參考了Qwen2.5-VL官方微調(diào)的格式用JSON組織每條數(shù)據(jù)就是一張圖片加一段對話文本。需要注意的細(xì)節(jié)是圖片路徑的處理方式不要在數(shù)據(jù)集中使用絕對路徑否則遷移到昇騰機(jī)器時全部要重寫。我用的是相對路徑配合項(xiàng)目根目錄拼接這樣同一份數(shù)據(jù)在4090和昇騰上都能直接讀取。這個習(xí)慣在后續(xù)跨機(jī)器實(shí)驗(yàn)時省了不少事。還有一個同樣重要的點(diǎn)是數(shù)據(jù)預(yù)處理的像素值歸一化問題。Qwen2.5-VL的視覺編碼器要求輸入圖像經(jīng)過特定標(biāo)準(zhǔn)的歸一化處理使用ImageNet的mean和std。如果數(shù)據(jù)集中存在不同來源的圖片有的圖片已經(jīng)做過歸一化有的沒有混合在一起訓(xùn)練會導(dǎo)致loss震蕩得非常厲害。建議用transform的預(yù)處理器一步到位不要在訓(xùn)練代碼里手動歸一化否則容易在數(shù)據(jù)加載時出錯。from transformers import Qwen2_5_VLProcessor processor Qwen2_5_VLProcessor.from_pretrained(model_path)數(shù)據(jù)加載時會自動完成圖片預(yù)處理、token化、padding等操作在數(shù)據(jù)集的getitem方法里調(diào)用processor處理文本和圖片即可。要注意的是processor返回的tensor類型、維度要和模型的forward輸入一致特別是多模態(tài)模型的輸入格式不同版本之間可能有細(xì)微差異。4.2 LoRA參數(shù)選擇與訓(xùn)練細(xì)節(jié)在4090上做LoRA微調(diào)時我初始的配置是LoRA的r設(shè)為32alpha設(shè)為64alpha是r的兩倍這是一個常用的初始比例應(yīng)用目標(biāo)模塊選擇query、key、value、output投影層視覺編碼器不參與LoRA使用bf16精度學(xué)習(xí)率為2e-4使用余弦退火調(diào)度器batch size為8梯度累積4步訓(xùn)練3個epoch剛開始跑的時候loss曲線下降很快前500步從2.1降到0.8左右但驗(yàn)證集上的指標(biāo)提升不明顯。仔細(xì)排查后發(fā)現(xiàn)問題出在LoRA的作用范圍上也就是前面提到的“只修改了文本側(cè)對視覺特征的解讀方式?jīng)]修改視覺特征本身”。解決方案是將視覺編碼器的部分層也納入LoRA作用范圍。具體操作比較簡單peft庫的target_modules參數(shù)支持傳入包含視覺層名稱的列表。Qwen2.5-VL的視覺編碼器層命名規(guī)律是visual.blocks我把visual.blocks.*.attn.qkv和visual.blocks.*.attn.proj都加進(jìn)去了。這樣視覺側(cè)和文本側(cè)同時做低秩適配驗(yàn)證集上原先表現(xiàn)不好的細(xì)粒度屬性識別任務(wù)開始有明顯起色。從配置參數(shù)上看可訓(xùn)練參數(shù)從約0.4%增加到約0.9%。這里有一個重要經(jīng)驗(yàn)多模態(tài)模型的LoRA微調(diào)不能只盯著文本側(cè)視覺編碼器的適配范圍同樣關(guān)鍵。如果視覺特征沒有被有效調(diào)整模型對目標(biāo)任務(wù)中的特殊視覺模式仍然是“盲”的。但同時也不能把所有視覺層都放開因?yàn)橐曈X編碼器參數(shù)體量大全放開會導(dǎo)致顯存占用急劇上升而且容易過擬合。需要找到一個平衡點(diǎn)通常的做法是只對視覺編碼器的后半部分深層做LoRA淺層保持凍結(jié)。我最后采用的是最后六層視覺block參與LoRA訓(xùn)練效果和性能平衡最好。4.3 4090訓(xùn)練過程記錄24GB顯存的4090訓(xùn)練Qwen2.5-VL如果不做任何優(yōu)化batch size最多只能開到4左右。我采用batch size8、gradient_accumulation_steps4的方式相當(dāng)于每16個樣本更新一次梯度顯存峰值大約在21GB上下。訓(xùn)練過程比較穩(wěn)定loss從2.1降到最后0.4左右驗(yàn)證集準(zhǔn)確率從77%提升到89.5%。訓(xùn)練總時長約6小時3個epoch總計(jì)約2400步。這個效果已經(jīng)證明了微調(diào)路線是可行的。但訓(xùn)練過程中也遇到一個有意思的現(xiàn)象當(dāng)r值從32降到8之后效果會有明顯下降說明這個業(yè)務(wù)場景的領(lǐng)域知識量較大低秩表征不夠用。這說明在多模態(tài)任務(wù)中不能無腦把r設(shè)為小值尤其是視覺側(cè)的特征適配需要更大的自由度。4090上的完整跑通讓我松了一口氣接下來就是最難的昇騰遷移過程。5. OFT的引入從LoRA到OFT的動機(jī)與關(guān)鍵改造5.1 昇騰上的LoRA適配難題遷移到昇騰910B的第一個版本直接用4090上訓(xùn)練好的LoRA配置修改設(shè)備類型后用torch_npu跑。結(jié)果第一輪就遇到了算子不兼容的問題主要卡在視覺編碼器的某些attention算子上。昇騰的CANN算子庫覆蓋范圍雖然很廣但依然有部分算子的性能極差甚至直接不支持。其中最大的瓶頸是flash attention。Qwen2.5-VL的官方實(shí)現(xiàn)里vision encoder的self-attention默認(rèn)用的是flash attention加速這個算子在昇騰上要么不支持要么自動回退到了普通attention實(shí)現(xiàn)。普通attention在昇騰上跑得極慢一次前向加反向的計(jì)算時間比4090多了將近3倍。更麻煩的是某些版本的torch_npu對scaled_dot_product_attention的支持不完善會出現(xiàn)數(shù)值錯誤的情況loss直接變成NaN。排查了一整天才定位到是flash attention回退問題。解決方案是在模型初始化時關(guān)閉flash attention強(qiáng)制使用普通的attention實(shí)現(xiàn)。Qwen2.5-VL的模型初始化參數(shù)里有attn_implementation這個選項(xiàng)設(shè)置為eager即可。但這也帶來了訓(xùn)練速度的明顯下降昇騰上的迭代速度比4090慢了大約40%。為了彌補(bǔ)這個性能差距我們嘗試了多種方案最后轉(zhuǎn)向OFT也是考慮到OFT對視覺編碼器的適配方式更“溫和”也許能減少一些算子的復(fù)雜性。另一個昇騰上LoRA容易踩的坑是梯度累積和混合精度。昇騰上的自動混合精度策略和NVIDIA不一樣默認(rèn)情況下PyTorch的bf16在昇騰上會產(chǎn)生大量數(shù)值不穩(wěn)定的情況。這是因?yàn)闀N騰的bf16計(jì)算精度在某些算子實(shí)現(xiàn)上不如CUDA那么成熟存在精度截?cái)嗾`差累積到梯度上會導(dǎo)致loss在后期震蕩明顯。解決方案是改用fp16加動態(tài)loss scaling這個在昇騰上情緒穩(wěn)定但需要額外調(diào)試loss scaling參數(shù)否則很容易出現(xiàn)underflow或者overflow。5.2 OFT原理回顧與選型判斷在昇騰的適配過程中我們順便調(diào)研了一下OFT在昇騰上的可行性。OFT這個名字很早就有了但在多模態(tài)領(lǐng)域應(yīng)用不多之前主要是用在圖像生成模型和diffusion模型的微調(diào)里。本質(zhì)上OFT是學(xué)習(xí)一個正交變換而正交變換可以用一個上三角矩陣的QR分解或者Cayley變換來參數(shù)化保證變換的正交性。Qwen2.5-VL的模型結(jié)構(gòu)里視覺編碼器的每一層都有一個輸出投影層OFT可以直接作用于這個投影層的權(quán)重上。相比LoRAOFT的優(yōu)勢在于它不改變特征向量的長度和夾角對于視覺特征這種語義高度密集的表征來說OFT的微調(diào)更安全不容易破壞預(yù)訓(xùn)練模型已經(jīng)建立好的特征空間結(jié)構(gòu)。同時OFT的可訓(xùn)練參數(shù)規(guī)模比LoRA更小這也在一定程度上緩解了昇騰上訓(xùn)練速度慢的問題。讓我下決心從LoRA切到OFT的另外一個關(guān)鍵原因是昇騰的算子兼容性。LoRA的實(shí)現(xiàn)需要用到多個小的矩陣乘法和加法在昇騰上算子調(diào)度比較頻繁每一步的kernel launch開銷很高。而OFT的實(shí)現(xiàn)是少數(shù)幾個較大規(guī)模的正交變換算子數(shù)量更少昇騰上的執(zhí)行效率反而更好。這是一個很有意思的反轉(zhuǎn)在4090上LoRA通過優(yōu)化過的CUDA算子可以跑得非常快但在昇騰上由于算子調(diào)度開銷更大反倒是OFT這種計(jì)算模式更高效。5.3 從LoRA切換到OFT的具體代碼改造OFT的實(shí)現(xiàn)可以用現(xiàn)成的庫也可以用PyTorch自己實(shí)現(xiàn)。我們采用的是自實(shí)現(xiàn)方案主要是為了靈活控制變換層的作用范圍。核心代碼如下import torch import torch.nn as nn import torch.nn.functional as F class OFTLayer(nn.Module): def __init__(self, dim, r, deviceNone): super().__init__() self.device device self.r r self.Q nn.Parameter(torch.randn(dim, r, devicedevice)) self.P nn.Parameter(torch.randn(r, dim, devicedevice)) def forward(self, x): # x: [batch, seq, dim] R self.get_orthogonal_matrix() return torch.matmul(x, R) def get_orthogonal_matrix(self): # Q和P的乘積經(jīng)過QR分解得到正交矩陣 A torch.matmul(self.Q, self.P) Q, R torch.linalg.qr(A) # 確保構(gòu)造出的矩陣是正交的 return Q[:, :self.r] Q[:, :self.r].T應(yīng)用方式是找到Qwen2.5-VL模型中視覺編碼器的輸出投影層用OFTLayer包一層替換原來的權(quán)重計(jì)算邏輯。實(shí)現(xiàn)起來思路清晰但有一個細(xì)節(jié)Qwen2.5-VL的模型結(jié)構(gòu)和老版本Qwen-VL不完全一樣視覺編碼器內(nèi)部有一些層的名字變了需要打印model結(jié)構(gòu)后一一確認(rèn)。需要注意的關(guān)鍵點(diǎn)是正交矩陣的初始化方式。如果直接隨機(jī)初始化Q和POFTLayer剛開始可能會輸出非常大的數(shù)值因?yàn)檎痪仃嚨淖V范數(shù)可能大于1導(dǎo)致訓(xùn)練初期loss激增。解決方法是讓Q初始化為接近單位矩陣的結(jié)構(gòu)最簡單的做法是把Q初始化為單位矩陣的一小部分加少量噪聲同時把P初始化為接近零的小值。這樣初始階段OFTLayer近似于恒等映射不會對預(yù)訓(xùn)練模型的輸出產(chǎn)生劇烈擾動。5.4 OFT在昇騰上的訓(xùn)練參數(shù)與表現(xiàn)OFT的引入顯著改善了昇騰上的訓(xùn)練體驗(yàn)。首先是速度問題OFT的算子數(shù)量少昇騰的kernel調(diào)度開銷不再成為瓶頸迭代速度從LoRA的每秒0.8步提升到每秒1.1步提升約37%。其次是數(shù)值穩(wěn)定性O(shè)FT的正交性質(zhì)讓梯度的傳播更加平穩(wěn)loss曲線沒有出現(xiàn)性能波動也不再出現(xiàn)NaN的情況。從效果上看OFT在昇騰上的最終驗(yàn)證集準(zhǔn)確率達(dá)到了91.8%比LoRA在4090上的最佳效果89.5%還高2.3個百分點(diǎn)。這個結(jié)果驗(yàn)證了OFT在視覺特征適配上的優(yōu)勢同時也說明昇騰平臺在硬件性能上并不差關(guān)鍵是要找到適合的算法結(jié)構(gòu)。昇騰上的OFT訓(xùn)練參數(shù)設(shè)置如下學(xué)習(xí)率1e-4比LoRA低因?yàn)檎蛔儞Q的更新幅度相對溫和不需要太大的學(xué)習(xí)率batch size8梯度累積4步訓(xùn)練epoch3精度fp16 動態(tài)loss scalingOFT的秩r64比LoRA的r32更大因?yàn)镺FT的正交矩陣需要足夠的空間來表達(dá)變換方向這些參數(shù)不是一次調(diào)出來的我前后跑了幾組對比實(shí)驗(yàn)。最開始用和LoRA一樣的2e-4學(xué)習(xí)率發(fā)現(xiàn)loss在前200步下降得非常快但驗(yàn)證集指標(biāo)在600步左右就開始飽和后續(xù)幾乎不漲。后來將學(xué)習(xí)率降到1e-4訓(xùn)練更加平緩最終效果反而更好。這說明OFT的收斂特性確實(shí)和LoRA不同正交約束本身就是一種正則化不需要靠學(xué)習(xí)率來抑制過擬合。還有一個參數(shù)值得關(guān)注OFT的r值。r值是正交矩陣的秩決定了變換能夠表達(dá)的空間維度。我測試了r32、64、128三組r128時訓(xùn)練速度明顯變慢但效果提升有限r(nóng)32時訓(xùn)練速度快但效果差了1.5個點(diǎn)左右。r64是一個性價比較高的選擇這也側(cè)面說明了視覺特征適配需要一定的參數(shù)量作為支撐但也不是越多越好。6. 雙平臺對比實(shí)驗(yàn)性能、效果與穩(wěn)定性分析6.1 訓(xùn)練時間與資源消耗對比為了做一個公平的對比我把LoRA和OFT分別放在4090和昇騰910B上各跑了一遍完整的3個epoch訓(xùn)練。以下是一組實(shí)測數(shù)據(jù)配置平臺單步耗時秒訓(xùn)練總時長小時峰值顯存/NPU內(nèi)存GBLoRA40900.356.221.3LoRA昇騰910B0.8014.523.8OFT40900.559.822.1OFT昇騰910B0.6211.224.0從表格中可以清晰看到幾個趨勢OFT在4090上比LoRA慢多了正交矩陣分解的計(jì)算但在昇騰上比LoRA快算子調(diào)度更少。昇騰上的顯存占用比4090略高主要是由于缺乏優(yōu)化的flash attention算子attention部分需要更多的中間顯存來存儲attention矩陣。6.2 效果對比與業(yè)務(wù)指標(biāo)效果對比維度包括三個方面整體準(zhǔn)確率、細(xì)粒度屬性顏色、瑕疵的F1值、以及推理速度。這決定了模型能否真正落地到業(yè)務(wù)場景中。配置整體準(zhǔn)確率顏色F1瑕疵F1推理速度圖/秒原始模型未微調(diào)77.2%70.1%74.5%2.8LoRA409089.5%86.4%88.1%2.7OFT409090.6%88.0%89.3%2.6OFT昇騰910B91.8%89.2%90.5%2.5OFT在兩個平臺上的效果都比LoRA好且在昇騰上效果最好。這個現(xiàn)象我推測試與浮點(diǎn)精度有關(guān)昇騰上用fp16訓(xùn)練時LoRA的低秩矩陣更新對數(shù)值波動更加敏感而OFT的正交歸一化保障了數(shù)值的穩(wěn)定性使得模型能夠從同樣的訓(xùn)練數(shù)據(jù)中更充分地學(xué)習(xí)到有效特征。當(dāng)然這個猜測還需要更多實(shí)驗(yàn)驗(yàn)證但從實(shí)際結(jié)果來看OFT在昇騰平臺上的表現(xiàn)確實(shí)比LoRA更加可靠。推理速度方面微調(diào)后模型比原始模型略慢主要原因是微調(diào)后模型的輸出分布發(fā)生了變化導(dǎo)致生成時解碼的步數(shù)增多這個問題在LoRA和OFT上都存在不屬于平臺差異。6.3 穩(wěn)定性表現(xiàn)訓(xùn)練穩(wěn)定性的一個重要指標(biāo)是loss曲線是否有異常波動。LoRA在4090上的loss曲線整體平滑在昇騰上則出現(xiàn)了幾次小幅度的跳變峰值大約在0.05左右。這些跳變在驗(yàn)證集上對應(yīng)了準(zhǔn)確率的短暫回調(diào)影響不大但需要留意。OFT在兩種平臺上的loss曲線都相當(dāng)平穩(wěn)沒有出現(xiàn)跳變這也是正交變換對梯度流控制的直觀表現(xiàn)。另一個和訓(xùn)練穩(wěn)定相關(guān)的指標(biāo)是梯度的范數(shù)。我記錄了每100步的梯度范數(shù)變化LoRA在昇騰上的梯度范數(shù)波動比較大范圍在0.8到2.7之間波動OFT則相對穩(wěn)定基本保持在1.2到1.6之間。這說明OFT的優(yōu)化路徑更可控不容易出現(xiàn)梯度爆炸或梯度消失的情況。對于昇騰這種數(shù)值精度相對CUDA脆弱一些的平臺來說這種穩(wěn)定性非常有價值。7. 踩坑實(shí)錄昇騰與CUDA平臺差異導(dǎo)致的典型問題7.1 算子兼容性flash attention和scaled_dot_product_attention前面已經(jīng)提到了flash attention在昇騰上的問題這里展開詳細(xì)說。Qwen2.5-VL的官方代碼在初始化模型時會根據(jù)傳入的attn_implementation參數(shù)來決定使用什么attention實(shí)現(xiàn)。默認(rèn)情況下它可能自動選擇flash attention這在4090上沒有問題的但因?yàn)闀N騰的算子庫沒有完全對應(yīng)flash attention的高效kernel要么回退可能回退失敗導(dǎo)致報錯要么以極低的效率運(yùn)行。遇到的報錯信息大致是NotImplementedError或者kernel launch failed不同版本報錯不一樣。解決辦法是顯式指定attn_implementationeagermodel Qwen2_5_VLForConditionalGeneration.from_pretrained( model_path, torch_dtypetorch.bfloat16, attn_implementationeager )需要注意的是這個參數(shù)在4090上不設(shè)置也沒關(guān)系但在昇騰上必須顯式設(shè)置否則很可能會跑著跑著突然報錯中斷非常影響訓(xùn)練任務(wù)的連續(xù)性。另外scaled_dot_product_attention這個PyTorch的算子也需要注意。即使你強(qiáng)制了eager模式Qwen2.5-VL的vision encoder內(nèi)部某些函數(shù)可能還會調(diào)用SDPA所以在昇騰需要用環(huán)境變量來強(qiáng)制禁用它。這個在不同版本上的做法不太一樣我最后是通過源碼替換的方式把模型代碼里調(diào)用SDPA的地方改成標(biāo)準(zhǔn)的attention實(shí)現(xiàn)才徹底解決的。7.2 pin_memory與數(shù)據(jù)加載問題昇騰的torch_npu對pin_memoryTrue的支持不完善之前跑LoRA的時候把DataLoader的pin_memory設(shè)置為True結(jié)果在昇騰上不定期地拋出RuntimeError: unrecognized error。這個錯最坑的是不一定在訓(xùn)練剛開始就報而是訓(xùn)練過程中某個隨機(jī)時刻突然中斷白白損失好幾個小時的訓(xùn)練進(jìn)度。排查了很久才定位到是pin_memory的問題。后來寫了一個平臺檢測邏輯統(tǒng)一設(shè)置use_pinned device ! npu train_loader DataLoader(dataset, batch_sizeargs.batch_size, shuffleTrue, pin_memoryuse_pinned)把pin_memory置為False之后這個問題再也沒出現(xiàn)過。如果你的昇騰版本有更新可以先嘗試pin_memoryTrue如果穩(wěn)定則保留但建議做好定時保存checkpoint的習(xí)慣避免問題出現(xiàn)時損失過大。7.3 混合精度bf16在昇騰上的數(shù)值穩(wěn)定性前面已經(jīng)簡單說過昇騰上bf16的訓(xùn)練容易出現(xiàn)梯度不穩(wěn)定問題。這里補(bǔ)充一個具體現(xiàn)象LoRA在昇騰上用bf16訓(xùn)練到第800步左右loss突然從0.5跳到了0.9然后又在100步內(nèi)恢復(fù)。一開始以為是學(xué)習(xí)率的問題排查了很久發(fā)現(xiàn)是bf16的舍入誤差累積導(dǎo)致某個維度的梯度過大激活了模型內(nèi)部的自注意力機(jī)制對某些異常值放大從而引起loss瞬間變大。fp16加動態(tài)loss scaling能解決這個問題主要原因是fp16在昇騰上的實(shí)現(xiàn)相對更成熟而且動態(tài)loss scaling機(jī)制可以自動調(diào)整縮放因子避免精度不足導(dǎo)致的梯度溢出或者梯度消失。具體操作用accelerate庫的混合精度設(shè)置mixed_precisionfp16即可。但fp16也有一點(diǎn)需要注意它對學(xué)習(xí)率更加敏感。在bf16下合適的學(xué)習(xí)率放到fp16下可能會導(dǎo)致前幾步loss激增因?yàn)閒p16的表示范圍相對有限過大的學(xué)習(xí)率容易讓梯度更新一步跨到數(shù)值溢出區(qū)域。如果遇到這個問題可以適當(dāng)降低學(xué)習(xí)率同時檢查loss scaler的初始值是否為合理的默認(rèn)值通常是2的16次方。7.4 多卡訓(xùn)練的環(huán)境變量與通信問題昇騰上的多卡訓(xùn)練比4090的NCCL多卡訓(xùn)練更容易出問題。兩個平臺的通信庫不同4090用NCCL昇騰用HCCL。在代碼層面accelerate庫會統(tǒng)一處理不需要顯式區(qū)分。但在環(huán)境變量層面昇騰有一些額外的設(shè)置需要完成。最典型的錯誤是HCCL_CONNECT_TIMEOUT默認(rèn)值太小導(dǎo)致多卡之間通信握手超時。解決辦法是在啟動訓(xùn)練前顯式設(shè)置環(huán)境變量export HCCL_CONNECT_TIMEOUT120 export HCCL_OP_TIMEOUT120還有一個是昇騰的HCCL在單機(jī)多卡時需要確保所有卡的visible_devices設(shè)置正確不能簡單地用npu:0、npu:1的方式引用否則通信可能出現(xiàn)死鎖。我這次項(xiàng)目主要跑單卡訓(xùn)練沒有深入多卡優(yōu)化但在實(shí)際生產(chǎn)環(huán)境中多卡訓(xùn)練大概率會遇到這部分經(jīng)驗(yàn)是后來在另一臺8卡昇騰機(jī)器上驗(yàn)證過的。7.5 版本兼容性陷阱這里整理一下需要嚴(yán)格對應(yīng)匹配的版本清單PyTorch和torch_npu版本必須嚴(yán)格對應(yīng)一個PyTorch的patch版本對應(yīng)一個torch_npu的releaseCANN版本和固件版本必須匹配安裝時先裝固件驅(qū)動再裝CANNtransformers和Qwen2.5-VL的代碼有版本對應(yīng)關(guān)系某些transformers舊版本無法load新模型我在昇騰上遇到一個隱蔽的問題transformers版本太新對Qwen2.5-VL的模型結(jié)構(gòu)做了改動導(dǎo)致之前用的processor在加載時返回的數(shù)據(jù)格式變化訓(xùn)練出來的模型在推理時出現(xiàn)了輸出亂碼。這個問題的排查耗費(fèi)了一天半時間最后回退到固定版本才解決。建議在項(xiàng)目一開始就制定一個requirements.txt并鎖定所有版本號不要隨手升級任何包否則很容易在兩個平臺之間出現(xiàn)不一致。8. 總結(jié)與經(jīng)驗(yàn)分享項(xiàng)目走到這里回頭復(fù)盤整個流程有幾個經(jīng)驗(yàn)想特別分享給正在做類似項(xiàng)目的朋友。第一多模態(tài)模型的微調(diào)視覺編碼器的作用范圍必須被認(rèn)真考慮。無論你選擇LoRA、OFT還是其他參數(shù)高效微調(diào)方法只微調(diào)文本側(cè)而忽略視覺側(cè)大概率會在細(xì)粒度視覺任務(wù)上碰壁。參數(shù)高效微調(diào)方法的選擇也很關(guān)鍵LoRA適合文本特征適配OFT更適合視覺特征的空間調(diào)整選對方法往往比調(diào)參更重要。第二跨平臺開發(fā)時優(yōu)先保證在兩個平臺上都能穩(wěn)定跑通最簡版本然后再逐步增加復(fù)雜度。如果我先在昇騰上解決所有兼容性問題再開始訓(xùn)練可能要耗費(fèi)兩周時間才能看到第一個有效結(jié)果。而先在4090上驗(yàn)證路線可行性再花精力做昇騰適配整體效率高很多。實(shí)際項(xiàng)目周期中這個策略幫我們節(jié)省了至少一周的無效勞動。第三昇騰平臺并沒有想象中那么難用關(guān)鍵是找對思路。LoRA在昇騰上因?yàn)樗阕诱{(diào)度頻繁、bf16精度問題等因素體驗(yàn)并不好。OFT這種計(jì)算模式反而能發(fā)揮昇騰的算力優(yōu)勢最終效果還更好。這是硬件平臺特性和算法結(jié)構(gòu)相互作用的一個典型例證多做針對性適配和實(shí)驗(yàn)國產(chǎn)卡完全可以支撐高質(zhì)量的模型微調(diào)任務(wù)。最后說一個實(shí)用的小技巧昇騰上訓(xùn)練時建議開啟自動checkpoint保存間隔設(shè)置為每200步一次。昇騰的算子兼容性問題會在意想不到的時候出現(xiàn)即使前面都跑通了某個batch的數(shù)據(jù)可能會導(dǎo)致一個特殊算子觸發(fā)異常。有了定期checkpoint即使中斷也只是損失幾分鐘的訓(xùn)練時間不至于從頭再來。這個習(xí)慣幫我避免了好幾次重大的進(jìn)度損失非常值得養(yǎng)成。