Vulkan kernel-policy diagnosis
kiln.vulkan-kernel-policy.v6 is derived once from the selected physical device's reported
workgroup, shared-memory, descriptor, push-constant, subgroup, API, and memory-topology capabilities. Its
former KILN_DISABLE_VULKAN_*, KILN_ENABLE_VULKAN_*, kernel-threshold,
split-K, stage-profile, packed-weight, recurrence, and resident-decode variables are not controls and
must not be used to explain a run. The backend, kernel, and resident-model planners share one source
object for those decisions; malformed shell values, device names, vendor IDs, device IDs, and PCI identity
cannot select a different path.
curl -fsS http://localhost:8420/v1/config \
| jq '.accelerator_runtime | {schema_id, version, vulkan_kernel_policy_schema_id, vulkan_device_policy_schema_id, vulkan_device_index, vulkan_validation}'
- Remove old kernel switches from launch scripts. They have no compatibility aliases or replacement fields.
- Compare the binary/source commit and policy schema before comparing receipts. A route change requires a reviewed source revision and renewed Vulkan parity, performance, and soak evidence.
- Use typed batching, memory, prewarm, and accelerator fields for supported operator decisions. Do not infer a hidden model-route or kernel override from a throughput change.
- Historical optimization logs and the Vulkan microbenchmark document research experiments; neither defines the product runtime contract.
- Select a device with typed
accelerator.vulkan_device_index = "auto" or a strict zero-based index. Invalid explicit indices fail startup; they never fall through to another GPU.
- Enable validation only with typed
accelerator.vulkan_validation = true under the experimental profile. Startup fails when the Khronos validation layer is unavailable, so diagnostics cannot claim validation that was not active.
- The serving/kernel product no longer reads residual
KILN_VK_* tiling or CPU-fallback controls. The separate research executable uses only typed CLI arguments and cannot define a qualified product receipt.
Do not use the July 20 soak's 0.455 aggregate output tokens/second as a decode-rate diagnostic. That value
divides all output by a 1,935-second mixed-concurrency request window; its 76.7 ms median inter-token
latency corresponds to about 13.0 decode tokens/second. The
benchmark page separates decode, prefill, TTFT, and request-window throughput
and shows the July 27 regression and current correction as comparable runs.
Vulkan prefix-cache diagnosis
Vulkan currently correctness-quarantines all cross-request prompt, KV, and recurrent-state reuse.
A conforming process reports the configured intent separately from an effective false capability and
fresh-prefills exact repeats. Do not interpret zero hits as a tuning or capacity problem on this backend.
curl -fsS http://localhost:8420/v1/config | jq '.prefix_cache'
curl -fsS http://localhost:8420/health | jq '.prefix_cache, .decode_runtime.batching_engine.prefix_cache_enabled'
curl -fsS http://localhost:8420/metrics | grep '^kiln_.*prefix_cache'
- Require
effective_enabled=false, effective_reason="vulkan_correctness_quarantine", health prefix_cache.enabled=false, and actor prefix_cache_enabled=false.
- Every lookup, hit, miss, hit-token, hit-block, cached-block, maximum-block, cached-entry, maximum-entry, state-byte, lease, and pending-release value must be zero.
- Changing
prefix_cache.max_blocks or max_entries cannot enable the cache on Vulkan. No request field or environment alias bypasses the source-level gate.
- A nonzero activity value, an exact repeat that takes a cache route, or an effective true capability means artifact drift and requires stopping the process before trusting output.
- Re-enablement requires production-model oracle parity across first use, exact repeats, strict descendants, changing concurrency, cancellation, and repeated history.
Vulkan resident-prefill diagnosis
The serving profile—not a device name or request field—controls admission. Stable and maintenance
report resident_prefill_enabled=false; experimental reports true and may take the native
route when the request and selected device satisfy its checks. This route is separate from
cross-request prefix reuse, which remains quarantined on Vulkan in every profile.
curl -fsS http://localhost:8420/health \
| jq '.decode_runtime.batching_engine | with_entries(select(.key | contains("resident_prefill")))'
curl -fsS http://localhost:8420/metrics \
| grep '^kiln_batching_engine_.*resident_prefill'
- Under stable or maintenance, every attempt, forward, decline, route-failure, row, completion, active-row, and batch-size field must remain zero; each request must report
resident_prefill_used=false.
- Under experimental, require the capability to be true before interpreting activity. A request-level
resident_prefill_used=true means a native full-stack forward completed; it is route evidence, not a performance or correctness verdict.
- There is no independent resident-prefill TOML field, environment switch, or request override. Change the serving profile, restart, and verify the resolved policy.
- For wrong tokens, route failures, or instability, preserve the exact source/config/device receipt and return to stable. Production-model parity across changing cohorts, cancellation, and repeated process history is required before promotion.