Modelpublic

hypaai/Hypa-SmolLM-135M-Instruct-16bit

sourceHugging Faceapache-2.0updated 3d agoView on Hugging Face

0likes370downloads

Model Card

Hypa SmolLM 135M — Keyboard (BF16)

A smart-keyboard model for 27 languages, weighted toward African languages no mainstream keyboard supports.

These are the merged BF16 reference weights — full precision, LoRA already applied, loadable with plain Transformers. Use this build to serve the model on a GPU, to evaluate it without quantisation artefacts, or as the source for your own conversions and quants. If you're deploying to a phone, take the GGUF instead.

The model does the four things a keyboard has to do — predict the next word, complete the word being typed, fix the last word, and clean up a whole sentence — in Igbo, Yorùbá, Hausa, Efik, Tiv, Igede, Eggon and twenty others, alongside English, French, Spanish, Portuguese and Arabic.

Built by Hypa Intelligence. Trained on Hypa-Keyboard-v2.

Which build do I want?

Repo	Format	Size	Use it when
`-GGUF`	GGUF Q4KM	105 MB	On-device, llama.cpp, Ollama, LM Studio, mobile
→ [`-16bit`](https://huggingface.co/hypaai/Hypa-SmolLM-135M-Instruct-16bit) (this one)	BF16 safetensors	0.1B params	Transformers or vLLM; converting or quantising yourself
`-LoRAs`	PEFT adapter	—	Merging onto your own base, or continued training

What it does

Five tasks, each selected by its system prompt:

Task	System prompt	Behaviour
Next-word prediction	`You are Hypa Keyboard. Predict the next word.`	Text ends at a word boundary → emit the next word
Word completion	`You are Hypa Keyboard. Complete the current word.`	Text ends mid-word → finish the word being typed
Last-word correction	`You are Hypa Keyboard. Correct the last word.`	Fix only the final, just-typed token
Block correction	`You are Hypa Keyboard. Correct the text block.`	Return a clean version of the whole span
Grammar correction	`You are Hypa Keyboard. Correct grammar, missing words, spelling, and sentence errors.`	Full grammatical error correction over the span

Correction is trained against a controlled corruption vocabulary that treats tone-mark damage as a first-class error type. Losing diacritics is the single most common failure when typing tonal orthographies on a standard mobile keyboard, so restoring them is a core capability rather than an afterthought.

Usage

python

from transformers import AutoTokenizer, AutoModelForCausalLM

model_id = "hypaai/Hypa-SmolLM-135M-Instruct-16bit"

tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(model_id, device_map="auto")


def keyboard(system_prompt, text, max_new_tokens=8):
    messages = [
        {"role": "system", "content": system_prompt},
        {"role": "user",   "content": text},
    ]
    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=max_new_tokens, do_sample=False)
    return tokenizer.decode(
        outputs[0][inputs["input_ids"].shape[-1]:], skip_special_tokens=True
    )


# Next-word prediction
keyboard("You are Hypa Keyboard. Predict the next word.", "Ndewo, kedu ka ị")

# Word completion
keyboard("You are Hypa Keyboard. Complete the current word.", "Ẹ káàbọ̀ sí ilé ìwé wa, a")

# Fix the last word
keyboard("You are Hypa Keyboard. Correct the last word.", "I dey go markit")

# Clean the whole span
keyboard("You are Hypa Keyboard. Correct the text block.",
         "Omi Omi kp anya'ami mail ekubo uche r'abo ohigbeli mi.", max_new_tokens=64)

Serving with vLLM

bash

vllm serve hypaai/Hypa-SmolLM-135M-Instruct-16bit

Settings that matter

Use greedy decoding (do_sample=False). Sampling makes keyboard suggestions feel erratic — users experience variance as the keyboard being broken, not creative.

Keep `max_new_tokens` low: 4–8 for prediction and completion, 32–64 for block and grammar correction. On a 135M model, longer generations drift.

Converting to GGUF yourself

bash

python llama.cpp/convert_hf_to_gguf.py \
    hypaai/Hypa-SmolLM-135M-Instruct-16bit \
    --outfile hypa-keys-135m-f16.gguf --outtype f16

./llama-quantize hypa-keys-135m-f16.gguf hypa-keys-135m-Q8_0.gguf Q8_0

Training


Base model	`unsloth/smollm-135m-instruct-bnb-4bit` (SmolLM-135M-Instruct)
Method	LoRA (PEFT) via TRL `SFTTrainer`, accelerated with Unsloth, then merged to BF16
Dataset	`hypaai/Hypa-Keyboard-v2` — 409,598 examples
Languages	27
Precision	BF16
LoRA rank / alpha	2048
Target modules	["qproj", "kproj", "vproj", "oproj","gateproj", "upproj", "down_proj"]
Learning rate	1e-4
Epochs / steps	1
Max sequence length	2048

Framework versions

—TRL 1.9.2
—Transformers 5.13.1
—PyTorch 2.11.0+cu128
—Datasets 3.6.0
—Tokenizers 0.22.2

Evaluation

<!-- TODO: The most important section in this card, and currently the weakest. Suggested minimum:

—Next-word prediction: top-1 and top-3 accuracy, held-out split
—Word completion: exact-match by prefix length
—Correction: exact match and character error rate vs the clean target
—Diacritic restoration: accuracy on the has_tone=True slice
—Baseline: un-finetuned SmolLM-135M-Instruct, which makes the gain legible
—Per-language breakdown, or at minimum best and worst language Run it here on BF16, then reuse the same harness on the GGUF so the two cards can report a like-for-like quantisation comparison. -->

Not yet published.

Limitations

—No per-language evaluation. The training dataset has no language column, so quality across the 27 languages is unmeasured and certainly uneven. Expect better results in Hausa, Igbo, Yorùbá and Swahili than in Eggon, Igede, Ebira or Nupe.
—Synthetic training noise. Corruptions were programmatically injected. The model has not seen real keyboard-layout adjacency errors (fat-finger typos), swipe-typing failures, or genuine mid-sentence code-switching — all of which dominate actual mobile input.
—Close-relative confusion. Efik, Ibibio and Annang share substantial vocabulary and orthography. A correction valid in one may be applied to text written in another.
—Trained through a quantised base. The LoRA was trained against a 4-bit bnb checkpoint and then merged to BF16, so these weights are not identical to what full-precision training would have produced.
—Source-formatting leakage. Some training spans carried Markdown, prompt fragments and JSON punctuation, so the model occasionally treats prompt-like text as ordinary typing.
—Not a chat model. Despite the instruct base, this is trained for five narrow keyboard tasks. Conversation, question answering and translation are out of scope and will produce poor output.

Intended use

For: serving and evaluating the keyboard model at full precision; as the conversion source for on-device builds; research on low-resource keyboard modelling.

Not for: general text generation, translation, question answering, or any setting where output is treated as authoritative text in these languages. Corrections must be shown as suggestions the user can reject, never applied silently — a wrong autocorrect in a language the user speaks and the model barely knows is worse than no autocorrect at all.

Citation

bibtex

@misc{hypaai2026hypakeys,
  title        = {Hypa SmolLM 135M: A Compact Multilingual Keyboard Model for African Languages},
  author       = {Hypa Intelligence},
  year         = {2026},
  publisher    = {Hugging Face},
  howpublished = {\url{https://huggingface.co/hypaai/Hypa-SmolLM-135M-Instruct-16bit}}
}

License

Apache 2.0, inherited from SmolLM-135M-Instruct.

Contact

Hypa Intelligence • Website • Hugging Face • GitHub • Blog

Trained with Unsloth and Hugging Face TRL.