使用应用数据微调模型：独立开发者指南

您构建了一个应用。它使用 AI API——也许是 OpenAI，也许是 Anthropic——而且运行良好。但 API 费用在攀升，延迟不可预测，您开始意识到模型为您的应用做的事情中，90% 是相同的狭窄任务重复数千次。您不需要一个通才天才，您需要一个专家。

在应用的实际数据上微调一个较小的模型，就是获得那个专家的方法。尽管 ML Twitter 上的讨论可能暗示其他，您不需要博士学位或 H100 集群来做到这一点。本指南为从未接触过模型训练的开发者逐步介绍整个过程。

为什么用您的数据微调很重要

通用前沿模型是出色的通才。它们能写诗、调试代码、总结法律文件、生成 SQL——全在同一个对话中。但这种通用性是有代价的：它们没有针对任何单一任务进行优化。

您的应用可能只需要模型把一件事做好。也许是分类支持工单，也许是从发票中提取结构化数据，也许是以特定语调生成产品描述。对于这样的任务，基于您数据微调的 3B 参数模型将持续优于 70B 通用模型——且成本和延迟只是一小部分。

微调不是让模型更聪明，而是让它更专注。

步骤 1：训练数据长什么样

微调的训练数据只是一组输入-输出对的集合，展示您希望模型执行的任务。如果您的应用向 API 发送提示并获得响应，您已经拥有原始素材。

标准格式是 JSONL——每行一个 JSON 对象：

{"input": "Classify this ticket: My order hasn't arrived in 2 weeks", "output": "shipping_delay"}
{"input": "Classify this ticket: The app crashes when I upload photos", "output": "bug_report"}
{"input": "Classify this ticket: Can I change my subscription plan?", "output": "account_inquiry"}

格式的具体细节取决于您的工具，但概念是通用的：告诉模型什么输入应该产生什么输出。

首先记录您的 API 调用。应用发送到 AI API 的每个请求和收到的每个响应都是潜在的训练示例。如果还没有日志层，添加一个，让它积累几周。

步骤 2：需要多少数据

最常见的问题——答案比你想象的少。

对于狭窄、定义明确的任务（分类、提取、重新格式化），1,000 到 3,000 个高质量示例通常足以看到相对于基础模型的显著改善。某些任务仅用 500 个示例就能收敛。

质量远比数量重要。一千个精心筛选的示例将优于一万个嘈杂的示例。重点关注：

• **多样性：**覆盖应用处理的全部输入范围，包括边缘情况
• **正确性：**训练集中的每个输出都应该是您希望模型产生的确切内容
• **一致性：**相似的输入应有一致格式的输出

如果您有 50,000 条 API 日志但其中一半包含错误或格式不一致，请无情地筛选。2,000 个干净示例胜过 20,000 个杂乱的。

步骤 3：选择基础模型

对于应用特定微调，较小的模型几乎总是正确的选择：

• **3B 参数：**快速推理，在消费级硬件上运行，适合分类和提取任务
• **7B 参数：**大多数应用的最佳点，处理生成任务良好，仍然在单个 GPU 上运行
• **13B+ 参数：**仅在输出质量至关重要的复杂生成任务中需要

从能合理处理任务的最小模型开始。微调 3B 模型需要几分钟，微调 13B 模型需要几小时。如果 3B 模型能达到 90%，就发布它继续前进。

步骤 4：微调过程

您不需要理解微调背后的数学就能有效使用它。以下是实际层面的关键：

**LoRA（低秩自适应）**是您将使用的技术。LoRA 不修改模型中所有数十亿参数，而是在特定层添加小型可训练矩阵。这意味着：

• 训练快速——分钟到小时而非天
• 内存需求低——7B 模型可以在 16GB VRAM 的单个消费级 GPU 上微调
• 输出是一个小型适配器文件（50-150MB），而非完整模型副本

训练循环本身很简单：模型看到您的输入-输出对，调整 LoRA 权重以更好预测预期输出，并在数据集上重复几遍（epochs）。两到四个 epochs 对大多数任务来说是典型的。

步骤 5：评估模型

在部署之前，您需要知道微调模型是否真的比当前设置表现更好。保留 10-20% 的数据作为测试集——模型在训练期间从未见过的示例。

在测试集上运行您当前基于 API 的解决方案和微调模型。比较：

• **准确率：**微调模型是否同等或更频繁地产生正确输出？
• **格式合规性：**它是否一致地遵循预期输出结构？
• **边缘情况：**它如何处理让通用模型出错的异常输入？

常见质量问题：

• **过拟合：**模型记忆训练示例而非学习模式。通过添加更多样化数据或减少训练 epochs 来修复。
• **格式漂移：**模型以不一致的格式产生正确答案。通过确保训练数据具有完美一致的格式来修复。
• **对陌生输入的幻觉：**模型对训练中未充分代表的输入类型自信地产生错误输出。通过扩展训练数据覆盖这些情况来修复。

步骤 6：部署模型

一旦模型通过评估，部署就是简单的部分。

**导出为 GGUF 格式。**GGUF 是使用 Ollama 和 llama.cpp 等工具本地运行模型的标准格式。微调适配器与基础模型合并为一个便携文件。

**使用 Ollama 运行。**安装 Ollama，加载 GGUF 文件，您就有了一个本地 API 端点，可以直接替换应用当前使用的云 API。更改应用配置中的端点 URL 即可上线。

**您获得的：**零按 token 计费、可预测的延迟、完全数据隐私、无速率限制。对于运行 SaaS 产品的独立开发者，从 API 调用切换到自托管微调模型可以降低 95% 以上的 AI 成本。

常见错误

**数据多样性不足。**如果训练数据只覆盖正常路径输入，模型在任何异常情况下都会失败。刻意包含边缘情况和错误场景。

**基础模型大小选错。**因为"越大越好"而从 70B 模型开始会浪费时间和金钱。从小开始，评估，只有当较小模型确实无法处理任务时才扩大。

**跳过评估。**没有适当测试集就部署等于盲飞。在对基线进行测量之前，您不会知道微调模型是否更好。

Ertas 如何让这变得容易

Ertas 专为希望获得微调好处而无需 ML 基础设施开销的开发者而设计。上传训练数据，选择基础模型，启动训练运行——无需 Python 脚本、无需 CUDA 调试、无需 YAML 配置文件。

平台处理数据验证、训练编排、评估指标和 GGUF 导出。从 API 日志到可部署模型，全程不离开浏览器。

对于独立开发者和小团队，这是"我应该某天微调"和本周实际发布微调模型之间的区别。

延伸阅读

• 您的 Vibe 编码应用的 AI 费用将爆炸——解决方案在这里
• 无需编写代码微调 AI
• 独立应用的自托管 AI