尧图网站建设 
简介这份PDF文档聚焦电信网络优化场景系统讲解DeepSeek-R1模型在5G基站部署中的微调技巧面向通信工程师、网络优化人员及对AI落地感兴趣的开发者帮助解决5G基站覆盖、容量与网络质量调优中的实际问题。资源包共1个文件为1.73MB的PDF文档内容完整、目录清晰涵盖模型基础介绍、适配分析、数据预处理与参数微调、效果评估指标及实际案例等模块并配有图表辅助理解。文档从5G基站部署挑战切入逐步展开DeepSeek-R1的架构原理、兼容性分析、学习率与批次大小调整、层结构与神经元数量微调等操作要点最后通过真实案例展示优化方案制定与效果评估流程。已有63人学习适合希望将大模型技术应用于电信网络优化的读者参考可帮助快速建立从理论到微调实践的完整认知。1. 电信网络优化遇上 DeepSeek-R15G 基站侧微调到底在调什么5G 基站每天都在吐海量数据小区级 KPI、MR 测量报告、告警日志、信令跟踪、工参配置。传统做法是靠专家写规则、拉阈值、做关联分析一套流程跑下来问题定位周期动辄按天算。现在把 DeepSeek-R1 这类推理大模型放到基站侧做网络优化核心诉求不是让它“聊天”而是让它读懂 KPI 劣化模式、告警因果链和参数配置之间的隐性关系直接给出可执行的优化建议。但通用模型对电信域术语、基站拓扑约束、3GPP 参数取值范围几乎没概念直接问它“某小区上行干扰抬升怎么调”回答大概率是泛泛而谈。所以必须做微调而且是带着 5G 基站领域数据做垂直微调。这篇文章面向的是已经有一定深度学习基础、手头有基站侧数据、想用 DeepSeek-R1 做网络优化微调的工程师。我会把选型理由、数据构造、LoRA 微调参数、部署验证和踩坑记录按可复现的路径讲清楚不绕弯子。2. 为什么选 DeepSeek-R1 做基站侧微调选型逻辑与数据准备2.1 基站侧微调为什么优先考虑 DeepSeek-R1 而不是通用小模型电信网络优化场景对模型的要求比较特殊。第一它需要多步推理能力一个 KPI 劣化往往不是单一原因可能是邻区干扰、切换参数不合理、天馈接反、甚至传输闪断模型得能沿着因果链往下推。第二它需要理解结构化数据MR 报告里的 RSRP、SINR、TA 分布KPI 里的掉线率、切换成功率、上行 PRB 利用率这些数值之间的关联不是简单查表能覆盖的。第三它需要输出可执行建议不是“建议检查邻区”而是“将某小区到某邻区的 CIO 从 2dB 调整为 4dB同时把 A3 偏置从 2 调为 3”。DeepSeek-R1 的推理链能力在开源模型里属于第一梯队尤其是它的长思维链输出天然适合做“现象→推理→建议”这种三段式任务。相比 Qwen 系列R1 在复杂因果推理上的表现更稳相比同规模稠密模型R1 的 MoE 架构在推理成本上更有优势。如果你手头 GPU 资源有限又不想牺牲推理深度R1 是目前比较务实的选择。当然如果你的场景只是做 KPI 异常检测这种分类任务那用 Qwen3 0.6B 做 LoRA 微调就够了没必要上 R1。选型的第一原则是任务复杂度决定模型规模不是反过来。2.2 基站侧微调数据从哪来四类数据源与构造方法微调数据质量直接决定模型能不能用。基站侧数据通常散落在几个地方网管 KPI 报表、MR 测量报告、告警系统、工参配置库。我一般按下面四类来构造指令数据。第一类是 KPI 劣化归因。输入是一组小区级 KPI 时间序列输出是劣化原因排序和对应优化建议。数据来源是网管历史报表需要人工标注或半自动关联告警和工参变更记录。第二类是告警根因分析。输入是告警序列和关联 KPI输出是根因告警和处置步骤。这类数据可以从工单系统里回溯把已解决的工单还原成指令对。第三类是参数配置推荐。输入是场景描述覆盖、容量、干扰输出是推荐参数集。这类数据需要专家经验但量不用大几百条高质量样本就能见效。第四类是信令流程解读。输入是信令跟踪摘要输出是异常环节定位。这类数据最难拿但价值最高。构造格式统一用 Alpaca 风格{ instruction: 某5G小区上行PRB利用率持续高于80%同时上行干扰噪声抬升6dB邻区切换成功率下降3%。请分析原因并给出优化建议。, input: 小区ID: NR_00123, 频段: 2.6GHz, 带宽: 100MHz, 当前CIO: 2dB, A3偏置: 2dB, output: 推理上行PRB利用率高且干扰抬升优先排查外部干扰和邻区上行冲突。切换成功率下降说明干扰已影响测量精度。建议1. 调整该小区到邻区的CIO至4dB减少边缘用户切换失败2. A3偏置调整为3dB提前触发切换3. 排查2.6GHz频段外部干扰源。 }注意输出里必须包含推理过程不能只给结论。R1 的微调如果只喂结论推理能力会退化。数据量方面LoRA 微调通常 5002000 条高质量样本就能看到明显效果。关键是覆盖度每个 KPI 劣化模式至少 20 条每个告警类型至少 10 条。数据划分按 8:1:1 切训练、验证、测试注意同一小区的数据不能同时出现在训练集和测试集否则评估结果会虚高。2.3 数据清洗的三个硬标准基站数据脏起来是真的脏。我踩过的坑包括KPI 时间戳对不齐、MR 采样点缺失、告警去重没做导致同一根因重复出现。清洗时盯住三条时间对齐到 15 分钟粒度、缺失值超过 30% 的样本直接丢、告警序列按根因去重。别心疼数据量脏数据喂进去模型学到的就是错的关联。3. LoRA 微调实战从环境搭建到训练脚本3.1 环境准备与基座模型加载我一般用 LLaMA-Factory 做微调框架它对 DeepSeek-R1 的支持比较完整配置驱动改参数不用动代码。环境依赖conda create -n deepseek-r1-ft python3.10 conda activate deepseek-r1-ft pip install torch2.1.0 transformers4.40.0 peft0.10.0 datasets2.18.0 pip install llama-factory基座模型加载用 HuggingFace 格式如果显存不够用 4bit 量化加载from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig bnb_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_compute_dtypebfloat16, bnb_4bit_quant_typenf4 ) model AutoModelForCausalLM.from_pretrained( deepseek-ai/DeepSeek-R1-Distill-Qwen-7B, quantization_configbnb_config, device_mapauto ) tokenizer AutoTokenizer.from_pretrained(deepseek-ai/DeepSeek-R1-Distill-Qwen-7B)这里选 7B 蒸馏版而不是满血 R1原因是基站侧微调通常不需要 671B 的通用能力7B 蒸馏版在推理任务上保留得比较好单卡 24G 就能跑 LoRA。如果你有 A100 80G可以直接上 32B 版本效果更稳。3.2 LoRA 参数怎么设rank、alpha、target_modules 的取值逻辑LoRA 的核心参数就三个rank、alpha、target_modules。rank 决定低秩矩阵的秩越大容量越强但越容易过拟合。基站侧任务我一般从 rank16 起步数据量超过 2000 条可以加到 32。alpha 通常设 rank 的 2 倍即 alpha32。target_modules 要覆盖注意力层的 q_proj、k_proj、v_proj、o_proj以及 FFN 层的 gate_proj、up_proj、down_proj。只调 q_proj 和 v_proj 在电信域任务上不够FFN 层承载了大量领域知识。from peft import LoraConfig, get_peft_model lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) model get_peft_model(model, lora_config) model.print_trainable_parameters()学习率设 1e-4 到 2e-4cosine 调度warmup 比例 0.03。batch size 根据显存来7B 模型 4bit 量化下单卡 24G 可以跑 batch_size4梯度累积 4 步等效 batch_size16。训练轮数 35 轮多了必过拟合。评估指标看验证集 loss 和生成质量loss 不降或者生成开始重复立刻停。3.3 训练脚本与关键参数说明用 LLaMA-Factory 的配置文件方式model_name_or_path: deepseek-ai/DeepSeek-R1-Distill-Qwen-7B stage: sft do_train: true finetuning_type: lora lora_rank: 16 lora_alpha: 32 lora_dropout: 0.05 lora_target: all dataset: telecom_kpi_sft template: deepseek cutoff_len: 2048 max_samples: 2000 overwrite_cache: true preprocessing_num_workers: 8 output_dir: ./output/deepseek-r1-telecom-lora logging_steps: 10 save_steps: 200 plot_loss: true overwrite_output_dir: true per_device_train_batch_size: 4 gradient_accumulation_steps: 4 learning_rate: 1.5e-4 num_train_epochs: 3 lr_scheduler_type: cosine warmup_ratio: 0.03 bf16: true gradient_checkpointing: truecutoff_len设 2048 是因为基站侧指令数据里 KPI 序列和推理链比较长512 会截断。template必须选 deepseek否则特殊 token 对不上。gradient_checkpointing开起来省显存代价是训练慢 20% 左右。save_steps设 200 是为了方便回滚LoRA 权重文件小多存几个不占地方。训练启动llamafactory-cli train config/telecom_lora_sft.yaml跑起来之后盯 loss 曲线。正常情况 loss 从 2.0 左右降到 0.81.2 区间如果降到 0.5 以下大概率过拟合了验证集生成会开始胡言乱语。4. 微调后的模型怎么用推理部署与效果验证4.1 合并 LoRA 权重并导出推理模型训练完的 LoRA 权重需要合并回基座模型才能独立部署from peft import PeftModel from transformers import AutoModelForCausalLM, AutoTokenizer base_model AutoModelForCausalLM.from_pretrained( deepseek-ai/DeepSeek-R1-Distill-Qwen-7B, torch_dtypebfloat16, device_mapauto ) model PeftModel.from_pretrained(base_model, ./output/deepseek-r1-telecom-lora) model model.merge_and_unload() model.save_pretrained(./merged/deepseek-r1-telecom) tokenizer.save_pretrained(./merged/deepseek-r1-telecom)合并后模型大小和基座一致7B 的 bf16 权重约 14G。如果要用 vLLM 部署直接加载合并后的目录即可。基站侧如果要做边缘推理可以进一步用 GPTQ 或 AWQ 量化到 4bit显存降到 5G 左右单张 T4 就能跑。4.2 验证微调效果三个必须看的指标第一个是领域术语准确率。拿 100 条测试样本看模型输出的参数名、告警名、KPI 名是否和规范一致。微调前这个指标通常低于 60%微调后应该到 90% 以上。第二个是推理链完整度。看模型是否给出“现象→原因→建议”的完整结构而不是直接跳结论。这个靠人工抽检 50 条按完整、部分完整、缺失三档打分。第三个是建议可执行率。把模型输出的优化建议给运维人员判断是否可执行可执行率低于 70% 说明训练数据里的建议质量不够得回去补数据。def evaluate_model(model, tokenizer, test_samples): results [] for sample in test_samples: prompt f### Instruction:\n{sample[instruction]}\n\n### Input:\n{sample[input]}\n\n### Response:\n inputs tokenizer(prompt, return_tensorspt).to(model.device) outputs model.generate(**inputs, max_new_tokens512, temperature0.1) response tokenizer.decode(outputs[0], skip_special_tokensTrue) results.append({ prompt: prompt, response: response.split(### Response:)[-1].strip(), reference: sample[output] }) return resultstemperature设 0.1 是为了保证输出稳定基站优化建议不能有随机性。max_new_tokens设 512 覆盖大多数推理链长度超过的截断。4.3 基站侧部署的两种路径路径一集中式部署。模型跑在核心机房 GPU 服务器上基站侧通过北向接口把 KPI 和告警数据传上来推理结果回传。适合省级或地市级网络优化中心优点是算力集中、模型更新方便缺点是对传输时延有要求。路径二边缘式部署。模型量化后跑在基站侧边缘计算节点上本地推理本地执行。适合对时延敏感的场景比如实时切换参数调整。缺点是算力受限只能跑 4bit 量化的小模型。我一般建议先走集中式验证效果后再考虑边缘下沉。别一上来就追求边缘部署模型还没调好就折腾部署架构本末倒置。5. 避坑记录基站侧微调最容易翻车的五个地方5.1 数据泄漏导致评估虚高现象验证集 loss 降到 0.3生成质量看起来很好但上线后效果一塌糊涂。原因同一小区的不同时间段数据被分到了训练集和测试集模型记住了小区特征而不是学到通用规律。解决按小区 ID 划分数据集确保同一小区数据只出现在一个集合里。5.2 推理链截断导致模型只学结论现象微调后模型输出很短直接给建议没有推理过程。原因cutoff_len设太小训练时推理链被截断模型只学到后半段结论。解决统计训练数据 token 长度分布cutoff_len设为 95 分位以上基站侧任务一般 2048 够用推理链特别长的设 4096。5.3 学习率过高导致灾难性遗忘现象微调后模型在电信域任务上表现好但通用对话能力完全丧失连基本指令都理解不了。原因学习率设太大或者训练轮数太多LoRA 权重覆盖了基座能力。解决学习率降到 1e-4训练轮数控制在 3 轮以内LoRA rank 不要超过 32。如果已经遗忘了降低 LoRA 权重缩放系数或者重新用更小学习率训练。5.4 告警数据未去重导致过拟合现象模型对某类告警的根因判断特别准但对其他告警完全没反应。原因训练数据里某类告警样本重复太多模型偏向预测高频类别。解决按告警根因去重每个根因保留不超过 50 条确保类别均衡。5.5 量化加载与 LoRA 训练不兼容现象4bit 量化加载基座后训练报错提示某些层不支持梯度计算。原因bitsandbytes 量化层默认不参与梯度更新需要额外配置。解决用prepare_model_for_kbit_training处理模型开启gradient_checkpointing确保 LoRA 层可训练。from peft import prepare_model_for_kbit_training model prepare_model_for_kbit_training(model) model get_peft_model(model, lora_config)6. 进阶技巧用验证集 loss 曲线判断该不该继续训练微调最怕两件事欠拟合和过拟合。欠拟合就是模型没学到东西过拟合就是模型把训练数据背下来了。判断方法看验证集 loss 曲线但基站侧任务有个特殊之处验证集 loss 和生成质量不完全正相关。有时候 loss 还在降但生成已经开始重复或者格式错乱。我一般同时盯三个信号。第一个信号是验证集 loss 的拐点。正常情况训练 loss 和验证 loss 同步下降验证 loss 降到最低点后开始反弹反弹点就是最佳停止点。如果验证 loss 一直不降说明学习率太小或者数据质量有问题。第二个信号是生成样本的重复率。每 200 步抽 10 条验证样本生成统计 n-gram 重复率。重复率超过 30% 说明模型开始退化即使 loss 还在降也得停。第三个信号是格式合规率。基站侧输出有固定格式要求比如必须包含“推理”和“建议”两个段落。格式合规率低于 80% 说明模型在偏离训练分布。def check_generation_quality(model, tokenizer, val_samples, step): repeat_count 0 format_ok 0 for sample in val_samples[:10]: inputs tokenizer(sample[instruction], return_tensorspt).to(model.device) outputs model.generate(**inputs, max_new_tokens256, temperature0.1) text tokenizer.decode(outputs[0], skip_special_tokensTrue) # 检查格式 if 推理 in text and 建议 in text: format_ok 1 # 检查重复 words text.split() if len(words) 0: unique_ratio len(set(words)) / len(words) if unique_ratio 0.5: repeat_count 1 print(fStep {step}: 格式合规率{format_ok/10:.2f}, 重复率{repeat_count/10:.2f})这个检查函数每 200 步跑一次和 loss 曲线对照看。如果格式合规率突然掉到 0.5 以下不管 loss 多低都该停了。我自己的习惯是验证 loss 连续 3 次评估不降或者格式合规率连续两次低于 0.7直接停训练回滚到上一个保存点。别跟曲线较劲基站侧数据噪声大过拟合比欠拟合更难救。希望帮到你。本文还有配套的精品资源点击获取 DeepSeek-R1 基站侧微调实战：5G 网络优化 LoRA 微调与部署
简介这份PDF文档聚焦电信网络优化场景系统讲解DeepSeek-R1模型在5G基站部署中的微调技巧面向通信工程师、网络优化人员及对AI落地感兴趣的开发者帮助解决5G基站覆盖、容量与网络质量调优中的实际问题。资源包共1个文件为1.73MB的PDF文档内容完整、目录清晰涵盖模型基础介绍、适配分析、数据预处理与参数微调、效果评估指标及实际案例等模块并配有图表辅助理解。文档从5G基站部署挑战切入逐步展开DeepSeek-R1的架构原理、兼容性分析、学习率与批次大小调整、层结构与神经元数量微调等操作要点最后通过真实案例展示优化方案制定与效果评估流程。已有63人学习适合希望将大模型技术应用于电信网络优化的读者参考可帮助快速建立从理论到微调实践的完整认知。1. 电信网络优化遇上 DeepSeek-R15G 基站侧微调到底在调什么5G 基站每天都在吐海量数据小区级 KPI、MR 测量报告、告警日志、信令跟踪、工参配置。传统做法是靠专家写规则、拉阈值、做关联分析一套流程跑下来问题定位周期动辄按天算。现在把 DeepSeek-R1 这类推理大模型放到基站侧做网络优化核心诉求不是让它“聊天”而是让它读懂 KPI 劣化模式、告警因果链和参数配置之间的隐性关系直接给出可执行的优化建议。但通用模型对电信域术语、基站拓扑约束、3GPP 参数取值范围几乎没概念直接问它“某小区上行干扰抬升怎么调”回答大概率是泛泛而谈。所以必须做微调而且是带着 5G 基站领域数据做垂直微调。这篇文章面向的是已经有一定深度学习基础、手头有基站侧数据、想用 DeepSeek-R1 做网络优化微调的工程师。我会把选型理由、数据构造、LoRA 微调参数、部署验证和踩坑记录按可复现的路径讲清楚不绕弯子。2. 为什么选 DeepSeek-R1 做基站侧微调选型逻辑与数据准备2.1 基站侧微调为什么优先考虑 DeepSeek-R1 而不是通用小模型电信网络优化场景对模型的要求比较特殊。第一它需要多步推理能力一个 KPI 劣化往往不是单一原因可能是邻区干扰、切换参数不合理、天馈接反、甚至传输闪断模型得能沿着因果链往下推。第二它需要理解结构化数据MR 报告里的 RSRP、SINR、TA 分布KPI 里的掉线率、切换成功率、上行 PRB 利用率这些数值之间的关联不是简单查表能覆盖的。第三它需要输出可执行建议不是“建议检查邻区”而是“将某小区到某邻区的 CIO 从 2dB 调整为 4dB同时把 A3 偏置从 2 调为 3”。DeepSeek-R1 的推理链能力在开源模型里属于第一梯队尤其是它的长思维链输出天然适合做“现象→推理→建议”这种三段式任务。相比 Qwen 系列R1 在复杂因果推理上的表现更稳相比同规模稠密模型R1 的 MoE 架构在推理成本上更有优势。如果你手头 GPU 资源有限又不想牺牲推理深度R1 是目前比较务实的选择。当然如果你的场景只是做 KPI 异常检测这种分类任务那用 Qwen3 0.6B 做 LoRA 微调就够了没必要上 R1。选型的第一原则是任务复杂度决定模型规模不是反过来。2.2 基站侧微调数据从哪来四类数据源与构造方法微调数据质量直接决定模型能不能用。基站侧数据通常散落在几个地方网管 KPI 报表、MR 测量报告、告警系统、工参配置库。我一般按下面四类来构造指令数据。第一类是 KPI 劣化归因。输入是一组小区级 KPI 时间序列输出是劣化原因排序和对应优化建议。数据来源是网管历史报表需要人工标注或半自动关联告警和工参变更记录。第二类是告警根因分析。输入是告警序列和关联 KPI输出是根因告警和处置步骤。这类数据可以从工单系统里回溯把已解决的工单还原成指令对。第三类是参数配置推荐。输入是场景描述覆盖、容量、干扰输出是推荐参数集。这类数据需要专家经验但量不用大几百条高质量样本就能见效。第四类是信令流程解读。输入是信令跟踪摘要输出是异常环节定位。这类数据最难拿但价值最高。构造格式统一用 Alpaca 风格{ instruction: 某5G小区上行PRB利用率持续高于80%同时上行干扰噪声抬升6dB邻区切换成功率下降3%。请分析原因并给出优化建议。, input: 小区ID: NR_00123, 频段: 2.6GHz, 带宽: 100MHz, 当前CIO: 2dB, A3偏置: 2dB, output: 推理上行PRB利用率高且干扰抬升优先排查外部干扰和邻区上行冲突。切换成功率下降说明干扰已影响测量精度。建议1. 调整该小区到邻区的CIO至4dB减少边缘用户切换失败2. A3偏置调整为3dB提前触发切换3. 排查2.6GHz频段外部干扰源。 }注意输出里必须包含推理过程不能只给结论。R1 的微调如果只喂结论推理能力会退化。数据量方面LoRA 微调通常 5002000 条高质量样本就能看到明显效果。关键是覆盖度每个 KPI 劣化模式至少 20 条每个告警类型至少 10 条。数据划分按 8:1:1 切训练、验证、测试注意同一小区的数据不能同时出现在训练集和测试集否则评估结果会虚高。2.3 数据清洗的三个硬标准基站数据脏起来是真的脏。我踩过的坑包括KPI 时间戳对不齐、MR 采样点缺失、告警去重没做导致同一根因重复出现。清洗时盯住三条时间对齐到 15 分钟粒度、缺失值超过 30% 的样本直接丢、告警序列按根因去重。别心疼数据量脏数据喂进去模型学到的就是错的关联。3. LoRA 微调实战从环境搭建到训练脚本3.1 环境准备与基座模型加载我一般用 LLaMA-Factory 做微调框架它对 DeepSeek-R1 的支持比较完整配置驱动改参数不用动代码。环境依赖conda create -n deepseek-r1-ft python3.10 conda activate deepseek-r1-ft pip install torch2.1.0 transformers4.40.0 peft0.10.0 datasets2.18.0 pip install llama-factory基座模型加载用 HuggingFace 格式如果显存不够用 4bit 量化加载from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig bnb_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_compute_dtypebfloat16, bnb_4bit_quant_typenf4 ) model AutoModelForCausalLM.from_pretrained( deepseek-ai/DeepSeek-R1-Distill-Qwen-7B, quantization_configbnb_config, device_mapauto ) tokenizer AutoTokenizer.from_pretrained(deepseek-ai/DeepSeek-R1-Distill-Qwen-7B)这里选 7B 蒸馏版而不是满血 R1原因是基站侧微调通常不需要 671B 的通用能力7B 蒸馏版在推理任务上保留得比较好单卡 24G 就能跑 LoRA。如果你有 A100 80G可以直接上 32B 版本效果更稳。3.2 LoRA 参数怎么设rank、alpha、target_modules 的取值逻辑LoRA 的核心参数就三个rank、alpha、target_modules。rank 决定低秩矩阵的秩越大容量越强但越容易过拟合。基站侧任务我一般从 rank16 起步数据量超过 2000 条可以加到 32。alpha 通常设 rank 的 2 倍即 alpha32。target_modules 要覆盖注意力层的 q_proj、k_proj、v_proj、o_proj以及 FFN 层的 gate_proj、up_proj、down_proj。只调 q_proj 和 v_proj 在电信域任务上不够FFN 层承载了大量领域知识。from peft import LoraConfig, get_peft_model lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) model get_peft_model(model, lora_config) model.print_trainable_parameters()学习率设 1e-4 到 2e-4cosine 调度warmup 比例 0.03。batch size 根据显存来7B 模型 4bit 量化下单卡 24G 可以跑 batch_size4梯度累积 4 步等效 batch_size16。训练轮数 35 轮多了必过拟合。评估指标看验证集 loss 和生成质量loss 不降或者生成开始重复立刻停。3.3 训练脚本与关键参数说明用 LLaMA-Factory 的配置文件方式model_name_or_path: deepseek-ai/DeepSeek-R1-Distill-Qwen-7B stage: sft do_train: true finetuning_type: lora lora_rank: 16 lora_alpha: 32 lora_dropout: 0.05 lora_target: all dataset: telecom_kpi_sft template: deepseek cutoff_len: 2048 max_samples: 2000 overwrite_cache: true preprocessing_num_workers: 8 output_dir: ./output/deepseek-r1-telecom-lora logging_steps: 10 save_steps: 200 plot_loss: true overwrite_output_dir: true per_device_train_batch_size: 4 gradient_accumulation_steps: 4 learning_rate: 1.5e-4 num_train_epochs: 3 lr_scheduler_type: cosine warmup_ratio: 0.03 bf16: true gradient_checkpointing: truecutoff_len设 2048 是因为基站侧指令数据里 KPI 序列和推理链比较长512 会截断。template必须选 deepseek否则特殊 token 对不上。gradient_checkpointing开起来省显存代价是训练慢 20% 左右。save_steps设 200 是为了方便回滚LoRA 权重文件小多存几个不占地方。训练启动llamafactory-cli train config/telecom_lora_sft.yaml跑起来之后盯 loss 曲线。正常情况 loss 从 2.0 左右降到 0.81.2 区间如果降到 0.5 以下大概率过拟合了验证集生成会开始胡言乱语。4. 微调后的模型怎么用推理部署与效果验证4.1 合并 LoRA 权重并导出推理模型训练完的 LoRA 权重需要合并回基座模型才能独立部署from peft import PeftModel from transformers import AutoModelForCausalLM, AutoTokenizer base_model AutoModelForCausalLM.from_pretrained( deepseek-ai/DeepSeek-R1-Distill-Qwen-7B, torch_dtypebfloat16, device_mapauto ) model PeftModel.from_pretrained(base_model, ./output/deepseek-r1-telecom-lora) model model.merge_and_unload() model.save_pretrained(./merged/deepseek-r1-telecom) tokenizer.save_pretrained(./merged/deepseek-r1-telecom)合并后模型大小和基座一致7B 的 bf16 权重约 14G。如果要用 vLLM 部署直接加载合并后的目录即可。基站侧如果要做边缘推理可以进一步用 GPTQ 或 AWQ 量化到 4bit显存降到 5G 左右单张 T4 就能跑。4.2 验证微调效果三个必须看的指标第一个是领域术语准确率。拿 100 条测试样本看模型输出的参数名、告警名、KPI 名是否和规范一致。微调前这个指标通常低于 60%微调后应该到 90% 以上。第二个是推理链完整度。看模型是否给出“现象→原因→建议”的完整结构而不是直接跳结论。这个靠人工抽检 50 条按完整、部分完整、缺失三档打分。第三个是建议可执行率。把模型输出的优化建议给运维人员判断是否可执行可执行率低于 70% 说明训练数据里的建议质量不够得回去补数据。def evaluate_model(model, tokenizer, test_samples): results [] for sample in test_samples: prompt f### Instruction:\n{sample[instruction]}\n\n### Input:\n{sample[input]}\n\n### Response:\n inputs tokenizer(prompt, return_tensorspt).to(model.device) outputs model.generate(**inputs, max_new_tokens512, temperature0.1) response tokenizer.decode(outputs[0], skip_special_tokensTrue) results.append({ prompt: prompt, response: response.split(### Response:)[-1].strip(), reference: sample[output] }) return resultstemperature设 0.1 是为了保证输出稳定基站优化建议不能有随机性。max_new_tokens设 512 覆盖大多数推理链长度超过的截断。4.3 基站侧部署的两种路径路径一集中式部署。模型跑在核心机房 GPU 服务器上基站侧通过北向接口把 KPI 和告警数据传上来推理结果回传。适合省级或地市级网络优化中心优点是算力集中、模型更新方便缺点是对传输时延有要求。路径二边缘式部署。模型量化后跑在基站侧边缘计算节点上本地推理本地执行。适合对时延敏感的场景比如实时切换参数调整。缺点是算力受限只能跑 4bit 量化的小模型。我一般建议先走集中式验证效果后再考虑边缘下沉。别一上来就追求边缘部署模型还没调好就折腾部署架构本末倒置。5. 避坑记录基站侧微调最容易翻车的五个地方5.1 数据泄漏导致评估虚高现象验证集 loss 降到 0.3生成质量看起来很好但上线后效果一塌糊涂。原因同一小区的不同时间段数据被分到了训练集和测试集模型记住了小区特征而不是学到通用规律。解决按小区 ID 划分数据集确保同一小区数据只出现在一个集合里。5.2 推理链截断导致模型只学结论现象微调后模型输出很短直接给建议没有推理过程。原因cutoff_len设太小训练时推理链被截断模型只学到后半段结论。解决统计训练数据 token 长度分布cutoff_len设为 95 分位以上基站侧任务一般 2048 够用推理链特别长的设 4096。5.3 学习率过高导致灾难性遗忘现象微调后模型在电信域任务上表现好但通用对话能力完全丧失连基本指令都理解不了。原因学习率设太大或者训练轮数太多LoRA 权重覆盖了基座能力。解决学习率降到 1e-4训练轮数控制在 3 轮以内LoRA rank 不要超过 32。如果已经遗忘了降低 LoRA 权重缩放系数或者重新用更小学习率训练。5.4 告警数据未去重导致过拟合现象模型对某类告警的根因判断特别准但对其他告警完全没反应。原因训练数据里某类告警样本重复太多模型偏向预测高频类别。解决按告警根因去重每个根因保留不超过 50 条确保类别均衡。5.5 量化加载与 LoRA 训练不兼容现象4bit 量化加载基座后训练报错提示某些层不支持梯度计算。原因bitsandbytes 量化层默认不参与梯度更新需要额外配置。解决用prepare_model_for_kbit_training处理模型开启gradient_checkpointing确保 LoRA 层可训练。from peft import prepare_model_for_kbit_training model prepare_model_for_kbit_training(model) model get_peft_model(model, lora_config)6. 进阶技巧用验证集 loss 曲线判断该不该继续训练微调最怕两件事欠拟合和过拟合。欠拟合就是模型没学到东西过拟合就是模型把训练数据背下来了。判断方法看验证集 loss 曲线但基站侧任务有个特殊之处验证集 loss 和生成质量不完全正相关。有时候 loss 还在降但生成已经开始重复或者格式错乱。我一般同时盯三个信号。第一个信号是验证集 loss 的拐点。正常情况训练 loss 和验证 loss 同步下降验证 loss 降到最低点后开始反弹反弹点就是最佳停止点。如果验证 loss 一直不降说明学习率太小或者数据质量有问题。第二个信号是生成样本的重复率。每 200 步抽 10 条验证样本生成统计 n-gram 重复率。重复率超过 30% 说明模型开始退化即使 loss 还在降也得停。第三个信号是格式合规率。基站侧输出有固定格式要求比如必须包含“推理”和“建议”两个段落。格式合规率低于 80% 说明模型在偏离训练分布。def check_generation_quality(model, tokenizer, val_samples, step): repeat_count 0 format_ok 0 for sample in val_samples[:10]: inputs tokenizer(sample[instruction], return_tensorspt).to(model.device) outputs model.generate(**inputs, max_new_tokens256, temperature0.1) text tokenizer.decode(outputs[0], skip_special_tokensTrue) # 检查格式 if 推理 in text and 建议 in text: format_ok 1 # 检查重复 words text.split() if len(words) 0: unique_ratio len(set(words)) / len(words) if unique_ratio 0.5: repeat_count 1 print(fStep {step}: 格式合规率{format_ok/10:.2f}, 重复率{repeat_count/10:.2f})这个检查函数每 200 步跑一次和 loss 曲线对照看。如果格式合规率突然掉到 0.5 以下不管 loss 多低都该停了。我自己的习惯是验证 loss 连续 3 次评估不降或者格式合规率连续两次低于 0.7直接停训练回滚到上一个保存点。别跟曲线较劲基站侧数据噪声大过拟合比欠拟合更难救。希望帮到你。本文还有配套的精品资源点击获取