简介：面向希望在个人电脑上运行专属领域ChatGPT模型的开发者，这里提供一套基于ChatGLM的继续训练与精调实现资源，完整覆盖了从数据准备、模型训练到推理部署的代码流程。压缩包共28个文件，大小仅124KB，以Python脚本为主（12个py文件），配合json数据与配置、xml工程结构、requirements依赖及README说明，便于快速搭建本地微调项目。核心提供训练、评估、推理等环节的脚本，以及示例数据集与数据自制工具；同时包含分词处理、数据转换等模块，配合模型参数配置、DeepSpeed训练配置和API演示样例，可让使用者在PC上尝试轻量LoRA微调，并快速搭建Web演示接口。项目结构清晰，数据生成、处理、训练、评估到推理部署均有对应模块，便于二次开发与参数调试。目前已有1581人学习，适合具备一定Python基础、希望将通用大模型定制到垂直领域的机器学习开发者和研究者参考。 这个标题一眼看过去就很有画面感。chagpt这个拼写，懂的都懂，大概率是ChatGPT的笔误，但项目本身一点不马虎：用开源的ChatGLM做继续训练和精调，最终产出一个能装进zip、在普通PC上跑起来的领域对话模型。这类“私有化小模型”的需求最近特别多，不管你是想给公司做个内部知识库问答机器人，还是想把手头积累的行业语料变成对话模型，这套流程都值得认真走一遍。这篇就按我从头到尾实操下来的经验，把继续训练、指令精调、PC端推理部署这几大步拆开讲透，包括那些文档里不会写、只有踩过坑才知道的细节。
1. 项目整体设计与思路拆解
1.1 为什么选ChatGLM而不是其他开源模型
ChatGLM系列在中文场景下的性价比确实高。相比同等参数规模的Llama系模型，ChatGLM的中文词表更大，分词器对中文的切分更友好，训练和推理时的token消耗也更少。做领域微调时，这个优势会被放大：同样的文本量，ChatGLM需要计算的token数更少，训练速度和显存占用都更可观。
另一个原因是ChatGLM的基座版本选择灵活。从6B到更小的1.5B、3B版本都有，不同显存条件下的PC都能找到合适切入点。实测下来，6B模型跑SFT微调，消费级显卡（16GB显存）勉强能玩，但如果只想做推理部署，量化后8GB显存的卡也能流畅跑。这种“宽进严出”的特性，让它特别适合PC端玩私有化模型。
1.2 “继续训练”和“精调”分别解决什么问题
很多初学者容易把这两个概念混成一锅粥。简单说，继续训练（也叫增量预训练）是让模型“涨知识”，精调（SFT指令微调）是让模型“懂规矩”。
继续训练用的是纯文本语料，格式就是大段大段的领域文章、对话记录、技术文档，目标是让模型把领域内的术语、事实、表述习惯学进去。但只做这步，模型并不会变成好用的对话助手——它只是“肚子里有货”，输出仍然可能是发散式的，不知道怎么按指令回答。
精调用的是“指令-回答”配对数据，显式教会模型“用户问什么，你就怎么答”。做完精调，模型才真正从一个文本续写器变成对话助手。项目标题里“继续训练和精调”两个都写了，说明作者很清楚完整的流程必须两步都走，缺一个效果都会打折扣。我个人建议的顺序也是：先增量预训练，再指令微调。反过来做的话，模型容易在后续继续训练中把学过的指令格式冲淡。
1.3 为什么强调“可以在PC上运行”
“PC上运行”这四个字是整条技术路线的核心约束。这意味着你不能默认有A100或者多卡集群，必须把显存占用、内存占用、推理速度全部纳入设计考量。
实际操作中，我会围绕三个指标做取舍：模型参数量、量化精度、上下文长度。参数量决定底座选6B还是3B；量化精度决定推理时用FP16还是INT8/INT4；上下文长度决定最多能吃进多少字的输入。这三者此消彼长，比如选了6B+FP16，可用上下文就短；选了3B+INT4，能留出更多显存给长文本。项目既然要求PC可跑，通常我会推荐ChatGLM3-6B做Q4量化部署，或者直接用ChatGLM3-1.5B这种小模型做轻量级方案。
2. 环境准备与数据工程
2.1 硬件与训练环境搭建思路
先摸清自己的硬件底子。训练阶段和推理阶段的显存需求差别非常大：推理只要装下模型权重加一小块KV Cache；训练则要额外装下优化器状态、梯度、激活值。以6B模型为例，FP16推理大概需要12GB显存，但同样的模型做LoRA微调，16GB显存能勉强跑，全量微调基本得24GB起步。这块有一个很实用的估算方法：全量训练显存约等于模型参数量乘以20（单位为字节），LoRA微调可以压到参数量乘以6到8。也就是说，6B模型全量训练大概要120GB显存，LoRA只需要40GB左右，实际加上激活值后16GB显存也能跑小batch。
软件环境方面，首选Linux或WSL2。Windows裸跑PyTorch不是不行，但很多底层库的兼容性问题会消耗大量精力。训练框架我用的是transformers + peft + datasets 这套组合，这几样都是Hugging Face生态的标准件，配合度很高。CUDA版本建议直接上11.8或12.x，PyTorch选对应预编译版本，省去自行编译的痛苦。
注意：显存不够时优先降低batch size，而不是调小模型。梯度累积（gradient accumulation）可以在不减少有效batch的前提下，把单次显存峰值压下来，这是我最常用来“挤”显存的手段。
2.2 领域语料怎么收集和清洗
继续训练的数据质量直接决定模型“懂不懂行”。收集语料时，建议优先找这三类来源：一是行业文档与操作手册，二是客服对话记录/工单数据，三是专业社区的问答帖。数量上，个人项目10万到50万条文本就够了，不必追求百万级——PC端训练的吞吐量有限，数据太多反而跑不动。
清洗是比收集更关键的一环。我踩过最典型的坑是语料里残留大量HTML标签和Markdown语法符号，模型确实能学会输出这些乱码。清洗流程我一般做四步：去重（用MinHash或简单的MD5加上文本相似度判断）、去噪（删掉导航栏、版权声明、超链接等非正文内容）、统一编码（全部转成UTF-8）、格式规范化（把多个换行压成两个，去掉零宽字符）。清洗完还要做一次抽样检查，肉眼扫一批数据确认清洗效果，脏数据混进去一万条，后面就得花十倍的时间去调模型。
2.3 指令数据的构建与格式设计
精调的效果好坏，指令数据的质量权重超过一半。常见做法是做成JSON数组，每项包含instruction（指令）、input（可选输入）、output（期望输出）。这个格式对应的是ChatGLM的官方微调格式，用transformers的DataCollator处理起来很方便。
数据规模上，指令微调和继续训练不一样，通常几千到几万条高质量数据就能见效。数量不足时宁可用规则模板批量生成，也别随便从网上抓乱七八糟的数据凑数。我自己常用的一个技巧是先写20条种子样本，涵盖最常见的提问类型，然后设计一个模板，把行业语料里的知识点填充进去，自动扩展成几百条“背景信息+指令+回答”的样本。这样既能保证规模，又能控制质量。
3. 核心实操：继续训练与精调的完整流程
3.1 继续训练阶段的关键参数与实现
增量预训练我用的是transformers的Trainer，模型加载后把prepare_model_for_kbit_training打开，配合peft的LoRA配置。LoRA的秩（r）我习惯设在8到16之间，alpha通常设成r的两倍。这个配置在大多数场景下都能平衡“学得进”和“不忘本”。
先看数据集处理的核心代码：
from transformers import AutoTokenizer, AutoModelForCausalLM from datasets import load_dataset tokenizer = AutoTokenizer.from_pretrained("chatglm3-6b", trust_remote_code=True) dataset = load_dataset("json", data_files="domain_corpus.jsonl") def tokenize_function(examples): # 统一在文本末尾加EOS，保证序列边界清晰 texts = [t + tokenizer.eos_token for t in examples["text"]] return tokenizer(texts, max_length=2048, truncation=True, padding=False) tokenized_dataset = dataset.map(tokenize_function, batched=True)这块有个容易忽略的点：ChatGLM类的模型加载时通常需要trust_remote_code=True，因为它的模型结构用了自定义代码，不信任远程代码的话根本加载不了。我第一次跑的时候漏了这个参数，报错报得莫名其妙。
训练参数里，学习率我常用5e-5，warmup_ratio设0.1，训练轮数视语料量而定，一般2到3轮即可。轮数并不是越多越好，增量训练做太狠会破坏原有通用能力，这在领域模型里叫“灾难性遗忘”。判断标准很简单：训练后用通用问题测一测，如果连“编一个冷笑话”都答不上来，说明训过头了。
3.2 指令精调阶段的训练流程
精调的代码骨架和继续训练类似，区别在数据和模型加载方式。数据端是instruction、input、output三字段结构，模型端需要用peft的LoraConfig配置target_modules。
ChatGLM-6B的target_modules通常设置为query_key_value这一个模块，这是它和LlaMA系（一般用q_proj、v_proj）最大的不同点。这个参数配错的话，LoRA等于没生效，训练完模型权重纹丝不动，推理结果和底座模型一模一样。我当时排查了半天，最后打印模型结构才发现的。
一个规范的精调训练脚本核心片段如下：
from peft import LoraConfig, get_peft_model, TaskType lora_config = LoraConfig( r=8, lora_alpha=16, lora_dropout=0.05, target_modules=["query_key_value"], bias="none", task_type=TaskType.CAUSAL_LM, ) model = AutoModelForCausalLM.from_pretrained( "chatglm3-6b", load_in_4bit=True, # 4bit量化加载，大幅降低显存占用 trust_remote_code=True ) model = prepare_model_for_kbit_training(model) model = get_peft_model(model, lora_config)训练参数上，精调的学习率可以比继续训练稍微大一点，1e-4到2e-4都是合理区间。epoch我一般控制在2到3轮，设大了模型会把指令数据的格式背得滚瓜烂熟，但对没见过的新问题反而泛化变差。还有个容易忽视的细节：精调阶段padding策略建议改成padding="max_length"，保持batch内每个样本长度一致，Trainer内部的损失计算才不会出偏差。
3.3 合并LoRA权重与底座模型
训练完成后，LoRA权重是独立保存的。部署推理时有两种选择：一是保留LoRA适配器，加载底座模型后再挂载；二是把LoRA权重合并回底座模型，导出一个完整权重文件。
我强烈建议最终部署时选择合并导出。原因有两个：一是推理速度更快——省去每层额外计算LoRA分支的时间；二是部署更省心——不需要在推理代码里额外管理peft配置。合并代码很简单：
from peft import PeftModel base_model = AutoModelForCausalLM.from_pretrained("chatglm3-6b", trust_remote_code=True) model = PeftModel.from_pretrained(base_model, "./lora_ckpt") merged_model = model.merge_and_unload() merged_model.save_pretrained("./domain_chatglm_merged") tokenizer.save_pretrained("./domain_chatglm_merged")注意merge_and_unload()之后，模型结构里不会残留任何LoRA痕迹，此时再保存的就是一个完整的、可以直接加载的ChatGLM模型。这个文件大小和底座模型相当，6B版本合并后大约是12GB（FP16）。如果想进一步压缩，可以再走一步量化，压到4GB左右。
4. PC端推理部署与效果优化
4.1 显存优化与量化方案选择
训练完成后的模型要落到PC上跑，量化是第一优先级。常见的量化选择是bitsandbytes的4bit/8bit加载，还有GPTQ和GGUF两种更彻底的离线量化方案。
实测下来，如果要追求最好的PC兼容性和部署便利性，我推荐GGUF格式，配合llama.cpp或ollama这个推理运行时，完全不依赖PyTorch环境，纯C++实现，对老显卡和纯CPU机器都友好。转换路径也不复杂：先用transformers导出ONNX或直接用transformers权重的ChatGLM模型配合llama.cpp的转换脚本，生成GGUF文件，然后丢给ollama一键跑起来。
要是还想保留transformers生态做更多定制，bitsandbytes的8bit加载是最省事的选择。但要注意，部分量化方案和某些显卡的兼容性有坑，实测中出现过4bit推理在个别显卡上速度反而变慢的情况。我的建议是项目初期先用8bit兜底，确认效果后再考虑上GGUF追求极致性能。
4.2 流式输出与并发处理
PC上跑模型，用户体验的关键就在响应速度。ChatGLM本身支持流式输出（streaming），通过model.stream_chat()接口逐token返回结果。用FastAPI包装一下，前端就能做到“边说边显示”的效果，体感上比等完整回答再一次性吐出好太多。
并发方面，PC的算力有限，我的经验是把并发数限制在1到2，多余请求排队处理。盲目调大并发只会导致显存OOM，或者所有请求一起龟速。实践中我还会把输入长度限制在1024 token以内，输出长度控制在512 token以内，这样单次请求的显存峰值和响应延迟都能保持稳定。
注意：部署时一定要用
torch.inference_mode()或@torch.no_grad()包裹推理过程，关闭梯度计算。这不仅省显存，还能明显提升推理速度。新手经常忽略这行代码，直接把训练时的写法套到推理上，GPU跑得又慢又烫。实测可以提升1.5-2倍的速度。
4.3 效果评估的“三件套”测试法
模型训完不能只看loss降没降，必须做效果测试。我习惯从三个维度交叉验证：领域问题测试、通用能力测试、敏感边界测试。
领域问题测试用训练数据里没有出现过的、但属于该领域的问题来问，检查模型是否真的学到了知识，而不是把训练语料背下来了。通用能力测试用“写一首诗”“解释一下什么是机器学习”这类问题，确认模型没丢掉基础能力。边界测试则用一些对抗性问题，确保模型在方向不偏的情况下不出现离谱输出。这三个维度各有侧重，分别对应“学得会”“忘不掉”“不失控”。
具体实施时，我通常从测试数据里手动挑15到20个问题，按上面三类各分配5到7个，每轮训练完固定跑一遍。不需要自动化评估脚本，人工看结果反而更快更准。这比只盯着筛选loss曲线靠谱得多。
5. 常见问题与排查技巧实录
5.1 显存不足与训练崩溃的排查
训练中报“CUDA out of memory”是最常见的事故。常规手段是从这几个方向依次调：batch size减半、梯度累积补回来；输入最大长度缩短（2048降到1024）；优化器换成8bit AdamW；开gradient_checkpointing以时间换空间。
如果以上都试过还是爆显存，就要重新评估方案了：换更小的底座模型（6B换3B甚至1.5B），或者把数据切得更碎。还有一个小众但有效的技巧：用torch.cuda.empty_cache()在每轮评估前清一次缓存碎片，有时能多挤出几百MB。虽然治标不治本，但对小显存用户很实用。
5.2 Loss不下降或下降过慢
增量预训练时loss不降，通常是数据质量和格式问题。先Check一下语料是不是大量重复——重复数据会让模型快速过拟合，loss假性下降后就不再动了。另一个原因是学习率太低，特别是用了warmup后，前几百步几乎看不到loss波动，这时候别急着中断，多跑一段看趋势。
如果数据没问题，就要看学习率是否匹配LoRA的秩。r设大时（比如16），lr可以相应调高一些；r小时（比如4），lr要调低防止震荡。我常用的组合是r=8、lr=5e-5，比较稳。
5.3 精调后模型输出空洞/答非所问
这类问题的元凶多半是指令数据格式不一致。ChatGLM的精调数据里，instruction和input的含义有别：instruction是“做什么”，input是“做这件事的素材”。很多新手把整段上下文都塞进instruction，模型学习时指令信号混乱，推理时自然抓不准重点。
另一个常见原因是指令数据的回答描述太长，指令太短。模型学到的是“不管用户问什么，我都回一大段话”，而不是“根据问题精准回答”。建议指令保持1到2句话，输出控制在合理长度，让模型明确学到“简洁回答”的映射关系。精调完如果发现模型说话风格变啰嗦，也可以试试在推理参数里调高temperature，并在system prompt里强调“用最简洁的中文回答”。
5.4 部署后首token等待过长
PC端跑大模型，首token延迟是个硬伤。原因在于用户输入的prompt需要完整过一遍模型才能开始生成第一个token。优化手段有三招：一是限制用户输入长度，过长的历史记录做截断；二是打开KV Cache复用，多轮对话时只对新增内容计算；三是换用支持前缀缓存的推理框架，减少重复计算。综合用下来，多轮对话场景的响应速度能明显提升。
提示：如果你用的是llama.cpp/ollama路线的GGUF方案，新版本自带prompt caching，基本上开箱即用。而如果自己用transformers写推理服务，多轮对话时需要手动维护历史token的KV Cache，处理不好会出现“聊得越多越慢”的尴尬情况。
写在最后的实操建议
如果你正处于起步阶段，我个人的建议是不要一上来就追求把6B模型在PC上全量微调和部署完。先从ChatGLM3-1.5B或更小的模型开始，用几百条数据和LoRA跑通整条链路，然后再逐步放大到6B和更复杂的场景。小模型试错成本低，一次训练几分钟就能出结果，你可以快速验证数据格式、参数设置、部署流程，等全流程跑顺了再上大模型，效率反而更高。另外，项目里那些“zip打包交付”的习惯也别丢，把训练代码、数据处理脚本、部署说明、量化好的模型都整理进一个包，后续不管自己在别的机器上复用，还是分享给别人，都能省一大堆折腾时间。祝你在自己的领域模型上早日跑出满意效果。
本文还有配套的精品资源，点击获取
