每天都會(huì)收到不少私信問(wèn)的問(wèn)題高度雷同——從零訓(xùn)練一個(gè)大模型到底要多少?gòu)埧ㄎ⒄{(diào)用LoRA還是全量微調(diào)本地部署用Ollama還是vLLM這些問(wèn)題看著分散其實(shí)背后是同一套底層邏輯在支撐。訓(xùn)練、微調(diào)、推理三個(gè)環(huán)節(jié)各自吃什么樣的資源解決什么問(wèn)題你只要把這三件事從原理上想明白后面所有選型、顯存估算、參數(shù)調(diào)節(jié)就都不會(huì)慌。這篇文章不打算講那種紙上談兵的大道理而是以我這些年實(shí)際做模型訓(xùn)練和部署的經(jīng)驗(yàn)把大模型訓(xùn)練、微調(diào)與推理框架的底層邏輯和工程落地要點(diǎn)拆開(kāi)講。無(wú)論你是剛?cè)腴T想規(guī)劃學(xué)習(xí)路線還是已經(jīng)在跑微調(diào)任務(wù)但對(duì)部署細(xì)節(jié)拿不準(zhǔn)這里面提到的很多細(xì)節(jié)都是你按文檔做一遍未必能踩到、但最終一定會(huì)遇到的東西。1. 訓(xùn)練、微調(diào)與推理底層邏輯先理清1.1 訓(xùn)練、微調(diào)、推理三者到底差在哪很多人容易把訓(xùn)練和微調(diào)混為一談?dòng)钟X(jué)得推理就是把模型加載起來(lái)跑一下屬于“最簡(jiǎn)單的環(huán)節(jié)”。實(shí)際從系統(tǒng)角度看三者的關(guān)系更像是“地基、改造、使用”。訓(xùn)練通常指預(yù)訓(xùn)練。模型從隨機(jī)權(quán)重開(kāi)始在幾萬(wàn)億token的大規(guī)模語(yǔ)料上反復(fù)做前向計(jì)算和反向傳播逐步學(xué)習(xí)語(yǔ)言本身的統(tǒng)計(jì)規(guī)律。這個(gè)過(guò)程追求的是模型對(duì)世界的通用理解工程上關(guān)注的核心指標(biāo)是Loss能否穩(wěn)定下降、訓(xùn)練吞吐能做到多少token每秒、GPU利用率能不能打滿。預(yù)訓(xùn)練不是普通團(tuán)隊(duì)能隨便碰的大部分情況下我們見(jiàn)到的都是別人已經(jīng)訓(xùn)練好的底座模型。微調(diào)是基于預(yù)訓(xùn)練權(quán)重繼續(xù)訓(xùn)練。區(qū)別在于微調(diào)用的數(shù)據(jù)量通常很小幾千條到幾十萬(wàn)條不等目標(biāo)非常明確——讓模型學(xué)會(huì)某個(gè)特定領(lǐng)域的話術(shù)、某種輸出格式或者對(duì)齊到更貼近人的表達(dá)。微調(diào)過(guò)程同樣存在前向和反向傳播但因?yàn)閿?shù)據(jù)量小、訓(xùn)練時(shí)間短它對(duì)硬件的要求比預(yù)訓(xùn)練低了好幾個(gè)數(shù)量級(jí)。這也是為什么個(gè)人開(kāi)發(fā)者用一張消費(fèi)級(jí)顯卡就能做LoRA微調(diào)。推理則是模型投入使用的階段。此時(shí)模型參數(shù)被凍結(jié)不再有任何梯度計(jì)算輸入一句話模型做一次前向計(jì)算把預(yù)測(cè)結(jié)果輸出出來(lái)。推理關(guān)注的不再是Loss下降而是首token延遲、每秒生成token數(shù)、顯存占用、并發(fā)能力這些指標(biāo)。同一個(gè)模型用不對(duì)推理框架吞吐可能差出三到五倍。拿生活類比的話訓(xùn)練是“九年義務(wù)教育”微調(diào)是“考前專項(xiàng)突擊”推理是“上考場(chǎng)答題”。義務(wù)教育階段知識(shí)面廣專項(xiàng)突擊解決特定題型考場(chǎng)上一道題只給有限時(shí)間。三者的目標(biāo)不同評(píng)價(jià)標(biāo)準(zhǔn)和資源消耗方式自然完全不同。1.2 為什么工程上必須把三個(gè)階段拆開(kāi)看很多項(xiàng)目出問(wèn)題根源就在于把三個(gè)階段混在一個(gè)框架里考慮。有人拿著訓(xùn)練的思路去做推理服務(wù)結(jié)果并發(fā)一上來(lái)就崩也有人把推理框架當(dāng)成訓(xùn)練工具發(fā)現(xiàn)根本沒(méi)法做梯度回傳。從框架設(shè)計(jì)角度看訓(xùn)練框架必須支持自動(dòng)求導(dǎo)、梯度累積、模型并行、優(yōu)化器狀態(tài)管理每一步都要維護(hù)大量的中間狀態(tài)。而推理框架恰恰相反它要想辦法把這些中間狀態(tài)盡量砍掉或者壓縮換取更快的響應(yīng)和更高的吞吐。一個(gè)最有代表性的優(yōu)化是KV Cache它把之前算過(guò)的注意力鍵值對(duì)緩存下來(lái)避免每一步都重新計(jì)算這是推理框架獨(dú)有的優(yōu)化手段訓(xùn)練階段根本不需要。另一個(gè)容易被忽視的差異是評(píng)估標(biāo)準(zhǔn)。訓(xùn)練看的是Loss曲線微調(diào)看的是驗(yàn)證集指標(biāo)而推理看的是線上延遲和成本。我見(jiàn)過(guò)不少團(tuán)隊(duì)微調(diào)做完后模型驗(yàn)證指標(biāo)很漂亮但一上推理服務(wù)就發(fā)現(xiàn)顯存不夠、速度太慢最后只能降并發(fā)、砍上下文長(zhǎng)度。這就是因?yàn)槿齻€(gè)階段沒(méi)有提前統(tǒng)一規(guī)劃。比如在選微調(diào)策略時(shí)如果知道上線環(huán)境是單卡32G就不會(huì)貿(mào)然用全量微調(diào)去追求極致效果而是優(yōu)先考慮能合并回權(quán)重的LoRA方案讓推理時(shí)模型結(jié)構(gòu)保持干凈不增加額外負(fù)載。1.3 一張圖看懂三者的資源差異這里我直接列一個(gè)對(duì)比表方便大家在做技術(shù)方案時(shí)快速對(duì)照。對(duì)比維度預(yù)訓(xùn)練微調(diào)推理參數(shù)量更新全量更新全量或部分更新完全不更新數(shù)據(jù)規(guī)模萬(wàn)億token級(jí)千到百萬(wàn)條樣本無(wú)訓(xùn)練數(shù)據(jù)核心計(jì)算前向反向傳播前向反向傳播僅前向傳播顯存大頭權(quán)重梯度優(yōu)化器激活權(quán)重梯度優(yōu)化器激活LoRA可壓縮權(quán)重KV Cache關(guān)鍵指標(biāo)Loss、吞吐驗(yàn)證集效果、訓(xùn)練速度延遲、吞吐、并發(fā)量常用框架DeepSpeed、Megatrontransformers、peft、acceleratevLLM、Ollama、llama.cpp注意看顯存這一行預(yù)訓(xùn)練和微調(diào)都要吃梯度和優(yōu)化器狀態(tài)所以同樣的模型規(guī)模下訓(xùn)練態(tài)比推理態(tài)顯存需求高很多。很多人問(wèn)“GPU顯存容量到底是按推理算還是按訓(xùn)練算”答案很簡(jiǎn)單完全看你要干什么。只做推理就按推理算要做微調(diào)就按訓(xùn)練算最好還要留出余量。我自己見(jiàn)過(guò)7B模型在16G顯存的卡上推理毫無(wú)壓力但同樣這張卡想全量微調(diào)7B模型連權(quán)重都裝不下。2. 微調(diào)方案怎么選全量、Freeze與LoRA實(shí)戰(zhàn)對(duì)比2.1 全量微調(diào)什么時(shí)候值得上全量微調(diào)是對(duì)所有模型參數(shù)做梯度更新效果理論上最接近“為這個(gè)領(lǐng)域?qū)ｉT定制”。但它有兩個(gè)硬門檻顯存大、數(shù)據(jù)多。以7B模型為例如果用AdamW優(yōu)化器做全量微調(diào)顯存需要同時(shí)容納權(quán)重、梯度、優(yōu)化器狀態(tài)和激活值16G顯卡基本沒(méi)戲通常要80G以上才舒服。數(shù)據(jù)方面全量微調(diào)一般需要足夠多的高質(zhì)量領(lǐng)域數(shù)據(jù)否則很容易把預(yù)訓(xùn)練學(xué)到的通用能力覆蓋掉出現(xiàn)“災(zāi)難性遺忘”。我的建議是只有當(dāng)你手里的數(shù)據(jù)量足夠大、任務(wù)確實(shí)需要模型在全局層面發(fā)生改變時(shí)才考慮全量微調(diào)。否則用全量微調(diào)只是“看起來(lái)更正統(tǒng)”實(shí)際操作中既慢又費(fèi)卡效果還不一定比LoRA好。2.2 Freeze微調(diào)輕量場(chǎng)景的另一種解Freeze微調(diào)也叫凍結(jié)微調(diào)意思是把底座模型的大部分層凍住只訓(xùn)練一部分靠近任務(wù)輸出的層或者只訓(xùn)練新加的任務(wù)頭。這種方案在傳統(tǒng)遷移學(xué)習(xí)里非常常見(jiàn)在CV領(lǐng)域尤其典型比如很多人用YOLOv8訓(xùn)練自己的數(shù)據(jù)集時(shí)如果數(shù)據(jù)量小就會(huì)凍住Backbone只微調(diào)Head部分。Freeze微調(diào)的優(yōu)勢(shì)是顯存占用小、速度快不容易把通用特征沖掉。但它的局限也很明顯可學(xué)習(xí)的參數(shù)太少對(duì)復(fù)雜任務(wù)的適配能力有限。如果只是想改變輸出格式比如讓模型學(xué)會(huì)輸出JSONFreeze微調(diào)夠用。如果要模型具備新的推理能力光靠Freeze微調(diào)往往不夠得靠LoRA或者全量微調(diào)來(lái)注入了。2.3 LoRA原理解讀與實(shí)戰(zhàn)經(jīng)驗(yàn)LoRA是目前最主流的參數(shù)高效微調(diào)方法。它背后的思路非常巧妙預(yù)訓(xùn)練模型雖然參數(shù)量巨大但真正需要更新以適配新任務(wù)的“增量權(quán)重”其實(shí)處于一個(gè)低秩空間。所以LoRA不會(huì)直接去更新原始的權(quán)重矩陣而是凍結(jié)原始權(quán)重在旁邊加兩個(gè)低秩的小矩陣A和B用這兩個(gè)小矩陣的乘積去模擬權(quán)重增量。假設(shè)原始矩陣維度是4096×4096理論上增量矩陣也是4096×4096但LoRA把它拆成4096×8和8×4096兩個(gè)小矩陣參數(shù)總量從1600多萬(wàn)降到了6萬(wàn)多少了兩百多倍。訓(xùn)練完以后又可以把A和B合并進(jìn)原始權(quán)重推理時(shí)就是普通模型沒(méi)有任何額外計(jì)算量。實(shí)戰(zhàn)中我強(qiáng)烈建議除非你有明確理由否則微調(diào)第一個(gè)版本直接上LoRA。選r值時(shí)一般從8開(kāi)始顯存和效果都能兼顧r太小比如1或2表達(dá)能力不足r太大比如64以上訓(xùn)練慢而且容易過(guò)擬合。alpha通常設(shè)成r的兩倍學(xué)習(xí)率用2e-4左右跑對(duì)話任務(wù)是一個(gè)比較穩(wěn)的起點(diǎn)。2.4 三種方案選型心法方案更新參數(shù)顯存需求訓(xùn)練速度適用場(chǎng)景難度全量微調(diào)全部參數(shù)高慢大規(guī)模領(lǐng)域數(shù)據(jù)、全局能力重塑高Freeze微調(diào)部分層低快輸出格式變化、任務(wù)頭適配低LoRA低秩矩陣低快大多數(shù)場(chǎng)景兼顧效果與成本中選型核心就一句話顯存和成本允許的情況下效果優(yōu)先不允許的情況下先LoRA。LoRA在線評(píng)測(cè)指標(biāo)可能比全量微調(diào)低那么一兩個(gè)點(diǎn)但在絕大多數(shù)業(yè)務(wù)場(chǎng)景里這一兩個(gè)點(diǎn)根本感知不到而成本卻差出好幾倍。3. 推理部署不只“跑起來(lái)”那么簡(jiǎn)單3.1 推理的“隱藏成本”和四個(gè)優(yōu)化方向很多人第一次部署大模型時(shí)最大的誤區(qū)是認(rèn)為“能跑起來(lái)”就算部署成功。實(shí)際上同一個(gè)模型用裸的transformers庫(kù)跑和用vLLM這類專用推理框架跑吞吐差距動(dòng)輒三到五倍顯存占用也能差出一倍。真正的推理工程繞不開(kāi)四個(gè)優(yōu)化方向。第一個(gè)是量化。把FP16權(quán)重壓縮成INT8甚至INT4顯存需求和計(jì)算量都會(huì)明顯下降。常用工具包括bitsandbytes、AWQ、GPTQ本地部署時(shí)GGUF量化則非常流行。量化會(huì)有精度損失但7B模型INT8量化后大多數(shù)任務(wù)效果退化可以忽略。第二個(gè)是KV Cache優(yōu)化。注意力計(jì)算過(guò)程中產(chǎn)生的Key和Value會(huì)隨著生成token數(shù)增長(zhǎng)而膨脹如果每個(gè)請(qǐng)求都重新計(jì)算速度會(huì)非常慢。KV Cache就是把這些歷史信息緩存起來(lái)空間換時(shí)間。但KV Cache本身也很占顯存所以推理框架會(huì)做PagedAttention之類的頁(yè)式管理像操作系統(tǒng)管理內(nèi)存一樣管理KV Cache減少碎片。第三個(gè)是連續(xù)批處理。傳統(tǒng)批處理要等一個(gè)批次全部生成完才換下一批效率低下。連續(xù)批處理是當(dāng)一個(gè)請(qǐng)求生成結(jié)束后立即插入新的請(qǐng)求讓GPU始終處在高利用率狀態(tài)。這個(gè)特性決定了高并發(fā)場(chǎng)景下能不能扛住流量。第四個(gè)是流式輸出與張量并行。流式輸出解決首字延遲體驗(yàn)不必等整段生成完畢再返回。張量并行則是把模型權(quán)重切到多張卡上適合單卡放不下的超大模型。多卡部署時(shí)還要考慮通信開(kāi)銷不能線性提升性能。3.2 部署框架選型vLLM、Ollama、llama.cpp怎么選現(xiàn)在主流的推理部署框架我來(lái)逐個(gè)給結(jié)論。vLLM是目前生產(chǎn)環(huán)境用下來(lái)最穩(wěn)的高吞吐方案支持PagedAttention和連續(xù)批處理API格式兼容OpenAI方便和各類Agent框架對(duì)接。如果你要部署在線服務(wù)面對(duì)幾十甚至上百路并發(fā)優(yōu)先上vLLM。Ollama是本地部署體驗(yàn)做得很友好的工具一條命令就能把模型拉下來(lái)跑對(duì)普通用戶特別友好。它的底層引擎依賴llama.cpp系列支持GGUF量化模型非常適合在個(gè)人電腦或者內(nèi)網(wǎng)機(jī)器上快速搭建一個(gè)本地模型服務(wù)。但Ollama高并發(fā)場(chǎng)景下的性能優(yōu)化相對(duì)沒(méi)有vLLM激進(jìn)更偏向把“跑起來(lái)”的門檻降到最低。llama.cpp則是底層運(yùn)行時(shí)級(jí)別的選擇適合需要精細(xì)控制、要跨平臺(tái)編譯或者在CPU上做推理的場(chǎng)景。它有豐富的量化方案資源受限的環(huán)境下表現(xiàn)非常好。還有一類選擇是Hugging Face transformers自帶的Text Generation Inference和vLLM定位接近生態(tài)兼容好部署也方便。我這里給一個(gè)選型表框架核心優(yōu)勢(shì)最佳使用場(chǎng)景上手難度vLLM高吞吐、高并發(fā)生產(chǎn)環(huán)境在線服務(wù)中Ollama簡(jiǎn)單、跨平臺(tái)本地快速體驗(yàn)、輕量服務(wù)低llama.cpp底層可控、效率高CPU/邊緣設(shè)備部署中高TGI生態(tài)無(wú)縫銜接HF已有HF生態(tài)團(tuán)隊(duì)中順便回答一個(gè)經(jīng)常被問(wèn)到的點(diǎn)AnythingLLM可以訓(xùn)練模型嗎答案是不行。AnythingLLM本質(zhì)是一個(gè)知識(shí)庫(kù)問(wèn)答和RAG可視化管理工具它負(fù)責(zé)把文檔切塊、向量化、檢索然后把找到的內(nèi)容拼進(jìn)Prompt送給大模型。它不會(huì)去更新模型權(quán)重也不提供訓(xùn)練能力。想在AnythingLLM里用上微調(diào)后的效果正確姿勢(shì)是先把模型用LoRA之類的方案微調(diào)好然后通過(guò)API接入AnythingLLM。3.3 顯存估算把這筆賬算清楚顯存永遠(yuǎn)是稀缺資源能自己預(yù)估需求比到處問(wèn)人更靠譜。推理階段顯存主要由兩部分組成模型權(quán)重和KV Cache。權(quán)重顯存可以直接用參數(shù)量乘精度字節(jié)數(shù)。比如7B模型用FP16推理權(quán)重大約占7×214GINT4量化后7×0.53.5G左右。KV Cache則取決于層數(shù)、注意力頭數(shù)、序列長(zhǎng)度和并發(fā)數(shù)8B模型跑4096長(zhǎng)度上下文KV Cache大概也要占1到2G。把兩者加起來(lái)再留20%余量基本就是單卡需要的最小顯存。訓(xùn)練階段就完全不同了。全量微調(diào)時(shí)顯存要同時(shí)裝下權(quán)重、梯度、優(yōu)化器狀態(tài)和激活值以7B模型為例如果用AdamW優(yōu)化器加混合精度總顯存需求很容易超過(guò)60G。所以個(gè)人用戶的常見(jiàn)做法是LoRA微調(diào)因?yàn)橹挥?xùn)練低秩矩陣梯度只針對(duì)這部分參數(shù)顯存壓力一下降到十幾G消費(fèi)級(jí)顯卡也能接受。對(duì)“GPU顯存容量是測(cè)算推理還是訓(xùn)練用的”這個(gè)問(wèn)題我的回答是分開(kāi)算哪邊都不能含糊。如果任務(wù)既做微調(diào)又做推理顯存按訓(xùn)練需求來(lái)配如果只是部署上線按推理需求來(lái)配。最簡(jiǎn)單的辦法是啟動(dòng)前用nvidia-smi盯著看峰值顯存留出10%到20%的富余不要卡在臨界值上。4. 從數(shù)據(jù)集到上線的完整落地路徑4.1 環(huán)境準(zhǔn)備與硬件選型先聊環(huán)境。做LLM微調(diào)現(xiàn)在的標(biāo)準(zhǔn)組合是Python 3.10以上、PyTorch 2.x、CUDA 11.8或12.1。常用到的Python庫(kù)無(wú)非就是transformers、datasets、accelerate、peft、trl再加上一個(gè)用來(lái)查看日志的wandb或者tensorboard。安裝這些東西沒(méi)什么難度真正容易踩坑的是版本不匹配。PyTorch版本和CUDA版本不匹配會(huì)導(dǎo)致CUDA不可用transformers版本太老又不支持新模型結(jié)構(gòu)建議直接參考各庫(kù)官方給的兼容表一次性把版本固定好。硬件選型方面7B模型的LoRA微調(diào)一張24G顯存的卡就可以跑數(shù)據(jù)量不大的情況下甚至16G也能湊合。13B到14B模型建議32G以上顯存。70B級(jí)別模型LoRA微調(diào)建議至少一張80G的卡推理則可以把模型量化后塞進(jìn)一張48G或80G的卡。如果手頭沒(méi)有硬件現(xiàn)在云GPU按小時(shí)租用的模式很成熟A100或H100都能臨時(shí)租到個(gè)人做實(shí)驗(yàn)的成本比買卡低很多。有一個(gè)經(jīng)驗(yàn)我每次都想強(qiáng)調(diào)先跑通小模型再上大模型。同樣的代碼和數(shù)據(jù)集先用1B或3B級(jí)別的模型驗(yàn)證整個(gè)訓(xùn)練流程、檢查數(shù)據(jù)格式、確認(rèn)Loss能正常下降然后再切到7B甚至更大。直接在7B模型上調(diào)試一次完整的訓(xùn)練就要好幾個(gè)小時(shí)排錯(cuò)成本太高效率極其低下。4.2 指令微調(diào)數(shù)據(jù)集與偏好數(shù)據(jù)集的構(gòu)建微調(diào)的數(shù)據(jù)質(zhì)量直接決定效果上限這點(diǎn)怎么強(qiáng)調(diào)都不為過(guò)。當(dāng)前主流的微調(diào)數(shù)據(jù)有兩種類型它們的用途完全不同別搞混。指令微調(diào)數(shù)據(jù)集格式通常是“指令-輸入-輸出”訓(xùn)練目標(biāo)是把模型的回答行為對(duì)齊到用戶期望的風(fēng)格和內(nèi)容。比如一個(gè)客服場(chǎng)景指令是“用戶說(shuō)商品缺貨現(xiàn)在幫你查詢補(bǔ)貨時(shí)間”輸出是“您好商品正在補(bǔ)貨中預(yù)計(jì)X月X日恢復(fù)請(qǐng)問(wèn)需要我為您設(shè)置到貨提醒嗎”。構(gòu)建這類數(shù)據(jù)集時(shí)要特別注意多樣性覆蓋指令的各種表達(dá)方式避免模型見(jiàn)過(guò)太多次同一種句式后產(chǎn)生過(guò)擬合。強(qiáng)化學(xué)習(xí)偏好數(shù)據(jù)集則不同它不直接給正確答案而是給兩個(gè)或多個(gè)候選回答并標(biāo)注哪個(gè)更好或者給一個(gè)完整排序。這套數(shù)據(jù)用來(lái)做RLHF或DPO這類偏好對(duì)齊訓(xùn)練讓模型學(xué)會(huì)區(qū)分回答質(zhì)量的優(yōu)劣。實(shí)際構(gòu)建偏好數(shù)據(jù)時(shí)常見(jiàn)做法是先讓模型生成多個(gè)候選再由人工或規(guī)則排序數(shù)據(jù)量不需要很大幾千到兩三萬(wàn)條高質(zhì)量偏好對(duì)就能明顯提升對(duì)話體驗(yàn)。我最想提醒的一點(diǎn)是無(wú)論哪類數(shù)據(jù)都要做清洗、去重、脫敏。一個(gè)常見(jiàn)翻車現(xiàn)場(chǎng)是數(shù)據(jù)里有大量重復(fù)樣本模型沒(méi)學(xué)會(huì)新能力反而把重復(fù)片段背了下來(lái)。另一個(gè)是正負(fù)樣本不均衡指令數(shù)據(jù)集里某個(gè)業(yè)務(wù)類型占了80%模型對(duì)這個(gè)類型過(guò)擬合其他類型一塌糊涂。構(gòu)造完數(shù)據(jù)后一定要看長(zhǎng)度分布和標(biāo)簽分布這是我在每次訓(xùn)練前必做的檢查。4.3 實(shí)操流程用LoRA微調(diào)一個(gè)Qwen對(duì)話模型這里給出一個(gè)可以直接跑通的最小示例模型用Qwen2.5-7B-Instruct訓(xùn)練框架用transformers加peft。示例代碼重點(diǎn)是讓讀者看到整個(gè)鏈路實(shí)際訓(xùn)練時(shí)數(shù)據(jù)要換成自己的。import torch from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments, Trainer from peft import LoraConfig, get_peft_model model AutoModelForCausalLM.from_pretrained( Qwen/Qwen2.5-7B-Instruct, torch_dtypetorch.bfloat16, device_mapauto ) tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2.5-7B-Instruct) lora_config LoraConfig( r8, 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() training_args TrainingArguments( output_dir./qwen-lora, per_device_train_batch_size1, gradient_accumulation_steps8, learning_rate2e-4, num_train_epochs3, logging_steps50, save_steps500, fp16False, bf16True, ) trainer Trainer( modelmodel, argstraining_args, train_datasettrain_dataset, tokenizertokenizer, ) trainer.train()注意三個(gè)細(xì)節(jié)。第一target_modules要覆蓋到模型實(shí)際使用的注意力層和MLP層不同架構(gòu)模型的模塊命名不一樣建議先把model打印出來(lái)確認(rèn)而不是照抄別人的列表。第二7B模型訓(xùn)練時(shí)16位浮點(diǎn)容易溢出導(dǎo)致Loss變成NaN如果卡支持就用bf16這是訓(xùn)練穩(wěn)定性很關(guān)鍵的一步。第三batch_size設(shè)1然后靠gradient_accumulation_steps累加梯度是顯存不夠時(shí)最常見(jiàn)也最有效的補(bǔ)救手段效果上等價(jià)于大batch訓(xùn)練。訓(xùn)練結(jié)束后模型權(quán)重被保存成LoRA adapter文件。上線前要把a(bǔ)dapter合并回原始權(quán)重這樣部署時(shí)就不依賴peft庫(kù)模型結(jié)構(gòu)也完全等價(jià)于普通模型。合并后通常還要轉(zhuǎn)成GGUF格式做量化才能在Ollama這類工具里高效地跑。4.4 用Ollama做本地化部署Ollama是我目前用過(guò)最省心的本地部署工具。微調(diào)完的模型如果要本地部署先把LoRA adapter合并回原始權(quán)重再用llama.cpp系列工具轉(zhuǎn)成GGUF格式然后寫一個(gè)Modelfile指向這個(gè)GGUF文件最后運(yùn)行ollama create和ollama run就能加載起來(lái)。這里有個(gè)小技巧如果只想本地快速體驗(yàn)甚至不用自己轉(zhuǎn)格式Ollama官方庫(kù)就能直接拉很多現(xiàn)成模型的GGUF版本。如果是公司內(nèi)部需要私有化部署把微調(diào)后的GGUF文件放到內(nèi)網(wǎng)服務(wù)器上再創(chuàng)建模型整個(gè)過(guò)程不需要聯(lián)網(wǎng)數(shù)據(jù)都在本地流動(dòng)這對(duì)很多對(duì)數(shù)據(jù)邊界敏感的團(tuán)隊(duì)來(lái)說(shuō)非常重要。部署完成后Ollama會(huì)默認(rèn)暴露一個(gè)API端口你可以用curl或者python requests來(lái)調(diào)用。這個(gè)API兼容OpenAI格式所以各種Agent框架也能直接接入把本地模型當(dāng)成推理后端用。實(shí)際測(cè)試下來(lái)Ollama在單機(jī)小并發(fā)場(chǎng)景下完全夠用幾十路以內(nèi)的請(qǐng)求都能應(yīng)付沒(méi)必要為了這個(gè)場(chǎng)景直接上vLLM。5. 常見(jiàn)問(wèn)題速查與避坑手冊(cè)5.1 高頻問(wèn)題一張表解決我在實(shí)際操作中積累了不少問(wèn)題排查經(jīng)驗(yàn)整理成一張速查表覆蓋訓(xùn)練和推理兩個(gè)環(huán)節(jié)最常見(jiàn)的問(wèn)題。問(wèn)題現(xiàn)象可能原因解決方案訓(xùn)練Loss直接變NaN學(xué)習(xí)率太高或用FP16訓(xùn)練大模型降低學(xué)習(xí)率改用BF16顯存不足OOM權(quán)重、優(yōu)化器、激活值同時(shí)占顯存換LoRA、減小batch、開(kāi)梯度累積訓(xùn)練Loss下降但驗(yàn)證集效果差過(guò)擬合或數(shù)據(jù)分布有問(wèn)題增加數(shù)據(jù)多樣性、加正則、早停推理首token特別慢沒(méi)有用KV Cache或并發(fā)批處理?yè)Q成vLLM等推理框架推理時(shí)輸出亂碼模型和tokenizer不匹配確認(rèn)tokenizer加載的模型名一致API調(diào)用一直超時(shí)并發(fā)太高或上下文太長(zhǎng)限制最大生成長(zhǎng)度、增加卡、砍并發(fā)本地Ollama加載速度慢GGUF量化精度高或磁盤讀速慢用更高壓縮量化、把模型放到SSD這個(gè)表解決的是定位思路具體到每個(gè)問(wèn)題還要結(jié)合實(shí)際日志去看。我給一個(gè)排查習(xí)慣先看顯存利用率再看GPU算力利用率然后看日志里的報(bào)錯(cuò)堆棧。這三步走完八成的訓(xùn)練和推理故障都能定位到原因。5.2 我踩過(guò)的坑和獨(dú)家建議第一個(gè)坑是盲目追求大模型。很多時(shí)候業(yè)務(wù)場(chǎng)景根本不需要7B以上的模型1B到3B級(jí)別的小模型在特定任務(wù)上微調(diào)后效果已經(jīng)足夠推理成本卻低一個(gè)量級(jí)。我在實(shí)際項(xiàng)目里先用小模型做可行性驗(yàn)證確認(rèn)效果達(dá)標(biāo)后再考慮要不要升級(jí)模型體量這個(gè)順序幫我省掉了大量無(wú)謂的算力開(kāi)銷。第二個(gè)坑是忽略數(shù)據(jù)質(zhì)量。早期我做過(guò)一次微調(diào)訓(xùn)練數(shù)據(jù)是從業(yè)務(wù)日志里直接抽的數(shù)量看著很多但臟數(shù)據(jù)、重復(fù)樣本、格式不一致的問(wèn)題非常嚴(yán)重。訓(xùn)練出來(lái)的模型看似Loss挺低實(shí)際跑起來(lái)老說(shuō)車轱轆話。后來(lái)我花了大量時(shí)間做數(shù)據(jù)清洗和格式規(guī)范同樣的模型架構(gòu)和參數(shù)量上線效果天差地別。數(shù)據(jù)這塊偷的懶最后都會(huì)在效果上還回來(lái)。第三個(gè)坑是部署和訓(xùn)練割裂。有些人訓(xùn)練時(shí)不管推理優(yōu)化上線后才發(fā)現(xiàn)模型結(jié)構(gòu)復(fù)雜、速度慢?，F(xiàn)在我習(xí)慣在選型階段就確定部署框架如果打算用Ollama部署訓(xùn)練時(shí)就優(yōu)先考慮能否做INT4量化如果打算用vLLM就提前確認(rèn)模型格式是否兼容。前后端技術(shù)棧一起規(guī)劃上線才會(huì)順這是我項(xiàng)目里最重要的一條經(jīng)驗(yàn)。第四個(gè)建議是針對(duì)新手的學(xué)習(xí)路線。別一上來(lái)就啃訓(xùn)練大模型先把小模型跑通理解數(shù)據(jù)怎么構(gòu)造、Loss怎么下降、推理怎么部署然后再去看分布式訓(xùn)練、DeepSpeed、張量并行這些進(jìn)階內(nèi)容。我見(jiàn)過(guò)很多新手卡在環(huán)境配置上三天沒(méi)進(jìn)展其實(shí)先跑一個(gè)官方示例把流程走通再回到細(xì)節(jié)進(jìn)步會(huì)快得多。學(xué)習(xí)路線不是知識(shí)點(diǎn)越多越好而是每個(gè)階段解決那一個(gè)階段最核心的問(wèn)題。