简介由郭震编写的一份10页图解PDF面向希望深入理解并实践DeepSeek大模型的初学者、技术爱好者及研究人员系统拆解本地部署与训练推理全流程。全文约2.66MB共1个PDF文件内容涵盖本地部署三大核心优势隐私与数据安全、模型定制优化、无网络离线运行、三步搭建演示、LLM基础概念、Transformer架构及预训练/监督微调/强化学习等底层训练方法。随后深入解析DeepSeek-R1完整训练过程重点讲解基于R1-Zero的中间推理模型与通用强化学习两项关键创新揭示其如何大幅增强推理能力与应用普适性并附有进一步学习的参考资料。目前已有925人学习适合需要在私有环境使用、研究先进大模型并快速建立系统性认知的读者无论是零基础入门还是原理进阶都能从中受益。1. DeepSeek本地部署与训练解析先想清楚推理优化和强化学习到底解决什么问题很多人把DeepSeek权重下载到本地跑通一个对话Demo就以为部署完成了。但真正进入生产链路后才是问题开始并发请求一上来首token延迟成倍飙升微调训练中loss降到了2.0生成结果却变成复读机想用强化学习让模型学会自己的回答风格又不知道奖励函数和KL惩罚从哪调起。这篇笔记围绕DeepSeek本地部署展开把推理优化里显存计算、量化选型、并发参数这几个硬骨头拆开讲透再往下落到训练解析里的LoRA微调和强化学习技术重点讲GRPO这套不需要价值模型的方案。适合想把DeepSeek私有化部署到单机并且有后续微调和强化学习对齐需求的一线开发者和算法工程师。2. 先算本地部署的账显存、推理引擎与量化三要素部署前不算显存账后面所有推理优化都会变成玄学。DeepSeek本地部署的本质是把一个几十GB的权重文件塞进GPU显存同时还要给推理过程预留KV Cache。推理阶段的显存占用大致是权重显存加激活显存加KV Cache显存。权重显存很好算参数量乘以每个参数字节数FP16权重就是参数量乘2字节。一个7B规模的DeepSeek模型用FP16大约需要14GB权重显存要想跑得舒服单卡至少24GB起步否则就必须做量化。这里的推理优化第一件事就是把显存账算明白再动引擎参数。2.1 推理优化为什么必须前置TTFT、TPOT和吞吐量怎么看部署之后到底行不行用三个指标说话TTFT、TPOT、整体吞吐量。TTFT是用户发出请求到收到第一个token的时间决定“像不像即时响应”TPOT是每个token输出的平均耗时决定输出流畅度吞吐量是每秒生成的token总数决定系统能不能撑住多个用户同时提问。这三个指标互相牵制并发开得越大单请求分到的算力越少TTFT和TPOT会同步上升上下文长度设置越长KV Cache占显存越多能同时跑的请求数反而越少。指标含义本地部署关注点TTFT请求发出到收到首个Token的时间最好控制在1秒内越高越像卡死TPOT生成一个Token的平均耗时越低越好太高会让用户觉得输出迟钝吞吐量每秒生成的Token总数并发场景下更重要体现整体GPU利用率我一般先看单请求的TTFT再调并发到4、8、16分别观察TPOT变化。如果并发一旦超过某个阈值TTFT直接翻倍基本可以断定是KV Cache分配或者显存预留出了问题。推理引擎能自动处理KV Cache分配和连续批处理但分配策略设置不对照样会把大量显存浪费在缓存预留上这也是本地部署最常见的第一类翻车现场。2.2 最小可复现的部署启动命令显存检查与推理引擎参数常见的做法是直接用开源推理引擎加载DeepSeek权重。动手前先确认GPU当前状态再按下面这套最小命令启动服务# 1) 先看几块卡、每块卡多少显存、当前被谁占用 nvidia-smi # 2) 用推理引擎启动本地模型服务默认端口8000 python -m vllm.entrypoints.api_server \ --model /data/deepseek-chat \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.85 \ --max-model-len 4096 \ --max-num-seqs 8 \ --quantization gptq--model指向本地权重目录这份权重和后面训练用的是同一份避免反复下载。--tensor-parallel-size 1先按单卡部署多卡再逐步提升。--gpu-memory-utilization 0.85表示引擎最多可用85%的GPU显存剩余空间留给驱动和系统单任务独占时可以调到0.9如果同一张卡还要跑训练就要降到0.75。--max-model-len 4096限制最大上下文长度它同时决定KV Cache的上限显存吃紧时先把它降到2048。--max-num-seqs 8限制同时处理的序列数这是控制并发和防止OOM的保险阀。--quantization gptq让引擎加载量化后的权重如果权重是FP16就删掉这行。启动后我先用curl做一次连通性验证不要急着上业务curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model: deepseek-chat, messages: [{role: user, content: 你好}]} \ --max-time 30返回的JSON里有choices字段就说明链路通了。TTFT可以用time curl粗测但这个数值受网络影响更适合的测法放到最后一章用脚本压测。注意--gpu-memory-utilization和--max-model-len必须配合调整只动其中一个经常出现“显存看着没占满一并发就OOM”的情况。2.3 量化选型GPTQ、AWQ和层敏感度不是无脑int4量化是本地部署推理优化里回报最高的一步但选型取决于显卡和任务类型。FP16或BF16精度最高7B权重约14GB至少需要24GB显存才跑得舒服GPTQ的int8权重约7GB质量损失较小适合显存有限但任务需要保留较多原始能力的场景AWQ的int4权重约4GB能让20GB以下的显卡跑7B模型但数学、代码这类对数值精度敏感的任务会明显掉点。格式7B权重近似占用质量损失适用场景FP16/BF16约14GB无显存充足的推理环境质量优先GPTQ int8约7GB较小24GB以内追求质量与并发平衡AWQ int4约4GB较大高精度任务明显小显存、长上下文、重并发量化翻车高发在“校准数据集太单一”。常见做法是用领域相关文本做校准做代码生成就选几千条代码片段做通用对话就混合新闻、百科、书籍。校准集选错量化后可能出现所有数字变成乱码的极端现象。另外不同层对量化的敏感度不一样embedding层和最后的输出层敏感度最高量化时要尽量保守甚至保持int8不动中间层对低位宽容忍度更高可以按需压到int4。量化完成后还要再做一次冒烟测试用10道数字计算题和10道代码题对比量化前后的输出过了这关才算真正完成部署。3. 训练解析用LoRA把DeepSeek调成你的领域的形状本地单机做预训练不现实数据量、显存、算力都不够。这里的训练解析聚焦在最有落地价值的SFT微调用少量领域数据在已有的DeepSeek权重上做有监督微调让输出口吻和格式贴近业务。LoRA是首选方案冻结原模型、只训练低秩矩阵显存占用只有全参微调的几分之一。但LoRA不是简单套库就能收敛数据、超参、评估三项必须对得上。3.1 训练解析SFT数据长什么样JSONL模板与三条数据原则SFT数据决定微调上限。构造一条数据时要同时给出系统指令、用户输入、期望输出不要只给问题和答案否则模型会丢掉上下文约束能力。常见格式是JSONL每行一条字段包含system、user、assistant{system: 你是熟悉智能客服场景的助手回答要简洁直接不超过50字。, user: 充值没到账怎么办, assistant: 请先检查支付账单若扣款成功但充值未到账请提供订单号客服会在2小时内处理。}数据量建议从几千条起步质量比数量更重要。三条原则第一数据要彻底去重模型对重复片段极敏感重复几十条就会直接导致生成复读第二控制输出长度分布业务是短回复就把assistant字段控制在固定长度段长短混杂会让模型输出长度飘忽第三任务边界一致所有样本都用同一套系统指令不要让模型在助手和闲聊角色之间横跳。3.2 训练脚本LoRA参数、批量大小与学习率的设定逻辑下面是用LoRA微调DeepSeek权重的最小训练脚本基于常用训练器生态模型路径用部署时那份权重目录数据已处理成上面的JSONL格式import json from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments, Trainer from peft import LoraConfig, get_peft_model model_path /data/deepseek-chat model AutoModelForCausalLM.from_pretrained(model_path, torch_dtypeauto) tokenizer AutoTokenizer.from_pretrained(model_path) lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM, ) model get_peft_model(model, lora_config) def load_jsonl(path, tokenizer): samples [] with open(path) as f: for line in f: data json.loads(line) text f{data[system]}\n用户{data[user]}\n助手{data[assistant]} samples.append(tokenizer(text)) return samples dataset load_jsonl(sft_train.jsonl, tokenizer) training_args TrainingArguments( learning_rate2e-4, per_device_train_batch_size2, gradient_accumulation_steps8, num_train_epochs3, logging_steps20, save_steps200, save_total_limit2, fp16True, ) trainer Trainer(modelmodel, argstraining_args, train_datasetdataset) trainer.train()几个关键参数的设定逻辑要讲清楚。target_modules选q_proj、k_proj、v_proj、o_proj是因为这四个投影矩阵是注意力机制里的大矩阵LoRA改这四处能快速改变模型行为不同模型内部模块名可能有差异启动前用model.named_modules()核对一遍不要硬套。r16和lora_alpha32是经验起点效果不明显就把r提到32过拟合就回到8。lora_alpha和r的比值影响低秩矩阵更新幅度比值太大会让训练不稳定。learning_rate2e-4是LoRA常用起点全参微调一般是1e-5量级LoRA因为只有低秩结构在更新可以吃更大的学习率一旦loss炸了就先降一个数量级。per_device_train_batch_size2配合gradient_accumulation_steps8得到有效批量16显存不够就加大累积步数单batch不要压得太小否则梯度噪声会很严重。3.3 看训练是不是白费loss曲线、验证集和生成样例训练解析里最容易被忽视的是只看train loss不验证实际生成效果。训练时打开logging_steps20每20步记录一次loss正常情况是下降后收敛到平台。如果loss曲线锯齿很大优先调低学习率如果train loss降了但验证集loss反而上升就是过拟合减小epoch或增大lora_dropout。我习惯训练完先跑一遍评测集再直接生成5条真实业务问题对比微调前后的回答差异。格式对了但内容空洞说明数据质量不够内容对了但语气不像说明系统指令约束不够。这个“输出样例对照法”比任何评测指标都直观。LoRA训练后有两个选择直接加载LoRA权重推理或者把LoRA合并回基座模型再导出。合并回基座能减少推理时的额外计算也方便后续量化我通常在训练完成后直接合并。4. 强化学习技术详解GRPO让DeepSeek学会自己权衡输出微调只能让模型模仿数据里的答案强化学习技术才能让模型自己探索“什么样的回答更好”。在DeepSeek本地部署后的训练里我不用PPO而用GRPO核心原因是GRPO不需要训练价值模型显存和算力开销比PPO小很多。GRPO的思路很直白对同一个问题采样多个回答让模型在组内比较哪个得分高从相对表现里学习。这一节把原理、奖励设计、最小实现和超参调试顺序说清楚。4.1 从PPO到GRPO强化学习技术里的组内竞争思想经典PPO需要策略模型、价值模型、奖励模型各一份显存开销很大。GRPO去掉了价值模型改用一组采样结果自己算baseline同一个prompt采样N个response每个response的得分减去这组得分的均值再除以标准差得到归一化优势值。这相当于让模型学会“在这组选项中选更好的”而不是跟一个绝对标准比。前者在奖励函数不精准时更鲁棒代价是采样量增大对算力要求更高。GRPO的组内竞争机制更适合本地单卡部署后的强化学习因为省下来的显存可以拿去增大采样数量或序列长度。4.2 奖励与KL控制规则奖励、格式奖励、KL惩罚三件套强化学习里最怕稀疏奖励只有最终成败模型几乎没有学习信号。常见做法是把奖励拆成三类规则奖励、格式奖励、内容奖励。规则奖励看硬性条件例如代码能否运行、JSON能否解析、答案是否包含关键字段格式奖励看输出结构例如是否以指定开头或按固定模板输出内容奖励则需要偏好模型或人工打分。规则奖励实现成本最低但容易被钻空子模型会输出满足格式但内容空洞的文本。所以要加KL惩罚让策略模型不要偏离参考模型太远reward rule_score format_score content_score - kl_coef * kl_divergence这里的kl_coef是权衡探索与保守程度的关键。kl_coef太小模型偏离参考模型太远输出会退化kl_coef太大策略模型不敢改变强化学习几乎没有效果。这个系数是强化学习调试里最值得反复试的参数。4.3 最小GRPO训练伪代码采样、归一化与KL惩罚GRPO的工程实现有完整框架但理解核心逻辑比直接调库更重要。下面是最小伪代码方便看清参数在做什么def grpo_loss(model, ref_model, prompts, reward_fn, tokenizer, args): # 对每个prompt采样N个回复 responses model.generate( prompts, num_return_sequencesargs.num_samples, # 组内采样次数 max_new_tokensargs.max_new_tokens, do_sampleTrue, temperatureargs.temperature, ) # 计算每个回复的奖励并做组内归一化 rewards reward_fn(prompts, responses) mean_r rewards.mean(dim-1, keepdimTrue) std_r rewards.std(dim-1, keepdimTrue) 1e-6 advantages (rewards - mean_r) / std_r log_probs model.log_prob(prompts, responses) ref_log_probs ref_model.log_prob(prompts, responses) kl log_probs - ref_log_probs loss -(advantages * log_probs - args.kl_coef * kl).mean() return loss参数含义要一个个说args.num_samples常取8N越大组内基准越稳定但显存和算力成倍增长args.temperature控制在0.7到1.0采样多样性靠它太高会生成冗余内容args.kl_coef通常从0.01到0.1范围起步0.05是最常见的起点max_new_tokens必须限制否则不同长度样本混在一起归一化会被长度干扰。伪代码里省略了截断和mask正式实现时一定要对填充部分做mask否则logprob会算错奖励分布全乱。这个坑我踩过后面避坑章专门说。4.4 强化学习技术调试顺序先看奖励分布再动KL最后加采样调试强化学习比微调更玄学但也有一套固定顺序。第一步不看loss先看奖励分布对同一批prompt采样N个回复后把每个样本的reward打印出来确认得分不是全0或全1。如果全是0说明规则奖励设计太严一个都没命中。第二步固定kl_coef0.05跑50到100步看reward滑动均值有没有上升趋势。完全平线说明奖励太稀疏加一个中间步骤的格式奖励。第三步如果训练早期正常但后期reward下降把kl_coef调大说明模型偏离太远。最后才调num_samples显存允许就从4调到8或16。顺序反过来很容易出现奖励震荡半天其实问题根源在奖励函数本身没有区分度。5. 本地部署与训练避坑四个实测翻车记录本地部署和训练链路里问题集中在显存分配、量化、LoRA崩坏、强化学习不收敛四类。每一类都有比较典型的排查路径按现象、原因、解决三步拆开写对照着查会快很多。5.1 现象并发一上来就OOM显存看着还有余量单请求跑DeepSeek很流畅并发设到4以上服务直接报GPU OOM用显存检查命令看占用只有70%怎么想都不该爆。原因在于推理引擎按max_model_len预留KV Cache4096上下文意味着每个序列都要预留大量缓存空间并发8个序列时缓存总量直接翻倍显存看着有剩余其实已经预留给KV Cache了。解决时先下调max-model-len从4096降到2048再把max-num-seqs从8降到4最后配合gpu-memory-utilization减到0.8给缓存留出余量。这三个参数一起调一般能救回来如果还OOM就是量化没做回到第2章换int8。5.2 现象int4量化后模型失忆数字全错乱同一个DeepSeek权重FP16出口算题正常AWQ int4后所有数字对不上。原因在数值敏感任务上低位宽量化把数值精度吃掉了另外校准数据如果全是新闻类文本数学任务表现会崩得特别厉害。解决时先退到int8看质量是否恢复如果必须int4换校准集加入目标场景数据再测试。还可以用部分层保持高精度的方案embedding层和输出层保持int8中间层用int4能平衡显存和准确率。这个经验在代码生成和数学场景下非常有用。5.3 现象LoRA训练loss下降但生成结果是复读机训练日志里loss从3.0降到2.0生成结果却一直重复同一句话。原因通常有两类训练数据里重复片段太多模型把重复当成了规律或者lora_alpha设得太大低秩矩阵覆盖了原始行为让输出崩坏。解决时先把lora_alpha从32降到16或8重新训练看输出如果不缓解就在数据上做去重用simhash或文本相似度聚类把重复度高的样本挑出来最后检查epoch几千条数据3个epoch合适数据量只有几百条时1个epoch就够。5.4 现象GRPO奖励曲线一条直线训练好像没发生强化学习跑了200步奖励和惩罚都没有变化曲线一直是水平线。原因基本是奖励函数区分度太低要么所有生成的回复都得到同一个分数要么KL惩罚系数太大模型每一步都被拉回参考模型。解决时先单独打印5个prompt的采样结果看reward_fn是否真的返回不同分数如果全一样给奖励函数加一个中间约束比如先要求模型输出指定格式再给分。如果是KL惩罚太大把kl_coef从0.05降到0.01跑50步观察reward均值是否抬升。6. 压测脚本收官十分钟把TTFT、吞吐和显存余量一起试出来优化做完怎么验证值得投入我每次部署完都会跑一轮压测用数据说话而不是靠感觉。下面是最小压测脚本用并发请求测TTFT和整体时延import time, requests URL http://localhost:8000/v1/chat/completions def single_request(payload): t0 time.time() r requests.post(URL, jsonpayload) elapsed time.time() - t0 return elapsed, r.json() payload { model: deepseek-chat, messages: [{role: user, content: 请用一句话介绍推理优化}], max_tokens: 128, } for _ in range(5): latency, data single_request(payload) content data[choices][0][message][content] print(flatency{latency:.2f}s, tokens{len(content)})这个脚本先测单请求时延。如果单请求时延都超过3秒先查量化有没有生效、GPU占用是否满载如果单请求正常再用并发工具压4路和8路。ab -n 40 -c 4 -p request.json -T application/json http://localhost:8000/v1/chat/completions-c 4表示并发4个请求-n 40表示总共发送40个。压测结果看两个数平均时延和吞吐量。单请求时延正常但并发后平均时延翻倍说明max_num_seqs太低或max_model_len太长显存余量还有但吞吐上不去说明gpu-memory-utilization留了太多空间给系统可以适当调高。我现在的习惯是每调完一轮部署参数就把这套压测脚本原样跑一遍把数字记下来再改下一轮。这个动作帮我避开很多“感觉变快了”的错觉也比单纯看显存占用靠谱得多。好用的技巧不多能复现的才值得固化下来这套压测脚本就是其中之一希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/14 2:00:28 · 阅读 1.2k DeepSeek本地部署与训练解析：推理优化、LoRA微调与GRPO强化学习
简介由郭震编写的一份10页图解PDF面向希望深入理解并实践DeepSeek大模型的初学者、技术爱好者及研究人员系统拆解本地部署与训练推理全流程。全文约2.66MB共1个PDF文件内容涵盖本地部署三大核心优势隐私与数据安全、模型定制优化、无网络离线运行、三步搭建演示、LLM基础概念、Transformer架构及预训练/监督微调/强化学习等底层训练方法。随后深入解析DeepSeek-R1完整训练过程重点讲解基于R1-Zero的中间推理模型与通用强化学习两项关键创新揭示其如何大幅增强推理能力与应用普适性并附有进一步学习的参考资料。目前已有925人学习适合需要在私有环境使用、研究先进大模型并快速建立系统性认知的读者无论是零基础入门还是原理进阶都能从中受益。1. DeepSeek本地部署与训练解析先想清楚推理优化和强化学习到底解决什么问题很多人把DeepSeek权重下载到本地跑通一个对话Demo就以为部署完成了。但真正进入生产链路后才是问题开始并发请求一上来首token延迟成倍飙升微调训练中loss降到了2.0生成结果却变成复读机想用强化学习让模型学会自己的回答风格又不知道奖励函数和KL惩罚从哪调起。这篇笔记围绕DeepSeek本地部署展开把推理优化里显存计算、量化选型、并发参数这几个硬骨头拆开讲透再往下落到训练解析里的LoRA微调和强化学习技术重点讲GRPO这套不需要价值模型的方案。适合想把DeepSeek私有化部署到单机并且有后续微调和强化学习对齐需求的一线开发者和算法工程师。2. 先算本地部署的账显存、推理引擎与量化三要素部署前不算显存账后面所有推理优化都会变成玄学。DeepSeek本地部署的本质是把一个几十GB的权重文件塞进GPU显存同时还要给推理过程预留KV Cache。推理阶段的显存占用大致是权重显存加激活显存加KV Cache显存。权重显存很好算参数量乘以每个参数字节数FP16权重就是参数量乘2字节。一个7B规模的DeepSeek模型用FP16大约需要14GB权重显存要想跑得舒服单卡至少24GB起步否则就必须做量化。这里的推理优化第一件事就是把显存账算明白再动引擎参数。2.1 推理优化为什么必须前置TTFT、TPOT和吞吐量怎么看部署之后到底行不行用三个指标说话TTFT、TPOT、整体吞吐量。TTFT是用户发出请求到收到第一个token的时间决定“像不像即时响应”TPOT是每个token输出的平均耗时决定输出流畅度吞吐量是每秒生成的token总数决定系统能不能撑住多个用户同时提问。这三个指标互相牵制并发开得越大单请求分到的算力越少TTFT和TPOT会同步上升上下文长度设置越长KV Cache占显存越多能同时跑的请求数反而越少。指标含义本地部署关注点TTFT请求发出到收到首个Token的时间最好控制在1秒内越高越像卡死TPOT生成一个Token的平均耗时越低越好太高会让用户觉得输出迟钝吞吐量每秒生成的Token总数并发场景下更重要体现整体GPU利用率我一般先看单请求的TTFT再调并发到4、8、16分别观察TPOT变化。如果并发一旦超过某个阈值TTFT直接翻倍基本可以断定是KV Cache分配或者显存预留出了问题。推理引擎能自动处理KV Cache分配和连续批处理但分配策略设置不对照样会把大量显存浪费在缓存预留上这也是本地部署最常见的第一类翻车现场。2.2 最小可复现的部署启动命令显存检查与推理引擎参数常见的做法是直接用开源推理引擎加载DeepSeek权重。动手前先确认GPU当前状态再按下面这套最小命令启动服务# 1) 先看几块卡、每块卡多少显存、当前被谁占用 nvidia-smi # 2) 用推理引擎启动本地模型服务默认端口8000 python -m vllm.entrypoints.api_server \ --model /data/deepseek-chat \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.85 \ --max-model-len 4096 \ --max-num-seqs 8 \ --quantization gptq--model指向本地权重目录这份权重和后面训练用的是同一份避免反复下载。--tensor-parallel-size 1先按单卡部署多卡再逐步提升。--gpu-memory-utilization 0.85表示引擎最多可用85%的GPU显存剩余空间留给驱动和系统单任务独占时可以调到0.9如果同一张卡还要跑训练就要降到0.75。--max-model-len 4096限制最大上下文长度它同时决定KV Cache的上限显存吃紧时先把它降到2048。--max-num-seqs 8限制同时处理的序列数这是控制并发和防止OOM的保险阀。--quantization gptq让引擎加载量化后的权重如果权重是FP16就删掉这行。启动后我先用curl做一次连通性验证不要急着上业务curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model: deepseek-chat, messages: [{role: user, content: 你好}]} \ --max-time 30返回的JSON里有choices字段就说明链路通了。TTFT可以用time curl粗测但这个数值受网络影响更适合的测法放到最后一章用脚本压测。注意--gpu-memory-utilization和--max-model-len必须配合调整只动其中一个经常出现“显存看着没占满一并发就OOM”的情况。2.3 量化选型GPTQ、AWQ和层敏感度不是无脑int4量化是本地部署推理优化里回报最高的一步但选型取决于显卡和任务类型。FP16或BF16精度最高7B权重约14GB至少需要24GB显存才跑得舒服GPTQ的int8权重约7GB质量损失较小适合显存有限但任务需要保留较多原始能力的场景AWQ的int4权重约4GB能让20GB以下的显卡跑7B模型但数学、代码这类对数值精度敏感的任务会明显掉点。格式7B权重近似占用质量损失适用场景FP16/BF16约14GB无显存充足的推理环境质量优先GPTQ int8约7GB较小24GB以内追求质量与并发平衡AWQ int4约4GB较大高精度任务明显小显存、长上下文、重并发量化翻车高发在“校准数据集太单一”。常见做法是用领域相关文本做校准做代码生成就选几千条代码片段做通用对话就混合新闻、百科、书籍。校准集选错量化后可能出现所有数字变成乱码的极端现象。另外不同层对量化的敏感度不一样embedding层和最后的输出层敏感度最高量化时要尽量保守甚至保持int8不动中间层对低位宽容忍度更高可以按需压到int4。量化完成后还要再做一次冒烟测试用10道数字计算题和10道代码题对比量化前后的输出过了这关才算真正完成部署。3. 训练解析用LoRA把DeepSeek调成你的领域的形状本地单机做预训练不现实数据量、显存、算力都不够。这里的训练解析聚焦在最有落地价值的SFT微调用少量领域数据在已有的DeepSeek权重上做有监督微调让输出口吻和格式贴近业务。LoRA是首选方案冻结原模型、只训练低秩矩阵显存占用只有全参微调的几分之一。但LoRA不是简单套库就能收敛数据、超参、评估三项必须对得上。3.1 训练解析SFT数据长什么样JSONL模板与三条数据原则SFT数据决定微调上限。构造一条数据时要同时给出系统指令、用户输入、期望输出不要只给问题和答案否则模型会丢掉上下文约束能力。常见格式是JSONL每行一条字段包含system、user、assistant{system: 你是熟悉智能客服场景的助手回答要简洁直接不超过50字。, user: 充值没到账怎么办, assistant: 请先检查支付账单若扣款成功但充值未到账请提供订单号客服会在2小时内处理。}数据量建议从几千条起步质量比数量更重要。三条原则第一数据要彻底去重模型对重复片段极敏感重复几十条就会直接导致生成复读第二控制输出长度分布业务是短回复就把assistant字段控制在固定长度段长短混杂会让模型输出长度飘忽第三任务边界一致所有样本都用同一套系统指令不要让模型在助手和闲聊角色之间横跳。3.2 训练脚本LoRA参数、批量大小与学习率的设定逻辑下面是用LoRA微调DeepSeek权重的最小训练脚本基于常用训练器生态模型路径用部署时那份权重目录数据已处理成上面的JSONL格式import json from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments, Trainer from peft import LoraConfig, get_peft_model model_path /data/deepseek-chat model AutoModelForCausalLM.from_pretrained(model_path, torch_dtypeauto) tokenizer AutoTokenizer.from_pretrained(model_path) lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM, ) model get_peft_model(model, lora_config) def load_jsonl(path, tokenizer): samples [] with open(path) as f: for line in f: data json.loads(line) text f{data[system]}\n用户{data[user]}\n助手{data[assistant]} samples.append(tokenizer(text)) return samples dataset load_jsonl(sft_train.jsonl, tokenizer) training_args TrainingArguments( learning_rate2e-4, per_device_train_batch_size2, gradient_accumulation_steps8, num_train_epochs3, logging_steps20, save_steps200, save_total_limit2, fp16True, ) trainer Trainer(modelmodel, argstraining_args, train_datasetdataset) trainer.train()几个关键参数的设定逻辑要讲清楚。target_modules选q_proj、k_proj、v_proj、o_proj是因为这四个投影矩阵是注意力机制里的大矩阵LoRA改这四处能快速改变模型行为不同模型内部模块名可能有差异启动前用model.named_modules()核对一遍不要硬套。r16和lora_alpha32是经验起点效果不明显就把r提到32过拟合就回到8。lora_alpha和r的比值影响低秩矩阵更新幅度比值太大会让训练不稳定。learning_rate2e-4是LoRA常用起点全参微调一般是1e-5量级LoRA因为只有低秩结构在更新可以吃更大的学习率一旦loss炸了就先降一个数量级。per_device_train_batch_size2配合gradient_accumulation_steps8得到有效批量16显存不够就加大累积步数单batch不要压得太小否则梯度噪声会很严重。3.3 看训练是不是白费loss曲线、验证集和生成样例训练解析里最容易被忽视的是只看train loss不验证实际生成效果。训练时打开logging_steps20每20步记录一次loss正常情况是下降后收敛到平台。如果loss曲线锯齿很大优先调低学习率如果train loss降了但验证集loss反而上升就是过拟合减小epoch或增大lora_dropout。我习惯训练完先跑一遍评测集再直接生成5条真实业务问题对比微调前后的回答差异。格式对了但内容空洞说明数据质量不够内容对了但语气不像说明系统指令约束不够。这个“输出样例对照法”比任何评测指标都直观。LoRA训练后有两个选择直接加载LoRA权重推理或者把LoRA合并回基座模型再导出。合并回基座能减少推理时的额外计算也方便后续量化我通常在训练完成后直接合并。4. 强化学习技术详解GRPO让DeepSeek学会自己权衡输出微调只能让模型模仿数据里的答案强化学习技术才能让模型自己探索“什么样的回答更好”。在DeepSeek本地部署后的训练里我不用PPO而用GRPO核心原因是GRPO不需要训练价值模型显存和算力开销比PPO小很多。GRPO的思路很直白对同一个问题采样多个回答让模型在组内比较哪个得分高从相对表现里学习。这一节把原理、奖励设计、最小实现和超参调试顺序说清楚。4.1 从PPO到GRPO强化学习技术里的组内竞争思想经典PPO需要策略模型、价值模型、奖励模型各一份显存开销很大。GRPO去掉了价值模型改用一组采样结果自己算baseline同一个prompt采样N个response每个response的得分减去这组得分的均值再除以标准差得到归一化优势值。这相当于让模型学会“在这组选项中选更好的”而不是跟一个绝对标准比。前者在奖励函数不精准时更鲁棒代价是采样量增大对算力要求更高。GRPO的组内竞争机制更适合本地单卡部署后的强化学习因为省下来的显存可以拿去增大采样数量或序列长度。4.2 奖励与KL控制规则奖励、格式奖励、KL惩罚三件套强化学习里最怕稀疏奖励只有最终成败模型几乎没有学习信号。常见做法是把奖励拆成三类规则奖励、格式奖励、内容奖励。规则奖励看硬性条件例如代码能否运行、JSON能否解析、答案是否包含关键字段格式奖励看输出结构例如是否以指定开头或按固定模板输出内容奖励则需要偏好模型或人工打分。规则奖励实现成本最低但容易被钻空子模型会输出满足格式但内容空洞的文本。所以要加KL惩罚让策略模型不要偏离参考模型太远reward rule_score format_score content_score - kl_coef * kl_divergence这里的kl_coef是权衡探索与保守程度的关键。kl_coef太小模型偏离参考模型太远输出会退化kl_coef太大策略模型不敢改变强化学习几乎没有效果。这个系数是强化学习调试里最值得反复试的参数。4.3 最小GRPO训练伪代码采样、归一化与KL惩罚GRPO的工程实现有完整框架但理解核心逻辑比直接调库更重要。下面是最小伪代码方便看清参数在做什么def grpo_loss(model, ref_model, prompts, reward_fn, tokenizer, args): # 对每个prompt采样N个回复 responses model.generate( prompts, num_return_sequencesargs.num_samples, # 组内采样次数 max_new_tokensargs.max_new_tokens, do_sampleTrue, temperatureargs.temperature, ) # 计算每个回复的奖励并做组内归一化 rewards reward_fn(prompts, responses) mean_r rewards.mean(dim-1, keepdimTrue) std_r rewards.std(dim-1, keepdimTrue) 1e-6 advantages (rewards - mean_r) / std_r log_probs model.log_prob(prompts, responses) ref_log_probs ref_model.log_prob(prompts, responses) kl log_probs - ref_log_probs loss -(advantages * log_probs - args.kl_coef * kl).mean() return loss参数含义要一个个说args.num_samples常取8N越大组内基准越稳定但显存和算力成倍增长args.temperature控制在0.7到1.0采样多样性靠它太高会生成冗余内容args.kl_coef通常从0.01到0.1范围起步0.05是最常见的起点max_new_tokens必须限制否则不同长度样本混在一起归一化会被长度干扰。伪代码里省略了截断和mask正式实现时一定要对填充部分做mask否则logprob会算错奖励分布全乱。这个坑我踩过后面避坑章专门说。4.4 强化学习技术调试顺序先看奖励分布再动KL最后加采样调试强化学习比微调更玄学但也有一套固定顺序。第一步不看loss先看奖励分布对同一批prompt采样N个回复后把每个样本的reward打印出来确认得分不是全0或全1。如果全是0说明规则奖励设计太严一个都没命中。第二步固定kl_coef0.05跑50到100步看reward滑动均值有没有上升趋势。完全平线说明奖励太稀疏加一个中间步骤的格式奖励。第三步如果训练早期正常但后期reward下降把kl_coef调大说明模型偏离太远。最后才调num_samples显存允许就从4调到8或16。顺序反过来很容易出现奖励震荡半天其实问题根源在奖励函数本身没有区分度。5. 本地部署与训练避坑四个实测翻车记录本地部署和训练链路里问题集中在显存分配、量化、LoRA崩坏、强化学习不收敛四类。每一类都有比较典型的排查路径按现象、原因、解决三步拆开写对照着查会快很多。5.1 现象并发一上来就OOM显存看着还有余量单请求跑DeepSeek很流畅并发设到4以上服务直接报GPU OOM用显存检查命令看占用只有70%怎么想都不该爆。原因在于推理引擎按max_model_len预留KV Cache4096上下文意味着每个序列都要预留大量缓存空间并发8个序列时缓存总量直接翻倍显存看着有剩余其实已经预留给KV Cache了。解决时先下调max-model-len从4096降到2048再把max-num-seqs从8降到4最后配合gpu-memory-utilization减到0.8给缓存留出余量。这三个参数一起调一般能救回来如果还OOM就是量化没做回到第2章换int8。5.2 现象int4量化后模型失忆数字全错乱同一个DeepSeek权重FP16出口算题正常AWQ int4后所有数字对不上。原因在数值敏感任务上低位宽量化把数值精度吃掉了另外校准数据如果全是新闻类文本数学任务表现会崩得特别厉害。解决时先退到int8看质量是否恢复如果必须int4换校准集加入目标场景数据再测试。还可以用部分层保持高精度的方案embedding层和输出层保持int8中间层用int4能平衡显存和准确率。这个经验在代码生成和数学场景下非常有用。5.3 现象LoRA训练loss下降但生成结果是复读机训练日志里loss从3.0降到2.0生成结果却一直重复同一句话。原因通常有两类训练数据里重复片段太多模型把重复当成了规律或者lora_alpha设得太大低秩矩阵覆盖了原始行为让输出崩坏。解决时先把lora_alpha从32降到16或8重新训练看输出如果不缓解就在数据上做去重用simhash或文本相似度聚类把重复度高的样本挑出来最后检查epoch几千条数据3个epoch合适数据量只有几百条时1个epoch就够。5.4 现象GRPO奖励曲线一条直线训练好像没发生强化学习跑了200步奖励和惩罚都没有变化曲线一直是水平线。原因基本是奖励函数区分度太低要么所有生成的回复都得到同一个分数要么KL惩罚系数太大模型每一步都被拉回参考模型。解决时先单独打印5个prompt的采样结果看reward_fn是否真的返回不同分数如果全一样给奖励函数加一个中间约束比如先要求模型输出指定格式再给分。如果是KL惩罚太大把kl_coef从0.05降到0.01跑50步观察reward均值是否抬升。6. 压测脚本收官十分钟把TTFT、吞吐和显存余量一起试出来优化做完怎么验证值得投入我每次部署完都会跑一轮压测用数据说话而不是靠感觉。下面是最小压测脚本用并发请求测TTFT和整体时延import time, requests URL http://localhost:8000/v1/chat/completions def single_request(payload): t0 time.time() r requests.post(URL, jsonpayload) elapsed time.time() - t0 return elapsed, r.json() payload { model: deepseek-chat, messages: [{role: user, content: 请用一句话介绍推理优化}], max_tokens: 128, } for _ in range(5): latency, data single_request(payload) content data[choices][0][message][content] print(flatency{latency:.2f}s, tokens{len(content)})这个脚本先测单请求时延。如果单请求时延都超过3秒先查量化有没有生效、GPU占用是否满载如果单请求正常再用并发工具压4路和8路。ab -n 40 -c 4 -p request.json -T application/json http://localhost:8000/v1/chat/completions-c 4表示并发4个请求-n 40表示总共发送40个。压测结果看两个数平均时延和吞吐量。单请求时延正常但并发后平均时延翻倍说明max_num_seqs太低或max_model_len太长显存余量还有但吞吐上不去说明gpu-memory-utilization留了太多空间给系统可以适当调高。我现在的习惯是每调完一轮部署参数就把这套压测脚本原样跑一遍把数字记下来再改下一轮。这个动作帮我避开很多“感觉变快了”的错觉也比单纯看显存占用靠谱得多。好用的技巧不多能复现的才值得固化下来这套压测脚本就是其中之一希望帮到你。本文还有配套的精品资源点击获取