// use cases
Where a no-OS inference kernel earns its keep.
cllm is deliberately the opposite end of the spectrum from a managed Python endpoint. These are the workloads where deleting the host OS is a feature — and we are honest about the ones where it is not.
Edge inference appliances
→Ship an inference server as a single Multiboot ELF that boots on the metal — no distribution to patch, no init system to harden.
Edge & embedded teams
Latency-sensitive serving
→Remove the scheduler, the syscall trap, and the userspace boundary so the CPU spends its cycles on the inference path and nothing else.
Latency-focused operators
Air-gapped & inspectable deployments
→A single ELF with no shell, no userspace, and no package manager is a small, reviewable trusted computing base.
Security & regulated teams
Kernel & performance research
→A small, GDB-attachable ring-0 codebase where you can experiment with inference optimizations without negotiating with a host kernel.
Kernel & perf engineers
// where cllm is the wrong tool
If you write Python and want a managed endpoint, need production GPU serving today, or run on macOS, Windows, or non-x86 Linux, cllm is not the right answer — and will not be. It targets the other end of the spectrum on purpose. See the vLLM comparison for that trade-off.