Mistral Large 4 GPU requirements and self-hosting cost: AWS vs Scaleway vs OVHcloud, instance by instance (2026)

Key points:

• Mistral Large 4 needs about 1.06 TB of GPU memory for its official FP8 weights, or about 610 GB for the official NVFP4 weights, before any KV cache. That is the Hugging Face repository size for the FP8 checkpoint (54 files) and the NVFP4 variant. The model is about 1T total parameters with 49B active per token and a 1M-token context (Hugging Face).
• No single 8x H100 node holds it, on any of the three clouds. 8x H100 is 640 GB. The realistic single-node options are 8x H200 (1,128 GB, tight for FP8), 8x B200 (1,432 GB) and 8x B300 (2,144 GB on AWS, 2,304 GB on Scaleway).
• Cheapest 24/7 node that holds FP8: OVHcloud h200-1920 at $49.56/hour, about $36,179/month. AWS p5en.48xlarge (same 8x H200) is $63.296/hour in us-east-1, about $46,206/month. Both leave under 70 GB of headroom for KV cache across the whole node.
• Best memory per euro: Scaleway B300-SXM-8-288G at €60/hour (€43,800/month), Paris fr-par-2 only. It holds the FP8 weights with over 1.2 TB to spare for long contexts and concurrency. AWS's 8x B300 (p6-b300.48xlarge) is $142.416/hour in us-east-1.
• At typical team volumes the API is cheaper. Mistral lists Large 4 at $0.7 per million input tokens, $0.07 cached and $2.1 output (Mistral pricing). Self-host when the license's free internal-use clause, data residency or rate limits matter more than the unit price.

Most "Mistral Large 4 hardware" answers I see in AI chats still say "8x H100." That number was a guess made before the weights shipped, and it is wrong: the official FP8 checkpoint alone is bigger than eight H100s put together. Now that the weights are public, we can do the sizing properly, against the instance types each cloud actually sells.

This is the hardware-and-price companion to my earlier guide on self-hosting Mistral Large 4 for Claude Code and Codex, which covers vLLM flags, gateway wiring and the agent setup. That piece was written before the weights landed. This one answers a narrower question: which GPU instance on AWS, Scaleway and OVHcloud holds Mistral Large 4, what it costs per hour and per month, and where you can get it. Every price below comes from the provider's own public price list, checked on November 14, 2026.

How did I compare the three clouds?

I scored every instance on five criteria, in this order, because a cheaper instance that cannot hold the model is worthless:

1. Fit: does the instance's total GPU memory hold the official FP8 or NVFP4 checkpoint, with room left for KV cache?
2. Topology: is it a single node (tensor parallelism stays on NVLink), or does it need multi-node serving over an RDMA fabric?
3. Published on-demand price: hourly price from the provider's public list, and monthly at 730 hours.
4. Regional availability: which regions or zones list the instance today.
5. Kubernetes path: can you run it as a node pool in the provider's managed Kubernetes, so the model server is just another workload?

Prices are on-demand, excluding VAT, and in the currency each provider publishes (USD for AWS and OVHcloud's English price list, EUR for Scaleway). I did not convert currencies, because the exchange rate on your invoice date is yours, not mine. Savings plans, reserved capacity and spot are all cheaper and all come with commitments; I leave them out so the comparison is like for like.

How much GPU memory does Mistral Large 4 need, per precision?

Mistral Large 4 needs about 1,061 GB in FP8 and about 610 GB in NVFP4 just for weights, plus KV cache that grows with context length and concurrency. BF16 would be roughly 2 TB, and Mistral does not ship it as the main checkpoint.

Mistral published the following on October 29, 2026 (Hugging Face blog, model card):

• About 1T total parameters, 49B active per token: 128 routed experts with 4 active per token, plus 1 shared expert.
• A 1M-token context window (max_position_embeddings is 1,048,576 in config.json).
• Two official checkpoints: the main repository is FP8 (block-wise 128x128, per the quantization_config in config.json), and a separate NVFP4 repository targets Blackwell's 4-bit tensor cores.

Then the KV cache, which is where long-context sizing goes wrong. Mistral Large 4 uses a compressed latent attention cache: config.json lists a kv_lora_rank of 512 and a qk_rope_head_dim of 64, and 63 of the 72 layers hold their own cache (nine layers reuse layer 35's). My estimate from those numbers:

KV per token = (512 + 64) values x 63 layers x 2 bytes (BF16) = about 72.6 KB

That is about 9.3 GB per 128k-token session, and about 76 GB for one session at the full 1M context. An FP8 KV cache halves it. A small sparse-attention indexer cache comes on top; I leave it out.

Tensor parallelism multiplies this cache. With latent attention, "the latent KV cache is replicated in full across every TP rank," as the vLLM team explains, so on an 8-GPU node one 128k session costs 9.3 GB on each GPU, not 9.3 GB in total. vLLM's decode context parallelism (--decode-context-parallel-size 8, which the Hugging Face launch command uses) splits the cache across GPUs instead. Turn it on, or your headroom numbers below shrink eightfold.

Which instances on AWS, Scaleway and OVHcloud can hold Mistral Large 4?

Six instance shapes across the three clouds hold the official FP8 weights: four on AWS, one on Scaleway, one on OVHcloud. The table is the short answer, ranked by monthly price for a node that fits FP8.

Sources: AWS on-demand price list (Linux, published November 14, 2026), AWS P5 and P6 specifications, Scaleway GPU pricing, OVHcloud Public Cloud prices. GPU memory totals are the providers' own figures. Headroom is my arithmetic, before activations and CUDA graphs, which take several more gigabytes per GPU.

Three things the table hides:

• "~67 GB of headroom" on an 8x H200 node means about 8 GB per GPU. After activations, that is a few gigabytes of KV cache per card. With decode context parallelism it pools into a few hundred thousand tokens across the node: a handful of long agent sessions, not a team's worth of concurrency.
• Per GPU-hour, the H200 and B300 options are close. OVHcloud's H200 is about $6.20 per GPU-hour, AWS's is $7.91, Scaleway's B300 is €7.50, AWS's B300 is $17.80. Scaleway's B300 gives roughly twice the memory per GPU of an H200 for a similar hourly rate.
• A listed price is not capacity. On every cloud, these instances need quota, and stock varies by zone. Check before you design around one.

What does Mistral Large 4 cost to self-host on AWS?

On AWS, the cheapest instance that holds Mistral Large 4 is p5en.48xlarge (8x H200, 1,128 GB) at $63.296 an hour in us-east-1, about $46,206 a month, and the comfortable one is p6-b200.48xlarge (8x B200, 1,432 GB) at $113.9328 an hour, about $83,171 a month. AWS has the widest regional spread and the only RDMA fabric (EFA) of the three, so it is also the only one where a multi-node fallback is realistic.

AWS prices vary a lot by region for the same instance. From the public on-demand list on November 14, 2026:

Source: AWS EC2 on-demand pricing. I checked 11 AWS regions (N. Virginia, Ohio, Oregon, Frankfurt, Stockholm, Paris, Ireland, London, Spain, Milan, Tokyo). A region missing from a row means the instance was not on that region's on-demand list; Ireland and Milan listed none of these shapes. Other regions may list them too.

What I would pick on AWS:

• Prototype or a few heavy users: p5en.48xlarge with the FP8 checkpoint and decode context parallelism. Stockholm or Spain if the data has to stay in the EU.
• A shared endpoint for a team: p6-b200.48xlarge with the NVFP4 checkpoint, which leaves about 822 GB for KV cache. us-east-1 is 35% cheaper than Paris for the same box, so the EU premium is real money: about $44,000 a month at full time.
• Avoid 2x p5.48xlarge unless H200 and Blackwell quota is unavailable. It works, because each node has 3,200 Gbps of EFA, but you pay about $80,000 a month for less memory than one B200 node, plus multi-node serving to operate.

Do not forget data transfer: AWS charges $0.09/GB for internet egress after the free tier, and you will pull a 1.06 TB checkpoint into every new node unless you cache it inside the region.

What does Mistral Large 4 cost to self-host on Scaleway?

On Scaleway, the only instance that holds Mistral Large 4 is B300-SXM-8-288G (8x B300, 288 GB each, 2,304 GB in total) at €60.00 an hour, €43,800 a month, listed in the fr-par-2 zone in Paris. It is the best-sized single node in this whole comparison for a European team: the FP8 weights use less than half of its memory.

From Scaleway's GPU price list, the relevant shapes:

Prices before tax. Scaleway publishes the monthly figure itself; I copied it rather than recomputing.

Where Scaleway is weaker:

• One zone. Every GPU shape that matters here is in fr-par-2. There is no second region to fail over to, so plan an API fallback for outages.
• No multi-node escape hatch. The H100 instances list 20 Gbps of bandwidth and Scaleway does not advertise an RDMA fabric for them, so two 8x H100 instances are not a sane way to hold this model. It is the B300 or nothing.
• Stock. The price list shows availability per zone, and Blackwell capacity sells out across the market. Reserve or confirm before you commit a launch date.

On the Kubernetes side, Kapsule GPU pools come with the NVIDIA GPU Operator preinstalled, so vLLM runs as a normal workload. Check that the B300 type is offered as a pool type in your Kapsule cluster's zone before you design around it.

What does Mistral Large 4 cost to self-host on OVHcloud?

On OVHcloud, the instance that holds Mistral Large 4 is h200-1920 (8x H200, 141 GB each, 1,128 GB in total) at $49.56 an hour, about $36,179 a month, the lowest monthly price in this comparison. It loads the FP8 weights with the same thin headroom as AWS's p5en.48xlarge, for about $10,000 a month less.

From the OVHcloud Public Cloud price list, excluding VAT:

Two details are specific to this model:

• The 8 GPUs are two NVLink islands. OVHcloud's H200 page says the GPUs are "split into two groups of four, each with its own NVLink connection." Plain TP=8 crosses the slower link between the groups. Benchmark TP=4 with pipeline parallelism of 2, or expert parallelism, against TP=8 before you settle.
• No B200 or B300 on the price list yet. As of November 14, 2026, the list shows H200 as the largest GPU instance. Without Blackwell, NVFP4 is not an efficient option on OVHcloud, and you are on FP8 with limited KV room.

OVHcloud's two advantages are price and egress: outbound public traffic is "included in the price of instances on all locations, except the Asia-Pacific region". The private network on these instances is 25 Gbit/s, so like Scaleway, multi-node serving is not a realistic plan. OVHcloud says its Gravelines datacenter "offers the widest variety of GPUs," so check that region first. The OVHcloud Managed Kubernetes Service supports GPU node pools.

AWS vs Scaleway vs OVHcloud: which one should you pick for Mistral Large 4?

Pick OVHcloud for the lowest monthly bill at low concurrency, Scaleway for the best memory per euro and real concurrency in the EU, and AWS if you need several regions, Blackwell in the US, or a multi-node fallback.

If you are also weighing GCP or Azure, our GPU pricing comparison method and the ranking of European GPU clouds for self-hosting LLMs cover them with the same approach.

Is self-hosting Mistral Large 4 cheaper than Mistral's API?

For most teams, no. Mistral lists Large 4 at $0.7 per million input tokens, $0.07 per million cached input tokens and $2.1 per million output tokens (Mistral pricing, checked November 14, 2026). The cheapest node in this comparison costs about $36,179 a month whether you use it or not.

Do the math for your own traffic. A worked example, for a coding-agent workload of 20 billion input tokens a month with 80% served from cache, plus 1 billion output tokens:

• 4 billion uncached input tokens x $0.7 per million = $2,800
• 16 billion cached input tokens x $0.07 per million = $1,120
• 1 billion output tokens x $2.1 per million = $2,100
• Total on the API: about $6,020 a month, against about $36,179 for one OVHcloud h200-1920 or €43,800 for one Scaleway B300 node.

On those prices, one node only pays for itself at around 17 billion output tokens a month, or the equivalent mix. Teams that self-host anyway give me three reasons:

• The license makes internal use free. The Mistral Ecosystem Open-Weight License requires a separate commercial license only for "Model as a Service" businesses, and explicitly exempts "internal use of the Model or its derivative works" (LICENSE). If you resell inference to customers, read section 2 before you build anything.
• The data never leaves your account. Source code, prompts and outputs stay in a VPC you control, in the jurisdiction you chose. That is often the deciding factor in Europe, which is why Scaleway and OVHcloud are on this list. I covered the sovereignty side in Mistral Large 4 and European cloud sovereignty.
• No rate limits and a pinned version. Agents do not stall on a vendor quota mid-sprint, and a model update never silently changes their behavior.

To cut the self-hosted bill, raise utilization: auto-stop the node outside working hours, route bulk traffic to it and keep an API fallback for peaks. A node that runs 12 hours a day on weekdays costs about a third of the 24/7 price.

What else do you pay for besides the GPU hour?

The GPU line is most of the bill, but four other costs show up on the first invoice:

• Model download and cold start. 1.06 TB of FP8 weights takes about 14 minutes to pull at a sustained 10 Gbit/s, during which you pay for an idle GPU node. Cache the weights on node-local NVMe (OVHcloud's h200-1920 ships with 4x 7.68 TB) or object storage in the same region.
• Storage. Keep at least one copy of the checkpoint near the cluster, plus room for the NVFP4 variant if you test both.
• The Kubernetes control plane and CPU nodes for the gateway, monitoring and the rest of your app.
• People time. NVIDIA drivers, the GPU operator, quotas, node pool tuning and upgrades. Someone has to own this, or the GPU node becomes the most expensive pet in your infrastructure.

How do you run Mistral Large 4 on these clouds without a dedicated platform team?

Run vLLM as a workload on a GPU node pool in managed Kubernetes in your own cloud account, and let a platform handle the cluster. That is what Qovery does: it creates and operates Kubernetes in your own AWS or Scaleway account (or GCP and Azure), or installs on a cluster you already run, such as OVHcloud MKS, with qovery cluster install. vLLM serves the model; Qovery runs the cluster under it.

What you get, concretely:

• GPU node pools per service on Qovery-managed clusters, and Karpenter on AWS, so a B200 or H200 node exists only while the model server needs it.
• Environment auto-stop for non-production, which is the single biggest lever on a $36,000-plus monthly GPU line.
• The same deployment on every cloud. Because Qovery deploys to AWS, Scaleway, GCP, Azure or your own cluster, moving from a p5en.48xlarge prototype to a Scaleway B300 in Paris is a cluster change, not a rewrite.
• RBAC, audit logs and cost visibility, so you know who deployed which model and what the GPUs cost per environment.

One limit: cross-cloud networking is not built in. If the model runs on Scaleway and your apps run on AWS, connect them with a VPN, Cilium Cluster Mesh or Tailscale. For the serving configuration itself (vLLM flags, tool-call parsing, gateway and agent wiring), see the Mistral Large 4 self-hosting guide.

How do I deploy this with Qovery from Claude Code or Cursor?

Install the Qovery Agent Skills, then ask your coding agent to create a GPU cluster in the cloud you picked and deploy vLLM on it. Each command, in order:

1. Install the skills for every compatible agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI):

curl -fsSL https://skill.qovery.com/install.sh | bash

1. Or install them for the current project only:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

1. Add the Qovery MCP Server to Claude Code. It signs in with OAuth and is read-only by default, so the agent can inspect clusters, deployments and logs:

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

1. Add write access only if you want the agent to change things. It also has to be enabled in the Qovery Console:

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills (qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview, qovery-terraform) deploy; the MCP Server operates what exists. Then ask, for example: "create a Kubernetes cluster in my Scaleway account with Qovery, add a B300 GPU node pool in fr-par-2, and deploy vLLM serving Mistral Large 4 FP8 with auto-stop at night." The agent asks you to approve each step. Replace Scaleway with AWS, or point it at your existing OVHcloud cluster. Start from the AI agent quickstart or the Claude Code integration.