Qwen3.5-9B-English-trimmed

Qwen3.5-9B-English-Trimmed

A vocabulary-trimmed derivative of Qwen/Qwen3.5-9B, built for deployments that only need English + code, not all 201 languages the base tokenizer supports.

This model changes only the token embedding (embed_tokens) and output (lm_head) matrices — unlike the 0.8B version of this project, Qwen3.5-9B does not tie these two matrices (tie_word_embeddings: false), so both were sliced independently. Every other weight — all 32 transformer layers, the Gated DeltaNet / attention blocks — is copied byte-for-byte unmodified from the base model. No fine-tuning was performed.

Modified from the original. This is a derivative of Qwen/Qwen3.5-9B (Apache 2.0). See Attribution below.

What changed

The vocabulary keep-set is identical to sahilchachra/Qwen3.5-0.8B-English-trimmed — Qwen3.5-9B uses the exact same 248,320-token tokenizer as the 0.8B model, so the token-frequency mining, coverage analysis, and safety-net keyword pinning done for that release apply here unchanged. See that model's card and the accompanying methodology notes for the full mining process.

Why this is a smaller reduction than the 0.8B version

At 0.8B scale, the tied embedding/lm_head matrix was ~34% of total parameters. At 9B scale, the two (now separate, untied) matrices are a much smaller slice of a much bigger backbone — about 21% combined before trimming, 5% after. The absolute parameter savings from trimming the vocabulary are identical in relative terms (same 5.10x vocab reduction, same token math), but the backbone dominates total size far more at this scale, so the overall model shrinks by "only" 16.9% instead of 27%. The same logic applies to decode-time compute: the lm_head projection is a smaller fraction of total per-token cost on a 32-layer, 4096-hidden model than on a 24-layer, 1024-hidden one, so the relative decode speedup from trimming is expected to be smaller here too (see Limitations — this wasn't directly measured for this size).

Methodology

Identical pipeline to the 0.8B release:

1. Token frequency mined from ~10.7M characters of WikiText-103, Dolly-15k, public-domain novels, and idiomatic code across 8 languages (Python, JavaScript, Java, C++, Go, Rust, Bash, SQL), plus emoji.
2. Always-keep set: all 33 special/chat/multimodal tokens, all 256 primitive byte-level tokens, and a curated safety-net list of ~40 cross-language keywords/operators.
3. Coverage-based selection at 99.9%, rounded to a multiple of 64 → 48,704 tokens.
4. Both embed_tokens.weight and lm_head.weight sliced to the kept token ids (independently, since untied). Tokenizer's BPE vocab and merges rebuilt to match.

Engineering note: this model's ~19.3GB checkpoint was too large to safely load in full on the machine used to build it (24GB unified memory). Instead of loading the whole model, only the single safetensors shard containing embed_tokens/lm_head was opened (via safetensors.safe_open, memory-mapped) and rewritten with the sliced tensors; the other 3 shards (32 transformer layers, untouched) were copied through as-is. This avoided ever materializing the full 9.65B-parameter model in memory.

Limitations / what wasn't tested

Because of the memory constraint above, the following checks that were done for the 0.8B release were not repeated here:

• No live generation test was run on this exact checkpoint (loading a 16GB model on a 24GB-unified-memory machine with other processes already using ~22GB was assessed as too risky to attempt). Tensor shapes, dtypes, and the tokenizer round-trip (including multi-byte UTF-8/emoji) were verified programmatically instead.
• No before/after perplexity or decode-speed benchmark was run at this model size. The token-coverage statistics (99%+ on English/code held-out data, ~75-78% on non-English) are inherited from the 0.8B gap analysis and are valid here since they depend only on the tokenizer, not model size — but the quality impact of that coverage (bits-per-byte, generation coherence) has only been directly measured on the 0.8B model, not this one.

If you use this model, it's worth running your own quick generation/perplexity check on your target domain before relying on it in production — the trim mechanism is proven at 0.8B scale, but end-to-end behavior at 9B scale hasn't been independently verified.

Intended use

• Good for: English text generation/chat and code generation across Python, JavaScript, Java, C++, Go, Rust, Bash, and SQL (same target domain as the 0.8B release).
• Not good for: non-English languages — the base model supports 201 languages, this one doesn't (byte-level fallback prevents hard failures, but quality will be substantially worse, per the 0.8B benchmarks).
• Multimodal: the vision encoder is untouched; image/video special tokens are preserved for compatibility but multimodal inference was not tested.

Usage

from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

model_id = "sahilchachra/Qwen3.5-9B-English-trimmed"
tok = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(model_id, dtype=torch.bfloat16)

messages = [{"role": "user", "content": "Explain what a hash map is, with a short Python example."}]
inputs = tok.apply_chat_template(messages, add_generation_prompt=True, return_tensors="pt")
out = model.generate(inputs, max_new_tokens=200)
print(tok.decode(out[0], skip_special_tokens=True))

Attribution & License

This model is a derivative of Qwen/Qwen3.5-9B, licensed under Apache License 2.0. In accordance with the license:

• This is a modified version of the original work — only the embed_tokens/lm_head matrices and tokenizer vocabulary were changed; all other weights are unmodified copies of the original.
• Distributed under the same Apache License 2.0.
• All original copyright and attribution notices are retained.

See the Apache 2.0 license text for full terms.

See also: sahilchachra/Qwen3.5-0.8B-English-trimmed — the sibling release this vocabulary was originally mined and validated on.