Microsoft expanded the Foundry model catalog on August 19, 2026, with DeepSeek-V4-Flash-0731 and NVIDIA Nemotron 3.5 Lightning.

The release is notable for more than two model names. It gives teams several ways to consume and operate the same model families:

• DeepSeek-V4-Flash-0731 directly from Azure

• DeepSeek-V4-Flash-0731 through Fireworks on Foundry

• NVIDIA Nemotron 3.5 Lightning through Fireworks on Foundry

• NVIDIA Nemotron 3.5 Lightning through the Hugging Face collection on Foundry managed compute

• BF16 and NVFP4 Nemotron formats for different training and inference priorities

This turns model selection into a two-part decision: which model meets the workload's quality requirements, and which deployment path meets its support, governance, performance, customization, and cost requirements.

The New Models Target Agentic Workloads

DeepSeek-V4-Flash-0731 is positioned for coding agents, tool use, and workflow automation.

Microsoft reports substantial gains over the prior DeepSeek V4 Flash release in Foundry, including a DeepSWE benchmark change from 7.3 to 54.4 and a Terminal Bench increase from 61.8 to 82.7.

Those figures indicate a promising direction, but benchmark results are not production evidence. Teams need to reproduce the relevant tasks with their repositories, tools, prompts, policies, and failure conditions.

NVIDIA Nemotron 3.5 Lightning targets tool calling, long-context processing, multilingual work, structured output, and multi-step execution. Those capabilities align with agents, retrieval-augmented generation, workflow automation, and high-throughput assistants.

The word “Lightning” suggests an emphasis on efficient inference, but speed must be measured across the complete application path, including retrieval, tool calls, safety, network, and output validation.

Direct from Azure Changes the Support Boundary

DeepSeek-V4-Flash-0731 is available as a Foundry Model sold directly by Azure.

Microsoft documentation says models in this category are hosted and operated by Azure, billed through the Azure subscription, covered by Azure service-level agreements, and supported by Microsoft.

This route is attractive when teams want a familiar Azure commercial and operational boundary. It can simplify vendor onboarding, billing integration, support escalation, identity, and platform governance.

“Sold by Azure” does not mean every model behaves like an Azure OpenAI model. API capabilities, regional availability, quotas, safety behavior, lifecycle, input limits, and supported deployment types remain model specific.

Confirm the catalog details for the selected region and deployment before designing a production dependency.

Fireworks on Foundry Adds a Partner Deployment Path

Both new model families are also available through Fireworks on Foundry.

Microsoft describes Fireworks deployments as running inside the Foundry project with Azure governance and access controls. Teams can begin with pay-per-token serverless consumption and move to provisioned throughput when traffic becomes predictable.

The Fireworks path also supports bringing fine-tuned weights into the same catalog and endpoint model.

This option can help teams balance rapid evaluation, throughput, fine-tuning, and reserved capacity without building the complete serving stack themselves.

The commercial and support boundary differs from Direct from Azure. Review the partner terms, data handling, availability, support routing, billing, model lifecycle, and incident responsibilities before standardizing on the route.

The Same Model Through Two Routes Is Not the Same Service

DeepSeek-V4-Flash-0731 can be reached directly from Azure or through Fireworks. The model name may be the same, but the surrounding service can differ.

Compare:

• Regions and data-zone options

• Authentication and endpoint format

• Rate limits and quota

• Serverless and provisioned capacity

• Billing dimensions

• SLA and support owner

• Model version and update policy

• Logging and observability

• Content filtering and safety controls

• Network and private-access capabilities

• Fine-tuning and custom-weight support

Run conformance tests against both endpoints. Do not assume identical latency, output, token accounting, or failure behavior because the underlying model family matches.

Your application should record the provider route, deployment, and model version for every evaluated response.

Nemotron Through Hugging Face Uses Managed Compute

NVIDIA Nemotron 3.5 Lightning is also available from the Hugging Face collection in Foundry.

That path deploys the model on dedicated GPU capacity with a Foundry-managed runtime. Teams choose deployment templates, accelerator families, and scaling behavior to align capacity with demand.

Microsoft's Hugging Face integration documentation labels the capability as preview. Apply preview policies, verify supported regions and quotas, and do not assume the same service commitment as a Direct from Azure model.

Managed compute offers more control over the serving environment and hardware shape than a token-priced serverless endpoint. It also introduces capacity planning, startup, scaling, GPU utilization, patching boundary, and idle-cost considerations.

Use it when that control creates measurable value, not simply because dedicated GPUs sound more powerful.

BF16 Prioritizes Fidelity and Adaptation

The Hugging Face collection includes a BF16 format for Nemotron 3.5 Lightning.

Microsoft positions BF16 for:

• Supervised fine-tuning

• Reinforcement learning

• Distillation

• Domain adaptation

• Research and evaluation

• Creating custom quantized variants

BF16 is the higher-precision reference format and requires more accelerator memory. It fits training and adaptation work where fidelity and numerical headroom matter more than the smallest serving footprint.

Evaluate the complete fine-tuning lifecycle: dataset provenance, sensitive-data handling, license terms, experiment tracking, model registry, validation, red-teaming, approval, and rollback.

A customized model adds a software and data artifact that must be governed beyond the base-model deployment.

NVFP4 Targets Efficient Production Inference

The NVFP4 format is positioned for agent systems, chatbots, retrieval-augmented generation, instruction following, and production inference where latency, throughput, and memory efficiency matter.

Lower precision can reduce memory use and improve throughput. The tradeoff is that quantization may change quality for particular tasks, languages, long contexts, tool arguments, or edge cases.

Do not choose a format from a generic recommendation alone. Compare BF16 and NVFP4 on the exact workloads and hardware under consideration.

Measure:

• Task success and evaluator scores

• Structured-output validity

• Tool-call accuracy

• Long-context retrieval quality

• Multilingual behavior

• Tokens or requests per second

• Time to first token

• End-to-end latency

• GPU memory and utilization

• Cost per successful workflow

Promote the more efficient format only when it remains inside the required quality and safety envelope.

Pricing Is a Snapshot, Not an Architecture Constant

Microsoft's August 19 announcement included US Data Zone Standard token pricing for the Fireworks models.

At publication time, it listed:

• FW DeepSeek-V4-Flash-0731 at $0.150 per million input tokens, $0.030 per million cached input tokens, and $0.310 per million output tokens

• FW NVIDIA Nemotron Lightning 3.5 at $0.060 per million input tokens, $0.010 per million cached input tokens, and $0.220 per million output tokens

• Global Provisioned capacity at $1.00 per PTU-hour for supported models

• US Data Zone Provisioned capacity at $1.10 per PTU-hour for supported models

Nemotron Lightning was listed with US Data Zone Standard deployment, while the published table showed DeepSeek Flash with US Data Zone Standard plus selected provisioned options.

Prices, regions, models, and deployment availability can change. Verify the live Foundry catalog and Azure pricing terms before creating a budget or commitment.

Calculate cost per successful business outcome, including retries, retrieval, tool calls, human review, managed compute, idle capacity, logs, networking, and evaluation—not token price alone.

Open Model Choice Needs a Routing Discipline

Adding models to a catalog is easy. Operating a portfolio is harder.

Every approved model and deployment route should have:

• An owner

• Approved use cases

• Data classification boundaries

• Regional and network constraints

• A version and update policy

• A task-specific evaluation set

• Safety and red-team results

• A cost and quota limit

• Fallback behavior

• A retirement and migration plan

Centralize model policy behind a stable application interface where practical. Application teams should request a capability lane, not hard-code an ungoverned model identifier throughout the codebase.

A router can select a deployment based on task, quality, data boundary, latency, quota, and cost, but the routing decision itself must be logged and evaluated.

Coding Agents Need Repository-Level Evaluation

The DeepSeek update emphasizes coding-agent performance.

Evaluate it on real repositories rather than isolated algorithm questions. Include:

• Multi-file feature changes

• Bug diagnosis from incomplete symptoms

• Test generation and repair

• Dependency and API migration

• Tool use across search, shell, and version control

• Build and CI recovery

• Security-sensitive code review

• Long-running tasks with checkpoints

Score whether the final repository compiles, tests pass, requirements are met, and unsafe or unrelated changes are avoided.

Track tool-call loops, token use, time, failed patches, human corrections, and rollback frequency. A model that produces impressive explanations but unreliable repository changes is not the best coding-agent model.

Tool Calling Needs Contract Tests

Both model families target agentic workflows, so tool accuracy is critical.

Build contract tests for:

• Correct tool selection

• Valid argument schema

• Authorization failures

• Empty and ambiguous results

• Timeouts and transient errors

• Malicious content returned by a tool

• Duplicate write prevention

• Human approval before high-impact actions

• Recovery after partial completion

Structured-output support reduces parsing work but does not guarantee semantic correctness. Validate arguments against business rules and authorization policy before executing them.

The model should never be the sole authority for whether an action is permitted.

Security, Licensing, and Supply Chain

Open models introduce choice, not an exemption from governance.

Review the model license, provider terms, acceptable-use requirements, training-data disclosures, security guidance, and update process for every route.

For managed compute and custom weights, protect model artifacts, deployment templates, containers, registries, datasets, adapters, and generated logs. Scan dependencies and control who can deploy or replace a model.

Prevent secrets and regulated data from entering prompts unless the deployment is approved for that classification. Use private networking and managed identity where supported, and verify actual traffic paths.

Perform model-specific prompt-injection, data-exfiltration, harmful-output, and tool-abuse testing. A safety result from another model cannot be inherited automatically.

A Practical Evaluation Matrix

Choose one agentic coding task, one structured tool workflow, and one multilingual or long-context task.

Deploy the smallest relevant comparison set:

• DeepSeek Direct from Azure

• DeepSeek through Fireworks

• Nemotron through Fireworks

• Nemotron BF16 or NVFP4 on managed compute if dedicated serving is a real requirement

Run identical versioned prompts, tool schemas, data, and scoring logic. Repeat each test enough times to observe variance.

Compare quality, safety, tool accuracy, latency, availability, operator effort, support boundary, and total cost. Record model, provider route, region, format, deployment type, and version with every result.

The goal is not to declare one universal winner. It is to assign each approved option to a workload lane with evidence.

Who Should Care?

AI platform teams should care because the same model family can now arrive through different operational and commercial routes.

Agent developers should care because both releases focus on coding, tools, structured output, and multi-step work.

Machine-learning engineers should care because Nemotron's BF16 and NVFP4 formats support different adaptation and inference priorities.

Security and compliance teams should care because partner services, open-model licenses, managed compute, and custom weights create distinct boundaries.

FinOps teams should care because token pricing, provisioned throughput, and dedicated GPU economics must be compared using successful outcomes.

Practical Cloud Engineer Takeaway

Do not add both models to the production allowlist immediately.

Select three representative workflows and define quality, safety, latency, tool-call, data-location, and cost thresholds before deploying anything.

Test DeepSeek through both Azure and Fireworks if the support boundary matters. Test Nemotron through Fireworks first, then justify managed compute only if format choice, customization, or dedicated capacity produces measurable value.

For NVFP4, prove that throughput savings do not create unacceptable quality loss. For BF16 or fine-tuned weights, build the data and model-governance pipeline before treating customization as a shortcut.

Promote one route to a small traffic slice, monitor cost per completed workflow, and retain a tested fallback that obeys the same output and safety contract.

Bottom Line

Microsoft Foundry's DeepSeek-V4-Flash-0731 and NVIDIA Nemotron 3.5 Lightning additions expand both model choice and deployment choice.

DeepSeek is available directly from Azure and through Fireworks. Nemotron is available through Fireworks and the preview Hugging Face managed-compute path in BF16 and NVFP4 formats.

That flexibility lets teams balance Microsoft support, partner serving, serverless tokens, provisioned throughput, dedicated GPUs, fine-tuning, fidelity, and inference efficiency.

The right decision cannot be made from a catalog description or benchmark headline. Evaluate the exact model, route, format, region, and version against real workflows, then govern it as a production dependency with an owner, evidence, budget, fallback, and retirement plan.

Sources

Microsoft Foundry announcement, published August 19, 2026: https://techcommunity.microsoft.com/t5/microsoft-foundry-blog/expanding-open-model-choice-in-microsoft-foundry-with-new/ba-p/4547926

Foundry Models sold directly by Azure: https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure?pivots=azure-direct-others

Fireworks models on Microsoft Foundry: https://learn.microsoft.com/en-us/azure/foundry/how-to/fireworks/enable-fireworks-models

Hugging Face models in Microsoft Foundry: https://learn.microsoft.com/en-us/azure/foundry/foundry-models/how-to/hugging-face-models

Foundry managed compute overview: https://learn.microsoft.com/en-us/azure/foundry/concepts/managed-compute-overview

---

Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.

Chriz Beyond Cloud with Chriz