在本地部署過幾個開源基座模型之后很多程序員的感受其實高度一致模型確實能跑起來但回答總不如官方Demo里那么“聽話”。你問它東它給你續(xù)寫西你要它按JSON格式輸出它偏要自由發(fā)揮加一段解釋。這個差距十有八九出在監(jiān)督微調(diào)SFT這一環(huán)上。SFT全稱是Supervised Fine-Tuning簡單說就是拿一批人工標注好的“指令-回答”數(shù)據(jù)對預(yù)訓(xùn)練基座模型做有監(jiān)督的再訓(xùn)練讓模型學(xué)會人類期望的交互方式。這篇內(nèi)容我會把SFT的原理、數(shù)據(jù)構(gòu)造、超參數(shù)、訓(xùn)練配置、實操流程和踩坑記錄一次性講透。它不是泛泛的科普而是對著能做事的實踐總結(jié)寫下來之前已經(jīng)在多臺機器上反復(fù)驗證過建議直接存下來備查。1. 先搞清楚SFT在整條鏈路里的位置1.1 基座模型只會“續(xù)寫”不會“干活”很多人第一次玩開源基座模型時都會有這個困惑模型明明很大常識也很豐富為什么跟它對話就特別別扭這是因為基座模型在預(yù)訓(xùn)練階段的唯一目標函數(shù)是“下一個詞預(yù)測”。它學(xué)到的本質(zhì)是詞與詞之間的統(tǒng)計關(guān)聯(lián)你輸入一段文本它就按照統(tǒng)計規(guī)律往后接最可能的詞而不是“理解你的問題然后給出答案”。拿生活化的例子來說基座模型像一個博覽群書但沒參加過考試的學(xué)生。你問他一道題他憑記憶和語感展開長篇大論卻不知道答案應(yīng)該是一句話、一段代碼還是一個JSON對象。他不知道考試有固定格式、有標準答案、有答題邊界。這些“約定俗成”的東西預(yù)訓(xùn)練階段沒有專門教過只能靠SFT來補課。這種能力差距在實際部署中非常致命。比如你打算做一個代碼助手希望模型根據(jù)需求生成Python腳本基座模型可能會輸出一大段自然語言解釋再夾幾行偽代碼甚至把問題換個說法又重復(fù)一遍。而經(jīng)過SFT的模型才知道用戶問代碼時應(yīng)該先給代碼塊再給簡要說明。所以SFT解決的是“形式對齊”和“指令跟隨”問題不是知識注入問題。1.2 SFT、預(yù)訓(xùn)練和RLHF的分工關(guān)系大模型從零到可用的鏈路一般可以拆成三個階段預(yù)訓(xùn)練、SFT、偏好對齊常見手段是RLHF/DPO。這三者分工完全不同。預(yù)訓(xùn)練負責(zé)往里灌知識讓模型具備語言能力、事實記憶和推理基礎(chǔ)這一步成本最高通常需要幾千億token和成百上千張顯卡。SFT負責(zé)教模型“怎么把知識組織成用戶想要的樣子”用幾千到幾萬條高質(zhì)量的指令數(shù)據(jù)就能完成任務(wù)。偏好對齊則更進一步它解決的是“模型知道答案是什么但不一定知道哪個答案更符合人類品味”的問題。SFT給的是標準答案就像教科書上的參考答案偏好對齊給的是一堆答案排序就像閱卷老師告訴你“這個回答比那個更流暢、更有用”。SFT是基礎(chǔ)沒有好的SFT模型偏好對齊做起來會非常吃力因為模型連基本的指令格式都沒學(xué)好。我見過不少團隊為了省事跳過SFT直接嘗試用偏好優(yōu)化方法調(diào)基座模型結(jié)果模型學(xué)會了說漂亮話但依然不會嚴格按要求辦事。原因很簡單排序?qū)W習(xí)只能調(diào)整回答風(fēng)格的傾向無法補上“格式不對齊就是聽不懂人話”這個根本短板。SFT是讓模型“聽得懂人話”的最低成本方案。1.3 為什么SFT數(shù)據(jù)不多卻能改變模型行為一個值得思考的問題預(yù)訓(xùn)練看了幾千億token為什么SFT只用幾萬條數(shù)據(jù)就能明顯改變模型行為這里的關(guān)鍵在于SFT改變的不是知識量而是“概率分布的輸出模式”。模型在預(yù)訓(xùn)練階段其實已經(jīng)見過大量問答類文本它具備回答問題的潛力只是不知道怎么判斷“當前這是在問我問題我應(yīng)該認真回答而不是繼續(xù)編故事”。SFT相當于給模型做了行為示范看到指令停止發(fā)散按格式輸出。因為預(yù)訓(xùn)練已經(jīng)給了它足夠的語言能力和知識儲備SFT只需要“撥動開關(guān)”把回答模式從續(xù)寫切換到指令跟隨。這也是為什么SFT數(shù)據(jù)不需要海量但必須高質(zhì)量、格式統(tǒng)一、覆蓋充分。理解了這一點就不會盲目堆數(shù)據(jù)量了。2. SFT數(shù)據(jù)工程成敗的關(guān)鍵不在模型而在數(shù)據(jù)2.1 數(shù)據(jù)長什么樣三種主流格式必須掌握SFT數(shù)據(jù)的組織方式目前大體上有三種主流格式。第一種是“instruction/input/output”三段式適合任務(wù)型微調(diào)一條樣本就是一個獨立問題可以附帶輸入內(nèi)容。第二種是messages對話格式按角色區(qū)分user和assistant消息適合訓(xùn)練多輪對話能力。第三種是ShareGPT風(fēng)格用conversations數(shù)組保存完整對話歷史很多開源訓(xùn)練框架默認用這種格式。我在實際項目中習(xí)慣把數(shù)據(jù)統(tǒng)一轉(zhuǎn)成對話格式因為即便單輪任務(wù)也可以看成一輪對話。統(tǒng)一格式的好處是方便后續(xù)增加多輪樣本模型在推理時也容易保持上下文連貫。這里有個新手經(jīng)常踩的坑不同格式混在一起喂給模型模型會學(xué)到混亂的交互預(yù)期。今天學(xué)的是“首輪直接答”明天學(xué)的是“設(shè)身處地寒暄兩句”最后表現(xiàn)就是時靈時不靈。舉個例子一條標準的對話格式樣本大概長這樣{ conversations: [ {role: system, content: 你是一個專業(yè)的Python開發(fā)助手。}, {role: user, content: 寫一個函數(shù)輸入一個整數(shù)列表返回所有偶數(shù)的平方。要求用列表推導(dǎo)式。}, {role: assistant, content: python\ndef square_evens(nums):\n return [x*x for x in nums if x % 2 0]\n\n\n這個實現(xiàn)用列表推導(dǎo)式一次完成過濾和映射兩個操作時間復(fù)雜度為O(n)。} ] }這個格式里system字段很重要它定義了模型的人設(shè)和行為約束。很多項目為了省事不寫system模型也能跑但泛化性和穩(wěn)定性會差很多。我通常會讓每條樣本都帶system并且準備一個默認的system兜底避免推理時傳空值導(dǎo)致模板錯亂。2.2 數(shù)據(jù)從哪來開源數(shù)據(jù)集、日志清洗與模型構(gòu)造SFT數(shù)據(jù)來源大致有三條路。第一條是直接用社區(qū)已有的開源SFT數(shù)據(jù)集適合快速驗證流程。但這類數(shù)據(jù)集往往質(zhì)量參差不齊可能有回答錯誤、格式混亂、重復(fù)過高等問題直接拿來訓(xùn)練模型很容易學(xué)到臟模式。第二條是從自己業(yè)務(wù)里撈真實數(shù)據(jù)這是最推薦的方式。比如你做客服機器人就把歷史工單里優(yōu)質(zhì)的“用戶問題-客服回答”對挑出來清洗。真實業(yè)務(wù)數(shù)據(jù)與目標場景高度匹配微調(diào)效果通常是最好的。第三條是用強模型構(gòu)造數(shù)據(jù)思路是用能力更強的模型批量生成問答對再人工或者自動篩選。這種方式能快速擴充數(shù)據(jù)規(guī)模但有個隱患強模型自己可能也會犯錯錯誤會原樣傳給學(xué)生模型。我見過有團隊用這種方式一天造了幾萬條數(shù)據(jù)訓(xùn)完模型回答流暢但事實錯誤率很高最后排查才發(fā)現(xiàn)數(shù)據(jù)源頭就錯了。所以用強模型造數(shù)據(jù)抽樣審核環(huán)節(jié)必須跟上。還有一個值得注意的點數(shù)據(jù)構(gòu)造時要考慮分布。如果你做的助手要覆蓋技術(shù)問答、閑聊、拒答三類場景數(shù)據(jù)比例就要和實際使用場景接近。我見過有項目把閑聊數(shù)據(jù)堆到80%結(jié)果模型變得很油滑正事不愛干了。數(shù)據(jù)分布偏了就改不回來重訓(xùn)成本非常昂貴。2.3 清洗與質(zhì)量控制這些細節(jié)決定微調(diào)上限數(shù)據(jù)清洗是SFT里最枯燥但最重要的一環(huán)。我一般按下面的順序處理先做全局去重重復(fù)樣本會讓模型對特定句式過擬合訓(xùn)練時看起來loss很低實際泛化很差。然后做長度過濾過短的樣本沒有學(xué)習(xí)價值過長的樣本會拖慢訓(xùn)練還要處理超過max length的截斷問題。接著做格式標準化統(tǒng)一標點符號、統(tǒng)一換行、統(tǒng)一代碼塊的標記語言讓模型學(xué)到干凈的模式。更關(guān)鍵的是內(nèi)容校驗。如果數(shù)據(jù)里有明顯的錯誤答案模型會當作正確答案來學(xué)。這塊我建議人力抽檢加規(guī)則過濾雙管齊下。比如代碼類數(shù)據(jù)可以嘗試直接執(zhí)行樣本來驗證正確性知識類數(shù)據(jù)可以用關(guān)鍵詞匹配或交叉驗證來做粗篩。用腳本刪掉明顯答非所問的樣本比多訓(xùn)幾百條數(shù)據(jù)有用得多。另外提醒一下編碼問題中文數(shù)據(jù)最容易在清洗時踩這個坑。統(tǒng)一轉(zhuǎn)成UTF-8去掉不可見字符和亂七八糟的空格檢查有沒有打斷JSON解析的轉(zhuǎn)義符。這些小事在幾百條數(shù)據(jù)時看不出問題數(shù)據(jù)量到幾萬條時任何一個臟字符都可能讓訓(xùn)練中斷或者模型輸出亂碼。2.4 用多少數(shù)據(jù)最合適不是多多益善SFT數(shù)據(jù)量沒有一個固定標準但可以給一個經(jīng)驗區(qū)間場景單一的任務(wù)型微調(diào)幾千條高質(zhì)量樣本就夠通用助手的對話能力微調(diào)一到三萬條比較合適再往上增加數(shù)據(jù)收益會明顯遞減。原因前面說過SFT主要是行為對齊模型不需要通過SFT學(xué)海量新知識它只需要足夠多的示范來理解你的指令格式和輸出偏好。我實操下來的體會是數(shù)據(jù)質(zhì)量每提升一檔對最終效果的影響遠大于數(shù)據(jù)量翻倍。同樣一萬條數(shù)據(jù)粗洗和精洗之后的模型效果完全不是一個級別。寧可只有五千條高質(zhì)量數(shù)據(jù)也別硬湊兩萬條垃圾數(shù)據(jù)。額外的數(shù)據(jù)有時反而會引入噪聲讓模型在部分場景下的表現(xiàn)倒退。還有一個容易被忽略的事情驗證集的劃分。SFT不是用完全部數(shù)據(jù)就萬事大吉要留出一部分樣本做驗證。我在每次訓(xùn)練前都固定切出5%-10%的數(shù)據(jù)做驗證集訓(xùn)練過程中持續(xù)觀察驗證集loss。如果訓(xùn)練集loss在降驗證集loss在漲那就說明過擬合了及時停掉可以省下大量時間。3. 訓(xùn)練配置與超參數(shù)把SFT跑穩(wěn)的核心3.1 全參微調(diào)還是LoRA看條件選方案SFT的實現(xiàn)方式主要分成全參微調(diào)和參數(shù)高效微調(diào)兩大類LoRA是后者的典型代表。全參微調(diào)是讓基座模型的全部參數(shù)都參與更新效果上限最高但顯存和算力要求也最狠。以7B模型為例全參微調(diào)用AdamW優(yōu)化器動輒需要60GB以上的顯存單張消費級顯卡基本做不了。LoRA則是凍結(jié)原始權(quán)重只訓(xùn)練注入的低秩矩陣顯存占用大幅下降7B模型的LoRA訓(xùn)練在24GB顯存下就能跑起來。從效果角度說如果數(shù)據(jù)量足夠大、任務(wù)足夠復(fù)雜全參微調(diào)確實能學(xué)到更多細微變化。但對于大多數(shù)業(yè)務(wù)場景LoRA的效果已經(jīng)非常接近全參微調(diào)而且資源消耗少一個量級。我個人的選擇標準是24GB以下顯存無腦用LoRA能上全參微調(diào)的資源優(yōu)先把多余算力投給數(shù)據(jù)清洗和評估而不是一味追求全參更新。LoRA還有一個額外優(yōu)勢就是多個adapter可以共用一個基座模型不同任務(wù)切換非常方便。不過LoRA有個小坑如果基座模型本身難以通過低秩更新達到理想效果比如領(lǐng)域知識嚴重不足LoRA的表現(xiàn)就會比全參微調(diào)差一截。這種情況你得先評估是“不會聽指令”還是“不懂這個領(lǐng)域”前者LoRA能解決后者可能需要考慮增量預(yù)訓(xùn)練或者換更強的基座。3.2 關(guān)鍵超參數(shù)選擇與背后的邏輯SFT常用的超參數(shù)并不復(fù)雜但每個參數(shù)的取值范圍和背后邏輯一定要清楚。學(xué)習(xí)率是第一個要小心設(shè)置的參數(shù)。全參微調(diào)一般用1e-5到2e-5LoRA則可以用到1e-4到2e-4。因為LoRA只更新很少的參數(shù)學(xué)習(xí)率可以步子大一點。如果學(xué)習(xí)率設(shè)得太高模型會快速忘掉預(yù)訓(xùn)練學(xué)到的知識表現(xiàn)出來就是loss降低很快但輸出開始胡言亂語。訓(xùn)練輪數(shù)同樣需要克制。高質(zhì)量SFT數(shù)據(jù)集2到4個epoch是比較穩(wěn)的范圍。數(shù)據(jù)量很大時甚至1個epoch就夠了。這里有個常見的認知誤區(qū)多訓(xùn)幾輪不一定是好事。模型反復(fù)看過同一批樣本后會對訓(xùn)練集的表達方式過度擬合導(dǎo)致泛化能力下降。我在訓(xùn)練時會同時盯著訓(xùn)練loss和驗證loss一旦驗證loss開始回升就立即停止通常能比固定epoch訓(xùn)練得到更好的結(jié)果。批大小和梯度累積對SFT也很關(guān)鍵。因為顯存限制單卡一般只能放很小batch但batch太小會導(dǎo)致梯度噪聲大、訓(xùn)練不穩(wěn)定。解決辦法是設(shè)置一個較小的per_device_batch_size然后用梯度累積湊到等效batch size。比如per_device_batch_size1gradient_accumulation_steps16等效batch size就是16。我習(xí)慣把等效batch size控制在32到64之間既穩(wěn)定又不會太慢。權(quán)重衰減一般設(shè)為0.01warmup ratio設(shè)0.03左右這些是經(jīng)驗值大多數(shù)場景直接照用不會出錯。學(xué)習(xí)率調(diào)度器推薦cosine它在訓(xùn)練末期能把學(xué)習(xí)率平滑降到很低有助于收斂到更好的局部最優(yōu)。3.3 LoRA的rank、alpha和target_modules怎么定LoRA的rank是低秩矩陣的維度直接影響可訓(xùn)練參數(shù)量和表達能力。常見的實踐值是8、16、32。rank太小模型學(xué)不到足夠復(fù)雜的映射rank太大訓(xùn)練參數(shù)變多但收益不一定成比例提升。我通常先用16跑一個小實驗觀察效果后再決定要不要加大。alpha是縮放系數(shù)一般設(shè)置為rank的兩倍比如rank16時alpha32。這個比例在大多數(shù)情況下表現(xiàn)良好。target_modules的選擇是個容易被忽視的細節(jié)。在Transformer結(jié)構(gòu)里L(fēng)oRA可以注入到自注意力層的q/k/v/o投影矩陣也可以注入到前饋網(wǎng)絡(luò)的gate/up/down投影。我測試下來同時注入注意力模塊和前饋模塊效果比只注入注意力要好尤其在做中文指令跟隨任務(wù)時。原因是前饋網(wǎng)絡(luò)承擔(dān)了大量知識記憶的功能通過低秩更新微調(diào)這部分能讓模型更快適應(yīng)訓(xùn)練數(shù)據(jù)里出現(xiàn)的表達習(xí)慣。還有兩個細節(jié)值得提。第一bias參數(shù)通常設(shè)成not update保持和基座模型一致減少訓(xùn)練參數(shù)總量。第二lora_dropout建議設(shè)置0.05到0.1防止過擬合但如果驗證集表現(xiàn)正常dropout設(shè)小一點也能提升收斂速度這個可以微調(diào)。3.4 顯存與訓(xùn)練穩(wěn)定性配置跑SFT之前先想清楚兩個問題用不用梯度檢查點用不用混合精度。梯度檢查點是個顯存換速度的手段開啟后顯存占用可以降低大約30%-40%代價是訓(xùn)練速度變慢。對7B模型加LoRA的場景我建議開啟它因為顯存往往比時間更緊張?；旌暇确矫嬗ミ_較新的卡建議直接用bf16它的動態(tài)范圍和穩(wěn)定性都優(yōu)于fp16不容易出現(xiàn)loss溢出為NaN的問題。老顯卡只支持fp16時記得加上loss scale策略并持續(xù)監(jiān)控訓(xùn)練日志。序列長度max seq length是另一個需要仔細權(quán)衡的配置。它決定模型能看到多長的上下文。設(shè)得太短長對話會被截斷模型學(xué)不到完整的依賴關(guān)系設(shè)得太長顯存占用隨長度線性增長訓(xùn)練速度也會下降。我建議先統(tǒng)計一下訓(xùn)練數(shù)據(jù)中最長的樣本長度然后設(shè)定為覆蓋80%-90%樣本的長度值剩下的長樣本做截斷處理這樣性價比最高。還有兩個工程層面的配置容易出問題。一個是保存間隔建議同時按“步數(shù)”和“時間”兩個維度設(shè)置長時間訓(xùn)練時至少每小時能看到一個可用的checkpoint避免意外中斷后白白浪費時間。另一個是日志打印頻率打開日志打印每10步打一次loss監(jiān)控文本生成。因為有時候loss很漂亮實際生成的文本已經(jīng)完全崩壞只看數(shù)字發(fā)現(xiàn)不了問題。4. 完整實操從原始問答到微調(diào)上線4.1 環(huán)境準備與最低硬件要求實操第一步是準備環(huán)境。我的建議是先建一個獨立的Python環(huán)境避免依賴沖突。核心依賴就是深度學(xué)習(xí)框架、模型加載庫、數(shù)據(jù)集庫和LoRA庫這幾樣就能跑通整個流程。GPU方面如果你想微調(diào)7B量級的開源基座模型24GB顯存是甜點位用LoRA加梯度檢查點可以比較舒服地跑起來。如果顯存只有16GB可以通過4bit量化加載基座模型仍然能完成LoRA訓(xùn)練只是量化后訓(xùn)練精度略有損失。這里有個建議第一次跑通全流程時不要直接上大模型。先用幾億參數(shù)量級的小模型跑通數(shù)據(jù)加載、訓(xùn)練、保存、推理的閉環(huán)再換成目標模型。小模型調(diào)試成本低跑完一個epoch只需幾分鐘任何代碼問題都能快速暴露。我每次接到新任務(wù)都先用小模型驗證數(shù)據(jù)和代碼確認無誤后再換大模型訓(xùn)練這套流程幫我省下了大量調(diào)試時間?；Ｐ瓦x擇的核心原則是中英文、代碼、數(shù)學(xué)能力匹配你的目標場景且盡量選擇指令跟隨能力已經(jīng)不錯的版本。如果底子太差SFT要補的課太多效果必然受限。4.2 數(shù)據(jù)格式轉(zhuǎn)換腳本不管原始數(shù)據(jù)是Excel、JSON還是數(shù)據(jù)庫導(dǎo)出的CSV第一步都要統(tǒng)一轉(zhuǎn)成訓(xùn)練框架能讀入的格式。下面這個腳本可以把簡單的“問題-答案”列表轉(zhuǎn)成對話格式的JSONL文件import json # 原始數(shù)據(jù)假設(shè)每條是 {question: ..., answer: ...} raw_data [ { question: 什么是列表推導(dǎo)式, answer: 列表推導(dǎo)式是Python中一種簡潔地創(chuàng)建列表的語法格式為 [表達式 for 元素 in 可迭代對象 if 條件]。 }, # 更多樣本... ] SYSTEM_PROMPT 你是一個專業(yè)的中文技術(shù)助手請用簡潔準確的語言回答用戶的問題。 def convert_to_sharegpt(item): return { conversations: [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: item[question]}, {role: assistant, content: item[answer]}, ] } with open(sft_train.jsonl, w, encodingutf-8) as f: for item in raw_data: f.write(json.dumps(convert_to_sharegpt(item), ensure_asciiFalse) \n) print(f轉(zhuǎn)換完成共 {len(raw_data)} 條樣本)轉(zhuǎn)換腳本的核心邏輯就是把每條樣本包成system、user、assistant三段。有人問system每次都要寫嗎我的建議是默認都寫哪怕內(nèi)容一樣。這樣模型在訓(xùn)練中會穩(wěn)定學(xué)習(xí)到“先讀人設(shè)再看問題”的行為模式。另外寫入文件時一定加ensure_asciiFalse否則中文會被轉(zhuǎn)成\uXXXX的Unicode轉(zhuǎn)義序列可讀性極差后續(xù)檢查數(shù)據(jù)非常痛苦。4.3 訓(xùn)練腳本與關(guān)鍵配置數(shù)據(jù)準備好之后訓(xùn)練腳本的核心部分如下。這個腳本以加載基座模型為基礎(chǔ)套上LoRA配置然后通過訓(xùn)練參數(shù)控制訓(xùn)練過程from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments, Trainer from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training from datasets import load_dataset # 1. 加載基座模型和tokenizer # base_model_path 換成你手中的基座模型路徑 model AutoModelForCausalLM.from_pretrained( base_model_path, torch_dtypebf16, device_mapauto, ) tokenizer AutoTokenizer.from_pretrained(base_model_path) # 2. 設(shè)置pad token。如果tokenizer沒有pad token用eos代替 if tokenizer.pad_token is None: tokenizer.pad_token tokenizer.eos_token model.config.pad_token_id tokenizer.eos_token_id # 3. 配置LoRA lora_config LoraConfig( r16, lora_alpha32, target_modules[ q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj, ], lora_dropout0.05, biasnone, task_typeCAUSAL_LM, ) model get_peft_model(model, lora_config) model.print_trainable_parameters() # 打印可訓(xùn)練參數(shù)量 # 4. 定義訓(xùn)練參數(shù) training_args TrainingArguments( output_dir./sft_checkpoints, per_device_train_batch_size1, gradient_accumulation_steps16, learning_rate1e-4, num_train_epochs3, logging_steps10, save_steps200, save_total_limit3, bf16True, gradient_checkpointingTrue, optimadamw_torch, lr_scheduler_typecosine, warmup_ratio0.03, weight_decay0.01, report_tonone, ) # 5. 加載數(shù)據(jù)集并按模板格式處理 dataset load_dataset(json, data_filessft_train.jsonl, splittrain) def format_chat(example): # 把conversations拼成模型需要的模板文本 # 這里用簡單的拼接方式實際項目中建議使用tokenizer.apply_chat_template messages example[conversations] text for msg in messages: role msg[role] content msg[content] if role system: text f系統(tǒng){content}\n elif role user: text f用戶{content}\n else: text f助手{content}\n text 助手 return {text: text} tokenized_dataset dataset.map( lambda x: tokenizer( format_chat(x)[text], truncationTrue, max_length2048, paddingFalse, ), remove_columnsdataset.column_names, ) # 6. 創(chuàng)建Trainer并開始訓(xùn)練 trainer Trainer( modelmodel, argstraining_args, train_datasettokenized_dataset, tokenizertokenizer, ) trainer.train()這套配置有幾個數(shù)值值得解釋一下。per_device_train_batch_size1配gradient_accumulation_steps16的組合是為了在24GB顯存下跑7B模型的同時保持batch size不至過小。學(xué)習(xí)率1e-4是LoRA的常見起點如果你發(fā)現(xiàn)訓(xùn)練早期loss出現(xiàn)明顯波動可以降到5e-5繼續(xù)試。max_length設(shè)2048是因為大多數(shù)SFT樣本并不需要那么長的上下文這個長度在顯存和表達能力之間比較均衡。另外訓(xùn)練時打印可訓(xùn)練參數(shù)量是一個好習(xí)慣。一個7B模型的LoRA訓(xùn)練可訓(xùn)練參數(shù)通常只在幾千萬到一億左右占比不到2%?？吹竭@個數(shù)字你就明白為什么LoRA這么快了。4.4 推理驗證與adapter合并訓(xùn)練完成后LoRA的權(quán)重是單獨保存的并不會直接寫回基座模型。推理之前需要先加載adapter驗證效果。加載方式有兩種一種是直接生成適合快速驗證另一種是把adapter合并回基座模型生成一個新模型適合部署上線。from peft import PeftModel # 加載基座模型 base_model AutoModelForCausalLM.from_pretrained( base_model_path, torch_dtypebf16, device_mapauto, ) tokenizer AutoTokenizer.from_pretrained(base_model_path) if tokenizer.pad_token is None: tokenizer.pad_token tokenizer.eos_token # 加載訓(xùn)練好的LoRA adapter model PeftModel.from_pretrained(base_model, ./sft_checkpoints/checkpoint-600) model.eval() # 合并adapter到基座模型部署時推薦 merged_model model.merge_and_unload() merged_model.save_pretrained(merged_model) tokenizer.save_pretrained(merged_model)合并這一步值得多說兩點。第一合并后的模型體積和基座模型一樣大但推理時不再需要額外的adapter管理可以直接用常規(guī)方式加載和部署。如果你用的是vLLM這類推理框架合并后的模型兼容性更好。第二合并操作會修改全部權(quán)重所以合并前一定要把原始基座模型備份好。有一次我誤操作直接覆蓋了原始權(quán)重只能重新下載模型那個下載時間足夠?qū)懸黄虏┛土恕ｒ炞C模型效果時我建議同時準備三組測試用例第一組是訓(xùn)練數(shù)據(jù)里沒見過的類似題目看模型泛化能力第二組是訓(xùn)練數(shù)據(jù)里出現(xiàn)過的原題看模型記住了沒有第三組是稍微挑戰(zhàn)指令格式的用例比如要求它用表格輸出、用特定語氣回答看它是不是真的理解了指令跟隨。5. 常見問題與排查技巧實錄5.1 Loss降了模型反而變傻了這個現(xiàn)象出現(xiàn)過太多次了。訓(xùn)練日志上loss一路下降看起來非常健康結(jié)果拿出去一測模型回答質(zhì)量反而比微調(diào)前更差。遇到這種情況第一個懷疑對象就是數(shù)據(jù)質(zhì)量。SFT模型會把訓(xùn)練數(shù)據(jù)中的錯誤、噪聲和格式混亂原樣學(xué)進去。如果loss降得很快說明模型記性好把臟數(shù)據(jù)也記住了。第二個懷疑對象是數(shù)據(jù)分布。比如訓(xùn)練數(shù)據(jù)里80%都是“知識問答”20%是“代碼生成”模型自然會偏向知識問答的輸出風(fēng)格代碼能力反而不升反降。檢查一下訓(xùn)練數(shù)據(jù)的類別占比把比例往目標場景調(diào)整往往是這一類問題最簡單的解決辦法。第三個原因可能是驗證集劃分不合適。如果你留出的驗證集和訓(xùn)練集高度相似驗證loss會一直很樂觀等到真正上線面對新數(shù)據(jù)時才暴露問題。我建議驗證集盡量和線上場景保持一致而不是隨機抽樣。5.2 災(zāi)難性遺忘怎么控制災(zāi)難性遺忘是SFT最頭疼的問題之一表現(xiàn)是微調(diào)后模型對目標場景表現(xiàn)很好但通用能力明顯倒退比如數(shù)學(xué)變差、常識錯誤增多。根本原因在于SFT訓(xùn)練數(shù)據(jù)分布和預(yù)訓(xùn)練數(shù)據(jù)分布差距太大模型在擬合訓(xùn)練數(shù)據(jù)的過程中把原有的知識表達式覆蓋掉了。控制遺忘的方法有幾個第一個是降低學(xué)習(xí)率。學(xué)習(xí)率越高權(quán)重改動幅度越大遺忘越嚴重。我遇到過把學(xué)習(xí)率從1e-4降到5e-5之后目標任務(wù)效果只差一點點但通用能力明顯變好。第二個方法是混合通用數(shù)據(jù)。在目標SFT數(shù)據(jù)里摻入10%-20%的通用指令數(shù)據(jù)或者預(yù)訓(xùn)練語料讓模型在原分布附近“鞏固記憶”。第三個方法是做多任務(wù)混合訓(xùn)練。把多個場景的數(shù)據(jù)混在一起訓(xùn)而不是只訓(xùn)一個單獨任務(wù)模型對指令的理解會更穩(wěn)健。如果你已經(jīng)訓(xùn)練完了發(fā)現(xiàn)模型通用能力受損還有一個補救手段用低學(xué)習(xí)率在通用數(shù)據(jù)上做幾輪“恢復(fù)訓(xùn)練”通常能讓通用能力回來一部分但要謹慎控制輪數(shù)恢復(fù)過頭了目標任務(wù)的收益又會丟掉。5.3 輸出成了復(fù)讀機或者出現(xiàn)亂碼生成階段出現(xiàn)復(fù)讀機很多人第一反應(yīng)是調(diào)采樣參數(shù)比如降低temperature、調(diào)整repetition penalty但從SFT側(cè)來看根因常常在訓(xùn)練階段。學(xué)習(xí)率過高是常見元兇模型在訓(xùn)練集上過擬合生成的token序列容易掉進重復(fù)循環(huán)。把學(xué)習(xí)率降下來重新訓(xùn)練復(fù)讀現(xiàn)象經(jīng)常自動消失。數(shù)據(jù)里的重復(fù)樣本也值得排查。如果某條樣本在數(shù)據(jù)集中重復(fù)了幾十次模型對它的記憶特別深輸出時就容易反復(fù)橫跳。用去重腳本把完全重復(fù)和近似重復(fù)的樣本清理掉能有效緩解這個問題。至于亂碼問題優(yōu)先檢查tokenizer的pad token設(shè)置。很多基座模型的tokenizer沒有pad token訓(xùn)練時如果不指定系統(tǒng)會拿eos token來湊可能導(dǎo)致注意力掩碼錯亂。另一個檢查點是數(shù)據(jù)文本本身確認沒有混入非法字符或者編碼不一致的文本。5.4 顯存OOM的排查路線訓(xùn)練中途報CUDA out of memory是最常見的工程問題但解決辦法并不復(fù)雜按順序處理就好。先減per_device_batch_size從4減到2再減到1。如果batch1還是OOM說明單條樣本太大檢查max_length是不是設(shè)得過高適當截斷長樣本。接著開啟gradient_checkpointing這個能省不少顯存。還不行就考慮換LoRA或者上量化。從全參微調(diào)切到LoRA顯存占用能下降一半以上LoRA再加4bit量化加載7B模型的訓(xùn)練甚至可以壓到16GB顯存以內(nèi)。有一點要提醒batch變小后訓(xùn)練穩(wěn)定性會變差記得同步調(diào)大gradient_accumulation_steps把等效batch size維持住。用大batch換穩(wěn)定用累積換等效是解決顯存問題的通用思路。5.5 微調(diào)效果怎么評估才靠譜很多團隊評估SFT效果只看訓(xùn)練loss這是遠遠不夠的。loss只能說明模型有沒有擬合訓(xùn)練數(shù)據(jù)不能說明模型能不能解決真實問題。我自己的評估體系分三層第一層是規(guī)則指標如果任務(wù)是分類或者抽取計算準確率、F1這些客觀指標第二層是生成質(zhì)量指標比如代碼任務(wù)的passk、文本摘要的ROUGE分但這些只能做參考不能完全替代人工第三層是人工評測準備幾十條覆蓋各場景的測試用例逐個看模型輸出按有用性、正確性、格式規(guī)范度打分。人工評測雖然費時但它最能暴露問題。我通常會讓不直接參與訓(xùn)練的人來做評測這樣能避免“自己訓(xùn)的模型怎么看都好”的主觀偏差。打分表也不要搞得太復(fù)雜三到五個維度足夠了重點看有沒有出現(xiàn)答非所問、格式混亂、事實錯誤這三類致命問題。模型上線前至少做兩輪評估第一輪發(fā)現(xiàn)問題并重訓(xùn)第二輪確認修復(fù)效果這樣形成閉環(huán)才算真正跑完一次SFT。最后說一個我個人的習(xí)慣每次SFT訓(xùn)練跑完之后把所有配置、數(shù)據(jù)統(tǒng)計結(jié)果和評測記錄整理成一個簡單的文檔留檔。別小看這一步模型效果不好時想回溯原因這份記錄能幫你快速定位是數(shù)據(jù)問題、參數(shù)問題還是訓(xùn)練代碼問題。我做過的項目里好幾輪模型效果倒退都是靠文檔記錄快速查出了原因。如果你正準備開始自己的SFT實驗建議也養(yǎng)成這個習(xí)慣。