# Which Model Architectures Are Fully Verified-Native in MTPLX?

> Discover which model architectures are fully verified-native in MTPLX. Only Qwen 3 Next MTP offers complete verification and native multi-token prediction support.

- Repository: [Youssof Altoukhi/MTPLX](https://github.com/youssofal/MTPLX)
- Tags: deep-dive
- Published: 2026-09-04

---

**Only the Qwen 3 Next MTP architecture (`qwen3-next-mtp`) holds the fully `verified-native` support level in MTPLX, making it the sole model family with complete verification and native multi-token prediction capabilities out-of-the-box.**

The MTPLX repository (`youssofal/MTPLX`) maintains a strict architecture catalog that categorizes model families by their implementation maturity and verification status. Understanding which model architectures are fully verified-native is critical for production deployments requiring guaranteed multi-token prediction (MTP) stability and native backend optimization.

## Understanding Verified-Native Support Levels

MTPLX classifies model architectures using a tiered support system defined in the `ARCHITECTURE_CATALOG`. The **verified-native** designation represents the highest tier, indicating the architecture has passed full verification suites and implements native MTP without compatibility layers.

According to the source code in [`mtplx/backends/registry.py`](https://github.com/youssofal/MTPLX/blob/main/mtplx/backends/registry.py), this catalog assigns each architecture a `support_level` string that determines how the backend initializes the model and which optimizations are enabled.

## The Only Fully Verified-Native Architecture: Qwen 3 Next MTP

As of the current MTPLX codebase, **Qwen 3 Next MTP** (`qwen3-next-mtp`) stands alone as the only architecture with `verified-native` status.

In [`mtplx/backends/registry.py`](https://github.com/youssofal/MTPLX/blob/main/mtplx/backends/registry.py) at line 211, the architecture entry explicitly sets:

```python
support_level="verified-native"

```

This designation means the model can run with complete verification and native multi-token prediction support immediately upon initialization. No additional configuration flags or compatibility modes are required for full functionality.

## Alternative Support Levels for Other Architectures

All other architectures in the MTPLX catalog use alternative support designations that exclude them from fully verified-native status:

- **verified-native-ar-only** — Provides verified native support exclusively for autoregressive (AR) generation, lacking full MTP verification
- **experimental-native-contract-gated** — Requires explicit contract acceptance and carries experimental stability guarantees
- **recognized-backend-pending** — Acknowledged by the backend but pending full verification integration

For example, the `laguna-s-2.1-ar` architecture carries the `verified-native-ar-only` label, indicating it does not support the complete verified-native MTP pipeline available to Qwen 3 Next MTP models.

## How to Verify Architecture Support Levels Programmatically

You can query the support level for any registered architecture using the MTPLX CLI inspector. The tool reads directly from the `ARCHITECTURE_CATALOG` defined in the registry.

To check if a specific model is fully verified-native:

```bash

# Query the support level for Qwen 3 Next MTP

mtplx inspect --model qwen3-next-mtp --json | jq '.support_level'

```

The command returns:

```json
"verified-native"

```

Contrast this with a non-fully-verified architecture:

```bash

# Check a model with AR-only support

mtplx inspect --model laguna-s-2.1-ar --json | jq '.support_level'

```

Which returns:

```json
"verified-native-ar-only"

```

## Implementation Details in Source Files

Two critical files manage the verified-native classification system:

- **[`mtplx/backends/registry.py`](https://github.com/youssofal/MTPLX/blob/main/mtplx/backends/registry.py)** — Contains the `ARCHITECTURE_CATALOG` dictionary where each model family’s `support_level` is defined. This is where the `verified-native` string is assigned to `qwen3-next-mtp` at line 211.

- **[`mtplx/inspect.py`](https://github.com/youssofal/MTPLX/blob/main/mtplx/inspect.py)** — Implements the CLI `mtplx inspect` command that queries the catalog and returns the support level metadata for validation and debugging purposes.

## Summary

- Only **Qwen 3 Next MTP** (`qwen3-next-mtp`) holds the fully `verified-native` support level in the MTPLX architecture catalog.
- The designation is defined in [`mtplx/backends/registry.py`](https://github.com/youssofal/MTPLX/blob/main/mtplx/backends/registry.py) with `support_level="verified-native"`.
- Other architectures use lower tiers like `verified-native-ar-only` or `experimental-native-contract-gated`.
- Use `mtplx inspect --model <name> --json` to programmatically verify any architecture's support status.

## Frequently Asked Questions

### What does verified-native mean in MTPLX?

**Verified-native** indicates an architecture has passed comprehensive verification suites and implements native multi-token prediction without compatibility layers or experimental flags. According to the [`mtplx/backends/registry.py`](https://github.com/youssofal/MTPLX/blob/main/mtplx/backends/registry.py) source, this is the highest support tier in the `ARCHITECTURE_CATALOG`.

### Is Qwen 3 Next MTP the only fully verified-native model?

**Yes.** As implemented in `youssofal/MTPLX`, the `qwen3-next-mtp` architecture is the sole entry with `support_level="verified-native"` at line 211 of [`mtplx/backends/registry.py`](https://github.com/youssofal/MTPLX/blob/main/mtplx/backends/registry.py). No other model families currently qualify for this top-tier classification.

### What is the difference between verified-native and verified-native-ar-only?

**Verified-native** provides full multi-token prediction (MTP) support with complete verification, while **verified-native-ar-only** restricts verified native execution to autoregressive generation only. The latter lacks full MTP verification, as seen with architectures like `laguna-s-2.1-ar` in the registry.

### How do I check if my model is verified-native?

Run the MTPLX CLI inspector command: `mtplx inspect --model <architecture-name> --json | jq '.support_level'`. If the output returns `"verified-native"`, the model has full verified-native status. Any other value indicates limited or experimental support according to the catalog definitions in [`mtplx/backends/registry.py`](https://github.com/youssofal/MTPLX/blob/main/mtplx/backends/registry.py).