QwiVer3.6-35B-A3B
Qwen was the base. QwiVer won the desk.
BlackRiver AI's flagship local coding + agent model
35B total · ~3B active · 262K native context · Vision · Native MTP · GGUF
BlackRiver internal verdict: QwiVer3.6-35B-A3B consistently outperforms the upstream Qwen3.6-35B-A3B in our daily-use and real-world workflow evaluation.
It became the model we keep open.
QwiVer is not a renamed quantization and it is not an untouched Qwen checkpoint behind BlackRiver branding.
It is the released result of a BlackRiver curriculum post-training → Phase 10.2 adapter selection → exact BF16 merge → MTP-aware GGUF conversion → structural and inference validation pipeline.
The target was simple: take one of the most interesting small-active MoE architectures available and push its working behavior toward the kind of model we actually want beside us all day — deliberate, persistent, code-aware, tool-minded and difficult to derail once it has a job.
The result is our daily driver.
The short version
QwiVer3.6-35B-A3B inherits an unusually efficient sparse architecture:
| QwiVer3.6-35B-A3B | |
|---|---|
| Total parameters | ~35B |
| Parameters active per token | ~3B |
| Layers | 40 |
| Experts | 256 |
| Active experts | 8 routed + 1 shared |
| Native context | 262,144 tokens |
| Modalities | Text + Vision |
| Reasoning | Thinking mode |
| Speculative decoding | Native MTP preserved |
| Primary release format | GGUF |
| Primary runtime | llama.cpp |
That is the appeal of the architecture: a 35B parameter pool behind a roughly 3B-active path.
QwiVer keeps that efficiency while changing the behavior riding on top of it.
Why QwiVer exists
Qwen3.6-35B-A3B is already a strong model.
That is precisely why we chose it.
BlackRiver was not trying to rescue a weak foundation. We wanted to see how far a highly capable sparse MoE could be pushed with targeted post-training aimed at actual software-engineering and agentic work instead of generic benchmark cosmetics.
The upstream checkpoint remained our control throughout development.
The release decision was made for a much less abstract reason:
When both models were available, we kept choosing QwiVer.
For BlackRiver's day-to-day use, QwiVer is the stronger working model.
BlackRiver verdict
Upstream Qwen3.6-35B-A3B
- exceptional sparse MoE foundation
- strong coding and reasoning capability
- vision
- long context
- tool use
- native MTP
- BlackRiver control model
QwiVer3.6-35B-A3B
- BlackRiver daily-use winner
- stronger fit for repository work
- stronger fit for agentic execution
- more deliberate multi-step behavior
- better persistence across long tasks
- better alignment with tool-driven coding workflows
- retains vision + 262K native context + MTP
- ships as self-contained BlackRiver-merged GGUF releases
Same exceptional sparse architecture. Different behavior.
The superiority claim above refers to BlackRiver's internal A/B evaluation and sustained daily use, not to imported upstream benchmark numbers.
We do not relabel Qwen's published scores as QwiVer scores.
What it feels like
A baby GPT-5.6 Sol / Fable 5 feeling — running locally.
That is the shortest description after using QwiVer as a daily model.
Not because a ~3B-active local MoE suddenly has the knowledge coverage, compute budget or absolute ceiling of frontier-scale systems.
The comparison is about working behavior:
- it decomposes instead of immediately guessing
- it tends to keep a task model in its head
- it is comfortable operating through tools
- it can stay coherent across multi-file work
- it behaves more like a coding collaborator than an autocomplete engine
- it is willing to keep digging when the first answer is not enough
- it often feels more "agent-native" than its active parameter count suggests
That behavioral character is the reason QwiVer replaced upstream Qwen3.6-35B-A3B in our own daily workflow.
"GPT-5.6 Sol / Fable 5 feeling" is BlackRiver's subjective behavioral shorthand from daily use. It is not a claim of benchmark equivalence, identical capability, endorsement, or affiliation.
Built for work, not demos
QwiVer is most at home when it has context, tools and an actual job.
Repository work
Codebase navigation, multi-file reasoning, implementation, refactoring, debugging and iterative engineering where the model must maintain a coherent picture of a real project.
Agentic execution
OpenCode-style environments, shell agents, MCP tools, local OpenAI-compatible harnesses, browser/tool workflows and systems where the model must continue after the first answer.
Long-context reasoning
The native 262,144-token context window gives QwiVer room for large repositories, technical documents, logs and persistent task state.
Multimodal local systems
Pair the language-model GGUF with the supplied BF16 multimodal projector for compatible vision input.
Local-first development
QwiVer is built for the idea that a serious working model can live on your own machine, behind your own tools, with your own files, without renting every token.
BlackRiver post-training
The public release descends from the selected Phase 10.2 curriculum adapter.
| Training / release property | Value |
|---|---|
| Curriculum examples | 1,531 |
| Training tokens | 3,999,924 |
| Optimizer steps | 383 |
| Base precision | BF16 |
| Adapter strategy | LoRA |
| Selected adapter | Phase 10.2 |
| Release strategy | Exact adapter merge into BF16 base |
| Native context retained | 262,144 tokens |
The adapter is not required at inference time.
For the public release, Phase 10.2 was merged directly into the exact BF16 language-model base before GGUF conversion.
The model you download is therefore the merged QwiVer model, not an upstream Qwen quant with an external adapter bolted on at runtime.
Release provenance
Qwen3.6-35B-A3B BF16 foundation
│
▼
BlackRiver curriculum
post-training
│
▼
Phase 10.2 LoRA
│
▼
exact BF16 merge
│
▼
MTP-aware GGUF conversion
│
▼
structural + inference validation
│
▼
QwiVer3.6-35B-A3B
Every public QwiVer GGUF descends from the merged BlackRiver checkpoint.
That distinction matters.
Architecture
QwiVer inherits Qwen3.6's sparse Mixture-of-Experts design.
Instead of activating the entire ~35B parameter pool for each token, the router selects a much smaller expert path.
| Architecture property | Value |
|---|---|
| Total parameters | ~35B |
| Activated parameters | ~3B |
| Layers | 40 |
| Experts | 256 |
| Routed experts active | 8 |
| Shared experts active | 1 |
| Native context | 262,144 |
| Vision | Yes |
| MTP | Preserved |
Large pool. Small active path.
That is what makes QwiVer especially interesting for high-memory local systems: the model has a much larger parameter reservoir than its per-token active compute would suggest.
GGUF releases
Pick the footprint. Keep the model.
| File | Approx. size | BlackRiver positioning |
|---|---|---|
QwiVer3.6-35B-A3B-UD-Q2_K_XL.gguf |
12.57 GB | Minimum memory |
QwiVer3.6-35B-A3B-UD-Q3_K_XL.gguf |
17.23 GB | Lightweight |
QwiVer3.6-35B-A3B-UD-Q4_K_XL.gguf |
22.85 GB | BlackRiver default |
QwiVer3.6-35B-A3B-UD-Q8_K_XL.gguf |
39.10 GB | Maximum quantized fidelity |
Recommended: UD-Q4_K_XL
For most machines with enough memory, start with:
QwiVer3.6-35B-A3B-UD-Q4_K_XL.gguf
Q4_K_XL is the BlackRiver default because it keeps a strong fidelity/footprint balance while leaving meaningful room for KV cache and long-context operation.
Choose Q8 when memory is abundant and preserving the merged model as faithfully as practical matters more than footprint.
Vision
QwiVer retains the multimodal architecture.
Use:
mmproj-QwiVer3.6-BF16.gguf
alongside the selected QwiVer language-model GGUF.
For text-only operation the projector is not required.
Native MTP
The public GGUF releases preserve the Multi-Token Prediction components required by compatible modern llama.cpp builds.
BlackRiver's release validation verified the expected MTP tensors in each production quantization.
A conservative starting point:
--spec-type draft-mtp
--spec-draft-n-max 2
Speculative-decoding gains vary by hardware, backend, workload and sampling configuration, so measure it on the machine that will actually run the model.
llama.cpp starting profile
This is a practical BlackRiver baseline, not a universal optimum:
ctx-size = 262144
parallel = 1
n-gpu-layers = all
flash-attn = on
cache-type-k = q8_0
cache-type-v = q8_0
temp = 0.6
top-p = 0.95
top-k = 20
min-p = 0.0
spec-type = draft-mtp
spec-draft-n-max = 2
For coding and agentic work, the 0.6 / 0.95 / 20 sampling profile is a strong place to begin.
Windows example
llama-server.exe `
-m ".\QwiVer3.6-35B-A3B-UD-Q4_K_XL.gguf" `
--mmproj ".\mmproj-QwiVer3.6-BF16.gguf" `
-ngl 999 `
-fa on `
--jinja `
-c 262144 `
-np 1 `
--cache-type-k q8_0 `
--cache-type-v q8_0 `
--spec-type draft-mtp `
--spec-draft-n-max 2 `
--temp 0.6 `
--top-p 0.95 `
--top-k 20 `
--min-p 0.0
For text-only inference, remove the --mmproj argument.
A 262K architectural context limit does not mean every hardware configuration can practically allocate a 262K KV cache. Size context for the memory available on the target system.
Thinking / reasoning mode
QwiVer retains Qwen3.6's reasoning behavior and can emit Qwen-style thinking blocks when the selected template/runtime enables them.
For difficult repository work, planning, debugging and multi-step agentic tasks, this is generally how BlackRiver uses the model.
For low-latency conversational work, direct/non-thinking operation can still make sense.
Where we use it
QwiVer is designed to sit behind systems such as:
- OpenCode
- Qwen Code
- OpenClaw
- repository agents
- local shell / terminal agents
- MCP environments
- browser/tool agents
- local OpenAI-compatible APIs
- custom BlackRiver applications
- long-context coding assistants
The model is especially compelling when the runtime can give it real tools and real state instead of forcing every task through a chat-only interface.
Development hardware
QwiVer's development, merge, conversion and daily local evaluation were built around BlackRiver's AMD Strix Halo workstation:
- AMD Ryzen AI Max+ PRO 395
- Radeon 8060S
- 128 GB unified memory
- Windows
- ROCm where appropriate in training / merge work
llama.cppVulkan for production-style local GGUF inference
The GGUF release itself is not AMD-specific.
Compatible llama.cpp deployments can target Vulkan, CUDA, Metal, CPU and other supported backends.
Evaluation philosophy
We care about benchmark numbers.
We care more about whether the model survives real work.
BlackRiver evaluates QwiVer through a mixture of structural validation, controlled comparisons and repeated practical use:
- base vs adapter / merged-model comparison
- held-out behavioral evaluation
- repository-level coding work
- debugging and iterative correction
- multi-file task persistence
- agent/tool workflows
- long-context use
- model loading and inference validation
- multimodal compatibility checks
- MTP tensor validation
- quantization integrity checks
Internal result
QwiVer3.6-35B-A3B is the BlackRiver winner over upstream Qwen3.6-35B-A3B for our daily coding and agentic workflows.
That is why this model exists and why this is the version we release.
We intentionally do not copy upstream Qwen benchmark numbers into a table and pretend they are QwiVer results.
Any future public head-to-head numbers should be run under matched conditions:
same task · same harness · same runtime · same quantization class · same context · same sampler · same hardware
Until then, the claim on this card is exactly what it says: a BlackRiver internal A/B + sustained daily-use verdict.
Behavioral profile
Post-training changes behavior.
QwiVer should not be expected to reproduce upstream Qwen's exact response style, prioritization, refusal boundaries or decision patterns.
That is intentional.
The point of QwiVer is not to preserve every behavior of the control model. The point is to produce the BlackRiver version we would rather run.
Greater willingness to act does not make a model automatically correct, however. Tool-enabled deployments should still use appropriate filesystem permissions, sandboxes, backups, command review and network boundaries.
Limitations
QwiVer can still:
- hallucinate
- write broken code
- misunderstand repository state
- make incorrect assumptions
- misuse tools
- produce destructive commands
- lose coherence under pathological context pressure
- generate insecure implementations
- confidently choose the wrong approach
Do not treat it as the sole authority for high-stakes medical, legal, financial, security or safety-critical decisions.
The more autonomy you give a model, the more important the surrounding engineering becomes.
Model lineage
| Stage | Model / artifact |
|---|---|
| Upstream foundation | Qwen/Qwen3.6-35B-A3B |
| Training base | unsloth/Qwen3.6-35B-A3B |
| BlackRiver adapter | Phase 10.2 curriculum LoRA |
| Merge | Exact BF16 merge |
| Release | QwiVer3.6-35B-A3B GGUF family |
| Vision projector | mmproj-QwiVer3.6-BF16.gguf |
| Runtime target | llama.cpp |
Credits
Qwen
Architecture, pretrained/post-trained foundation, multimodal system and the original Qwen3.6-35B-A3B release.
Unsloth
Training / BF16 workflow and ecosystem contributions used in the QwiVer development pipeline.
llama.cpp
GGUF inference, multimodal runtime and MTP-capable local execution.
BlackRiver AI
Curriculum design, post-training, Phase 10.2 selection, evaluation, exact BF16 merge, MTP-preserving release engineering, quantization, validation and publication.
Creator: A.I Joe
Publisher: BlackRiver AI Ltd
- Downloads last month
- 925
2-bit
3-bit
4-bit
8-bit
Model tree for BlackRiverAI/QwiVer3.6-35B-A3B-GGUF
Base model
Qwen/Qwen3.6-35B-A3B