Overview
On-device language features must balance offline privacy and local availability against memory, latency, context, parsing, reliability, and hardware limits. This series shows how to assign hard guarantees to product logic, bound model generation, and use controlled adapters, graph optimization, quantization, and decoding for broader workloads. Palabrita illustrates scope reduction; Samsung illustrates runtime adaptation. Their results depend on tested devices, models, tasks, languages, and fallbacks, not universal edge-AI promises.
Learning outcomes
- Hard product guarantees belong in deterministic logic and curated data, not unconstrained generation.
- A smaller model role can preserve user value when bounded output and a deterministic fallback keep the feature usable.
- Runtime LoRA inputs can retain multiple tasks on a shared frozen graph, but compatible adapter shapes limit flexibility.
- On-device feasibility depends on measured device, model, workload, language, metric, and fallback conditions—not one benchmark.
Keywords
Preview every chapter · Unlock full text, audio, and video from chapter 4
PlansFAQ
What should an on-device language model be responsible for?
It should handle bounded creative or transformational work, while product logic and deterministic data enforce hard facts and guarantees. Runtime and hardware should control execution, validation, and failure paths.
How did Palabrita make local AI reliable enough for its word game?
Palabrita moved word selection into curated language-specific assets, kept the model to three hints, and used validation plus a deterministic fallback. This removed hard lexical constraints from generation.
How does Samsung support many tasks with one mobile language model?
Samsung supplies compatible task-specific LoRA adapters as runtime inputs to a shared frozen LLaMA-based graph, avoiding a separately compiled full model for each use case. The approach assumes equal adapter dimensions.
What evidence is needed before shipping on-device AI?
Measure the whole path on target devices and workloads: initialization, latency, memory, output acceptance, retries, fallbacks, context aging, and task-and-language quality. Keep architectural limits separate from evaluation gaps.