训练过程中，你需要关注两个关键指标来判断训练状态：训练损失（training loss）反映模型在训练数据上的表现，验证损失（evaluation loss）反映模型在未参与训练的验证数据上的表现。通过这两个指标的变化趋势，可以判断模型处于哪种状态：

常见问题

不适合蒸馏的场景及替代方案：

蒸馏在以下场景中即使推理成本不占优，仍然值得考虑：

• 延迟敏感：本地推理约 50ms，API 调用约 500ms，10 倍延迟差距在实时系统中影响显著
• 数据安全：员工的提问可能涉及内部人事信息，走外部 API 存在数据出域风险
• 离线场景：内网部署、无外网环境等无法调用云端 API 的场景
• 稳定性：不依赖外部服务的可用性和限流策略

部署决策

什么时候该用蒸馏，什么时候不该？

评估服务性能

为了评估部署后的模型服务性能，这里使用一个简单的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个超时错误。这是因为在并发量较高情况下，服务器的负载超过了其处理能力，性能的不足导致了部分请求超时。

云服务方案对比和决策推荐

在阿里云上部署模型时，选择不同的服务需要综合考虑业务需求、模型特性、技术能力、运维复杂度、成本等因素。以下是对上面几种常见的云服务部署方式的对比分析及选择建议：

在让大模型处理任务过程中，减少 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亿参数）规模的模型，如果出现过拟合，通常可以采取以下措施：

1. 增加数据量或数据多样性：引入更多高质量的微调或预训练数据。

2. 使用正则化技术：如增大 Dropout 比率、引入权重衰减（Weight Decay）。

3. 早停法（Early Stopping）：在验证损失开始上升的节点前停止训练，保存此时的模型参数。

4. 调整 LoRA 参数：如果是进行 LoRA 轻量化微调，可以尝试降低 LoRA 的秩（Rank, $r$）或 $\alpha$ 值，以减少可训练的参数量。

1. LoRA 的秩（rank，通常记为 r）

   • 秩越大，LoRA 引入的可训练参数量越多，模型表达能力越强，可以拟合更复杂、更多样的数据。

   • 秩越小，参数量越少，模型学习能力受限，容易欠拟合数据中的模式。

2. 数据量很小的场景

   • 数据量小 → 容易过拟合。

   • 如果此时增大秩（r），会让模型在有限样本上学到更多噪声和无意义的模式，进一步加剧过拟合，泛化能力更差。

   • 正确的做法一般是：数据量小 → 用小秩（r=4, 8 等），限制模型容量，减少过拟合风险。

3. 数据量大的场景

   • 数据量大 → 模型能力不足时会欠拟合。

   • 此时可以增大秩（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）。

• 反向传播： “追根溯源” —— 往回找原因，算出每个参数该负多少责（梯度）。

• 梯度更新： “知错就改” —— 迈出新一步，把参数往对的方向改（更新）。

如本文对您有用，捐赠和留言 将是对我最好的支持~
如愿意，请向朋友推荐本站，谢谢。

尊重他人劳动成果。转载请务必附上原文链接，我将感激不尽。

与《阿里云大模型ACP 笔记》相关的博文：

• 如何写出高质量的 Skill