The Open Frontier Changed While You Were Planning Your K3 Deployment
Kimi K3 is no longer the only frontier-scale open-weight model you can run on-prem. Here is what changed, what the new options actually require, and how to think about choosing between them.
Three months ago, I wrote that Kimi K3 was the first open frontier model you could actually run on-prem. That was true in July. By October, it is no longer the interesting question.
The interesting question is what comes after K3.

Between July and September 2026, four new frontier-scale open-weight models shipped: Xiaomi's MiMo V2.6 Pro, Z.ai's GLM-5.3, DeepSeek's V4 Pro (GA after four months in preview), and Tencent's Hunyuan Hy4 preview. Each is a frontier-scale MoE with a million-token context window. Each one makes a different set of tradeoffs. And none of them makes K3 obsolete, because "which is best" depends entirely on what you are deploying it for.
The important shift is not that K3 got beaten. It is that K3 stopped being the only serious architectural option.
What Actually Changed Since July
When K3 launched, it stood alone. A 2.8-trillion-parameter MoE with open weights, 1M context, and competitive benchmark scores. If you wanted to run a frontier model on your own infrastructure, K3 was the answer because it was the only answer.
Now there are five frontier-scale open-weight options, and the differences between them are not just benchmark points. They differ in architecture, active parameter count, hardware floor, license terms, and which workloads they optimize for. Most of this new competition is coming from Chinese labs, but the more important observation is that these are not clones of each other. They are making genuinely different engineering choices.
The New Models
MiMo V2.6 Pro (Xiaomi, September 22, 2026) 1.02T total parameters, 42B active per token. A sparse MoE with 384 routed experts, 8 active per forward pass. Multimodal: text, image, video, and audio. MIT licensed.
MiMo is interesting because of its efficiency. At 42B active parameters, it needs roughly 573 GB of VRAM for the weights alone. That puts it on a single 8-GPU H200 node for basic inference. For production throughput, Xiaomi recommends two nodes with TP-16. Compared to K3's 104B active parameters and 1.56 TB MXFP4 footprint, that is a fundamentally different hardware conversation.
The tradeoff is clear: less compute per token means you can serve it on less hardware, but 42B active parameters is doing less work per forward pass than K3's 104B. Whether that matters depends on your workload.
GLM-5.3 (Z.ai, August 14 API / weights released August 28, 2026) 743B total, approximately 40B active. No new pre-training over GLM-5.2; the gains come from post-training and a reasoning overhaul. GLM-5.3 is particularly interesting if coding and cybersecurity are your primary workloads: it posted strong results on Terminal-Bench 3.0 (28.3%) and CyberGym (84.5%), and Z.ai describes emergent cyber capabilities they did not specifically train for.
The weight release came with a complication. GLM-5.3's license is not MIT or Apache 2.0. It is a custom "GLM-5.3 License" that is permissive for most users but includes a security review gate for companies with aggregate Model-as-a-Service revenue above $10 billion. For enterprise deployment where you are running the model internally, this gate does not apply. But your legal team will still need to read a bespoke license, which is a different conversation than pointing at an MIT file.
DeepSeek V4 Pro (DeepSeek, preview April 24, GA August 13, 2026) 1.6T total, 49B active. MIT licensed. 1M context with a 384K output ceiling.
The architectural differentiator is DeepSeek's compressed attention design, which reportedly reduces single-token inference compute to 27% and KV cache to 10% compared to their V3.2 generation. That matters a lot for long-context workloads, which is where the 1M window actually gets used.
The hardware problem is real, though. At full precision, V4 Pro needs approximately 3,130 GB of VRAM. That is roughly 40 H100 80GB cards. This is the heaviest model on this list by weight count, and while the attention optimizations help with inference throughput, you still need to fit the model in memory first.
DeepSeek V4 Pro also illustrates the benchmark problem. The preview version scored 36 on the Artificial Analysis Intelligence Index v4.3. The GA version (0813), tested later, scored 53.2% on the same index framework. Same model family, same architecture, very different scores. Version matters.
Hunyuan Hy4 Preview (Tencent, August 28, 2026) 770B total, 49B active. MoE with 256 routed experts plus 1 shared expert, top-8 activation. Apache 2.0 licensed. Over 1M context.
Two things to flag. First, this is a preview release, not GA. Tencent is explicit about that. For production enterprise deployment, "preview" is a meaningful qualifier: it means the model may change before final release, and support commitments are different.
Second, the Apache 2.0 license is the cleanest on this list. No revenue gates, no security reviews, no custom terms. If license simplicity is your primary constraint, Hy4 is the most straightforward option.
Hardware: BF16 requires approximately 1,848 GB, so 16x B200 or 8x B300 minimum. Quantized to MXFP8, it fits on a single 8-GPU data-center node at around 924 GB.
The Benchmark Problem
I deliberately did not start this article with a leaderboard table. Here is why.
The Artificial Analysis Intelligence Index, one of the more rigorous composite benchmarks, changed its methodology between v4.2 and v4.3. They upgraded Terminal-Bench from 2.1 to 4.0, replaced a banking benchmark with AutomationBench-AA, and increased the weight of private test sets from 40% to 45%. Scores from v4.2 and v4.3 are not directly comparable.
Even within v4.3, version matters. DeepSeek V4 Pro's preview scored 36. The GA build scored 53.2%. The model's fundamental architecture did not change between those builds. Post-training, RLHF tuning, and inference pipeline improvements moved the score by 17 points.
The same index currently shows MiMo V2.6 Pro at 46 and GLM-5.3 at around 42-45 depending on variant. That makes DeepSeek V4 Pro the highest-scoring open-weight model on this particular benchmark. But Artificial Analysis is one framework with one set of category weights (Agents 30%, Coding 20%, General 30%, Scientific Reasoning 20%). Change those weights and the ranking changes.
The practical takeaway: if someone tells you "model X has the highest score," ask which benchmark, which version of the benchmark, which build of the model, and what the category weights are. A single composite number is not enough to make a deployment decision.
The Hardware Problem
Every model on this list requires a GPU cluster. The question is how big.
| Model | Active Params | Approx. VRAM (weights) | Minimum Config | Production Config |
|---|---|---|---|---|
| MiMo V2.6 Pro | 42B | ~573 GB | 8x H200 (1 node) | 2 nodes, TP-16 |
| GLM-5.3 | ~40B | ~550-600 GB* | 8x H200 (1 node)* | TBD (weights recently released) |
| DeepSeek V4 Pro | 49B | ~3,130 GB (FP16) | ~40x H100 80GB | Multi-node cluster |
| Hy4 Preview | 49B | ~924 GB (MXFP8) | 8x B200 (1 node, quantized) | 16x B200 (BF16) |
| Kimi K3 | 104B | ~1,560 GB (MXFP4) | 8x B300 / 16x B200 | 64+ accelerators recommended |
*GLM-5.3 weight release is recent; community deployment guides are still emerging.
K3's minimum configuration differs depending on GPU generation: it can fit on 8x B300 (each with 192 GB HBM3e) or 16x B200 (each with 192 GB). The native MXFP4 weights require Blackwell-generation hardware for full-speed execution. Older GPUs (H100, H200) can load the weights but dequantize at runtime, losing the throughput advantage.
The table tells a clear story. MiMo V2.6 Pro has the lowest hardware floor. Kimi K3 has the highest. DeepSeek V4 Pro's total parameter count makes it the heaviest at full precision, but its attention compression means inference throughput per dollar may be different from what the raw VRAM number suggests.
If you have one NVIDIA HGX node (8 GPUs), your realistic options are MiMo V2.6 Pro or a quantized GLM-5.3. Everything else requires multi-node networking, which changes the infrastructure conversation from "how many GPUs" to "what interconnect fabric."
The License Problem
For enterprises, licensing can matter more than benchmark position. Here is where things stand:
MIT (MiMo V2.6 Pro, DeepSeek V4 Pro): Use it however you want. Modify it, redistribute it, sell services built on it. No revenue gates, no review requirements.
Apache 2.0 (Hunyuan Hy4): Essentially the same freedom as MIT with an explicit patent grant. The cleanest option for IP-sensitive deployments.
Custom permissive (GLM-5.3): Broad commercial rights, but with a $10B MaaS revenue gate that triggers a security review. Does not apply to embedded product use or internal deployment. Practically equivalent to MIT for most enterprises, but it is still a custom license that legal needs to read.
Custom with gates (Kimi K3): Permissive up to $20M annual revenue or 100M monthly active users. Above those thresholds, you need a commercial agreement with Moonshot.
For internal enterprise deployments, the relevant commercial-use provisions are generally different from those governing external Model-as-a-Service offerings, but the exact license terms should still be reviewed. The practical gap between MIT/Apache and a bespoke license is the gap between a procurement conversation and a legal review, and in enterprise IT, that time difference matters.
Which Model Fits Which Workload
The deployment question is no longer "Can we run K3?" It is: which model do we want to run, for which workload, under which license, and on how much hardware?
General enterprise assistant, internal use: MiMo V2.6 Pro is the most practical starting point. Lowest hardware floor, MIT license, multimodal support. It will not match K3's raw capability at 42B active vs 104B active, but for summarization, Q&A, document processing, and internal tools, the capability is likely sufficient, and you are running it on one node instead of four.
Coding and security operations: GLM-5.3 is particularly interesting for these workloads. The Terminal-Bench and CyberGym results reflect a model that was specifically post-trained for agentic coding and security analysis. If your primary use case is code review, vulnerability assessment, or security automation, evaluate GLM-5.3 before defaulting to a general-purpose model.
Long-context workloads (legal, compliance, codebase analysis): DeepSeek V4 Pro's attention compression makes it particularly interesting when you are actually using the 1M context window at scale. The hardware cost is high, but the per-query cost for long documents may be competitive because of the KV cache reduction.
Maximum raw capability, hardware budget available: Kimi K3 still activates the most parameters per forward pass (104B vs 42-49B for everything else). If you have the infrastructure and need the highest possible quality on complex reasoning tasks, K3 remains in the conversation.
Clean licensing as the primary constraint: Hy4 on Apache 2.0, or MiMo / DeepSeek V4 Pro on MIT.
What This Means for VCF Private AI Foundation
If you are running VCF Private AI Foundation, the hardware table above maps directly to your sizing conversation. A single VCF management domain with an 8-GPU HGX workload domain can host MiMo V2.6 Pro or a quantized GLM-5.3. K3 or V4 Pro at full precision require multi-node GPU infrastructure, which introduces additional requirements around GPU interconnects, networking, placement, and failure domains.
The licensing picture is relevant here too. For internal enterprise deployments, the relevant commercial-use provisions are generally different from those governing external MaaS offerings, but the exact license terms should still be reviewed. And the gap between pointing procurement at an MIT file and asking legal to review a bespoke license is real calendar time.
The Bigger Signal
Three months ago, the open frontier was Kimi K3. Now it is five models from five companies, with three different license types, hardware requirements ranging from one node to eight, and no single benchmark that ranks them definitively.
This fragmentation is the story. It means the open-weight ecosystem is no longer waiting for one lab to ship one model that everyone runs. It means infrastructure teams need to evaluate models the same way they evaluate any other enterprise software: against their specific workload requirements, licensing constraints, and hardware budget.
It also means the models will keep coming. If five shipped between July and September, the landscape in January will look different again.
Build the platform, not around one model. Pick the model that fits the workload today. Make it possible to replace it tomorrow.
References
- Kimi K3: The First Open Frontier Model You Can Actually Run On-Prem (barhum.ai)
- Kimi K3 open weights, moonshotai/Kimi-K3 (Hugging Face)↗
- MiMo V2.6 Pro, XiaomiMiMo/MiMo-V2.6-Pro-RL (Hugging Face)↗
- Xiaomi MiMo-V2.6 series release notes (mimo.mi.com)↗
- GLM-5.3 open weights, zai-org/GLM-5.3 (Hugging Face)↗
- DeepSeek V4 Pro GA build, deepseek-ai/DeepSeek-V4-Pro-0813 (Hugging Face)↗
- DeepSeek V4 technical model card (DeepSeek)↗
- Hunyuan Hy4 Preview, tencent/Hy4-preview (Hugging Face)↗
- Announcing the Artificial Analysis Intelligence Index v4.3 (Artificial Analysis)↗
- Artificial Analysis Intelligence Benchmarking Methodology↗
Discussion
No comments yet. Be the first to start the discussion.
Related Articles
The AI Dictionary: Every Term You Need to Know, Explained Simply
A plain-language glossary of AI terms from the absolute basics to advanced concepts. No jargon walls, no assumptions. Every term explained so anyone can understand it.
AIJev and the Rise of Decision Models: What Changes When AI Returns Probabilities Instead of Text
TypeSafe AI's Jev returns typed decisions with probabilities instead of text. A technical look at what is new in the approach, a fair comparison with structured-output LLMs, what independent research says about calibration, and what it takes to self-host Jev-class open models.
AILLVM Is the Invisible Engine Behind AI Hardware. Here Is How.
From GPUs to custom AI chips, every major hardware company depends on LLVM and its younger sibling MLIR to turn AI models into running code. Here is what they are and why they matter.
Stay in the loop
Get new articles on infrastructure and AI delivered to your inbox. No spam, unsubscribe anytime.