Applications
Workloads that belong on the device, not in a datacentre
Grouped by what the model does and by the industries that ask for it most. Availability always depends on the target device profile.
- Detection
- Classification
- Language
- Audio
01By workload
What the model is asked to do
Offline assistants
On-device chat, summarisation and structured extraction where connectivity is unreliable or prohibited.
Local analysis
Useful local understanding that remains in the environment where it is needed.
Private workflows
On-device AI workflows that keep sensitive inputs private by default.
Audio classification
Alarm, speech and machine-sound events on low-power boards.
Anomaly detection
Baseline drift on sensor, vibration and current streams, evaluated locally.
Local automation
Local triggers and actions derived directly from on-device model output.
02By environment
Where local AI is useful
IoT environments
Connected devices that benefit from private, responsive local intelligence.
Private operations
Local workflows that avoid sending sensitive inputs to external services.
Field operations
Offline assistants on phones carried into sites without reliable networks.
Edge AI
Reliable local model execution when connectivity is limited or unavailable.
Retail & logistics
Counting, presence and condition checks on existing handheld hardware.
Research & prototyping
A fast path from a model repository to a real device for evaluation.
03Honest scope
What we do not claim
- LokiAI does not train models — it deploys and operates existing ones.
- A workload is only viable if the device profile can actually load and run the artifact.
- Large language models on constrained boards remain slow; quantisation is a trade, not a fix.
- Planned device classes cannot run any of these workloads yet.
Tell us the workload and the hardware
We will say honestly whether a current device class and runtime can carry it.
