Latest in AI
Clover-35B-A3B-Preview: Diffusion Model Benchmarks and Deployment Limits
DiffuSpace's open-weight coding model generates text in blocks, but its speed claims and available serving paths need to be read separately.
DiffuSpace released Clover-35B-A3B-Preview on October 28, a text-only diffusion language model with downloadable Apache 2.0 weights. It targets coding and tool use, generating blocks of text rather than committing to one token at a time. The early attraction is speed, with some important deployment caveats.
The release history records the checkpoint's initial publication on October 28. This is an available preview model, not merely a promised weight release, although parts of its serving setup are still being prepared.
What Clover changes about text generation
Clover is derived from Qwen3.6-35B-A3B. Its model card describes a 35-billion-parameter mixture-of-experts model with about 3 billion active parameters per token and a 131,072-token limit covering prompt and response together.
In the provided implementation, a new block starts with masked positions. The model fills sufficiently confident positions in parallel, then makes the completed block part of the context for the next one. The default block size is 32 tokens.
This changes where generation can run in parallel. It does not remove the need for an agent to wait for tools, read their results and decide what to do next. A faster generation step can shorten a workflow without making the whole workflow faster by the same proportion.
Clover benchmarks: useful claims, specific conditions
DiffuSpace's launch report gives the following results. They are company-reported measurements, not independent reproductions.
| Measurement | Reported result |
|---|---|
| SWE-bench Verified | 73.6 |
| Terminal-Bench 2.1 | 51.7 |
| Generation on one GB300 | 680 tokens per second |
| Generation on one H200 | 515 tokens per second |
The GB300 speed result uses BF16 precision, batch size one and internal agent-workload data. That context matters: it is not a promise of 680 tokens per second on a desktop GPU or under a busy multi-user service.
The release compares Clover with selected models including Qwen3.6-35B-A3B, LLaDA2.2 flash and Mercury 2.5. Its lead within those tables should not be expanded into a claim that it beats every current coding model. The useful next step is to reproduce the tasks, decoding settings and latency measurements on the hardware a team expects to use.
What can developers run today?
The official repository provides a standalone Transformers path. Its example uses Transformers 5.19.0 and PyTorch 2.10 or later, with enough GPU memory for approximately 69 GB of BF16 weights plus inference state.
That is the first practical constraint. Three billion active parameters does not mean three billion parameters to store. Mixture-of-experts routing reduces the computation selected for a token, while the full model still needs to be available during inference.
There is also a gap between the launch's broad support language and the repository's setup guidance. The repository describes SGLang and llama.cpp implementations, but says their backend code and setup guides will be added. Fine-tuning instructions are marked as coming soon too. The concrete published quick-start is the Transformers route; readers should not assume every stock inference application can already load the model.
The model card warns that very long generations can become repetitive and includes controls intended to discourage that behavior. It also notes that numerical differences between the standalone implementation and SGLang can change generated text. Those details are relevant when reproducing a benchmark, not just when debugging installation.
Where the speed could become useful
For a coding agent that spends much of its time generating plans, patches and explanations, faster decoding could make each iteration less expensive in elapsed time. For an agent dominated by slow tests or network calls, the gain may be smaller. The workload decides how much of the headline speed reaches the user.
The preview is most interesting for developers who want to inspect and evaluate a diffusion model themselves, with the engineering time to work through an emerging serving stack. The next milestone to watch is a reproducible path from these released weights to reliable task completion under realistic concurrency. That would make the speed claim much easier to turn into a product decision.
I’m Paras. I work at the intersection of AI, engineering and distribution.
I help technical founders turn model releases and engineering updates into clear launch stories that developers and founders want to read and share.