all articles
dev · ZH

闭源大模型也能微调:不碰权重,照样把模型调成你的形状

Aug 3, 2026·12 min read·by Mr Panda·4 阅读

闭源大模型也能微调:不碰权重,照样把模型调成你的形状

去年我见过一个做跨境电商客服的团队,他们的系统提示词写到了 4000 多个 token——品牌语气、退换货政策、禁用词列表、二十几条 few-shot 示例,全塞在里面。每次调用都要带着这坨东西,延迟高、成本高,效果还不稳定:模型时不时忘记"不能承诺具体退款时间"这条规矩。

他们的第一反应是换开源模型自己微调。租 GPU、搭训练环境、折腾 LoRA,两周之后放弃了——效果不如 GPT-4o 直接裸调。

但问题是——谁说微调一定要拿到模型权重?

OpenAI、Google、Anthropic 这些闭源模型厂商,早就把微调做成了 API 服务:你上传数据,平台在云端训练,返回一个专属模型 ID,调用方式和原模型一模一样。整个过程你碰不到一行权重,但模型确实变成了你的形状。

这篇文章讲清楚三件事:闭源微调是怎么回事、什么时候该用、以及在主流平台上具体怎么做。


一、闭源微调到底在调什么

先破除一个误解:闭源微调不是"重新训练模型"。

主流平台背后用的基本都是参数高效微调(PEFT,Parameter-Efficient Fine-Tuning)技术,最典型的是 LoRA(Low-Rank Adaptation)。原理一句话说清:冻结原模型的全部参数,只在旁边挂一组很小的"适配器"矩阵,训练时只更新这组小矩阵。

打个比方:原模型是一台出厂设置的钢琴,LoRA 不改琴的内部结构,只是在琴键上加了一层定制的配重——琴还是那台琴,但手感变成了你要的样子。

这带来几个直接后果:

  • 你训练的不是模型,是一层薄薄的偏移量。 所以训练快、成本低,几百条数据、几十分钟就能跑完一轮。
  • 微调改变的是"行为",不是"知识"。 它擅长教模型输出格式、语气风格、任务套路,不擅长往模型脑子里灌新知识。想让模型知道你公司上周发布的新产品,该用 RAG,不是微调。
  • 微调后的模型仍然托管在厂商的云上。 你得到的是一个新的模型 ID,数据出不了平台,模型也带不走。

一句话:闭源微调买的不是模型所有权,是行为定制权。


二、先别急着微调:一个决策顺序

微调是手段,不是目的。在动手之前,按这个顺序过一遍:

第一步,把提示词工程做到极限。 清晰的指令、结构化的输出要求、三到五个高质量 few-shot 示例。大多数"模型不听话"的问题,在这一步就能解决。

第二步,考虑 RAG。 如果问题出在"模型不知道某些信息"——内部文档、实时数据、专有知识——那是检索的活,微调帮不上忙。

第三步,才轮到微调。 当你发现以下信号,微调才是对的工具:

信号 典型场景
提示词已经长得离谱,还是不稳定 few-shot 示例超过 10 条仍有漏网行为
需要严格的输出格式 固定 schema 的 JSON、特定标记语言、代码风格
需要独特的语气和人设 品牌客服口吻、特定作者文风
想用小模型替代大模型省钱 用微调后的 GPT-4o-mini 达到 GPT-4o 在单一任务上的水平
任务套路固定但难以言传 分类、改写、信息抽取这类"看例子比看说明书快"的任务

最后一条尤其值钱。微调最经典的商业用法,是把大模型在某个窄任务上的能力"蒸馏"进小模型:质量不掉,单价降一个数量级,延迟砍一半。

反过来,这几种情况微调基本没用:注入新知识(用 RAG)、扩大上下文窗口(做不到)、教会模型全新的推理能力(几百条样本教不会)。


三、主流平台横向对比

闭源微调目前有四个主要入口:

平台 可微调的代表模型 支持的方法 特点
OpenAI 微调 API GPT-4o、GPT-4o-mini、GPT-4.1 系列 SFT、DPO、RFT(推理模型) 生态最成熟,文档和工具链最完善
Google Vertex AI Gemini 2.x Flash / Pro 监督微调为主 和 GCP 生态绑定深,适合已在 Google 云上的团队
Amazon Bedrock Claude Haiku、Amazon Nova、Cohere 等 监督微调 目前微调 Claude 的主要途径,企业合规友好
Azure OpenAI 与 OpenAI 基本同步 SFT、DPO 面向需要 Azure 合规体系的企业

选择逻辑很简单:你在哪个云上,数据在哪里,就优先用哪家。 微调本身的技术差异,远小于数据搬迁和合规审批的成本。

如果没有云的包袱,从 OpenAI 开始是最省事的路径——下面的实操也以它为例。


四、实操:在 OpenAI 上完成一次微调

整个流程五步:准备数据 → 上传 → 训练 → 评估 → 上线。

第一步,准备数据

数据格式是 JSONL,每行一条完整的对话样本:

{"messages": [{"role": "system", "content": "你是品牌客服小舟,回答简洁,绝不承诺具体退款到账时间。"}, {"role": "user", "content": "退款什么时候到账?"}, {"role": "assistant", "content": "退款已在处理中啦~到账时间以银行处理为准,一般不会太久。有其他问题随时找我!"}]}

每条样本就是一次"示范":给定这个输入,我希望你这样输出。注意三点:

  • system 提示词要和线上使用时保持一致——训练时写什么,推理时就写什么
  • 最少 10 条就能启动训练,但实践中 50 到 100 条高质量样本才是起步线
  • 宁要 50 条精挑细选的样本,不要 5000 条从日志里随手导出的垃圾。 微调是模仿学习,你给它看什么,它就学什么,包括你数据里的错误

第二步,上传数据

from openai import OpenAI
client = OpenAI()

file = client.files.create(
    file=open("train.jsonl", "rb"),
    purpose="fine-tune"
)

这一步把训练文件传到平台,拿到一个文件 ID。

第三步,创建微调任务

job = client.fine_tuning.jobs.create(
    training_file=file.id,
    model="gpt-4o-mini-2024-07-18",
    hyperparameters={"n_epochs": 3}
)

超参数里最常动的是 epoch 数(数据过几遍)。默认值通常够用;样本少可以适当加,发现模型开始"背答案"(过拟合)就减。训练过程在后台跑,几百条数据一般几十分钟完成。

第四步,评估

训练完成后你会拿到一个专属模型 ID,形如 ft:gpt-4o-mini-2024-07-18:your-org:custom:xxxx

评估不要靠肉眼感觉,要在训练前就留出一份测试集——模型从没见过的 30 到 50 个问题,微调前后各跑一遍,对比通过率。更省力的做法是用一个强模型(比如 GPT-4.1 或 Claude)当裁判,批量给两组输出打分。

第五步,上线

调用方式和普通模型完全一样,只是把 model 参数换成你的专属 ID:

response = client.chat.completions.create(
    model="ft:gpt-4o-mini-2024-07-18:your-org:custom:xxxx",
    messages=[...]
)

没有部署、没有运维,原来的代码改一行就切换完成。


五、进阶:SFT 之外还有两条路

上面走的是最基础的监督微调(SFT,Supervised Fine-Tuning):给示范,学模仿。当 SFT 不够用时,还有两个工具:

DPO(Direct Preference Optimization),教模型"哪个更好"。 数据格式变成一个输入配一对输出——一个你偏好的,一个你不要的。适合那种"两个回答都算对,但我就是更喜欢这种说法"的场景:语气拿捏、详略取舍、安全边界。SFT 定义正确,DPO 定义品味。

RFT(Reinforcement Fine-Tuning),用评分器驱动推理模型进化。 你不提供标准答案,而是提供一个打分函数(grader),模型在训练中反复尝试、根据得分调整。适合有客观对错的专业任务——法律条文引用、医学编码、复杂规则校验。数据效率高得惊人,几十条带评分标准的样本就可能看到明显提升,但它只对推理系列模型开放,且调试评分器本身是个技术活。

大多数团队的路径是:SFT 解决 80% 的问题,效果到瓶颈了再上 DPO,RFT 留给真正高价值的专业场景。


六、闭源微调的账本和暗坑

成本结构分两块:训练费和推理费。 训练按 token 计费,几百条样本的一轮训练通常只要几美元到几十美元——真正的成本大头从来不是训练,是准备数据的人力。推理端,微调模型的单价高于同型号基础模型,但如果你是用微调小模型替代大模型,总账通常是大幅下降的。

再说几个容易踩的坑:

  • 模型是"租"的,不是"买"的。 厂商下线某个基础模型版本时,基于它的微调模型也会跟着退役,你需要在新版本上重训。把数据管道自动化,让重训成本趋近于零,这比任何单次微调都重要。
  • 数据出境和合规。 训练数据会上传到厂商的云,含用户隐私的数据要先脱敏。主流平台都承诺微调数据不用于训练他们自己的模型,但合规审查该走还是要走。
  • 微调会"钝化"模型的通用能力。 在窄任务上调得越狠,模型在任务外的表现越容易变形。生产架构上的对策是路由:微调模型只接它擅长的那类请求,其他流量走基础模型。
  • 别跳过基线。 永远先测清楚基础模型 + 好提示词能到什么水平,再决定微调。没有基线,你无法证明那几周的数据工程换来了什么。

写在最后

闭源微调把一件原本需要 GPU 集群和算法工程师的事,压缩成了"整理一份好数据 + 调一个 API"。技术门槛消失之后,剩下的竞争力只有一个:你比别人更懂自己的任务,更舍得在数据质量上下笨功夫。

模型是租来的,数据才是你的资产。

先把 50 条最能代表你业务的样本整理出来——这一步做完,你已经超过大多数还在犹豫的人了。

━━━ fin ━━━

If you read this far — thank you.
Come tell me what you thought on X.