1.1 大模型核心概念与本地部署价值
我最早听说大模型参数规模的时候，脑子里只有“大”这个字。后来自己动手跑模型，才慢慢明白参数就是模型里那些可以学习的权重数字。几十亿到几千亿个数字凑在一起，让模型学会了预测下一个词。Transformer架构是这一切的骨架，自注意力机制让每个词都能看到句子里其他词，不管隔多远。推理流程说起来也简单，把文字切成token，送进网络一层层算，最后吐出概率最高的那个token。循环下去，就生成了一整段话。
本地部署的价值，我感受最深的是数据隐私。公司内部文档、客户信息，这些东西我根本不敢往云端API送。放在自己机器上跑，数据不出内网，心里踏实。离线可用性也很实在，出差路上没网，我照样能让模型帮我改代码。还有成本，云API按token收费，用多了肉疼。本地部署一次性买张显卡，后面电费就是主要开销。我认识一个做法律咨询的朋友，他把模型装在自己工作站上，客户合同从来没离开过办公室。
1.2 本地部署硬件与系统环境准备
我刚开始折腾的时候，拿笔记本的6GB显存跑7B模型，结果直接爆了。GPU选型这件事，显存比算力更关键。消费级卡里，RTX 4090的24GB显存能跑不少量化模型，3090的24GB性价比也不错。专业卡A100、H100当然好，价格也好看。显存估算有个粗略公式：参数量乘以精度字节数，再加上KV Cache。7B模型用FP16大概14GB，INT4量化后只要4GB左右。我一般会留出20%余量，不然上下文一长就崩。
驱动、CUDA、cuDNN这三兄弟的版本匹配，我踩过好几次坑。有次装了最新驱动，结果CUDA版本对不上，PyTorch直接报错。我的经验是先去PyTorch官网看推荐组合，照着装最省心。Python环境用conda或者venv隔离，别把系统Python搞乱。我习惯用conda建个环境，名字就叫“llm”，每次折腾完就删掉重来。系统方面，Ubuntu 22.04对NVIDIA支持最好，Windows也能跑，但有些工具链会别扭。
1.3 主流开源大模型选型与下载渠道
我试过的开源模型里，Llama 3的生态最热闹，社区教程一抓一大把。Qwen 2.5在中文任务上表现很稳，我拿它写公文和邮件，基本不用怎么改。DeepSeek的代码能力和数学推理让我惊喜，有次我扔给它一段报错日志，它直接指出是CUDA版本问题。Mistral走轻量路线，7B模型在消费级显卡上跑得飞快。ChatGLM对国内用户友好，ModelScope上直接下载，不用翻墙。
下载渠道我常用Hugging Face，模型全，但有时候速度慢。ModelScope国内下载快，Qwen和ChatGLM在上面都有官方仓库。GitHub上有些项目会直接放GGUF格式的模型，llama.cpp用户可以直接拉。选模型的时候，我会先看许可证。Llama有商用限制，Qwen和DeepSeek相对宽松。我习惯把模型卡片的许可条款复制到本地笔记里，免得以后忘了。
1.4 大模型本地部署工具链
Ollama是我推荐给新手的第一个工具。一条命令拉取模型，再一条命令就能对话。它把很多底层细节藏起来了，适合快速体验。我拿Ollama给产品经理演示过，他们觉得跟用ChatGPT差不多。vLLM是生产环境的好帮手，它用了PagedAttention，吞吐量比普通Transformers高好几倍。我做过测试，同样一张4090，vLLM能同时服务十几个请求，延迟还稳定。
Transformers库是研究者的瑞士军刀，想改模型结构、加自定义层，都得靠它。llama.cpp把模型量化到极致，CPU也能跑，我有一台旧MacBook Air，用llama.cpp跑7B的Q4模型，速度虽然慢，但能用。Text Generation WebUI界面做得漂亮，支持多种后端，适合喜欢点点鼠标的人。我的工具箱里这几个都留着，看场景换着用。快速验证用Ollama，上线服务用vLLM，研究实验用Transformers，老设备用llama.cpp。
1.5 模型量化与显存优化策略
量化这件事，我一开始觉得会损失精度，不太敢用。后来发现合适的量化下，输出质量差别很小，显存却省了一大半。GGUF是llama.cpp的格式，支持CPU和GPU混合推理，我的旧笔记本就靠它跑模型。GPTQ是训练后量化，主要针对GPU，加载速度快。AWQ叫激活感知量化，它对权重里重要的通道保留更高精度，效果比普通INT4好。
INT8和INT4是最常见的精度选项。INT8把每个权重从16位浮点压到8位整数，显存减半，速度可能还快一点。INT4再压一半，但质量下降更明显。我通常用Q4_K_M这个GGUF量化级别，平衡得不错。权衡的时候，我会问自己三个问题：显存够不够，速度能不能忍，输出能不能看。如果显存紧张，就上INT4。如果追求质量，就FP16或者INT8。没有绝对答案，看菜下饭。
1.6 大模型本地部署实战
我在单机跑通模型后，第一个想法是让同事也能用。最直接的办法是用FastAPI包一层，把推理接口暴露到局域网。同事在浏览器里打开一个网页，输入问题，后端调模型返回答案。Ollama自带API，vLLM有OpenAI兼容的接口，省了不少事。局域网访问要注意防火墙，我一般只绑定内网IP，不对外网开放。
Docker容器化让部署变得可重复。我把CUDA、Python依赖、模型权重都打包进镜像，换台机器直接跑。多用户访问是个挑战，单张显卡同时处理多个请求会排队。vLLM支持连续批处理，能把多个请求拼在一起算，吞吐量提升明显。我给团队配了个简单的队列系统，超过并发限制就等待。有次开会，五个人同时问模型问题，vLLM把请求调度得挺好，没人觉得卡。
1.7 部署效果测试、性能监控与常见故障排查
测试部署效果，我主要看三个数：吞吐量、延迟、显存占用。吞吐量是每秒生成多少token，延迟是第一个token出来要多久。我用一个脚本批量发请求，记录这些指标。上下文长度对显存影响很大，从4K拉到32K，显存可能翻倍。我一般会先测出模型能支持的最大上下文，再留点余量给并发。
常见报错里，CUDA out of memory出现频率最高。我的处理办法是降低批次大小，或者换更小的量化模型。版本不匹配的报错也烦人，比如PyTorch和CUDA对不上。监控我用nvidia-smi看显存和GPU利用率，gpustat更直观。有次模型输出乱码，查了半天发现是tokenizer版本不对。我现在养成习惯，每次部署完先跑个标准测试集，确认输出正常再上线。
1.8 本地部署安全合规与数据隐私保护
本地部署不代表绝对安全，我见过有人把Ollama的端口直接暴露到公网，结果被人扫到，模型被白嫖。模型许可要仔细读，Llama允许商用但有一定条件，Qwen和DeepSeek的许可证相对宽松。我在公司内部部署时，会加一层API key认证，每个请求都要验证。访问控制还能限制哪些IP能连，哪些用户能用。
日志审计是合规的重要一环。我配置了请求日志，记录谁在什么时候问了什么，返回了什么。敏感信息隔离更关键，我从不把生产数据库的原始数据喂给模型。如果要做知识库问答，我会先脱敏。有次客户要求模型处理合同，我建议他们用本地部署，并且把合同里的公司名、金额都替换成占位符。模型许可证、访问控制、日志、脱敏，这四件事我每次部署都会过一遍。
2.1 大模型微调基础：全参数微调、LoRA、QLoRA、Adapter 与提示工程的区别和适用边界
我刚开始接触微调的时候，以为就是把模型重新训练一遍。真正上手才发现，全参数微调对显存的要求高得吓人。7B模型全参微调，用FP16精度，光优化器状态就要吃掉几十GB显存，单张4090根本不够看。我试过一次，刚跑起来就OOM了，笔记本风扇转得像要起飞。后来才明白，全参数微调适合算力充足的团队，或者需要模型彻底适应某个新领域的场景。
LoRA改变了我对微调的认知。它的思路很巧妙，不动原来的权重，在旁边加两个小矩阵，训练的时候只更新这两个小矩阵。参数量能降到原来的百分之一甚至千分之一。我拿一张4090微调7B模型，LoRA跑得很顺畅，显存占用不到10GB。QLoRA在LoRA基础上把基础模型量化到4bit，显存更省，我的旧卡也能跑起来。Adapter是另一种插层方式，效果和LoRA接近，生态没有LoRA热闹。
提示工程和微调是两回事。提示工程不动模型参数，靠设计输入来引导输出。我写过几百字的提示词，试图让模型稳定输出某个格式，结果还是时好时坏。微调是从参数层面改变模型行为，稳定性强很多。我的判断标准很简单：任务变化快、数据少，先用提示工程试水；任务固定、数据充足、对稳定性要求高，就上微调。这两者不冲突，我经常先调提示词找感觉，再拿积累的数据去微调。
2.2 微调数据集构建：指令格式、问答对、多轮对话、数据清洗、标注规范与模板设计
数据这件事，我踩的坑比模型本身还多。最开始我拿一堆文档直接喂进去，模型学出来只会复读原文。后来才明白，微调需要的是指令-回答对。指令格式有很多种，Alpaca格式、ShareGPT格式、ChatML格式，各有各的模板。我习惯用Alpaca格式起步，简单明了：一条instruction，一条input，一条output。数据量不用很大，几千条高质量样本就能看到效果。
多轮对话数据的构造更麻烦。我要把整个对话历史拼成一条样本，模型才能学会上下文关联。有次我做客服微调，把五轮对话拆成单轮喂进去，结果模型完全不记得上一句说了什么。数据清洗是体力活，我用脚本去重、过滤太短或太长的样本，再人工抽查。标注规范要提前定好，不然不同人标出来的风格打架。我一般会写一份标注手册，把边界情况都列出来。
模板设计直接影响训练效果。不同模型的对话模板不一样，Llama 3用特殊的token包裹角色，Qwen有自己的格式。我见过有人拿Llama的模板去训练Qwen，损失曲线看着正常，推理的时候模型却不按套路出牌。我的做法是先看模型官方文档，找到推荐的对话模板，再照着构造数据。数据质量比数量重要得多，我宁可要一千条干净样本，也不要一万条混杂噪声的数据。
2.3 大模型微调框架与工具：PEFT、LLaMA-Factory、Axolotl、Unsloth、DeepSpeed 的选型与配置
PEFT是Hugging Face出的参数高效微调库，LoRA、QLoRA、Adapter都支持。它跟Transformers无缝衔接，我用起来很顺手。缺点是配置项多，新手容易懵。LLaMA-Factory把很多细节封装好了，配置文件一改就能跑。我第一次微调Llama就是用它，命令行敲进去，等几个小时，模型就出来了。它的WebUI也做得不错，适合不喜欢敲命令的人。
Axolotl是另一套配置驱动的框架，YAML文件写清楚参数就行。它的文档比较全，社区活跃。Unsloth主打速度和显存优化，我实测下来，同样的硬件，Unsloth比普通LoRA快将近一倍，显存占用也低。它底层做了不少算子优化，代价是支持的模型种类没那么多。DeepSpeed是微软的分布式训练框架，ZeRO系列优化能把显存摊到多张卡上。单卡用户用不上它，多卡训练的时候它是救星。
我的选型逻辑是看场景。单卡快速实验，用Unsloth或者LLaMA-Factory。需要精细控制训练过程，用PEFT加Transformers。多卡大规模训练，上DeepSpeed。我电脑里这几个环境都留着，conda环境名字分别叫peft、llamafactory、unsloth，互不干扰。配置的时候，学习率、批次大小、梯度累积步数这几个参数最影响结果，我会先跑个小规模实验，看损失曲线正常再放大。
2.4 大模型微调实战流程：训练集划分、超参数设置、学习率调度、批次大小与显存控制
我拿到数据后的第一件事是划分训练集和验证集。比例一般是九比一或者八比二。验证集不能跟训练集有重叠，我见过有人偷懒直接随机切，结果同一条数据既在训练又在验证，指标虚高。划分完我会再检查一遍，确保验证集覆盖了各种任务类型。数据格式统一转成jsonl，每行一条样本，加载起来快。
超参数设置没有标准答案，但有几个经验值可以参考。LoRA的秩一般设8到64，我常用16。学习率在1e-4到3e-4之间，QLoRA可以稍高一点。批次大小受显存限制，我通常设1或者2，再用梯度累积凑出等效批次。梯度累积步数设8，等效批次就是8或者16。学习率调度用余弦退火比较多，前期降得快，后期慢慢收敛。预热步数设总步数的百分之三到五。
显存控制是个动态过程。训练的时候我盯着nvidia-smi，显存快满了就降批次大小，或者开梯度检查点。梯度检查点用时间换空间，速度慢一点，显存省不少。序列长度对显存影响很大，我把最大长度从2048拉到4096，显存直接多占好几个GB。我的策略是先设短一点，看效果，不够再加。训练过程中损失曲线要盯着，一直不降可能是学习率太低，上下震荡可能是太高。我一般跑个几百步就停下来看看输出，不对就调整重来。
2.5 微调模型评估：自动指标、人工评测、领域基准、幻觉检测与安全对齐
自动指标我常用困惑度和BLEU、ROUGE。困惑度看模型对验证集的预测能力，数值越低越好。BLEU和ROUGE适合有标准答案的任务，比如翻译或者摘要。这些指标有个问题，它们跟人类感受不完全一致。我见过困惑度很低的模型，生成的内容却很死板。自动指标只能做粗筛，不能全信。
人工评测才是关键。我会准备一批测试问题，让模型和基座模型分别回答，然后自己盲评。评测维度包括准确性、流畅度、格式遵循度。有次我微调了一个法律问答模型，自动指标看着不错，人工一看，它把法条编号都编错了。领域基准更严格，医疗、法律这些行业有自己的评测集。幻觉检测我一般会问模型一些它不该知道的问题，看它会不会硬编答案。安全对齐要看模型会不会输出有害内容，我拿一批敏感问题测，观察它的拒绝策略。
评估这件事，我建议尽早做。不要等训练完才想起来评估，训练中途就可以拿验证集跑一跑，看趋势。我习惯每五百步存一个检查点，最后挑几个检查点对比。评估结果要记录，哪个版本好，好在哪里，都要写清楚。有次我对比了三个检查点，发现中间那个反而比最后的好，原因是过拟合了。评估不只是打分，是理解模型行为的过程。
2.6 微调后模型合并、量化与本地部署衔接：权重合并、格式转换、推理加速与服务发布
LoRA训练完，权重是分开存的，一个基础模型加一个适配器。要用的时候得合并。PEFT提供了merge_and_unload方法，几行代码就能把适配器权重合并回基础模型。合并后的模型跟普通模型一样，可以直接加载。我合并的时候会注意精度，用FP16合并，别用INT4，不然精度损失叠加。合并完我会跑一遍测试，确认输出跟合并前一致。
格式转换是部署前的必要步骤。Hugging Face格式转GGUF给llama.cpp用，转GPTQ或者AWQ给vLLM用。转换工具各个社区都有，llama.cpp自带convert脚本。量化的时候要选级别，Q4_K_M是我常用的，平衡得好。Q5_K_M质量更高，显存多占一点。Q8_0接近原始精度，显存占用大。我一般会转两三个量化版本，部署的时候看硬件选。
推理加速和服务发布跟第1章讲的内容衔接上了。vLLM加载微调后的模型，吞吐量比Transformers高很多。我做过对比，同样一张卡，vLLM能扛住的并发是Transformers的好几倍。服务发布用FastAPI包一层，加上API key认证，就能给团队用了。我习惯把模型版本号写进API路径，比如/v1/legal-model，方便后续更新。部署完跑一轮回归测试，确认微调效果没丢。
2.7 行业应用案例：智能客服、医疗问答、法律检索、代码生成、教育辅导与知识库增强
智能客服是我做得最多的场景。通用模型回答客服问题，经常太啰嗦或者不按话术来。我拿几千条历史对话微调之后，模型学会了固定话术，回答简洁多了。有次上线后，客户满意度涨了一截。微调的时候我把产品知识库也塞进去了，模型能回答具体产品参数，不用每次查文档。
医疗问答我参与过一个项目，数据是脱敏后的医患对话。这个领域对准确性要求极高，模型说错一句话可能出大事。我们做了大量人工评测，还加了拒答机制，模型不确定的时候会说“建议咨询医生”。法律检索我帮朋友做过，微调后的模型能准确引用法条，检索效率提升明显。代码生成我用自己的代码库微调过，模型学会了我的命名习惯和注释风格，写出来的代码更像我自己写的。
教育辅导场景有意思。我微调了一个数学辅导模型，训练数据是题目加解题步骤。模型学会了分步讲解，不会直接扔答案。知识库增强是另一个方向，我把公司内部文档切片、向量化，再结合微调模型做检索增强生成。模型先检索相关文档，再基于文档回答。这种方式比纯微调灵活，文档更新了不用重新训练。每个行业的数据特点不同，微调策略也要跟着变。
2.8 微调风险、伦理治理与持续迭代策略：数据偏见、版权合规、模型更新、反馈闭环与成本控制
数据偏见是我最担心的问题。训练数据里如果有性别、地域、职业的偏向，模型会学进去。我做过一个实验，用带有偏见的客服数据微调，模型对某些地区的用户明显不耐烦。后来我做了数据平衡，刻意补充了多样化的样本。版权合规也不能忽视，训练数据来源要清楚，不能用盗版内容。我一般只用自己的数据或者明确授权的数据。
模型更新是个持续过程。基础模型出新版本了，微调模型要不要跟着更新？我的做法是保留训练脚本和数据，新基础模型出来重新跑一遍。反馈闭环很重要，上线后收集用户反馈，把bad case挑出来，补充到下一轮训练数据里。成本控制要算账，训练一次的电费、GPU租用费、人工标注费，都要心里有数。我习惯先做小规模实验，验证方向对了再放大。
伦理治理不是喊口号。我在公司内部推动了一套审核流程，微调模型上线前要过数据合规、安全评测、人工抽检三道关。敏感行业还要加人工复核。有次模型生成了一条不当建议，幸好上线前被拦住了。持续迭代要靠机制，不能靠个人热情。我建了个反馈表格，用户遇到问题填进去，每周汇总一次，决定要不要重新训练。微调不是一次性工程，是长期维护的过程。
评论
发表评论