ks-cascade amendment 1b: the cost constants c_p and c_g, frozen before any SELECT generation

amendment · unverified · machine-checked · Kannaka · 2026-11-05T06:52:05.141Z

Amends preregistration 01M6MFZEQBGYD8517QFRP0GHP6; completes amendment 1 (01M6N3P11QCAQ58RDMR2D4503A), which deferred these constants to this record.
Filed before any feature matrix is built and before any SELECT generation. Nothing in amendment 1 changes.

The calibration ran on the dedicated instance from 2026-11-05T05:37Z, the moment the pilot released it, to
2026-11-05T06:47Z, status complete, 100 of 100 planned calls (it resumed the one-sample partial file of the
stopped 00:07Z attempt described in amendment 1; that sample is the 14B's excluded first call), under production load throughout (one-minute load average before each
call 6.4 to 26.4; the production server reported a loaded model on 99 of 100 calls; the 600 percent CPU quota throttled
the instance in 2838 scheduler periods, and CPU seconds count run time only). Protocol as published in amendment 1 (calibrate.py): five fixed prompts built from the
first five SELECT ids at the 5.2k-token character budget, both models interleaved, ten repetitions, 64 completion
tokens at most, think off, CPU seconds read from the instance's own cgroup counter around each call, and a sample
rejected when the server's prompt_eval_cached_count shows more than five percent of the prompt served from its
prefix cache. No thinking span appeared in any output.

Correction to amendment 1's token definition, before any row exists. Amendment 1 defined a row's gated prompt-token
count as prompt_eval_count plus prompt_eval_cached_count. The calibration shows the server's prompt_eval_count
already includes the cached tokens: a fully cached call reports prompt_eval_count 4193 and
prompt_eval_cached_count 4192, and an uncached one reports the same prompt_eval_count with a cached count of 22 to 63 (the
shared system prefix). The sum would double-count that prefix. The gated prompt-token count of a row is therefore
prompt_eval_count alone, which is the whole prompt whether or not any of it was cached; prompt_eval_cached_count
stays on every row as the cache stamp. The rejection rule in calibrate.py compares prompt_eval_count with 0.95 times
the sum, which with these semantics rejects a sample once more than about five percent of its prompt was cached;
that is the rule as applied and it is kept.

Constants, frozen from this record (CPU seconds per token, medians over the accepted samples; the gated cost of a
row is c_p times its prompt_eval_count plus c_g times its eval_count):
14B: c_p = 0.6059, c_g = 3.013 (accepted n = 5; c_p across prompts 0.5927 to 0.6178, a spread of 4.1 percent).
8B: c_p = 0.3181, c_g = 1.877 (accepted n = 4; c_p across prompts 0.3096 to 0.3249, a spread of 4.8 percent).
Least-squares fit of the same samples for comparison, not gated: 14B c_p 0.6151, c_g 1.595; 8B c_p 0.3226, c_g 1.424.
c8 over c14, the ratio of per-call CPU seconds at the same prompt: 0.537 (median over prompts, range
0.523 to 0.552). Prediction 3 said 0.45 to 0.55. Prompt evaluation ran at 9.9 tokens per
second on the 14B and 18.8 on the 8B; a sample's CPU seconds were 5.99 times its wall seconds on the 14B.

Deviation 3, the repetitions were cache hits. Repetition 0 produced one uncached sample per model and prompt
(the shared system prefix of 22 to 63 tokens was served from cache, under the five percent line). From repetition 1
on, the instance served 100.0 percent (14B) and 100.0 percent (8B) of every prompt from its prefix cache even though
four other prompts and the other model had been called in between: ollama retained every prompt's cache per model
across the interleaving. The preregistered rule rejected all 44 (14B) and 45 (8B) of those samples, as it should, so
the accepted counts are 5 and 4, not fifty. The 8B's first call was its first prompt and is excluded by
the first-call rule although the model was already resident from the pilot, which is why the 8B has one fewer.
Decision: the constants above are frozen from the accepted samples. No supplementary cache-busting run is added,
for three reasons: the spread of c_p across the different prompts is about four to five percent of the median
(range over median) with no visible dependence on the load average, well inside anything the cost gate can resolve; c_g does not depend on the prefix cache (the cached samples decode the same context), and
the median over all 49 (14B) and 49 (8B) non-first samples is 2.953 and 1.779, agreeing with the accepted-only
values; and the preregistration already validates the token model on every generated row with the same cgroup
counter, so a wrong constant shows up there rather than being masked. The calibration file carries every sample
with its load, cache and production stamps; no prompt text, question id or model output is in it (outputs are
hashed).

What the constants imply. At the pilot's median prompt and completion sizes one 14B answer costs 3448 CPU seconds
of the token model and one 8B answer 1917; the G1 cost line, half the sum of the always-14B and always-8B means,
sits near 2682 CPU seconds per question on those sizes. The actual line is computed from the arms' own rows.

The generation runner reads the same cgroup counter around every call and stores it on the row beside the token
counts, so the per-row validation in the preregistration is the comparison of that number with the token model.
Written by Claude Code in a session run by the maintainer, who asked for the filing.

Evidence

content hash 37388ddf3721b79522702b2a7373fd865c98c1ffac78e121c082189f0f83a381

Machine check: machine-checked

Derived from verify_record.py at b3ba75d; it never changes the standing.