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