企业官网建设流程全解析

简介：面向AI算法工程师与大模型学习者的DeepSeek全流程实操指南，以231页PDF系统拆解从预训练到微调、量化的完整技术链路。核心覆盖分层预训练、Parameter-Efficient融合微调、蒸馏模型低比特量化等关键环节，并结合工程场景给出数据体系构建、算力规划、超参调优、分布式训练等操作要点。压缩包内为单个PDF文件，约11.62MB，文档共231页、50个大章节，支持目录跳转与书签大纲快速定位，内容完整无异常。目前已有333人学习/下载，适合需要系统掌握DeepSeek全流程实操能力的读者。文档前19章详细讲解技术生态、预训练数据筛选与清洗、checkpoint管理、监控指标搭建、数据标注规范与工具、分布式训练架构、过拟合抑制、批次动态采样、学习率调度、硬件优化等内容，后续章节进一步展开Parameter-Efficient融合微调与蒸馏模型低比特量化全解析，可对照目录完成逐项演练与查漏补缺。

1. DeepSeek全流程：为什么预训练、微调、量化必须串起来改

我一开始也踩过坑：拿到开源DeepSeek模型的权重，第一反应就是全量微调，几十张卡跑了一周，结果领域任务提升不明显，通用对话能力反而明显退化。后来把思路换成“先分层干预预训练，再做Parameter-Efficient融合微调，最后蒸馏量化”，单卡也能跑通，效果反而稳定很多。原因在于这三个步骤不是孤立的：预训练决定知识边界，微调决定任务适应，蒸馏量化决定最终能否低成本上线。

这条链路对想要把DeepSeek落到私有数据或业务场景的工程师来说，价值在于每一步都有清晰的取舍。预训练阶段用分层数据教会模型基础知识，微调阶段用最小的可训练参数把领域技能装进去，蒸馏量化把模型压缩到普通GPU卡能跑的体积。下面的章节按操作顺序展开，每一阶段都会给到参数、代码和验证方法，不靠玄学。

2. 分层预训练实操：从数据配比到分段训练的参数设计

2.1 分层预训练的三个含义，以及你该选择哪种

在DeepSeek这个规模的模型上，从头训练需要的算力不是大多数团队能承担的。实际项目里说的“分层预训练”，多数是指继续预训练阶段的三种分层策略：数据分层、层学习率分层、训练阶段分层。

数据分层的意思是让模型先学通用文本，再逐步引入代码、数学、领域文档，而不是把数据一次性混起来喂进去。这样做的好处是收敛更稳：早期全是低噪声的通用语料，模型先把词法、句法和基本知识固化下来；后期引入垂直语料，在已有知识上叠加，不容易产生灾难性遗忘。层学习率分层则针对Transformer的结构特点，底层主要负责词法和局部语法，更新步长要小；高层负责语义和推理，可以给更大步长。训练阶段分层则是先短上下文稳定训练，再拉长上下文继续训练，降低显存峰值和训练初期的发散概率。

如果你的领域语料不足10GB，其实不需要单独做预训练阶段，直接跳到下一章的PEFT微调更划算。但如果是做行业大模型，语料在几十GB以上，我建议至少做数据分层和阶段分层。层学习率分层在中小规模训练上收益不一定明显，但它能有效缓解微调阶段旧知识被覆盖的问题，后面给到参数表可以直接抄。

2.2 用Trainer实现分阶段预训练的最小脚本

下面以DeepSeek的开源7B权重为例，给出一个可以在单张A100上运行的继续预训练脚本。数据文件是JSONL格式，每行一条{"text": "..."}，先用通用中文网页数据跑第一阶段。

# stage1_continue_pretrain.py from transformers import AutoModelForCausalLM, AutoTokenizer, Trainer, TrainingArguments from datasets import load_dataset model_name = "deepseek-ai/deepseek-llm-7b-base" model = AutoModelForCausalLM.from_pretrained(model_name) tokenizer = AutoTokenizer.from_pretrained(model_name) tokenizer.pad_token = tokenizer.eos_token def tokenize_fn(batch): return tokenizer(batch["text"], truncation=True, max_length=4096) dataset = load_dataset("json", data_files="web.jsonl") dataset = dataset.map(tokenize_fn, batched=True, remove_columns=["text"]) args = TrainingArguments( output_dir="./ckpt-st1", per_device_train_batch_size=1, gradient_accumulation_steps=8, learning_rate=2e-4, lr_scheduler_type="cosine", warmup_ratio=0.03, num_train_epochs=1, save_strategy="steps", save_steps=500, logging_steps=50, fp16=True, ) trainer = Trainer(model=model, args=args, train_dataset=dataset["train"]) trainer.train()

per_device_train_batch_size=1配合gradient_accumulation_steps=8，等效batch size就是8，这是7B模型在单卡A100上比较稳的配置。max_length=4096是短上下文阶段的主要设计，如果数据里存在超过这个长度的文本，会被直接截断。第一阶段跑完，把max_length改成8192，学习率降到1e-4，再从./ckpt-st1加载继续训练，就完成了“阶段分层”的基本操作。

训练时重点观察loss曲线。第二阶段loss如果比第一阶段结束时的loss反弹超过0.3，说明上下文过长导致梯度不稳定，此时应该增大warmup_ratio到0.1，而不是继续降学习率。如果loss完全没有下降，检查数据集里是否混入了大量重复文本，继续预训练对重复数据的拟合会让评估指标失真。

2.3 分层学习率的参数表与生效条件

继续预训练阶段最值得改的参数是层间学习率衰减。下面这段自定义优化器按层分组，让不同深度拿到不同学习率：

import torch def build_layerwise_optimizer(model, base_lr=2e-4, decay=0.9): num_layers = model.config.num_hidden_layers param_groups = [] for name, param in model.named_parameters(): if not param.requires_grad: continue if "model.layers." in name: layer = int(name.split(".")[2]) ratio = decay ** (num_layers - 1 - layer) else: ratio = 1.0 param_groups.append({"params": param, "lr": base_lr * ratio}) return torch.optim.AdamW(param_groups, weight_decay=0.1)

这段代码里的decay=0.9意味着每往下走一层，学习率乘一次0.9。比如24层模型，顶层base_lr是2e-4，底层就是2e-4 * 0.9^23，约为1.6e-5，差距接近一个数量级。model.layers.这个前缀对应标准Transformer结构，DeepSeek系列同样适用；如果是MoE版本，专家层参数虽然不匹配该前缀，会走到else统一用base_lr，一般不会出问题。

下面的参数表来自落地项目的常用起点，你可以按显存和任务类型调整：

注意一个常见误用：层学习率只在训练早期有意义。到了训练后期，loss平台期对学习率已经不再敏感，这时硬调decay不会带来收益，不如直接削减学习率。另外，分层学习率应该搭配warmup_ratio使用，底层很小、顶层较大，warmup阶段如果太长，顶层学习率反而会浪费。

3. Parameter-Efficient融合微调：多LoRA训练与权重合并

3.1 为什么“融合”比单任务微调更能保住通用能力

说到Parameter-Efficient，大部分人第一反应是LoRA。但标题里的“融合微调”强调的是多个低秩适配器如何协同工作，而不是简单加载一个LoRA。单任务LoRA在垂直领域数据上如果r和alpha设太大，模型会把新分布压过原有分布，表现为通用问答能力下降。多LoRA融合的思路是：在同一个DeepSeek基座上为每个领域分别训练适配器，推理时按权重合并或动态选择，基座权重保持原样。

这种方案还有一个工程优势：业务变化时，不需要为每个任务保存一份完整模型，只保存几十到几百MB的Adapter文件。原始模型在显存里只加载一份，多个领域适配器可以随时组合，这在多租户场景里尤其实用。

3.2 用PEFT训练两个LoRA的完整配置与代码

下面用PEFT库训练一个代码问答LoRA，数学任务换成数据集后按同样的流程再跑一次即可。模型选择DeepSeek的7B Chat版本：

from peft import LoraConfig, get_peft_model from transformers import AutoModelForCausalLM, AutoTokenizer base_model = AutoModelForCausalLM.from_pretrained( "deepseek-ai/deepseek-llm-7b-chat", torch_dtype="auto", ) tokenizer = AutoTokenizer.from_pretrained("deepseek-ai/deepseek-llm-7b-chat") lora_config = LoraConfig( r=16, lora_alpha=32, lora_dropout=0.05, target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"], bias="none", task_type="CAUSAL_LM", ) model = get_peft_model(base_model, lora_config) model.print_trainable_parameters()

这里target_modules覆盖了DeepSeek每个Decoder层的全部线性投影：自注意力的q/k/v/o，以及MLP的gate/up/down。漏掉任何一组都会让微调能力明显受限。使用get_peft_model后，模型里只有LoRA部分的requires_grad=True，训练时直接传入Trainer即可，不需要额外冻结参数。

训练完成后，分别保存两个适配器：

model.save_pretrained("./lora-code")

数学任务用同样的配置，换成数学数据训练，保存到./lora-math。两个LoRA的r和lora_alpha必须保持一致，否则后续权重重合会遇到维度不匹配。

3.3 推理时融合LoRA权重：算术合并还是路由选择

最直接的融合方法是权重合并。假设两个LoRA是在同一基座、相同r和alpha下训练出来的，那么可以线性插值：

from peft import PeftModel base = AutoModelForCausalLM.from_pretrained("deepseek-ai/deepseek-llm-7b-chat") model = PeftModel.from_pretrained(base, "./lora-code") # 默认adapter名为default model.load_adapter("./lora-math", adapter_name="math") # 以0.5/0.5加权融合，新适配器名为code-math model.add_weighted_adapter( adapter_names=["default", "math"], weights=[0.5, 0.5], adapter_name="code-math", combination_type="linear", ) model.set_adapter("code-math") model.merge_and_unload()

add_weighted_adapter会生成一个新的适配器，linear类型要求两个原始适配器的r和alpha一致，权重参数相加不会产生矩阵对齐问题。想让某个领域更突出，就把权重从0.5调高，例如代码0.7、数学0.3。如果训练时确实用了不同的r，combination_type可以改为cat，但这会让推理的batch size变小，显存占用上升。

另一个常用路线是路由选择：不合并权重，把两个适配器同时加载到模型上，推理前用一个分类器判断当前用户输入属于哪个领域，再触发对应的adapter。这个方式不会改变权重，适合需要频繁更新单个领域的线上系统。常见的做法是给每个adapter加一个关键prompt前缀，比如“请按代码助手回答”，然后由路由模型选择。路由方案的缺点是会引入额外推理延迟，但对DeepSeek这种大模型来说，RPC开销通常比多一个路由模型大得多。

下表是LoRA核心参数在这个场景下的推荐值：

融合之后一定要做回归测试。把单独代码LoRA和单独数学LoRA分别加载，跑各自领域的测试集，得到基准指标；再加载融合后的模型跑同一批测试集，任何一项掉点超过2个点，就说明权重配比不合适，优先调weights而不是重新训练。

4. 蒸馏模型低比特量化：教师数据生成与INT4推理落地

4.1 先蒸馏再量化，顺序错了精度会崩

“蒸馏模型低比特量化”这个词本身的顺序就是这个环节的落地顺序：先做知识蒸馏，得到更小的学生模型，再对学生模型做低比特量化。如果反过来，先量化再蒸馏，量化噪声会通过软标签传递给学生，让学生学到一个本来就受损的分布。实际对比中，先量化再蒸馏比先蒸馏再量化在推理性能上通常掉3%~5%，低比特场景下差距更明显。

有人会问，能不能直接用DeepSeek模型做PTQ量化，不蒸馏。如果对推理性能要求高、显存又紧张，当然可以直接量化。但蒸馏的价值在于把参数量从几十B缩到几B，再从几B量化到4bit，整体显存占用远低于量化一个原始大模型。这也是“蒸馏模型低比特量化”适合企业私有大模型落地的原因。

4.2 用DeepSeek大模型生成教师数据，训练学生模型

蒸馏第一步是准备教师logits。可以用DeepSeek大模型在指令数据集上推理，把输出logits保存下来，也可以在线蒸馏，即训练学生模型时实时跑教师前向。在线方式会增加训练成本，但省去磁盘存储。下面是一个标准的蒸馏损失函数：

import torch import torch.nn.functional as F def distill_loss(student_logits, teacher_logits, labels, temperature=4.0, alpha=0.5): vocab_size = student_logits.size(-1) soft_loss = F.kl_div( F.log_softmax(student_logits / temperature, dim=-1), F.softmax(teacher_logits.detach() / temperature, dim=-1), reduction="batchmean", ) * (temperature ** 2) hard_loss = F.cross_entropy( student_logits.view(-1, vocab_size), labels.view(-1), ignore_index=-100, ) return alpha * soft_loss + (1 - alpha) * hard_loss

temperature越高，软标签越平滑，能让学生学到教师对候选token的细微偏好，但过高会模糊正确答案，4~8是常用区间。alpha=0.5表示软损失和硬损失对半开；如果学生模型参数量很小，建议把alpha加大到0.7，让学生更依赖教师的分布信号。teacher_logits.detach()是必须的，否则梯度会穿过教师模型。

学生模型不需要和教师用同一个结构，但必须共用分词器。这也是蒸馏里最容易踩坑的地方：DeepSeek系列模型词表偏大，如果学生模型换了词表，输出层必须重新随机初始化，一开始的loss会非常高，需要多跑几千步才能对齐。

4.3 低比特量化的三种路线与校准集要求

训练完学生模型后进入量化，目前主流路线有三种：

用GPTQ做离线量化时，校准集的选择很关键。下面这段配置把dataset设为c4，只是为了演示，实际项目应换成业务领域文本：

from transformers import AutoModelForCausalLM, AutoTokenizer, GPTQConfig tokenizer = AutoTokenizer.from_pretrained("./student-model") quant_config = GPTQConfig( bits=4, group_size=128, desc_act=True, dataset="c4", tokenizer=tokenizer, ) model = AutoModelForCausalLM.from_pretrained( "./student-model", quantization_config=quant_config, device_map="auto", )

group_size=128是4bit量化最常用的分组大小，它把权重每128个分成一组，各自计算缩放因子，压缩比和精度的平衡点比较好。desc_act=True会按激活值对列做重排，让量化误差更均匀，但会略微降低推理吞吐。校准集数据条数不用多，但分布必须贴近真实场景，否则量化后模型在业务数据上的ppl会明显膨胀。

4.4 量化后模型质量验证：困惑度与下游任务

量化完成后先做快速验证。用一段没参与过训练的领域文本计算ppl：

import torch from transformers import AutoModelForCausalLM, AutoTokenizer model = AutoModelForCausalLM.from_pretrained("./student-model-gptq", device_map="auto") tokenizer = AutoTokenizer.from_pretrained("./student-model") text = "用一段包含代码与中文描述的文本作为测试集" inputs = tokenizer(text, return_tensors="pt").to("cuda") with torch.no_grad(): outputs = model(**inputs, labels=inputs["input_ids"]) ppl = torch.exp(outputs.loss).item() print(f"PPL: {ppl:.2f}")

对比量化前同样测试文本的ppl，增量超过2就说明量化配置需要调整。优先把group_size从128调到64，或者换成AWQ。如果仍然超过阈值，而且业务对精度要求很高，只能走QAT，在量化参数固定的情况下重新训练几百步，把量化误差拉回来。

5. DeepSeek本地部署与API调用的三个验证技巧

5.1 用vLLM启动量化模型并设置上下文长度

最后把量化好的模型部署成服务。常见做法是用vLLM，它原生支持GPTQ和AWQ格式，还能直接控制上下文长度上限：

vllm serve ./student-model-gptq \ --quantization gptq \ --max-model-len 8192 \ --gpu-memory-utilization 0.9

这里的--max-model-len决定对话长度上限。很多用户反馈“达到对话长度上限，请开启新对话”，优先要查这个参数是不是设得太小，而不是怀疑API本身有问题。--gpu-memory-utilization 0.9表示允许vLLM占用90%显存，剩余留给tokenizer和系统开销。

5.2 用curl和OpenAI SDK验证API是否正常工作

vLLM启动后暴露的是OpenAI兼容接口，先用curl做冒烟测试：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "./student-model-gptq", "messages": [{"role": "user", "content": "写一个Python装饰器"}], "max_tokens": 512, "temperature": 0.2 }'

注意model字段要和启动vLLM时传递的模型路径保持一致，否则会返回not found。返回体里的usage.total_tokens可以校验实际消耗的token数，如果发现总量明显大于输入文本，说明--max-model-len里包含了预留的推理预算。

5.3 用流式输出抑制上下文过长的风险

长对话场景下，一次性返回2048个token很容易在服务端触发内存峰值。给请求体加上"stream": true，服务端会按块返回token，前端逐token渲染，单次响应内存大幅降低。同时在会话层面对历史消息做截断，只保留最近的系统提示、用户最新输入和历史摘要。这个技巧对DeepSeek这类长上下文模型尤其有效，能直接减少“达到对话长度上限”的触发频率，也更方便按token计费做成本控制。

本文还有配套的精品资源，点击获取