Azure

Fireworks AI on Microsoft Foundry for Azure Inference

3 min read

Summary

Microsoft has launched a public preview of Fireworks AI on Microsoft Foundry, bringing high-throughput, low-latency open-model inference to Azure through a single managed endpoint. It matters because enterprises can now access models like DeepSeek V3.2, gpt-oss-120b, Kimi K2.5, and MiniMax M2.5 with Azure’s governance, serverless or provisioned deployment options, and bring-your-own-weights support—making it easier to move open-model AI from experimentation into production.

Need help with Azure?Talk to an Expert

Fireworks AI arrives on Microsoft Foundry

Introduction

Organizations adopting open models want more than raw performance—they need a practical way to run those models securely, govern them consistently, and move from testing to production without stitching together multiple tools. Microsoft’s new public preview of Fireworks AI on Microsoft Foundry is aimed at solving that problem by combining fast open-model inference with Azure’s enterprise management and governance capabilities.

What’s new

Microsoft Foundry now includes Fireworks AI as a public preview option for open model inference in Azure. The announcement positions Foundry as a centralized control plane for the full AI lifecycle, including model evaluation, deployment, customization, and operations.

Key updates include:

  • Public preview of Fireworks AI on Microsoft Foundry for high-throughput, low-latency open model inference
  • Access to supported open models through a single Azure endpoint in Foundry
  • Support for these models today:
    • DeepSeek V3.2
    • OpenAI gpt-oss-120b
    • Kimi K2.5
    • MiniMax M2.5
  • MiniMax M2.5 is newly added to Foundry with serverless support
  • Bring-your-own-weights (BYOW) support for quantized or fine-tuned models trained elsewhere
  • Deployment flexibility with:
    • Serverless, pay-per-token inference for rapid experimentation
    • Provisioned Throughput Units (PTUs) for predictable production performance

Microsoft also highlighted Fireworks AI’s large-scale inference capabilities, including internet-scale token processing and benchmark-leading throughput for open models.

Why this matters for IT and platform teams

For Azure administrators, AI platform teams, and enterprise architects, this reduces the operational complexity of supporting open models. Instead of building separate serving stacks or governance frameworks, teams can use Foundry as a single environment for model access, deployment, observability, and policy control.

This is especially relevant for organizations that want to:

  • Standardize on open models without vendor lock-in
  • Support custom fine-tuned models while keeping a consistent serving platform
  • Balance cost and performance across experimentation and production workloads
  • Apply enterprise governance and security controls to AI deployments in Azure

Admins and AI teams should:

  1. Review the Microsoft Foundry model catalog for Fireworks-hosted models.
  2. Evaluate whether serverless or PTU-based deployments best fit workload requirements.
  3. Test BYOW scenarios if your organization already has fine-tuned or quantized open models.
  4. Validate governance, observability, and operational requirements before production rollout.
  5. Track Microsoft’s additional guidance on model customization and lifecycle management in Foundry.

Fireworks AI on Microsoft Foundry gives Azure customers a stronger path to operationalizing open models at scale—without sacrificing performance, flexibility, or enterprise control.

Need help with Azure?

Our experts can help you implement and optimize your Microsoft solutions.

Talk to an Expert

Stay updated on Microsoft technologies

AzureMicrosoft FoundryFireworks AIopen modelsAI inference

Related Posts

Azure

SQL Server on Azure Local GA for Edge and Sovereign

Microsoft has announced general availability of SQL Server on Azure Local for both connected and disconnected environments. The release gives organizations a consistent way to run mission-critical SQL Server workloads close to their data, while supporting Azure Arc management, existing licensing benefits, and local AI scenarios with Foundry Local in preview.

Azure

Microsoft Fabric 2026: Copilot and Power BI Updates

At FabCon and SQLCon 2026, Microsoft announced new Microsoft Fabric and SQL innovations focused on grounding Copilot and agents in trusted enterprise data. Highlights include Fabric IQ integration with Microsoft Copilot, agentic app creation in Power BI Desktop, Fabric Apps enhancements, and new observability and database management capabilities.

Azure

Azure VM Lifecycle Policy: New Stages for Modernization

Microsoft has introduced a clearer Azure Virtual Machine lifecycle policy to help customers plan infrastructure transitions with more transparency and predictability. The new framework defines Current, Extended, End of Life, and Retired stages for key VM families, along with guidance, availability expectations, and modernization tools for affected workloads.

Azure

Microsoft Foundry Adds Voice Agents and GPT-6

Microsoft Foundry has expanded its AI agent platform with broader model choice, native voice agents, and tools for continuous optimization. The update gives Azure teams more flexibility to evaluate frontier models like GPT-6 and Claude Opus 5.5, build multilingual voice experiences, and improve agent quality, latency, and cost over time.

Azure

Claude Opus 5.5 in Microsoft Foundry for AI Agents

Microsoft Foundry now offers Claude Opus 5.5, Anthropic’s latest model aimed at long-running coding, knowledge work, and agent-based workflows. The update matters to Azure teams because it adds adaptive reasoning, clearer agent communication, and new capabilities for managing long-context tasks in production.

Azure

Azure Resilience Drift: Why Diagrams Are Not Enough

Microsoft is urging organizations to treat resilience as a continuously validated operational capability, not a one-time architecture exercise. The article highlights how configuration drift, AI dependencies, and untested failover paths can undermine resilient designs even when architecture diagrams still look correct.