上一篇我们聊了 Python 自然语言处理 的经典底座分词、停用词、TF-IDF、Word2Vec。如果你已经跟着跑过一遍应该会有一个感觉——这套东西在整理文本、做简单分类的时候非常可靠但当你想让模型理解一句话里到底是讽刺还是由衷夸赞或者让它直接写出一段像样的回复传统管线就明显使不上劲。AI 时代的 NLP 指南不能只停在“把文本变成向量再丢进分类器”这一步。这篇作为系列的二我打算把视角转向 2024 年大家真正在用的一套东西Transformer 架构、预训练模型生态、参数高效微调、检索增强生成、评估体系和推理部署。内容会偏工程代码为主但每个环节我都会解释“为什么这么做”毕竟光抄代码解决不了踩坑。1. 从经典管线走进大模型时代你的知识地图需要更新了1.1 传统 NLP 仍然在岗但天花板很明显如果你去翻公司里运行了好几年的旧系统大概率还能看到 TF-IDF 加逻辑回归做文本分类、Word2Vec 算相似度、LDA 做主题聚类这类经典方案。它们没有被淘汰的原因是便宜、稳定、可解释。一份日志分类任务几万条样本训练完分类速度以毫秒计线上出问题了还能直接查是哪几个特征把样本分错的。这类场景你去换大模型反而是给自己找麻烦。但经典管线在语义理解上的天花板也是真实存在的。最典型的问题是表示单一。Word2Vec 训练出来的是一个静态向量“苹果”这个词无论在“苹果很好吃”还是“苹果手机很贵”里都是同一个向量。你必须靠下游分类器去隐式区分而分词和上下文信息一旦清洗得不到位模型就很容易学歪。第二个问题是长距离依赖处理不好。TF-IDF 只看词频Word2Vec 只看局部窗口碰到“虽然这家店的菜偏咸但我还是因为服务态度给了好评”这种句子传统特征几乎抓不住转折关系。第三个问题才是致命的传统 NLP 没有生成能力。你可以用分类器判断情感是正还是负但你没法让它输出一句“这道菜偏咸但服务加分”这样有信息量的自然语言。2024 年的业务需求里生成式回复、摘要、开放问答占了很大一块这已经不是特征工程能解决的事儿了。1.2 大模型给 NLP 增加了哪些新能力大模型的出现并不是把分词和词向量消灭了而是把 NLP 的能力重心从“特征工程”转移到“预训练加对齐”。你在第一部分学到的知识仍然能帮你理解 tokenization、词表、向量空间只是现在模型参数量大了几个量级且学会了根据上下文动态生成词表示。新一代 NLP 体系下几个关键变化值得你重新建立认知上下文表征同一个词在不同句子里的向量不一样。这是 Transformer 这类架构带来的核心突破。迁移学习成为默认范式先在大规模语料上预训练再在具体任务上微调或直接做少样本提示。生成与理解统一很多任务不再区分“做分类”和“写回复”统一看成“给模型一段输入让它输出目标文本”。情感分析也可以变成“请判断这句话的情感输出‘正向’或‘负向’”。检索和记忆分离模型参数负责语言能力外部知识库负责事实两者通过检索增强生成RAG结合。这些能力让 NLP 项目的技术栈变长了但并不意味着你什么都要亲自训练。恰恰相反2024 年的实用路线是用成熟的开源预训练模型花最少的成本适配自己的数据。1.3 新知识地图四块拼图如果让我给一个刚进入 AI 时代 NLP 的开发者画知识地图我会把它分成四块模型原理至少理解 Transformer 的核心机制否则后面看微调、看推理优化全是黑话。模型使用熟悉预训练模型加载、分词器、文本分类和生成的标准写法。训练适配用低成本方式把通用模型变成领域模型常见方案是 LoRA 这类参数高效微调。工程落地包括评测、检索增强、显存估算、推理加速这部分最容易被教程忽略但生产环境每天都被它折磨。下面几章就按这张地图展开。你不用一次性全部吃透但建议跟着代码把每个环节跑通一遍踩一次坑比看十遍文章都管用。2. Transformer 不是黑盒注意力机制与位置编码的人话版2.1 从静态词向量到上下文表示为什么“苹果”在不同句子中含义不同理解 Transformer首先得理解它解决的核心问题。经典词向量给每个词分配一个固定向量这个向量等于把所有上下文打包成了一个平均值所以语义必然模糊。Transformer 引入了一个更聪明的做法每个词在进入模型时有一个初始表示然后它会根据当前句子的其他词不断更新自己的表示。我们可以把它想象成开会。参会者带着自己的初步观点进会议室经过一轮讨论后每个人的最终意见都被其他人的发言修正过。如果把“讨论”这个过程重复多层最终得到的观点就融合了整个会议的信息。Transformer 的一层网络做的就是一次“讨论”多层堆叠就是多轮讨论。这就是为什么它能捕捉到“苹果”在“苹果很好吃”和“苹果手机很贵”里语义不同——因为它的表示取决于同伴词汇。# 概念示例一个 token 在两层网络里不断被“上下文”改写 # 实际实现中会用矩阵并行计算这里只展示思想 def contextualize(token_embedding, sentence_embeddings): context_vector average(sentence_embeddings) return update(token_embedding, context_vector)2.2 自注意力机制的会议纪要员比喻自注意力Self-Attention是 Transformer 讨论环节的核心算法。每个 token 会产生三个向量分别叫 Query、Key、Value。这三个名字看起来玄乎其实对应一个非常朴素的流程Query当前这个词想问什么。相当于一个人心里想“谁和我现在讨论的话题有关”Key其他词发布的“标签”。相当于每个人胸前的名签写着“我涉及这些话题”。Value其他词真正的内容。相当于每个人要说的话。计算过程就是拿 Query 去和所有 Key 做点积得到一个分数表示“你和我的相关性”。分数经过 softmax 归一化后变成权重再用这个权重对所有 Value 做加权求和得到当前词的更新表示。打个比方你在开会时问了一句“预算多少合适”Key 匹配到“预算”“成本”“报价”这些词的注意力高于是你吸收的 Value 主要来自这几个词而不是来自无关的“今天的天气”。每一层 transformer 都在重复这个“找你最该听的内容”的过程。import torch import torch.nn.functional as F def softmax_attention(q, k, v): scores torch.matmul(q, k.transpose(-2, -1)) scores scores / (k.shape[-1] ** 0.5) # 缩放避免点积过大 weights F.softmax(scores, dim-1) return torch.matmul(weights, v)这里的缩放因子是维度开根号。为什么要缩放因为维度越高点积结果方差越大softmax 之后容易进入梯度极小的区间缩放能把数值拉回合理范围。这个细节你在自己手写注意力的时候会深刻体会到。2.3 多头注意力、位置编码与训练稳定三件套实际使用的 Transformer 不是只做一次注意力而是把向量切成多个子空间分别做注意力再把结果拼回来这叫多头注意力。多头有什么必要单一注意力只能学一种相关性多头相当于多组人从不同角度看同一份材料有的关注语法搭配有的关注指代关系有的关注语义相近。最后模型融合这些视角表达能力就上来了。另一个绕不开的问题是位置编码。注意力本身对位置不敏感你把“我打你”三个词的顺序打乱注意力计算完全不受影响但语义变了。所以模型必须额外注入位置信息。最早的方案是用正弦函数生成固定位置向量后来演变出可学习位置编码、旋转位置编码等。2024 年的主流开源模型基本都采用相对位置或旋转位置编码好处是对长文本的泛化更好。训练稳定三件套指的是残差连接、层归一化和掩码。残差连接让第 n 层可以拿到第 n-1 层的原始信息避免深层网络信息丢失层归一化让每一层的输入分布不要剧烈波动掩码则分两类padding mask 用来遮住填充字符保证它们不参与注意力causal mask 让生成模型只能看到当前位置之前的 token防止偷看未来。理解了这三件事你再去看模型配置文件里的参数名就不会是一头雾水。3. 用 transformers 生态把文本分类和生成都跑起来3.1 环境准备先把版本和 CUDA 的坑填了想在 2024 年顺畅地跑 NLP 实验最推荐的方式还是基于 Python 生态使用 transformers 这类成熟库。第一步是创建干净的虚拟环境推荐 Python 3.10 或 3.11。conda create -n nlp python3.10 conda activate nlp pip install torch transformers datasets tokenizers accelerate这里有个非常常见的坑如果你直接pip install torch在部分平台上会默认安装 CPU 版本。机器有 NVIDIA 显卡却用 CPU 跑后面一微调就慢得怀疑人生。正确做法是先到 PyTorch 官网按 CUDA 版本安装对应的 wheel再继续装其他库。另一个坑是版本冲突。transformers 依赖 tokenizers而某些老项目会把 tokenizers 降到很旧的版本结果加载模型时报 OSError。遇到这种问题不要急着整个环境重装先看报错是不是tokenizer版本不匹配单独升级即可。如果只是做小规模实验CPU 也不是不能跑像 BERT 这类 base 规模模型CPU 上推理单个短文本花费几十毫秒到几百毫秒够你调试代码逻辑。3.2 一条 AutoModel 走天下加载分词器与模型transformers 生态最方便的一点是 AutoClass 机制。你不用关心某个模型内部结构叫什么名字只要提供模型 ID库会自动把正确的分词器、模型结构加载回来。from transformers import AutoTokenizer, AutoModelForSequenceClassification model_name bert-base-chinese # 中文场景常用的基础文本模型 tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForSequenceClassification.from_pretrained(model_name, num_labels2)分词器负责把原始文本切成 token再映射成 ID同时生成注意力掩码等输入字段。中文文本的切分方式与英文差异很大英文一个词往往就是一个 token中文则可能按字或按子词切分。BERT-中文这一类模型通常基于字粒度好处是不用担心分词错误传导到模型。为什么需要AutoModelForSequenceClassification而不是直接用AutoModel因为分类任务需要在预训练模型上方加一个分类头这个类会自动帮你加。同理生成任务有AutoModelForCausalLM问答任务有AutoModelForQuestionAnswering。你可以把这些看作“模型骨架加上任务专用头”的组合。3.3 文本分类任务的完整跑通流程跑通一个文本分类 Demo代码很短但背后的逻辑很完整。如果你还没微调模型直接用预训练权重做推理输出只是随机初始化的结果意义不大真正有意义的是先微调再推理。这里先展示推理流程的标准写法下一章讲微调。texts [这个商品的体验超出预期, 物流太慢等了一周没有动静] batch tokenizer( texts, paddingTrue, # 将句子pad到等长 truncationTrue, # 超长截断 max_length128, return_tensorspt, ) outputs model(**batch) preds outputs.logits.argmax(dim-1) print(preds)paddingTrue会统一长度但 pad 出来的位置必须靠 attention mask 告诉模型不要去注意truncationTrue负责把超过 max_length 的内容扔掉。实际项目里max_length 的选择要看你文本的真实长度分布不要拍脑袋定 512。如果绝大多数样本都是 64 token 以内硬设 512 只会浪费显存和算力。我自己的习惯是先用 tokenizer 统计训练集的长度分布再选择覆盖 90% 样本的最小长度。比如分布结果显示 95% 的样本在 80 token 以内就设 96 或 128不要盲目跟风设 512。3.4 生成式任务不是分类的翻版生成式任务的使用方式完全不同。分类模型拿一段文本输出一个标签生成模型拿一段 prompt输出一段新文本。以开源中文对话模型为例from transformers import AutoTokenizer, AutoModelForCausalLM model_name Qwen/Qwen2.5-1.5B-Instruct # 开源可用的中文对话模型也可换成你的本地路径 tokenizer AutoTokenizer.from_pretrained(model_name, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( model_name, trust_remote_codeTrue, torch_dtypeauto, ) prompt 请用一句话解释什么是检索增强生成。 messages [{role: user, content: prompt}] text tokenizer.apply_chat_template(messages, tokenizeFalse, add_generation_promptTrue) inputs tokenizer(text, return_tensorspt) gen model.generate( **inputs, max_new_tokens128, do_sampleTrue, temperature0.7, top_p0.9, ) response tokenizer.decode(gen[0][inputs[input_ids].shape[1]:], skip_special_tokensTrue) print(response)这里有几个关键点。第一apply_chat_template会把用户输入包装成带助手前缀的完整消息你必须用模型配套的模板不能自己随便拼。第二max_new_tokens控制生成的回复长度不是控制输入长度。第三do_sampleTrue配合temperature和top_p控制随机性如果做实体抽取这类确定性任务建议关闭采样直接贪心解码结果更稳。很多人第一次跑生成类任务会被“回答得太啰嗦”或“自问自答”吓到。这通常是模板没用对或者 temperature 太高。把 temperature 降到 0.5 左右关闭include_special_tokens这类多余输出效果会立刻干净许多。4. 微调不一定要全量LoRA 参数高效微调的完整思路4.1 全量微调的显存账为什么很多人望而却步拿到预训练模型之后最直觉的做法是整个模型拿去自己的数据上接着训练这叫全量微调。听起来简单账却不一定算得过来。7B 参数的模型用 FP16 存储光参数就要 14GB。训练时还要保存梯度又要 14GB。优化器如果用 Adam还要存一阶和二阶动量这两项合起来又是 28GB 左右。还没算你的训练数据、中间激活值一张 24GB 显存的卡早就爆了。很多人第一次尝试微调大模型错误信息只有一个CUDA out of memory。所以 2024 年工业界的主流方案是参数高效微调其中 LoRA 是最普及的一种。它的核心思路是原模型参数全部冻结不动另外训练一小组新增参数让这组参数学会“该往哪个方向微调”。4.2 LoRA 在做什么冻结主干训练旁路低秩矩阵LoRA 的理论基础是低秩分解。研究者发现大模型微调前后权重的变化量 ΔW 通常是低秩的也就是说这个变化可以用一个很小的矩阵组合近似。假设原来的权重矩阵是 W微调后等价于 W W ΔW。LoRA 把 ΔW 拆成两个小矩阵 A 和 B 的乘积A 的维度是(输入维度, r)B 的维度是(r, 输出维度)其中秩 r 一般取 4、8、16。训练时W 不动只训练 A 和 B。这样可训练参数量从几十亿变成几百万。你可以把 LoRA 想象成给一个庞大的组织请顾问团队正式员工工资不变顾问团队只占很小预算但他们的建议能让整个组织的输出风格明显改变。from peft import LoraConfig, get_peft_model from transformers import AutoModelForSequenceClassification base_model AutoModelForSequenceClassification.from_pretrained( model_name, num_labels2, load_in_4bitTrue, # 进一步压缩显存 ) lora_config LoraConfig( r8, # 低秩矩阵的秩越大可学习容量越大但显存也更多 lora_alpha16, # 缩放因子控制 LoRA 参数对原模型的影响强度 target_modules[query, value], # 只对 attention 层的这两个模块加旁路 lora_dropout0.05, biasnone, task_typeSEQ_CLS, ) model get_peft_model(base_model, lora_config) model.print_trainable_parameters() # 可训练参数通常只占 1% 甚至更少为什么target_modules选择 query 和 value实践中最常见的是把注意力层的 Q、V 矩阵都加上 LoRA因为注意力层的权重变化对任务影响最直接。有些做法也会加 K、O 和 FFN 层效果会有提升但显存和训练时间也随之上升。小数据集上不用一上来就全加先 Q、V 就够了。4.3 一段能跑的 LoRA 微调脚本与关键参数微调脚本我用 transformers 的 Trainer 来写它可以省掉自己写训练循环的很多边界处理。数据集用 datasets 库加载保证格式统一。from datasets import Dataset from transformers import ( Trainer, TrainingArguments, DataCollatorWithPadding, ) # 假设 train_data 是包含 text 和 label 的列表 train_ds Dataset.from_list([ {text: 这个商品的体验超出预期, label: 1}, {text: 物流太慢等了一周, label: 0}, ]) def tokenize_func(batch): return tokenizer(batch[text], truncationTrue, max_length128) train_ds train_ds.map(tokenize_func, batchedTrue) training_args TrainingArguments( output_dir./lora_cls, per_device_train_batch_size16, gradient_accumulation_steps2, learning_rate2e-4, num_train_epochs3, fp16True, save_strategyepoch, logging_steps50, remove_unused_columnsFalse, ) trainer Trainer( modelmodel, argstraining_args, train_datasettrain_ds, tokenizertokenizer, data_collatorDataCollatorWithPadding(tokenizer), ) trainer.train()几个参数值得说明。learning_rate在 LoRA 里通常比全量微调大一个量级我用 1e-4 到 5e-4 之间的值居多。全量微调切忌直接用这么大的学习率否则很容易把预训练知识冲掉。gradient_accumulation_steps的作用是把多个小 batch 的梯度累加后再更新相当于变相增大了 batch size。显存不够时优先把 per_device_train_batch_size 调小再用累积步数补回来。DataCollatorWithPadding会自动把同一个 batch 里的样本 pad 到等长避免手动处理不等长输入。这个细节看着小但能省掉很多报错时间。4.4 微调完之后的合并、保存与常见心态LoRA 训练完保存的是适配器参数通常是一个几 MB 到几十 MB 的目录而不是完整的模型。使用时有两条路一是原模型加适配器一起加载推理时先用PeftModel.from_pretrained(base_model, ./lora_cls)加载二是把 LoRA 权重合并回原模型得到完整的微调后权重。merged_model model.merge_and_unload() merged_model.save_pretrained(./lora_cls_merged) tokenizer.save_pretrained(./lora_cls_merged)合并的好处是部署时只需加载一份模型文件推理速度更快。缺点是合并后的文件还是全量大小存储成本高。我的经验是实验阶段保留 LoRA 适配器文件上线阶段再合并导出。还有一个很多人提过但我必须重复的心态问题微调不是万能药。如果你的数据量只有几十条LoRA 也不会给你变出魔法。数据质量永远是第一位。先整理清晰、标签一致的数据再谈训练参数。小样本情况下宁可先跑几次全量推理人工检查 prompt 是否能解决问题也不要盲目开训练。5. 给模型装一个外接知识库RAG 检索增强生成的工程拆解5.1 RAG 解决的是幻觉和知识过期不是包装概念如果你微调过一个 7B 模型会发现一个很现实的问题它可以写出通顺的回复但一本正经地编造不存在的“内部政策”或“产品参数”。原因很简单模型参数里的知识是训练时定死的训练数据截止之后的新知识它不可能凭空知道。同时细粒度的私有知识本来就不可能靠微调全部灌进参数。检索增强生成RAGRetrieval-Augmented Generation的思路是改变信息来源不强迫模型把答案背在参数里而是在回答问题时先从外部知识库检索相关资料再把资料拼进 prompt让模型基于资料回答。这相当于考试时允许翻书比考前把所有内容背下来可靠得多。RAG 最适合的项目形态是企业知识库问答、私有文档助手、客服助手等。它不需要重新训练模型知识更新只需更新文档库成本远低于微调。5.2 搭一条最小可用的 RAG 管线RAG 管线看起来环节多但拆开就是五步加载文档、切块、向量化、检索、注入生成。给你一个最简单但能跑通全流程的版本。先做文档切块。切块是 RAG 里最影响效果的一步。我在生产项目里常用的参数是 chunk_size 取 300 到 500 字符chunk_overlap 取 50 到 80 字符。这个数值不是经验玄学太小的块召回时容易断章取义一个完整政策被切成七零八落模型根本看不出前因后果太大的块噪声多检索分数容易被无关内容稀释。from sentence_transformers import SentenceTransformer # 中文场景建议使用支持中文的embedding模型这里用通用示例 embedder SentenceTransformer(paraphrase-multilingual-MiniLM-L12-v2) # 假设 docs 是已经切好的文本块列表 doc_chunks [ 退换货政策签收后七日内可申请无理由退换货……, 物流说明工作日下午四点前下单当天发货……, 售后联系客服工作时间 9:00-18:00……, ] doc_vecs embedder.encode(doc_chunks) query 我买的商品不喜欢能退吗 query_vec embedder.encode([query]) # 计算余弦相似度取 top-3 scores cosine_similarity(query_vec, doc_vecs)[0] top_idx scores.argsort()[-3:][::-1] print([doc_chunks[i] for i in top_idx])这一步没有向量数据库也能跑数据量小时候直接算相似度完全够用。数据量到了百万级再引入向量检索服务也不迟。拿到检索结果后拼 prompt 的方式很关键。我的习惯是请仅根据以下资料回答问题不要使用资料之外的知识。 资料1…… 资料2…… 问题……首句“仅根据资料回答”能显著减少模型自由发挥的概率。注入的顺序也要注意最相关的资料放在最前面因为模型对 prompt 开头和结尾的内容记忆更牢顺序颠倒可能导致关键信息被长资料淹没。5.3 切块、召回、注入顺序三个最容易翻车的环节用 RAG 的人十有八九会遇到这几个问题我挨个说。召回质量差是这个方案最大的痛点。很多人跑通 demo 后发现答案驴唇不对马嘴第一反应是换更强的生成模型其实问题往往出在 embedding 模型和切块策略上。优先排查点查一下召回的 top-3 里到底有没有正确答案。如果答案根本不在召回的文本块里那再强的 LLM 也答不对。此时你要做的是调整切块大小或者换更适合领域的中文 embedding 模型而不是去调生成参数。相似度阈值不要拍脑袋。有人喜欢设“余弦相似度大于 0.7 才算命中”但不同 embedding 模型的分数分布差异极大。有的模型相似度普遍在 0.6 到 0.8 之间有的模型集中在 0.2 到 0.4。正确做法是拿一批标注了正确答案的样本统计分析“正确命中的最低分”和“错误命中的最高分”再决定阈值。上下文注入长度也要克制。很多人把检索到的所有相关片段全部塞进 prompt认为越多越好。模型上下文窗口是有限的塞了 5000 字资料后真正有用的细节可能被淹没还拖慢推理速度。我一版建议限定只注入 3 到 5 个强相关片段总共不超过 1500 字。如果业务确实需要长上下文优先考虑分段回答。6. 别靠感觉调模型NLP 项目的评估体系搭建方法6.1 传统的分类指标别只用准确率NLP 项目的惨痛教训之一是完全用准确率衡量模型。假设你的数据里 95% 是负样本模型只要全部预测为负准确率就有 95%但它对你的业务毫无价值。必须看精确率、召回率和 F1。精确率关心“模型说是正类的里面有多少真的为正”召回率关心“真正的正类里模型找回了多少”。这两个指标常常互斥F1 是它们的调和平均。对客服工单分类这类业务漏掉一个紧急工单的代价很高就要偏重召回对垃圾评论过滤误伤正常用户代价更高就偏重精确率。分类评估还需要看混淆矩阵。它能告诉你哪些类容易被混在一起这往往是数据标注不清或类别定义重叠的信号。如果“售后与退换货”两个类别频繁互相误判回到标注规范去改数据比继续调参有用得多。6.2 BLEU 和 ROUGE 的局限生成任务要小心到了生成任务评估一下子变得困难。很多人沿用机器翻译时代的方法用 BLEU、ROUGE 这些基于 n-gram 重叠的指标。它们能一定程度上衡量生成文本和标准答案的字面相似度但局限非常大。“这部手机电池很经用”和“这部手机续航表现相当好”意思几乎一样但字面 n-gram 重合度很低BLEU 会给一个很差的分数。反过来一段词汇完全一样但语序错乱的内容字面重合度可能很高实际完全不可读。所以我在生成类项目里只把 BLEU、ROUGE 当作快速看趋势的粗筛工具绝不把它当最终质量标准。6.3 LLM-as-Judge让大模型当评分员但别完全放手2024 年业界更多采用“用一个大模型给另一个大模型的输出打分”的做法简称 LLM-as-Judge。方法不复杂把待评文本、参考标准、评分维度都放进 prompt让评分模型输出 1 到 5 分或分维度打分。要让打分可靠核心是写清楚评分规则。比如请从相关性、完整性、忠实度三个维度打分每项 1-5 分。 相关性回答是否紧扣问题。 完整性是否覆盖问题要求的全部要点。 忠实度是否基于给定资料有无编造。 不要因为回答长度长就给高分。其中“不要因为长度长就给高分”这类纠偏提示非常关键。最早我用 LLM 打分时发现模型偏爱又长又绕的答案加了这个约束后分数才有区分度。另一个稳定技巧是让评分模型多次采样取平均或者用两个不同模型互相校验减少单个模型打分偏好带来的偏差。6.4 攒一个黄金回归集比写一百行 prompt 更值评估体系的真正核心不是指标有多复杂而是你有没有一个固定不变、覆盖面广的回归测试集。我习惯叫它 golden set里面放三类样本业务侧最常见的典型问题、之前线上翻过车的 bad case、以及边界条件样本。规模不用大50 到 200 条常常就够用。每次改动 prompt、微调数据或模型版本都在这个集上跑一遍记录分数变化。如果总分提升但某个重要 bad case 变差了就要谨慎上线。我自己固定每周更新一次 golden set凡是线上新发现的问题案例盘点后立刻补充进去。这个习惯会让项目越到后期越稳因为回归集积累的是真实世界里的坑而不是拍脑袋想出来的完美问题。7. 上线才是真正的开始显存估算、推理优化与降级方案7.1 先算账显存和成本的大致估算很多人开发时用一张消费级显卡跑通模型就以为部署很容易真到上线才发现显存不够、响应延迟超标。部署前花十分钟算一笔账能避免后面手忙脚乱。推理显存的粗略公式是模型显存约等于参数量乘以每个参数占用的字节数。FP32 是 4 字节FP16 是 2 字节INT8 是 1 字节INT4 约 0.5 字节。比如一个 7B 模型用 FP16 推理参数至少占 14GB再加上 KV cache 和运行时开销实际单卡 24GB 才比较从容。换成 INT4 量化后7B 模型只要约 4GB 参数空间很多消费级显卡也能跑。但量化不是免费的。INT4 量化可能让模型在复杂推理任务上出现明显质量下降。我的建议是逐步尝试先在 FP16 上跑通功能再试 INT8如果评估集指标没有明显下滑再考虑 INT4。上线前必须用黄金回归集重新测一遍不能只看显存数字。7.2 推理优化的三条路线量化、连续批处理、工程缓存显存只是第一关延迟和吞吐才是线上最头疼的问题。按投入产出比排序我会先说工程缓存。工程缓存指的是把重复的查询结果存起来。很多人第一反应是用精确哈希做缓存但实际用户问题表述千变万化完全相同的文本比例很低。更有效的方式是把用户 query 做 embedding向量相似度高于阈值时直接返回缓存答案。对客服助手这类场景Top 20 热点问题的缓存命中率可能达到 30% 以上响应时间直接从秒级降到毫秒级。第二路线是量化加速。除了降低显存量化还能减少显存带宽压力这在 GPU 推理里经常比算力更关键。配合批量推理吞吐量提升显著。如果你的场景是智能客服这种高并发短文本量化加批量几乎是标准配置。第三路线是实现连续批处理。传统批处理是攒一批请求再一起推理缺点是高矮个互相拖累最短的请求也要等最长的跑完。连续批处理把不同请求的生成过程交错执行先结束的先返回从而显著提高 GPU 利用率。开源的推理框架很多已经内置了这个能力你只需要把模型导出成对应格式不必自己实现复杂调度。7.3 降级与兜底模型挂了不能只剩报错生产环境里最容易被忽略的是降级方案。大模型推理服务偶尔会因为长尾输入、显存异常或后端波动而超时如果没有兜底用户看到的就是一个转圈后报错的页面体验非常差。我的建议是至少准备两层降级。第一层模型服务超时后返回预设的热门 FAQ 或简短提示而不是直接报 500。第二层如果超时率达到阈值自动把流量切换到 lite 模型或规则匹配保证核心功能不中断。还有一个小细节生成模型的超时时间要单独设置。分类模型 200 毫秒能返回生成模型回答几百 token 可能耗时好几秒。如果复用同样的超时配置很容易误杀正常请求。我通常按“预估生成长度乘以单 token 预计耗时再留 50% 余量”来配置超时时间同时给前端流式输出方案提升用户等待体验。最后一件事上线后必须持续监控。不用只看模型指标更要看业务指标比如用户问题解决率、转人工率、投诉率。模型指标再漂亮用户不买账也是白搭。把 golden set、线上日志、人工反馈串成一个循环每周复盘一次NLP 项目才能从一个“能跑的模型”变成一个“可靠的系统”。