简介这份PDF资料面向AI工程师、机器学习工程师、数据科学家及企业技术管理者系统梳理企业级生成式人工智能与大模型的技术原理、算法内核与落地案例帮助读者建立从GenAI本质到生产环境部署的完整认知。内容涵盖工业级Prompting技术、Llama 2/3模型解密、Agentic应用开发、模型微调与Quantization、PEFT高效微调、RLHF与DPO/PPO对齐算法、Red Teaming安全评估及Responsible AI等模块并配有语音聊天机器人、会议助理、自动编程工具等综合项目实战。资源包为1个PDF文件约965KB便于在电脑或移动端随时查阅适合作为技术进阶与项目参考手册。目前已有323人学习读者可从中获取大模型全生命周期流程、微调与对齐算法实现思路、生产环境常见问题解决方案及企业私有安全模型构建方法对希望深入LLM工程实践的技术人员具有较高参考价值。1. 从一份企业级 LLM 实战资料说起它到底能解决什么问题很多团队在 2024 年之后都遇到过同一个尴尬老板说要上大模型业务方说要接生成式人工智能可真正落到代码层面大家手里只有一堆 API 文档和几篇论文没人能说清从数据到上线中间到底要补哪些环节。这份《企业级生成式人工智能LLM大模型技术、算法及案例实战》之所以被反复检索本质上是因为它试图把「LLM 是什么」和「企业里怎么用」这两件事缝在一起。它面向的不是想调个 prompt 玩玩的个人开发者而是需要把大模型微调、部署、评测串成一条可交付流水线的工程团队。如果你正卡在「模型能跑但业务不认」的阶段这份资料里的算法选型和案例拆解思路比单纯追 open llm leaderboard 榜单更有参考价值。2. 企业级 LLM 技术栈的分层从 token 到 agent 的完整链路2.1 为什么先要理解 token 的三元组语义任何企业级 LLM 应用第一道门槛不是模型多大而是能不能把业务数据翻译成模型能吃的 token 序列。热词里那句「llm的token三个点key我是谁、query我在找什么、value我能提供什么」其实点破了注意力机制的本质每个 token 在生成时都在做一次软性检索。企业场景里这意味着你不能只把文档切片丢进去还要保证切片后的每个 chunk 在语义上能回答一个明确的 query。我一般会先用一个最小脚本把业务语料跑一遍 token 统计看看平均长度、特殊符号占比和截断率。这一步不做后面微调时 loss 曲线会莫名其妙地抖。from transformers import AutoTokenizer # 选一个和后续基座模型一致的分词器别用错版本 tokenizer AutoTokenizer.from_pretrained(your-base-model-path) def token_stats(texts, max_len512): lengths [] truncated 0 for t in texts: ids tokenizer.encode(t, add_special_tokensTrue) lengths.append(len(ids)) if len(ids) max_len: truncated 1 avg sum(lengths) / len(lengths) print(f平均 token 长度: {avg:.1f}, 截断比例: {truncated/len(texts):.2%}) return avg # texts 换成你自己的业务语料列表 token_stats([企业级大模型需要关注数据质量, 微调不是万能药])这段代码的逻辑很直白用和训练时一致的分词器统计真实分布。参数上max_len要和你计划设置的max_seq_length对齐如果截断比例超过 15%说明要么切片策略有问题要么该换更长上下文的基座。很多团队翻车就翻在训练和推理用了不同分词器导致 token 对不上输出全是乱码。2.2 微调、RAG 与 Agent 的选型边界企业里最常见的争论是到底该微调还是做 RAG。我的经验是看三个维度——知识更新频率、推理成本容忍度、任务复杂度。如果业务知识每周都在变RAG 是唯一选择因为微调一次的成本和周期你扛不住。如果任务是固定的格式转换或分类微调小模型比调 API 更稳。Agent 则适合多步工具调用的场景但前提是你的 LLM 本身指令遵循能力够强。方案适合场景数据需求典型坑全量微调领域术语密集、任务固定1万条以上高质量样本灾难性遗忘LoRA快速验证、显存有限几百到几千条rank 设太大过拟合RAG知识频繁更新文档向量库切片粒度不当Agent多工具编排工具描述少量示例死循环调用选型时别迷信「大模型微调实战」里那些一步到位的说法。我见过太多团队直接上全量微调结果基座模型的通用能力被洗掉连基本的 JSON 输出都保不住。稳妥做法是先 LoRA 跑通链路再决定要不要放开。2.3 一个可复现的 LoRA 微调最小流程下面这个流程是我在多个企业项目里验证过的基座换成你手头的开源模型即可。关键是数据格式和 target_modules 的选择。from peft import LoraConfig, get_peft_model, TaskType from transformers import AutoModelForCausalLM, TrainingArguments, Trainer # 加载基座注意 dtype 和 device_map 按实际显存调整 model AutoModelForCausalLM.from_pretrained( your-base-model-path, torch_dtypeauto, device_mapauto ) # LoRA 配置rank 和 alpha 是核心参数 lora_config LoraConfig( task_typeTaskType.CAUSAL_LM, r8, # rank一般 4-16太大容易过拟合 lora_alpha32, # 缩放系数通常是 r 的 2-4 倍 lora_dropout0.1, # 防过拟合 target_modules[q_proj, v_proj], # 注意力层的 q/v 是常见选择 biasnone ) model get_peft_model(model, lora_config) model.print_trainable_parameters() # 确认可训练参数占比通常 1% training_args TrainingArguments( output_dir./lora-out, per_device_train_batch_size4, gradient_accumulation_steps4, learning_rate2e-4, # LoRA 常用 1e-4 到 3e-4 num_train_epochs3, logging_steps10, save_strategyepoch, fp16True # 有 bf16 优先用 bf16 ) trainer Trainer(modelmodel, argstraining_args, train_datasetyour_dataset) trainer.train()逻辑说明LoRA 只更新低秩矩阵所以学习率可以比全量微调大一个量级。target_modules选 q_proj 和 v_proj 是性价比最高的做法如果效果不够再考虑加上 k_proj 和 o_proj。r8对大多数企业任务够用除非你的领域和基座差异极大。训练完记得把 LoRA 权重合并回基座再部署否则推理时还要挂载适配器延迟会上去。3. 案例实战的拆解方法从业务问题到可评测的 LLM 任务3.1 把模糊需求翻译成模型可执行的任务定义企业里业务方提的需求往往是「帮我做个智能客服」或者「自动生成报告」。这种话直接丢给 LLM 团队结果一定是反复返工。我习惯先做一步任务翻译把需求拆成输入、输出、约束和评测标准四要素。比如「自动生成报告」可以翻译成输入是结构化的数据库查询结果输出是固定小标题的 Markdown约束是数字必须来自输入不能编造评测标准是人工抽检 50 条看事实一致性。这一步做完你才能决定用 few-shot、微调还是 Agent。热词里的「llm as judge」在这里就派上用场了——用另一个 LLM 做自动评测但前提是你的评测 prompt 本身要经过人工校准否则就是垃圾进垃圾出。3.2 用 LLM as judge 搭建自动评测流水线自动评测不是让模型打个分就完事关键是要有可追溯的评分维度和校准集。下面这个结构我一般会保留方便后续排查。import json # 评测 prompt 模板维度要具体别用好不好这种模糊词 JUDGE_PROMPT 你是一个严格的评测员。请根据以下维度给回答打分1-5分 1. 事实一致性回答中的事实是否与参考材料一致 2. 完整性是否覆盖了问题的所有要点 3. 格式合规是否符合要求的输出格式 参考材料{context} 问题{question} 模型回答{answer} 请以 JSON 输出{{fact: 分数, complete: 分数, format: 分数, reason: 简短理由}} def judge_one(context, question, answer, judge_llm): prompt JUDGE_PROMPT.format(contextcontext, questionquestion, answeranswer) resp judge_llm.generate(prompt) try: return json.loads(resp) except json.JSONDecodeError: return {fact: 0, complete: 0, format: 0, reason: 解析失败} # 批量跑完后人工抽检 10% 校准 judge 的偏差参数说明judge_llm最好用比被评测模型更强的模型否则评分会失真。JSON 解析失败率如果超过 5%说明 judge 的指令遵循有问题要么换模型要么加 few-shot 示例。校准环节不能省我见过 judge 把编造事实的回答打满分的案例原因就是评测 prompt 里没强调「参考材料之外的信息一律视为不一致」。3.3 从单点案例到可复用模板的抽象企业里做完一个案例如果不抽象成模板下一个项目又要从头来。我的做法是把每个案例拆成「数据构造脚本 训练配置 评测脚本」三件套放到内部仓库里。下次遇到类似任务改数据构造和评测维度就行。热词里的「深度学习实战项目案例」之所以受欢迎就是因为大家想要的是可迁移的骨架而不是某个具体任务的代码。抽象时注意保留参数化的部分数据路径、模型路径、超参、评测阈值都做成配置文件。这样不同团队复用时不用改代码只改配置。4. 避坑与排查企业级 LLM 落地最常见的 5 个翻车现场4.1 现象微调后模型输出重复或截断原因学习率过大或者训练轮次过多导致模型过拟合到训练数据的固定模式。另一个常见原因是 padding 侧设置错误导致生成时位置编码混乱。解决先把学习率降到 1e-4 以下重跑观察 loss 曲线是否在验证集上回升。检查 tokenizer 的 padding_side生成任务一般设为 left。如果还不行减少 epoch 到 1-2 轮LoRA 本身收敛很快不需要太多轮次。4.2 现象RAG 检索到的文档和问题不相关原因切片粒度太粗一个 chunk 里混了多个主题或者 embedding 模型和业务语料领域不匹配。解决把 chunk size 从 512 降到 256 试试同时加 10%-20% 的 overlap。embedding 模型如果通用效果差可以用业务数据做对比学习微调但样本量至少要几千对。另外检查向量库的相似度阈值太低会引入噪声。4.3 现象Agent 调用工具时陷入死循环原因工具返回的错误信息没有被模型正确理解或者工具描述太模糊导致模型反复尝试同一个调用。解决在工具描述里明确写清输入输出格式和失败时的返回结构。加一个最大调用步数限制超过就强制终止并返回兜底话术。我一般会设 5-8 步超过这个数基本说明任务定义有问题。4.4 现象评测分数很高但业务方不买账原因评测集和真实分布不一致或者评测维度没有覆盖业务真正关心的点。解决从线上真实请求里采样构建评测集别用公开数据集凑数。评测维度拉上业务方一起定让他们参与标注 50-100 条校准样本。这一步做完评测分数才有说服力。4.5 现象推理延迟忽高忽低原因batch size 不稳定、KV cache 没开、或者多个请求共享模型实例时显存竞争。解决固定推理时的 batch size开启 KV cache用连续批处理框架。如果显存紧张考虑量化到 int8 或 int4但要在评测集上确认精度损失可接受。延迟问题不解决再好的效果业务方也不会用。5. 进阶技巧用剪枝和量化把企业级 LLM 塞进有限显存5.1 剪枝不是万能药先看任务敏感度剪枝算法在 LLM 上的效果因任务而异。分类任务对剪枝容忍度高生成任务则很容易因为剪掉关键注意力头而崩掉。我的做法是先做结构化剪枝的敏感度分析逐层剪掉 10% 的注意力头看评测分数掉多少。掉得少的层可以多剪掉得多的层保留。import torch def prune_heads_sensitivity(model, eval_fn, prune_ratio0.1): 逐层剪枝并评估返回每层的敏感度 results {} for layer_idx, layer in enumerate(model.model.layers): # 备份原始权重 original layer.self_attn.q_proj.weight.clone() # 简单示例按权重范数剪掉最小的头 # 实际实现需要按头维度 reshape 后排序 with torch.no_grad(): layer.self_attn.q_proj.weight * (torch.rand_like(original) prune_ratio) score eval_fn(model) results[layer_idx] score # 恢复 layer.self_attn.q_proj.weight.copy_(original) return results # 敏感度低的层优先剪高的层保留这段代码是示意性的真实剪枝要按注意力头的维度操作并且要同时处理 q/k/v/o 四个投影。参数prune_ratio从 0.1 开始试别一上来就 0.5。剪完必须重新评测不能只看 loss。5.2 量化部署的精度与速度权衡量化到 int8 通常精度损失很小int4 就要看任务了。我一般先用 GPTQ 或 AWQ 做权重量化然后在评测集上对比。如果 int4 的分数掉超过 3%就退回 int8。部署时注意 KV cache 的量化这部分对显存影响很大但量化不当会导致长文本生成质量下降。量化方式显存节省精度损失适用场景int8约 50%很小大多数企业任务int4 (GPTQ)约 75%中等显存极度受限int4 (AWQ)约 75%较小生成任务优先5.3 一个我踩过的坑量化后评测集要重建有次我把模型量化到 int4 后直接用原来的评测集跑分数只掉了 1%以为万事大吉。上线后业务方反馈长文本生成质量明显下降。后来发现原评测集都是短文本量化对长序列的影响被掩盖了。重建评测集加入长文本样本后分数掉了 8%。这个教训让我养成了一个习惯任何压缩操作后评测集必须覆盖线上真实长度分布。希望帮到你。本文还有配套的精品资源点击获取 企业级LLM大模型实战：微调、RAG与Agent选型及避坑指南
简介这份PDF资料面向AI工程师、机器学习工程师、数据科学家及企业技术管理者系统梳理企业级生成式人工智能与大模型的技术原理、算法内核与落地案例帮助读者建立从GenAI本质到生产环境部署的完整认知。内容涵盖工业级Prompting技术、Llama 2/3模型解密、Agentic应用开发、模型微调与Quantization、PEFT高效微调、RLHF与DPO/PPO对齐算法、Red Teaming安全评估及Responsible AI等模块并配有语音聊天机器人、会议助理、自动编程工具等综合项目实战。资源包为1个PDF文件约965KB便于在电脑或移动端随时查阅适合作为技术进阶与项目参考手册。目前已有323人学习读者可从中获取大模型全生命周期流程、微调与对齐算法实现思路、生产环境常见问题解决方案及企业私有安全模型构建方法对希望深入LLM工程实践的技术人员具有较高参考价值。1. 从一份企业级 LLM 实战资料说起它到底能解决什么问题很多团队在 2024 年之后都遇到过同一个尴尬老板说要上大模型业务方说要接生成式人工智能可真正落到代码层面大家手里只有一堆 API 文档和几篇论文没人能说清从数据到上线中间到底要补哪些环节。这份《企业级生成式人工智能LLM大模型技术、算法及案例实战》之所以被反复检索本质上是因为它试图把「LLM 是什么」和「企业里怎么用」这两件事缝在一起。它面向的不是想调个 prompt 玩玩的个人开发者而是需要把大模型微调、部署、评测串成一条可交付流水线的工程团队。如果你正卡在「模型能跑但业务不认」的阶段这份资料里的算法选型和案例拆解思路比单纯追 open llm leaderboard 榜单更有参考价值。2. 企业级 LLM 技术栈的分层从 token 到 agent 的完整链路2.1 为什么先要理解 token 的三元组语义任何企业级 LLM 应用第一道门槛不是模型多大而是能不能把业务数据翻译成模型能吃的 token 序列。热词里那句「llm的token三个点key我是谁、query我在找什么、value我能提供什么」其实点破了注意力机制的本质每个 token 在生成时都在做一次软性检索。企业场景里这意味着你不能只把文档切片丢进去还要保证切片后的每个 chunk 在语义上能回答一个明确的 query。我一般会先用一个最小脚本把业务语料跑一遍 token 统计看看平均长度、特殊符号占比和截断率。这一步不做后面微调时 loss 曲线会莫名其妙地抖。from transformers import AutoTokenizer # 选一个和后续基座模型一致的分词器别用错版本 tokenizer AutoTokenizer.from_pretrained(your-base-model-path) def token_stats(texts, max_len512): lengths [] truncated 0 for t in texts: ids tokenizer.encode(t, add_special_tokensTrue) lengths.append(len(ids)) if len(ids) max_len: truncated 1 avg sum(lengths) / len(lengths) print(f平均 token 长度: {avg:.1f}, 截断比例: {truncated/len(texts):.2%}) return avg # texts 换成你自己的业务语料列表 token_stats([企业级大模型需要关注数据质量, 微调不是万能药])这段代码的逻辑很直白用和训练时一致的分词器统计真实分布。参数上max_len要和你计划设置的max_seq_length对齐如果截断比例超过 15%说明要么切片策略有问题要么该换更长上下文的基座。很多团队翻车就翻在训练和推理用了不同分词器导致 token 对不上输出全是乱码。2.2 微调、RAG 与 Agent 的选型边界企业里最常见的争论是到底该微调还是做 RAG。我的经验是看三个维度——知识更新频率、推理成本容忍度、任务复杂度。如果业务知识每周都在变RAG 是唯一选择因为微调一次的成本和周期你扛不住。如果任务是固定的格式转换或分类微调小模型比调 API 更稳。Agent 则适合多步工具调用的场景但前提是你的 LLM 本身指令遵循能力够强。方案适合场景数据需求典型坑全量微调领域术语密集、任务固定1万条以上高质量样本灾难性遗忘LoRA快速验证、显存有限几百到几千条rank 设太大过拟合RAG知识频繁更新文档向量库切片粒度不当Agent多工具编排工具描述少量示例死循环调用选型时别迷信「大模型微调实战」里那些一步到位的说法。我见过太多团队直接上全量微调结果基座模型的通用能力被洗掉连基本的 JSON 输出都保不住。稳妥做法是先 LoRA 跑通链路再决定要不要放开。2.3 一个可复现的 LoRA 微调最小流程下面这个流程是我在多个企业项目里验证过的基座换成你手头的开源模型即可。关键是数据格式和 target_modules 的选择。from peft import LoraConfig, get_peft_model, TaskType from transformers import AutoModelForCausalLM, TrainingArguments, Trainer # 加载基座注意 dtype 和 device_map 按实际显存调整 model AutoModelForCausalLM.from_pretrained( your-base-model-path, torch_dtypeauto, device_mapauto ) # LoRA 配置rank 和 alpha 是核心参数 lora_config LoraConfig( task_typeTaskType.CAUSAL_LM, r8, # rank一般 4-16太大容易过拟合 lora_alpha32, # 缩放系数通常是 r 的 2-4 倍 lora_dropout0.1, # 防过拟合 target_modules[q_proj, v_proj], # 注意力层的 q/v 是常见选择 biasnone ) model get_peft_model(model, lora_config) model.print_trainable_parameters() # 确认可训练参数占比通常 1% training_args TrainingArguments( output_dir./lora-out, per_device_train_batch_size4, gradient_accumulation_steps4, learning_rate2e-4, # LoRA 常用 1e-4 到 3e-4 num_train_epochs3, logging_steps10, save_strategyepoch, fp16True # 有 bf16 优先用 bf16 ) trainer Trainer(modelmodel, argstraining_args, train_datasetyour_dataset) trainer.train()逻辑说明LoRA 只更新低秩矩阵所以学习率可以比全量微调大一个量级。target_modules选 q_proj 和 v_proj 是性价比最高的做法如果效果不够再考虑加上 k_proj 和 o_proj。r8对大多数企业任务够用除非你的领域和基座差异极大。训练完记得把 LoRA 权重合并回基座再部署否则推理时还要挂载适配器延迟会上去。3. 案例实战的拆解方法从业务问题到可评测的 LLM 任务3.1 把模糊需求翻译成模型可执行的任务定义企业里业务方提的需求往往是「帮我做个智能客服」或者「自动生成报告」。这种话直接丢给 LLM 团队结果一定是反复返工。我习惯先做一步任务翻译把需求拆成输入、输出、约束和评测标准四要素。比如「自动生成报告」可以翻译成输入是结构化的数据库查询结果输出是固定小标题的 Markdown约束是数字必须来自输入不能编造评测标准是人工抽检 50 条看事实一致性。这一步做完你才能决定用 few-shot、微调还是 Agent。热词里的「llm as judge」在这里就派上用场了——用另一个 LLM 做自动评测但前提是你的评测 prompt 本身要经过人工校准否则就是垃圾进垃圾出。3.2 用 LLM as judge 搭建自动评测流水线自动评测不是让模型打个分就完事关键是要有可追溯的评分维度和校准集。下面这个结构我一般会保留方便后续排查。import json # 评测 prompt 模板维度要具体别用好不好这种模糊词 JUDGE_PROMPT 你是一个严格的评测员。请根据以下维度给回答打分1-5分 1. 事实一致性回答中的事实是否与参考材料一致 2. 完整性是否覆盖了问题的所有要点 3. 格式合规是否符合要求的输出格式 参考材料{context} 问题{question} 模型回答{answer} 请以 JSON 输出{{fact: 分数, complete: 分数, format: 分数, reason: 简短理由}} def judge_one(context, question, answer, judge_llm): prompt JUDGE_PROMPT.format(contextcontext, questionquestion, answeranswer) resp judge_llm.generate(prompt) try: return json.loads(resp) except json.JSONDecodeError: return {fact: 0, complete: 0, format: 0, reason: 解析失败} # 批量跑完后人工抽检 10% 校准 judge 的偏差参数说明judge_llm最好用比被评测模型更强的模型否则评分会失真。JSON 解析失败率如果超过 5%说明 judge 的指令遵循有问题要么换模型要么加 few-shot 示例。校准环节不能省我见过 judge 把编造事实的回答打满分的案例原因就是评测 prompt 里没强调「参考材料之外的信息一律视为不一致」。3.3 从单点案例到可复用模板的抽象企业里做完一个案例如果不抽象成模板下一个项目又要从头来。我的做法是把每个案例拆成「数据构造脚本 训练配置 评测脚本」三件套放到内部仓库里。下次遇到类似任务改数据构造和评测维度就行。热词里的「深度学习实战项目案例」之所以受欢迎就是因为大家想要的是可迁移的骨架而不是某个具体任务的代码。抽象时注意保留参数化的部分数据路径、模型路径、超参、评测阈值都做成配置文件。这样不同团队复用时不用改代码只改配置。4. 避坑与排查企业级 LLM 落地最常见的 5 个翻车现场4.1 现象微调后模型输出重复或截断原因学习率过大或者训练轮次过多导致模型过拟合到训练数据的固定模式。另一个常见原因是 padding 侧设置错误导致生成时位置编码混乱。解决先把学习率降到 1e-4 以下重跑观察 loss 曲线是否在验证集上回升。检查 tokenizer 的 padding_side生成任务一般设为 left。如果还不行减少 epoch 到 1-2 轮LoRA 本身收敛很快不需要太多轮次。4.2 现象RAG 检索到的文档和问题不相关原因切片粒度太粗一个 chunk 里混了多个主题或者 embedding 模型和业务语料领域不匹配。解决把 chunk size 从 512 降到 256 试试同时加 10%-20% 的 overlap。embedding 模型如果通用效果差可以用业务数据做对比学习微调但样本量至少要几千对。另外检查向量库的相似度阈值太低会引入噪声。4.3 现象Agent 调用工具时陷入死循环原因工具返回的错误信息没有被模型正确理解或者工具描述太模糊导致模型反复尝试同一个调用。解决在工具描述里明确写清输入输出格式和失败时的返回结构。加一个最大调用步数限制超过就强制终止并返回兜底话术。我一般会设 5-8 步超过这个数基本说明任务定义有问题。4.4 现象评测分数很高但业务方不买账原因评测集和真实分布不一致或者评测维度没有覆盖业务真正关心的点。解决从线上真实请求里采样构建评测集别用公开数据集凑数。评测维度拉上业务方一起定让他们参与标注 50-100 条校准样本。这一步做完评测分数才有说服力。4.5 现象推理延迟忽高忽低原因batch size 不稳定、KV cache 没开、或者多个请求共享模型实例时显存竞争。解决固定推理时的 batch size开启 KV cache用连续批处理框架。如果显存紧张考虑量化到 int8 或 int4但要在评测集上确认精度损失可接受。延迟问题不解决再好的效果业务方也不会用。5. 进阶技巧用剪枝和量化把企业级 LLM 塞进有限显存5.1 剪枝不是万能药先看任务敏感度剪枝算法在 LLM 上的效果因任务而异。分类任务对剪枝容忍度高生成任务则很容易因为剪掉关键注意力头而崩掉。我的做法是先做结构化剪枝的敏感度分析逐层剪掉 10% 的注意力头看评测分数掉多少。掉得少的层可以多剪掉得多的层保留。import torch def prune_heads_sensitivity(model, eval_fn, prune_ratio0.1): 逐层剪枝并评估返回每层的敏感度 results {} for layer_idx, layer in enumerate(model.model.layers): # 备份原始权重 original layer.self_attn.q_proj.weight.clone() # 简单示例按权重范数剪掉最小的头 # 实际实现需要按头维度 reshape 后排序 with torch.no_grad(): layer.self_attn.q_proj.weight * (torch.rand_like(original) prune_ratio) score eval_fn(model) results[layer_idx] score # 恢复 layer.self_attn.q_proj.weight.copy_(original) return results # 敏感度低的层优先剪高的层保留这段代码是示意性的真实剪枝要按注意力头的维度操作并且要同时处理 q/k/v/o 四个投影。参数prune_ratio从 0.1 开始试别一上来就 0.5。剪完必须重新评测不能只看 loss。5.2 量化部署的精度与速度权衡量化到 int8 通常精度损失很小int4 就要看任务了。我一般先用 GPTQ 或 AWQ 做权重量化然后在评测集上对比。如果 int4 的分数掉超过 3%就退回 int8。部署时注意 KV cache 的量化这部分对显存影响很大但量化不当会导致长文本生成质量下降。量化方式显存节省精度损失适用场景int8约 50%很小大多数企业任务int4 (GPTQ)约 75%中等显存极度受限int4 (AWQ)约 75%较小生成任务优先5.3 一个我踩过的坑量化后评测集要重建有次我把模型量化到 int4 后直接用原来的评测集跑分数只掉了 1%以为万事大吉。上线后业务方反馈长文本生成质量明显下降。后来发现原评测集都是短文本量化对长序列的影响被掩盖了。重建评测集加入长文本样本后分数掉了 8%。这个教训让我养成了一个习惯任何压缩操作后评测集必须覆盖线上真实长度分布。希望帮到你。本文还有配套的精品资源点击获取