The 2026 open-weight model landscape

4 August 2026 · 11 min · Open Models

TL;DR Open-weight model performance on coding and reasoning indexes (high 40s to low 50s) has narrowed the capability gap against leading proprietary cloud models. Mixture-of-Experts architectures allow models like DeepSeek V4-Flash (13B active) and Qwen3.6 35B-A3B (3B active) to keep inference compute low while requiring VRAM sized for total parameters. Quantized 4-bit variants of 27B to 35B parameter class models fit into standard 16 GB to 24 GB workstation VRAM envelopes. Permissive licenses (MIT and Apache 2.0) remain preferred for enterprise and commercial integration over custom community licenses.

The gap between proprietary cloud endpoints and open-weight models has narrowed significantly across coding, retrieval-augmented generation, and domain-specific agentic tasks. For software teams, enterprise architects, and infrastructure operators, self-hosting open-weight models is no longer a compromise on raw capability. The primary evaluation criteria have shifted from purely measuring benchmark accuracy to assessing inference efficiency, hardware VRAM constraints, and software license terms (P1).

Model families and architectural shifts

The 2026 open-weight ecosystem is dominated by dense and Mixture-of-Experts (MoE) architectures designed to balance total parameter capacity against active per-token compute costs. Each major release family has chosen a different point on this tradeoff curve.

[DeepSeek](https://deepseek.com) introduced two primary tiers with its V4 release (P1). The V4-Pro architecture utilizes approximately 1.6 trillion total parameters with 49 billion active parameters per token. This configuration targets enterprise and research deployments where multi-node GPU clusters are available. The V4-Flash variant deploys 284 billion total parameters with 13 billion active parameters across a 1-million-token context window. Both models ship under MIT-style permissive licenses, which grant unrestricted commercial use, modification, and distribution without behavioral restrictions on fields of endeavor.

The V4-Flash configuration is particularly relevant for self-hosting teams. With 13 billion active parameters, per-token compute cost is comparable to a 13B dense model. But the 284 billion total parameter count means the VRAM requirement is determined by the full weight set, not the active fraction. At 4-bit quantization, the total weight footprint occupies approximately 160 GB of VRAM, requiring a multi-GPU server configuration.

[Qwen Team](https://qwenlm.github.io) released Qwen3.6 in both a 27B dense variant and a 35B-A3B MoE variant (P1). The 35B-A3B architecture routes tokens through only 3 billion active parameters per forward pass, maintaining 128K to 256K context windows under an Apache 2.0 license. The dense 27B variant targets workstation-class hardware with standard 24 GB VRAM envelopes, while the MoE variant trades higher total memory requirements for substantially lower per-token compute.

The Qwen3.6 35B-A3B is notable because it pushes the active parameter count down to 3 billion while maintaining a 35 billion total parameter capacity. This means inference latency approaches that of a small 3B model, but the knowledge and reasoning capacity derives from the full 35B weight set. For teams building interactive applications where response latency matters more than throughput, this architecture is a strong fit.

[Meta AI](https://ai.meta.com/llama) introduced the Llama 4 family with two MoE configurations (P1). Scout deploys 109 billion total parameters with 17 billion active per token and supports up to a 10-million-token context window. Maverick scales to 400 billion total parameters with the same 17 billion active parameter count and a 1-million-token context window. Both ship under the Meta Community License, which permits commercial use below a 700 million monthly active user threshold but requires a separate agreement above it.

The context window specifications on Llama 4 are significant. A 10-million-token context window on Scout enables processing of entire codebases, legal document collections, or research corpora in a single inference pass. However, the key-value cache storage for such a context window scales linearly with token count, meaning VRAM requirements grow beyond the base model weight storage.

[Google DeepMind](https://ai.google.dev/gemma) updated the Gemma 4 series with 12B and 31B dense and MoE variants under Apache 2.0 licensing (P1). The Apache 2.0 terms grant patent grants and unrestricted commercial modification without telemetry requirements or user-tier limits. Concurrently, GLM-5.2, Mistral variants, and Microsoft Phi-4/5 series provide lightweight, highly optimized dense options for localized edge deployments where VRAM is constrained.

MoE parameter distribution vs VRAM floors

A critical distinction in evaluating modern open-weight models is the difference between total parameters and active parameters. This distinction drives both hardware cost and inference speed, and failing to account for it is a common procurement error.

In a Mixture-of-Experts design, only a fraction of total parameters (the active parameters) process any single token. A gating network selects which experts to activate for each token based on the input. This keeps per-token FLOPS and latency close to small dense models. However, the entire model weights must remain loaded in memory, meaning total parameter counts determine the VRAM floor.

For local workstation execution, 4-bit (Q4_K_M) quantization enables 27B to 35B class models to run within standard 16 GB to 24 GB hardware constraints. A 27B dense model at Q4_K_M occupies approximately 16 GB of VRAM, leaving headroom for key-value cache and context window storage on a 24 GB card. The 35B-A3B MoE variant at Q4_K_M occupies approximately 20 GB, which also fits within a 24 GB envelope but with less headroom for extended context.

Larger MoE configurations like Llama 4 Scout (109B total) or DeepSeek V4-Flash (284B total) require multi-GPU setups. At Q4_K_M quantization, Scout requires approximately 64 GB of VRAM, which can be served by two 32 GB GPUs or a single 80 GB data center card. V4-Flash requires approximately 160 GB, which demands a four-GPU server configuration.

The practical implication for procurement teams is that model selection must account for both the active parameter count (which determines inference speed) and the total parameter count (which determines hardware cost). A model with 3 billion active parameters and 35 billion total parameters delivers small-model latency but requires large-model memory. The cost calculation must include the hardware to hold the full weight set, not just the compute to process a token.

License selection and commercial deployment

When selecting an open-weight foundation model for production environments, licensing determines long-term deployment stability. The 2026 landscape offers three distinct license categories, and the choice between them has real consequences for what you can build and ship.

MIT and Apache 2.0 licenses (found on DeepSeek V4, Qwen3.6, and Gemma 4) grant unrestricted commercial modification, self-hosting, and integration into proprietary products without telemetry or user-tier limits. These are standard, OSI-approved licenses that enterprise legal teams can clear immediately without custom review. The legal friction is zero. A legal team encountering Apache 2.0 can clear it in minutes because they have cleared it hundreds of times before.

Custom community licenses, such as the Meta Community License terms on Llama 4, require legal review prior to embedding in enterprise software products. The 700 million monthly active user threshold creates a conditional compliance surface. Below the threshold, commercial use is permitted. Above it, a separate commercial agreement is required. For organizations building products that could scale past this line, the license introduces a future obligation that permissive licenses do not.

The practical question for a procurement team is whether the product they are building could plausibly exceed the user threshold. For internal tools, small business applications, or specialized industry deployments, the community license is workable. For consumer-facing products or large enterprise platforms, the threshold creates a dependency on the licensor that permissive licenses eliminate.

Practical selection criteria

For most self-hosted software architectures, selecting a model requires balancing three factors: license permissiveness, total VRAM requirements against target hardware, and whether the workload demands multimodal capability or text-only reasoning. A model that scores well on capability but carries a community license with a user threshold is a procurement risk. A model with a permissive license but total parameters beyond your GPU is a hardware upgrade waiting to happen.

A useful framework is to evaluate models on a two-axis grid. The first axis is VRAM fit: can the total parameter count at your target quantization fit on your hardware? The second axis is license fit: can your legal team clear the license for your intended commercial use? A model must pass both checks before it enters a pilot.

For teams with a single 24 GB workstation GPU, the viable 2026 options include Qwen3.6 27B dense (Apache 2.0, 16 GB at Q4), Gemma 4 12B (Apache 2.0, 7 GB at Q4), and Mistral variants (Apache 2.0, various sizes). For teams with multi-GPU server configurations, DeepSeek V4-Flash (MIT, 160 GB at Q4) and Llama 4 Scout (Community License, 64 GB at Q4) become accessible.

Where this leaves you

The 2026 open-weight landscape gives you more viable options than any prior year, but the selection criteria have multiplied. You need to evaluate active parameter ratios for inference speed, total parameter counts for VRAM sizing, and license terms for commercial viability. A model that fits your hardware but carries a community license with a user threshold is a future compliance task. A model with a permissive license but total parameters beyond your GPU is a hardware upgrade waiting to happen.

Before you commit to a model for production, read the license text, measure the VRAM on your actual hardware, and confirm the active parameter count delivers the latency your application requires. Which of these three constraints is most likely to shape your next model selection?