Hypa SmolLM 135M — Keyboard (GGUF)

A 105 MB smart-keyboard model for 27 languages, built to run on a phone.

This is the quantised llama.cpp build — the one you want if you're actually deploying. It 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.

Keyboard assistance has to run locally, offline, with low latency, on the mid-range Android phones that dominate the markets these languages are spoken in. That constraint is why the base model is 135M parameters and why this build is 105 MB rather than several gigabytes.

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

---

Which build do I want?

---

What it does

Five tasks, each selected by its system prompt:

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

llama.cpp

# Interactive
llama-cli -hf hypaai/Hypa-SmolLM-135M-Instruct-GGUF:Q4_K_M --jinja

# OpenAI-compatible server
llama-server -hf hypaai/Hypa-SmolLM-135M-Instruct-GGUF:Q4_K_M --jinja

Ollama

ollama run hf.co/hypaai/Hypa-SmolLM-135M-Instruct-GGUF:Q4_K_M

LM Studio / Jan

Search for hypaai/Hypa-SmolLM-135M-Instruct-GGUF in the model browser.

Calling a keyboard task

Against the llama.cpp server:

curl -s http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "messages": [
      {"role": "system", "content": "You are Hypa Keyboard. Predict the next word."},
      {"role": "user",   "content": "Ndewo, kedu ka ị"}
    ],
    "max_tokens": 8,
    "temperature": 0
  }'

From Python with llama-cpp-python:

from llama_cpp import Llama

llm = Llama.from_pretrained(
    repo_id="hypaai/Hypa-SmolLM-135M-Instruct-GGUF",
    filename="*Q4_K_M.gguf",
    n_ctx=512,
    verbose=False,
)

def keyboard(system_prompt, text, max_tokens=8):
    out = llm.create_chat_completion(
        messages=[
            {"role": "system", "content": system_prompt},
            {"role": "user",   "content": text},
        ],
        max_tokens=max_tokens,
        temperature=0.0,
    )
    return out["choices"][0]["message"]["content"]


keyboard("You are Hypa Keyboard. Predict the next word.", "Ndewo, kedu ka ị")
keyboard("You are Hypa Keyboard. Complete the current word.", "Ẹ káàbọ̀ sí ilé ìwé wa, a")
keyboard("You are Hypa Keyboard. Correct the last word.", "I dey go markit")
keyboard("You are Hypa Keyboard. Correct the text block.",
         "Omi Omi kp anya'ami mail ekubo uche r'abo ohigbeli mi.", max_tokens=64)

Settings that matter

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

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

A small context window (256–512) is usually enough and keeps latency and memory down on mobile.

Available files

---

Training

---

Evaluation

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.
• Quantisation cost is unmeasured. Q4 on a 135M model is a harsher compression than the same quant on a large model. Until the BF16-vs-Q4 comparison exists, treat any quality gap as unknown.
• 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.
• 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: on-device keyboard assistance — prediction, autocomplete, autocorrect, diacritic restoration, light grammar correction; 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

@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-GGUF}}
}

License

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

Contact

Hypa Intelligence • Website • Hugging Face • GitHub • Blog

Quantised with Unsloth.