2.8 Trillion-Parameter Open-Weights LLM: Weight Downloads, Benchmarks, and Commercial Licensing Explained
A Mixture-of-Experts (MoE) model with 2.8 trillion total parameters—activating 104 billion per inference—has opened its weights for public download: roughly 1.56 TB, quantized in MXFP4 and split into 96 shards. This article explains what the release means in practice: how to read the vendor-reported benchmarks (65.7% on a terminal command execution and agentic task benchmark, versus 66.4% for the top closed-source model), how the three-tier license draws commercial boundaries (free use until you offer Model-as-a-Service or exceed US$20 million in revenue over a 12-month period, plus attribution requirements at 100 million MAU), how the US$10 per million output token API price compares with a US$2.5 competitor whose weights remain closed, the capability cost of safety alignment (a drop from 90.5% to 81% on vulnerability exploitation tests), and a practical framework for deciding between API calls and self-hosted deployment.
From “Accessible via API” to “Ownable Weights”: A New Watershed for Open LLMs
Over the past year, competition in the large language model space has unfolded along two fronts: the raw intelligence of the models themselves, and the business models around model distribution. Early open-source models were mostly in the tens-of-billions parameter range, while top-performing closed models were delivered through APIs. Recent developments are eroding that boundary: a Mixture-of-Experts (MoE) model with 2.8 trillion total parameters—activating 104 billion per inference pass—has released its weight files for public download.
The significance goes well beyond the record-setting parameter count. It marks a new phase in how large models are distributed: developers are no longer limited to calling an API. They can download the full set of weights (about 1.56 TB) onto their own infrastructure for deployment, fine-tuning, and further development. The shift is analogous to moving from “renting software” to “buying the source code,” giving engineering teams unprecedented autonomy and room for customization.
Note that this release does not simply hand the full model to the community with zero conditions. The model is quantized in MXFP4 (a 4-bit floating-point precision format) and published in 96 shards. The engineering rationale is twofold: 4-bit quantization compresses the model down to a transferable size (1.56 TB), putting self-hosted inference clusters within reach of mid-sized AI teams, while the sharding design supports distributed loading and parallel inference scheduling, lowering the deployment barrier.
Hardware Requirements and Benchmark Reality: How Much Are Leaderboard Scores Worth?
For most developers, the first question is: how capable is this model in practice? According to the official benchmark results published by the model’s creator, it scores 65.7% on a terminal command execution and agentic task benchmark—only 0.7 percentage points behind the current top closed-source model (66.4% on the same benchmark) and clearly ahead of another mainstream closed model’s 58.2%.
These numbers call for careful interpretation. First, the 65.7% score was achieved with inference compute “maxed out”—the model spends more compute on self-verification and error correction for each question, rather than running in the default lower-cost mode. Second, these are vendor-reported results; no independent third-party lab has reproduced them under the same test protocol. Without neutral validation, reading this score as “matching closed-source first-tier level” is premature. The more reasonable interpretation is that the model demonstrates a theoretical capability ceiling close to the very best, but real-world project performance still needs to be verified against private evaluation sets.
Another phenomenon worth noting: community reports of “high scores on public benchmarks, failures on private test sets.” This is not an isolated incident but a widespread challenge in LLM evaluation. Public benchmark sets have circulated long enough that they may have leaked into training data, producing a “teaching-to-the-test” effect. When assessing this model’s true strength, teams should build evaluation sets tightly tied to their own business scenarios rather than blindly trusting public leaderboards.
The License, Decoded: Open Weights ≠ Free Commercial Use
Alongside the weights, the release includes a license that explicitly defines its commercial boundaries. Its core terms fall into three tiers:
Tier 1: Unrestricted use. For internal research, product prototyping, non-commercial development, and similar scenarios, developers can freely download and use the model weights without additional authorization—consistent with the spirit of mainstream open-source licenses.
Tier 2: Triggered commercial licensing. Users must sign a separate commercial agreement with the model’s creator if either condition is met: (1) they offer “Model as a Service” (MaaS) based on the model—that is, charging third parties, directly or indirectly, for inference via API; or (2) their commercial revenue exceeds US$20 million over a consecutive 12-month period. In other words, a startup using the model to build its own internal tools can keep using it for free even if it grows into a unicorn, as long as it never crosses either red line: reselling model services to outsiders or exceeding the revenue threshold.
Tier 3: User-visible attribution obligation. When a product powered by the model exceeds 100 million monthly active users, or US$20 million in monthly revenue, the product interface must clearly display the underlying model’s name. Similar to academic citation norms, this clause protects the model developer’s attribution rights and brand transparency.
For enterprise decision-makers, understanding this framework is essential. The real value of open weights is that they make private deployment a legitimate option—data can stay within your own perimeter, and the model becomes customizable. But “open” does not waive payment obligations for every commercial scenario. Mistaking “open weights” for “free for all commercial use” can plant compliance risks.
The Real Economics of Inference: Is the API Worth the Price?
Beyond the weights, official API pricing is another observable dimension. The model’s official API output price is about US$10 per million output tokens. On the same day, another cloud vendor released a comparable large model whose API output price is US$2.5 per million tokens—just one quarter of the former.
This pricing gap reflects different vendor strategies: the first targets a “performance-first” market, using higher unit prices to cover inference costs and sustain high availability; the second plays a volume game, using lower per-call costs to grab market share quickly. Note, however, that the cheaper model—with 770 billion total parameters and 49 billion activated—is somewhat smaller than the model discussed here, and its weights have not been released. That means users cannot avoid ongoing API fees through self-hosting.
Taken together: for low-volume applications without special data-privacy requirements, choosing the cheaper third-party API is the rational option. For teams with very high call volumes, or those that prioritize data sovereignty or deep customization, a one-time private deployment may be more cost-effective in the long run—even after accounting for hardware, GPU clusters, and operations staff.
Safety Alignment Costs: The Selection Criterion Nobody Checks
In model selection, one often-overlooked yet critical dimension is safety and alignment. The technical report accompanying this release discloses a key data point: after removing cyberattack-related training data, the model’s pass rate on a vulnerability exploitation test dropped from 90.5% to 81%—roughly a 9.5 percentage point capability loss in generating code useful for penetration testing or exploit development.
This reveals the inherent tension between safety and capability. To reduce the risk of malicious use—generating attack code or phishing emails, for example—developers must run safety alignment training, and that process necessarily sacrifices some raw capability. For enterprises operating in high-risk domains such as network security or financial risk control, a model’s safety performance may matter more than its benchmark scores. A high-scoring model capable of writing malicious code is a liability, not an asset. Your evaluation checklist should therefore include “safety benchmarks”—request them from the model provider or test them yourself.
Conclusion: A Model Selection Framework for the Open-Weights Era
Taken together, this 2.8-trillion-parameter open release does mark a genuine milestone in the technology’s evolution. It proves that very large models can be effectively quantized and openly distributed, and it demonstrates how a commercial license can balance the interests of different stakeholders.
For technical decision-makers, we suggest the following selection framework: First, clarify your project’s data-sensitivity level and compliance requirements to determine whether private deployment is necessary. Second, compare “total API cost (unit price × projected call volume)” against “total self-hosting cost (GPU hardware amortization + operations labor + power).” Third, build private evaluation sets focused on actual performance in your own business scenarios rather than relying on public leaderboards. Finally, review the full license text and assess your risk of triggering the commercial terms.
The competition among large language models is shifting from a pure benchmark race toward a contest of engineering execution. Organizations that can combine model capability, cost control, and compliance will be the ones that lead the next wave of AI adoption.
