简介面向AI和大数据零基础学习者的DeepSeek本地模型训练实操指南尤其适合仅掌握JavaScript或对Python只有初步了解的学习者。资源包为单个PDF文件压缩后约1.93MB内部以完整步骤说明从Ollama部署到数据预处理的每一个环节。指南首先介绍通过Ollama在本地安装DeepSeek模型并说明模型文件存放路径再讲解准备txt训练样本、安装Python及torch/transformers/datasets依赖库的关键细节同时解读安装过程中的下载进度与等待时间。后续内容推荐VSCode、PyCharm、Jupyter Notebook等编辑器给出fine_tune_deepseek文件夹与脚本文件的目录组织方式以及使用transformers加载本地模型与分词器的代码示例同时演示数据预处理和运行确认方法。对完全不具备深度学习背景的初学者而言这份文档能帮助跨越环境配置障碍按步骤完成DeepSeek本地模型的初步微调目前已有269人学习下载。1. 本地训练 deepseek从 API 调用到调出自己的模型这一步到底卡在哪做 AI 应用的人大概都经历过这个场景调 deepseek 的 API 跑通了一版原型效果不错但一算账就头疼——对话多的业务每天烧掉几十上百块数据还得全部过一遍外部接口稍微敏感一点的场景根本不敢用。于是“deepseek 本地模型训练”这个词就成了检索热门大家想知道的是同一件事能不能在自有的显卡上把开源的 deepseek 权重拿来微调成自己的模型效果不掉队成本还能控住。这里要先说破一个认知误区本地训练 deepseek 不是从头预训练那些动辄几千张卡、几十万条文本的活儿跟普通人没关系。绝大多数从业者做的是“参数高效微调”也就是 LoRA 或 QLoRA——冻结原模型只训练一小部分注入的低秩矩阵用一张消费级显卡就能跑。8GB 显存能动 1.5B 参数的小模型24GB 显存可以够到 7B 甚至 14B。做完之后把 LoRA 权重合并回原模型再导出 GGUF 格式跑本地推理模型就是自己的了。这篇只讲一件事从下载权重、准备数据集、跑通训练脚本到把模型合并导出并验证效果。适合手里有 8GB 以上显存、想私有化部署或定制领域模型的开发者阅读也适合刚入门大模型微调、想找个完整链路练手的人照着做。2. 选型与准备本地训练 deepseek 该用哪个版本环境怎么搭2.1 版本矩阵先搞清楚你该训练哪个 deepseekdeepseek 开源出来的模型不是一个而是一族。先从最基础的了解DeepSeek LLM 有 7B 和 67B 两个尺寸7B 是本地训练最常用的底座DeepSeek-Coder 系列在代码任务上更强如果你要做代码补全或仓库级理解选它而不是通用版DeepSeek-MoE 是混合专家架构16B 激活参数但总参数上百亿推理效率高但本地训练时 LoRA 注入的 target_modules 选择和显存占用都更复杂新手不建议碰。我一般建议第一次上手的人选 deepseek-llm-7b-chat 的原始权重。原因只有一条社区资料最全踩坑记录最多。用它在开源榜单上能查到各种 LoRA 微调案例参数照着抄都能跑通。等这条链路跑熟了再换 Coder 系列或更大的模型调整。还有两个概念要先分清base 版和 chat 版。base 版只做过预训练输出经常不成句需要你自己准备大量高质量的指令数据才能调出对话能力chat 版已经带上了通用对话能力你做的是“领域增强”——让它从只会说普通话变成会说你的行业话。绝大多数业务场景应该选 chat 版做底座除非你要做的是从零训练一个垂直领域生成模型且数据量极大那才考虑 base。模型权重下载有两个渠道HuggingFace 和 ModelScope。国内网络条件下 ModelScope 通常更稳下载命令如下pip install modelscope modelscope download --model deepseek-ai/deepseek-llm-7b-chat --local_dir ./models/deepseek-llm-7b-chat这里--local_dir指定权重落地目录省得下载完找半天文件。如果后续要换 HuggingFace用huggingface-cli download deepseek-ai/deepseek-llm-7b-chat --local-dir ./models/deepseek-llm-7b-chat即可。注意两个平台的目录名规则一致但国内直连 HuggingFace 经常断流下载到一半报错就换 ModelScope。2.2 显存焦虑先放一边LoRA 与 QLoRA 的内存账选完模型下一个问题是我的显卡跑得动吗这里有个经常被误解的点本地训练和本地推理的显存占用是两个量级。推理时 7B 模型用 4bit 量化只需 6GB 左右显存但训练时即使只训练 LoRA 参数也要把整个模型的梯度、优化器状态、激活值都留在显存里。不做任何优化时7B 模型的全量微调需要 70GB 以上这显然不现实。LoRA 把可训练参数量降到原来的 0.1% 以下但模型权重本身还是全精度加载7B 的 bf16 权重就要占 14GB。QLoRA 更进一步把底座权重用 4bit NF4 量化加载显存需求直接腰斩再腰斩。两种方案的区别和适配场景如下方案底座精度7B 训练显存约需适合情况LoRAbf16/fp1618~24GB有 24GB 以上显存追求训练稳定性QLoRA4bit NF410~14GB8GB 到 16GB 显存新手首选QLoRA 在 16GB 显存比如 RTX 4080 Laptop 或 4090 Laptop上能训练 7B 模型1080Ti 只有 11GB 显存建议退到 1.5B 或 3B 尺寸。这不是玄学是显存带宽和容量共同决定的硬约束硬上 7B 大概率第一轮训练就 OOM 翻车。2.3 环境搭建miniconda、CUDA、依赖版本一次装对环境问题比训练问题更磨人。我见过太多人卡在安装阶段torch 版本和 CUDA 不匹配跑起来报错说找不到_scaled_mmtransformers 版本太老加载模型时提示 key 对不上bitsandbytes 在 Windows 上配置不对4bit 量化加载直接崩掉。用 miniconda 管理环境是最稳的做法conda create -n ds-train python3.10 conda activate ds-train pip install torch2.1.2 --index-url https://download.pytorch.org/whl/cu121 pip install transformers4.38.2 datasets2.18.0 accelerate0.28.0 pip install peft0.10.0 bitsandbytes0.43.1 trl0.7.11几个关键点torch 2.1.2 对应 CUDA 12.1先跑nvidia-smi看驱动支持的 CUDA 版本驱动版本必须大于等于 12.1。bitsandbytes 0.43.1 是 Windows 和 Linux 都能稳定工作的版本新版在 Windows 上偶尔报No module named bitsandbytes。trl 做 SFT监督微调时封装了很多细节比裸写 Trainer 省事。装完后先跑一个快速验证确认 GPU 对 torch 可见python -c import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))输出True NVIDIA GeForce RTX ...才算环境就绪。如果输出False优先检查 torch 装的是不是 CPU 版——用pip list | grep torch看版本后缀有没有cu没有就重装一次。3. 数据集准备与处理决定微调质量的不是模型是数据3.1 训练集格式化从原始问答到 alpaca 与 sharegpt 两种模板很多人在网上找开源数据集下载解压后直接用结果训练出的模型前言不搭后语然后怪模型不行。根据我的实际经验80% 的微调翻车都出在数据格式上。deepseek 官方和社区微调主流用两种格式alpaca 和 sharegpt。alpaca 格式是最经典的单轮指令格式每条数据包含 instruction、input、output 三个字段适合做“给指令出结果”的场景比如文章分类、关键词抽取、实体识别这类单轮任务{ instruction: 判断这段文本的情感倾向是正面还是负面。, input: 这家餐厅的服务态度很差等了一个小时才上菜。, output: 负面 }sharegpt 格式则用于多轮对话场景conversations 数组里按 human 和 gpt 角色交替排列适合做客服机器人、对话助手这类需要多轮上下文的业务{ conversations: [ { from: human, value: 我最近总是失眠怎么办 }, { from: gpt, value: 先说说你最近的生活习惯吧比如作息时间和压力情况。 }, { from: human, value: 我一般凌晨两点才睡白天工作压力很大。 }, { from: gpt, value: 建议你先逐步提前入睡时间每天提前 15 分钟同时白天增加运动量。 } ] }不要混用两种格式。trl 的 SFTTrainer 对两种格式都支持但内部的对话模板组装逻辑不同混用会导致部分数据在训练时被跳过或截断。行业里做中医问答、电商客服场景的数据集几乎都是整理成这两类格式之一后清洗再喂进模型的。3.2 数据清洗与统计一份能直接喂给训练脚本的干净数据原始数据几乎不可能直接使用。以我从公开渠道整理中医问答数据的经验为例第一步是做去重、去空、去坏样本第二步是长度过滤——超过模型上下文窗口的截断短于几个字且没有实际信息量的删除第三步是标签检查多轮对话里每个 human 轮次后面必须跟着至少一个 gpt 轮次否则训练时模型会学到“有问无答”的坏习惯。清洗脚本我习惯用 pandas 写简单直观import json import pandas as pd # 读取原始 JSON 文件数据为 alpaca 格式 with open(raw_data.json, r, encodingutf-8) as f: data json.load(f) df pd.DataFrame(data) # 去掉 instruction 和 output 为空或纯空白的样本 df df[(df[instruction].str.strip() ! ) (df[output].str.strip() ! )] # 去掉 output 过长或过短的极端样本设定合理区间 df df[(df[output].str.len() 8) (df[output].str.len() 2000)] # 按 instruction 文本去重保留第一条 df df.drop_duplicates(subset[instruction]) # 统计清洗后的数据量和输出长度分布 print(f清洗后样本数: {len(df)}) print(df[output].str.len().describe()) # 导出为训练用的 JSONL 格式 df.to_json(train_data.jsonl, orientrecords, linesTrue, force_asciiFalse)force_asciiFalse很关键加了它中文字符才会原样写入文件否则全变成\uXXXX转义序列不仅肉眼没法检查训练时 tokenizer 处理起来也多一道无谓的解码开销。清洗时注意别把带条件的样本删掉有些指令本身带业务背景比如“如果患者是儿童剂量减半”这类样本恰恰是领域微调的精华。数据量参考单轮指令微调500 到 2000 条高质量样本就能看到明显变化多轮对话场景2000 到 5000 条比较合适。低于 500 条时模型容易过拟合学成“复读机”高于 5000 条时边际收益递减训练时间成本反而直线上升。3.3 训练集与验证集拆分固定随机种子别让验证集泄露进训练拆训练集和验证集看起来是小事但有个隐蔽的坑如果不固定随机种子每次拆分结果不同你甚至无法判断模型变好是因为数据质量提升还是因为运气好。更严重的问题是有些人在拆分前忘了打乱数据原始数据按业务来源分组排列导致训练集和验证集高度同质验证集上的指标虚高。推荐写法是用 sklearn 的train_test_split并显式固定种子from sklearn.model_selection import train_test_split with open(train_data.jsonl, r, encodingutf-8) as f: lines [json.loads(line) for line in f] # 按 95:5 拆分shuffleTrue 打乱random_state 固定为 42 train_data, eval_data train_test_split(lines, test_size0.05, shuffleTrue, random_state42) with open(train.json, w, encodingutf-8) as f: json.dump(train_data, f, ensure_asciiFalse, indent2) with open(eval.json, w, encodingutf-8) as f: json.dump(eval_data, f, ensure_asciiFalse, indent2) print(f训练集 {len(train_data)} 条验证集 {len(eval_data)} 条)知识点是验证集不参与梯度更新它只用于评估每个 epoch 结束后的 loss 和回答质量。5% 的占比在样本量小的时候够用如果总数据量超过 1 万条可以把验证集比例降到 3%。另外强烈建议把固定随机种子这件事写进训练脚本的配置里后面调参对比时才能保证结果可复现。4. LoRA 参数配置与训练实战从加载 4bit 基座到跑完第一个 epoch4.1 训练脚本的完整骨架基于 transformers 与 peft 的最小实现环境装好、数据备齐就该进入核心环节。下面这份脚本是我在实际做 deepseek 本地微调时精简出来的最小可运行版本使用 peft 和 transformers 原生 API避免过度封装导致问题难以排查import torch from datasets import load_dataset from transformers import ( AutoTokenizer, AutoModelForCausalLM, TrainingArguments, Trainer, DataCollatorForSeq2Seq ) from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training # 加载 4bit 量化配置QLoRA 的核心基础 from transformers import BitsAndBytesConfig bnb_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_quant_typenf4, bnb_4bit_use_double_quantTrue, bnb_4bit_compute_dtypetorch.bfloat16 ) # 加载 tokenizer 和模型device_mapauto 让 transformers 自动分配显存 model_name ./models/deepseek-llm-7b-chat tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained( model_name, quantization_configbnb_config, device_mapauto, trust_remote_codeTrue ) # 为 kbit 训练做准备冻结原模型并启用梯度检查点 model prepare_model_for_kbit_training(model) # 配置 LoRA只修改 q_proj 和 v_proj 两个投影层 lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, v_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) model get_peft_model(model, lora_config) model.print_trainable_parameters() # 加载 JSON 格式数据配对 tokenizer 和最大长度 dataset load_dataset(json, data_files{train: train.json, validation: eval.json}) def tokenize(examples): # 组装指令与输出为模型输入文本 texts [] for ins, out in zip(examples[instruction], examples[output]): text f### 指令:\n{ins}\n\n### 回答:\n{out}\n texts.append(text) tokenized tokenizer(texts, truncationTrue, max_length1024, paddingFalse) tokenized[labels] tokenized[input_ids].copy() return tokenized tokenized_data dataset.map(tokenize, batchedTrue) # 训练参数小批量 梯度累积适配 16GB 显存 training_args TrainingArguments( output_dir./checkpoints, per_device_train_batch_size2, per_device_eval_batch_size2, gradient_accumulation_steps8, learning_rate2e-4, num_train_epochs3, logging_steps50, eval_strategyepoch, save_strategyepoch, fp16True, report_tonone ) trainer Trainer( modelmodel, argstraining_args, train_datasettokenized_data[train], eval_datasettokenized_data[validation], data_collatorDataCollatorForSeq2Seq(tokenizer, paddingTrue) ) trainer.train()这个脚本里labels直接拷贝input_ids表示让模型预测全部 token——对单轮指令任务足够如果做多轮对话需要用 datacollator 的padding参数把输入和标签对齐。4.2 关键参数逐项拆解学习率、批量大小、序列长度怎么定LoRA 训练有几个参数几乎是决定成败的下面逐一说明。r是 LoRA 矩阵的秩决定注入低秩矩阵的容量。r8 是保守起步值r16 在数据量充足2000 条以上时表现更好r32 适合数据量很大或任务与预训练分布差异明显的场景。显存和效果之间要平衡r 翻倍显存占用大概增加 10% 左右但训练时间变化不明显。lora_alpha是缩放系数和 r 的比值控制在 1 到 2 之间比较稳妥。r16 配 lora_alpha32 是社区验证过最稳的组合之一。target_modules决定在哪些层注入 LoRA常见配置是[q_proj, v_proj]效果更激进一些的还会加[k_proj, o_proj, gate_proj, up_proj, down_proj]。后者效果可能更好但显存占用和过拟合风险同时上升新手先用 q 和 v 两层跑通。学习率在 LoRA 里的量级和全量微调完全不同。全量微调用 1e-5 到 5e-5LoRA 因为只更新极小部分参数学习率可以到 2e-4 到 5e-4。我踩过的坑是有人直接照搬全量微调的学习率结果训练了十几个小时 loss 纹丝不动一度以为显卡坏了其实就是学习率太小。批量大小和梯度累积是一对组合。显存有限时单卡 batch_size 只能到 2要凑够等效批量就需要梯度累积。上面脚本per_device_train_batch_size2配gradient_accumulation_steps8等效批量就是 16效果和 batch_size16 差不多但显存占用只是后者的八分之一。max_length决定每条训练样本的最大 token 长度deepseek 7B 的上下文窗口是 4096但训练时设 4096 会带来两个问题显存暴涨、训练速度大幅下降。多数业务问答样本实际长度在 512 token 以下设 1024 已经覆盖 95% 以上的情况。4.3 训练过程监控与中断恢复从 loss 曲线看模型的“健康状态”训练启动后不要干等着要看三样东西loss 曲线的走势、显存占用率、日志里有没有警告。第一loss 是否在持续下降。理想情况下第一个 epoch 结束时 loss 应该比初始低 20% 以上。如果 loss 几乎平着走多半是学习率太低如果 loss 降到某个值之后反而上升多半是过拟合开始这时候应该提前停止或调小学习率。第二显存是否稳定。用watch -n 1 nvidia-smi实时查看显存和利用率。显存占用超过 90% 时容易 OOM要立刻调per_device_train_batch_size到 1 或者把max_length降到 512。利用率如果一直低于 50%检查 CPU 是否成了瓶颈——数据预处理线程太少也会造成 GPU 空转。第三训练中断恢复。训练到一半断电或 OOM 崩溃是家常便饭TrainingArguments里设好save_strategyepoch后每轮结束会在./checkpoints下留下检查点。恢复训练只需在Trainer初始化时加一行trainer Trainer( modelmodel, argstraining_args, train_datasettokenized_data[train], eval_datasettokenized_data[validation], data_collatorDataCollatorForSeq2Seq(tokenizer, paddingTrue) ) trainer.train(resume_from_checkpointTrue)resume_from_checkpointTrue会自动找到最近的检查点继续训练省下的不是钱是重头再来的一天时间。中断恢复后建议再观察一个 logging_steps 的 loss确认数值在正常范围——检查点保存和加载之间的微小版本差异偶尔会带来 loss 抖动的现象属于正常情况跑几步就平复了。5. 常见问题与避坑显存 OOM、中文乱码、复读机、合并失败5.1 显存 OOM现象、原因、一条命令定位训练跑了几分钟报CUDA out of memory这是新手遇到最多的崩溃。绝大多数情况不是显卡真的不够而是配置里有三处显存杀手max_length 太大、batch_size 太大、没有开启 gradient_checkpointing。解决路径按优先级来。先把序列长度砍到 512如果数据结构不允许至少别超过 1024再把per_device_train_batch_size从 2 降到 1配合梯度累积补回等效批量。最后启用梯度检查点在TrainingArguments里设置gradient_checkpointingTrue这能把激活值占用的显存降低 60% 左右代价是训练速度慢 20% 上下。定位显存去向有个笨办法但很有效训练开始前用torch.cuda.mem_get_info()打印空闲显存和已占用显存然后逐条注释掉配置项看哪一项改动对显存影响最大。这不是玄学是排查问题最直接的二分法。5.2 中文输出乱码与 tokenizer 问题模型学会了但“说不了人话”训练完成后测试模型输出的中文大面积乱码或者只有规律性重复字符这个坑我见得太多了原因基本都在 tokenizer 上。deepseek 的 tokenizer 是基于字节级的 BPE对中文的切分方式和其他模型不同。如果你用了和模型不匹配的 tokenizer微调后 embedding 和语言模型的输出对不上就会生成乱码。检查办法很简单加载模型后先跑一段原始权重推理看输出是否正常输出正常再跑微调后的权重。问题出在训练阶段的话多半是数据集文字编码有问题——CSV 文件用了 GBK 编码但用 UTF-8 读取中文字符在 tokenize 前就已经损坏。解决路径是这样训练前做一次 tokenizer 的编码测试把一条中文样本 tokenize 后再 decode 回文本确认内容一致不一致就检查文件编码统一转成 UTF-8再不行就换官方 tokenizer 重新加载模型。5.3 模型变成复读机loss 降了输出却一直在重复loss 正常下降但生成结果永远在重复同一句话这是过拟合的典型表现。通常发生在三处数据量太小低于 300 条、epoch 数太多、学习率偏高导致权重更新过于激进。解决思路按顺序试先减 epoch 到 1 或 2验证集 loss 开始上升就停止再降低学习率到 1e-4最后扩充数据或增加数据多样性。还有一个容易被忽略的点生成参数里的repetition_penalty推理时调高到 1.1 到 1.2能压制重复但治标不治本数据问题不解决惩罚系数再高也白搭。5.4 合并 LoRA 权重导出失败transformers 版本不一致与路径陷阱训练完成后的一个高频翻车点是合并权重。用merge_and_unload()时报KeyError或者加载合并后的模型报形状不匹配八成是训练和合并时 transformers 版本不一致。训练时是 4.38合并时用了 4.40LoRA 权重的 key 映射规则变了自然对不上。我现在的习惯是把训练和合并写进同一个脚本用同一个环境执行彻底避开版本问题。另一个常见错误是save_pretrained后直接把整个目录复制到别处用但 LoRA adapter 的配置文件adapter_config.json里记录的是训练时的 base_model_name_or_path换了路径后加载会找不到基座。这个文件要在导出时改掉或者直接把合并后的完整模型保存merged_model model.merge_and_unload() merged_model.save_pretrained(./merged_model, safe_serializationTrue) tokenizer.save_pretrained(./merged_model)safe_serializationTrue用 safetensors 格式保存比 pytorch_model.bin 更安全加载时也少踩权重文件被截断的坑。合并前记得先确认 GPU 显存能容纳合并后的全精度模型7B 的 bf16 权重需要 14GB 空间显存不够就在加载时用low_cpu_mem_usageTrue。5.5 多卡训练与 vLLM 部署的隐形矛盾训练时显存分布与推理时的差异有的人训完模型后用 vLLM 部署发现显存需求比训练时还高怀疑自己训练了个假模型。其实训练和推理的显存计算逻辑完全不同。训练时 4bit 量化加载底座权重只有 3.5GB 左右LoRA 参数几十 MB推理时如果用 vLLM 加载全精度合并权重7B 模型直接占 14GB。如果要省显存合并后用 llama.cpp 转成 GGUF 做 4bit 量化显存需求能压到 6GB 以内。如果你只有一台多卡机器想用 accelerate 或 deepspeed 多卡训练新手阶段我不建议碰。多卡引入通信开销小模型训练速度反而可能不如单卡deepseek 这类 7B 以下的模型单卡冷启动到收敛也就几个小时多卡省的时间还不如调试多卡环境的时间长。等你真要训练 14B 以上的模型再考虑也不迟。6. 从微调到可用评估效果、合并导出、部署验证的完整闭环训练结束时看到 loss 降下来只是完成了第一步。我从血泪经验里学到的习惯是任何模型不经过验证闭环就不要宣布“训完了”。这个闭环分三层能力验证、格式导出、推理对比。能力验证最简单也最容易被跳过。准备 20 到 30 条领域测试题覆盖训练数据里出现过的场景和没出现过的场景逐个喂给合并后的模型记录回答是否准确、是否完整、是否带幻觉。这里有个技巧测试题不要全来自训练集至少一半是没见过的题这样才能看出模型是否真正学到了领域知识还是只会背诵。如果是多轮客服场景还要测试连续对话的上下文保持能力。格式导出按照业务需求分流。如果要用 llama.cpp 或 ollama 在本地跑需要把合并模型转成 GGUF 格式git clone https://github.com/ggerganov/llama.cpp cd llama.cpp python convert_hf_to_gguf.py ./merged_model --outfile deepseek-llm-7b-chat.gguf --outtype q8_0--outtype q8_0是 8bit 量化质量损失极小如果要更省显存用q4_k_m。转换完成后用 ollama 的 Modelfile 创建一个本地模型文件ollama create mymodel -f Modelfile一条命令就能在本地跑起来。如果你想用 vLLM 做高并发服务保留 transformers 格式即可vLLM 直接支持加载 safetensors 权重。最后做一步新旧对比微调前的原始模型回答同一题集微调后的模型再答一遍把两组答案并列记录下来。这个对比的意义在于很多微调是“按下葫芦浮起瓢”——领域能力提升但通用对话能力下降如果你发现通用能力明显退化说明训练数据里领域样本比例过高超过 80%需要混入一批通用对话数据重新训练。我现在每完成一次微调都会把测试题集、参数配置、loss 曲线截图、新旧回答对比归档成一个目录下次调参直接对比。这个习惯让我避免了很多返工也希望帮到你。本文还有配套的精品资源点击获取 DeepSeek本地微调实战：从LoRA配置到模型合并部署
简介面向AI和大数据零基础学习者的DeepSeek本地模型训练实操指南尤其适合仅掌握JavaScript或对Python只有初步了解的学习者。资源包为单个PDF文件压缩后约1.93MB内部以完整步骤说明从Ollama部署到数据预处理的每一个环节。指南首先介绍通过Ollama在本地安装DeepSeek模型并说明模型文件存放路径再讲解准备txt训练样本、安装Python及torch/transformers/datasets依赖库的关键细节同时解读安装过程中的下载进度与等待时间。后续内容推荐VSCode、PyCharm、Jupyter Notebook等编辑器给出fine_tune_deepseek文件夹与脚本文件的目录组织方式以及使用transformers加载本地模型与分词器的代码示例同时演示数据预处理和运行确认方法。对完全不具备深度学习背景的初学者而言这份文档能帮助跨越环境配置障碍按步骤完成DeepSeek本地模型的初步微调目前已有269人学习下载。1. 本地训练 deepseek从 API 调用到调出自己的模型这一步到底卡在哪做 AI 应用的人大概都经历过这个场景调 deepseek 的 API 跑通了一版原型效果不错但一算账就头疼——对话多的业务每天烧掉几十上百块数据还得全部过一遍外部接口稍微敏感一点的场景根本不敢用。于是“deepseek 本地模型训练”这个词就成了检索热门大家想知道的是同一件事能不能在自有的显卡上把开源的 deepseek 权重拿来微调成自己的模型效果不掉队成本还能控住。这里要先说破一个认知误区本地训练 deepseek 不是从头预训练那些动辄几千张卡、几十万条文本的活儿跟普通人没关系。绝大多数从业者做的是“参数高效微调”也就是 LoRA 或 QLoRA——冻结原模型只训练一小部分注入的低秩矩阵用一张消费级显卡就能跑。8GB 显存能动 1.5B 参数的小模型24GB 显存可以够到 7B 甚至 14B。做完之后把 LoRA 权重合并回原模型再导出 GGUF 格式跑本地推理模型就是自己的了。这篇只讲一件事从下载权重、准备数据集、跑通训练脚本到把模型合并导出并验证效果。适合手里有 8GB 以上显存、想私有化部署或定制领域模型的开发者阅读也适合刚入门大模型微调、想找个完整链路练手的人照着做。2. 选型与准备本地训练 deepseek 该用哪个版本环境怎么搭2.1 版本矩阵先搞清楚你该训练哪个 deepseekdeepseek 开源出来的模型不是一个而是一族。先从最基础的了解DeepSeek LLM 有 7B 和 67B 两个尺寸7B 是本地训练最常用的底座DeepSeek-Coder 系列在代码任务上更强如果你要做代码补全或仓库级理解选它而不是通用版DeepSeek-MoE 是混合专家架构16B 激活参数但总参数上百亿推理效率高但本地训练时 LoRA 注入的 target_modules 选择和显存占用都更复杂新手不建议碰。我一般建议第一次上手的人选 deepseek-llm-7b-chat 的原始权重。原因只有一条社区资料最全踩坑记录最多。用它在开源榜单上能查到各种 LoRA 微调案例参数照着抄都能跑通。等这条链路跑熟了再换 Coder 系列或更大的模型调整。还有两个概念要先分清base 版和 chat 版。base 版只做过预训练输出经常不成句需要你自己准备大量高质量的指令数据才能调出对话能力chat 版已经带上了通用对话能力你做的是“领域增强”——让它从只会说普通话变成会说你的行业话。绝大多数业务场景应该选 chat 版做底座除非你要做的是从零训练一个垂直领域生成模型且数据量极大那才考虑 base。模型权重下载有两个渠道HuggingFace 和 ModelScope。国内网络条件下 ModelScope 通常更稳下载命令如下pip install modelscope modelscope download --model deepseek-ai/deepseek-llm-7b-chat --local_dir ./models/deepseek-llm-7b-chat这里--local_dir指定权重落地目录省得下载完找半天文件。如果后续要换 HuggingFace用huggingface-cli download deepseek-ai/deepseek-llm-7b-chat --local-dir ./models/deepseek-llm-7b-chat即可。注意两个平台的目录名规则一致但国内直连 HuggingFace 经常断流下载到一半报错就换 ModelScope。2.2 显存焦虑先放一边LoRA 与 QLoRA 的内存账选完模型下一个问题是我的显卡跑得动吗这里有个经常被误解的点本地训练和本地推理的显存占用是两个量级。推理时 7B 模型用 4bit 量化只需 6GB 左右显存但训练时即使只训练 LoRA 参数也要把整个模型的梯度、优化器状态、激活值都留在显存里。不做任何优化时7B 模型的全量微调需要 70GB 以上这显然不现实。LoRA 把可训练参数量降到原来的 0.1% 以下但模型权重本身还是全精度加载7B 的 bf16 权重就要占 14GB。QLoRA 更进一步把底座权重用 4bit NF4 量化加载显存需求直接腰斩再腰斩。两种方案的区别和适配场景如下方案底座精度7B 训练显存约需适合情况LoRAbf16/fp1618~24GB有 24GB 以上显存追求训练稳定性QLoRA4bit NF410~14GB8GB 到 16GB 显存新手首选QLoRA 在 16GB 显存比如 RTX 4080 Laptop 或 4090 Laptop上能训练 7B 模型1080Ti 只有 11GB 显存建议退到 1.5B 或 3B 尺寸。这不是玄学是显存带宽和容量共同决定的硬约束硬上 7B 大概率第一轮训练就 OOM 翻车。2.3 环境搭建miniconda、CUDA、依赖版本一次装对环境问题比训练问题更磨人。我见过太多人卡在安装阶段torch 版本和 CUDA 不匹配跑起来报错说找不到_scaled_mmtransformers 版本太老加载模型时提示 key 对不上bitsandbytes 在 Windows 上配置不对4bit 量化加载直接崩掉。用 miniconda 管理环境是最稳的做法conda create -n ds-train python3.10 conda activate ds-train pip install torch2.1.2 --index-url https://download.pytorch.org/whl/cu121 pip install transformers4.38.2 datasets2.18.0 accelerate0.28.0 pip install peft0.10.0 bitsandbytes0.43.1 trl0.7.11几个关键点torch 2.1.2 对应 CUDA 12.1先跑nvidia-smi看驱动支持的 CUDA 版本驱动版本必须大于等于 12.1。bitsandbytes 0.43.1 是 Windows 和 Linux 都能稳定工作的版本新版在 Windows 上偶尔报No module named bitsandbytes。trl 做 SFT监督微调时封装了很多细节比裸写 Trainer 省事。装完后先跑一个快速验证确认 GPU 对 torch 可见python -c import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))输出True NVIDIA GeForce RTX ...才算环境就绪。如果输出False优先检查 torch 装的是不是 CPU 版——用pip list | grep torch看版本后缀有没有cu没有就重装一次。3. 数据集准备与处理决定微调质量的不是模型是数据3.1 训练集格式化从原始问答到 alpaca 与 sharegpt 两种模板很多人在网上找开源数据集下载解压后直接用结果训练出的模型前言不搭后语然后怪模型不行。根据我的实际经验80% 的微调翻车都出在数据格式上。deepseek 官方和社区微调主流用两种格式alpaca 和 sharegpt。alpaca 格式是最经典的单轮指令格式每条数据包含 instruction、input、output 三个字段适合做“给指令出结果”的场景比如文章分类、关键词抽取、实体识别这类单轮任务{ instruction: 判断这段文本的情感倾向是正面还是负面。, input: 这家餐厅的服务态度很差等了一个小时才上菜。, output: 负面 }sharegpt 格式则用于多轮对话场景conversations 数组里按 human 和 gpt 角色交替排列适合做客服机器人、对话助手这类需要多轮上下文的业务{ conversations: [ { from: human, value: 我最近总是失眠怎么办 }, { from: gpt, value: 先说说你最近的生活习惯吧比如作息时间和压力情况。 }, { from: human, value: 我一般凌晨两点才睡白天工作压力很大。 }, { from: gpt, value: 建议你先逐步提前入睡时间每天提前 15 分钟同时白天增加运动量。 } ] }不要混用两种格式。trl 的 SFTTrainer 对两种格式都支持但内部的对话模板组装逻辑不同混用会导致部分数据在训练时被跳过或截断。行业里做中医问答、电商客服场景的数据集几乎都是整理成这两类格式之一后清洗再喂进模型的。3.2 数据清洗与统计一份能直接喂给训练脚本的干净数据原始数据几乎不可能直接使用。以我从公开渠道整理中医问答数据的经验为例第一步是做去重、去空、去坏样本第二步是长度过滤——超过模型上下文窗口的截断短于几个字且没有实际信息量的删除第三步是标签检查多轮对话里每个 human 轮次后面必须跟着至少一个 gpt 轮次否则训练时模型会学到“有问无答”的坏习惯。清洗脚本我习惯用 pandas 写简单直观import json import pandas as pd # 读取原始 JSON 文件数据为 alpaca 格式 with open(raw_data.json, r, encodingutf-8) as f: data json.load(f) df pd.DataFrame(data) # 去掉 instruction 和 output 为空或纯空白的样本 df df[(df[instruction].str.strip() ! ) (df[output].str.strip() ! )] # 去掉 output 过长或过短的极端样本设定合理区间 df df[(df[output].str.len() 8) (df[output].str.len() 2000)] # 按 instruction 文本去重保留第一条 df df.drop_duplicates(subset[instruction]) # 统计清洗后的数据量和输出长度分布 print(f清洗后样本数: {len(df)}) print(df[output].str.len().describe()) # 导出为训练用的 JSONL 格式 df.to_json(train_data.jsonl, orientrecords, linesTrue, force_asciiFalse)force_asciiFalse很关键加了它中文字符才会原样写入文件否则全变成\uXXXX转义序列不仅肉眼没法检查训练时 tokenizer 处理起来也多一道无谓的解码开销。清洗时注意别把带条件的样本删掉有些指令本身带业务背景比如“如果患者是儿童剂量减半”这类样本恰恰是领域微调的精华。数据量参考单轮指令微调500 到 2000 条高质量样本就能看到明显变化多轮对话场景2000 到 5000 条比较合适。低于 500 条时模型容易过拟合学成“复读机”高于 5000 条时边际收益递减训练时间成本反而直线上升。3.3 训练集与验证集拆分固定随机种子别让验证集泄露进训练拆训练集和验证集看起来是小事但有个隐蔽的坑如果不固定随机种子每次拆分结果不同你甚至无法判断模型变好是因为数据质量提升还是因为运气好。更严重的问题是有些人在拆分前忘了打乱数据原始数据按业务来源分组排列导致训练集和验证集高度同质验证集上的指标虚高。推荐写法是用 sklearn 的train_test_split并显式固定种子from sklearn.model_selection import train_test_split with open(train_data.jsonl, r, encodingutf-8) as f: lines [json.loads(line) for line in f] # 按 95:5 拆分shuffleTrue 打乱random_state 固定为 42 train_data, eval_data train_test_split(lines, test_size0.05, shuffleTrue, random_state42) with open(train.json, w, encodingutf-8) as f: json.dump(train_data, f, ensure_asciiFalse, indent2) with open(eval.json, w, encodingutf-8) as f: json.dump(eval_data, f, ensure_asciiFalse, indent2) print(f训练集 {len(train_data)} 条验证集 {len(eval_data)} 条)知识点是验证集不参与梯度更新它只用于评估每个 epoch 结束后的 loss 和回答质量。5% 的占比在样本量小的时候够用如果总数据量超过 1 万条可以把验证集比例降到 3%。另外强烈建议把固定随机种子这件事写进训练脚本的配置里后面调参对比时才能保证结果可复现。4. LoRA 参数配置与训练实战从加载 4bit 基座到跑完第一个 epoch4.1 训练脚本的完整骨架基于 transformers 与 peft 的最小实现环境装好、数据备齐就该进入核心环节。下面这份脚本是我在实际做 deepseek 本地微调时精简出来的最小可运行版本使用 peft 和 transformers 原生 API避免过度封装导致问题难以排查import torch from datasets import load_dataset from transformers import ( AutoTokenizer, AutoModelForCausalLM, TrainingArguments, Trainer, DataCollatorForSeq2Seq ) from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training # 加载 4bit 量化配置QLoRA 的核心基础 from transformers import BitsAndBytesConfig bnb_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_quant_typenf4, bnb_4bit_use_double_quantTrue, bnb_4bit_compute_dtypetorch.bfloat16 ) # 加载 tokenizer 和模型device_mapauto 让 transformers 自动分配显存 model_name ./models/deepseek-llm-7b-chat tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained( model_name, quantization_configbnb_config, device_mapauto, trust_remote_codeTrue ) # 为 kbit 训练做准备冻结原模型并启用梯度检查点 model prepare_model_for_kbit_training(model) # 配置 LoRA只修改 q_proj 和 v_proj 两个投影层 lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, v_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) model get_peft_model(model, lora_config) model.print_trainable_parameters() # 加载 JSON 格式数据配对 tokenizer 和最大长度 dataset load_dataset(json, data_files{train: train.json, validation: eval.json}) def tokenize(examples): # 组装指令与输出为模型输入文本 texts [] for ins, out in zip(examples[instruction], examples[output]): text f### 指令:\n{ins}\n\n### 回答:\n{out}\n texts.append(text) tokenized tokenizer(texts, truncationTrue, max_length1024, paddingFalse) tokenized[labels] tokenized[input_ids].copy() return tokenized tokenized_data dataset.map(tokenize, batchedTrue) # 训练参数小批量 梯度累积适配 16GB 显存 training_args TrainingArguments( output_dir./checkpoints, per_device_train_batch_size2, per_device_eval_batch_size2, gradient_accumulation_steps8, learning_rate2e-4, num_train_epochs3, logging_steps50, eval_strategyepoch, save_strategyepoch, fp16True, report_tonone ) trainer Trainer( modelmodel, argstraining_args, train_datasettokenized_data[train], eval_datasettokenized_data[validation], data_collatorDataCollatorForSeq2Seq(tokenizer, paddingTrue) ) trainer.train()这个脚本里labels直接拷贝input_ids表示让模型预测全部 token——对单轮指令任务足够如果做多轮对话需要用 datacollator 的padding参数把输入和标签对齐。4.2 关键参数逐项拆解学习率、批量大小、序列长度怎么定LoRA 训练有几个参数几乎是决定成败的下面逐一说明。r是 LoRA 矩阵的秩决定注入低秩矩阵的容量。r8 是保守起步值r16 在数据量充足2000 条以上时表现更好r32 适合数据量很大或任务与预训练分布差异明显的场景。显存和效果之间要平衡r 翻倍显存占用大概增加 10% 左右但训练时间变化不明显。lora_alpha是缩放系数和 r 的比值控制在 1 到 2 之间比较稳妥。r16 配 lora_alpha32 是社区验证过最稳的组合之一。target_modules决定在哪些层注入 LoRA常见配置是[q_proj, v_proj]效果更激进一些的还会加[k_proj, o_proj, gate_proj, up_proj, down_proj]。后者效果可能更好但显存占用和过拟合风险同时上升新手先用 q 和 v 两层跑通。学习率在 LoRA 里的量级和全量微调完全不同。全量微调用 1e-5 到 5e-5LoRA 因为只更新极小部分参数学习率可以到 2e-4 到 5e-4。我踩过的坑是有人直接照搬全量微调的学习率结果训练了十几个小时 loss 纹丝不动一度以为显卡坏了其实就是学习率太小。批量大小和梯度累积是一对组合。显存有限时单卡 batch_size 只能到 2要凑够等效批量就需要梯度累积。上面脚本per_device_train_batch_size2配gradient_accumulation_steps8等效批量就是 16效果和 batch_size16 差不多但显存占用只是后者的八分之一。max_length决定每条训练样本的最大 token 长度deepseek 7B 的上下文窗口是 4096但训练时设 4096 会带来两个问题显存暴涨、训练速度大幅下降。多数业务问答样本实际长度在 512 token 以下设 1024 已经覆盖 95% 以上的情况。4.3 训练过程监控与中断恢复从 loss 曲线看模型的“健康状态”训练启动后不要干等着要看三样东西loss 曲线的走势、显存占用率、日志里有没有警告。第一loss 是否在持续下降。理想情况下第一个 epoch 结束时 loss 应该比初始低 20% 以上。如果 loss 几乎平着走多半是学习率太低如果 loss 降到某个值之后反而上升多半是过拟合开始这时候应该提前停止或调小学习率。第二显存是否稳定。用watch -n 1 nvidia-smi实时查看显存和利用率。显存占用超过 90% 时容易 OOM要立刻调per_device_train_batch_size到 1 或者把max_length降到 512。利用率如果一直低于 50%检查 CPU 是否成了瓶颈——数据预处理线程太少也会造成 GPU 空转。第三训练中断恢复。训练到一半断电或 OOM 崩溃是家常便饭TrainingArguments里设好save_strategyepoch后每轮结束会在./checkpoints下留下检查点。恢复训练只需在Trainer初始化时加一行trainer Trainer( modelmodel, argstraining_args, train_datasettokenized_data[train], eval_datasettokenized_data[validation], data_collatorDataCollatorForSeq2Seq(tokenizer, paddingTrue) ) trainer.train(resume_from_checkpointTrue)resume_from_checkpointTrue会自动找到最近的检查点继续训练省下的不是钱是重头再来的一天时间。中断恢复后建议再观察一个 logging_steps 的 loss确认数值在正常范围——检查点保存和加载之间的微小版本差异偶尔会带来 loss 抖动的现象属于正常情况跑几步就平复了。5. 常见问题与避坑显存 OOM、中文乱码、复读机、合并失败5.1 显存 OOM现象、原因、一条命令定位训练跑了几分钟报CUDA out of memory这是新手遇到最多的崩溃。绝大多数情况不是显卡真的不够而是配置里有三处显存杀手max_length 太大、batch_size 太大、没有开启 gradient_checkpointing。解决路径按优先级来。先把序列长度砍到 512如果数据结构不允许至少别超过 1024再把per_device_train_batch_size从 2 降到 1配合梯度累积补回等效批量。最后启用梯度检查点在TrainingArguments里设置gradient_checkpointingTrue这能把激活值占用的显存降低 60% 左右代价是训练速度慢 20% 上下。定位显存去向有个笨办法但很有效训练开始前用torch.cuda.mem_get_info()打印空闲显存和已占用显存然后逐条注释掉配置项看哪一项改动对显存影响最大。这不是玄学是排查问题最直接的二分法。5.2 中文输出乱码与 tokenizer 问题模型学会了但“说不了人话”训练完成后测试模型输出的中文大面积乱码或者只有规律性重复字符这个坑我见得太多了原因基本都在 tokenizer 上。deepseek 的 tokenizer 是基于字节级的 BPE对中文的切分方式和其他模型不同。如果你用了和模型不匹配的 tokenizer微调后 embedding 和语言模型的输出对不上就会生成乱码。检查办法很简单加载模型后先跑一段原始权重推理看输出是否正常输出正常再跑微调后的权重。问题出在训练阶段的话多半是数据集文字编码有问题——CSV 文件用了 GBK 编码但用 UTF-8 读取中文字符在 tokenize 前就已经损坏。解决路径是这样训练前做一次 tokenizer 的编码测试把一条中文样本 tokenize 后再 decode 回文本确认内容一致不一致就检查文件编码统一转成 UTF-8再不行就换官方 tokenizer 重新加载模型。5.3 模型变成复读机loss 降了输出却一直在重复loss 正常下降但生成结果永远在重复同一句话这是过拟合的典型表现。通常发生在三处数据量太小低于 300 条、epoch 数太多、学习率偏高导致权重更新过于激进。解决思路按顺序试先减 epoch 到 1 或 2验证集 loss 开始上升就停止再降低学习率到 1e-4最后扩充数据或增加数据多样性。还有一个容易被忽略的点生成参数里的repetition_penalty推理时调高到 1.1 到 1.2能压制重复但治标不治本数据问题不解决惩罚系数再高也白搭。5.4 合并 LoRA 权重导出失败transformers 版本不一致与路径陷阱训练完成后的一个高频翻车点是合并权重。用merge_and_unload()时报KeyError或者加载合并后的模型报形状不匹配八成是训练和合并时 transformers 版本不一致。训练时是 4.38合并时用了 4.40LoRA 权重的 key 映射规则变了自然对不上。我现在的习惯是把训练和合并写进同一个脚本用同一个环境执行彻底避开版本问题。另一个常见错误是save_pretrained后直接把整个目录复制到别处用但 LoRA adapter 的配置文件adapter_config.json里记录的是训练时的 base_model_name_or_path换了路径后加载会找不到基座。这个文件要在导出时改掉或者直接把合并后的完整模型保存merged_model model.merge_and_unload() merged_model.save_pretrained(./merged_model, safe_serializationTrue) tokenizer.save_pretrained(./merged_model)safe_serializationTrue用 safetensors 格式保存比 pytorch_model.bin 更安全加载时也少踩权重文件被截断的坑。合并前记得先确认 GPU 显存能容纳合并后的全精度模型7B 的 bf16 权重需要 14GB 空间显存不够就在加载时用low_cpu_mem_usageTrue。5.5 多卡训练与 vLLM 部署的隐形矛盾训练时显存分布与推理时的差异有的人训完模型后用 vLLM 部署发现显存需求比训练时还高怀疑自己训练了个假模型。其实训练和推理的显存计算逻辑完全不同。训练时 4bit 量化加载底座权重只有 3.5GB 左右LoRA 参数几十 MB推理时如果用 vLLM 加载全精度合并权重7B 模型直接占 14GB。如果要省显存合并后用 llama.cpp 转成 GGUF 做 4bit 量化显存需求能压到 6GB 以内。如果你只有一台多卡机器想用 accelerate 或 deepspeed 多卡训练新手阶段我不建议碰。多卡引入通信开销小模型训练速度反而可能不如单卡deepseek 这类 7B 以下的模型单卡冷启动到收敛也就几个小时多卡省的时间还不如调试多卡环境的时间长。等你真要训练 14B 以上的模型再考虑也不迟。6. 从微调到可用评估效果、合并导出、部署验证的完整闭环训练结束时看到 loss 降下来只是完成了第一步。我从血泪经验里学到的习惯是任何模型不经过验证闭环就不要宣布“训完了”。这个闭环分三层能力验证、格式导出、推理对比。能力验证最简单也最容易被跳过。准备 20 到 30 条领域测试题覆盖训练数据里出现过的场景和没出现过的场景逐个喂给合并后的模型记录回答是否准确、是否完整、是否带幻觉。这里有个技巧测试题不要全来自训练集至少一半是没见过的题这样才能看出模型是否真正学到了领域知识还是只会背诵。如果是多轮客服场景还要测试连续对话的上下文保持能力。格式导出按照业务需求分流。如果要用 llama.cpp 或 ollama 在本地跑需要把合并模型转成 GGUF 格式git clone https://github.com/ggerganov/llama.cpp cd llama.cpp python convert_hf_to_gguf.py ./merged_model --outfile deepseek-llm-7b-chat.gguf --outtype q8_0--outtype q8_0是 8bit 量化质量损失极小如果要更省显存用q4_k_m。转换完成后用 ollama 的 Modelfile 创建一个本地模型文件ollama create mymodel -f Modelfile一条命令就能在本地跑起来。如果你想用 vLLM 做高并发服务保留 transformers 格式即可vLLM 直接支持加载 safetensors 权重。最后做一步新旧对比微调前的原始模型回答同一题集微调后的模型再答一遍把两组答案并列记录下来。这个对比的意义在于很多微调是“按下葫芦浮起瓢”——领域能力提升但通用对话能力下降如果你发现通用能力明显退化说明训练数据里领域样本比例过高超过 80%需要混入一批通用对话数据重新训练。我现在每完成一次微调都会把测试题集、参数配置、loss 曲线截图、新旧回答对比归档成一个目录下次调参直接对比。这个习惯让我避免了很多返工也希望帮到你。本文还有配套的精品资源点击获取