Foundry Fine-Tuning: open-source model expansion, MAI-Code, and shared multi-LoRA deployments

Today, Microsoft Foundry Managed Fine-Tuning is thrilled to unveil four exciting new open-source models, including the addition of MAI-Code-1.1-Flash to its Foundry resources, now available in public preview. Alongside these models, Multi-LoRA Managed Compute deployments are also entering public preview, allowing compatible adapters to share crucial base-model weights and GPU resources, eliminating the need for separate serving allocations for each one.

Muse-Glimmer-30B, qwen3.8-27b, qwen3.6-35b-a3b, and gpt-oss-120b are now part of Foundry’s managed open-source model series, offering supervised fine-tuning (SFT) support across all four options. This wide selection allows you to enhance your customization workflow with improved tool reliability, coding efficiency, or enhanced planning and reasoning abilities. Here’s a quick overview of what each model offers:

Utilise SFT to adapt these models to suit your specific application needs:

• Coding standards: adapt to your organisation’s specific library requirements and preferred coding practices.
• Structured outputs: JSON schemas and response extraction formats for downstream applications.
• Domain-specific workflows: tailored terminology, supportive tone, and classification strategies.
• Distillation: utilise teacher-generated example outputs to specialise a smaller model for your specific tasks.

All four models support reinforcement fine-tuning (RFT) if your workflow requires a more sophisticated, reward-driven optimisation approach.

In addition to the models mentioned earlier, we also introduce MAI-Code-1.1-Flash — the first Microsoft model designed for Managed Fine-Tuning within Foundry. With the base model available on GitHub Copilot, this compact and coding-focused model excels in software development tasks. Its focus on responsiveness and token efficiency makes it an ideal choice for edit-build-test cycles, where inspecting code and responding to feedback from compilers or tests is crucial for efficiency.

Currently, MAI-Code-1.1-Flash supports RFT only during this preview phase. You can utilize it to achieve measurable outcomes: whether that’s a change passing specific tests, using an internal library correctly, or meeting your repository’s acceptance criteria. Focus on rewarding correctness and the intended scope of changes instead of merely checking if the output matches a reference. This allows for multiple valid solutions while aligning the customisation with your engineering requirements.

Previously, outputs from Foundry’s managed fine-tuning were charged based on a serverless pay-as-you-go model: input/output token fees along with hosting costs for each fine-tuned deployment. Increased traffic meant higher usage fees; additional deployed variants led to added hosting expenses. With the introduction of Multi-LoRA adapter deployment on Managed Compute, compatible adapters can now share LoRA-enabled base deployments and GPU resources. You’ll be billed an hourly rate for this hardware instead of per-token inference charges, allowing multiple customizations to utilise a single serving allocation rather than incurring costs for separate GPU instances.

For instance, three task-specific qwen3.8-27b adapters can work together by sharing a LoRA-enabled base deployment while still being individually accessible. As long as their combined demand remains within limits, adding an adapter won’t trigger additional hardware bills. This approach avoids unnecessary duplication of the base-model’s serving capability and enhances efficiency by distributing traffic across variants, in contrast to paying separate serverless hosting fees for each.

However, running equipment incurs charges even when it’s not in use, so it’s essential to size according to cumulative concurrency and context lengths. If traffic spikes, you might need extra capacity, while retaining serverless options for sporadic workloads on eligible models. The managed compute deployment supports models like Muse-Glimmer-30B, the new Qwen models, and gpt-oss-120b. All adapters must align with the same base model and version, requiring a compatible LoRA-enabled template. An accelerator quota is also needed.

The addition of these models allows you to select a backbone suited for your specific tasks, while Multi-LoRA enables compatible customizations to share resources efficiently. These features come together in agent applications, where differing roles may require distinct model behaviours. For instance, a coding assistant and a code-review agent can operate with separate adapters on the same supported open-source base model yet share the same hardware to serve them.

Fine-tuning is all about personalising model behaviour, with the overarching aim of enhancing the agent application that utilises it. Ensure your tuned models are linked to your agent applications in Foundry and conduct evaluations alongside the tools, instructions, and workflows they’ll employ in real-world scenarios. This approach keeps customisation focused on achieving better application results, rather than solely improving training metrics.

Take advantage of these new capabilities for your agent’s next version. Start exploring Foundry Fine-Tuning today.