Kiln is a local server for one continuous loop: serve a model, collect evidence, train an adapter, evaluate it, and put the winner back into service. It packages that loop in one Rust process instead of making you operate a separate inference server, training service, evaluation system, and adapter registry.
Is Kiln for me?
Use Kiln when you want to improve Qwen3.5-4B on a machine you control and the improvement loop matters as much as raw serving throughput.
Kiln is a good fit for:
- OpenAI-compatible local inference for agents and applications;
- SFT, GRPO, OPD, and adapter hot-swap when the selected backend advertises the required training route;
- local eval suites, comparisons, judgments, and replay;
- traceable artifacts with model, request, training, and execution provenance;
- a single-GPU workstation rather than a distributed serving fleet.
Kiln is not presently positioned as a replacement for vLLM in a high-concurrency, serving-only deployment. See Benchmarks for the measured boundary and the metrics behind it.
The shortest path
- Follow the guided Quickstart.
- Send an OpenAI-compatible chat request.
- Open the embedded dashboard at
http://127.0.0.1:8420/ui/. - Import or collect training examples.
- Train an adapter, run an eval, and promote the result deliberately.
The public product tour shows the current dashboard and explains which parts are live product UI, seeded example data, or historical recordings.
What runs where
Kiln supports CUDA, ROCm, Metal, and Vulkan builds. Backend availability,
supported training routes, memory limits, and optimization maturity differ.
Startup resolves the selected backend and exposes the effective configuration
through /health, /v1/config, the CLI, and the dashboard.
The project does not treat “the process started” as proof that every route is qualified. Performance pages distinguish source revisions, hardware, workloads, and metric definitions; qualification receipts remain separate from user guidance.
How the loop fits together
| Stage | What Kiln does | Where to continue |
|---|---|---|
| Serve | Runs chat, completion, streaming, batching, and adapter-aware requests | API guide |
| Observe | Records latency phases, request lineage, outputs, and runtime state | Latency observability |
| Teach | Accepts SFT, GRPO, OPD, and related training jobs | GRPO guide |
| Evaluate | Runs local suites, comparisons, judgments, and replay | Evals guide |
| Promote | Saves, validates, loads, and selects LoRA adapters | Adapter manifest |
Documentation map
The site is split intentionally:
- Product guides answer the common “how do I do this?” questions.
- Core documentation explains configuration, architecture, performance, and supported workflows without reproducing internal engineering ledgers.
- Reference library contains exact schemas, contracts, qualification protocols, and maintainer material when you need source-level detail.
Core pages keep the common path readable and link to the searchable reference for exact fields, schemas, and qualification evidence.