简介这是厦门大学大数据教学团队出品的《大模型概念、技术与应用实践》PPT课件共140页面向希望系统了解大模型技术体系与产业应用的读者尤其适合零基础起步的学习者。资源为单个PDF文件容量14.41MB目前已有663人参与学习。课件先梳理人工智能发展简史与图灵测试概述其从诞生到未来发展的多个阶段再进入大模型核心内容涵盖概念演变、技术原理、模型分类、典型产品、本地部署方式等并专门围绕DeepSeek展开科普随后聚焦AIGC应用与实践展示自然语言处理、多模态生成等场景帮助读者理解大模型如何影响工作与生活。整套内容图文并茂、逻辑连贯既适合高校教学也可作为企业内训与自学的入门参考。整体上这套PPT从历史脉络讲到前沿实践能帮助读者建立对DeepSeek与大模型的系统认知。1. 大模型不是玩具读这类课件前先想清楚的三件事一份百页级的大模型讲义标题通常会把三个词放一起概念、技术与应用。很多人翻完一遍记住了 Transformer 和微调回到项目里却不知道怎么下手。原因不在讲义在于顺序——概念是帮你建立坐标系技术是给你工具应用才是真正决定投入产出的一步。这一篇我按工程落地的路径重新拆解这套大模型概念、技术与应用实践先说概念里哪些必须吃透、哪些可以直接翻再给一条从微调到部署的可抄作业链路最后把最容易翻车的五个坑摆出来。适合两类人想私有化部署但被显存和成本劝退的开发者以及正准备把大模型接进真实业务的方案负责人。读完你至少能算出自己该选哪条路线。2. 先把概念层去魅Token、参数量与上下文窗口影响你的每个决策2.1 Token 切分不是玄学两行代码看懂模型眼里的文本概念部分绕不开的第一个词是 Token。你可以把它理解成模型读文本的最小单位一个中文字符可能对应一个或多个 Token英文单词经常被切成子词。这个切法决定了两件事你的文本在模型看来有多长以及你的算力成本有多高。与其看十页理论不如直接跑一次切分。from transformers import AutoTokenizer # 加载本地权重不依赖远程仓库 tokenizer AutoTokenizer.from_pretrained(./model-weights, trust_remote_codeTrue) text 大模型微调最核心的不是调参而是数据 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 数量还直接等于推理成本。同一段中文不同分词器切出来的 Token 数能差出 30%。选型时别只看参数量拿你业务里的真实文本分别切一下谁省 Token 谁就更省钱。2.2 参数量、上下文窗口与能力边界一张表绕开越大越好误区概念层第二个容易走偏的是参数量崇拜。几十亿参数和百亿千亿参数之间差的不是“聪明程度”而是使用场景。整理成一张选型表比读长章节管用模型规模典型硬件需求适合场景不适合场景十亿级单卡 16G 起步垂直领域分类、抽取、改写复杂推理、长文生成百亿级单机多卡或大显存通用对话、内容生成、私有化部署高并发 C 端服务千亿级多机集群深度推理、复杂指令、研究实验预算有限的内部工具上下文窗口是另一个常被误读的指标。窗口大意味着“能读进去的内容多”不代表“记得住”。模型对窗口中间位置的内容记忆力最差这是注意力机制的结构性特点。所以做长文档问答时别指望把整个文档塞进窗口就能解决后面讲 RAG 的章节会细说。2.3 这类 140 页讲义的概念章节哪些页值得精读哪些页可以直接翻概念部分占了这类讲义将近一半篇幅但真正和落地强相关的只有三块神经网络怎么表示文本、Transformer 的注意力机制在做什么、训练分哪几个阶段。其他关于模型历史、各家厂商的路线对比了解即可。个人建议的精读顺序是先读 Token 与 Embedding再读注意力机制的直觉解释最后读训练阶段划分。这三块对应你后面要做的三个决策数据怎么处理、显存怎么估、微调怎么选。泛泛讲“神经网络是什么”的章节可以直接跳过你已经会用 Python 写接口的话那部分唤醒不了任何实操记忆。我一般会建议团队把概念部分的笔记压缩成一页纸一张模型能力对照表一段训练阶段流程图一份 Token 切分示例。剩下的内容等真遇到问题时再回头查比一次读完更有效。3. 微调是最贵的改性格环节从 SFT 到 LoRA 的一条完整训练路径3.1 预训练、SFT、RLHF三个训练阶段各自负责什么预训练解决的是“语言能力”问题模型在这个阶段读海量文本学会语法、知识和推理的底层规律。这个阶段成本极高普通团队不用碰。SFT监督微调解决的是“听从指令”的问题用人工标注的问答对让模型学会回答的格式和语气。绝大多数业务定制落在这一层。RLHF基于人类反馈的强化学习解决的是“价值观对齐”的问题让模型学会拒绝敏感请求、输出更安全的内容这个阶段同样重资源。对做应用的人来说只需要把 SFT 吃透。RLHF 通常由模型提供方完成你拿到的开源模型已经带了一定程度的对齐。如果业务有特殊的安全要求比如医疗建议或法律意见需要再加一层偏好微调但那是少数场景。三者的关系可以概括成一句话预训练决定上限SFT 决定下限RLHF 决定安全性。你的业务提升空间全在 SFT 里。3.2 全参微调与 LoRA 的选型模板按显存预算倒推方案全参微调会把模型全部权重都更新一遍效果最好但也最贵LoRA 只训练一小部分新增参数用很低的成本逼近全参效果。这是一个决策模板预算内有 4 张以上高端显卡且需要极致效果全参微调单卡或双卡、数据量 10 万条以内LoRA数据量巨大且任务单一先 LoRA 跑基线再决定要不要升级LoRA 不是玄学它的核心是冻结原模型权重额外插入低秩矩阵去学任务差异。训练时只更新这个增量部分推理时把增量合并回原权重推理速度不受影响。一个可抄作业的配置from transformers import AutoModelForCausalLM from peft import LoraConfig, get_peft_model, TaskType # 加载基础模型 model AutoModelForCausalLM.from_pretrained( ./base-model-weights, torch_dtypeauto, device_mapauto ) lora_config LoraConfig( r16, # 秩决定新增参数量常用 8 / 16 / 32 lora_alpha32, # 缩放系数经验值取 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() # 看新增参数量占比r16意味着每个被改造的线性层额外学习一个 16 维的低秩空间越大表达能力越强但过大会过拟合。lora_alpha32控制最终注入的强度alpha 与 r 的比值决定微调对原模型的影响程度。一个血泪经验是不确定性大的时候先上小模型加 LoRA 跑通流程。别一上来就在几百亿参数上试翻车成本太高。3.3 数据配比与清洗翻不翻车七成看这里微调翻车的首要原因不是参数是数据。常见问题包括指令重复导致模型只会一种句式、答案包含噪声导致生成质量下降、领域数据与通用数据比例失衡导致灾难性遗忘。一个稳妥的配比基准数据类别占比单条长度建议领域指令数据30%100-500 Token通用指令数据30%50-300 Token通用对话数据20%50-200 Token长文/格式化输出样本20%500-2000 Token领域数据占比通常不要超过 40%否则模型容易丢掉通用能力。清洗这一步直接决定数据质量我常用一个最小脚本过滤明显噪声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 # 过滤重复率过高的噪声文本 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)这个脚本处理了三类噪声超链接、短文本、重复率异常高的文本。实际项目里还得加一层敏感词过滤和格式校验。清洗完的数据要抽看 20 条确认格式统一。格式不一致是微调后输出乱套的头号原因。4. 部署与推理显存、量化、并发的三笔账算清再动手4.1 先算显存再下单一套能估到够不够用的公式部署环节第一大坑是显存估算错误。很多人只算了模型权重的大小忘了 KV Cache 和激活值。推理时显存占用大致是权重显存加 KV Cache再加激活值与临时缓冲。权重显存等于参数量乘字节数FP16 下每 10 亿参数约 2GBKV Cache 则与层数、注意力头数、序列长度和并发数直接相关并发越高占得越猛。给出一个浓缩的估算方式按模型规模粗算模型规模FP16 推理最低显存参考INT8 量化参考INT4 量化参考十亿级约 16GB约 8GB约 5GB百亿级约 200GB约 100GB约 60GB千亿级约 1600GB约 800GB约 500GB这里还没算 KV Cache。长对话场景会把 KV Cache 放大好几倍最终显存需求经常比权重显存高一倍以上。我的习惯是先按“权重显存乘 2”打底再根据并发和序列长度往上加。峰值显存和你“感觉够用”的显存之间差距最大的就是 KV Cache。理解这一点后面并发调优就顺了。4.2 量化不是免费的午餐精度损失的边界在哪量化是压缩显存的直接手段。INT8 在实际业务里精度损失通常很小大多数任务可以接受INT4 就要小心了复杂推理、数学题、长文本生成这类任务容易出现质量下降。量化的本质是牺牲精度换显存换不换取决于你的任务容忍度。建议先做小规模评测再决定量化等级。拿 50 条业务真实样本分别用 FP16、INT8、INT4 跑一遍人工对比输出质量。如果差别不明显上 INT8如果任务涉及复杂推理保守留在 FP16。量化不是越狠越好翻车往往是因为上线前没做逐条对比。4.3 推理服务的并发参数别让默认值背锅推理服务并发上不去很多人第一反应是加显卡其实先要查 KV Cache。并发每加一倍KV Cache 显存占用跟着涨一倍。现在主流的推理框架普遍带 PagedAttention 机制能显著降低缓存浪费这是首选方案。另一个通用做法是限制单请求最大 Token 数防止个别请求把显存吃空。一个常见的推理启动参数模板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限制同一时刻处理的请求数超出的排队等待gpu-memory-utilization 0.9表示最多用掉 90% 显存留 10% 给系统与临时缓冲。这两个参数直接决定服务稳定性。如果并发一高就 502 或超时先把max-num-seqs降下来再观察显存曲线。部署形态上外部 API 适合快速验证私有化部署适合数据敏感场景混合架构适合既要灵活性又要安全性的团队。三者不是替代关系而是不同阶段的过渡路径。5. 大模型实践五大常见坑现象、原因与排查手册5.1 模型一本正经胡说八道现象对话里模型给出非常肯定但明显错误的答案甚至引用不存在的文献或数据。原因模型本身是预测下一个词的工具它不知道什么是“事实”采样参数设置不当会放大这种倾向。解决先把temperature降到 0.2 到 0.4 区间让输出更保守同时接入检索兜底让模型基于外部资料回答。不要指望模型自己承认不知道它只会继续编。5.2 算好的显存够用上线就爆现象按权重显存估算买好了卡一跑真实负载直接 OOM。原因忽略了 KV Cache 和推理框架自身占用。解决用 4.1 节的公式重算把 KV Cache 单独列出来估上线前压测至少 30 分钟观察显存曲线而不是只跑一条测试请求。5.3 LoRA 微调后模型变笨了现象领域问题答得不错但常识和推理能力明显下降甚至语气都变了。原因领域数据占比过高或者学习率太大模型把原来学会的通用能力覆盖掉了。解决把领域数据占比降到 40% 以下加入通用对话数据混合训练LoRA 的学习率从 1e-4 降到 2e-5 再试。微调完做一组前后对比测试不要只看领域指标的涨跌。5.4 并发一高响应就变慢甚至超时现象单请求测试 500ms并发 20 就变成 5 秒再调高直接超时。原因KV Cache 挤占了可用显存模型开始换入换出参数推理变慢。解决启用 PagedAttention 类方案限制max-num-seqs并为长响应单独设置超时时间。排查时先看nvidia-smi的显存曲线如果接近打满优先调并发上限。5.5 评测集涨分上线效果打脸现象离线评测指标提升明显真用户反馈却更差了。原因评测集和业务真实分布不一致或者模型把评测集样例背下来了。解决评测集从真实业务流量里按月采样每个月换一部分同时建立人工抽检机制每次上线前抽 50 条真实输入对比新旧版本的输出。指标只做参考用户反馈才是最终裁判。6. 落到业务上的最后一公里RAG、Agent 与投入产出判断法RAG检索增强生成是当前性价比最高的落地方式。它不微调模型而是把知识库切块存进向量库用户提问时先检索相关片段再交给模型基于片段生成答案。这样做的好处是知识可以随时更新不用重新训练。最小落地顺序切块、向量化、检索、拼接、生成。切块大小直接影响检索效果一般按 200 到 500 Token 一块块之间重叠 10% 左右避免语义断裂。Agent 类应用则是把模型从一个答复工具变成一个执行引擎让它调用搜索、计算器或业务 API 完成任务。这类方案效果上限高但稳定性依赖工具调用的成功率适合内部效率工具先行验证。投入产出判断我用一个简单模型总成本等于训练或调用成本加上运维成本再加人工评测成本。如果业务对响应速度要求极高、数据又敏感私有化部署大概率划算如果只是内部辅助写作或信息整理外部 API 加 RAG 的成本优势明显。我做这类方案有个习惯先把评测集建好再谈算力采购。评测集来自真实业务流量每条都标了预期答案。拿到一个新模型时先跑一遍评测集超过当前方案再换不过线就继续用旧方案。这个习惯帮我挡掉过很多次冲动换模型的翻车。先定评估标准再定技术选型顺序不要反。希望帮到你。本文还有配套的精品资源点击获取