When is self-hosting Mistral's open weights better than calling la Plateforme?

## Reframe the question before answering it Interviewers ask this to see whether you reduce it to ideology ("open source is cheaper") or decompose it. The honest decomposition has four axes, and they do not point the same way. ## Axis 1 — what you are legally allowed to run This constrains the whole discussion and is where people skip straight to benchmarks. Only Mistral's Apache-2.0 releases can be self-hosted for commercial use: Mistral 7B, Mixtral 8x7B and 8x22B, Mistral NeMo, the Mistral Small line, Pixtral 12B and the permissively licensed specialists. Flagship weights published under the research licence and code-specialist weights under the non-production licence are not deployable without a negotiated agreement, and Mistral Medium has no weights at all. So the real proposition is never "self-host Mistral" — it is "self-host the Small/Mixtral tier and accept that ceiling, or pay the API for the flagship tier". Any answer that ignores this is answering a different question. A common resolution is hybrid: self-host Small for the bulk of traffic and call the API for the slice that genuinely needs flagship reasoning, which also gives you a working fallback in both directions. ## Axis 2 — data boundary and residency When it applies, this axis dominates and cost becomes secondary. Regulated healthcare and finance data, defence work, customer source code, air-gapped environments, and EU-residency commitments can all make "the tokens never leave our VPC" a hard requirement. Mistral's European base and the availability of its models through EU cloud regions soften this for some organisations, but a hard air-gap or a contractual no-third-party-processing clause is only satisfiable by running the weights yourself. Note the middle options too: dedicated or in-VPC deployments from Mistral or a cloud marketplace can satisfy residency without you owning the operations. ## Axis 3 — economics, honestly modelled The hosted API bills per input and output token, scales down to literally zero when idle, and carries no fixed cost. Self-hosting inverts that: accelerators (rented or owned) bill whether or not a request arrives, plus the engineering time to build and operate serving, autoscaling, monitoring, upgrades and on-call. There is a crossover point, and finding it requires modelling **sustained** utilisation, not peak. Signals that you are past it: steady round-the-clock traffic, a large batch or offline workload with no latency requirement, a very high token-per-request profile, or a task where a small model suffices so each GPU serves enormous throughput. Signals that you are far short of it: bursty daytime-only traffic, a few thousand requests a day, or a workload still changing shape weekly. Two costs are chronically underestimated — idle capacity you provision for peak, and the salary line for the people who keep the fleet healthy. Two are chronically overestimated — how much a smaller self-hosted model degrades the product, and how quickly the fleet becomes routine. ## Axis 4 — control, reproducibility, lifecycle Downloaded weights are a permanent artefact. They never roll forward under an alias, never enter a deprecation window, never change output style on a Tuesday. For anything that must be reproducible — a regulated decision log, a published evaluation, a model whose outputs are audited — this is a genuine and under-priced benefit. It also means you own fine-tuning outright, with no per-model hosting fee and no vendor policy on what you may train. The flip side is that you also own being stuck: a frozen model does not get the vendor's quality improvements, and the gap widens with each generation. Freezing is a deliberate choice with a refresh plan attached, not a way of avoiding the upgrade question. ## Latency and locality Self-hosting removes the public-network hop, which matters most for interactive workloads with tight budgets — inline code completion, typing-latency UX. Against that, a well-provisioned vendor fleet usually beats an under-provisioned private one at peak, and your tail latency is now your own queueing problem. ## The organisational question The axis a principal is uniquely expected to raise: do you have, or want to build, a team that operates GPU inference? That is capacity planning, quantisation choices, batching and KV-cache behaviour, driver and kernel upgrades, and a pager. For an organisation whose product is not AI infrastructure, that headcount is often better spent on the product, and the API's markup is cheap by comparison. For an organisation running inference as a core cost centre at scale, the same headcount pays for itself many times over. ## The answer that lands "Self-host when the licence permits the capability we need, when a hard data boundary or residency rule forces it, or when sustained utilisation clears the fixed-cost crossover and we already have the operational muscle. Otherwise call the API, and revisit at the volume where the model says otherwise — and be explicit that self-hosting Mistral means committing to the Apache-2.0 tier, so run a hybrid if the hard slice of traffic needs the flagship."