Paul’s learnings

The speed is not
in the LoRA.

The adapter changes what the model learns. The inference objective changes how much work you ask it to do.

Field guide · Decision experiments · Adaptation and training

Execution paths: Generative vs. Kev vs. Laya-LiteRT

Generative language modelKev (ONNX pointer head)Laya (LiteRT dual graph)
Prefill the input once.Prefill state and question branches once (block-causal mask).Main graph encodes prompt with right-padded inputs and [MASK] markers.
Decode token 1, then token 2 conditioned on token 1, and so on.Read scores at option/decision positions with pointer head.Host gathers token_logits at [MASK] markers; separate act head runs after.
With a KV cache, prior keys/values are reused. It does not recompute the whole prompt every step.In-graph delimiter detection and pointer head; softmax in app.Decision softmax computed host-side over gathered mask logits; act head emits act_logits [1,2].
Time depends on input prefill plus output length, decode throughput, batching and hardware.Single forward pass per request. Input length, options, questions, attention/memory costs and infrastructure still matter.Single forward pass per question. Input length, options, attention and memory costs still matter.

A hundred generated tokens involve repeated sequential decoding steps. Eliminating that loop can materially reduce latency. But a decision request is not constant-time with respect to its input, and neither “one pass” nor “LoRA” mathematically implies 200× speedup.

What LoRA and encoder decision layers contribute

Low-rank adaptation learns a small weight update rather than training every base weight. It primarily reduces training parameters and optimizer state. At inference, an adapter may be merged into the base weights or applied alongside them. It does not delete the base transformer or make a 4B model into an 11M-parameter forward pass.

Kev’s specialized training objective and readout repurpose that transformer: instead of repeatedly sampling vocabulary tokens, it computes scores over the caller’s declared options. The small trained head is critical, but most of the inference work is still running the backbone on the packed input.

Dual-graph LiteRT vs. single-graph ONNX

On-device decision models differ in their underlying backbone class and execution packaging:

A cost-shape calculator, not a benchmark

Change the assumed prefill and per-token times. The arithmetic illustrates why output length matters; it does not model an actual provider or account for all runtime costs.

Formula: generative = prefill + tokens × decode; decision = prefill + illustrative 2ms readout. Shared prefill is an explicit simplifying assumption, not measured parity.

Where the evidence ends

For a fair comparison, hold task quality, context, options, hardware and concurrency fixed. Compare end-to-end latency, including transport, and report the complete distribution—not just a vendor’s best multiplier.