When Mistral recently released the open weights of Mistral Large 4, a question many French leadership teams had parked came back on the table: should we run a self-hosted LLM on our own infrastructure, or keep calling frontier APIs such as Claude, GPT or Gemini? The answer is rarely "one or the other". It depends on your data, your volumes, your team and your regulatory exposure. This guide gives you a decision framework you can apply this quarter, without hype.
What changed with Mistral Large 4 open weights
According to Mistral's announcement, Mistral Large 4 is a natively multimodal model with around one trillion parameters, now downloadable from Hugging Face under the Mistral Ecosystem Open-Weight licence, a modified MIT licence. Use, modification, fine-tuning and commercial use are allowed; companies selling the model itself as a hosted service need a separate commercial licence.
Three details matter for a business decision:
- It is a Mixture-of-Experts model: only a fraction of the parameters is used per token, which keeps inference costs lower than the headline size suggests. The Mistral model page lists a 1M-token context window.
- It is not a laptop model: the Hugging Face launch blog cites 8 NVIDIA H200 GPUs for FP8 serving on its Inference Endpoints. That is data-centre hardware, not a spare server in the basement.
- The same model is also an API: Mistral lists API pricing of $0.70 per million input tokens and $2.10 per million output tokens. You can start on the API and move to your own hosting later without changing models.
That last point is the real shift. For the first time, a large European model of this class is available both as a managed API and as weights you control. It turns "self-hosted or frontier?" from a philosophical debate into a cost and risk calculation.
Self-hosted LLM vs frontier API: the real trade-offs
Before comparing benchmarks, compare operating models. Here is what each option really means for a French B2B company.
Data control: a self-hosted model keeps prompts and documents inside your perimeter. A frontier API sends them to a provider, under its contractual terms and data-processing agreement.
Quality ceiling: the best closed frontier models still tend to lead on the hardest reasoning, coding and agentic tasks. Open-weight models have closed much of the gap for everyday work such as summarising, classifying, extracting and drafting. Test on your own tasks rather than trusting a leaderboard.
Cost profile: APIs are pure variable cost, cheap at low volume and predictable per request. Self-hosting is mostly fixed cost (GPUs, hosting, engineering time) that only pays off at high, steady volume.
Skills required: an API needs integration skills. Self-hosting needs people who can run a serving stack such as vLLM, which exposes an OpenAI-compatible API, plus monitoring, scaling, security patching and model upgrades.
Speed of innovation: with an API you get new model versions the day they ship. With self-hosting you choose when to upgrade, which is good for stability but means you can fall behind.
A useful rule of thumb: if your GPUs would sit idle most of the day, the API is almost always cheaper. Self-hosting becomes rational when volumes are high and constant, when data cannot leave your perimeter, or both.
GDPR and the EU AI Act: what really applies to you
Sovereignty arguments often mix two different regulations. Separate them.
GDPR is about the personal data you send. The CNIL's Q&A on deploying generative AI (in French) notes that on-premise deployment is generally preferable for personal or sensitive data because it limits the risk of a third party accessing it. Cloud hosting remains possible with a data-processing contract that clarifies roles and access. With an API, the CNIL advises limiting the personal data you send, framing any transfer outside the EU, involving your DPO and considering a data protection impact assessment (DPIA).
The EU AI Act mostly targets model providers, not you. The Commission's FAQ on general-purpose AI obligations states that these obligations apply from 2 August 2025, with full enforcement, including fines, from 2 August 2026. A company that fine-tunes or modifies a model becomes a "provider" only in exceptional cases, when the modification uses more than a third of the original training compute. For most companies running or lightly fine-tuning an open-weight model, the provider obligations stay with the original lab.
In practice, a self-hosted LLM simplifies the GDPR side (no transfer, no external processor for prompts) but does not remove your obligations as a deployer, nor the need for access control, logging and a clear purpose for each use case.
A decision checklist: choose self-hosted if… choose an API if…
Choose a self-hosted or EU-hosted open-weight model if:
- Your use cases process sensitive personal data, health data, or trade secrets that legal will not allow outside your perimeter.
- You have high, steady volumes, for example nightly classification of documents or tickets.
- You need to freeze a model version for months for audit or reproducibility reasons.
- You already run GPU or MLOps infrastructure, or have a cloud partner that does it for you in the EU.
Choose a frontier API if:
- You are still exploring use cases and volumes are low or unpredictable.
- Your tasks need the strongest reasoning, coding or multi-step agent behaviour available.
- You do not have the team to run and secure an inference stack around the clock.
- The data involved can be minimised or pseudonymised before it leaves your systems.
Choose a hybrid setup if you recognise yourself in both lists. This is where most mid-size companies land: a router sends sensitive or high-volume tasks to an open-weight model you control and sends complex, low-volume tasks to a frontier API. Because vLLM and most providers speak the same OpenAI-style API, switching a workflow from one to the other can be a configuration change rather than a rewrite.
What to do now: a 6-step plan
- List your top five AI use cases and classify the data each one touches: public, internal, personal, sensitive.
- Estimate monthly volumes in requests and tokens for each use case. Without this, any cost comparison is guesswork.
- Build a small evaluation set of 30 to 50 real examples per use case, with expected answers, and score two or three candidate models on it.
- Price both paths: API cost at your volumes versus GPU hosting plus engineering time for a self-hosted LLM. Include monitoring and upgrades.
- Involve your DPO early: document data flows, processors and transfers, and decide whether a DPIA is needed.
- Start with an API pilot, design for portability: keep prompts, evaluation sets and integration code model-agnostic so you can move a workload to self-hosting when the numbers justify it.
If you want a structured version of this exercise, our AI audit maps your use cases and data constraints, and our AI strategy and roadmap service turns them into a sequenced deployment plan. For teams ready to build, see how we handle AI implementations. You can also read how we connect Claude to a CRM through MCP or our take on agentic AI for Salesforce implementations.
Conclusion
Open weights for a model of this size from a European lab change the conversation, but not the method. Start from your data and your volumes, test models on your own tasks, and keep your architecture portable. For most French B2B companies, the winning answer in 2026 is not "self-hosted" or "frontier", it is a deliberate mix of both.
