olka-fi/Inkling-Small-MXFP4

Inkling-Small — MXFP4 (mixed precision)

A 4-bit MXFP4 quantization of Inkling-Small, produced with llm-compressor model_free_ptq. The routed MoE experts (≈95% of the weights) are quantized to MXFP4; everything quality-sensitive stays BF16.

The original model card follows in full below.

Size	163 GB (152 GiB) — down from 532 GB BF16, ~31%
Format	compressed-tensors mxfp4-pack-quantized (E2M1 4-bit + E8M0 group-32 scales)
Base	Inkling-Small — 276B total / 12B active multimodal MoE, 42 layers, 256 experts top-6 + 2 shared, hybrid local(SWA-512)/global attention, short-conv, 8-layer MTP

What is quantized to what

Component	Precision	Why
Routed experts (model.llm.layers.{3..41}.mlp.experts.w13_weight / w2_weight)	MXFP4 (4-bit)	251B of 276B params — the only place worth the size win
First MoE layer (layer 2) experts	BF16	left unquantized, matching both the official Inkling-Small-NVFP4 and RedHatAI/Inkling-FP8-dynamic
Shared experts (2/layer, always active), attention + short-conv, router gates	BF16	run on every token / sensitive — bit-identical to the source
Dense MLP layers 0–1, embeddings, unembed, norms	BF16	unchanged
Vision + audio towers	BF16	multimodal capability equals the base model
MTP (8 next-token-prediction layers)	BF16	speculative-decoding draft path — kept intact and usable

78 tensors quantized (39 layers × w13 + w2). Everything else is verified bit-identical: all 970 remaining tensors (29.4 GB) compared byte-for-byte against the source and unchanged — 504 attention/short-conv, 160 MTP, 120 router gates, 84 norms/sconv, 80 shared-expert, 10 vision/audio, 6 dense-MLP, 4 embedding/norm, and the 2 layer-2 expert tensors.

Quality

Metric	Result
GSM8K (full 1319-problem test set, chain-of-thought)	95.3% (1257/1319)
Routed-expert reconstruction SQNR vs BF16 source	18.99 dB (sd 0.04)
Cosine similarity, quantized vs original expert weights	0.9938
Non-expert tensors bit-identical to source	970 / 970

SQNR ≈ 19 dB is the unavoidable 4-bit rounding floor and nothing more — a damaged checkpoint would sit far below this. Measured over 7 randomly sampled experts (seed 0) spanning layers 8–40 and both projections: min 18.96, max 19.07, sd 0.040 dB — the error is uniform, with no outlier expert. w13 runs ~0.1 dB cleaner than w2 because it has 128 scale groups per row against w2's 64. Cosine is computed in float64; a float32 reduction over 16.7M elements drifts enough to inflate it. Reconstruction norm is 0.9939× the source — the slight shrinkage the MSE clipping search trades for lower total error.

The quantization error in this checkpoint is confined entirely to those 78 expert tensors, since every other tensor is byte-for-byte unchanged.

Scale selection: weight scales use an MSE-optimal clipping search (memoryless_mse) rather than plain group amax, which measured 0.29–0.42% lower reconstruction error on every expert tested, for ~3.5 min of extra quantization time.

Provenance

Built with llm-compressor model_free_ptq (MXFP4A16, group size 32) streaming shard-to-shard — the 532 GB source is never materialized. Requires two patches on top of llm-compressor main:

1. PR #2932 — Inkling's fused 3D expert tensors (w13_weight / w2_weight) are not matched by the stock model-free path.
2. A pack-quantized fix on top of it: #2932 reads state["weight"], but MXFP4 emits weight_packed, so the suffix must carry into the re-stacked fused tensor.

Serving with vLLM

Verified on 2× RTX PRO 6000 Blackwell (SM120, 96 GB) at -tp 2: 152 GiB of weights, ~450–530 tok/s aggregate generation at 8 concurrent requests, with native MTP speculative decoding enabled.

SM120 — use the pre-built image

olkafi/inkling-mxfp4:sm120 keeps the upstream ENTRYPOINT ["vllm","serve"], so it is a drop-in replacement for vllm/vllm-openai and takes the usual arguments:

docker run --rm --gpus all --ipc=host -p 8000:8000 \
  -v /path/to/Inkling-Small-MXFP4:/model:ro \
  olkafi/inkling-mxfp4:sm120 \
    /model -tp 2 --gpu-memory-utilization 0.93 \
    --max-model-len 4096 --max-num-seqs 8 \
    --tokenizer-mode inkling \
    --speculative-config '{"method":"mtp","num_speculative_tokens":4}' \
    --compilation-config '{"mode":0,"cudagraph_mode":"FULL_DECODE_ONLY"}'

A wrapper with these defaults is installed as inkling-serve if you want it (--entrypoint inkling-serve, tunable via TP / MTP_K / MAX_MODEL_LEN / …), but it is opt-in — the image does not second-guess your flags. The Dockerfile and full patch set are in vllm/ to audit or rebuild.

SM90 / SM100 — stock vLLM

No patches needed:

vllm serve olka-fi/Inkling-Small-MXFP4 \
  -tp 2 --gpu-memory-utilization 0.93 \
  --max-model-len 4096 --max-num-seqs 8 \
  --tokenizer-mode inkling \
  --speculative-config '{"method":"mtp","num_speculative_tokens":4}' \
  --compilation-config '{"mode":0,"cudagraph_mode":"FULL_DECODE_ONLY"}'

num_speculative_tokens > 1 requires vllm#48768 (Inkling multi-depth MTP — open at the time of writing). Without it, stock vLLM raises Inkling MTP currently supports exactly one speculative token and only num_speculative_tokens: 1 works. The PR needs two hand-fixes if your vLLM is newer than its base d4b456291: multi_stream_utils.py hunk 2, and _build_draft_attn_metadata, which loses its seq_lens_cpu_upper_bound / step parameters in the rename (surfaces only at runtime as a NameError).

On SM120 specifically, stock vLLM cannot serve Inkling at all: its CuTe FA4 attention has no paged-KV support (Paged KV not supported on SM 12.0), and vLLM v1 has no unpaged mode. This is a base-model kernel gap unrelated to quantization — the BF16 model fails identically, and NVFP4 would too.

A ready-to-run image is published as olkafi/inkling-mxfp4:sm120 — see the serving recipe above. Its Dockerfile and the complete patch set ship in vllm/ in this repo, so you can audit or rebuild it:

cd vllm && docker build -t inkling-mxfp4:sm120 .

It builds on the official vllm/vllm-openai nightly (pinned by commit) and applies the contiguous-KV gather and memory-safety clamps from blockmos/inkling-sparks-gb10, vllm#48768 for multi-depth MTP, and EAGLE3 aux hidden states — verifying each layer at build time. See vllm/README.md. Because the workaround re-gathers KV rather than paging it, long-context decode degrades; prefill is unaffected. SM90 / SM100 need none of this.

Do not drop "mode": 0. Without it vLLM resolves to full torch.compile, which silently corrupts this model's output rather than erroring.

Native MTP acceptance (measured on this checkpoint)

Inkling ships an 8-layer MTP head, kept BF16 here — so speculative decoding works out of the box. Measured at num_speculative_tokens=5 over the full GSM8K run (135,507 draft steps, 677,535 drafted tokens), conditional acceptance is flat at ~79–83% through depth 5 — it does not decay with depth:

position	0	1	2	3	4
unconditional	78.9%	62.2%	49.7%	40.1%	33.1%
conditional	78.9%	78.9%	79.8%	80.7%	82.7%

52.8% of drafted tokens accepted overall → 3.64 tokens per verify step. Because acceptance does not decay, deeper drafting keeps paying: the checkpoint carries 8 MTP layers, so num_speculative_tokens up to 8 is worth testing for single-stream latency (needs vllm#48768 — see above). At high concurrency the extra verify width starts to cost more than it returns — k=4 is a reasonable default there, and k=1 works on stock vLLM.

License

Inherits Apache-2.0 from the base model. This is a derivative (quantized) work of thinkingmachines/Inkling-Small.

---

Original model card

Inkling

BF16 | NVFP4 | Playground | Tinker Cookbook | Acceptable Use

1. General Information

Inkling-Small is a general-purpose multimodal model that accepts text, image and audio inputs and generates text outputs. It is intended for use in English and other languages, and across multiple coding languages. The model is designed to be used by developers building AI-powered applications, including agentic and tool-use systems, coding assistants, chatbots, and retrieval-augmented generation systems, and is suitable for general-purpose conversational use, instruction-following, and other natural language and multimodal tasks. It is released with open weights to support research, fine-tuning and integration into third-party products by downstream developers.

Languages: English, with general multilingual capabilities across other languages.

2. Getting Started

Try Inkling-Small on the Tinker Playground or access via API using the Tinker Cookbook.

Inkling-Small supports local deployment using the following open-source libraries:

• SGLang (recipe)
• vLLM (recipe)
• TokenSpeed (recipe)
• Unsloth (recipe)
• Huggingface (recipe)

API access is also available through third party inference providers.

3. Model Properties

Model type

Multimodal autoregressive transformer

Architecture type

A 42-layer decoder-only transformer with a sparse Mixture-of-Experts (MoE) feed-forward backbone: each token is routed to 6 of 256 experts, plus 2 shared experts active on every token. Attention is a hybrid of local and global layers. The model is natively multimodal — images are encoded via a hierarchical patch encoder, and audio via discrete token encoding — with all modalities projected into a shared hidden space and processed jointly by the decoder.

Parameters

276B total, 12B active

Numerics support

BF16 and NVFP4

Input modalities

Inkling-Small accepts text, image, and audio inputs:

• Text: UTF-8 encoded text
• Image: Any pixel-based image input. For optimal performance, each image dimension should be between 40px to 4096px.
• Audio: WAV format, sampled at 16kHz. For optimal performance, audio length should ideally be under 2 mins.

Output modalities

Inkling-Small generates output as UTF-8 encoded text.

4. Training

Training data includes a broad variety of content types, including text, images, audio, video.

Training data for the model was drawn from publicly available sources, acquired from third-parties, or synthetically generated or augmented. Publicly available data includes content from the public internet and publicly accessible repositories.

The training data curation process includes cleaning, processing, and modifying datasets. These processing steps, which vary by data type, may include deduplication and filtering to remove junk or other low-quality data, or to advance safety or other objectives.

5. Evaluations

	Open weights							Closed weights
	Inkling-Small	Qwen3.5 397B-A17B	MiMo V2.5	Minimax M2.7	DeepSeek V4 Flash	Nemotron 3 Ultra	Inkling	Claude 4.5 Haiku	Gemini 3.5 Flash-Lite	GPT 5.6 Luna
Model Info
AA Index (v4.1)	40.0%	34.0%	37.0%	38.0%	40.0%	38.0%	41.0%	30.0%	36.0%	49.0%
Params (B) (activated / total)	12 / 276	17 / 397	15 / 310	10 / 230	13 / 284	55 / 550	41 / 975	–	–	–
Agentic (coding)
SWEBench Verified	80.2%	76.4%	71.0%	79.9%	79.0%	70.7%	77.6%	73.3%	75.0%	93.0%
SWEBench Pro (public)	55.9%	50.9%	56.1%	56.2%	52.6%	46.4%	54.3%	39.5%	54.2%	62.7%
Terminal Bench 2.1 (best harness)	64.7%	51.3%	63.7%	55.4%	61.8%	56.4%	63.8%	44.2%	54.0%	82.5%
SciCode	48.7%	42.0%	43.1%	47.0%	44.9%	39.9%	46.1%	43.3%	40.9%	50.0%
Agentic (general)
GDPval-AA v2	1269	962	1145	1159	1189	1164	1238	911	1139	1530
MCP Atlas (public / all)	79.6/79.2%	74.2%/–	–	49.4%/–	69.0%/–	47.4/44.7%	78.8/76.0%	41.2/40.2%	79.8/76.8%	77.0/75.0%
Tau 3 Banking	15.5%	13.4%	6.6%	8.9%	22.9%	13.8%	23.7%	9.1%	16.5%	24.3%
BrowseComp (with context management)	77.4%	78.6%	–	76.3%	73.2%	63.0%	77.1%	–	–	84.0%
Toolathlon Verified	54.4%	40.7%	49.1%	47.5%	50.9%	34.3%	45.5%	26.9%	57.1%	67.9%
AA-Briefcase	917	–	–	–	833	870	839	612	–	–
Reasoning (general)
GPQA Diamond	89.5%	89.3%	84.9%	87.4%	89.4%	86.7%	87.2%	67.2%	83.8%	89.5%
HLE (text only)	31.6%	27.3%	25.2%	28.1%	32.1%	26.6%	29.7%	9.7%	17.5%	35.6%
HLE (with tools)	47.8%	48.3%	40.0%	40.3%	45.1%	37.4%	46.0%	17.8%	42.5%	48.9%
AIME 2026	95.5%	93.3%	93.6%	87.7%	95.8%	94.2%	97.1%	85.1%	82.2%	97.6%
HMMT Feb 2026	90.2%	87.9%	82.6%	71.2%	93.9%	78.8%	86.3%	66.7%	63.6%	98.5%
CritPt	8.3%	1.7%	3.7%	0.6%	7.1%	3.1%	5.4%	0.0%	0.0%	20.6%
Reasoning (abstract)
ARC-AGI-1	84.0%	–	–	–	–	–	79.5%	47.7%	–	87.7%
ARC-AGI-2	40.1%	–	–	–	–	–	36.5%	4.0%	–	47.6%
Factuality
SimpleQA Verified	20.6%	26.0%	16.1%	13.5%	34.1%	32.4%	43.9%	5.9%	44.1%	41.7%
AA Omniscience (index)	-9.0	-29.8	-9.3	0.7	-22.9	-1.0	2.1	-4.2	6.9	-11.6
Chat
IFBench	82.2%	78.8%	67.1%	75.7%	79.2%	81.4%	79.8%	54.3%	78.6%	67.3%
Global-MMLU-Lite	86.7%	90.0%	83.5%	83.9%	88.4%	85.6%	88.7%	83.4%	89.4%	88.7%
Safety
StrongREJECT	98.4%	99.4%	99.3%	99.4%	97.4%	98.7%	98.6%	98.6%	97.6%	98.7%
FORTRESS (adversarial)	71.6%	77.3%	64.8%	86.3%	32.0%	77.6%	78.0%	91.3%	70.7%	83.8%
FORTRESS (benign)	96.9%	95.4%	94.6%	90.1%	99.2%	90.6%	95.9%	94.1%	95.5%	97.8%
Vision
MMMU Pro (Standard 10)	74.0%	77.3%	75.4%	–	–	–	73.5%	58.6%	79.0%	78.6%
Charxiv RQ (original / with python)	77.4/81.3%	80.8%/–	81.0%/–	–	–	–	78.1/82.0%	57.4%/–	70.0%/–	81.4%/–
Audio
Audio MC	54.9%	–	30.4%	–	–	–	56.6%	–	33.6%	–
MMAU	77.0%	–	73.6%	–	–	–	77.2%	–	75.2%	–
VoiceBench	90.1%	–	86.4%	–	–	–	91.4%	–	85.9%	–

• Inkling-Small against open-and closed-weights models across the full eval suite. Activated and total parameters are given for scale; a dash means the score was not available at the time of writing.
• SWEBench Verified: Inkling and Inkling-Small’s numbers are reported using a bash-only harness. We use self-reported numbers for external models.
• Terminal Bench 2.1: Inkling and Inkling-Small’s numbers are reported using an internal coding harness. A small number of solutions were found to be contaminated from web search and were assigned a score of 0. We use self-reported numbers for external models where available. Otherwise, we report performance using our internal harness.
• Audio MC: Other models were evaluated internally since they are not on the official leaderboard.
• VoiceBench: VoiceBench uses rule-based, hard-coded string matching for grading, making the evaluation sensitive to output-formatting differences. We therefore added a system message instructing models to follow the expected answer format.
• HLE with tools: We benchmarked Minimax M2.7, Claude 4.5 Haiku, Gemini 3.5 Flash-Lite, and GPT 5.6 Luna using our internal harness.

6. Safety

We conducted safety evaluations ahead of release, spanning both everyday human-AI interaction and dangerous-capability testing. Because Inkling-Small is multimodal, we paid attention to whether safety behavior held consistently across text, audio, and image inputs. We applied mitigations to reduce risks before release.

For everyday interaction, we evaluated sycophancy, harmful manipulation, and psychological-harm patterns like parasocial dependency and validation of delusional reasoning, including through multi-turn, open-ended external red-teaming designed to surface issues that only emerge over longer conversations. We also assessed whether the model refuses genuinely harmful requests without over-refusing benign ones. For CBRN and cyber, we assessed knowledge and procedural uplift through internal evaluations, external testing, and refusal-suppressed variants intended to estimate latent capability with safeguards removed. For loss of control, we evaluated agentic capability, strategic deception, and sabotage potential, benchmarked against public frontier models, and found the model materially below frontier capabilities.

Across all areas, we concluded that Inkling-Small did not present risk of material uplift beyond what's already available in the open-weight ecosystem.

The residual risks identified in our evaluations — specifically, Inkling-Small’s occasional tendency to comply with role-play and indirectly framed prompts concerning harmful topics — are consistent with what you would see from any open-weight model, and are best addressed with defense-in-depth rather than relying on the model's refusals alone. Common downstream moderation tools, such as Llama Guard, are compatible with Inkling-Small and can be layered around the model to catch jailbreak attempts, filter unsafe outputs, and enforce use-case-specific policies. We would encourage treating this kind of input/output classification as a part of your deployment stack, especially for consumer-facing or high-traffic applications where adversarial prompting is more likely.

7. Bias, risks and limitations

Inkling-Small may exhibit general limitations common to foundation models, including hallucination (generating plausible but factually incorrect or unsupported content), occasional failures to follow instructions precisely, and degraded performance in long multi-turn conversations. As with other large-scale models trained on web-derived and synthetic data, Inkling-Small may reflect biases present in its training data, including demographic, cultural, or linguistic biases, and may perform unevenly across languages, dialects, or subject domains that were less represented during training.

Inkling-Small's knowledge is limited to information available as of its training cutoff, and it may not reflect events, developments, or changes that occurred afterward.

We recommend that downstream developers and deployers apply appropriate human oversight and review for outputs used in high-stakes or safety-critical contexts, rather than relying on Inkling-Small's outputs without verification.

• Conduct their own evaluation of Inkling-Small's performance, safety, and fairness for their specific use case, language, and population prior to deployment, particularly for applications involving vulnerable groups.
• Implement additional safeguards – such as content filtering, rate limiting, and monitoring – at the application layer, especially for open deployment contexts where Inkling-Small's built-in mitigations may not be sufficient on their own.
• Avoid deploying Inkling-Small in domains such as medical, legal, or safety-critical decision-making without additional fine-tuning, domain-specific validation, and human oversight

8. Legal

Training Data Documentation