The serving cell's context value was a default misnamed as a limit, its concurrency axis was unmodeled, and the cost model for the trade was false

[gunbai-bot]

Three fleet-serving facts that were misnamed, missing, or wrong. Split out of #9897, which is a model-authority PR and was carrying this only because both edits happened in the same hour.

Misnamed

extdeps.ollama.server_env called OLLAMA_CONTEXT_LENGTH "the context window the SERVER allocates" and "the CONFIGURED limit". Upstream 0.32.9 resolves options in layers — environment, then model, then request — and an explicit num_ctx at either later layer replaces it. It never limited anything: it is the value used when no override applies. One name carrying two materially different contracts is a meaning fork, and a deployment reading it as a ceiling would believe it had bounded something any caller can raise. Renamed through the carriers to default_context.

Missing

OLLAMA_NUM_PARALLEL was not in the closed variable set and not rendered, so the hosts inherited whatever the runtime chose — one slot, which serializes. Measured 2026-09-01: a ~61,000-token prefill held one host for roughly two hundred seconds at a healthy 283–331 tok/s while every other caller queued, and the queue was read as a latency regression in the model rather than as contention. The axis is now modeled and the desired value is 4.

Wrong

The P1b note said the two axes trade "because the slot count divides the context window." Measured on one host, one model, changing only that variable:

slots	context_length	size_vram
1	1,048,576	88,865,253,620
2	1,048,576	90,543,761,652

Each slot receives its own full window. The count multiplies memory; it does not divide context. Deleted rather than softened.

The desired context becomes 1,048,576, and its evidence sentence is replaced

The old one cited an /api/ps reading as proof of a configured value. But /api/ps reports what a loaded runner holds, and both hosts carried no OLLAMA_CONTEXT_LENGTH line at all — so the number being confirmed was the runtime's own automatic default. A declaration cited its own absence as confirmation. Two prior values, 8192 and 131072, were both never enacted.

The rung drop is filed

One row for both values, because they are one defect in two spellings: measured on one node, one artifact, one runtime, one concurrency condition — then applied to two hosts and every realization the cell loads. llama4:scout in particular declares a window far beyond this ceiling with no cache compression.

The trigger names the capability, not an artifact: an observation table alone does not discharge it, because while a global default exists an unmeasured realization still inherits these numbers automatically. An unobserved realization must refuse, not inherit.

Standing disclosure

Both values are already live on both hosts, set by hand under operator instruction while they were blocked on testing. The modeled route — fleet_converge_timer → fleet_converge_apply → host_effect_realize — exists and carries spark serving rows, but was not usable at the time: the gunbc converge CLI verb is unwired by design, and a peer lane's wet plan run on that spine returned PartiallyApplied with apply refused. This PR reconciles the corpus to the hosts; until it lands, canonical main selects 131,072 and the hosts are intentional drift.

[gunbai-bot]

Fixed in ac9ff995d94.

Review 58311 is right and the fix is the one it names. The note in gunbc.extdeps.ollama.server_env ollama_num_parallel_env_assignment carried two byte figures and two context_length readings copied out of a run. The qualitative conclusion is what the authority needs — same context_length at one slot and at two, a larger buffer at two, so the count multiplies memory rather than dividing context — and the figures are replaced by the producer that owns them: gunbc.spark.serving_observe spark_serving_observe_ci_wet, whose readback is decoded by gunbc.spark.serving_readback_parse and already yields both quantities the comparison needs.

That is the same citation style the neighbouring gunbc.spark.serving_desired note already uses, so the two now agree instead of one naming the instrument and the other transcribing it.

— sent from eager-pike-541