任务微调模型兼顾端云部署与低成本

小模型能不能比旗舰模型更准？Exowatt 给出的答案是：在边界清楚、有可靠标签、能核验输出的任务上，可以。他们用微调后的 Qwen3-1.7B 做离线告警分类，用 Qwen3-14B 分析能源市场，两个任务都超过了参与对比的通用模型。

这篇 AWS 案例更值得程序员关注的，是成绩背后的工程路径：怎样把业务规则变成训练数据，怎样扩充样本而不污染标签，以及怎样让模型的回答接受程序检查。至于「便宜 49 倍」，需要连同评测范围和成本口径一起看。

小模型赢在哪里，先看任务有多窄

Exowatt 做的是可按需供电的模块化太阳能系统。旗舰产品 Exowatt P3 通过光学透镜收集太阳能，把能量以热的形式储存，再通过热机发电，可在电表后直接向数据中心供电，减少对电网接入排队的依赖。

他们需要 AI 处理的第一个任务，是现场告警分诊：读取设备状态和遥测数据，从固定类别中选出判断，附上证据；信息不足时明确弃答。它不要求模型自由发挥，而是要求模型熟悉这套硬件的运行逻辑。

现场还经常断网，没有 GPU。即使云端模型足够准确，只要必须联网调用，就无法持续覆盖这些设备。

团队最初尝试 Qwen3-8B 配合提示词和护栏，macro-F1 停在 0.735。macro-F1 可以理解为先分别计算各类别的识别成绩，再取平均，避免数量多的类别掩盖少数类别的问题。他们在 12 个数据集版本上训练了 13 个 Qwen3-8B 候选模型，仍未超过这个提示词基线。

最后胜出的是参数量约为其五分之一的 Qwen3-1.7B。微调后，它在 320 个测试案例上达到 0.911，高于 Claude Sonnet 4.6 的 0.698。

第二个任务同样受约束：Qwen3-14B 读取最近六小时、约 90 行市场数据，包括实时价格、日前预测和电网通知，在约四秒内识别五类市场事件，并为结论引用具体数据行。

它的 macro-F1 从基础模型的 0.415 提升到 0.975，超过 Claude Opus 4.7 的 0.625；在另一份时间更晚的测试集上，仍有 0.968。

这组结果支持的是「专用模型能在专用任务上胜出」，不能推导出小模型拥有更强的通用能力。

真正拉开差距的是数据变化，不是多跑几轮

告警模型的训练集只有 2,522 条：684 条经过验证的决策，加上 1,838 条通过审核的改写样本。原始决策来自生成的站点场景，并非原文明确披露的现场历史日志。

改写也不是让大模型随便扩写。团队要求保留决策、标签、证据引用和全部数字，只改变表达方式，再用确定性检查筛选。2,218 个候选中，1,838 个通过，生成费用约 $3.72。另外，一整个故障家族没有进入训练集，用来考察模型面对未见故障的表现，但原文未单独披露这一部分的成绩。

这一步有对照实验：只用 684 条原始决策，macro-F1 为 0.584；加入改写后达到 0.911。把原始数据重复训练 11 个 epoch，让训练步数与扩充数据的方案一致，也只有 0.879。

重复看同一批答案，确实能提高成绩，但没有覆盖更多表达方式有效。模型需要学会识别不同措辞里的相同判断条件。

能源市场模型采用了相似做法。团队从 ERCOT 五年历史数据中取材，涉及 12 张表、约 1.63 亿行记录，通过规则生成 25,000 个带标签样本，分为 22,000 条训练、1,000 条验证和 2,000 条测试数据。随后用 Claude Sonnet 4.6 改写文本，保持标签和数值字段固定，将训练集扩充到 86,281 行。

每个答案增加三种改写后，macro-F1 从 0.950 升到 0.975。最终训练使用 LoRA，也就是只训练少量适配参数的低秩适配方案，执行一个 epoch，rank 16、alpha 32，耗时约 8.5 小时。

这里还有一个原文细节需要保留疑问：前面的流程说明把告警改写模型写成 Qwen3-VL-235B，后面的数据说明却写成 Qwen3-235B。仅凭文章无法确定实际使用的是哪一个。

训练交给托管服务，输出仍要经过程序核验

Exowatt 采用 Amazon SageMaker AI serverless model customization，主要解决的是实验启动成本。

过去每次微调都要准备容器和训练配方，选择 GPU 实例，再等待对应容量。现在他们直接使用 SageMaker Public Hub 的开放权重模型和现成训练配方，按训练实际运行时间付费，不必自己安排 GPU 容量。

告警模型训练约 32 分钟，费用约 $20–$25。训练完成后，模型被量化为 8 位 GGUF，约占 1.71 GiB，通过 llama.cpp 运行在现场 Kubernetes 的 6 GiB pod 中，使用已有 CPU 服务器，也能运行在 t3.2xlarge 上。

能源市场模型选择 Qwen3-14B，除了任务效果，还因为它有现成 LoRA 配方、受 Amazon Bedrock Custom Model Import 支持，约 28 GiB 的体积也符合部署考虑。合并后的检查点约 14 分钟完成导入，按活跃时间以 $6.86/小时计费，没有空闲费用。

团队在六天内运行了 23 个训练任务，累计约 155 小时，最多四个任务并发，完成能源市场模型上线。文章另称，定制模型从实验到生产共用九天；这与六天描述的范围不同，不能混成一个周期。

不过，模型分数只是其中一层。两个模型都必须返回严格 JSON，结论引用输入中的具体数据行。后续程序逐项检查引用的来源、字段和值，无法与输入字面匹配的主张会被删除；告警模型还可以弃答。

结构化输出方便程序读取，证据核验才决定哪些内容可以交给操作员。

这也解释了作者为何强调流水线：从数据认证、微调、评估，到模型注册和部署，流程可以复用；边缘和云端使用不同模型，各自适配运行条件。

我的判断

我更认可这篇文章对数据和输出约束的重视。尤其是「固定标签与数字，只改写表达」以及训练步数相同的对照，比泛泛宣称微调有效更有说服力。

但两类任务都具备相当有利的前提：输出类别有限，业务规则比较明确，证据能够定位到输入行。能源市场标签本身就由规则产生。既然规则能生成标签，就应该把直接执行规则作为基线；文章没有给出规则系统、传统分类器或检索增强方案的完整对照，因此无法判断微调是不是总体投入最划算的选择。

「49 倍」也有明确口径：按 Amazon Bedrock 标价乘以实测回答 token 数，每 1,000 次回答，Qwen3-14B 为 $0.60，Claude Opus 4.7 为 $29.26。两者 macro-F1 差值为 0.35，95% 置信区间为 0.324–0.371。这个成本比较没有覆盖完整的数据准备、训练和维护投入。边缘端的 $0 则指没有计量式 API 或 GPU 推理费用，服务器和运维仍有成本。

证据检查同样有边界。引用真实存在，不代表分类推理一定正确。文章明确提到的自主运行是在云端站点副本上的影子模式，不能据此认定已经完成真实现场的无人控制验证。

至于 serverless 节省了多少日历时间，作者提供了实际交付周期，但「原本可能需要几个月」没有对照数据，应当视作团队经验判断。它移除了基础设施准备环节，无法替团队解决标签质量和评测设计。

能拿来做什么

• 如果你维护 Node 告警处理服务，可以先把任务收窄为固定分类、证据字段和弃答条件，并建立独立测试集，再决定是否需要微调。
• 如果已有可靠的业务决策样本，可以尝试只改写表达方式，并用程序检查标签、数字和引用是否保持一致；评估集应单独保留，避免改写样本混入。
• 在接入模型结果的后端服务中，可以把 JSON 格式校验与证据校验分开实现：前者检查字段结构，后者检查结论引用的字段和值是否确实存在于输入。
• 对必须离线运行的现场应用，可以参考 GGUF 与 llama.cpp 的 CPU 部署路径，但要用自己的输入长度、内存限制和延迟要求验证，不能直接套用文中的部署成绩。