：從概念、微調(diào)到部署的完整指南)
簡介這是廈門大學(xué)大數(shù)據(jù)教學(xué)團隊出品的《大模型概念、技術(shù)與應(yīng)用實踐》PPT課件共140頁面向希望系統(tǒng)了解大模型技術(shù)體系與產(chǎn)業(yè)應(yīng)用的讀者尤其適合零基礎(chǔ)起步的學(xué)習(xí)者。資源為單個PDF文件容量14.41MB目前已有663人參與學(xué)習(xí)。課件先梳理人工智能發(fā)展簡史與圖靈測試概述其從誕生到未來發(fā)展的多個階段再進入大模型核心內(nèi)容涵蓋概念演變、技術(shù)原理、模型分類、典型產(chǎn)品、本地部署方式等并專門圍繞DeepSeek展開科普隨后聚焦AIGC應(yīng)用與實踐展示自然語言處理、多模態(tài)生成等場景幫助讀者理解大模型如何影響工作與生活。整套內(nèi)容圖文并茂、邏輯連貫既適合高校教學(xué)也可作為企業(yè)內(nèi)訓(xùn)與自學(xué)的入門參考。整體上這套PPT從歷史脈絡(luò)講到前沿實踐能幫助讀者建立對DeepSeek與大模型的系統(tǒng)認知。1. 大模型不是玩具讀這類課件前先想清楚的三件事一份百頁級的大模型講義標題通常會把三個詞放一起概念、技術(shù)與應(yīng)用。很多人翻完一遍記住了 Transformer 和微調(diào)回到項目里卻不知道怎么下手。原因不在講義在于順序——概念是幫你建立坐標系技術(shù)是給你工具應(yīng)用才是真正決定投入產(chǎn)出的一步。這一篇我按工程落地的路徑重新拆解這套大模型概念、技術(shù)與應(yīng)用實踐先說概念里哪些必須吃透、哪些可以直接翻再給一條從微調(diào)到部署的可抄作業(yè)鏈路最后把最容易翻車的五個坑擺出來。適合兩類人想私有化部署但被顯存和成本勸退的開發(fā)者以及正準備把大模型接進真實業(yè)務(wù)的方案負責人。讀完你至少能算出自己該選哪條路線。2. 先把概念層去魅Token、參數(shù)量與上下文窗口影響你的每個決策2.1 Token 切分不是玄學(xué)兩行代碼看懂模型眼里的文本概念部分繞不開的第一個詞是 Token。你可以把它理解成模型讀文本的最小單位一個中文字符可能對應(yīng)一個或多個 Token英文單詞經(jīng)常被切成子詞。這個切法決定了兩件事你的文本在模型看來有多長以及你的算力成本有多高。與其看十頁理論不如直接跑一次切分。from transformers import AutoTokenizer # 加載本地權(quán)重不依賴遠程倉庫 tokenizer AutoTokenizer.from_pretrained(./model-weights, trust_remote_codeTrue) text 大模型微調(diào)最核心的不是調(diào)參而是數(shù)據(jù) tokens tokenizer(text, max_length128, truncationTrue, return_tensorspt) # 看切出來的子詞序列 print(tokenizer.convert_ids_to_tokens(tokens[input_ids][0]))max_length128限制了這條樣本最多用 128 個 Token超出部分會被truncationTrue從尾部直接裁掉。這里有個很隱蔽的坑長文檔問答里如果答案恰好長在文檔后半段截斷后模型根本看不到答案。所以處理長文本時要把truncation的策略改成按段落切而不是從尾部一刀切。Token 數(shù)量還直接等于推理成本。同一段中文不同分詞器切出來的 Token 數(shù)能差出 30%。選型時別只看參數(shù)量拿你業(yè)務(wù)里的真實文本分別切一下誰省 Token 誰就更省錢。2.2 參數(shù)量、上下文窗口與能力邊界一張表繞開越大越好誤區(qū)概念層第二個容易走偏的是參數(shù)量崇拜。幾十億參數(shù)和百億千億參數(shù)之間差的不是“聰明程度”而是使用場景。整理成一張選型表比讀長章節(jié)管用模型規(guī)模典型硬件需求適合場景不適合場景十億級單卡 16G 起步垂直領(lǐng)域分類、抽取、改寫復(fù)雜推理、長文生成百億級單機多卡或大顯存通用對話、內(nèi)容生成、私有化部署高并發(fā) C 端服務(wù)千億級多機集群深度推理、復(fù)雜指令、研究實驗預(yù)算有限的內(nèi)部工具上下文窗口是另一個常被誤讀的指標。窗口大意味著“能讀進去的內(nèi)容多”不代表“記得住”。模型對窗口中間位置的內(nèi)容記憶力最差這是注意力機制的結(jié)構(gòu)性特點。所以做長文檔問答時別指望把整個文檔塞進窗口就能解決后面講 RAG 的章節(jié)會細說。2.3 這類 140 頁講義的概念章節(jié)哪些頁值得精讀哪些頁可以直接翻概念部分占了這類講義將近一半篇幅但真正和落地強相關(guān)的只有三塊神經(jīng)網(wǎng)絡(luò)怎么表示文本、Transformer 的注意力機制在做什么、訓(xùn)練分哪幾個階段。其他關(guān)于模型歷史、各家廠商的路線對比了解即可。個人建議的精讀順序是先讀 Token 與 Embedding再讀注意力機制的直覺解釋最后讀訓(xùn)練階段劃分。這三塊對應(yīng)你后面要做的三個決策數(shù)據(jù)怎么處理、顯存怎么估、微調(diào)怎么選。泛泛講“神經(jīng)網(wǎng)絡(luò)是什么”的章節(jié)可以直接跳過你已經(jīng)會用 Python 寫接口的話那部分喚醒不了任何實操記憶。我一般會建議團隊把概念部分的筆記壓縮成一頁紙一張模型能力對照表一段訓(xùn)練階段流程圖一份 Token 切分示例。剩下的內(nèi)容等真遇到問題時再回頭查比一次讀完更有效。3. 微調(diào)是最貴的改性格環(huán)節(jié)從 SFT 到 LoRA 的一條完整訓(xùn)練路徑3.1 預(yù)訓(xùn)練、SFT、RLHF三個訓(xùn)練階段各自負責什么預(yù)訓(xùn)練解決的是“語言能力”問題模型在這個階段讀海量文本學(xué)會語法、知識和推理的底層規(guī)律。這個階段成本極高普通團隊不用碰。SFT監(jiān)督微調(diào)解決的是“聽從指令”的問題用人工標注的問答對讓模型學(xué)會回答的格式和語氣。絕大多數(shù)業(yè)務(wù)定制落在這一層。RLHF基于人類反饋的強化學(xué)習(xí)解決的是“價值觀對齊”的問題讓模型學(xué)會拒絕敏感請求、輸出更安全的內(nèi)容這個階段同樣重資源。對做應(yīng)用的人來說只需要把 SFT 吃透。RLHF 通常由模型提供方完成你拿到的開源模型已經(jīng)帶了一定程度的對齊。如果業(yè)務(wù)有特殊的安全要求比如醫(yī)療建議或法律意見需要再加一層偏好微調(diào)但那是少數(shù)場景。三者的關(guān)系可以概括成一句話預(yù)訓(xùn)練決定上限SFT 決定下限RLHF 決定安全性。你的業(yè)務(wù)提升空間全在 SFT 里。3.2 全參微調(diào)與 LoRA 的選型模板按顯存預(yù)算倒推方案全參微調(diào)會把模型全部權(quán)重都更新一遍效果最好但也最貴LoRA 只訓(xùn)練一小部分新增參數(shù)用很低的成本逼近全參效果。這是一個決策模板預(yù)算內(nèi)有 4 張以上高端顯卡且需要極致效果全參微調(diào)單卡或雙卡、數(shù)據(jù)量 10 萬條以內(nèi)LoRA數(shù)據(jù)量巨大且任務(wù)單一先 LoRA 跑基線再決定要不要升級LoRA 不是玄學(xué)它的核心是凍結(jié)原模型權(quán)重額外插入低秩矩陣去學(xué)任務(wù)差異。訓(xùn)練時只更新這個增量部分推理時把增量合并回原權(quán)重推理速度不受影響。一個可抄作業(yè)的配置from transformers import AutoModelForCausalLM from peft import LoraConfig, get_peft_model, TaskType # 加載基礎(chǔ)模型 model AutoModelForCausalLM.from_pretrained( ./base-model-weights, torch_dtypeauto, device_mapauto ) lora_config LoraConfig( r16, # 秩決定新增參數(shù)量常用 8 / 16 / 32 lora_alpha32, # 縮放系數(shù)經(jīng)驗值取 r 的 2 倍 lora_dropout0.05, # 防止過擬合 target_modules[q_proj, k_proj, v_proj, o_proj], biasnone, task_typeTaskType.CAUSAL_LM ) model get_peft_model(model, lora_config) model.print_trainable_parameters() # 看新增參數(shù)量占比r16意味著每個被改造的線性層額外學(xué)習(xí)一個 16 維的低秩空間越大表達能力越強但過大會過擬合。lora_alpha32控制最終注入的強度alpha 與 r 的比值決定微調(diào)對原模型的影響程度。一個血淚經(jīng)驗是不確定性大的時候先上小模型加 LoRA 跑通流程。別一上來就在幾百億參數(shù)上試翻車成本太高。3.3 數(shù)據(jù)配比與清洗翻不翻車七成看這里微調(diào)翻車的首要原因不是參數(shù)是數(shù)據(jù)。常見問題包括指令重復(fù)導(dǎo)致模型只會一種句式、答案包含噪聲導(dǎo)致生成質(zhì)量下降、領(lǐng)域數(shù)據(jù)與通用數(shù)據(jù)比例失衡導(dǎo)致災(zāi)難性遺忘。一個穩(wěn)妥的配比基準數(shù)據(jù)類別占比單條長度建議領(lǐng)域指令數(shù)據(jù)30%100-500 Token通用指令數(shù)據(jù)30%50-300 Token通用對話數(shù)據(jù)20%50-200 Token長文/格式化輸出樣本20%500-2000 Token領(lǐng)域數(shù)據(jù)占比通常不要超過 40%否則模型容易丟掉通用能力。清洗這一步直接決定數(shù)據(jù)質(zhì)量我常用一個最小腳本過濾明顯噪聲import re import json def clean_text(raw: str) - str: # 去掉超鏈接和多余空白 raw re.sub(rhttp\S, , raw) raw re.sub(r\s, , raw).strip() # 過濾過短文本 if len(raw) 20: return None # 過濾重復(fù)率過高的噪聲文本 char_set set(raw) if len(char_set) / max(len(raw), 1) 0.1: return None return raw records [] with open(raw_qa.jsonl, r) as f: for line in f: item json.loads(line) text clean_text(item.get(question, ) \n item.get(answer, )) if text and text not in records: records.append(text) with open(cleaned_qa.jsonl, w) as f: for t in records: f.write(json.dumps({text: t}) \n)這個腳本處理了三類噪聲超鏈接、短文本、重復(fù)率異常高的文本。實際項目里還得加一層敏感詞過濾和格式校驗。清洗完的數(shù)據(jù)要抽看 20 條確認格式統(tǒng)一。格式不一致是微調(diào)后輸出亂套的頭號原因。4. 部署與推理顯存、量化、并發(fā)的三筆賬算清再動手4.1 先算顯存再下單一套能估到夠不夠用的公式部署環(huán)節(jié)第一大坑是顯存估算錯誤。很多人只算了模型權(quán)重的大小忘了 KV Cache 和激活值。推理時顯存占用大致是權(quán)重顯存加 KV Cache再加激活值與臨時緩沖。權(quán)重顯存等于參數(shù)量乘字節(jié)數(shù)FP16 下每 10 億參數(shù)約 2GBKV Cache 則與層數(shù)、注意力頭數(shù)、序列長度和并發(fā)數(shù)直接相關(guān)并發(fā)越高占得越猛。給出一個濃縮的估算方式按模型規(guī)模粗算模型規(guī)模FP16 推理最低顯存參考INT8 量化參考INT4 量化參考十億級約 16GB約 8GB約 5GB百億級約 200GB約 100GB約 60GB千億級約 1600GB約 800GB約 500GB這里還沒算 KV Cache。長對話場景會把 KV Cache 放大好幾倍最終顯存需求經(jīng)常比權(quán)重顯存高一倍以上。我的習(xí)慣是先按“權(quán)重顯存乘 2”打底再根據(jù)并發(fā)和序列長度往上加。峰值顯存和你“感覺夠用”的顯存之間差距最大的就是 KV Cache。理解這一點后面并發(fā)調(diào)優(yōu)就順了。4.2 量化不是免費的午餐精度損失的邊界在哪量化是壓縮顯存的直接手段。INT8 在實際業(yè)務(wù)里精度損失通常很小大多數(shù)任務(wù)可以接受INT4 就要小心了復(fù)雜推理、數(shù)學(xué)題、長文本生成這類任務(wù)容易出現(xiàn)質(zhì)量下降。量化的本質(zhì)是犧牲精度換顯存換不換取決于你的任務(wù)容忍度。建議先做小規(guī)模評測再決定量化等級。拿 50 條業(yè)務(wù)真實樣本分別用 FP16、INT8、INT4 跑一遍人工對比輸出質(zhì)量。如果差別不明顯上 INT8如果任務(wù)涉及復(fù)雜推理保守留在 FP16。量化不是越狠越好翻車往往是因為上線前沒做逐條對比。4.3 推理服務(wù)的并發(fā)參數(shù)別讓默認值背鍋推理服務(wù)并發(fā)上不去很多人第一反應(yīng)是加顯卡其實先要查 KV Cache。并發(fā)每加一倍KV Cache 顯存占用跟著漲一倍?，F(xiàn)在主流的推理框架普遍帶 PagedAttention 機制能顯著降低緩存浪費這是首選方案。另一個通用做法是限制單請求最大 Token 數(shù)防止個別請求把顯存吃空。一個常見的推理啟動參數(shù)模板python -m vllm.entrypoints.openai.api_server \ --model ./model-weights \ --tensor-parallel-size 1 \ --max-model-len 4096 \ --max-num-seqs 8 \ --gpu-memory-utilization 0.9max-num-seqs 8限制同一時刻處理的請求數(shù)超出的排隊等待gpu-memory-utilization 0.9表示最多用掉 90% 顯存留 10% 給系統(tǒng)與臨時緩沖。這兩個參數(shù)直接決定服務(wù)穩(wěn)定性。如果并發(fā)一高就 502 或超時先把max-num-seqs降下來再觀察顯存曲線。部署形態(tài)上外部 API 適合快速驗證私有化部署適合數(shù)據(jù)敏感場景混合架構(gòu)適合既要靈活性又要安全性的團隊。三者不是替代關(guān)系而是不同階段的過渡路徑。5. 大模型實踐五大常見坑現(xiàn)象、原因與排查手冊5.1 模型一本正經(jīng)胡說八道現(xiàn)象對話里模型給出非常肯定但明顯錯誤的答案甚至引用不存在的文獻或數(shù)據(jù)。原因模型本身是預(yù)測下一個詞的工具它不知道什么是“事實”采樣參數(shù)設(shè)置不當會放大這種傾向。解決先把temperature降到 0.2 到 0.4 區(qū)間讓輸出更保守同時接入檢索兜底讓模型基于外部資料回答。不要指望模型自己承認不知道它只會繼續(xù)編。5.2 算好的顯存夠用上線就爆現(xiàn)象按權(quán)重顯存估算買好了卡一跑真實負載直接 OOM。原因忽略了 KV Cache 和推理框架自身占用。解決用 4.1 節(jié)的公式重算把 KV Cache 單獨列出來估上線前壓測至少 30 分鐘觀察顯存曲線而不是只跑一條測試請求。5.3 LoRA 微調(diào)后模型變笨了現(xiàn)象領(lǐng)域問題答得不錯但常識和推理能力明顯下降甚至語氣都變了。原因領(lǐng)域數(shù)據(jù)占比過高或者學(xué)習(xí)率太大模型把原來學(xué)會的通用能力覆蓋掉了。解決把領(lǐng)域數(shù)據(jù)占比降到 40% 以下加入通用對話數(shù)據(jù)混合訓(xùn)練LoRA 的學(xué)習(xí)率從 1e-4 降到 2e-5 再試。微調(diào)完做一組前后對比測試不要只看領(lǐng)域指標的漲跌。5.4 并發(fā)一高響應(yīng)就變慢甚至超時現(xiàn)象單請求測試 500ms并發(fā) 20 就變成 5 秒再調(diào)高直接超時。原因KV Cache 擠占了可用顯存模型開始換入換出參數(shù)推理變慢。解決啟用 PagedAttention 類方案限制max-num-seqs并為長響應(yīng)單獨設(shè)置超時時間。排查時先看nvidia-smi的顯存曲線如果接近打滿優(yōu)先調(diào)并發(fā)上限。5.5 評測集漲分上線效果打臉現(xiàn)象離線評測指標提升明顯真用戶反饋卻更差了。原因評測集和業(yè)務(wù)真實分布不一致或者模型把評測集樣例背下來了。解決評測集從真實業(yè)務(wù)流量里按月采樣每個月?lián)Q一部分同時建立人工抽檢機制每次上線前抽 50 條真實輸入對比新舊版本的輸出。指標只做參考用戶反饋才是最終裁判。6. 落到業(yè)務(wù)上的最后一公里RAG、Agent 與投入產(chǎn)出判斷法RAG檢索增強生成是當前性價比最高的落地方式。它不微調(diào)模型而是把知識庫切塊存進向量庫用戶提問時先檢索相關(guān)片段再交給模型基于片段生成答案。這樣做的好處是知識可以隨時更新不用重新訓(xùn)練。最小落地順序切塊、向量化、檢索、拼接、生成。切塊大小直接影響檢索效果一般按 200 到 500 Token 一塊塊之間重疊 10% 左右避免語義斷裂。Agent 類應(yīng)用則是把模型從一個答復(fù)工具變成一個執(zhí)行引擎讓它調(diào)用搜索、計算器或業(yè)務(wù) API 完成任務(wù)。這類方案效果上限高但穩(wěn)定性依賴工具調(diào)用的成功率適合內(nèi)部效率工具先行驗證。投入產(chǎn)出判斷我用一個簡單模型總成本等于訓(xùn)練或調(diào)用成本加上運維成本再加人工評測成本。如果業(yè)務(wù)對響應(yīng)速度要求極高、數(shù)據(jù)又敏感私有化部署大概率劃算如果只是內(nèi)部輔助寫作或信息整理外部 API 加 RAG 的成本優(yōu)勢明顯。我做這類方案有個習(xí)慣先把評測集建好再談算力采購。評測集來自真實業(yè)務(wù)流量每條都標了預(yù)期答案。拿到一個新模型時先跑一遍評測集超過當前方案再換不過線就繼續(xù)用舊方案。這個習(xí)慣幫我擋掉過很多次沖動換模型的翻車。先定評估標準再定技術(shù)選型順序不要反。希望幫到你。本文還有配套的精品資源點擊獲取 大模型工程落地實戰(zhàn)：從概念、微調(diào)到部署的完整指南
簡介這是廈門大學(xué)大數(shù)據(jù)教學(xué)團隊出品的《大模型概念、技術(shù)與應(yīng)用實踐》PPT課件共140頁面向希望系統(tǒng)了解大模型技術(shù)體系與產(chǎn)業(yè)應(yīng)用的讀者尤其適合零基礎(chǔ)起步的學(xué)習(xí)者。資源為單個PDF文件容量14.41MB目前已有663人參與學(xué)習(xí)。課件先梳理人工智能發(fā)展簡史與圖靈測試概述其從誕生到未來發(fā)展的多個階段再進入大模型核心內(nèi)容涵蓋概念演變、技術(shù)原理、模型分類、典型產(chǎn)品、本地部署方式等并專門圍繞DeepSeek展開科普隨后聚焦AIGC應(yīng)用與實踐展示自然語言處理、多模態(tài)生成等場景幫助讀者理解大模型如何影響工作與生活。整套內(nèi)容圖文并茂、邏輯連貫既適合高校教學(xué)也可作為企業(yè)內(nèi)訓(xùn)與自學(xué)的入門參考。整體上這套PPT從歷史脈絡(luò)講到前沿實踐能幫助讀者建立對DeepSeek與大模型的系統(tǒng)認知。1. 大模型不是玩具讀這類課件前先想清楚的三件事一份百頁級的大模型講義標題通常會把三個詞放一起概念、技術(shù)與應(yīng)用。很多人翻完一遍記住了 Transformer 和微調(diào)回到項目里卻不知道怎么下手。原因不在講義在于順序——概念是幫你建立坐標系技術(shù)是給你工具應(yīng)用才是真正決定投入產(chǎn)出的一步。這一篇我按工程落地的路徑重新拆解這套大模型概念、技術(shù)與應(yīng)用實踐先說概念里哪些必須吃透、哪些可以直接翻再給一條從微調(diào)到部署的可抄作業(yè)鏈路最后把最容易翻車的五個坑擺出來。適合兩類人想私有化部署但被顯存和成本勸退的開發(fā)者以及正準備把大模型接進真實業(yè)務(wù)的方案負責人。讀完你至少能算出自己該選哪條路線。2. 先把概念層去魅Token、參數(shù)量與上下文窗口影響你的每個決策2.1 Token 切分不是玄學(xué)兩行代碼看懂模型眼里的文本概念部分繞不開的第一個詞是 Token。你可以把它理解成模型讀文本的最小單位一個中文字符可能對應(yīng)一個或多個 Token英文單詞經(jīng)常被切成子詞。這個切法決定了兩件事你的文本在模型看來有多長以及你的算力成本有多高。與其看十頁理論不如直接跑一次切分。from transformers import AutoTokenizer # 加載本地權(quán)重不依賴遠程倉庫 tokenizer AutoTokenizer.from_pretrained(./model-weights, trust_remote_codeTrue) text 大模型微調(diào)最核心的不是調(diào)參而是數(shù)據(jù) tokens tokenizer(text, max_length128, truncationTrue, return_tensorspt) # 看切出來的子詞序列 print(tokenizer.convert_ids_to_tokens(tokens[input_ids][0]))max_length128限制了這條樣本最多用 128 個 Token超出部分會被truncationTrue從尾部直接裁掉。這里有個很隱蔽的坑長文檔問答里如果答案恰好長在文檔后半段截斷后模型根本看不到答案。所以處理長文本時要把truncation的策略改成按段落切而不是從尾部一刀切。Token 數(shù)量還直接等于推理成本。同一段中文不同分詞器切出來的 Token 數(shù)能差出 30%。選型時別只看參數(shù)量拿你業(yè)務(wù)里的真實文本分別切一下誰省 Token 誰就更省錢。2.2 參數(shù)量、上下文窗口與能力邊界一張表繞開越大越好誤區(qū)概念層第二個容易走偏的是參數(shù)量崇拜。幾十億參數(shù)和百億千億參數(shù)之間差的不是“聰明程度”而是使用場景。整理成一張選型表比讀長章節(jié)管用模型規(guī)模典型硬件需求適合場景不適合場景十億級單卡 16G 起步垂直領(lǐng)域分類、抽取、改寫復(fù)雜推理、長文生成百億級單機多卡或大顯存通用對話、內(nèi)容生成、私有化部署高并發(fā) C 端服務(wù)千億級多機集群深度推理、復(fù)雜指令、研究實驗預(yù)算有限的內(nèi)部工具上下文窗口是另一個常被誤讀的指標。窗口大意味著“能讀進去的內(nèi)容多”不代表“記得住”。模型對窗口中間位置的內(nèi)容記憶力最差這是注意力機制的結(jié)構(gòu)性特點。所以做長文檔問答時別指望把整個文檔塞進窗口就能解決后面講 RAG 的章節(jié)會細說。2.3 這類 140 頁講義的概念章節(jié)哪些頁值得精讀哪些頁可以直接翻概念部分占了這類講義將近一半篇幅但真正和落地強相關(guān)的只有三塊神經(jīng)網(wǎng)絡(luò)怎么表示文本、Transformer 的注意力機制在做什么、訓(xùn)練分哪幾個階段。其他關(guān)于模型歷史、各家廠商的路線對比了解即可。個人建議的精讀順序是先讀 Token 與 Embedding再讀注意力機制的直覺解釋最后讀訓(xùn)練階段劃分。這三塊對應(yīng)你后面要做的三個決策數(shù)據(jù)怎么處理、顯存怎么估、微調(diào)怎么選。泛泛講“神經(jīng)網(wǎng)絡(luò)是什么”的章節(jié)可以直接跳過你已經(jīng)會用 Python 寫接口的話那部分喚醒不了任何實操記憶。我一般會建議團隊把概念部分的筆記壓縮成一頁紙一張模型能力對照表一段訓(xùn)練階段流程圖一份 Token 切分示例。剩下的內(nèi)容等真遇到問題時再回頭查比一次讀完更有效。3. 微調(diào)是最貴的改性格環(huán)節(jié)從 SFT 到 LoRA 的一條完整訓(xùn)練路徑3.1 預(yù)訓(xùn)練、SFT、RLHF三個訓(xùn)練階段各自負責什么預(yù)訓(xùn)練解決的是“語言能力”問題模型在這個階段讀海量文本學(xué)會語法、知識和推理的底層規(guī)律。這個階段成本極高普通團隊不用碰。SFT監(jiān)督微調(diào)解決的是“聽從指令”的問題用人工標注的問答對讓模型學(xué)會回答的格式和語氣。絕大多數(shù)業(yè)務(wù)定制落在這一層。RLHF基于人類反饋的強化學(xué)習(xí)解決的是“價值觀對齊”的問題讓模型學(xué)會拒絕敏感請求、輸出更安全的內(nèi)容這個階段同樣重資源。對做應(yīng)用的人來說只需要把 SFT 吃透。RLHF 通常由模型提供方完成你拿到的開源模型已經(jīng)帶了一定程度的對齊。如果業(yè)務(wù)有特殊的安全要求比如醫(yī)療建議或法律意見需要再加一層偏好微調(diào)但那是少數(shù)場景。三者的關(guān)系可以概括成一句話預(yù)訓(xùn)練決定上限SFT 決定下限RLHF 決定安全性。你的業(yè)務(wù)提升空間全在 SFT 里。3.2 全參微調(diào)與 LoRA 的選型模板按顯存預(yù)算倒推方案全參微調(diào)會把模型全部權(quán)重都更新一遍效果最好但也最貴LoRA 只訓(xùn)練一小部分新增參數(shù)用很低的成本逼近全參效果。這是一個決策模板預(yù)算內(nèi)有 4 張以上高端顯卡且需要極致效果全參微調(diào)單卡或雙卡、數(shù)據(jù)量 10 萬條以內(nèi)LoRA數(shù)據(jù)量巨大且任務(wù)單一先 LoRA 跑基線再決定要不要升級LoRA 不是玄學(xué)它的核心是凍結(jié)原模型權(quán)重額外插入低秩矩陣去學(xué)任務(wù)差異。訓(xùn)練時只更新這個增量部分推理時把增量合并回原權(quán)重推理速度不受影響。一個可抄作業(yè)的配置from transformers import AutoModelForCausalLM from peft import LoraConfig, get_peft_model, TaskType # 加載基礎(chǔ)模型 model AutoModelForCausalLM.from_pretrained( ./base-model-weights, torch_dtypeauto, device_mapauto ) lora_config LoraConfig( r16, # 秩決定新增參數(shù)量常用 8 / 16 / 32 lora_alpha32, # 縮放系數(shù)經(jīng)驗值取 r 的 2 倍 lora_dropout0.05, # 防止過擬合 target_modules[q_proj, k_proj, v_proj, o_proj], biasnone, task_typeTaskType.CAUSAL_LM ) model get_peft_model(model, lora_config) model.print_trainable_parameters() # 看新增參數(shù)量占比r16意味著每個被改造的線性層額外學(xué)習(xí)一個 16 維的低秩空間越大表達能力越強但過大會過擬合。lora_alpha32控制最終注入的強度alpha 與 r 的比值決定微調(diào)對原模型的影響程度。一個血淚經(jīng)驗是不確定性大的時候先上小模型加 LoRA 跑通流程。別一上來就在幾百億參數(shù)上試翻車成本太高。3.3 數(shù)據(jù)配比與清洗翻不翻車七成看這里微調(diào)翻車的首要原因不是參數(shù)是數(shù)據(jù)。常見問題包括指令重復(fù)導(dǎo)致模型只會一種句式、答案包含噪聲導(dǎo)致生成質(zhì)量下降、領(lǐng)域數(shù)據(jù)與通用數(shù)據(jù)比例失衡導(dǎo)致災(zāi)難性遺忘。一個穩(wěn)妥的配比基準數(shù)據(jù)類別占比單條長度建議領(lǐng)域指令數(shù)據(jù)30%100-500 Token通用指令數(shù)據(jù)30%50-300 Token通用對話數(shù)據(jù)20%50-200 Token長文/格式化輸出樣本20%500-2000 Token領(lǐng)域數(shù)據(jù)占比通常不要超過 40%否則模型容易丟掉通用能力。清洗這一步直接決定數(shù)據(jù)質(zhì)量我常用一個最小腳本過濾明顯噪聲import re import json def clean_text(raw: str) - str: # 去掉超鏈接和多余空白 raw re.sub(rhttp\S, , raw) raw re.sub(r\s, , raw).strip() # 過濾過短文本 if len(raw) 20: return None # 過濾重復(fù)率過高的噪聲文本 char_set set(raw) if len(char_set) / max(len(raw), 1) 0.1: return None return raw records [] with open(raw_qa.jsonl, r) as f: for line in f: item json.loads(line) text clean_text(item.get(question, ) \n item.get(answer, )) if text and text not in records: records.append(text) with open(cleaned_qa.jsonl, w) as f: for t in records: f.write(json.dumps({text: t}) \n)這個腳本處理了三類噪聲超鏈接、短文本、重復(fù)率異常高的文本。實際項目里還得加一層敏感詞過濾和格式校驗。清洗完的數(shù)據(jù)要抽看 20 條確認格式統(tǒng)一。格式不一致是微調(diào)后輸出亂套的頭號原因。4. 部署與推理顯存、量化、并發(fā)的三筆賬算清再動手4.1 先算顯存再下單一套能估到夠不夠用的公式部署環(huán)節(jié)第一大坑是顯存估算錯誤。很多人只算了模型權(quán)重的大小忘了 KV Cache 和激活值。推理時顯存占用大致是權(quán)重顯存加 KV Cache再加激活值與臨時緩沖。權(quán)重顯存等于參數(shù)量乘字節(jié)數(shù)FP16 下每 10 億參數(shù)約 2GBKV Cache 則與層數(shù)、注意力頭數(shù)、序列長度和并發(fā)數(shù)直接相關(guān)并發(fā)越高占得越猛。給出一個濃縮的估算方式按模型規(guī)模粗算模型規(guī)模FP16 推理最低顯存參考INT8 量化參考INT4 量化參考十億級約 16GB約 8GB約 5GB百億級約 200GB約 100GB約 60GB千億級約 1600GB約 800GB約 500GB這里還沒算 KV Cache。長對話場景會把 KV Cache 放大好幾倍最終顯存需求經(jīng)常比權(quán)重顯存高一倍以上。我的習(xí)慣是先按“權(quán)重顯存乘 2”打底再根據(jù)并發(fā)和序列長度往上加。峰值顯存和你“感覺夠用”的顯存之間差距最大的就是 KV Cache。理解這一點后面并發(fā)調(diào)優(yōu)就順了。4.2 量化不是免費的午餐精度損失的邊界在哪量化是壓縮顯存的直接手段。INT8 在實際業(yè)務(wù)里精度損失通常很小大多數(shù)任務(wù)可以接受INT4 就要小心了復(fù)雜推理、數(shù)學(xué)題、長文本生成這類任務(wù)容易出現(xiàn)質(zhì)量下降。量化的本質(zhì)是犧牲精度換顯存換不換取決于你的任務(wù)容忍度。建議先做小規(guī)模評測再決定量化等級。拿 50 條業(yè)務(wù)真實樣本分別用 FP16、INT8、INT4 跑一遍人工對比輸出質(zhì)量。如果差別不明顯上 INT8如果任務(wù)涉及復(fù)雜推理保守留在 FP16。量化不是越狠越好翻車往往是因為上線前沒做逐條對比。4.3 推理服務(wù)的并發(fā)參數(shù)別讓默認值背鍋推理服務(wù)并發(fā)上不去很多人第一反應(yīng)是加顯卡其實先要查 KV Cache。并發(fā)每加一倍KV Cache 顯存占用跟著漲一倍?，F(xiàn)在主流的推理框架普遍帶 PagedAttention 機制能顯著降低緩存浪費這是首選方案。另一個通用做法是限制單請求最大 Token 數(shù)防止個別請求把顯存吃空。一個常見的推理啟動參數(shù)模板python -m vllm.entrypoints.openai.api_server \ --model ./model-weights \ --tensor-parallel-size 1 \ --max-model-len 4096 \ --max-num-seqs 8 \ --gpu-memory-utilization 0.9max-num-seqs 8限制同一時刻處理的請求數(shù)超出的排隊等待gpu-memory-utilization 0.9表示最多用掉 90% 顯存留 10% 給系統(tǒng)與臨時緩沖。這兩個參數(shù)直接決定服務(wù)穩(wěn)定性。如果并發(fā)一高就 502 或超時先把max-num-seqs降下來再觀察顯存曲線。部署形態(tài)上外部 API 適合快速驗證私有化部署適合數(shù)據(jù)敏感場景混合架構(gòu)適合既要靈活性又要安全性的團隊。三者不是替代關(guān)系而是不同階段的過渡路徑。5. 大模型實踐五大常見坑現(xiàn)象、原因與排查手冊5.1 模型一本正經(jīng)胡說八道現(xiàn)象對話里模型給出非常肯定但明顯錯誤的答案甚至引用不存在的文獻或數(shù)據(jù)。原因模型本身是預(yù)測下一個詞的工具它不知道什么是“事實”采樣參數(shù)設(shè)置不當會放大這種傾向。解決先把temperature降到 0.2 到 0.4 區(qū)間讓輸出更保守同時接入檢索兜底讓模型基于外部資料回答。不要指望模型自己承認不知道它只會繼續(xù)編。5.2 算好的顯存夠用上線就爆現(xiàn)象按權(quán)重顯存估算買好了卡一跑真實負載直接 OOM。原因忽略了 KV Cache 和推理框架自身占用。解決用 4.1 節(jié)的公式重算把 KV Cache 單獨列出來估上線前壓測至少 30 分鐘觀察顯存曲線而不是只跑一條測試請求。5.3 LoRA 微調(diào)后模型變笨了現(xiàn)象領(lǐng)域問題答得不錯但常識和推理能力明顯下降甚至語氣都變了。原因領(lǐng)域數(shù)據(jù)占比過高或者學(xué)習(xí)率太大模型把原來學(xué)會的通用能力覆蓋掉了。解決把領(lǐng)域數(shù)據(jù)占比降到 40% 以下加入通用對話數(shù)據(jù)混合訓(xùn)練LoRA 的學(xué)習(xí)率從 1e-4 降到 2e-5 再試。微調(diào)完做一組前后對比測試不要只看領(lǐng)域指標的漲跌。5.4 并發(fā)一高響應(yīng)就變慢甚至超時現(xiàn)象單請求測試 500ms并發(fā) 20 就變成 5 秒再調(diào)高直接超時。原因KV Cache 擠占了可用顯存模型開始換入換出參數(shù)推理變慢。解決啟用 PagedAttention 類方案限制max-num-seqs并為長響應(yīng)單獨設(shè)置超時時間。排查時先看nvidia-smi的顯存曲線如果接近打滿優(yōu)先調(diào)并發(fā)上限。5.5 評測集漲分上線效果打臉現(xiàn)象離線評測指標提升明顯真用戶反饋卻更差了。原因評測集和業(yè)務(wù)真實分布不一致或者模型把評測集樣例背下來了。解決評測集從真實業(yè)務(wù)流量里按月采樣每個月?lián)Q一部分同時建立人工抽檢機制每次上線前抽 50 條真實輸入對比新舊版本的輸出。指標只做參考用戶反饋才是最終裁判。6. 落到業(yè)務(wù)上的最后一公里RAG、Agent 與投入產(chǎn)出判斷法RAG檢索增強生成是當前性價比最高的落地方式。它不微調(diào)模型而是把知識庫切塊存進向量庫用戶提問時先檢索相關(guān)片段再交給模型基于片段生成答案。這樣做的好處是知識可以隨時更新不用重新訓(xùn)練。最小落地順序切塊、向量化、檢索、拼接、生成。切塊大小直接影響檢索效果一般按 200 到 500 Token 一塊塊之間重疊 10% 左右避免語義斷裂。Agent 類應(yīng)用則是把模型從一個答復(fù)工具變成一個執(zhí)行引擎讓它調(diào)用搜索、計算器或業(yè)務(wù) API 完成任務(wù)。這類方案效果上限高但穩(wěn)定性依賴工具調(diào)用的成功率適合內(nèi)部效率工具先行驗證。投入產(chǎn)出判斷我用一個簡單模型總成本等于訓(xùn)練或調(diào)用成本加上運維成本再加人工評測成本。如果業(yè)務(wù)對響應(yīng)速度要求極高、數(shù)據(jù)又敏感私有化部署大概率劃算如果只是內(nèi)部輔助寫作或信息整理外部 API 加 RAG 的成本優(yōu)勢明顯。我做這類方案有個習(xí)慣先把評測集建好再談算力采購。評測集來自真實業(yè)務(wù)流量每條都標了預(yù)期答案。拿到一個新模型時先跑一遍評測集超過當前方案再換不過線就繼續(xù)用舊方案。這個習(xí)慣幫我擋掉過很多次沖動換模型的翻車。先定評估標準再定技術(shù)選型順序不要反。希望幫到你。本文還有配套的精品資源點擊獲取