企业官网建设流程全解析

看到这个标题的时候，我第一反应是：又来一个把PPT写成新闻稿的项目。可等我真把安装包和文档拉下来跑完一轮，才发现这事没有标题看起来那么玄，也没有想象中那么水。它其实就是一群做水产数字化的人，拿一个通用大模型底座，往龙虾养殖这种细分到不能再细分的场景里做了一次领域微调，模型内部代号就叫GLM-Turbo，文档首页写的还是GLM--Turbo，我也不知道为什么多敲了一个连字符。标题末尾那个“朴”，我怀疑是从群聊昵称复制过来时混进去的，下文不会再出现。

这篇教程写给三类人：一是真在搞水产数字化、想找一个垂直模型做二开的开发者；二是做农业AI方向、想看看“小底座+领域微调”这条路怎么落地的研究者；三就是手头有显卡、想跟着跑一个完整模型部署流程的玩家。我后面写的所有步骤都基于我自己在Linux环境里的实测，Windows能跑，但坑更多，建议还是照着Linux来。先说清楚：这不是商业产品，是内部实验项目，叫法也为“全球首个”留有水分，咱们把工具本身跑明白，比看标题重要。

1. “全球首个”听起来唬人，拆开看其实就三件事

1.1 它不是从零训练，而是“通用底座+领域微调”

很多人看到“全球首个龙虾模型”会觉得技术含量极高，以为训练了一个几万亿参数的模型。实际完全不是。GLM-Turbo走的是非常标准的“基座模型 + 领域指令微调”路线：先拿一个公开的通用底座，再把龙虾养殖相关的语料、问答对、水质案例灌进去，用小学习率继续训练若干轮。这样做的好处很朴素——通用模型已经会人类的语言、逻辑和常识，我们只需要让它把“氨氮”“弧菌”“虾苗活力”这些词和真实养殖经验绑定起来，不需要让它重新学一遍语法。

做个类比：通用大模型像是刚毕业的大学生，懂很多基础知识，但问到他“水温28度时虾苗摄食率大概掉多少”这种课本上没有的细节，他就只能给你编一个看起来合理的答案。领域微调相当于给他报了一个养殖岗前培训班，把常见问题的标准答案反复背了几遍，再遇到相似问题，他至少会先查记忆而不是现场编。这解释了为什么这个模型体量不大，却能给出比通用模型更聚焦的答案。

我拿到权重时翻了一下训练日志，里面有几个关键数字：训练数据大概只有几万条指令样本，另外加了几十万条网页和研究报告语料；训练轮数只有3轮；用的是低学习率加长warmup。这些细节说明项目组很清楚自己在做什么——不是想炼一个“全能模型”，而是想在一个窄场景里做到“够用”。对普通开源项目来说，这种思路特别值得参考，因为它意味着高质量数据比盲目堆数据更有效。

1.2 为什么选龙虾养殖这种窄场景

选龙虾养殖不是拍脑袋，而是因为这类垂直场景的痛点足够明显。通用模型在回答“pH 8.2是否适合虾苗生长”时，往往会一本正经地给出通用水质标准，但它不知道当地水体、底质、藻相、放苗密度这些上下文。养殖户真正的问题往往口语化严重，比如“水浑了怎么肥”“虾不开口吃料咋整”，甚至带着方言。通用模型面对这种输入很容易跑偏。

另外，龙虾养殖的数据其实并不少，但分散在论文、技术手册、论坛贴子和养殖户的日常记录里，没有统一整理。项目组做的核心工作，就是把散落的数据清洗成结构化指令，再按养殖阶段做成问答对。比如早期虾苗阶段重点在育苗和应激处理，成虾阶段重点在投喂和捕捞销售。经过微调后，模型面对不同阶段会主动切换回答口径，这个学习能力是靠通用底座已有的上下文理解实现的，而不是项目组写了大量if-else规则。

从工程角度看，选择一个足够小的场景还有个隐性优势：评估容易。几万条训练样本可以覆盖绝大部分常见问题，测试集只要几百条就能准确反映模型效果，迭代周期大大缩短。如果是大而全的通用助手，评估指标会很模糊，很难判断哪次改动是变好了还是变差了。窄场景下的模型，每个版本的好坏一眼就能看出来。

1.3 模型能力边界：能做什么、不能做什么

跑通之后，我专门整理了一张能力边界表，方便后面的人不踩“期望过高”的坑。模型能做好的事情，我概括为三大类：一是养殖知识问答，包括病害识别、药品用量解释、饵料选择；二是水质参数解读，给它一组水温、pH、氨氮、亚硝酸盐、溶解氧数值，它能把潜在风险和可操作建议列出来；三是生产流程辅助，比如放苗前后注意事项、分池操作要点、饲料转料建议。这些场景下的回答，风格比通用模型更克制，不会动不动给你写一篇两千字论文。

但它不能做的事情也要说清楚。其一，它不接入实时传感器数据，你每次问它都得手动把参数贴进去，它没有“预测未来”的超能力；其二，它不能替代试纸和检测仪，所有“毒性判断”都基于你输入的数字，数字本身不准，输出再漂亮也没用；其三，它对极端天气和突发灾害只能给常识性建议，不能做精细化预测。很多人误以为垂直模型能当自动化监控系统用，实际它更像一个“值班技术员”，你问什么它答什么，不会主动报警。

我在实测中还发现一个特点：面对超出训练范围的输入，它比通用模型更容易给出“空洞但平稳”的答案。这是领域微调造成的——数据太专，模型退化成“只学套路没学场景”。所以用的时候一定要有心理预期，它在泛化能力上反而可能不如通用底座。这个边界认知，是后面所有使用技巧的前提。

2. 环境准备：显卡、Python、依赖，一样一样来

2.1 硬件需求：不同显存对应不同玩法

先说实话，这个模型虽然不算巨型，但也绝不是随便一台电脑就能跑。我建议把显存当成第一道分界线：16GB显存是舒适区，8GB是及格线，4GB以下就别想着本地推理了，老老实实用云端服务。我在一台16GB显存的机器上跑过，全精度加载很顺畅，还能开比较长的上下文；后来换到8GB显存机器，就得靠4bit量化加CPU卸载，速度慢不少，但能跑通。

具体到不同配置，我的建议是这样：如果你手头是16GB或以上显存，直接用bfloat16加载，推理质量最好，步骤最少；如果只有8GB，就用bitsandbytes做4bit量化，牺牲一点精度换显存容量；如果连8GB都没有，那就优先考虑租一台带GPU的云主机，别在本机折腾。内存方面，32GB内存是底线，因为加载权重文件时要把整个模型读进内存再往显存搬；我试过16GB内存，模型加载中途就卡到爆。

CPU推理我不建议尝试。虽然理论上支持，但一个7B级别的模型在CPU上生成几百个token可能要等十几分钟，交互体验基本为零。如果非要测，至少准备好一个晚上的耐心。总之，这个项目的环境准备核心就一句话：先看显存，再谈安装。

2.2 创建虚拟环境与安装核心依赖

我推荐用Miniconda管理Python环境，避免把系统Python搞乱。我用的Python版本是3.10，这个版本对当前深度学习生态兼容性最好，3.11、3.12也能用，但有些库的二进制包可能滞后。创建环境并激活的命令如下：

conda create -n glm_turbo python=3.10 conda activate glm_turbo

接着安装PyTorch。这一步最容易出岔子，因为PyTorch版本必须和你的CUDA版本匹配。我建议先去终端里输入nvidia-smi看驱动支持的CUDA最高版本，然后据此安装对应版本。我这次用的CUDA 11.8，安装命令是：

pip install torch==2.1.0 torchvision==0.16.0 --index-url https://download.pytorch.org/whl/cu118

这里我不展开CUDA原理，只说一个经验：驱动版本和CUDA Toolkit版本不是一回事，nvidia-smi里显示的是驱动支持的版本，PyTorch只要小于等于它就行。装高了也不一定报错，但装错了会浪费时间。装完PyTorch后，继续安装transformers、accelerate、bitsandbytes和safetensors：

pip install transformers accelerate bitsandbytes safetensors

2.3 验证环境是否正常的第一步

很多人装完依赖就开始加载模型，结果报一堆莫名其妙的错，我建议先做一个10秒验证。创建一个虚拟目录，放一个简单的Python脚本：

import torch print("PyTorch version:", torch.__version__) print("CUDA available:", torch.cuda.is_available()) print("GPU name:", torch.cuda.get_device_name(0) if torch.cuda.is_available() else "CPU only")

如果CUDA available返回False，先别急着跑模型，十有八九是PyTorch的CUDA版本没配对，重装一次比继续往下走省时间。等这一步通过，再把模型文件目录准备好。

这里插一句：我遇到过不少朋友跳过验证，直接加载模型，最后报错“CUDA driver not initialized”，绕了半天才发现是早期安装PyTorch时装成了CPU版本。花30秒做这个检查，后面顺着流程走，心态完全不一样。

3. 模型文件与目录结构：先搞清楚权重在哪

3.1 标准的模型仓库目录长什么样

GLM-Turbo的权重文件在项目组内部分发时是一个压缩包，解压后目录结构如下：

glm_turbo/ ├── config.json ├── generation_config.json ├── model.safetensors.index.json ├── model-00001-of-00002.safetensors ├── model-00002-of-00002.safetensors ├── tokenizer.json ├── tokenizer_config.json └── special_tokens_map.json

如果你接触过transformers，这个结构应该很眼熟。config.json是模型的灵魂，所有架构参数都在里面；tokenizer.json是分词器文件，负责把中文和英文切成token；model.safetensors.index.json是分片权重索引，告诉加载器从哪个分片读哪些张量。这里我要提醒一下，不要随便省略分片文件，模型加载时是按索引文件去找的，少一个文件就会加载失败。

解压之后，我习惯把整个目录放到固定路径，比如~/models/glm_turbo，不要在多个地方复制一堆副本，否则后面改配置时会改错位置。项目管理上最常见的问题就是“我记得改过配置但模型没反应”，八成是改了另一份拷贝。

3.2 配置文件config.json里必须检查的几个字段

加载模型之前，我强烈建议先打开config.json看一眼，不用全看懂，但有几个字段必须核对。首先是model_type，它决定了transformers用哪个模型类去加载，如果写的不对，加载时会直接报错；其次是hidden_size、num_hidden_layers、num_attention_heads这一组维度参数，它们是模型架构的核心，一般情况下不要动；最后是vocab_size，这个字段在后续自定义词表时尤其重要，因为一旦你往tokenizer里加词，这个数字就要同步变大。

我用表格列一下我这次重点关注的字段：

关于vocab_size我要多说一句。如果项目组调整过词表，这个数字会和embedding矩阵的第一维严格对应。你自定义加词之后，必须要执行resize_token_embeddings，否则加载模型时会出现维度不匹配的报错，这个在第6章会详细讲。

3.3 文件完整性校验

权重文件动辄几十GB，传输过程中很容易损坏。项目组随包发了一个SHA256SUMS文件，我拿到之后第一件事就是做校验。Linux下命令很简单：

cd ~/models/glm_turbo sha256sum -c SHA256SUMS

如果输出里有FAILED，那就别浪费时间排查别的，直接用下载工具重传对应文件。我遇到过两次这种问题，一次是网盘中转导致文件截断，一次是磁盘满了写入不完整。校验不通过盲目加载，轻则加载失败，重则模型输出全是乱码，而且这种乱码非常难排查——错不在你的代码，在权重文件本身。

4. 配置与加载：把模型跑起来只差这几步

4.1 最小加载脚本

当环境、模型文件都准备好后，加载过程其实很短。下面是最小可用的加载脚本，我建议所有初学者先从这里开始：

import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_path = "~/models/glm_turbo" tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True) model = AutoModelForCausalLM.from_pretrained( model_path, torch_dtype=torch.bfloat16, device_map="auto", trust_remote_code=True ) model.eval() print("model loaded!")

这个脚本包含几个关键点。trust_remote_code=True是允许加载项目自定义的建模代码，很多国产模型或定制模型都需要这个选项；缺失时transformers会拒绝执行自定义代码。torch_dtype=torch.bfloat16是为了降低显存占用，同时保持数值稳定性，尤其在生成时不容易溢出。device_map="auto"让transformers自动把算子分配到可用的GPU或CPU上，省去手动管理设备。

如果你的显存不够全精度加载，可以把加载方式换成4bit量化：

from transformers import BitsAndBytesConfig bnb_config = BitsAndBytesConfig( load_in_4bit=True, bnb_4bit_quant_type="nf4", bnb_4bit_compute_dtype=torch.bfloat16, ) model = AutoModelForCausalLM.from_pretrained( model_path, quantization_config=bnb_config, device_map="auto", trust_remote_code=True, )

这个方案是我实测中“低配显卡唯一能跑”的选择。4bit量化会把大部分权重压到4位精度，显存需求几乎减半，8GB显存也能勉强跑起来。缺点也很明显，量化后的模型在某些专业长句上的回答会略有变形，尤其涉及数字时容易出现“换算口误”，比如把0.1说成0.01。

4.2 推理参数怎么调才不像AI说话

模型加载完了，接一段推理逻辑。我给模型封装了一个简单的问答函数：

def ask(prompt): messages = [{"role": "user", "content": prompt}] text = tokenizer.apply_chat_template( messages, tokenize=False, add_generation_prompt=True, ) inputs = tokenizer(text, return_tensors="pt").to(model.device) outputs = model.generate( **inputs, max_new_tokens=512, temperature=0.7, top_p=0.9, do_sample=True, repetition_penalty=1.05, ) answer = tokenizer.decode( outputs[0][inputs.input_ids.shape[1]:], skip_special_tokens=True, ) return answer

这里参数选择不是随便拍的。temperature=0.7是生成多样性和稳定性的折中点，太低容易机械复读模板，太高容易胡言乱语。top_p=0.9在采样时限制候选范围，和temperature配合使用，效果比单用temperature稳定。repetition_penalty=1.05是我特别推荐的参数，因为领域模型微调后很容易蹈“问答模板复读”的毛病，这个惩罚项能明显减少车轱辘话。max_new_tokens=512对于养殖问答足够了，太长反而容易跑偏。

有一个反直觉的经验：不要把这个模型当搜索引擎，问太开放的问题。比如“给我写一篇关于龙虾养殖的论文大纲”，它会给你一个看似工整但内容平庸的大纲；但如果你问“水温25度，虾苗放养密度为每亩3万尾，投放第二天需要关注哪些指标”，它的回答会具体得多。越具体的问题，领域模型的价值越明显。

4.3 接入对话模板的正确方式

上面函数里用了apply_chat_template，这一步千万别省。很多初学者喜欢直接把用户输入拼成一个字符串喂给模型，结果发现模型回答风格千奇百怪，甚至把系统提示词也当成回答的一部分。原因就是没有走对话模板。

对话模板的本质是让输入格式遵循训练时使用的格式。GLM-Turbo训练数据采用类似 [用户问题] 然后 [助手回答] 的内容组织形式，如果你不套模板，模型不知道现在该以什么身份续写。apply_chat_template会帮你把[{"role": "user", "content": "..."}]转换成模型认识的特殊token序列。

我强烈建议每次启动服务前都打印一次模板转换后的文本，确认特殊token位置对不对。比如打印text = tokenizer.apply_chat_template(...)后能看到类似<|user|>...<|assistant|>这样的结构，说明是对的。不要直接拿“你好”去测，因为“你好”这类通用开场白，即使模板错了也可能碰巧得到很像样的回答，会给人错误的安全感。

5. 实际任务：用龙虾模型跑一轮养殖问答

5.1 构造一个真实的水质场景

光说不练没有意义，我构造一个最常见的场景：成虾养殖池水质调整。模拟一组典型的池水数据，输入给模型。先看输入：

水温28度，pH 8.2，氨氮0.1mg/L，亚硝酸盐0.05mg/L，溶解氧5.5mg/L，虾苗活力一般，摄食速度较慢，接下来该怎么调整？

这组数据看起来不算极端，但溶解氧5.5其实已经偏低，再加上虾苗活力一般，说明可能处于应激状态。通用模型看到这种问题，很可能会告诉你“注意换水、增加增氧、调整投喂”，正确但肤浅。领域模型能不能给出更细颗粒度的建议，就是检验微调效果的关键。

5.2 模型的输出长什么样

我在实测中问了几次，输出稳定在一个模式，我用其中一次的回答摘录如下：

当前溶解氧5.5mg/L低于安全区间，建议先开启增氧设备，将溶解氧维持在6.0mg/L以上再考虑喂料。氨氮0.1mg/L尚在安全范围，但亚硝酸盐0.05mg/L已属于逐步累积阶段，建议连续两天检测亚硝酸盐变化趋势，避免突然升高。投喂方面，当前虾苗摄食速度较慢，可暂时按正常投喂量的80%执行，并观察2小时内的吃完比例，若仍不理想，应排查最近是否有水质剧烈波动或药品残留影响虾苗状态。

这个输出让我比较满意的地方是，它没有停留在“要增氧要换水”的泛泛层面，而是把投喂量改成80%、让你观察2小时吃完比例、提醒查药品残留，这些都是养殖手册里常见但通用模型很少主动引用的细节。这就是领域微调的价值：它把课本知识训练成了条件反射。

当然，输出也不是完美。它没有明确指出“检测溶氧可能偏低，需要校正设备”，这个点是项目组后续想优化的方向。归根结底，这个模型给出的仍然是建议，最终判断还是要靠人做。

5.3 结果校验与防幻觉

生成结果看起来头头是道，但一定要做校验，因为幻觉在垂直模型里同样存在，甚至因为训练数据窄，幻觉更容易“自信地胡说”。我有一套很轻量的校验方法：专门建了一个测试集，包含大约100条有标准答案的问答对，每次模型输出后，先人工抽查20条，再统计关键词命中率。

用得最多的技巧是让模型给出依据。我在提示词里加过一句话：“请先列出判断依据，再给出建议”。效果很明显，模型会先复述它认为关键的水质指标，然后再做分析。这不算真正的“理论推理”，但至少给了人类复核的抓手。比如它如果说“先增氧”，我们就能看到它是否引用了溶解氧5.5这个输入值；如果说“暂时按80%投喂”，就知道它看到了摄食速度慢的条件。只要依据能对应上输入，这条回答就可以放心一半。

防幻觉还有一个土办法：限制输入范围。在服务层做一道拦截，凡是问题里没带任何数量、时间、操作对象等实际信息，就直接转给通用模型处理，不劳驾这个垂直模型。因为领域模型很容易在没有信息量的开放题上“强行表演”。这个技巧我在部署时用了，效果立竿见影，垂直模型真正擅长的就是“给一组真实数据，输出一条合理决策链”，别的场景还是别难为它。

6. 安装配置过程中的踩坑实录

6.1 显存不够：量化加载，立省百分之几十

我第一次在8GB显卡上加载时，直接OOM，报错信息大致是CUDA out of memory. Tried to allocate 512.00 MiB。我当时的第一个念头是换更大的上下文长度、关掉一些没用的显存占用，但治标不治本。后来才意识到，最有效的方法就是把权重换成4bit加载。

具体操作我在第4章已经给过代码，这里补充一个量化后的观察指标：加载模型后，可以用torch.cuda.memory_allocated()查看显存占用。在我的实测里，bfloat16全精度大概占用接近13GB，而4bit量化后只要6GB左右，差距非常明显。量化后生成速度会稍微慢一点，但完全在可接受范围。如果你的显卡是Tesla系列或者老款显卡，需要注意bitsandbytes是否支持你的卡，这个库对新卡的兼容比较好，老卡可能要换更新版本。

还有一个小坑：开启量化加载后，device_map="auto"有时会把某些层放到CPU上，导致首轮生成特别慢。解决办法是把模型的max_memory参数显式设一下，比如给GPU设10GB，给CPU设32GB，让分配器优先填满GPU。我以前觉得这个参数无所谓，直到发现模型有接近10层被放到CPU上，首token延迟直接爆炸。

6.2 自定义词表后embedding错位

因为项目组扩展了词表，加了很多水产领域词汇，比如“虾苗”“弧菌”“溶解氧”等，我第一次加载后训练就报了一个维度错位的错误。报错大意是size mismatch for model.embed_tokens.weight: copying a param with shape torch.Size([65024, 4096]) from checkpoint, the shape in current model is torch.Size([65000, 4096])。

原因很清楚：词表里的token数量是65024，但当前模型初始化时的vocab_size还是旧值65000。修复方法就是加载模型后调用：

tokenizer.add_tokens(["虾苗", "弧菌", "溶解氧", "亚硝酸盐"]) model.resize_token_embeddings(len(tokenizer))

resize_token_embeddings会自动调整embedding层维度，把新增token对应的向量随机初始化。但这个操作必须在加载原始权重之后、开始任何训练/推理之前完成。如果你是在训练中途才想起来加词，之前保存的权重和当前模型状态完全不匹配，等于浪费了一轮训练。

这个坑提醒我：任何时候修改词表，都要同时改动config.json里的vocab_size字段，并重新保存权重。否则下一次加载时，你可能自己都忘了模型是扩词表前的版本还是扩词表后的版本，排查起来非常痛苦。

6.3 量化后输出乱码与重复

量化后的模型输出偶尔会出现一种现象：开头几句很正常，后面突然蹦出几个“无意义字符”，然后继续正常，或者连续几行重复同一句话。我一开始以为是tokenizer出了问题，后来发现是量化推理时的数值随机性被放大了。

我查了生成日志，发现这些乱码token集中在repetition_penalty生效时。原因是量化后权重精度低了，同一个概率分布里相近token的分数变得更接近，惩罚项容易把前面出现的token分数压得太低，导致采样器跳到了概率接近的“乱码区”。解决方案很简单，把repetition_penalty从1.05降到1.02，或者把top_p从0.9调到0.85，乱码概率就小很多。

这个经验让我意识到，量化不能只考虑加载阶段，推理参数也必须跟着重新调。不要因为全精度下某个参数好用，就默认量化后也一样。我建议量化用户记住一个估值：量化后温度需要比全精度低0.1到0.2，惩罚项需要低0.02左右，生成会更稳。

6.4 训练阶段loss不降的warmup问题

最后说一个训练相关的坑，虽然标题是安装、配置、使用，但很多人在集成后必然会走到“想再微调一下”这一步。我第一次做参数微调时，loss在前500步几乎不降，盯着曲线干着急，一度以为是数据或者学习率的问题。后来发现是warmup步数设得太长，模型在前2000步里根本还没进入正常学习轨道。

warmup的作用是让学习率从零逐渐爬升到目标值，避免一开始就大踏步导致梯度震荡。但如果warmup步数和总步数的比例设置太大，就等于让模型白白热身很久。我后来把训练总步数定在3000步，warmup设置100步，也就是大概3%的比例，loss下降速度立刻恢复正常。项目组给的训练日志里用的是总步数的5%左右，我按这个比例复现效果也不错。

这个坑给我最重要的提醒是：面对loss曲线不降，不要急着加数据或者改模型结构，先检查warmup和batch size这类基础超参数。我见过太多人一遇到loss“停滞”就怀疑模型没救了，结果只改了一个warmup参数就恢复了。

7. 进阶：用LoRA做一轮自己的微调

7.1 准备数据：不需要海量，但要精

当你跑通推理、也理解了边界之后，自然想用自己的数据微调一版。我不建议一上来就对全量权重做全参数微调，那是又贵又容易过拟合的路线，推荐用LoRA。

LoRA的核心思路很直白：冻结原来的大权重，只训练注入的一小部分低秩矩阵，参数量可能只有原来的1%左右。看起来没训几个参数，但效果往往意外地好，因为原模型已经很强，只需要微调“说话方式”和“知识点倾向”。

数据准备是重中之重。我的做法是把所有问答对整理成JSONL格式，每一行一条：

{"instruction": "水温28度，pH 8.2，氨氮0.1mg/L，虾苗活力一般，摄食慢，怎么调整？", "output": "建议先提升溶解氧至6.0以上，投喂量降至正常80%，观察2小时吃完比例。"}

要提醒的是，数据量不需要多，但必须精。我第一批数据只有600条，训练后主观评价明显更“像”养殖技术员了。我后来又试了把数据扩到3000条，但其中混了一些从论坛复制来的闲聊贴，效果反而变差。领域模型对“语气一致性”非常敏感，数据里的噪音会让模型变成四不像。所以我的经验是：先准备300条高质量数据跑通全流程，确定有效后再逐步扩量。

7.2 LoRA参数怎么选

LoRA的参数看起来很复杂，但核心就几个：r表示低秩矩阵的秩，alpha表示缩放系数，target_modules决定在哪几个模块上注入。我第一次训练时用了r=16，alpha=32，target_modules覆盖了注意力层的q/k/v/o和MLP层的gate/up/down，一共7个模块。这个配置在7B级模型里非常通用，性价比很高。

下面是训练脚本的关键片段：

from peft import LoraConfig, get_peft_model lora_config = LoraConfig( r=16, lora_alpha=32, target_modules=["q_proj", "v_proj", "k_proj", "o_proj", "gate_proj", "up_proj", "down_proj"], lora_dropout=0.05, bias="none", ) model = get_peft_model(model, lora_config) model.print_trainable_parameters()

print_trainable_parameters()会显示可训练参数量，正常应该在总参数的5%以下。如果显示的占比超过10%，大概率是target_modules写得太宽或者层数重复，需要复查。

关于r的选择，我自己的体会是：垂直场景小模型用16足够，不需要盲目上64或128。r越大，可训练参数量越大，模型拟合能力越强，但训练数据不够时反而更容易遗忘通用知识。有一个很直观的现象：用r=64训练后，模型在龙虾问答上表现很好，但一转到“给我解释一下什么是溶解氧”这种通用解释题上，回答质量反而下降了。这不是模型退化，是低秩空间里注入的领域知识“挤占”了原来的能力。用较小的r则几乎没有这个问题。

7.3 微调后的评估：先人工，再谈指标

微调完之后怎么评估，是最容易被忽视的一环。我见过不少团队把loss曲线发出来，就声称模型变好了。但loss下降只能说明模型记住了训练集，不能说明它在陌生问题上表现好。

我的评估流程分三步。第一步，人工测试不少于50条训练集之外的真实问题，覆盖水质、投喂、病害、蜕壳、运输几个方向，把模型回答逐条打分，分“可用”“勉强可用”“不可用”三档。第二步，对照一套固定的检查项，比如是否引用输入参数、是否给出具体数值而非空话、是否区分不同养殖阶段、是否避免绝对化表述。第三步，再回测一遍“通用能力”，挑十道不相关的常识题，看模型有没有变成只会养虾的“偏科生”。

如果你手头有多个候选版本，也建议做同一批样本的对比测试。我在第5章提到过，每次版本更新都要用同一套100条测试集去跑，哪怕判断结果是主观的，也能清晰看出趋势。只凭一两次对话体感评估，很容易被模型生成的“势利话术”迷惑，以为回答专业，实际只是表面流畅。

最后说几个实操中的体会

整个流程跑下来，我最深的感受不是“模型部署有多难”，而是“领域模型要想真正有用，数据比模型结构重要得多”。GLM-Turbo之所以能在龙虾养殖这种小得不能再小的场景里看起来能用，不是因为模型架构多先进，而是项目组把大量分散的养殖经验整理成了高密度指令数据。这个认知直接改变了我之后做类似项目的习惯：先囤数据，再想模型。

还有一个具体的技巧想分享：在配置服务时，把第5章那种典型问答做成一个预置快捷列表，放到交互入口旁边，而不是让用户对着空文本框发呆。模型不是搜索引擎，很多人不知道该怎么问才详细。给几个带具体数值的示例问题，输出质量会明显提高，这比反复调temperature管用得多。如果你之后要给别人部署这套模型，强烈建议把这条加上。

最后再说一遍：这模型不是神器，它只能把“有数据、有参数、有标准答案”的养殖问题回答得比较像样。能把这个边界守住，你就能顺手把垂直模型真正落到生产工具里；守不住，再炫酷的“全球首个”也只是个演示文稿。