簡介面向希望在個人電腦上運行專屬領(lǐng)域ChatGPT模型的開發(fā)者這里提供一套基于ChatGLM的繼續(xù)訓(xùn)練與精調(diào)實現(xiàn)資源完整覆蓋了從數(shù)據(jù)準(zhǔn)備、模型訓(xùn)練到推理部署的代碼流程。壓縮包共28個文件大小僅124KB以Python腳本為主12個py文件配合json數(shù)據(jù)與配置、xml工程結(jié)構(gòu)、requirements依賴及README說明便于快速搭建本地微調(diào)項目。核心提供訓(xùn)練、評估、推理等環(huán)節(jié)的腳本以及示例數(shù)據(jù)集與數(shù)據(jù)自制工具同時包含分詞處理、數(shù)據(jù)轉(zhuǎn)換等模塊配合模型參數(shù)配置、DeepSpeed訓(xùn)練配置和API演示樣例可讓使用者在PC上嘗試輕量LoRA微調(diào)并快速搭建Web演示接口。項目結(jié)構(gòu)清晰數(shù)據(jù)生成、處理、訓(xùn)練、評估到推理部署均有對應(yīng)模塊便于二次開發(fā)與參數(shù)調(diào)試。目前已有1581人學(xué)習(xí)適合具備一定Python基礎(chǔ)、希望將通用大模型定制到垂直領(lǐng)域的機(jī)器學(xué)習(xí)開發(fā)者和研究者參考。 這個標(biāo)題一眼看過去就很有畫面感。chagpt這個拼寫懂的都懂大概率是ChatGPT的筆誤但項目本身一點不馬虎用開源的ChatGLM做繼續(xù)訓(xùn)練和精調(diào)最終產(chǎn)出一個能裝進(jìn)zip、在普通PC上跑起來的領(lǐng)域?qū)υ捘Ｐ汀＿@類“私有化小模型”的需求最近特別多不管你是想給公司做個內(nèi)部知識庫問答機(jī)器人還是想把手頭積累的行業(yè)語料變成對話模型這套流程都值得認(rèn)真走一遍。這篇就按我從頭到尾實操下來的經(jīng)驗把繼續(xù)訓(xùn)練、指令精調(diào)、PC端推理部署這幾大步拆開講透包括那些文檔里不會寫、只有踩過坑才知道的細(xì)節(jié)。1. 項目整體設(shè)計與思路拆解1.1 為什么選ChatGLM而不是其他開源模型ChatGLM系列在中文場景下的性價比確實高。相比同等參數(shù)規(guī)模的Llama系模型ChatGLM的中文詞表更大分詞器對中文的切分更友好訓(xùn)練和推理時的token消耗也更少。做領(lǐng)域微調(diào)時這個優(yōu)勢會被放大同樣的文本量ChatGLM需要計算的token數(shù)更少訓(xùn)練速度和顯存占用都更可觀。另一個原因是ChatGLM的基座版本選擇靈活。從6B到更小的1.5B、3B版本都有不同顯存條件下的PC都能找到合適切入點。實測下來6B模型跑SFT微調(diào)消費級顯卡16GB顯存勉強(qiáng)能玩但如果只想做推理部署量化后8GB顯存的卡也能流暢跑。這種“寬進(jìn)嚴(yán)出”的特性讓它特別適合PC端玩私有化模型。1.2 “繼續(xù)訓(xùn)練”和“精調(diào)”分別解決什么問題很多初學(xué)者容易把這兩個概念混成一鍋粥。簡單說繼續(xù)訓(xùn)練也叫增量預(yù)訓(xùn)練是讓模型“漲知識”精調(diào)SFT指令微調(diào)是讓模型“懂規(guī)矩”。繼續(xù)訓(xùn)練用的是純文本語料格式就是大段大段的領(lǐng)域文章、對話記錄、技術(shù)文檔目標(biāo)是讓模型把領(lǐng)域內(nèi)的術(shù)語、事實、表述習(xí)慣學(xué)進(jìn)去。但只做這步模型并不會變成好用的對話助手——它只是“肚子里有貨”輸出仍然可能是發(fā)散式的不知道怎么按指令回答。精調(diào)用的是“指令-回答”配對數(shù)據(jù)顯式教會模型“用戶問什么你就怎么答”。做完精調(diào)模型才真正從一個文本續(xù)寫器變成對話助手。項目標(biāo)題里“繼續(xù)訓(xùn)練和精調(diào)”兩個都寫了說明作者很清楚完整的流程必須兩步都走缺一個效果都會打折扣。我個人建議的順序也是先增量預(yù)訓(xùn)練再指令微調(diào)。反過來做的話模型容易在后續(xù)繼續(xù)訓(xùn)練中把學(xué)過的指令格式?jīng)_淡。1.3 為什么強(qiáng)調(diào)“可以在PC上運行”“PC上運行”這四個字是整條技術(shù)路線的核心約束。這意味著你不能默認(rèn)有A100或者多卡集群必須把顯存占用、內(nèi)存占用、推理速度全部納入設(shè)計考量。實際操作中我會圍繞三個指標(biāo)做取舍模型參數(shù)量、量化精度、上下文長度。參數(shù)量決定底座選6B還是3B量化精度決定推理時用FP16還是INT8/INT4上下文長度決定最多能吃進(jìn)多少字的輸入。這三者此消彼長比如選了6BFP16可用上下文就短選了3BINT4能留出更多顯存給長文本。項目既然要求PC可跑通常我會推薦ChatGLM3-6B做Q4量化部署或者直接用ChatGLM3-1.5B這種小模型做輕量級方案。2. 環(huán)境準(zhǔn)備與數(shù)據(jù)工程2.1 硬件與訓(xùn)練環(huán)境搭建思路先摸清自己的硬件底子。訓(xùn)練階段和推理階段的顯存需求差別非常大推理只要裝下模型權(quán)重加一小塊KV Cache訓(xùn)練則要額外裝下優(yōu)化器狀態(tài)、梯度、激活值。以6B模型為例FP16推理大概需要12GB顯存但同樣的模型做LoRA微調(diào)16GB顯存能勉強(qiáng)跑全量微調(diào)基本得24GB起步。這塊有一個很實用的估算方法全量訓(xùn)練顯存約等于模型參數(shù)量乘以20單位為字節(jié)LoRA微調(diào)可以壓到參數(shù)量乘以6到8。也就是說6B模型全量訓(xùn)練大概要120GB顯存LoRA只需要40GB左右實際加上激活值后16GB顯存也能跑小batch。軟件環(huán)境方面首選Linux或WSL2。Windows裸跑PyTorch不是不行但很多底層庫的兼容性問題會消耗大量精力。訓(xùn)練框架我用的是transformers peft datasets 這套組合這幾樣都是Hugging Face生態(tài)的標(biāo)準(zhǔn)件配合度很高。CUDA版本建議直接上11.8或12.xPyTorch選對應(yīng)預(yù)編譯版本省去自行編譯的痛苦。注意顯存不夠時優(yōu)先降低batch size而不是調(diào)小模型。梯度累積gradient accumulation可以在不減少有效batch的前提下把單次顯存峰值壓下來這是我最常用來“擠”顯存的手段。2.2 領(lǐng)域語料怎么收集和清洗繼續(xù)訓(xùn)練的數(shù)據(jù)質(zhì)量直接決定模型“懂不懂行”。收集語料時建議優(yōu)先找這三類來源一是行業(yè)文檔與操作手冊二是客服對話記錄/工單數(shù)據(jù)三是專業(yè)社區(qū)的問答帖。數(shù)量上個人項目10萬到50萬條文本就夠了不必追求百萬級——PC端訓(xùn)練的吞吐量有限數(shù)據(jù)太多反而跑不動。清洗是比收集更關(guān)鍵的一環(huán)。我踩過最典型的坑是語料里殘留大量HTML標(biāo)簽和Markdown語法符號模型確實能學(xué)會輸出這些亂碼。清洗流程我一般做四步去重用MinHash或簡單的MD5加上文本相似度判斷、去噪刪掉導(dǎo)航欄、版權(quán)聲明、超鏈接等非正文內(nèi)容、統(tǒng)一編碼全部轉(zhuǎn)成UTF-8、格式規(guī)范化把多個換行壓成兩個去掉零寬字符。清洗完還要做一次抽樣檢查肉眼掃一批數(shù)據(jù)確認(rèn)清洗效果臟數(shù)據(jù)混進(jìn)去一萬條后面就得花十倍的時間去調(diào)模型。2.3 指令數(shù)據(jù)的構(gòu)建與格式設(shè)計精調(diào)的效果好壞指令數(shù)據(jù)的質(zhì)量權(quán)重超過一半。常見做法是做成JSON數(shù)組每項包含instruction指令、input可選輸入、output期望輸出。這個格式對應(yīng)的是ChatGLM的官方微調(diào)格式用transformers的DataCollator處理起來很方便。數(shù)據(jù)規(guī)模上指令微調(diào)和繼續(xù)訓(xùn)練不一樣通常幾千到幾萬條高質(zhì)量數(shù)據(jù)就能見效。數(shù)量不足時寧可用規(guī)則模板批量生成也別隨便從網(wǎng)上抓亂七八糟的數(shù)據(jù)湊數(shù)。我自己常用的一個技巧是先寫20條種子樣本涵蓋最常見的提問類型然后設(shè)計一個模板把行業(yè)語料里的知識點填充進(jìn)去自動擴(kuò)展成幾百條“背景信息指令回答”的樣本。這樣既能保證規(guī)模又能控制質(zhì)量。3. 核心實操繼續(xù)訓(xùn)練與精調(diào)的完整流程3.1 繼續(xù)訓(xùn)練階段的關(guān)鍵參數(shù)與實現(xiàn)增量預(yù)訓(xùn)練我用的是transformers的Trainer模型加載后把prepare_model_for_kbit_training打開配合peft的LoRA配置。LoRA的秩r我習(xí)慣設(shè)在8到16之間alpha通常設(shè)成r的兩倍。這個配置在大多數(shù)場景下都能平衡“學(xué)得進(jìn)”和“不忘本”。先看數(shù)據(jù)集處理的核心代碼from transformers import AutoTokenizer, AutoModelForCausalLM from datasets import load_dataset tokenizer AutoTokenizer.from_pretrained(chatglm3-6b, trust_remote_codeTrue) dataset load_dataset(json, data_filesdomain_corpus.jsonl) def tokenize_function(examples): # 統(tǒng)一在文本末尾加EOS保證序列邊界清晰 texts [t tokenizer.eos_token for t in examples[text]] return tokenizer(texts, max_length2048, truncationTrue, paddingFalse) tokenized_dataset dataset.map(tokenize_function, batchedTrue)這塊有個容易忽略的點ChatGLM類的模型加載時通常需要trust_remote_codeTrue因為它的模型結(jié)構(gòu)用了自定義代碼不信任遠(yuǎn)程代碼的話根本加載不了。我第一次跑的時候漏了這個參數(shù)報錯報得莫名其妙。訓(xùn)練參數(shù)里學(xué)習(xí)率我常用5e-5warmup_ratio設(shè)0.1訓(xùn)練輪數(shù)視語料量而定一般2到3輪即可。輪數(shù)并不是越多越好增量訓(xùn)練做太狠會破壞原有通用能力這在領(lǐng)域模型里叫“災(zāi)難性遺忘”。判斷標(biāo)準(zhǔn)很簡單訓(xùn)練后用通用問題測一測如果連“編一個冷笑話”都答不上來說明訓(xùn)過頭了。3.2 指令精調(diào)階段的訓(xùn)練流程精調(diào)的代碼骨架和繼續(xù)訓(xùn)練類似區(qū)別在數(shù)據(jù)和模型加載方式。數(shù)據(jù)端是instruction、input、output三字段結(jié)構(gòu)模型端需要用peft的LoraConfig配置target_modules。ChatGLM-6B的target_modules通常設(shè)置為query_key_value這一個模塊這是它和LlaMA系一般用q_proj、v_proj最大的不同點。這個參數(shù)配錯的話LoRA等于沒生效訓(xùn)練完模型權(quán)重紋絲不動推理結(jié)果和底座模型一模一樣。我當(dāng)時排查了半天最后打印模型結(jié)構(gòu)才發(fā)現(xiàn)的。一個規(guī)范的精調(diào)訓(xùn)練腳本核心片段如下from peft import LoraConfig, get_peft_model, TaskType lora_config LoraConfig( r8, lora_alpha16, lora_dropout0.05, target_modules[query_key_value], biasnone, task_typeTaskType.CAUSAL_LM, ) model AutoModelForCausalLM.from_pretrained( chatglm3-6b, load_in_4bitTrue, # 4bit量化加載大幅降低顯存占用 trust_remote_codeTrue ) model prepare_model_for_kbit_training(model) model get_peft_model(model, lora_config)訓(xùn)練參數(shù)上精調(diào)的學(xué)習(xí)率可以比繼續(xù)訓(xùn)練稍微大一點1e-4到2e-4都是合理區(qū)間。epoch我一般控制在2到3輪設(shè)大了模型會把指令數(shù)據(jù)的格式背得滾瓜爛熟但對沒見過的新問題反而泛化變差。還有個容易忽視的細(xì)節(jié)精調(diào)階段padding策略建議改成paddingmax_length保持batch內(nèi)每個樣本長度一致Trainer內(nèi)部的損失計算才不會出偏差。3.3 合并LoRA權(quán)重與底座模型訓(xùn)練完成后LoRA權(quán)重是獨立保存的。部署推理時有兩種選擇一是保留LoRA適配器加載底座模型后再掛載二是把LoRA權(quán)重合并回底座模型導(dǎo)出一個完整權(quán)重文件。我強(qiáng)烈建議最終部署時選擇合并導(dǎo)出。原因有兩個一是推理速度更快——省去每層額外計算LoRA分支的時間二是部署更省心——不需要在推理代碼里額外管理peft配置。合并代碼很簡單from peft import PeftModel base_model AutoModelForCausalLM.from_pretrained(chatglm3-6b, trust_remote_codeTrue) model PeftModel.from_pretrained(base_model, ./lora_ckpt) merged_model model.merge_and_unload() merged_model.save_pretrained(./domain_chatglm_merged) tokenizer.save_pretrained(./domain_chatglm_merged)注意merge_and_unload()之后模型結(jié)構(gòu)里不會殘留任何LoRA痕跡此時再保存的就是一個完整的、可以直接加載的ChatGLM模型。這個文件大小和底座模型相當(dāng)6B版本合并后大約是12GBFP16。如果想進(jìn)一步壓縮可以再走一步量化壓到4GB左右。4. PC端推理部署與效果優(yōu)化4.1 顯存優(yōu)化與量化方案選擇訓(xùn)練完成后的模型要落到PC上跑量化是第一優(yōu)先級。常見的量化選擇是bitsandbytes的4bit/8bit加載還有GPTQ和GGUF兩種更徹底的離線量化方案。實測下來如果要追求最好的PC兼容性和部署便利性我推薦GGUF格式配合llama.cpp或ollama這個推理運行時完全不依賴PyTorch環(huán)境純C實現(xiàn)對老顯卡和純CPU機(jī)器都友好。轉(zhuǎn)換路徑也不復(fù)雜先用transformers導(dǎo)出ONNX或直接用transformers權(quán)重的ChatGLM模型配合llama.cpp的轉(zhuǎn)換腳本生成GGUF文件然后丟給ollama一鍵跑起來。要是還想保留transformers生態(tài)做更多定制bitsandbytes的8bit加載是最省事的選擇。但要注意部分量化方案和某些顯卡的兼容性有坑實測中出現(xiàn)過4bit推理在個別顯卡上速度反而變慢的情況。我的建議是項目初期先用8bit兜底確認(rèn)效果后再考慮上GGUF追求極致性能。4.2 流式輸出與并發(fā)處理PC上跑模型用戶體驗的關(guān)鍵就在響應(yīng)速度。ChatGLM本身支持流式輸出streaming通過model.stream_chat()接口逐token返回結(jié)果。用FastAPI包裝一下前端就能做到“邊說邊顯示”的效果體感上比等完整回答再一次性吐出好太多。并發(fā)方面PC的算力有限我的經(jīng)驗是把并發(fā)數(shù)限制在1到2多余請求排隊處理。盲目調(diào)大并發(fā)只會導(dǎo)致顯存OOM或者所有請求一起龜速。實踐中我還會把輸入長度限制在1024 token以內(nèi)輸出長度控制在512 token以內(nèi)這樣單次請求的顯存峰值和響應(yīng)延遲都能保持穩(wěn)定。注意部署時一定要用torch.inference_mode()或torch.no_grad()包裹推理過程關(guān)閉梯度計算。這不僅省顯存還能明顯提升推理速度。新手經(jīng)常忽略這行代碼直接把訓(xùn)練時的寫法套到推理上GPU跑得又慢又燙。實測可以提升1.5-2倍的速度。4.3 效果評估的“三件套”測試法模型訓(xùn)完不能只看loss降沒降必須做效果測試。我習(xí)慣從三個維度交叉驗證領(lǐng)域問題測試、通用能力測試、敏感邊界測試。領(lǐng)域問題測試用訓(xùn)練數(shù)據(jù)里沒有出現(xiàn)過的、但屬于該領(lǐng)域的問題來問檢查模型是否真的學(xué)到了知識而不是把訓(xùn)練語料背下來了。通用能力測試用“寫一首詩”“解釋一下什么是機(jī)器學(xué)習(xí)”這類問題確認(rèn)模型沒丟掉基礎(chǔ)能力。邊界測試則用一些對抗性問題確保模型在方向不偏的情況下不出現(xiàn)離譜輸出。這三個維度各有側(cè)重分別對應(yīng)“學(xué)得會”“忘不掉”“不失控”。具體實施時我通常從測試數(shù)據(jù)里手動挑15到20個問題按上面三類各分配5到7個每輪訓(xùn)練完固定跑一遍。不需要自動化評估腳本人工看結(jié)果反而更快更準(zhǔn)。這比只盯著篩選loss曲線靠譜得多。5. 常見問題與排查技巧實錄5.1 顯存不足與訓(xùn)練崩潰的排查訓(xùn)練中報“CUDA out of memory”是最常見的事故。常規(guī)手段是從這幾個方向依次調(diào)batch size減半、梯度累積補回來輸入最大長度縮短2048降到1024優(yōu)化器換成8bit AdamW開gradient_checkpointing以時間換空間。如果以上都試過還是爆顯存就要重新評估方案了換更小的底座模型6B換3B甚至1.5B或者把數(shù)據(jù)切得更碎。還有一個小眾但有效的技巧用torch.cuda.empty_cache()在每輪評估前清一次緩存碎片有時能多擠出幾百MB。雖然治標(biāo)不治本但對小顯存用戶很實用。5.2 Loss不下降或下降過慢增量預(yù)訓(xùn)練時loss不降通常是數(shù)據(jù)質(zhì)量和格式問題。先Check一下語料是不是大量重復(fù)——重復(fù)數(shù)據(jù)會讓模型快速過擬合loss假性下降后就不再動了。另一個原因是學(xué)習(xí)率太低特別是用了warmup后前幾百步幾乎看不到loss波動這時候別急著中斷多跑一段看趨勢。如果數(shù)據(jù)沒問題就要看學(xué)習(xí)率是否匹配LoRA的秩。r設(shè)大時比如16lr可以相應(yīng)調(diào)高一些r小時比如4lr要調(diào)低防止震蕩。我常用的組合是r8、lr5e-5比較穩(wěn)。5.3 精調(diào)后模型輸出空洞/答非所問這類問題的元兇多半是指令數(shù)據(jù)格式不一致。ChatGLM的精調(diào)數(shù)據(jù)里instruction和input的含義有別instruction是“做什么”input是“做這件事的素材”。很多新手把整段上下文都塞進(jìn)instruction模型學(xué)習(xí)時指令信號混亂推理時自然抓不準(zhǔn)重點。另一個常見原因是指令數(shù)據(jù)的回答描述太長指令太短。模型學(xué)到的是“不管用戶問什么我都回一大段話”而不是“根據(jù)問題精準(zhǔn)回答”。建議指令保持1到2句話輸出控制在合理長度讓模型明確學(xué)到“簡潔回答”的映射關(guān)系。精調(diào)完如果發(fā)現(xiàn)模型說話風(fēng)格變啰嗦也可以試試在推理參數(shù)里調(diào)高temperature并在system prompt里強(qiáng)調(diào)“用最簡潔的中文回答”。5.4 部署后首token等待過長PC端跑大模型首token延遲是個硬傷。原因在于用戶輸入的prompt需要完整過一遍模型才能開始生成第一個token。優(yōu)化手段有三招一是限制用戶輸入長度過長的歷史記錄做截斷二是打開KV Cache復(fù)用多輪對話時只對新增內(nèi)容計算三是換用支持前綴緩存的推理框架減少重復(fù)計算。綜合用下來多輪對話場景的響應(yīng)速度能明顯提升。提示如果你用的是llama.cpp/ollama路線的GGUF方案新版本自帶prompt caching基本上開箱即用。而如果自己用transformers寫推理服務(wù)多輪對話時需要手動維護(hù)歷史token的KV Cache處理不好會出現(xiàn)“聊得越多越慢”的尷尬情況。寫在最后的實操建議如果你正處于起步階段我個人的建議是不要一上來就追求把6B模型在PC上全量微調(diào)和部署完。先從ChatGLM3-1.5B或更小的模型開始用幾百條數(shù)據(jù)和LoRA跑通整條鏈路然后再逐步放大到6B和更復(fù)雜的場景。小模型試錯成本低一次訓(xùn)練幾分鐘就能出結(jié)果你可以快速驗證數(shù)據(jù)格式、參數(shù)設(shè)置、部署流程等全流程跑順了再上大模型效率反而更高。另外項目里那些“zip打包交付”的習(xí)慣也別丟把訓(xùn)練代碼、數(shù)據(jù)處理腳本、部署說明、量化好的模型都整理進(jìn)一個包后續(xù)不管自己在別的機(jī)器上復(fù)用還是分享給別人都能省一大堆折騰時間。祝你在自己的領(lǐng)域模型上早日跑出滿意效果。本文還有配套的精品資源點擊獲取