本文是对 Microsoft Foundry 博客一篇公告的分析。事实部分均以原文为依据，作者判断会明确标注。
这次更新说了什么
公告包含三件事：托管微调新增四个开源模型，首次提供微软自家的 MAI-Code-1.1-Flash，以及 Multi-LoRA 托管计算部署。三者均处于公开预览阶段。
四个新增开源基座
新增模型为 Muse-Glimmer-30B、qwen3.8-27b、qwen3.6-35b-a3b 和 gpt-oss-120b，均支持监督微调（SFT）和强化微调（RFT）。文章对它们的定位各有侧重：工具调用的稳健性、长程研究与规划、代码仓库与前端编码，以及比 gpt-oss-20b 更高的推理余量。
我的看法是，这份定位更适合当作初筛线索。真正选型仍需要用自己的数据和评测集做对比，而不是依据一句能力描述。
文章列举的 SFT 场景包括：团队编码规范、结构化输出、领域流程与话术，以及用教师模型的回答蒸馏出更小的模型。
MAI-Code-1.1-Flash：只开放 RFT
这是 Foundry 托管微调中第一个微软自家的模型。文章称其基础模型已在 GitHub Copilot 中提供，侧重响应速度和 token 效率，适合反复的编辑、构建、测试循环。预览阶段仅支持 RFT。
这决定了使用方式：需要先把目标写成可验证的结果，例如通过任务测试、正确使用内部库、满足仓库验收检查。文章建议奖励围绕正确性和改动范围设计，而不是是否复现某个参考补丁。这一点对奖励函数的设计要求不低，我认为是落地时的主要工作量。
Multi-LoRA：用硬件共享换计费方式
此前，微调产物部署到无服务器按量付费端点，按 token 计费，另加每个部署的托管费。新的托管计算路径让兼容的适配器共享同一个启用 LoRA 的基座部署和 GPU 容量，按小时为硬件付费，而不是按 token 付费。
文章举例：三个面向不同任务的 qwen3.8-27b 适配器可以共用一个基座部署，同时各自可单独寻址。代价是硬件空闲时同样计费，所以需要按总并发和上下文长度估算容量。流量间歇的场景，在符合条件的模型上仍可使用无服务器方式。
前提条件包括：适配器必须与基座模型及版本一致，基座部署需要兼容 LoRA 的模板，并且需要加速器配额。该路径支持 Muse-Glimmer-30B、两个新 Qwen 模型和 gpt-oss-120b。
作者分析：如果同一个基座上有多个适配器、流量稳定，共享部署更可能划算；若只有一个低频的微调变体，常驻 GPU 的成本未必低于无服务器。具体拐点取决于定价与负载，原文没有给出数字，需要自行测算。
对智能体应用的意义
文章把这些能力放在智能体场景下：编码助手和代码评审智能体可以使用同一基座上的不同适配器，共享底层硬件。文章也强调，应把微调后的模型接入 Foundry 中的智能体应用，与其指令、工具和流程一起评估，而不是只看训练指标。
值得继续观察
- 预览结束后的正式定价、区域与配额情况。
- 单个基座上能稳定承载多少适配器，延迟如何变化（推测，原文未提供数据）。
- MAI-Code-1.1-Flash 之后是否会开放 SFT。
原文链接：https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/foundry-fine-tuning-open-source-model-expansion-mai-code-and-shared-multi-lora-d/4565915
- 作者:月明
- 链接:https://lunalight.top//article/azure-foundry-2026-10-23-4565915
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
