Qwen3-8B微调实测：LLM路由需要更多数据吗？

把每个AI请求都交给最贵的模型处理，是一种常见的成本浪费。从JSON里提取一个字段、格式化一段文本，和调试复杂算法、分析系统设计问题，对推理能力的要求完全不同。LLM路由（LLM Routing）要解决的就是这个问题：在处理请求之前，先判断它有多难，再决定交给哪个模型。

一位开发者用Qwen3-8B做了一个名为Complexity Scorer的实验项目——微调模型给prompt打0.00到1.00的复杂度分数，再根据分数路由到便宜模型或高级推理模型。实验结果里有一个反直觉的发现：用50条数据微调的模型，准确率反而高于用2500条数据微调的版本。

Complexity Scorer是什么？

这个项目的核心思路很直接：模型不回答用户的问题，只评估问题的复杂度。分数映射大致如下：

分数	难度	典型任务
0.00	琐碎	提取值、格式化文本
0.25	简单	执行几个直白步骤
0.50	中等	组合信息与约束条件
0.75	困难	分析权衡与复杂需求
1.00	极难	跨复杂系统的深度推理

整个流程是：用户prompt → Complexity Scorer打分 → Model Router → 便宜模型或高级推理模型。目标是削减不必要的API开销，同时不牺牲回答质量。

从工程角度看，这个设计的价值在于把"判断难度"和"完成任务"解耦。路由器可以独立迭代、独立评估，不需要动下游的生成模型。

开放权重模型（Open-weight Models）指模型参数可公开下载、允许用户自行部署和微调的模型，与闭源API模型（如GPT-4、Claude）相对。Qwen3-8B即属于此类，其权重可自由获取，因此作者能通过Tinker对其做监督微调。开放权重的优势在于任务定制自由度高、数据不出本地、可复现性强；代价是需要自行承担推理硬件与运维成本。值得注意的是，开放权重并不等同于开源——部分模型仅开放权重而保留训练数据与代码，使用时需留意许可证条款。

微调实验结果：50条打赢2500条

项目使用Tinker对Qwen3-8B进行微调，并与原始模型对比。评估集固定为50条样本，所有实验共用同一套评估数据。

实验	训练样本数	准确率
原始Qwen3-8B	0	50%
微调模型	50	86%
微调模型	500	74%
微调模型	2,500	76%

最终模型（2500条训练）达到76%准确率，比原始模型的50%提升了26个百分点。但只用50条样本训练的模型在这套评估集上拿到了最高的86%。

这个结果不能简单理解为"少即是多"。作者自己给出了几条解释，值得逐条拆开看。

合成数据的标签一致性

训练样本由AI生成，而AI生成的复杂度标签可能前后不一致：两个相似的prompt被打上不同的分数，模型就很难学到清晰的类别边界。数据量越大，这种噪声被放大的机会也越多。

合成数据（Synthetic Data）指由大模型自动生成的训练样本，而非人工标注。在本项目中，AI负责为每条prompt生成0.00–1.00的复杂度分数作为标签。这种方式的成本远低于人工标注，但会引入标签噪声：生成模型对"中等"与"困难"的边界判断可能前后矛盾，导致相似prompt获得不同分数。监督微调依赖标签提供稳定的梯度信号，标签一旦不一致，模型学到的决策边界就会模糊。数据量增大时，矛盾样本的绝对数量随之上升，噪声对训练的干扰可能被放大，这正是作者解释"数据越多未必越好"的核心机制之一。

50条评估集太小

86%这个数字建立在50条评估样本上。样本量这么小，单个样本的得失就能让准确率跳动2个百分点，结果很可能反映的是模型"恰好适配了这50条"，而非泛化能力。

统计显著性指观察到的差异是否可能由随机波动造成。在50条样本的评估集上，每条样本权重高达2个百分点，两套模型准确率相差2%仅相当于一条样本的得失，无法排除偶然因素。要可靠区分74%与76%这样的差距，通常需要数百至上千条独立评估样本，并配合置信区间或假设检验。更严谨的做法是使用held-out数据集（训练中完全未接触的数据），否则模型可能通过记忆训练分布而虚高。作者在结论中将"更大的held-out评估"列为首要后续方向，正是对这一问题的方法论回应。

500到2500的提升只有一条样本

准确率从74%到76%，在50条评估集上只对应多答对1条。这个差异在统计上几乎没有意义，需要更大、更多样的评估集才能判断它是否真实。

作者在文末也明确提醒：小评估集限制了这些准确率结果的可推广性。这一点值得肯定——很多类似实验会略过这个限制。

API工程化：从模型到可用的服务

微调完成后，项目用.NET Minimal API把模型包装成服务，包含API key认证、限流、异常处理、与Tinker推理API的集成，以及一个浏览器端的playground用于测试prompt。模型适配器发布到了Hugging Face，供其他开发者复用。

这层工程封装的意义在于：复杂度评估成为一个独立服务，与最终回答用户问题的应用分离，各自演进。

代理指标（Proxy Metric）与真实目标（True Objective）的区分是评估路由系统的关键。分类准确率只是代理指标，它衡量的是"分数是否接近参考答案"，却无法反映"路由决策是否真正省钱且不降质"。真实目标是成本、延迟与质量三者的联合优化：一条被误判为简单的难题，可能因交给弱模型而产生错误回答，其代价远高于省下的那点API费用。因此有效的路由评估应引入混淆矩阵的成本加权版本，或直接测量端到端的每千次请求成本与用户满意度，而非孤立地看分类器在测试集上的分数。

为什么选择开放权重模型

用闭源模型处理每一次分类请求也是一种做法，但会引入额外的供应商依赖和推理成本。开放权重模型提供了另一种灵活性：针对特定任务微调、试验不同训练集、把模型分享给其他开发者、在兼容运行时上探索本地部署。

作者也保持了克制：本地部署仍需合适的硬件，开放权重本身不保证更低的总成本。这种表述比"开源一定省钱"的说法更接近现实。

这次实验留下的四条经验

优化真实目标，而非代理指标。 路由器要平衡推理成本、延迟，以及把难题误判给弱模型的风险。单纯追求复杂度分类准确率，不等于路由系统有效。

谨慎对待评估结果。 小测试集会让性能差异看起来比实际更显著。这是本次实验最直接的教训。

给AI工具设护栏。 能访问付费API或启动训练任务的自动化agent，应当有明确的支出上限和权限边界。

不要假设堆数据能解决一切。 更好的数据生成、一致的标签、更强的评估方法，可能比增加样本数量更有价值。

下一步值得做的验证

作者列出了几个方向：在更大的held-out数据集上评估、检验复杂度分数是否与真实任务难度相关、用真实推理成本和回答质量衡量路由决策、与更简单的分类方法对比、试验置信度阈值和回退机制。

其中最有价值的一条是复杂度分数与实际任务难度的相关性验证。如果模型给某类prompt打0.3分，但这类prompt实际上经常需要高级模型才能答好，那么分类器再"准"也没有意义。路由系统的最终指标应该是成本与质量的联合优化结果，而不是分类准确率本身。

常见问题

LLM路由适合什么规模的应用？ 当请求量和模型价差足够大，路由带来的节省超过路由本身的推理开销时，就值得做。小规模应用直接用规则或轻量分类器可能更划算。

为什么微调后准确率反而随数据量下降？ 本次实验的合理解释是合成数据标签不一致，加上评估集过小导致的波动。不能据此得出"数据越多越差"的普遍结论。

开放权重模型做路由一定比闭源便宜吗？ 不一定。作者明确表示开放权重不保证更低的总成本，硬件和运维开销需要单独计算。