Mistral Large 4 Open Weights Released: Can a 1T-Parameter Model Run on Consumer Hardware?

Europe's open-source LLM camp has gained another heavyweight—Mistral Large 4 (codename LeChonc) has officially moved from API preview to downloadable weights. The released version underwent an additional three weeks of reinforcement learning, boosting its Terminal Bench 4.0 score from 28% in the preview to 41%. But the practical question follows immediately: can your hardware actually run it?

Model Specs: Fine-Grained MoE and a Million-Token Context

Mistral Large 4 uses a fine-grained mixture-of-experts architecture with roughly 1 trillion total parameters and about 52 billion activated per token (including embedding and output layers; 49 billion excluding them). Internally it contains 128 routed experts, 4 of which are woken per token, plus a shared expert that always participates in voting. The context window reaches 1 million tokens.

The model reads text and images through a Pixtrel-like vision encoder and outputs text in over 160 languages. Reasoning effort comes in three levels—low, medium, and high, with high as the default—so the same set of weights can handle both quick conversation and difficult agentic tasks.

Fine-grained MoE (Mixture of Experts) is a design in which only a subset of parameters is activated in a model with a very large total parameter count. Unlike early MoE (e.g., 2–8 large experts per layer), fine-grained MoE splits experts into smaller, more numerous units, and the routing network selects a few experts per token to participate in computation. The benefit: with the same number of activated parameters, expert combinations are more flexible, specialization is higher, and both training and inference load are more balanced. The cost is that routing overhead and VRAM usage rise with the total number of experts. Of Mistral Large 4's 128 routed experts, only 4 are woken per token, plus one shared expert—meaning the vast majority of weights are "asleep" when processing a single token. This is the key to running a trillion-parameter model at roughly 52 billion activated parameters.

License: Open Weights, Not Open Source

Mistral created a custom "Mistral Ecosystem Open Weight License" for this model, modified from MIT. Personal use, modification, fine-tuning, and integration into commercial products are all free. But if you want to offer hosted API access as a Model-as-a-Service, you need to apply to Mistral for a separate commercial license.

In other words, self-hosting for your own use is fine; selling API access is not. Note in particular that this is "open weight," not an OSI-approved open-source license. Calling it "fully open source" in public is inaccurate.

The difference between open weight and open source is often confused. The OSI's open-source definition requires that the license allow anyone to use, modify, and redistribute the software for any purpose, without restricting the field of use. Open weight only guarantees that the model parameter files are downloadable and self-hostable, but the license often carries restrictive clauses—in this case, prohibiting selling the model as a hosted API without permission. Such "almost open source but with commercial protection" licenses have precedents in models like Llama and Gemma, and the industry usually refers to them collectively as "open-weight models." For developers, the practical difference is: internal use, fine-tuning, and integration into products are generally free; but if you want to build a competing inference service, you need to negotiate a license separately.

Benchmarks: Vendor Numbers Look Great, but Independent Verification Is Needed

Mistral and Hugging Face published a series of results, but these are all vendor self-reported numbers with no complete reproduction by an independent lab yet.

On Cognition's Frontier Code 2.0 (which measures whether maintainers are willing to merge an agent's changes), it leads at 19.7%. Terminal Bench 4.0 scores 41%, a 13-point improvement over the preview while using 30% fewer output tokens. The Artificial Analysis Coding Agent Index gives it 48%, roughly on par with leading open-weight models but using 47% fewer tokens per task. Cyber Index is 51%, with a 96.6% malicious-cyber refusal rate—the highest among the open models tested. In the Surge Code blind test, raters preferred it over all open-source competitors, trailing only Claude Opus 5.5.

These numbers are impressive, but until the community reproduces them, it's best to treat them as "claims" rather than "facts."

VRAM Tiers: Where Does Your Hardware Land?

The following data comes from Unsloth's Day Zero documentation. Note that "total memory" here means RAM plus VRAM, and you need to leave headroom for the OS, KV cache, and runtime buffers.

• Dynamic 1-bit quantization: 233GB on disk, requires 256–270GB total memory. 1-bit retains 91% of top-1 accuracy and is 80% smaller than FP8.
• 2-bit: smaller footprint, retains 95% accuracy, about two-thirds the size of FP8.
• 3-bit: 302–378GB files, requires 310–390GB memory; another 3-bit tier requires 435–500GB.
• 4-bit: requires 630GB.
• 8-bit: requires 1.2TB.

Compression efficiency is already quite impressive, but this is still a "truck"-level burden.

The relationship between quantization bits and retained accuracy needs to be understood: 1-bit, 2-bit, etc. refer to the average number of bits per weight. Lower bit counts mean smaller files and less VRAM, but greater information loss. Dynamic quantization allocates different precision across layers, retaining higher bit counts for sensitive layers, which is why 1-bit can still preserve about 91% of top-1 accuracy. Another key concept is Unified Memory: in architectures like Apple Silicon, the CPU and GPU share the same memory pool, so the model doesn't need to be shuttled between RAM and VRAM—making the "total memory = RAM + VRAM" framing especially applicable to high-memory Macs. On traditional discrete-GPU platforms, weights must reside fully in VRAM, with overflow offloaded to system memory at a significant speed cost.

Four Paths to Run It: Pick Your Door by Hardware

Mistral officially recommends two sampling settings: temperature 1.0, top P 0.95, consistent across all reasoning levels. Don't use the low-temperature settings of older chat models; higher temperature combined with top P filtering keeps reasoning modes diverse without collapsing. Choose reasoning level by task: low replaces the old "none" mode for simple questions; medium is the default for everyday chat and lightweight tools; high is for coding sessions, long tool chains, and difficult analysis, and is also the factory default.

There are roughly four ways to run it:

1. The easy path: Unsloth Desktop (Mac/Windows/Linux) finds the model entry, downloads the quantization your memory allows, and serves it with one command, with support for reasoning effort settings.
2. The tinkerer path: Use Llama server with GDK to manually control GPUF paths, context size, GPU layers, and sampling flags.
3. The data-center path: Official FP8 or NVFP4 checkpoints deployed across 8 GPUs with VLLM or SGLang; the NVFP4 version supports only Blackwell cards.
4. The API path: If you don't want to download hundreds of GB, just call the API.

Be aware that there is currently no verified Day Zero Ollama library listing. GGUF files exist, but Ollama tags don't—don't paste commands you can't verify.

The choice of inference engine directly affects deployment feasibility. VLLM and SGLang are high-throughput serving frameworks commonly used in data centers, supporting tensor parallelism (splitting the model across multiple GPUs for joint computation), continuous batching, and PagedAttention—suitable for 8-GPU-class FP8/NVFP4 deployments. llama.cpp (the ecosystem referred to as "Llama server with GDK") targets single machines and consumer hardware, supports GGUF format and various quantizations, and can run in mixed CPU+GPU environments, but with limited throughput and concurrency. Ollama is a wrapper on top of llama.cpp offering simpler model pulling and running; its model library tags require official review, so a window often appears early after a new model launch where "GGUF exists but the Ollama tag isn't live yet."

Single-Machine Reality: A Story Without 24GB GPUs

Frankly, a 24GB GPU can't run this model. 1-bit needs 256GB of unified memory, meaning a maxed-out Mac Studio or two DGX Sparks. 2-bit needs about 512GB of unified memory—an Apple Silicon Ultra-class machine—at roughly 15 tokens per second. 4-bit needs 630GB, already beyond single-machine territory, requiring two large workstations or a small cluster node. The data-center option is 8× H200 for FP8, or 4× B200 for NVFP4.

Home labs have only three choices: a large unified-memory Mac, RAM+VRAM pooling with offloading, or just use the API. Using the API is nothing to be ashamed of.

Competitive Landscape and API Pricing

Compared with similar giant models: Beam 501B uses the Apache 2.0 license with no hosting restrictions—a freer license; but Mistral claims leadership in coding and cybersecurity, with higher token efficiency. Kimmy K2 is another ~1T-parameter MoE, which the community considers friendlier for single-machine stories. Step 5 Preview is 600B parameters, aimed at data centers. Quen 3.8 Max is a 2.4T-parameter text-only model under a custom commercial license. LeChonc's positioning is the middle path: claimed best open-source coding and defensive data, a single checkpoint with multimodal input/output, European infrastructure training, and a license that allows self-hosting (but not competing API businesses).

API pricing is 70 cents per million input tokens, 7 cents on cache hits, and $2.10 per million output tokens. A weekend of agent experiments costs less than lunch. Mistral's vibe code can point directly at your repo, OpenRouter also offers the model, and Nvidia provides an endpoint plus optimized NIM containers to make it easy to test the serving path before building your own.

Conclusion: Spend $20 First, Then Decide

If you have a 512GB unified-memory machine, download the 2-bit dynamic quantization, use medium for chat and high for agents. If you have 256GB, go 1-bit and keep context moderate. If you have a Blackwell cluster, pull the official NVFP4 and serve it with VLLM or SGLang. Everyone else: use the API, or wait for the distilled small versions the company promised (no timeline yet).

The most pragmatic advice: spend $20 on API calls first. If the answers are worth downloading 400GB for, you'll know; if not, you've saved a weekend of rsync time. Before trusting anyone's screenshots—including mine—measure your own hardware.

One-line Summary

Mistral Large 4 goes open-weight with a trillion-parameter MoE, needs at least 256GB of memory, and is best tried via API first.

Paragraph Summary

Mistral Large 4 (codename LeChonc) moves from API preview to open-weight download, using a fine-grained MoE architecture with ~1T total parameters, ~52B activated per token, 1M-token context, and multimodal input. The license is a modified MIT that allows self-hosting and commercial integration but prohibits offering API access as a model-as-a-service. Vendor-reported scores: 41% on Terminal Bench 4.0 and 19.7% on Frontier Code 2.0, trailing only Claude Opus 5.5 in blind tests—none independently reproduced. Hardware barriers are steep: 1-bit dynamic quantization needs 256–270GB total memory, 2-bit about 512GB unified memory, and a 24GB GPU can't run it. The article lays out four paths—easy desktop app, manual llama server, multi-GPU data center, and API—and recommends spending about $20 on API calls before deciding whether to download hundreds of GB of weights.