Happy-LLM 学习笔记 11：小模型微调、Thinking Budget 和多模态拼接的工程启发

补充章节读下来，我最大的感受是：LLM 工程并不是只围着“更大的模型”转。真正落地时，常见问题反而是数据能不能出内网、成本能不能压住、延迟能不能接受、上下文格式是否稳定。大模型给了能力上限，但业务常需要可控、便宜、可部署的边界。

这几篇 Extra-Chapter 把几个主题串了起来：小模型微调、vLLM 推理预算、多模态拼接，以及 tokenizer、BPE、滑动窗口、词嵌入等数据处理。它们共同提醒我：效果很重要，但工程质量往往取决于输入怎么表示、参数怎么更新、推理怎么约束。

小模型微调不是退让

看到“微调 0.6B 小模型”时，我一开始也会本能地拿它和更强的大模型比较。但如果任务是投诉文本字段抽取、固定格式分类、内部工单流转这类窄场景，问题就变了：我们不一定需要最强通用模型，而是需要稳定输出、可本地部署、不会把敏感数据送到外部 API 的模型。

小模型的价值来自约束。数据敏感时，本地部署能降低泄漏风险；调用量很大时，推理成本和并发能力比单次效果更关键；任务清楚时，SFT 和 LoRA 可以把有限参数集中到具体格式和领域表达上。教程里用 Qwen3-0.6B 做信息抽取，并通过 LoRA 只训练很小一部分参数，适合做第一版验证。

关键不是“小模型一定够用”，而是先把任务拆窄：输入分布是否稳定，输出 schema 是否明确，失败样本能否收集。如果任务开放、含糊、强依赖复杂推理，盲目压模型规模会把问题藏到后续维护里。

Thinking Budget 是推理阶段的旋钮

Thinking Budget 让我重新看待“让模型多想一会儿”这件事。它不是简单把 max_tokens 调大，而是在推理阶段人为设置预算，用 stop 条件、计数逻辑和类似 Wait! 的提示，让模型在预算内继续展开思考，最后再输出答案。

这个方法的工程价值在于把质量、成本和延迟变成可调参数。复杂题多给预算，简单题少浪费 token；线上系统也可以按任务难度或实时负载动态分配预算。相比只改训练，test-time scaling 更像是在推理服务层加控制器。

但它不是万能开关。材料里的实验现象很有提醒意义：强行插入等待词可能让模型重复生成，甚至沿着错误思路继续走下去。预算只提供“继续生成”的机会，不保证模型真的会反思。因此上线时还要监控 token 消耗、重复率、超时率和分任务收益。

多模态拼接看接口

SmolVLM2 与 Qwen3-0.6B 的拼接微调很有工程味。表面上看是把视觉模块、特征映射层和文本模型接起来，实际每一步都在处理接口契约：图像 token 要不要被 tokenizer 拆开，chat template 如何表达图文输入，视觉特征如何映射到语言模型 hidden size，词表大小、image_token_id、eos_token_id 是否同步更新。

这类工作让我意识到，多模态不是给 LLM 外面贴一层图片输入。视觉编码器输出特征，语言模型接收嵌入后的 token 序列，connector 负责维度对齐，模板说明图像特征插在什么位置，训练数据还会决定模型学到的是“看图回答”还是“记住短答案模式”。

更细的地方是损失掩码和上下文长度。图像 token 会占掉大量上下文，截断策略没处理好，训练样本会直接失效；如果对图像占位符也计算损失，优化目标也会变乱。拼接能跑通，不代表训练目标正确。

数据处理决定输入

文本数据处理章节把基础链路重新串了一遍：分词把字符串切成 token，词表把 token 映射成 ID，特殊标记标识边界和控制信息，BPE 通过子词拆分缓解未知词问题，滑动窗口构造下一 token 预测样本，词嵌入和位置嵌入再把离散 ID 变成可计算向量。

这些内容看似基础，但和前面的微调、多模态、Agent 都连在一起。小模型微调依赖稳定的 prompt 和输出格式；多模态拼接要处理特殊图像 token；Thinking Budget 要准确统计 <think> 区间里的 token；RAG 和 Agent 也需要区分用户输入、工具结果和系统约束。

所以数据处理不是训练前的杂活，而是模型行为的入口设计。tokenizer、特殊标记、截断、padding、mask、位置编码，都会影响模型能看到什么、该学什么、在哪些位置计算损失。

工程启发：先写清楚约束

这篇收尾让我更倾向于把 LLM 项目先写成一份约束说明，而不是一上来就选最大模型。需要回答：任务是不是窄任务，数据能否出网，输出是否需要结构化，延迟预算是多少，是否要支持图片或工具调用，失败样本如何回流。

如果约束清楚，小模型微调、LoRA、Thinking Budget、多模态拼接和数据处理就不再是孤立技术点，而是一组可组合的工程手段。模型大小负责能力边界，数据格式负责学习目标，推理预算负责运行成本，接口对齐负责稳定性。重点不是把每个技术点都用上，而是在具体场景里知道该收紧哪里、放开哪里。

参考项目：https://github.com/datawhalechina/happy-llm
在线阅读：https://datawhalechina.github.io/happy-llm/