Fireworks Agent自动化LLM微调：将输出风格注入权重

自动化LLM微调：使用Fireworks Agent 从上下文窗口到权重

Andrej Karpathy (@karpathy) 最近将个人LLM Wiki描述为一种前AGI时代的记忆辅助工具——一个精心整理的笔记仓库，记录论文、工具和想法，当你希望模型基于这些内容进行推理时，可将它们读入上下文。

在他那条广为流传的推文中，Karpathy指明了顺理成章的下一步：“随着仓库不断增长，自然而然会考虑合成数据生成和微调，以便让LLM在权重中‘知道’这些数据，而不仅仅依赖上下文窗口。”

构建LLM知识库或LLM Wiki已经可以通过Claude Code或Codex这类Agent实现，但随着规模的扩大，这种方法很快就会变得低效且昂贵。对LLM进行微调以维护知识库通常是更高效的前进方向。

本文迈出了下一步，将Wiki的输出风格固化到权重中。在不到十分钟的GPU时间和几分钱的算力下，一个小型开源权重模型就能以Wiki使用的精确格式为新论文撰写摘要，无需复杂的系统提示、小样本示例或路由逻辑。部署后，摘要仅需一次快速调用即可返回，速度快到足以作为更大Agent循环中的内联步骤，而非批处理任务。更难的版本（将Wiki内容进行参数化知识注入）是Karpathy框架中的自然后续，我在文末将其视为未来工作。

有趣的部分不在于模型本身，而在于一个Fireworks AI Agent会话完成了整个流程（数据集检查、超参数扫描、完整训练、部署以及可用的推理端点）。Fireworks Agent是微调运行的自主编排层，你只需给出自然语言目标，它就会规划、执行并将决策门返回给你。整个流程可以通过你已有的编码Agent（Claude Code、Codex或类似工具）驱动，这也是我运行的方式。

这指向的更大图景是自我改进的LLM和Agent。一旦训练成为Agent循环中一个可调用的步骤，驱动你工作流的同一个编码Agent也可以启动微调运行，将重复出现的模式（Wiki的语气、编码风格、分类策略）固化到模型本身，从而在使用模型和改进模型之间形成闭环。

本文其余部分为完整操作指南。

本次运行的所有资源均可在配套仓库中找到，包括训练集和验证集（train.jsonl、val.jsonl、wiki-sft-2026.jsonl）、数据构建脚本（parse_2026.py、fetch_abstracts.py、build_jsonl.py）、pilot-agent.md斜杠命令、冒烟测试脚本（test_new_deployment.py）以及基线模型与微调模型对比代码（before_after.py）。请从 github.com/dair-ai/wiki-sft 获取，克隆到本地，指向你自己的语料库，并端到端复现运行。

为什么输出风格是正确的首个SFT目标

对于个人Wiki而言，高杠杆点在于一致性。读者通过形状识别摘要：一段引言的段落，指出作者所属机构和核心贡献，随后是三到五个要点，每个要点带有加粗的简短标签。一个有能力的基座模型可以通过精心设计的系统提示被引导进入这种格式，但失败的模式也很熟悉：它可能会恢复为标题式大标题、遗漏机构行、变动要点数量、掺入营销语言。

监督微调在参数层面解决了这个问题。一旦格式固化到权重中，每次生成默认就会符合要求，系统提示可以缩减为单个句子（甚至完全省去）。当数据集保持较小时，成本保持较低，而50到100个简洁风格化的样本通常就足以入门。

将工作交给Agent

大多数微调教程会引导你完成十个不同的步骤：格式化数据、上传、选择基座模型、决定LoRA秩和学习率、启动任务、解析日志、选择胜出者、在全量数据上重新训练、部署、冒烟测试。每一步都是出错的风险点，你最终自己扮演了调优Agent的角色。

Fireworks Agent颠覆了这一点。其接口是 firectl session create -n "<你的指令>"，其中 firectl 是Fireworks CLI。之后，你观察事件流，并在Agent提出决策时（如拟议计划或超参数扫描结果）响应门控。

Fireworks还提供了一个Claude Code斜杠命令（或者你可以将其格式化为Agent技能）pilot-agent.md（以前称为Pilot Agent），它封装了 firectl 命令并处理事件流、门控检测以及从最后时间戳恢复的逻辑。

完整操作指南

步骤0：设置

安装Fireworks CLI并确认你的账户。 在Fireworks仪表板中，创建一个具有Training Agent所需权限（允许它代表你启动训练作业和部署的角色）的服务帐户，然后生成与该服务帐户关联的API密钥。同时，创建一个单独的用户级API密钥用于推理和部署检查。将两者放入项目旁边的 .env 文件中。

步骤1：构建数据集

我使用的训练数据由基于DAIR.AI Top AI Papers of the Week Wiki的聊天格式记录组成，选自2026年每周排名前五的论文，并与arXiv摘要配对。三个小型Python脚本处理流程：parse_2026.py（Wiki转为结构化条目）、fetch_abstracts.py（arXiv摘要查询）和 build_jsonl.py（聊天格式组装）。聊天架构是标准的Fireworks形状：

最终输出为 train.jsonl 和 val.jsonl（以及供参考的合并文件 wiki-sft-2026.jsonl），大约90%的记录用于训练，10%用于验证。

步骤2：将数据集上传到Fireworks

确认数据集状态为 READY： 你将传递给Fireworks Agent的数据集路径形如 accounts/<你的账户>/datasets/wiki-sft-2026。

步骤3：启动Fireworks Agent

这是本次运行面向用户的全部配置，仅一条指令： 会话返回一个ID，如 1777224532-7ddb。流式传输事件： --wait 标志很重要；没有它，命令会转储现有事件后退出。Claude Code斜杠命令会为你处理这一点。

步骤4：批准计划并推广胜出者

Agent会呈现两个门控。第一个是计划，包含成本估算和三个并行扫描的超参数配置，以验证损失作为评估器；你批准后继续流式传输。 超参数扫描同时运行三个SFT作业，返回一个排名的表格；随后Agent呈现第二个门控，包含胜出配置。在我的运行中，前三个配置在评估损失上非常接近，这表明在这个数据集规模下，任务对超参数并不特别敏感，因此批准完整训练是显而易见的下一步。 完整训练大约需要八分钟的GPU时间，花费几分钱。

步骤5：验证部署

部署是临时微调工作流通常会出错的地方：选错加速器、形状不兼容、或因容量问题卡住。Agent会自行处理恢复，因此会话以状态 succeeded 结束，得到一个可用的、缩放到零的部署。使用以下命令确认部署：

步骤6：调用模型

推理使用标准的Fireworks聊天补全端点，并带有一个部署固定的模型ID，以便请求路由到你的自定义部署： 预热后，调用返回速度足够快，可以作为Agent内部的内联步骤，而非批处理任务。

为什么这个工作流值得

我在训练集之外的几篇论文上测试了微调后的模型，向基座模型 qwen3-8b 和微调模型发送相同的系统提示和摘要。微调模型生成了以所属机构为首的引文，点明研究人员的实验室，接着是三到五个带有加粗简短标签前缀（方法：、性能提升：、可扩展性：）的要点，以及分析性、非宣传性的语气。例如，在《思维链》上，它开头写道：“斯坦福大学的研究人员证明，思维链提示显著增强了大型语言模型的推理能力……”这正是Wiki的语气，固化在权重中，通过一次快速调用生成。

实际回报是：你不再需要一个大型、低效的LLM或Agent来为你的LLM Wiki编写摘要。一个较小的微调模型可以高效、低价地完成这项工作。针对这个用例，风格和语气的正确至关重要，再多的技能或系统提示调优也无法取代一个经过适当微调的LLM所能带来的效果。

还有两件事使这项工作超越一次性实验。第一，训练成为了一种工具，而非一个项目——一条CLI命令、几分钱的计算、最终得到一个真实可调的端点，而Agent负责处理枯燥的失败模式。第二，你拥有最终的模型。权重存在于你的账户中，部署在你控制的基础设施上，空闲成本为零。在这样低的成本和摩擦下，将SFT视为更广泛的风格和格式问题的合理解决方案就变得顺理成章。

下一步：权重中的知识

我故意停留在风格迁移，因为这是小数据集上最干净的SFT初始目标。Karpathy描述的更难的版本（你的Wiki内容在权重中）是自然的后续，涉及合成数据生成、更多训练记录和知识回忆评估器。

这种模式超越了个人论文Wiki。任何结构化知识表面（内部文档Wiki、产品手册、研究库）都可以成为相同两步配方（先用SFT学习风格，再在其上注入知识）的候选对象。一个将语料的语气和实质都内化了的模型，正是使其上的个性化Agent真正有用的关键。

Fireworks Agent目前处于私有预览阶段，即将公开发布。如果你正在考虑将这一工作流应用于你自己的语料库，并希望请求访问或与Fireworks团队讨论，请通过 fireworks.ai/contact-training 联系我们。