Mistral on Azure AI
On this page
Updated November 3, 2026: The TypeScript example previously passed
process.env.AZUREAI_API_KEYandprocess.env.AZUREAI_ENDPOINTdirectly toMistralAzure. Since both options are required, TypeScript 7 in strict mode refused to compile (verified with@mistralai/mistralai-azure2.1.0). Environment variables are now validated before constructing the client. Source:@mistralai/mistralai-azureSDK.
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.
| Model | Positioning |
|---|---|
| Mistral Medium 3.5 | Good 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:
- Go to Microsoft Foundry
- Create a project or select an existing one
- Deploy a Mistral model from the model catalog
- 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
MistralAzureclient takes the endpoint viaserver_url(Python,mistralai.azure.client) orendpoint(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