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