简介这份资源是厦门大学大数据教学团队出品的《大模型概念、技术与应用实践》完整课件由林子雨副教授主讲面向希望系统入门大模型的高校师生、技术从业者与自学者。内容从人工智能发展简史与图灵测试讲起梳理大模型的概念、发展历程、原理特点与分类并延伸至AIGC应用实践、行业落地场景、本地部署及智能体等前沿方向帮助读者建立从理论到实践的完整认知框架。资源包内含1个PDF文件共140页压缩包约14.41MB以图文并茂的幻灯片形式呈现目录结构清晰便于按章节检索与自学。目前已有663人学习下载适合作为课程教学参考或大模型科普读物帮助读者快速读懂大模型的核心逻辑与未来影响。1. 大模型概念、技术与应用实践从一份 140 页 PPT 的骨架说起很多人第一次接触大模型是被一份动辄上百页的 PPT 砸晕的概念、架构、训练、微调、推理、应用、评测每一页都像名词解释翻完还是不知道从哪下手。这份以“大模型概念、技术与应用实践”为主线的 140 页材料真正有价值的地方不是它讲了多少名词而是它把一条从原理到落地的链路串了起来——先讲清楚 Transformer 为什么能撑起今天的大模型再讲训练和微调到底在调什么最后落到检索增强、智能体、私有化部署这些能上手的方向。它适合两类人一类是想系统补齐大模型知识地图的开发者另一类是被业务推着要落地、但缺一套可复现路径的工程师。下面我不复述 PPT而是按它的骨架把每一块拆成能动手的部分。2. 概念先立住Transformer、注意力与“大”到底大在哪2.1 从 RNN 到 Transformer为什么必须换掉循环结构早期做序列任务主流是 RNN、LSTM 那一套。它的核心问题是串行第 t 个词必须等第 t-1 个词算完长序列上既慢又容易丢信息。Transformer 换了个思路用自注意力Self-Attention让每个位置直接和所有位置算相关性一步到位拿到全局依赖。这个改动带来的直接后果是训练可以高度并行才让“堆到千亿参数”在工程上变得可行。自注意力的计算可以写成一句话每个 token 生成 Query、Key、Value 三个向量用 Q 和 K 的点积算权重再对 V 加权求和。缩放点积注意力的公式是 softmax(QK^T / sqrt(d_k))V除以 sqrt(d_k) 是为了防止维度大时点积过大、softmax 梯度消失。多头注意力则是把这一套并行做 h 次让模型在不同子空间里关注不同关系——有的头盯语法有的头盯指代。import torch import torch.nn as nn import math class MultiHeadAttention(nn.Module): def __init__(self, d_model512, num_heads8): super().__init__() assert d_model % num_heads 0, d_model 必须能被 num_heads 整除 self.d_model d_model self.num_heads num_heads self.d_k d_model // num_heads # Q/K/V 三个投影一次线性层搞定 self.w_qkv nn.Linear(d_model, d_model * 3) self.w_out nn.Linear(d_model, d_model) def forward(self, x, maskNone): B, L, _ x.shape qkv self.w_qkv(x) # [B, L, 3*d_model] q, k, v qkv.chunk(3, dim-1) # 拆成多头: [B, num_heads, L, d_k] q q.view(B, L, self.num_heads, self.d_k).transpose(1, 2) k k.view(B, L, self.num_heads, self.d_k).transpose(1, 2) v v.view(B, L, self.num_heads, self.d_k).transpose(1, 2) # 缩放点积注意力 scores torch.matmul(q, k.transpose(-2, -1)) / math.sqrt(self.d_k) if mask is not None: scores scores.masked_fill(mask 0, -1e9) attn torch.softmax(scores, dim-1) out torch.matmul(attn, v) # [B, num_heads, L, d_k] out out.transpose(1, 2).contiguous().view(B, L, self.d_model) return self.w_out(out)这段代码里几个参数值得盯住d_model 是隐藏维度常见 512、768、4096num_heads 是头数必须整除 d_modeld_k 是每个头的维度等于 d_model/num_heads。mask 用来做因果掩码保证生成时第 t 个位置看不到后面的词。实际调参时头数不是越多越好头太多会让每个头维度太小、表达力下降工程上 8 到 32 头是常见区间。2.2 “大模型”的“大”体现在哪三个维度很多人以为大就是参数量大其实要拆成三层看。第一层是参数规模从亿级到千亿级决定了模型的容量上限第二层是数据规模训练语料从 GB 级到 TB 级决定了知识覆盖面第三层是算力规模训练一次动辄上千张加速卡跑数周决定了这件事的门槛。三者是绑定的参数大但数据少会过拟合数据大但参数小会欠拟合算力不够则前两者都落不了地。对从业者来说真正要关心的不是“多大算大”而是“我这个任务需要多大”。做文本分类、信息抽取这类判别任务几亿到几十亿参数的模型微调就够做开放式生成、复杂推理才需要更大的底座。盲目追大参数推理成本和延迟会直接吃掉业务收益这是最常见的翻车点。2.3 预训练、微调、推理三段式每一段在干什么大模型的落地链路基本是三段。预训练是拿海量无标注文本做自监督学习主流目标是预测下一个 token这一步产出的是底座模型成本最高一般团队不自己做。微调是拿任务数据在底座上继续训练分全量微调和参数高效微调PEFT后者只训练少量附加参数显存占用能降一个数量级。推理是把训练好的模型部署起来对外服务关注的是吞吐、延迟和显存。理解这三段的意义在于你拿到的开源模型已经是预训练产物你的工作 90% 集中在微调和推理这两段。把精力放对地方比从头研究预训练划算得多。3. 微调怎么做从全量微调到 LoRA 的最小可跑路径3.1 全量微调为什么劝退大多数人全量微调是把模型所有参数都更新一遍。以 7B 模型为例FP16 权重约 14GB加上梯度、优化器状态Adam 要存一阶和二阶动量显存需求轻松到 80GB 以上单卡根本放不下。就算用多卡训练一轮的时间和成本也让大多数团队望而却步。更现实的问题是全量微调容易在小数据集上过拟合把底座原有的通用能力“洗掉”出现灾难性遗忘。所以除非你有几十万条以上的高质量领域数据、且任务和底座差异极大否则不建议一上来就全量微调。常见做法是先试 PEFT效果不够再考虑全量。3.2 LoRA 的原理与三个必调参数LoRALow-Rank Adaptation的思路很巧不去改原权重 W而是在旁边加一个低秩分解的增量 ΔW BA其中 B 是 d×rA 是 r×kr 远小于 d 和 k。前向时输出变成 Wx BAx训练时只更新 A 和 B原权重冻结。这样可训练参数能降到原来的千分之一甚至更低。from peft import LoraConfig, get_peft_model from transformers import AutoModelForCausalLM model AutoModelForCausalLM.from_pretrained(your-base-model) lora_config LoraConfig( r8, # 秩越大容量越强常见 4/8/16/32 lora_alpha32, # 缩放系数一般设为 2*r target_modules[q_proj, v_proj], # 注入哪些层 lora_dropout0.05, # 防过拟合 biasnone, task_typeCAUSAL_LM ) model get_peft_model(model, lora_config) model.print_trainable_parameters() # 输出类似: trainable params: 4,194,304 || all params: 6,742,609,920 || 0.06%三个参数最关键。r 是秩控制新增参数的容量任务越复杂、数据越多r 可以适当调大但超过 64 收益递减明显。lora_alpha 是缩放系数实际生效的缩放是 alpha/r常见做法是设成 2r让缩放接近 2。target_modules 决定注入位置只注入 q_proj、v_proj 是最省的做法效果不够可以加上 k_proj、o_proj 甚至 FFN 层但参数量和显存会同步上升。3.3 数据准备与训练脚本的关键配置微调效果七分靠数据。指令微调的数据格式一般是“指令 输入 输出”三元组要保证指令多样、输出质量高、格式统一。数据量上几千到几万条高质量样本往往比几十万条噪声数据效果好。切分时留出验证集别拿训练集当验证集自欺欺人。from transformers import TrainingArguments, Trainer training_args TrainingArguments( output_dir./lora-out, per_device_train_batch_size4, # 显存不够就降到 1~2 gradient_accumulation_steps8, # 等效 batch 4*8 32 learning_rate2e-4, # LoRA 常用 1e-4 ~ 3e-4 num_train_epochs3, lr_scheduler_typecosine, warmup_ratio0.03, logging_steps10, save_strategyepoch, fp16True, # 支持 bf16 优先用 bf16 gradient_checkpointingTrue, # 用时间换显存 ) trainer Trainer( modelmodel, argstraining_args, train_datasettrain_ds, eval_dataseteval_ds, ) trainer.train()这里几个配置是血泪经验换来的。per_device_train_batch_size 和 gradient_accumulation_steps 配合能在小显存上凑出大等效 batch但累积步数太大会让训练变慢。learning_rate 对 LoRA 来说 2e-4 是个稳妥起点太大容易发散太小收敛慢。gradient_checkpointing 能显著降显存代价是训练速度慢 20% 到 30%。fp16 在部分卡上会溢出能用 bf16 就优先 bf16。3.4 微调后怎么验证别只看 loss训练 loss 下降不代表模型变好。要单独跑一批留出样本人工看生成质量重点看三类问题格式是否稳定、事实是否准确、有没有复读或跑偏。可以设计一组固定评测 prompt每次微调后都跑一遍对比形成自己的回归测试集。这一步很多团队省掉结果上线后才发现模型学会了胡说后悔药都没得吃。4. 应用落地RAG、智能体与私有化部署怎么选4.1 RAG 解决的是知识更新和幻觉问题微调擅长教模型“怎么说”但不擅长教它“知道什么”。知识类问答、文档检索这类场景更合适的是检索增强生成RAG先把文档切块、向量化存进向量库用户提问时检索最相关的片段拼进 prompt 让模型基于片段回答。这样知识更新只需重建索引不用重新训练幻觉也能靠“只依据检索内容回答”的约束压下去。# 伪代码RAG 检索 生成主流程 def rag_answer(query, retriever, llm, top_k5): # 1. 检索相关文档块 docs retriever.search(query, top_ktop_k) context \n\n.join(d[text] for d in docs) # 2. 拼 prompt明确约束模型只依据上下文 prompt f仅根据以下资料回答问题资料中没有的信息请回答“未找到”。 资料 {context} 问题{query} 回答 # 3. 生成 return llm.generate(prompt, max_new_tokens512, temperature0.2)切块大小和 top_k 是两个核心参数。块太大检索精度下降、prompt 变长块太小上下文不完整。常见块大小 300 到 800 字top_k 取 3 到 8。temperature 调低到 0.1 到 0.3让回答更稳定、少发挥。4.2 智能体把模型从“会答”变成“会做”智能体Agent是在模型外面套一层循环模型决定调用哪个工具、传什么参数工具执行后把结果回灌给模型直到任务完成。它适合需要多步操作、外部信息或计算的场景比如查数据库、调接口、做多轮规划。落地时最容易出问题的是工具描述不清和循环不收敛前者让模型乱调后者让任务卡死。常见做法是给每个工具写清楚用途和参数格式并设最大循环步数兜底。4.3 私有化部署的显存估算与量化取舍私有化部署绕不开显存。粗略估算FP16 推理显存约等于参数量 × 2GB7B 约 14GB加上 KV Cache 和中间激活实际要留 1.5 到 2 倍余量。显存不够就上量化INT8 约省一半INT4 约省四分之三但量化会带来精度损失尤其是数学和代码任务更敏感。精度7B 权重显存相对精度适用场景FP16约 14GB基准质量优先、显存充足INT8约 7GB轻微下降通用问答、成本敏感INT4约 4GB明显下降边缘部署、简单任务选型顺序建议先确认任务对精度的敏感度再定量化等级最后按并发量估 KV Cache。并发高时 KV Cache 可能比权重还吃显存这点常被忽略。5. 避坑与排查五个真实会踩的坑5.1 显存溢出OOM现象、原因与解决现象是训练或推理跑到一半报 CUDA out of memory。原因通常是 batch 太大、序列太长、没开梯度检查点或者推理时并发上来 KV Cache 爆了。解决上训练先降 per_device_train_batch_size 并用梯度累积补等效 batch开 gradient_checkpointing把序列长度截断到任务实际需要推理则限制最大并发、限制 max_new_tokens、必要时上量化。排查时用工具看显存峰值别凭感觉猜。5.2 微调后模型变“傻”灾难性遗忘怎么破现象是微调后任务数据答得不错但通用问题开始胡言乱语。原因是学习率太大、训练轮数太多把底座能力覆盖了。解决是降学习率、减 epoch、混入一定比例的通用指令数据一起训或者改用更小的 r。判断是否遗忘固定一组通用问题做回归测试别只看任务指标。5.3 RAG 检索答非所问切块和召回的锅现象是明明文档里有答案模型却说没找到。原因多半是切块把关键信息切断了或者向量模型和领域不匹配导致召回不准。解决是调整切块策略按语义或标题切别硬按字数切、加重叠窗口、换更合适的嵌入模型必要时加关键词召回做混合检索。检索质量不行后面生成再强也白搭。5.4 推理延迟高先分清是计算还是调度现象是单条请求要好几秒。原因可能是模型太大、没做批处理、或者每次请求都重新加载模型。解决是常驻模型进程、开启动态批处理continuous batching、用更快的推理框架、必要时蒸馏小模型。排查时把预处理、推理、后处理耗时分开打点别把网络延迟算到模型头上。5.5 评测失真别用训练集当验证集现象是离线指标很漂亮上线就拉胯。原因是评测集和训练集分布重叠或者评测指标和业务目标不一致。解决是严格切分数据、构造贴近真实分布的评测集、引入人工评估并定期用线上反馈更新评测集。评测这件事偷懒的代价最后都会在线上还回来。6. 把 140 页压成一条可执行路线我的取舍习惯真要把这份材料的骨架用起来我的习惯是先定任务类型再倒推技术选型而不是从模型出发。判别类任务分类、抽取、匹配优先考虑小模型微调成本低、延迟可控生成类任务先试 RAG知识更新灵活、幻觉可控需要多步操作的再上智能体但一定设好工具边界和循环上限。底座选择上先看社区活跃度和工具链成熟度再看参数规模别一上来就挑最大的。验证环节我会固定三件事一是留出真实分布的评测集每次改动都跑二是记录每次实验的配置和结果形成可回溯的实验台账三是上线前做一轮压力测试看并发下的延迟和显存曲线。这三件事看着笨但能挡掉大部分上线事故。最后说个具体技巧微调时把学习率预热warmup和余弦退火配上前 3% 步数线性升温后面余弦下降收敛稳定性比固定学习率好很多。这个配置我几乎每次都留着省心。大模型落地没有银弹把数据、评测、显存这三件事盯住剩下的就是耐心迭代。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/14 1:54:27 · 阅读 1.2k 大模型从原理到落地：Transformer、LoRA微调与RAG实战指南
简介这份资源是厦门大学大数据教学团队出品的《大模型概念、技术与应用实践》完整课件由林子雨副教授主讲面向希望系统入门大模型的高校师生、技术从业者与自学者。内容从人工智能发展简史与图灵测试讲起梳理大模型的概念、发展历程、原理特点与分类并延伸至AIGC应用实践、行业落地场景、本地部署及智能体等前沿方向帮助读者建立从理论到实践的完整认知框架。资源包内含1个PDF文件共140页压缩包约14.41MB以图文并茂的幻灯片形式呈现目录结构清晰便于按章节检索与自学。目前已有663人学习下载适合作为课程教学参考或大模型科普读物帮助读者快速读懂大模型的核心逻辑与未来影响。1. 大模型概念、技术与应用实践从一份 140 页 PPT 的骨架说起很多人第一次接触大模型是被一份动辄上百页的 PPT 砸晕的概念、架构、训练、微调、推理、应用、评测每一页都像名词解释翻完还是不知道从哪下手。这份以“大模型概念、技术与应用实践”为主线的 140 页材料真正有价值的地方不是它讲了多少名词而是它把一条从原理到落地的链路串了起来——先讲清楚 Transformer 为什么能撑起今天的大模型再讲训练和微调到底在调什么最后落到检索增强、智能体、私有化部署这些能上手的方向。它适合两类人一类是想系统补齐大模型知识地图的开发者另一类是被业务推着要落地、但缺一套可复现路径的工程师。下面我不复述 PPT而是按它的骨架把每一块拆成能动手的部分。2. 概念先立住Transformer、注意力与“大”到底大在哪2.1 从 RNN 到 Transformer为什么必须换掉循环结构早期做序列任务主流是 RNN、LSTM 那一套。它的核心问题是串行第 t 个词必须等第 t-1 个词算完长序列上既慢又容易丢信息。Transformer 换了个思路用自注意力Self-Attention让每个位置直接和所有位置算相关性一步到位拿到全局依赖。这个改动带来的直接后果是训练可以高度并行才让“堆到千亿参数”在工程上变得可行。自注意力的计算可以写成一句话每个 token 生成 Query、Key、Value 三个向量用 Q 和 K 的点积算权重再对 V 加权求和。缩放点积注意力的公式是 softmax(QK^T / sqrt(d_k))V除以 sqrt(d_k) 是为了防止维度大时点积过大、softmax 梯度消失。多头注意力则是把这一套并行做 h 次让模型在不同子空间里关注不同关系——有的头盯语法有的头盯指代。import torch import torch.nn as nn import math class MultiHeadAttention(nn.Module): def __init__(self, d_model512, num_heads8): super().__init__() assert d_model % num_heads 0, d_model 必须能被 num_heads 整除 self.d_model d_model self.num_heads num_heads self.d_k d_model // num_heads # Q/K/V 三个投影一次线性层搞定 self.w_qkv nn.Linear(d_model, d_model * 3) self.w_out nn.Linear(d_model, d_model) def forward(self, x, maskNone): B, L, _ x.shape qkv self.w_qkv(x) # [B, L, 3*d_model] q, k, v qkv.chunk(3, dim-1) # 拆成多头: [B, num_heads, L, d_k] q q.view(B, L, self.num_heads, self.d_k).transpose(1, 2) k k.view(B, L, self.num_heads, self.d_k).transpose(1, 2) v v.view(B, L, self.num_heads, self.d_k).transpose(1, 2) # 缩放点积注意力 scores torch.matmul(q, k.transpose(-2, -1)) / math.sqrt(self.d_k) if mask is not None: scores scores.masked_fill(mask 0, -1e9) attn torch.softmax(scores, dim-1) out torch.matmul(attn, v) # [B, num_heads, L, d_k] out out.transpose(1, 2).contiguous().view(B, L, self.d_model) return self.w_out(out)这段代码里几个参数值得盯住d_model 是隐藏维度常见 512、768、4096num_heads 是头数必须整除 d_modeld_k 是每个头的维度等于 d_model/num_heads。mask 用来做因果掩码保证生成时第 t 个位置看不到后面的词。实际调参时头数不是越多越好头太多会让每个头维度太小、表达力下降工程上 8 到 32 头是常见区间。2.2 “大模型”的“大”体现在哪三个维度很多人以为大就是参数量大其实要拆成三层看。第一层是参数规模从亿级到千亿级决定了模型的容量上限第二层是数据规模训练语料从 GB 级到 TB 级决定了知识覆盖面第三层是算力规模训练一次动辄上千张加速卡跑数周决定了这件事的门槛。三者是绑定的参数大但数据少会过拟合数据大但参数小会欠拟合算力不够则前两者都落不了地。对从业者来说真正要关心的不是“多大算大”而是“我这个任务需要多大”。做文本分类、信息抽取这类判别任务几亿到几十亿参数的模型微调就够做开放式生成、复杂推理才需要更大的底座。盲目追大参数推理成本和延迟会直接吃掉业务收益这是最常见的翻车点。2.3 预训练、微调、推理三段式每一段在干什么大模型的落地链路基本是三段。预训练是拿海量无标注文本做自监督学习主流目标是预测下一个 token这一步产出的是底座模型成本最高一般团队不自己做。微调是拿任务数据在底座上继续训练分全量微调和参数高效微调PEFT后者只训练少量附加参数显存占用能降一个数量级。推理是把训练好的模型部署起来对外服务关注的是吞吐、延迟和显存。理解这三段的意义在于你拿到的开源模型已经是预训练产物你的工作 90% 集中在微调和推理这两段。把精力放对地方比从头研究预训练划算得多。3. 微调怎么做从全量微调到 LoRA 的最小可跑路径3.1 全量微调为什么劝退大多数人全量微调是把模型所有参数都更新一遍。以 7B 模型为例FP16 权重约 14GB加上梯度、优化器状态Adam 要存一阶和二阶动量显存需求轻松到 80GB 以上单卡根本放不下。就算用多卡训练一轮的时间和成本也让大多数团队望而却步。更现实的问题是全量微调容易在小数据集上过拟合把底座原有的通用能力“洗掉”出现灾难性遗忘。所以除非你有几十万条以上的高质量领域数据、且任务和底座差异极大否则不建议一上来就全量微调。常见做法是先试 PEFT效果不够再考虑全量。3.2 LoRA 的原理与三个必调参数LoRALow-Rank Adaptation的思路很巧不去改原权重 W而是在旁边加一个低秩分解的增量 ΔW BA其中 B 是 d×rA 是 r×kr 远小于 d 和 k。前向时输出变成 Wx BAx训练时只更新 A 和 B原权重冻结。这样可训练参数能降到原来的千分之一甚至更低。from peft import LoraConfig, get_peft_model from transformers import AutoModelForCausalLM model AutoModelForCausalLM.from_pretrained(your-base-model) lora_config LoraConfig( r8, # 秩越大容量越强常见 4/8/16/32 lora_alpha32, # 缩放系数一般设为 2*r target_modules[q_proj, v_proj], # 注入哪些层 lora_dropout0.05, # 防过拟合 biasnone, task_typeCAUSAL_LM ) model get_peft_model(model, lora_config) model.print_trainable_parameters() # 输出类似: trainable params: 4,194,304 || all params: 6,742,609,920 || 0.06%三个参数最关键。r 是秩控制新增参数的容量任务越复杂、数据越多r 可以适当调大但超过 64 收益递减明显。lora_alpha 是缩放系数实际生效的缩放是 alpha/r常见做法是设成 2r让缩放接近 2。target_modules 决定注入位置只注入 q_proj、v_proj 是最省的做法效果不够可以加上 k_proj、o_proj 甚至 FFN 层但参数量和显存会同步上升。3.3 数据准备与训练脚本的关键配置微调效果七分靠数据。指令微调的数据格式一般是“指令 输入 输出”三元组要保证指令多样、输出质量高、格式统一。数据量上几千到几万条高质量样本往往比几十万条噪声数据效果好。切分时留出验证集别拿训练集当验证集自欺欺人。from transformers import TrainingArguments, Trainer training_args TrainingArguments( output_dir./lora-out, per_device_train_batch_size4, # 显存不够就降到 1~2 gradient_accumulation_steps8, # 等效 batch 4*8 32 learning_rate2e-4, # LoRA 常用 1e-4 ~ 3e-4 num_train_epochs3, lr_scheduler_typecosine, warmup_ratio0.03, logging_steps10, save_strategyepoch, fp16True, # 支持 bf16 优先用 bf16 gradient_checkpointingTrue, # 用时间换显存 ) trainer Trainer( modelmodel, argstraining_args, train_datasettrain_ds, eval_dataseteval_ds, ) trainer.train()这里几个配置是血泪经验换来的。per_device_train_batch_size 和 gradient_accumulation_steps 配合能在小显存上凑出大等效 batch但累积步数太大会让训练变慢。learning_rate 对 LoRA 来说 2e-4 是个稳妥起点太大容易发散太小收敛慢。gradient_checkpointing 能显著降显存代价是训练速度慢 20% 到 30%。fp16 在部分卡上会溢出能用 bf16 就优先 bf16。3.4 微调后怎么验证别只看 loss训练 loss 下降不代表模型变好。要单独跑一批留出样本人工看生成质量重点看三类问题格式是否稳定、事实是否准确、有没有复读或跑偏。可以设计一组固定评测 prompt每次微调后都跑一遍对比形成自己的回归测试集。这一步很多团队省掉结果上线后才发现模型学会了胡说后悔药都没得吃。4. 应用落地RAG、智能体与私有化部署怎么选4.1 RAG 解决的是知识更新和幻觉问题微调擅长教模型“怎么说”但不擅长教它“知道什么”。知识类问答、文档检索这类场景更合适的是检索增强生成RAG先把文档切块、向量化存进向量库用户提问时检索最相关的片段拼进 prompt 让模型基于片段回答。这样知识更新只需重建索引不用重新训练幻觉也能靠“只依据检索内容回答”的约束压下去。# 伪代码RAG 检索 生成主流程 def rag_answer(query, retriever, llm, top_k5): # 1. 检索相关文档块 docs retriever.search(query, top_ktop_k) context \n\n.join(d[text] for d in docs) # 2. 拼 prompt明确约束模型只依据上下文 prompt f仅根据以下资料回答问题资料中没有的信息请回答“未找到”。 资料 {context} 问题{query} 回答 # 3. 生成 return llm.generate(prompt, max_new_tokens512, temperature0.2)切块大小和 top_k 是两个核心参数。块太大检索精度下降、prompt 变长块太小上下文不完整。常见块大小 300 到 800 字top_k 取 3 到 8。temperature 调低到 0.1 到 0.3让回答更稳定、少发挥。4.2 智能体把模型从“会答”变成“会做”智能体Agent是在模型外面套一层循环模型决定调用哪个工具、传什么参数工具执行后把结果回灌给模型直到任务完成。它适合需要多步操作、外部信息或计算的场景比如查数据库、调接口、做多轮规划。落地时最容易出问题的是工具描述不清和循环不收敛前者让模型乱调后者让任务卡死。常见做法是给每个工具写清楚用途和参数格式并设最大循环步数兜底。4.3 私有化部署的显存估算与量化取舍私有化部署绕不开显存。粗略估算FP16 推理显存约等于参数量 × 2GB7B 约 14GB加上 KV Cache 和中间激活实际要留 1.5 到 2 倍余量。显存不够就上量化INT8 约省一半INT4 约省四分之三但量化会带来精度损失尤其是数学和代码任务更敏感。精度7B 权重显存相对精度适用场景FP16约 14GB基准质量优先、显存充足INT8约 7GB轻微下降通用问答、成本敏感INT4约 4GB明显下降边缘部署、简单任务选型顺序建议先确认任务对精度的敏感度再定量化等级最后按并发量估 KV Cache。并发高时 KV Cache 可能比权重还吃显存这点常被忽略。5. 避坑与排查五个真实会踩的坑5.1 显存溢出OOM现象、原因与解决现象是训练或推理跑到一半报 CUDA out of memory。原因通常是 batch 太大、序列太长、没开梯度检查点或者推理时并发上来 KV Cache 爆了。解决上训练先降 per_device_train_batch_size 并用梯度累积补等效 batch开 gradient_checkpointing把序列长度截断到任务实际需要推理则限制最大并发、限制 max_new_tokens、必要时上量化。排查时用工具看显存峰值别凭感觉猜。5.2 微调后模型变“傻”灾难性遗忘怎么破现象是微调后任务数据答得不错但通用问题开始胡言乱语。原因是学习率太大、训练轮数太多把底座能力覆盖了。解决是降学习率、减 epoch、混入一定比例的通用指令数据一起训或者改用更小的 r。判断是否遗忘固定一组通用问题做回归测试别只看任务指标。5.3 RAG 检索答非所问切块和召回的锅现象是明明文档里有答案模型却说没找到。原因多半是切块把关键信息切断了或者向量模型和领域不匹配导致召回不准。解决是调整切块策略按语义或标题切别硬按字数切、加重叠窗口、换更合适的嵌入模型必要时加关键词召回做混合检索。检索质量不行后面生成再强也白搭。5.4 推理延迟高先分清是计算还是调度现象是单条请求要好几秒。原因可能是模型太大、没做批处理、或者每次请求都重新加载模型。解决是常驻模型进程、开启动态批处理continuous batching、用更快的推理框架、必要时蒸馏小模型。排查时把预处理、推理、后处理耗时分开打点别把网络延迟算到模型头上。5.5 评测失真别用训练集当验证集现象是离线指标很漂亮上线就拉胯。原因是评测集和训练集分布重叠或者评测指标和业务目标不一致。解决是严格切分数据、构造贴近真实分布的评测集、引入人工评估并定期用线上反馈更新评测集。评测这件事偷懒的代价最后都会在线上还回来。6. 把 140 页压成一条可执行路线我的取舍习惯真要把这份材料的骨架用起来我的习惯是先定任务类型再倒推技术选型而不是从模型出发。判别类任务分类、抽取、匹配优先考虑小模型微调成本低、延迟可控生成类任务先试 RAG知识更新灵活、幻觉可控需要多步操作的再上智能体但一定设好工具边界和循环上限。底座选择上先看社区活跃度和工具链成熟度再看参数规模别一上来就挑最大的。验证环节我会固定三件事一是留出真实分布的评测集每次改动都跑二是记录每次实验的配置和结果形成可回溯的实验台账三是上线前做一轮压力测试看并发下的延迟和显存曲线。这三件事看着笨但能挡掉大部分上线事故。最后说个具体技巧微调时把学习率预热warmup和余弦退火配上前 3% 步数线性升温后面余弦下降收敛稳定性比固定学习率好很多。这个配置我几乎每次都留着省心。大模型落地没有银弹把数据、评测、显存这三件事盯住剩下的就是耐心迭代。希望帮到你。本文还有配套的精品资源点击获取