Downloads · 30 days
57
32% of all-time downloads
kodelow/Kimi-K3-DSpark-FP8
Kimi-K3-DSpark-FP8 is a text generation model from kodelow. Use it when you need the model to write or continue text. It is set up for vllm. The card lists the license as other.
An 8-bit FP8 quantization of Inferact/Kimi-K3-DSpark, the MLA-native DSpark draft model for Kimi-K3, produced with qstream.<br The original model card follows in full below.<br
Downloads · 30 days
57
32% of all-time downloads
All-time downloads
180
Public
Parameters
3.6B
4.9 GB on disk
Likes
0
Public
Click a slice to open those files.
.safetensors4.9 GB · 100%
How the weights are stored.
F8_E4M32.2B · 61%
From the Hugging Face model README
An 8-bit FP8 quantization of Inferact/Kimi-K3-DSpark, the MLA-native DSpark draft model for Kimi-K3, produced with qstream.<br> The original model card follows in full below.<br> Size | 4.6 GiB (down from 6.6 GiB BF16, ~69%) |
| Variant | pos 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|---|---|---|---|---|---|---|---|
| BF16 | 98.6 | 98.0 | 97.1 | 96.4 | 95.7 | 94.6 | 93.5 |
| FP8 | 98.1 | 96.0 | 94.5 | 92.8 | 92.0 | 90.4 | 89.3 |
| NVFP4 | 91.6 | 83.8 | 78.3 | 71.3 | 67.2 | 64.0 | 59.6 |
| MXFP4 | 89.8 | 82.0 | 76.1 | 69.0 | 65.4 | 60.7 | 57.5 |
Composing the per-position sequential-rollout agreement gives an upper bound on the acceptance length that can survive numerics. This is the number that decides the format:
| Variant | boot | heavy | gauss |
|---|---|---|---|
| FP32 reference | 7.00 | 7.00 | 7.00 |
| BF16 (served baseline — the noise floor) | 6.25 | 6.04 | 6.13 |
| FP8 (this model) | 5.70 | 4.91 | 5.04 |
| NVFP4 | 3.29 | 2.34 | 2.25 |
| MXFP4 | 3.08 | 2.28 | 2.15 |
FP8 lands 0.4–1.1 below the BF16 floor depending on regime. Both 4-bit formats lose roughly half the block — about 3 tokens — and are disqualified by a wide margin, consistently across all three regimes.
A speculative draft model is not an ordinary quantization target. Acceptance length is a prefix-run-length statistic — a drafted block is accepted only up to its first mismatch — so per-token error compounds multiplicatively across all 7 positions. Error that would be invisible in a standalone LM turns into lost acceptance, and acceptance is the entire reason the draft model exists.
MXFP4 and NVFP4 builds were produced and measured alongside this one. Both land at 19–20 dB weight SNR, which is perfectly normal for 4-bit — and still not good enough here. FP8 costs 1.0 GiB more than MXFP4, on a model served beside a ~1 T-param target.
| Component | Precision | Why |
|---|---|---|
layers.*.mlp.{gate,up,down}_proj | FP8 | 1.54 B params — the bulk of the draft GEMM work |
layers.*.self_attn.o_proj, q_b_proj | FP8 | 0.39 B params, no fusion constraint |
context_proj | FP8 | 0.26 B params; combines the 5 target aux hidden states |
embed_tokens | BF16 | lookup-only, no GEMM to accelerate — and it is not a copy of the target's embedding (46% relative difference), so it carries trained signal |
markov_head.markov_w{1,2} | BF16 | rank-256 sequential head; directly shapes the sampled token |
q_a_proj, kv_a_proj_with_mqa | BF16 | vLLM fuses these into fused_qkv_a_proj; compressed-tensors raises if fused shards disagree on scheme, and this path writes the KV latent shared with the target's page layout |
kv_b_proj | BF16 | consumed by MLA weight absorption; only 42 M params |
All norms, confidence_head | BF16 | unchanged |
2.19 B of 3.56 B params quantized (61%). Everything else is bit-identical BF16.
Acceptance length cannot be measured without the ~1 T-param Kimi-K3 target in the loop, and the drafter is not a standalone LM — it consumes target hidden states from K3 layers (2, 23, 47, 71, 89). So we measure drift against a high-precision reference: how far a variant's drafted block moves from the reference's, on identical inputs. Every token where they agree is a token whose accept/reject outcome is unchanged by definition.
Three choices make this honest rather than flattering:
context_proj and its
own context-KV projections, so quantizing context_proj is measured, not excluded. Only
the 5 aux hidden states — which genuinely cannot be obtained — are held common.markov_w1
to bias the next position, as the real speculator does. Holding that bias fixed hides error
compounding through tokens and understates drift.Real inputs: GSM8K token streams (train+test) tokenized with the actual Kimi-K3 tokenizer,
the actual target lm_head, and the real drafter embedding/Markov/norm weights. The one
input that cannot be obtained — the aux hidden states — is swept over three distributions so
the result can be checked for sensitivity to it: gauss (iid normal), heavy (lognormal
per-channel scales, mimicking massive-activation structure), and boot (the drafter's own 5
layer outputs run causally over the same GSM8K tokens — real LLM hidden states with real
token correlation).
1024 blocks per regime, 7168 drafted tokens, 95% CI ±0.7–0.9 pp.
heavy regime — the pessimistic one)| Variant | Weight SNR | Greedy agree | Seq rollout | 1−TV | KL mean | KL p99 | Reverse KL | JS | Hidden rel err | Confidence r | Sched flip |
|---|---|---|---|---|---|---|---|---|---|---|---|
| BF16 | exact | 98.41% | 95.20% | 99.13% | 0.00029 | 0.00142 | 0.00029 | 0.00007 | 0.84% | 1.0000 | 7.5% |
| FP8 | 31.5 dB | 96.12% | 88.35% | 97.38% | 0.00275 | 0.01315 | 0.00273 | 0.00068 | 3.12% | 0.9997 | 12.4% |
| NVFP4 | 20.4 dB | 83.80% | 60.04% | 87.79% | 0.06100 | 0.31556 | 0.06192 | 0.01490 | 14.85% | 0.9877 | 46.4% |
| MXFP4 | 19.0 dB | 82.39% | 58.93% | 86.79% | 0.07004 | 0.28368 | 0.06989 | 0.01699 | 16.86% | 0.9898 | 23.1% |
draft_sample_method: probabilistic.confidence_head drives resource-aware draft-length
scheduling. Flip rate is measured against the per-block median confidence, which is a
deliberately knife-edge threshold (half the samples sit near it by construction), so
absolute values are pessimistic and only the comparison is meaningful. FP8 roughly matches
BF16; NVFP4 flips nearly half of all scheduling decisions.FP8 tracks the BF16 curve with a roughly constant offset. The 4-bit curves decay steeply — the compounding that the prefix-run-length structure punishes.
Harness: eval_dspark_quant.py (standalone BF16/FP32 reference forward — MLA + SwiGLU +
context-KV cross-attention + sequential Markov head — reimplemented from vLLM's DSpark
backbone).
Stated plainly, because this is an unusual evaluation:
original_max_position_embeddings 32768, factor 32) was planned and not completed. The
base card reports acceptance holding at ~95 k tokens; whether FP8 holds equally there is
unverified.K3DSparkModel in its registry.
The config.json is verified structurally — single config group, 41 ignored modules, no
target/ignore overlap, fused-module constraint respected — but has not been through a real
loader.Requires a vLLM build that registers K3DSparkModel (the public vllm/vllm-openai:kimi-k3
image). Serve Kimi-K3 per the official recipe
and point the speculative config at this repo:
--speculative-config '{"method": "dspark", "model": "kodelow/Kimi-K3-DSpark-FP8",
"num_speculative_tokens": 7, "attention_backend": "FLASHINFER_MLA",
"draft_sample_method": "probabilistic", "rejection_sample_method": "block"}'
FP8 weight-only needs no calibration and no activation scales.
qstream-quantize \
--model_dir <Inferact/Kimi-K3-DSpark> \
--output_dir ./Kimi-K3-DSpark-FP8 \
--quant_format fp8 \
--include_layers "mlp.gate_proj" "mlp.up_proj" "mlp.down_proj" \
"self_attn.o_proj" "self_attn.q_b_proj" "context_proj" \
--device cuda --workers 1
Built with qstream @fcfe8a2. SmoothQuant is deliberately
off: this FP8 path is weight-only per-output-channel, which is already invariant to
per-column rescaling, so smoothing can only redistribute error, never remove it.
Inherits the Kimi-K3 license from the base model. This is a derivative (quantized) work of Inferact/Kimi-K3-DSpark.
Inferact/Kimi-K3-DSpark is an MLA-native DSpark draft model that accelerates Kimi-K3 on vLLM, served through vLLM's native dspark speculative method.
The draft trains on target hidden states extracted from vLLM itself — the same engine that serves it, so the numerics it learns from are the numerics it meets at inference. TorchSpec provides the loop, streaming those hidden states from live target inference into concurrent FSDP draft training.
DSpark = a block-diffusion backbone of 5 dense layers with non-causal attention, drafting 7 tokens in a single parallel pass, a low-rank sequential Markov head supplying the intra-block dependency, and a confidence head for resource-aware scheduling. Mirroring Kimi-K3's own MLA attention means draft and target share one KV layout (a compact 576-element latent per token), so the draft's pages unify with the target's cache — KV offloading and P/D disaggregation work with no separate page format.
Under low-entropy real reasoning workload — Kimi-K3 + DSpark on vLLM can achieve 464 tok/s using the public vllm/vllm-openai:kimi-k3 image on 4 × GB300 at bs=1 & tensor-parallel-size=16.
Speculators do best on predictable, low-entropy work like the reasoning workload behind the 464 tok/s above, and worst on open-ended, high-entropy generation. So we measured 14 benchmarks spanning math, code synthesis, real-world software engineering, multi-turn chat, RAG and QA, multilingual text, creative writing and long-context generation — all with the Kimi-K3 chat template enabled and production sampling parameters, with temperature=0 reported alongside for reproducibility. Acceptance stays strong at long context too, verified on AA-LCR's ~95k-token multi-document prompts. That is the most comprehensive view we can give of how the speculator performs on real-world workloads.
Acceptance length, with 7 speculative tokens:
| benchmark | temperature=0 | temperature=1.0, top_p=0.95 | prompts |
|---|---|---|---|
| GSM8K | 5.64 | 5.44 | 1319 |
| HumanEval | 5.34 | 5.07 | 164 |
| MBPP | 4.44 | 4.31 | 256 |
| SPEED-Bench · coding | 4.38 | 4.22 | 80 |
| SPEED-Bench · multilingual | 4.21 | 4.10 | 80 |
| SPEED-Bench · RAG | 4.11 | 3.97 | 80 |
| MATH-500 | 3.82 | 3.77 | 500 |
| SPEED-Bench · low-entropy, 10k input | 3.72 | 3.66 | 512 |
| SWE-bench Pro | 3.35 | 3.11 | 128 |
| AA-LCR · ~95k input | 3.19 | 3.23 | 100 |
| MT-Bench | 3.14 | 3.06 | 80 |
| SPEED-Bench · QA | 3.07 | 2.98 | 80 |
| SPEED-Bench · writing | 2.79 | 2.69 | 80 |
| AIME 2026 | 2.72 | 2.64 | 30 |
| mean | 3.85 | 3.73 |
Benchmarks: GSM8K, MATH-500, AIME 2026, HumanEval, MBPP, SWE-bench Pro, MT-Bench, AA-LCR — 100 multi-document prompts of 71k–115k tokens — and six splits of NVIDIA SPEED-Bench: its throughput_16k low-entropy split at 10k-token input, plus five qualitative categories.
Data — all responses regenerated on-policy by Kimi-K3 itself, so the draft learns the target's own reasoning traces and chat formatting. Prompts come from public datasets:
lightseekorg/kimi-mtp-dataset — general instruction promptsnvidia/OpenCodeInstruct — single-turn codingCohereLabs/aya_dataset, spanning chat, code, multilingual, RAG/QA, math, structured output and safety. Evaluation-set prompts are excluded.Method: DSpark with block_size=7, trained on a combined CE + L1 distribution-distillation objective against the target's post-final-norm hidden state, bf16. The draft consumes Kimi-K3 auxiliary hidden states from target layers (2, 23, 47, 71, 89) of 93. Roughly two epochs in total, on GB300 nodes.
Draft architecture, block size, sequence length, and loss weights are YAML-configurable — see the TorchSpec repo.
For serving Kimi-K3 itself — hardware, parallelism and engine flags — follow the official vLLM recipe: recipes.vllm.ai/moonshotai/Kimi-K3.
Add to your Kimi-K3 vllm serve command:
--speculative-config '{"method": "dspark", "model": "Inferact/Kimi-K3-DSpark", "num_speculative_tokens": 7, "attention_backend": "FLASHINFER_MLA", "draft_sample_method": "probabilistic", "rejection_sample_method": "block"}'
vLLM offers two knobs on top of the defaults, both used in the temperature=1.0 column above:
draft_sample_method — probabilistic samples the draft from its own distribution instead of taking its argmax. Pair it with a sampling client; use greedy when serving at temperature=0 so the draft matches the client.rejection_sample_method — block verifies the drafted block as a unit rather than token by token. It is a no-op under greedy decoding (at temperature=0 verification reduces to a deterministic argmax match), so it only applies to the sampling configuration.The temperature=0 column was produced with {"draft_sample_method": "greedy"} and no rejection_sample_method.