什么时候需要微调，什么时候改应用就够了

教材分类助手经常把两种类别混淆，团队准备微调模型。先查清错误发生在哪里：资料没取到、标签含义不清、输出字段不合法与模型映射能力不足，分别需要不同修复。微调改变参数，部署改变运行方式，都不能自动修复缺失的应用约束。

本课以合成分类任务讨论适配路径，再用一百万参数估算权重字节数。这个规模只用于算术演示，不代表选择了实际模型，也没有执行训练或 GPU 部署。

先建立可比较的基线

记录当前模型、提示、上下文、输出验证与测试样本。评估按错误类型展开：类别混淆、证据不足仍作答、输出遗漏、延迟超限和权限拒绝。固定同一批样本才能判断哪种修改有效；只看训练 loss 或几次展示答案，不能比较应用效果。

把业务错误与输入质量分开。如果源文档本身没有类别判断需要的信息，应允许未知；如果标签定义互相重叠，应先改任务。为正常输入与关键失败分支分别设定验收条件，并考虑误判成本。不同类别错误不一定具有同样严重程度。

保留独立测试集，不把它反复用作训练样本筛选。标注者需要一致的规则，分歧样本可以帮助发现任务模糊。数据不足或标签不可靠时，训练更久可能只把问题记得更牢。

根据错误选择适配路径

提示与上下文适合明确任务规则、补充少量示例和选择当前状态。检索适合提供会变化的外部知识，并保留来源与权限。微调适合在合适数据下改善某种任务映射、风格或格式行为。它不应被当成可精确更新与删除的事实数据库。

例如课程分类规则稳定、相似类别样本很多且标签可靠时，可以评估微调。若问题是最新课程政策缺失，优先检查检索和数据更新。若问题是 schema 漏字段，先修输出约束与验证。几种方法可以组合，但应保留各自贡献的证据。

推理部署则关心模型怎样被加载与服务，包括并发、资源、队列和版本。换服务框架不改变任务训练目标，可能改善特定运行条件，却不能保证分类准确度上升。把效果评估与服务性能评估分别报告。

训练数据需要按来源切分

Hugging Face Transformers 的训练资料说明，微调从已有预训练权重继续学习特定数据。实施前要确认模型许可、数据使用权限、任务形式与训练工具兼容条件。托管微调与自行训练有不同支持范围，不能混用参数或承诺。

按文档、作者、模板或时间等容易造成泄漏的单位切分。相邻段落和改写样本若跨训练与测试，可能高估泛化。训练、验证与测试的职责应清楚；新数据进入训练后，对原测试集是否仍独立要重新检查。

清理重复、纠正标签、检查类别比例，并记录处理版本。训练配置应保存基模型、tokenizer、输入模板、随机条件与适配文件。最终模型要重新跑拒绝、权限与无证据样本，不能只核对主要类别准确率。

LoRA 减少训练参数但仍有条件

LoRA 冻结基模型权重，用低秩矩阵表示可训练的更新。若一个权重矩阵的更新表示为两个较小矩阵的乘积，训练参数可以减少。低秩是假设与选择，并不保证在所有任务中无损保留全参数微调能力。

rank、目标模块和训练数据会影响结果与资源。论文在特定模型和任务上的结论，不能直接变成当前模型的性能保证。适配权重合并、量化与推理内核支持依赖具体实现，部署前应核对格式与版本。

适配文件往往还依赖基模型。仅保留一个 adapter 文件而丢掉准确基模型、模板与 tokenizer，可能无法重现行为。回滚时也需要恢复这一组相关产物，不能只换一个展示名称。

权重内存只是资源估算的一部分

权重存储可粗略按参数数乘位宽估算。实际运行还有量化元数据、激活、KV cache、临时工作区、框架和设备开销。上下文长度与并发变化会改变资源需求，所以单看模型文件大小不能判断机器是否能服务。

下面计算原始权重位数向上取整成字节，再加一项人为设定的开销。它不估算具体 KV cache，也不做真实部署规划。

def weight_bytes(parameters, bits):
    if type(parameters) is not int or type(bits) is not int:
        raise ValueError("integer sizes required")
    if parameters < 0 or bits <= 0:
        raise ValueError("invalid size")
    return (parameters*bits + 7)//8
assert weight_bytes(1000, 16) == 2000
assert weight_bytes(1000, 4) == 500
base = weight_bytes(1000000, 16)
overhead = 400000
assert base + overhead > base
print(base, base + overhead)

实际输出是 2000000 2400000。一百万参数每个十六位需两百万原始字节；加教学设定的四十万字节为二百四十万。这里使用十进制字节计数，并未换算成 MiB，也没有包括全部运行内存。

量化可以降低某些存储需求，但质量、内核支持与速度取决于方法和硬件。位宽更低不保证吞吐更高。训练资源还包含梯度与优化器状态，不能用这个仅计算推理权重的函数推断训练显存。

推理服务按真实负载验证

vLLM 提供用于模型服务的调度和内存管理能力，但当前文档的 latest 路径也可能是开发预览。选择实现时应固定版本并核对模型、量化格式和硬件支持，不把某个文档标题当成兼容保证。

用目标输入长度、输出长度、并发与请求比例测试。分别观察排队、首 token、总耗时、失败与资源占用，避免只报告一个吞吐数字。长请求与短请求混合会改变调度效果，容量限制也要覆盖下游调用与存储。

部署记录包括模型、适配、tokenizer、模板、服务版本与配置。设置受控灰度和停止条件，保留旧产物。升级后除了质量，还要检查拒绝状态、格式和工具参数，防止行为变化越过原有应用契约。

练习：用证据决定是否微调

列出分类助手的十个失败样本，按输入、知识、规则、模型行为和服务性能分类。为提示、检索与微调各写前提、验收方法和成本项，选择能直接修复主要问题的一个小实验。

验收时，训练与测试没有文档级重叠，修改前后的配置与样本可追溯，旧模型可以恢复。解释权重估算遗漏了什么，并为目标负载制定另行测量计划。若没有可靠标签或独立测试，结论应是先补证据，而不是宣称微调一定有效。