训练过程中，你需要关注两个关键指标来判断训练状态：训练损失（training loss）反映模型在训练数据上的表现，验证损失（evaluation loss）反映模型在未参与训练的验证数据上的表现。通过这两个指标的变化趋势，可以判断模型处于哪种状态：
| 训练损失 | 验证损失 | 状态 | 含义 |
|---|---|---|---|
| 不降 / 上升 | 不降 / 上升 | 训练失败 | 学习率可能太高，模型无法学习 |
| 下降 | 下降 | 欠拟合 | 模型在学习，但还没学够，继续训练 |
| 下降 | 先降后升 | 过拟合 | 模型在”背题”，需要更多数据或减少训练轮次 |
| 趋于平稳 | 趋于平稳 | 训练成功 | 模型已经充分学习 |
| 参数 | 本课选值 | 调优方向 |
|---|---|---|
lora_rank |
8 | 训练数据 < 200 条可降到 4；> 2000 条或任务更复杂可升到 16 |
learning_rate |
5e-5 | loss 不降 → 调高到 1e-4；loss 震荡 → 调低到 1e-5 |
num_train_epochs |
5 | 验证损失开始上升 → 减少轮次；验证损失仍在下降 → 增加轮次 |
per_device_train_batch_size |
8 | 显存不足 → 减小到 4；显存充裕 → 增大可加速训练 |
常见问题
| 问题 | 原因 | 解决方法 |
|---|---|---|
| 训练损失不降 | 学习率太高 | 降低 learning_rate 到 1e-5 |
| 验证损失上升 | 过拟合 | 减少 epochs 或增加训练数据 |
| JSON 格式崩坏 | 训练数据中 JSON 格式不统一 | 检查数据格式一致性 |
| 意图遗漏 | 多意图样本占比不足 | 确保训练集中多意图样本 ≥ 30% |
| 显存不足 | batch_size 或 max_length 太大 | 减小 batch_size 到 4 |
不适合蒸馏的场景及替代方案：
| 场景 | 原因 | 替代方案 |
|---|---|---|
| 需要实时知识更新（如政策查询） | 蒸馏模型的知识固化在训练时刻 | 蒸馏做意图识别 + RAG 提供最新知识 |
| 需要多步推理（如数学证明） | 小模型推理能力有限 | 保留大模型，或用推理压缩蒸馏 |
| 教师模型本身表现不稳定 | 学生无法超过教师的上限 | 先优化教师的 prompt 或换更强的教师 |
| 基座模型已能基本完成需求 | 提升空间有限，投入产出不划算 | 权衡投入产出比，考虑直接使用基座模型 |
蒸馏在以下场景中即使推理成本不占优，仍然值得考虑：
- 延迟敏感：本地推理约 50ms，API 调用约 500ms，10 倍延迟差距在实时系统中影响显著
- 数据安全：员工的提问可能涉及内部人事信息，走外部 API 存在数据出域风险
- 离线场景：内网部署、无外网环境等无法调用云端 API 的场景
- 稳定性：不依赖外部服务的可用性和限流策略
部署决策
什么时候该用蒸馏，什么时候不该？
| 场景特征 | 推荐方案 | 原因 |
|---|---|---|
| 高频、固定域、结构化输出 | 蒸馏 | 小模型推理成本低，效果接近大模型 |
| 知识每天更新 | RAG | 蒸馏模型无法自动适应新知识 |
| 需要复杂推理 | 保留大模型 | 小模型推理能力有限 |
| 蒸馏 + RAG 混合 | 混合架构 | 蒸馏做预处理，RAG 做知识查询 |
评估服务性能
为了评估部署后的模型服务性能，这里使用一个简单的HTTP性能测试工具wrk来快速模拟压测请求并生成报告。下面以压测 POST /v1/chat/completions 接口为例，展示服务的相关性能指标。
首先，打开一个新的终端窗口，安装压测工具wrk的依赖包。注意：终端窗口是在步骤1中指定的目录下。
sudo apt update sudo apt install wrk
接着，准备POST请求所需要的Body数据。数据已放在./resources/2_9/post.lua文件，文件内容如下所示。
wrk.method = "POST" wrk.headers["Content-Type"] = "application/json" wrk.body = [[ { "model": "./model/qwen3-0.6b", "messages": [ {"role": "system", "content": "你是一个帮助助手。"}, {"role": "user", "content": "请告诉我2008年北京奥运会，中国队总共获得了多少枚金牌？"} ] } ]]
然后，在终端窗口执行wrk压测命令，分别设置chat接口的并发量(-c)为1和10，压测时间(-d)均为10s，观察两个实验的压测结果。
wrk -t1 -c1 -d10s -s ./resources/2_9/post.lua http://localhost:8000/v1/chat/completions wrk -t1 -c10 -d10s -s ./resources/2_9/post.lua http://localhost:8000/v1/chat/completions
wrk压测结果如下所示：
根据压测结果可见，随着并发量增加（1 -> 10），QPS提升了约6倍（3.30 -> 20.08），平均延迟增加了约30%（324.61ms -> 426.84ms）。特别地是，第二个压测实验中出现了2个超时错误。这是因为在并发量较高情况下，服务器的负载超过了其处理能力，性能的不足导致了部分请求超时。
云服务方案对比和决策推荐
在阿里云上部署模型时，选择不同的服务需要综合考虑业务需求、模型特性、技术能力、运维复杂度、成本等因素。以下是对上面几种常见的云服务部署方式的对比分析及选择建议：
| 服务名称 | 特点 | 适用场景 |
|---|---|---|
| 阿里云百炼 | 大模型专属平台，提供一键部署、模型优化、API调用管理，封装底层复杂性。 | 快速部署大模型（如千问系列），无需关注基础设施。 |
| 函数计算（FC） | Serverless 架构，按请求量计费，自动扩缩容，免运维。 | 适用于需要轻量级推理任务、低频访问场景（如定时任务、事件触发）。 |
| PAI-EAS | 模型在线服务平台，支持自定义模型部署，弹性扩缩容，监控等能力。 | 中小型深度学习模型（如图像分类、NLP），需弹性扩缩容和细粒度资源管理。 |
| GPU云服务器 | IaaS层资源，灵活安装任意框架和依赖，需手动管理运维。 | 自定义模型训练/推理，需要完全掌控环境（如复杂依赖、特殊硬件需求）。 |
| 容器服务ACK/容器计算服务ACS | Kubernetes集群部署，集成CI/CD、自动扩缩容、负载均衡。 | 复杂微服务架构、混合工作负载、大规模分布式推理或训练。 |
在让大模型处理任务过程中，减少 token 的输入和输出可以帮助模型缩减推理时间，从而加快响应速度，这对于实时性要求较高的应用场景（如对话系统、客服机器人）尤为重要。
-
输入端优化：精简输入内容，去除输入中的冗余信息或无关内容，只保留关键信息。例如，在对话系统中，可以通过预处理提取用户的意图和核心问题，而不是将整个对话历史输入模型。还可以对长文档或复杂输入内容生成摘要，作为模型的输入。这可以通过小型摘要模型或规则方法实现。
-
输出端优化：相对于输入端优化，输出端的优化往往更为重要，因为生成 token 的过程几乎总是最耗时的。最简单的优化方法就是通过提示词（prompt）明确要求模型生成简洁的回答。例如，”请用一句话回答”或”请非常简短地解释”。同时在结构化输出的场景中，可以尽可能优化输出内容，如去除重复性描述、缩短函数名等。
用户感知优化
除了上面介绍的几种提升 LLM 系统性能的原则外，还可以通过以下方法进一步提升用户在使用过程中的满意度。
2.2.1 流式输出
将生成的内容逐步返回给用户的技术，可以减少用户感知延迟、提高交互的流畅性，从而显著提升用户体验，尤其是在实时性要求较高的场景（如在线客服、语音助手）中。如果你的应用架构中使用了负载均衡，可能需要关闭缓存和数据压缩功能，避免流式输出失效。
2.2.2 分块处理
将任务分解为多个小块，分别处理并逐步返回结果。比如在 RAG 系统中，分块处理可以应用于检索和生成两个阶段：
- 将检索任务分解为多个子任务，例如按主题或数据源分块检索。
- 将生成任务分解为多个段落或句子，分别生成并返回。
2.2.3 展示任务进度
可以让用户了解当前系统的处理状态，减少因未知等待带来的焦虑感。在 RAG 系统中，可以通过进度条、加载动画或文字提示展示任务进度。例如：
- 在前端显示一个进度条，实时更新检索完成的比例。
- 显示生成进度（如”正在生成回答… 已完成 3/5 句话”）。
2.2.4 完善错误处理机制
这是确保系统稳定性和用户体验的关键。明确的错误处理机制不仅能够捕获和处理各种异常情况，还能通过返回友好的错误信息和重试建议，提升用户对系统的信任感和满意度。
- 分类错误和友好提示：根据问题分类返回精简结果或默认响应，其中友好的错误信息提示是非常有必要的，
- 清晰易懂：避免使用技术术语，确保普通用户也能理解。
- 具体明确：说明错误原因，并提供解决方案。
- 情感友好：语气温和，避免让用户感到挫败。
- 重试机制和降级：
- 自动重试：对于临时性错误（如网络抖动、服务短暂不可用），可以自动重试。注意设置最大重试次数和重试间隔，设置过大的重试次数和过短的重试间隔可能会增加额外的资源消耗。
- 错误降级：对于每种错误类型，设计相应的降级方案。如在返回错误信息的同时，提供重试按钮或操作指南。
2.2.5 提供用户反馈入口与持续改进
- 反馈入口：在界面中提供便捷的反馈渠道，鼓励用户提出意见或报告问题。
- 持续优化：通过分析用户反馈及用户行为数据，持续发现问题并优化。
系统性能提升 中介绍的很多方法不仅能降低延迟，提升性能，还能帮助你有效节约成本，包括：
- 用小模型替换大模型 ：不仅推理更快，同时也更便宜。
- 上下文缓存 ：高频重复的查询，将结果缓存起来，避免每次调用 LLM 的开销。（如千问系列模型 cache_token 单价为 input_token 单价的40%）
- 批量推理 ：通过合并或去重请求，减少不必要的模型调用。一般来说批量推理任务对时效要求不高，可以通过离线推理方式充分利用空闲计算资源进一步降低成本。（如百炼批量推理的计费仅为实时推理的50%）
- 减少 token 数量 ：降低计算资源的需求，从而节省硬件成本和能源消耗。
- 不让大模型处理所有任务 ：通过硬编码、预先计算等方式替换大模型推理可以有效降低成本。
上面这些方法比较通用，在实际业务部署中，通常有两种方式：自建环境和云上部署。自建环境初期成本高，且服务器采购流程长、维护难度大。相比之下，云上部署更适合初创企业及对成本敏感的业务。云部署将基础设施维护等任务交由云厂商处理，并能根据业务需求快速调整资源，实现高效利用。
-
过拟合（Overfitting）： 表现为训练损失持续下降，但验证损失开始上升。这意味着模型过于死记硬背训练集中的数据特征和噪声，导致其泛化能力下降，在未见过的验证集上表现变差。
-
欠拟合（Underfitting）： 表现为训练损失和验证损失都很高，且均无法有效地下降。说明模型还没有学到数据的核心规律。
-
正常/成功训练： 表现为训练损失和验证损失都在持续下降，并最终趋于稳定（收敛）。
应对过拟合的常见方法
对于 1.5B（15亿参数）规模的模型，如果出现过拟合，通常可以采取以下措施：
-
增加数据量或数据多样性：引入更多高质量的微调或预训练数据。
-
使用正则化技术：如增大 Dropout 比率、引入权重衰减（Weight Decay）。
-
早停法（Early Stopping）：在验证损失开始上升的节点前停止训练，保存此时的模型参数。
-
调整 LoRA 参数：如果是进行 LoRA 轻量化微调，可以尝试降低 LoRA 的秩（Rank, $r$）或 $\alpha$ 值，以减少可训练的参数量。
-
LoRA 的秩（rank，通常记为 r）
-
秩越大，LoRA 引入的可训练参数量越多，模型表达能力越强，可以拟合更复杂、更多样的数据。
-
秩越小，参数量越少，模型学习能力受限，容易欠拟合数据中的模式。
-
-
数据量很小的场景
-
数据量小 → 容易过拟合。
-
如果此时增大秩（r），会让模型在有限样本上学到更多噪声和无意义的模式，进一步加剧过拟合，泛化能力更差。
-
正确的做法一般是：数据量小 → 用小秩（r=4, 8 等），限制模型容量，减少过拟合风险。
-
-
数据量大的场景
-
数据量大 → 模型能力不足时会欠拟合。
-
此时可以增大秩（r=32, 64 甚至更高），让 LoRA 有足够容量学习数据中的丰富模式。
-
批大小（Batch Size） 指的是在模型训练的单次迭代中，同时送入模型进行前向传播和反向传播的样本数量。它对训练的方方面面都有着直接或间接的影响：
-
每次更新时考虑的数据量：Batch Size 直接决定了模型在计算一次梯度并更新权重时，看过了多少条数据。
-
内存/显存使用（Memory Usage）：Batch Size 越大，意味着显卡需要同时缓存更多的激活值（Activations），因此显存占用会呈线性或接近线性的增长。在大模型（如 Qwen2.5）训练中，Batch Size 往往受限于硬件显存大小。
-
收敛速度（Convergence Speed）：
-
较大的 Batch Size：梯度计算更稳定、噪声小，方向更准确，可以允许使用更大的学习率，从而在总的 Epoch 数量上更快地收敛。
-
较小的 Batch Size：梯度计算随机性大（带来一定的噪声），虽然每步更新较快，但由于路线曲折，通常需要更多的迭代次数才能收敛。
-
-
正向传播： “大惊失色” —— 往前看结果，算出我们差了多少（Loss）。
-
反向传播： “追根溯源” —— 往回找原因，算出每个参数该负多少责（梯度）。
-
梯度更新： “知错就改” —— 迈出新一步，把参数往对的方向改（更新）。
如您从本文得到了有价值的信息或帮助，请考虑扫描下方二维码捐赠和鼓励。
如本文对您有用，捐赠和留言 将是对我最好的支持~
如愿意，请向朋友推荐本站，谢谢。
尊重他人劳动成果。转载请务必附上原文链接，我将感激不尽。