Instructions to use iamrahulreddy/Quintus with libraries, inference providers, notebooks, and local apps. Follow these links to get started.
- Libraries
- Transformers
How to use iamrahulreddy/Quintus with Transformers:
# Use a pipeline as a high-level helper from transformers import pipeline pipe = pipeline("text-generation", model="iamrahulreddy/Quintus") messages = [ {"role": "user", "content": "Who are you?"}, ] pipe(messages)# Load model directly from transformers import AutoTokenizer, AutoModelForCausalLM tokenizer = AutoTokenizer.from_pretrained("iamrahulreddy/Quintus") model = AutoModelForCausalLM.from_pretrained("iamrahulreddy/Quintus") messages = [ {"role": "user", "content": "Who are you?"}, ] inputs = tokenizer.apply_chat_template( messages, add_generation_prompt=True, tokenize=True, return_dict=True, return_tensors="pt", ).to(model.device) outputs = model.generate(**inputs, max_new_tokens=40) print(tokenizer.decode(outputs[0][inputs["input_ids"].shape[-1]:])) - Notebooks
- Google Colab
- Kaggle
- Local Apps Settings
- vLLM
How to use iamrahulreddy/Quintus with vLLM:
Install from pip and serve model
# Install vLLM from pip: pip install vllm # Start the vLLM server: vllm serve "iamrahulreddy/Quintus" # Call the server using curl (OpenAI-compatible API): curl -X POST "http://localhost:8000/v1/chat/completions" \ -H "Content-Type: application/json" \ --data '{ "model": "iamrahulreddy/Quintus", "messages": [ { "role": "user", "content": "What is the capital of France?" } ] }'Use Docker
docker model run hf.co/iamrahulreddy/Quintus
- SGLang
How to use iamrahulreddy/Quintus with SGLang:
Install from pip and serve model
# Install SGLang from pip: pip install sglang # Start the SGLang server: python3 -m sglang.launch_server \ --model-path "iamrahulreddy/Quintus" \ --host 0.0.0.0 \ --port 30000 # Call the server using curl (OpenAI-compatible API): curl -X POST "http://localhost:30000/v1/chat/completions" \ -H "Content-Type: application/json" \ --data '{ "model": "iamrahulreddy/Quintus", "messages": [ { "role": "user", "content": "What is the capital of France?" } ] }'Use Docker images
docker run --gpus all \ --shm-size 32g \ -p 30000:30000 \ -v ~/.cache/huggingface:/root/.cache/huggingface \ --env "HF_TOKEN=<secret>" \ --ipc=host \ lmsysorg/sglang:latest \ python3 -m sglang.launch_server \ --model-path "iamrahulreddy/Quintus" \ --host 0.0.0.0 \ --port 30000 # Call the server using curl (OpenAI-compatible API): curl -X POST "http://localhost:30000/v1/chat/completions" \ -H "Content-Type: application/json" \ --data '{ "model": "iamrahulreddy/Quintus", "messages": [ { "role": "user", "content": "What is the capital of France?" } ] }' - Docker Model Runner
How to use iamrahulreddy/Quintus with Docker Model Runner:
docker model run hf.co/iamrahulreddy/Quintus
Experiment Timeline
This timeline explains why the final Quintus design looks the way it does. It focuses on the technical evolution from sparse offline distillation to the final online full-vocabulary pipeline.
1. Offline Top-K KD Prototype
The earliest design precomputed teacher logits to disk and trained the student from cached top-k supports.
Why it was attractive:
- Avoided loading teacher and student together.
- Reduced KD memory from full vocabulary to top-k support.
- Made cloud interruptions easier to survive because teacher logits were already saved.
Main lessons:
- Serialization contracts matter as much as loss math.
- Top-k token IDs need safe dtypes.
- Teacher-logit shards must preserve original row order.
- Missing or stale shards should fail loudly.
2. Static Audit And Fail-Fast Hardening
The project then moved through a static-audit phase focused on silent failure modes.
Major hardening themes:
- Dataset zero-retention checks.
- Missing-shard hard failures.
- Stale artifact cleanup.
- DeepSpeed accumulation correctness.
- Rank-safe writes.
- Explicit model revision and remote-code policy.
- Stronger provenance metadata.
This phase turned the code from a script bundle into a more reliable training pipeline.
3. Assistant-Only Supervision
The tokenization path originally risked supervising the whole conversation. That can over-train prompts, headers, and formatting tokens.
The corrected path derives loss_mask and trains only on assistant response tokens.
This changed the training contract:
- Prompt tokens provide context.
- Assistant tokens receive CE and KD loss.
- Rows without assistant targets are rejected.
- Checkpoints and datasets must agree on the mask schema.
4. Top-K Plus Residual Bucket
A later offline-KD pass improved the sparse support by adding an "other" bucket for teacher probability mass outside top-k.
This fixed a mathematical weakness: the student should be normalized against the full vocabulary before comparison, not only inside top-k. The residual bucket made offline KD less wrong, but it still compressed most of the teacher distribution into one scalar.
That design was useful, but not enough for flagship results.
5. Dataset And Objective Mismatch
Smoke runs showed a pattern that became important later: held-out KD validation loss can improve while benchmark quality worsens.
Key diagnosis:
- Matching teacher token distributions on a training corpus is not identical to improving GSM8K, ARC, coding, or open-ended assistant quality.
- Dataset order and first-N streaming can bias sample selection.
- Long reasoning traces can overweight style and process tokens relative to final answers.
- Small students can forget useful baseline behavior when full-parameter training is too aggressive.
This motivated stricter downstream evaluation gates.
6. Base Student Pivot
Several runs tested whether distilling into an already-instruct-tuned student caused destructive interference. The base-student hypothesis was sound: a raw base model has more plasticity and fewer alignment paths to overwrite.
The result was only a marginal improvement under offline top-k KD. That was the decisive clue.
Conclusion:
The student choice was not the main bottleneck. Offline top-k sparsity was the main bottleneck.
7. Offline Top-K Ceiling
With $k = 8$, the student saw only a tiny fraction of the teacher vocabulary distribution per target token:
Different $\alpha$ values, epochs, and student initializations did not remove this limit.
Offline top-k KD could perturb the student and sometimes improve narrow metrics, but it could not reliably transfer the teacher's broader reasoning distribution.
The project stopped treating offline top-k KD as the path to a flagship model.
8. Online Full-Vocabulary KD
Online KD became the final architecture.
Instead of reading cached teacher shards, the training loop loads a frozen teacher and runs live teacher forward passes beside the student. The KD loss uses the teacher's full-vocabulary distribution.
Benefits:
- No top-k sparsity ceiling.
- No shard-order mismatch risk.
- No stale teacher-logit cache.
- Stronger transfer signal for reasoning.
Cost:
- Higher VRAM footprint.
- Teacher and student must fit together.
- KL computation needs chunking.
- Throughput depends heavily on packing and kernels.
9. Sequence Packing And B200 Tuning
Sequence packing converted padding waste into useful tokens.
The packing implementation:
- Packs only training data.
- Keeps validation easier to interpret.
- Uses fixed 4096-token bins.
- Inserts masked EOS separators.
- Stores packing metadata in checkpoints.
- Rejects packed/unpacked resume mismatches.
Development probes showed the expected utilization improvement and made online KD fast enough for serious single-GPU runs.
10. English-Only Final Data
The release run focuses on English samples.
Reasons:
- Reduce language drift in open-ended outputs.
- Keep the model's assistant behavior aligned with the intended release language.
- Make qualitative evaluation cleaner.
- Avoid CJK continuation artifacts after missed EOS.
The tradeoff is real: removing multilingual data can reduce access to some reasoning traces. For a public English assistant, language stability is worth that tradeoff.
11. Targeted SFT After KD
Online KD transferred capability, but raw KD is not a full assistant-alignment process.
Targeted SFT was added after KD to improve:
- identity grounding,
- chat format stability,
- practical assistant style,
- repetition control,
- response presentation.
This created the final two-stage public model:
Qwen3-1.7B-Base
-> online full-vocab KD from Qwen3-8B
-> targeted SFT
-> Quintus-1.7B
12. Release Verification
The final release surface combines:
- benchmark scoreboard,
- architecture documentation,
- evaluation methodology notes,
- pipeline hardening notes,
- weight audit,
- model-card draft.
The public docs focus on reusable methods, release results, and reproducible checks.
