托管微调服务怎么选Expert LoRA、自动早停与成本对比原文Together AI 官方博客 - 《Together AI expands fine-tuning service with more models, live metrics, and finer controls》https://www.together.ai/blog/together-ai-expands-fine-tuning-service-with-more-models-live-metrics-and-finer-controls一、Agent 开发者为什么该关心托管微调Agent 主链路通常交给旗舰大模型这个选择基本不会错。但主链路外围总有一批「高频、低难度、强格式」的子任务工具调用参数纠错、意图分类与路由、固定 JSON 抽取、日志归因、检索结果的二次判定。这些任务用旗舰模型跑token 账单很难看而用托管微调把一个小模型训到够用往往是最省钱的一条路。真正的门槛不在「会不会调微调 API」而在实验循环本身你得知道模型到底学了什么、训练跑到哪一步了、哪个 checkpoint 最好、这一次要花多少钱。任何一环是黑盒微调就变成掷骰子。Together AI 在 2026 年 9 月 11 日发布的这次扩展正好是沿着这条循环补齐的。下面按「新增了什么」到「怎么用」的顺序拆一遍重点放在 Expert LoRA 这组实测数据上 —— 它解释了为什么标准 LoRA 有时候学不会新东西。二、这次扩展补齐了四个环节原文的自我总结很简洁支持最新的开源权重模型、实时实验跟踪、对训练与数据处理更细的控制、以及部分模型降价。对应到开发者的动作就是四步换更强的底座、在训练中就能看曲线、能验证数据到底喂进去什么、以及同样的实验花更少的钱。三、新支持的模型怎么选新增清单覆盖了从端侧小模型到旗舰 MoE 的完整区间。选型可以按三个方向看追前沿性能GLM-5.3 与 Kimi K2.7。原文给出的一个参考点是 GLM-5.3 在 Terminal-Bench 2.1 上得 88.2距离领先的闭源模型在 1 分以内。兼顾性能与成本Qwen 3.8-27B、Gemma 4 这类中等规模。端侧与本地部署Qwen 3.5 系列提供 0.8B 到 9B 的多个尺寸。本次新增的完整模型列表为GLM 5.3、GLM-5.2、GLM-5.1、DeepSeek-V4-Flash-0731、DeepSeek-V4-Flash、Kimi K2.7-Code、Kimi K2.6、Qwen 3.8-27B、Qwen 3.6-35B-A3B、Qwen 3.6-27B、Qwen 3.5-27B、Qwen 3.5-9B、Qwen 3.5-4B、Qwen 3.5-2B、Qwen 3.5-0.8B、Gemma 4-31B、Gemma 4-26B-A4B。平台负责处理不同架构带来的复杂度你提交训练任务即可。四、Expert LoRA 与标准 LoRA一组值得记住的实测对比这是我读完原文后觉得最有价值的一段。在一个 MoE混合专家模型里超过 90% 的参数、以及模型真正「知道」的大部分内容都住在 expert 层。而标准 LoRA 微调从来不碰这些层adapter 挂在 attention 上experts 保持冻结。也就是说你想让模型学一点新东西却只训练了它「怎么用已有知识」没训练它「记住新知识」的地方。Expert LoRA 允许把 adapter 直接挂到 expert 层本身。原文给了一组很干净的对照实验让模型学习 200 个虚构事实base 模型对这些事实完全不知道然后测召回。方案新知识召回率MMLU-Pro含 expert 层的 adapter最高 89%75.3%仅 attention 的 adapter最高 15%71.5%原文还给出了训练动力学层面的解释用仅 attention 的 adapter 时越来越多的 routed experts 会在训练过程中不再被使用相当于专家被「饿死」了而 expert adapter 能让整个 mixture 持续参与训练。副作用也很清楚 —— 它保留住了更多模型原有知识。启用方式并不复杂把 expert 模块加进lora_trainable_modules即可其余流程和普通 LoRA 任务一致// 训练配置片段字段名来自官方文档说明具体取值以官方文档为准 { model: GLM-5.3, method: lora, lora_trainable_modules: [ q_proj, k_proj, v_proj, o_proj, // 常规注意力层 mlp.experts // 关键把 expert 层纳入可训练范围 ] }判断你该不该开 Expert LoRA可以问一个问题这个任务需要模型记住 base 模型不知道的东西吗如果只是让模型按固定格式输出、按固定规则分类标准 LoRA 就够如果它要记住你们内部的术语表、私有工具的参数语义、某个业务领域的专有事实Expert LoRA 的差距会非常明显。原文那组 89% 对 15% 就是这种「真新知识」场景下的对比。五、live metrics训练过程中就能做决定越早看到一条训练轨迹就能越早做下一个决定 —— 改数据、调超参、或者让它跑完。现在每个训练与评估步都会记录指标并通过 API、CLI 和 UI 面板同时暴露。核心信号包括 loss、gradient norm、learning rate如果你提供了验证集evaluation loss 与指标会和训练指标一起被跟踪。面板上每个任务有一个 Metrics 标签页曲线在任务还在跑的时候就持续更新更实用的是可以多选几个任务把它们画在同一组坐标轴上 —— 一次超参扫描就变成一张图而不是十几个浏览器标签页。Python SDK 也能做同样的事一条命令在终端里出曲线不用切环境。API 直接返回底层序列支持按区间过滤或降采样方便拉进 notebook 或你们已有的内部看板。对接手的项目来说这意味着「训练中」不再是等待状态而是一个可以持续判断的阶段。六、训练控制早停、任意 batch size、打包开关自动早停。提供验证集并开启后平台会在每个评估点看验证 loss曲线走平时就停止训练把验证 loss 最好的 checkpoint 作为你的最终模型并自动退回你没用到的训练步。也就是说你拿到的是最好的模型而不是最后一个模型同时不为无效训练付费。patience、对小幅改进的敏感度、warmup 都可以调。任意 batch size。有些任务需要的 batch size 装不进显存 —— 长序列、大模型或者按经验调出来的大全局 batch。现在可以用gradient_accumulation_steps让梯度先在 micro-batch 上累积再做一次优化器更新有效 batch 等于 batch_size 乘以 gradient_accumulation_steps。打包packing控制。序列打包把多条序列拼成一条避免在 padding token 上浪费算力提高吞吐、缩短训练时间所以平台默认开启。但它并非总是对的数据集很小时打包会让每个 epoch 的优化步数太少。现在可以一个开关整体关掉或者在预分词数据格式里用position_ids控制打包程度。这三项合起来的意义是训练配方从「平台替你定」变成「你可以按实验目标调」。七、数据侧把黑盒变回可验证微调最常见的翻车方式不是超参不对而是数据没按你想象的样子喂进去 —— chat template 应用方式和你以为的不一样、label mask 位置错了、行被静默截断。以前这些都在 job 里黑盒运行出问题只能看到一个无法追溯的质量下降。这次扩展把这段打开了。训练前预览分词结果用你即将微调的那个 base 模型的 tokenizer 和 chat template预览任意已上传文件的行直接看到 token ID、token 字符串、逐 token 的标签、哪些片段计入 loss、以及这一行是否因超过模型最大序列长度被截断。预览在几秒内完成。训练后核对实际消费的数据每个任务都会暴露它完全准备好的数据子集已分词、已打包、已 collate与训练器收到的完全一致可以通过 Python SDK 或控制台的下载入口取回。服务端预检你的 JSONL 文件一上传完就启动完整的服务端校验结果落在文件对象上所以在创建任务之前就能看到问题不用等排队、调度、启动之后才发现。校验覆盖 message 结构与角色、工具定义与 tool-call / response 配对、reasoning 字段、多模态内容与图像解码、偏好对结构、样本权重的类型与范围错误信息会带上有问题的样本下标。校验成功时也会报告识别结果 —— 数据集格式、行数以及是否包含 sample weights、message weights、tools、parallel tool calls、reasoning traces、images让你确认平台是按你期望的方式读的数据。样本权重给 JSONL 里任意样本加一个weight字段训练时会按权重缩放该样本对 loss 的贡献。多来源混合数据集人工标注混合成数据、不同领域混在一起时这个能力比过滤更灵活且支持所有已支持的 JSONL 格式和训练方法。八、成本对比原文说明降价从 30% 起gpt-oss 系列最高可达 70%。LoRA adapter 训练的价格每 100 万 token对比模型SFT 原价SFT 现价DPO 原价DPO 现价Qwen3.5-9B0.480.341.200.84Qwen3.8-27B1.501.053.752.62gemma-4-31B-it1.501.053.752.62gpt-oss-120b5.002.5012.506.25gpt-oss-20b1.500.403.751.00同规模档位的降幅差异很明显27B 级从 1.50 降到 1.05降 30%而 gpt-oss-20b 从 1.50 降到 0.40降约 73%。对预算敏感的实验可以先用降价幅度大的模型把配方跑通再迁移到更强的底座上做最后一轮。九、接下来会有什么原文提到的下一步是每个中间 LoRA adapter 在微调还在进行时就可以部署。不必等整个训练任务结束第一个 adapter 保存下来之后就可以通过 Dedicated Model Inference 部署或者挂到一个已经在运行的 endpoint 上走 Multi-LoRA 配置省掉「每个实验一个独立 endpoint」的成本和启动时间。初期支持 GLM-5.3随后是 Kimi K3完整的 API 走查会随新流程发布一起给出。原文还给了一个客户案例Adaption 的 AutoScientist 把自动研究循环跑在 Together 的微调平台上支持 LoRA 与全量微调覆盖最高 1T 参数的模型评测跑在专用的 endpoint 上。这说明「托管训练 托管推理」这条链路已经能支撑到比较极端的规模。十、给 Agent 开发者的落地顺序先判断任务类型。格式与规则类任务用标准 LoRA 就够要注入 base 模型不知道的领域事实直接上 Expert LoRA。数据先过预检再开任务。JSONL 上传后看服务端校验报告确认工具调用配对、reasoning 字段、权重范围都没问题别把校验留到 job 里。用预览确认真实输入。挑几行看 token 级结果确认 chat template 和 label mask 与你的假设一致。用 10% 到 20% 的验证集配自动早停让平台替你挑 checkpoint而不是凭最后一个 checkpoint 交付。让扫描可读。多选任务画在一组坐标轴上再用 API 把序列拉进自己的看板形成可复盘的实验记录。以上模型清单、实测数字与价格均来自 Together AI 官方博客2026-09-11 发布部分 API 字段与参数取值请以官方文档为准文中训练配置片段为说明用示例不是可运行脚本。托管微调服务的产品迭代很快如果打算长期依赖某个能力建议在下单前回官方文档确认当前支持范围。 托管微调服务怎么选：Expert LoRA、自动早停与成本对比
托管微调服务怎么选Expert LoRA、自动早停与成本对比原文Together AI 官方博客 - 《Together AI expands fine-tuning service with more models, live metrics, and finer controls》https://www.together.ai/blog/together-ai-expands-fine-tuning-service-with-more-models-live-metrics-and-finer-controls一、Agent 开发者为什么该关心托管微调Agent 主链路通常交给旗舰大模型这个选择基本不会错。但主链路外围总有一批「高频、低难度、强格式」的子任务工具调用参数纠错、意图分类与路由、固定 JSON 抽取、日志归因、检索结果的二次判定。这些任务用旗舰模型跑token 账单很难看而用托管微调把一个小模型训到够用往往是最省钱的一条路。真正的门槛不在「会不会调微调 API」而在实验循环本身你得知道模型到底学了什么、训练跑到哪一步了、哪个 checkpoint 最好、这一次要花多少钱。任何一环是黑盒微调就变成掷骰子。Together AI 在 2026 年 9 月 11 日发布的这次扩展正好是沿着这条循环补齐的。下面按「新增了什么」到「怎么用」的顺序拆一遍重点放在 Expert LoRA 这组实测数据上 —— 它解释了为什么标准 LoRA 有时候学不会新东西。二、这次扩展补齐了四个环节原文的自我总结很简洁支持最新的开源权重模型、实时实验跟踪、对训练与数据处理更细的控制、以及部分模型降价。对应到开发者的动作就是四步换更强的底座、在训练中就能看曲线、能验证数据到底喂进去什么、以及同样的实验花更少的钱。三、新支持的模型怎么选新增清单覆盖了从端侧小模型到旗舰 MoE 的完整区间。选型可以按三个方向看追前沿性能GLM-5.3 与 Kimi K2.7。原文给出的一个参考点是 GLM-5.3 在 Terminal-Bench 2.1 上得 88.2距离领先的闭源模型在 1 分以内。兼顾性能与成本Qwen 3.8-27B、Gemma 4 这类中等规模。端侧与本地部署Qwen 3.5 系列提供 0.8B 到 9B 的多个尺寸。本次新增的完整模型列表为GLM 5.3、GLM-5.2、GLM-5.1、DeepSeek-V4-Flash-0731、DeepSeek-V4-Flash、Kimi K2.7-Code、Kimi K2.6、Qwen 3.8-27B、Qwen 3.6-35B-A3B、Qwen 3.6-27B、Qwen 3.5-27B、Qwen 3.5-9B、Qwen 3.5-4B、Qwen 3.5-2B、Qwen 3.5-0.8B、Gemma 4-31B、Gemma 4-26B-A4B。平台负责处理不同架构带来的复杂度你提交训练任务即可。四、Expert LoRA 与标准 LoRA一组值得记住的实测对比这是我读完原文后觉得最有价值的一段。在一个 MoE混合专家模型里超过 90% 的参数、以及模型真正「知道」的大部分内容都住在 expert 层。而标准 LoRA 微调从来不碰这些层adapter 挂在 attention 上experts 保持冻结。也就是说你想让模型学一点新东西却只训练了它「怎么用已有知识」没训练它「记住新知识」的地方。Expert LoRA 允许把 adapter 直接挂到 expert 层本身。原文给了一组很干净的对照实验让模型学习 200 个虚构事实base 模型对这些事实完全不知道然后测召回。方案新知识召回率MMLU-Pro含 expert 层的 adapter最高 89%75.3%仅 attention 的 adapter最高 15%71.5%原文还给出了训练动力学层面的解释用仅 attention 的 adapter 时越来越多的 routed experts 会在训练过程中不再被使用相当于专家被「饿死」了而 expert adapter 能让整个 mixture 持续参与训练。副作用也很清楚 —— 它保留住了更多模型原有知识。启用方式并不复杂把 expert 模块加进lora_trainable_modules即可其余流程和普通 LoRA 任务一致// 训练配置片段字段名来自官方文档说明具体取值以官方文档为准 { model: GLM-5.3, method: lora, lora_trainable_modules: [ q_proj, k_proj, v_proj, o_proj, // 常规注意力层 mlp.experts // 关键把 expert 层纳入可训练范围 ] }判断你该不该开 Expert LoRA可以问一个问题这个任务需要模型记住 base 模型不知道的东西吗如果只是让模型按固定格式输出、按固定规则分类标准 LoRA 就够如果它要记住你们内部的术语表、私有工具的参数语义、某个业务领域的专有事实Expert LoRA 的差距会非常明显。原文那组 89% 对 15% 就是这种「真新知识」场景下的对比。五、live metrics训练过程中就能做决定越早看到一条训练轨迹就能越早做下一个决定 —— 改数据、调超参、或者让它跑完。现在每个训练与评估步都会记录指标并通过 API、CLI 和 UI 面板同时暴露。核心信号包括 loss、gradient norm、learning rate如果你提供了验证集evaluation loss 与指标会和训练指标一起被跟踪。面板上每个任务有一个 Metrics 标签页曲线在任务还在跑的时候就持续更新更实用的是可以多选几个任务把它们画在同一组坐标轴上 —— 一次超参扫描就变成一张图而不是十几个浏览器标签页。Python SDK 也能做同样的事一条命令在终端里出曲线不用切环境。API 直接返回底层序列支持按区间过滤或降采样方便拉进 notebook 或你们已有的内部看板。对接手的项目来说这意味着「训练中」不再是等待状态而是一个可以持续判断的阶段。六、训练控制早停、任意 batch size、打包开关自动早停。提供验证集并开启后平台会在每个评估点看验证 loss曲线走平时就停止训练把验证 loss 最好的 checkpoint 作为你的最终模型并自动退回你没用到的训练步。也就是说你拿到的是最好的模型而不是最后一个模型同时不为无效训练付费。patience、对小幅改进的敏感度、warmup 都可以调。任意 batch size。有些任务需要的 batch size 装不进显存 —— 长序列、大模型或者按经验调出来的大全局 batch。现在可以用gradient_accumulation_steps让梯度先在 micro-batch 上累积再做一次优化器更新有效 batch 等于 batch_size 乘以 gradient_accumulation_steps。打包packing控制。序列打包把多条序列拼成一条避免在 padding token 上浪费算力提高吞吐、缩短训练时间所以平台默认开启。但它并非总是对的数据集很小时打包会让每个 epoch 的优化步数太少。现在可以一个开关整体关掉或者在预分词数据格式里用position_ids控制打包程度。这三项合起来的意义是训练配方从「平台替你定」变成「你可以按实验目标调」。七、数据侧把黑盒变回可验证微调最常见的翻车方式不是超参不对而是数据没按你想象的样子喂进去 —— chat template 应用方式和你以为的不一样、label mask 位置错了、行被静默截断。以前这些都在 job 里黑盒运行出问题只能看到一个无法追溯的质量下降。这次扩展把这段打开了。训练前预览分词结果用你即将微调的那个 base 模型的 tokenizer 和 chat template预览任意已上传文件的行直接看到 token ID、token 字符串、逐 token 的标签、哪些片段计入 loss、以及这一行是否因超过模型最大序列长度被截断。预览在几秒内完成。训练后核对实际消费的数据每个任务都会暴露它完全准备好的数据子集已分词、已打包、已 collate与训练器收到的完全一致可以通过 Python SDK 或控制台的下载入口取回。服务端预检你的 JSONL 文件一上传完就启动完整的服务端校验结果落在文件对象上所以在创建任务之前就能看到问题不用等排队、调度、启动之后才发现。校验覆盖 message 结构与角色、工具定义与 tool-call / response 配对、reasoning 字段、多模态内容与图像解码、偏好对结构、样本权重的类型与范围错误信息会带上有问题的样本下标。校验成功时也会报告识别结果 —— 数据集格式、行数以及是否包含 sample weights、message weights、tools、parallel tool calls、reasoning traces、images让你确认平台是按你期望的方式读的数据。样本权重给 JSONL 里任意样本加一个weight字段训练时会按权重缩放该样本对 loss 的贡献。多来源混合数据集人工标注混合成数据、不同领域混在一起时这个能力比过滤更灵活且支持所有已支持的 JSONL 格式和训练方法。八、成本对比原文说明降价从 30% 起gpt-oss 系列最高可达 70%。LoRA adapter 训练的价格每 100 万 token对比模型SFT 原价SFT 现价DPO 原价DPO 现价Qwen3.5-9B0.480.341.200.84Qwen3.8-27B1.501.053.752.62gemma-4-31B-it1.501.053.752.62gpt-oss-120b5.002.5012.506.25gpt-oss-20b1.500.403.751.00同规模档位的降幅差异很明显27B 级从 1.50 降到 1.05降 30%而 gpt-oss-20b 从 1.50 降到 0.40降约 73%。对预算敏感的实验可以先用降价幅度大的模型把配方跑通再迁移到更强的底座上做最后一轮。九、接下来会有什么原文提到的下一步是每个中间 LoRA adapter 在微调还在进行时就可以部署。不必等整个训练任务结束第一个 adapter 保存下来之后就可以通过 Dedicated Model Inference 部署或者挂到一个已经在运行的 endpoint 上走 Multi-LoRA 配置省掉「每个实验一个独立 endpoint」的成本和启动时间。初期支持 GLM-5.3随后是 Kimi K3完整的 API 走查会随新流程发布一起给出。原文还给了一个客户案例Adaption 的 AutoScientist 把自动研究循环跑在 Together 的微调平台上支持 LoRA 与全量微调覆盖最高 1T 参数的模型评测跑在专用的 endpoint 上。这说明「托管训练 托管推理」这条链路已经能支撑到比较极端的规模。十、给 Agent 开发者的落地顺序先判断任务类型。格式与规则类任务用标准 LoRA 就够要注入 base 模型不知道的领域事实直接上 Expert LoRA。数据先过预检再开任务。JSONL 上传后看服务端校验报告确认工具调用配对、reasoning 字段、权重范围都没问题别把校验留到 job 里。用预览确认真实输入。挑几行看 token 级结果确认 chat template 和 label mask 与你的假设一致。用 10% 到 20% 的验证集配自动早停让平台替你挑 checkpoint而不是凭最后一个 checkpoint 交付。让扫描可读。多选任务画在一组坐标轴上再用 API 把序列拉进自己的看板形成可复盘的实验记录。以上模型清单、实测数字与价格均来自 Together AI 官方博客2026-09-11 发布部分 API 字段与参数取值请以官方文档为准文中训练配置片段为说明用示例不是可运行脚本。托管微调服务的产品迭代很快如果打算长期依赖某个能力建议在下单前回官方文档确认当前支持范围。