Tsallake zuwa babban abun ciki

Deployment for African contexts

The chapter that nobody else writes.

Most NLP deployment writing assumes a fibre connection, a GPU-backed cloud region a short round-trip away, a modern laptop or high-end phone, and a monolingual user typing standard-orthography input. None of these assumptions hold across the majority of African deployment surfaces. Connectivity is patchy or expensive; a large share of interactions happen on Android Go phones with 2 GB of RAM; users switch languages within a single conversation; and the practical text-entry surface is often SMS or WhatsApp, not a native app. Deployment writing that ignores this is written for someone else's market.

This chapter is opinionated deployment guidance for the surfaces where African-language NLP actually meets its users. It is not a general MLOps guide — for cloud deployment, latency budgets in low-hundreds-of-milliseconds, and standard-issue Kubernetes practice, use ML Systems (Chip Huyen) or the cloud providers' own material. This chapter picks up where those leave off.

What this chapter covers

  • Offline and patchy-connectivity NLP — the design pattern where the model runs on-device or in a locally-cached scenario, syncs opportunistically, and degrades gracefully when the network drops mid-session. Available now.
  • SMS, USSD, and WhatsApp as NLP surfaces — the three practical text-entry channels for hundreds of millions of African users, with channel-by-channel design implications and NLP problems each magnifies. Available now.
  • Edge devices and cheap-hardware inference — the phone tier map, quantised model inference, on-device runtimes (whisper.cpp / llama.cpp / ONNX Runtime Mobile / MLC-LLM), battery and thermal realities, single-board-computer edge servers. Available now.
  • Multilingual switching within a session — code-switching as the majority interaction pattern for African users, four granularities of switching, detection strategies, response strategies, model training implications, and the UI patterns that make code-switched deployment usable. Available now.
  • Non-Latin scripts in real UIs — Ajami, Ge'ez, N'Ko, Tifinagh, Vai, and Latin-with-diacritics; Unicode support, font shipping, input-method availability, rendering pitfalls, search and normalisation, testing methodology. Available now.

Why this chapter belongs in a playbook, not a blog post

Deployment realities shape modelling decisions upstream. A team that will ship to Android Go should not fine-tune a 7B model. A team that will accept SMS input should not assume tone-mark diacritics. A team whose users code-switch should test on code-switched evaluation sets. These decisions cascade back through training data, evaluation set design, and even annotation guidelines. Keeping the deployment lens visible from the start prevents a lot of expensive rework at the end.

What this chapter is not

  • Not a tutorial on any single cloud provider or MLOps tool. Those change annually and are documented by the vendors.
  • Not a benchmark of quantised model latency. Vendor-specific and out of date the moment it is published. When we need those numbers, we point at a live benchmark.
  • Not a critique of any particular platform. Practical guidance, not commentary.

For the strategic reasoning behind this chapter — why the playbook adds a "Deployment for African contexts" section instead of writing a general deployment guide — see What this playbook is (and isn't).

Contributor
@abumafrim

Join the discussion

Spotted an error, have a question, or want to share what worked on a real project? Sign in with GitHub to add your voice — every thread lives in the open, powered by GitHub Discussions.

Loading discussion…

Thanks to our Contributors

The Playbook is built by a growing community of researchers, students, and language experts. If you've contributed code, content, or review — thank you.

SUPPORTED BY

Masakhane African Languages HubBayero University, KanoBahir Dar UniversityHausaNLPEthioNLP