Skip to main content
Lesson 11 of 14 · Mistral API: Quick Start

Mistral on Azure AI

Lesson 11 of 14 Updated November 3, 2026 Developer
On this page
  1. Why use Mistral via Azure?
  2. Choosing between serverless and dedicated GPU
  3. Models available on Azure
  4. Getting your credentials
  5. Calling the model in Python
  6. The same call in TypeScript
  7. Leveraging the rest of the platform
  8. Key takeaways

Updated November 3, 2026: The TypeScript example previously passed process.env.AZUREAI_API_KEY and process.env.AZUREAI_ENDPOINT directly to MistralAzure. Since both options are required, TypeScript 7 in strict mode refused to compile (verified with @mistralai/mistralai-azure 2.1.0). Environment variables are now validated before constructing the client. Source: @mistralai/mistralai-azure SDK.

Why use Mistral via Azure?

This question rarely arises for technical reasons: the direct Mistral API works perfectly. It arises for contractual and organizational reasons. A company already embedded in the Microsoft ecosystem consumes a negotiated Azure commitment, has established procurement processes, and has no desire to open a new vendor contract for a few thousand euros worth of tokens.

Using Azure AI consolidates billing onto your existing Azure contract, ensures GDPR compliance through European regions, provides native integration with other Azure services—Azure Functions, Cosmos DB, Azure ML—and offers Microsoft enterprise support with corresponding service level agreements. In short: the same model, within the governance perimeter your IT department has already approved.

Choosing between serverless and dedicated GPU

Azure offers two approaches, and the choice depends on the regularity of your workload. The pay-as-you-go mode, also known as MaaS (Model as a Service), exposes a serverless API: no GPUs to provision, you pay only for consumed tokens, and Azure handles scaling alone. This is the recommended mode for most use cases, especially while your traffic is irregular or unpredictable.

Real-time endpoints address the opposite need. You choose the GPU type and count, the infrastructure is dedicated to you, and billing occurs per compute hour—whether the model is working or idle. An internal API continuously hit by several thousand users fits this model; a prototype accessed three times a day will waste a lot of money here. Remember the rule: this mode is recommended for predictable, high-throughput workloads.

Models available on Azure

Mistral documentation lists the following models on Azure (list retrieved November 2, 2026). The catalog evolves regularly: consult the official page for the current list.

ModelPositioning
Mistral Medium 3.5Good performance/cost balance
Mistral Large 3 (25.12)Flagship model for complex tasks
Mistral Small (25.06)Fast and economical
Codestral (25.01)Specialized in code generation
Ministral 3B (24.10)Compact model for lightweight tasks
Document AI (OCR 4)Text and structure extraction in documents

Getting your credentials

Retrieving credentials happens through the Azure interface and takes a few minutes:

  1. Go to Microsoft Foundry
  2. Create a project or select an existing one
  3. Deploy a Mistral model from the model catalog
  4. Retrieve your endpoint and API key from the deployment page

Place these two values in environment variables, exactly like the direct Mistral key. The difference lies in the endpoint: every Azure deployment has its own; there is no common URL.

export AZUREAI_ENDPOINT="https://your-endpoint.inference.ai.azure.com"
export AZUREAI_API_KEY="your-azure-secret-key"

Calling the model in Python

The Mistral SDK provides a dedicated Azure client, MistralAzure, included in the mistralai package: you pass it your deployment URL and key, and the rest of the code is identical to what you write for the direct API. Since SDK version 2.0 (March 2026), it imports from mistralai.azure.client.

import os
from mistralai.azure.client import MistralAzure

client = MistralAzure(
    server_url=os.environ["AZUREAI_ENDPOINT"],
    api_key=os.environ["AZUREAI_API_KEY"],
)

response = client.chat.complete(
    model="azureai",  # Identifier expected by Azure endpoints
    messages=[
        {"role": "user", "content": "What are the benefits of sovereign cloud in Europe?"}
    ]
)

print(response.choices[0].message.content)

The most confusing point lies in the model parameter. You expect to write mistral-large-latest; instead, you must put azureai. The reason is simple: the model is already determined by the deployment you created on the Azure side; the endpoint points to it and it alone. Changing models therefore means changing endpoints, not changing a string in the code.

Streaming, however, does not change one iota compared to the direct API—same method, same .data level to reach the chunk content. That is the whole point of a unified SDK: the code you wrote in previous lessons works as is.

stream = client.chat.stream(
    model="azureai",
    messages=[
        {"role": "user", "content": "Describe the architecture of a data lake on Azure."}
    ]
)

for chunk in stream:
    content = chunk.data.choices[0].delta.content
    if content:
        print(content, end="", flush=True)

The same call in TypeScript

On the TypeScript side, the Azure client is published in a separate package, @mistralai/mistralai-azure, installed with npm add @mistralai/mistralai-azure. Its options follow JavaScript casing: apiKey and endpoint, both required. Hence the environment variable validation, without which strict mode refuses to compile, since an environment variable might be missing:

import { MistralAzure } from '@mistralai/mistralai-azure';

const apiKey = process.env.AZUREAI_API_KEY;
const endpoint = process.env.AZUREAI_ENDPOINT;
if (!apiKey || !endpoint) {
  throw new Error('Set AZUREAI_API_KEY and AZUREAI_ENDPOINT.');
}

const client = new MistralAzure({ apiKey, endpoint });

const response = await client.chat.complete({
  model: 'azureai',
  messages: [
    { role: 'user', content: 'How to secure an Azure Key Vault?' },
  ],
});

console.log(response.choices[0]?.message?.content);

Sources: Mistral on Azure (Mistral documentation) · TypeScript SDK @mistralai/mistralai-azure

Leveraging the rest of the platform

Once the call works, leverage the services you are already paying for. Store your keys in Azure Key Vault rather than in environment variables: rotation becomes an administrative operation, not a redeployment. Enable diagnostic logs on your endpoint to monitor latency and errors, the only way to distinguish model slowness from code slowness. Choose a European region, West Europe or France Central, to remain GDPR compliant—this is often the very reason for choosing Azure. Finally, configure Azure Monitor alerts on token consumption: a poorly closed loop in a nightly job shows up on the bill much later than on an alert.

Key takeaways

  • Azure AI offers Mistral in serverless (MaaS) or dedicated GPU modes
  • The model is identified by "azureai" in API calls
  • The MistralAzure client takes the endpoint via server_url (Python, mistralai.azure.client) or endpoint (TypeScript, @mistralai/mistralai-azure)
  • Integration with the Azure ecosystem (Key Vault, Monitor, Functions) is a major asset for enterprises
  • Choose a European region to remain GDPR compliant