runtime: move the ollama pin to 0.33.3 — the first release whose llama.cpp can load qwen4exp (#1193) - #1235
Merged
Conversation
|
📘 Docs preview — the preview channel for this PR has been deleted now that it is closed. |
….cpp can load qwen4exp (#1193) v0.33.3 became a stable release on 2026-09-02 (the GitHub release API reports prerelease=false), which is what #1193 was waiting for. It vendors llama.cpp b10760, and qwen4exp landed at b10666 (ggml-org/llama.cpp#27742), so this is the first pinned engine whose llama.cpp runner can load the Qwen3.8-Flash-Next family at all — the floor #1192's catalog entry declares, and the reason TestBundledEngineFloorsNeverExceedThePin needs this constant moved first. Measured rather than assumed (#1132's list), on three OSes. Three things came back narrower than the tree assumed, and each is recorded where the claim lived rather than fixed away: - "Report cached prompt tokens" reaches this product. ollama now reports prompt_tokens_details.cached_tokens on /v1 and prompt_eval_cached_count on /api/chat, with no flag to ask for it: a repeated request on qwen3.5:0.8b-q8_0 answered 610 prompt tokens with 606 cached where the first answered 0. OpenAIUsage.CachedPromptTokens therefore starts returning real reuse on the ollama path, and convert.go's "ollama has no equivalent on any surface" is narrowed to say when that stopped being true. - "Honor GGUF model defined default parameters" made the engine's own default window host-dependent — 32768 on a 37.4 GiB Mac, 262144 on a 102.2 GiB Strix Halo. ollamaContextFloor's value is unaffected (it floors what the agent asks for, and the agent always exports OLLAMA_CONTEXT_LENGTH), but its doc's sentence about "the pinned engine's own default" now names one end of a range. - The Windows ROCm overlay is rocm_v7_1, not the v6.1 that amdROCmSupportedRes is stamped against, and its rocBLAS kernels carry gfx1150/1151 and gfx1200/1201 — Strix Halo and RDNA4, neither of which that list or upstream's own Windows table knows about. The regexes and the Strix Halo arm are deliberately unchanged here: both gaps end on Vulkan, which works, and choosing differently wants a measurement. #1233 carries it. The comment's pointer to scripts/install/ollama-windows.ps1 is removed instead: #493 deleted that file, so "keep in sync with" named a file that is gone and the per-bump checklist it referred to did not exist. The checklist now lives beside the list it maintains. Unchanged and re-verified: asset names and sha256sum.txt coverage (TestPinnedReleasePublishesEveryAssetChecksum against the real release); all three archive layouts, by unpacking them; a non-leading system turn still answering 200 on both surfaces (#1035); the keep_alive asymmetry ResidencyEffect rests on (#908); /api/ps's fields and engine.log's logfmt; and -np still on the runner command line (#763). Refs #1192 Refs waired-ai/waired#1312 Signed-off-by: gen16k <gen16k@users.noreply.github.com>
…hat quote the pin The changelog paragraph in OllamaPinnedVersion's doc names the hosts and the numbers; these two dated records carry the full measurement and the reasoning, in the shape docs/decisions/20260829/1600 and docs/knowledges/20260829/1600 set for the previous bump. Two corrections to the paragraph landed here as well: the Linux leg was the WSL2 development machine rather than sv-mag (held by another lane for the whole window, and a different card from the RTX PRO 4000 the 0.33.2 entry used), and all three archives were unpacked rather than two. The raw-vs-folded prompt_eval_count comparison gained a bullet with its numbers — qwen3.8-27b agrees on both counts (19/19, 24/24) and qwen3.5:0.8b-q8_0 differs on the second (28 vs 24), identically on macOS and Linux, which is what rules the OS out and leaves the chat template as the explanation the 0.33.2 entry already gave. The docs-site quotes move because they quote product output: cli.md and its ja mirror carried 0.33.2, and troubleshooting.md and doctor.mdx (and their mirrors) were stale further back at 0.32.15 and 0.33.2. Refs #1233 Refs waired-ai/waired#1312 Signed-off-by: gen16k <gen16k@users.noreply.github.com>
… moved npm run i18n:accept for doctor.mdx, reference/cli.md and troubleshooting.md. The Japanese text needed no change — the edit was inside a quoted block of product output, which is identical in both languages — but the hash records that the pair was looked at, which is what the check asks for. Signed-off-by: gen16k <gen16k@users.noreply.github.com>
gen16k
force-pushed
the
l100-ollama-0333-pin
branch
from
September 5, 2026 17:37
bac6fc3 to
cd4aafb
Compare
gen16k
added a commit
that referenced
this pull request
Sep 5, 2026
…the page (#1215) Every ja page carried a sourceHash in its frontmatter — a digest of the English page it was translated from — and i18n:check compared it. That is a derived value stored in a versioned file: two PRs touching one English page always rewrote it to two different values and always conflicted, on that line and nothing else, while the prose merged cleanly. Measured on main over the 60 days before this: 219 of 622 commits touch a ja page, 90% of them rewrite the hash, and 35 of 144 overlapping PR pairs share a ja file. At one or two docs lanes that is a cost per collision. At today's lane count it is a condition on landing — #1198 held 12 of the 32 ja pages for 2 h 19 m and went CONFLICTING four times, each within nine minutes of a competing PR merging, and the answer of the day was to hold everyone else's merges. It is not only wide docs PRs: #1237, a gateway change that touches three docs pages incidentally, spent two of its four force-pushes on the same line. This PR itself went CONFLICTING 2 m 40 s after it was opened, before its own CI finished, on one line of ja/troubleshooting.md. Removing the stored value removes the class. The freshness question moves to the diff, where nothing is stored and nothing conflicts: a PR that changes an English page changes its Japanese one too, enforced by scripts/ci/i18n-pair-guard.sh in docs-guard.yml, with a `translation-not-needed: <reason>` line in the PR body for the English edit that genuinely needs no translation. Replayed over every commit since the mirror was enforced (#147), that line would have been needed six times across 405 page pairs — three terminology sweeps where an English phrase changed and the Japanese sentence was already right — and nothing else in the repository's history would have failed the rule. A merge driver was considered and does not work: a custom driver only runs where git config sets it, and GitHub computes mergeability server-side, so the PR still goes DIRTY and still has to be rebased. i18n:check keeps the two questions that are about the tree and cannot be answered from a diff: is there a ja page at all, and do the two sides still have the same shape (#678, #1011). That comparison now runs on every pair, always, instead of only on pairs whose hashes already agreed — and that gate was worth less than it looked, because on the path a stale pair actually takes, --accept wrote the hash before it ever reached the refusal, recording a lost heading as intentional and reporting it only on the next run. --accept and i18n:accept are gone with the value they wrote. So is the "may be out of date" notice in PageTitle.astro and the second copy of the digest it carried: deploy-docs.yml runs i18n:check before the build in the same job, so a page the notice would fire on never reaches the site, and it has never rendered on docs.waired.ai since it was added alongside the check in #147. The rule and its opt-out are written where a contributor already reads about the sibling one — CONTRIBUTING.md next to docs-not-needed:, and CLAUDE.md §Documentation, whose "npm run i18n:check gates it" was true of freshness before this change and is not any more. Sequenced directly with the lanes that had docs PRs open (#1235, #1237 first; #1241 after), because this touches all 32 ja pages at once. Fixes #1215 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BgrcRiYj339QxzD3b6KijQ
gen16k
added a commit
that referenced
this pull request
Sep 6, 2026
…copy each (#1193) #1235 narrowed convert.go's "ollama has no equivalent on any surface" and ollamaContextFloor's "the pinned engine's own default is 32768". Both statements existed in more than one place, and the other copies were left saying what the measurement had just disproved. The cached-token claim also lived in internal/gateway/handlers.go (setCachedInput: "every engine but vLLM with --enable-prompt-tokens-details") and in internal/observability/ eventring.go (CachedInputTokens: "only vLLM reports the breakdown"). Both now say when that stopped being true. This matters more than the wording: CachedInputTokens feeds waired_inference_cached_input_tokens_total, whose Help already says "Only engines that report a prompt-token breakdown move this" — so ollama hosts silently started moving a counter two comments said they could not. The untuned-default claim lived in internal/runtime/ollama.go and cmd/waired-agent/inference.go, both describing the #624 boot-order gap as costing "its 32k default". 0.33.3 derives that default from the VRAM it found instead — measured 32768 on a 37.4 GiB Mac and 262144 on a 102.2 GiB Strix Halo — so the window an untuned spawn takes on a large host is now far bigger than the sentence implies. The tuned path is unaffected, which is why nothing here changes behaviour; the gap's cost simply is not what it says. Found by tracing what the two narrowed claims actually feed, rather than by grep: the question "what would change for the product" is what turned up the counter and the untuned path. Refs #1235 Refs waired-ai/waired#1312 Signed-off-by: gen16k <gen16k@users.noreply.github.com>
gen16k
added a commit
that referenced
this pull request
Sep 6, 2026
… numbers that survive the spread The owner rejected #1247's ROCm conclusion on two grounds, and both were right. Prior verification had concluded ROCm did not work on Windows, and a 102.2 GiB / 76.8 GiB difference in exposed memory looked wrong. Reading my own logs back, the evidence for "ROCm engages" was ollama's dispatch label and /api/ps — neither of them llama.cpp's accounting. The line I had quoted, `load_tensors: ROCm_Host model buffer size`, is a HOST buffer. The device line was never read. It is read now, with a CPU-only control obtained by moving both backends out of lib/ollama: ROCm load_tensors: ROCm0 model buffer size = 21171.18 MiB, GPU 453 % Vulkan load_tensors: Vulkan0 model buffer size = 21171.18 MiB, GPU 112 % CPU only size_vram 0, GPU 0 %, prefill 158.1, decode 19.33 So both really run on the GPU. The performance claim did not survive. #1247 measured one turn per backend at num_predict 64 — a 1.2-second decode window — and the same Vulkan configuration moved 22 % between sessions under it, which is twice the gap it claimed. On the owner's suggestion the measurement was sized up: 30-36k-token prompts, num_predict 512, the backends alternated inside each run, the cold turn after each load discarded, six samples each. prefill Vulkan 876.8 (839.4-912.6) ROCm 636.3 (580.0-654.1) decode Vulkan 49.2 ( 47.9- 50.1) ROCm 43.8 ( 43.1- 44.3) Neither range overlaps. Vulkan by 37.8 % and 12.3 %, and the decode spread fell to 2.7 % — that collapse is the whole reason the gap is readable. The conclusion #1247 reached survives; the numbers it reached it with do not, and are replaced. The history is corrected in the same pass. #1247 said the arm's "ROCm has no Windows APU support" stopped being true at 0.33.3. Reading the zip central directory for five releases shows gfx1151 in the overlay back to v0.12.6, and starting v0.31.1 and v0.33.2 on the host shows both discovering ROCm exactly as 0.33.3 does. What DID change is upstream of that: the 2026-05 survey (waired's own records) found the overlay was `lib/ollama/rocm` at ROCm v6.1 and AMD documenting Ryzen AI APUs as excluded, so the claim was written against a real state of the world and the stamp went stale rather than the claim being careless. Also finishes two claims #1235 narrowed in one copy each: the cached-token comments in handlers.go and eventring.go, and the untuned-default comments in ollama.go and inference.go. The knowledge note on the second records why that one is contained — every consumer gates on ContextLength > 0, so the engine's own default reaches no advertisement, no measurement and no verdict. Refs #1247 Refs #1235 Refs waired-ai/waired#1312 Signed-off-by: gen16k <gen16k@users.noreply.github.com>
gen16k
added a commit
that referenced
this pull request
Sep 6, 2026
…d the next bump knows what to re-read (#1233, #1193) (#1250) * runtime: ROCm did not start working on Strix Halo at 0.33.3 — it always did (#1233) #1247 said the Windows arm's "ROCm has no Windows APU support" stopped being true at 0.33.3, because the overlay "is now rocm_v7_1 and carries gfx1151". That "now" was an inference from the comment's own version stamp, and it is wrong. The overlay asset was read for five releases — 0.31.1, 0.32.13, 0.32.15, 0.33.2 and 0.33.3. All five unpack to rocm_v7_1 and all five carry the same targets: gfx906, gfx906-xnack-, gfx1030, gfx1100, gfx1101, gfx1102, gfx1150, gfx1151, gfx1200, gfx1201. The overlay's contents are not what changed, and the stamp "Ollama 0.31.x, ROCm v6.1 overlay" was wrong about the version it named. Shipping kernels is not engaging, so that was measured too: 0.31.1 and 0.33.2 were each unpacked on the same Ryzen AI Max+ 395 with their own overlay and started with OLLAMA_IGPU_ENABLE=1 — no model needed, the startup discovery line is enough. Both emit, character for character, what 0.33.3 emits: library=ROCm compute=gfx1151 ... type=iGPU total="76.8 GiB" available="76.6 GiB" So the claim was not overtaken by an upstream change. It was false on every engine this product has pinned, at least back to the version its own stamp named. Nothing else in #1247 moves: Vulkan is still faster here, ollama still picks it by itself with both backends on disk, and the reason the arm now gives — measured faster, not ROCm absent — is still the right one. Only the history was wrong. The knowledge note takes a dated 補足 rather than a rewrite, so the record shows what was believed and what replaced it, and it carries the lesson one level up from its own §4: a version stamp in a comment is not evidence about that version. Both checks were cheap — one ranged request for a zip's central directory, one 14-second model-less server start — so there was no reason not to make them first. Refs #1247 Refs waired-ai/waired#1312 Signed-off-by: gen16k <gen16k@users.noreply.github.com> * gateway, runtime: finish the two claims the pin bump narrowed in one copy each (#1193) #1235 narrowed convert.go's "ollama has no equivalent on any surface" and ollamaContextFloor's "the pinned engine's own default is 32768". Both statements existed in more than one place, and the other copies were left saying what the measurement had just disproved. The cached-token claim also lived in internal/gateway/handlers.go (setCachedInput: "every engine but vLLM with --enable-prompt-tokens-details") and in internal/observability/ eventring.go (CachedInputTokens: "only vLLM reports the breakdown"). Both now say when that stopped being true. This matters more than the wording: CachedInputTokens feeds waired_inference_cached_input_tokens_total, whose Help already says "Only engines that report a prompt-token breakdown move this" — so ollama hosts silently started moving a counter two comments said they could not. The untuned-default claim lived in internal/runtime/ollama.go and cmd/waired-agent/inference.go, both describing the #624 boot-order gap as costing "its 32k default". 0.33.3 derives that default from the VRAM it found instead — measured 32768 on a 37.4 GiB Mac and 262144 on a 102.2 GiB Strix Halo — so the window an untuned spawn takes on a large host is now far bigger than the sentence implies. The tuned path is unaffected, which is why nothing here changes behaviour; the gap's cost simply is not what it says. Found by tracing what the two narrowed claims actually feed, rather than by grep: the question "what would change for the product" is what turned up the counter and the untuned path. Refs #1235 Refs waired-ai/waired#1312 Signed-off-by: gen16k <gen16k@users.noreply.github.com> * docs(knowledges): the engine's default window reaches nothing — every consumer gates on ContextLength > 0 (#1193) ollama 0.33.3 derives its own default context from the VRAM it sees (32768 on the 37.4 GiB / 23.8 GiB hosts, 262144 on the 102.2 GiB Strix Halo). Record why that changed only comments: the tuned path never consults the engine default, the untuned path (#624 boot-order gap) is narrow, and all five readers of ModelTuning.ContextLength return nothing when it is 0, so an untuned engine advertises no window, produces no measurement, and triggers no verdict. What is not established — an untuned spawn that the larger default makes fail — is said so. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0167iiPnKQz1qcuz2bhNBGep Signed-off-by: gen16k <gen16k@users.noreply.github.com> * runtime: measure the Strix Halo backends properly, and keep Vulkan on numbers that survive the spread The owner rejected #1247's ROCm conclusion on two grounds, and both were right. Prior verification had concluded ROCm did not work on Windows, and a 102.2 GiB / 76.8 GiB difference in exposed memory looked wrong. Reading my own logs back, the evidence for "ROCm engages" was ollama's dispatch label and /api/ps — neither of them llama.cpp's accounting. The line I had quoted, `load_tensors: ROCm_Host model buffer size`, is a HOST buffer. The device line was never read. It is read now, with a CPU-only control obtained by moving both backends out of lib/ollama: ROCm load_tensors: ROCm0 model buffer size = 21171.18 MiB, GPU 453 % Vulkan load_tensors: Vulkan0 model buffer size = 21171.18 MiB, GPU 112 % CPU only size_vram 0, GPU 0 %, prefill 158.1, decode 19.33 So both really run on the GPU. The performance claim did not survive. #1247 measured one turn per backend at num_predict 64 — a 1.2-second decode window — and the same Vulkan configuration moved 22 % between sessions under it, which is twice the gap it claimed. On the owner's suggestion the measurement was sized up: 30-36k-token prompts, num_predict 512, the backends alternated inside each run, the cold turn after each load discarded, six samples each. prefill Vulkan 876.8 (839.4-912.6) ROCm 636.3 (580.0-654.1) decode Vulkan 49.2 ( 47.9- 50.1) ROCm 43.8 ( 43.1- 44.3) Neither range overlaps. Vulkan by 37.8 % and 12.3 %, and the decode spread fell to 2.7 % — that collapse is the whole reason the gap is readable. The conclusion #1247 reached survives; the numbers it reached it with do not, and are replaced. The history is corrected in the same pass. #1247 said the arm's "ROCm has no Windows APU support" stopped being true at 0.33.3. Reading the zip central directory for five releases shows gfx1151 in the overlay back to v0.12.6, and starting v0.31.1 and v0.33.2 on the host shows both discovering ROCm exactly as 0.33.3 does. What DID change is upstream of that: the 2026-05 survey (waired's own records) found the overlay was `lib/ollama/rocm` at ROCm v6.1 and AMD documenting Ryzen AI APUs as excluded, so the claim was written against a real state of the world and the stamp went stale rather than the claim being careless. Also finishes two claims #1235 narrowed in one copy each: the cached-token comments in handlers.go and eventring.go, and the untuned-default comments in ollama.go and inference.go. The knowledge note on the second records why that one is contained — every consumer gates on ContextLength > 0, so the engine's own default reaches no advertisement, no measurement and no verdict. Refs #1247 Refs #1235 Refs waired-ai/waired#1312 Signed-off-by: gen16k <gen16k@users.noreply.github.com> * runtime: the Strix Halo arm names Vulkan for correctness, and the next bump knows what to re-read (#1233) Two facts arrived after the performance re-measurement, and they change which sentence the arm should lead with. ROCm on gfx1151 has open upstream defects that a coding agent meets on every request. ollama/ollama#17895 has it returning wrong output above ~4k prompt tokens — "fluent, confident, wrong answers" with nothing logged, and past ~8k byte-identical replies to different prompts — reproduced across 0.32.5 to 0.32.14, on Debian and Windows, on three model families, with the bundled rocm_v7_2. ollama/ollama#17847 has it bleeding KV state between sequential requests at OLLAMA_NUM_PARALLEL=1. Both report the same machine clean on Vulkan and on CPU. Vulkan has one of its own, #17870, and the difference in kind is what decides this: it FAILS the request where ROCm answers wrongly, and a wrong answer with no error is caught by nothing this repository runs. So speed becomes the lesser reason and is labelled as what it is — a measurement of ollama's own bundled ROCm, which is a stock HIP build. Tuned gfx1151 builds exist and report the prefill split going the other way, so the figures here are a fact about the engine we ship rather than about ROCm. The rest is a standing checklist rather than a proposal. The MAINTENANCE block gains the four upstream threads and the ROCm 7.2.4 question, with the warning that 7.2.4 answers performance and not correctness — #17895 already reproduces on 7.2 — so the two must not be read as one. The new knowledge note carries the background a bump needs to interpret what it finds: which overrides are bug workarounds and which are preferences, why amdROCmSupportedRes is a download decision that Linux answers without a list, what the list actually matches when run against real SKU strings, why it cannot be derived from the overlay while hardware.GPU carries no gfx target, and the method — including the three harness traps that cost this investigation two false conclusions before it produced a true one. Nothing is recommended and nothing changes: the arm still names Vulkan, and it now says why in terms that expire when the upstream threads do. Refs #1247 Refs #1248 Refs waired-ai/waired#1312 Signed-off-by: gen16k <gen16k@users.noreply.github.com> --------- Signed-off-by: gen16k <gen16k@users.noreply.github.com> Co-authored-by: gen16k <gen16k@users.noreply.github.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
gen16k
added a commit
that referenced
this pull request
Sep 6, 2026
The entry the pin move in #1235 existed for. Measured end to end on sv-evox2 (Ryzen AI Max+ 395, 127 GB unified) against the pinned 0.33.3: 12 trials of the agent-harness grade pass, and all six request shapes are accepted. The tag as published accepts only three of those six. Its config carries no renderer, so ollama renders prompts with the GGUF's embedded Jinja, which raises "System message must be at the beginning." on the three shapes a coding agent actually sends. Reading the config blob of all 24 GGUF tags carrying this model, across six namespaces, not one declares a renderer — the safetensors convert path stamps it automatically and the GGUF create path does not, so this is a property of the packaging route rather than one publisher's oversight. The manifest therefore names the renderer and the pull path stamps it onto the local copy. `ollama create` on the same tag reuses every layer, so it costs 0.00 GB and keeps the projector and the license blob; only the small config object is rewritten, and every identifier downstream stays what it was. With it, the three refused shapes answer 200 with nothing else changed. This is what ollama does for the same model: its own library tag declares renderer qwen3.8 / parser qwen3.5, and that renderer ships in the pin — normalizeQwen38Messages folds every system and developer turn into one leading system turn, the same operation the gateway does, with no branch inside it that can refuse a shape. No engine bump was needed; v0.34.0-rc1 registers exactly the same renderers as 0.33.3. Decision 20260828/1930 is untouched. A model that cannot render the shapes a coding agent sends is still one this project does not offer; this one renders them, so the gate is passed rather than exempted. Also here: - qwen3.5-122b-a10b drops to manual_only. Same generation swap as #823: the replacement is lighter on the same hosts (55.1 GB resident against 81.0) and graded on real hardware rather than inherited. - The shapes store records the renderer a measurement was taken under and compares it against the manifest, because VariantSHA cannot: that payload is frozen, so a manifest that quietly drops its renderer keeps the same SHA and the old record would go on claiming shapes the engine would now refuse. - The sources guard from #1240 accepts a manifest-supplied renderer. It was written when the only fix was a different tag; that is no longer true, and it now says which of the two is missing. - The quant ladder gains Q2_K, Q3_K_M and UD-Q2_K_XL. The UD row's bpw is measured, not modelled — dynamic quants have no a-priori table value, and folding one onto plain Q2_K under-estimates its weights by a quarter. - Two hostfit tests asserted on capacity-plus-roofline where they meant the recommendation gate. A 180B-A6B entry separates the two for the first time — 55 GB of weights against a 24 GB card, but only 6B read per token — so they now assert both sides. The default on those hosts does not move; `weights_spill` still holds it. - catalog-radar's licence rule said the catalog carries only Apache-2.0 and MIT. It now carries one Qwen Community License 1.0 entry, so the rule says what it actually is: the bar for what the radar may propose, not a precedent to follow. waired-agent#1255 carries the KV modelling gap this measurement found: the engine allocates a second, asymmetric KV cache the derivation has no term for, so the annotation under-counts real KV by 38%. Fixes #1192 Refs waired-ai/waired#1312 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0167iiPnKQz1qcuz2bhNBGep Signed-off-by: gen16k <gen16k@users.noreply.github.com>
gen16k
added a commit
that referenced
this pull request
Sep 6, 2026
The entry the pin move in #1235 existed for. Measured end to end on sv-evox2 (Ryzen AI Max+ 395, 127 GB unified) against the pinned 0.33.3: 12 trials of the agent-harness grade pass, and all six request shapes are accepted. The tag as published accepts only three of those six. Its config carries no renderer, so ollama renders prompts with the GGUF's embedded Jinja, which raises "System message must be at the beginning." on the three shapes a coding agent actually sends. Reading the config blob of all 24 GGUF tags carrying this model, across six namespaces, not one declares a renderer — the safetensors convert path stamps it automatically and the GGUF create path does not, so this is a property of the packaging route rather than one publisher's oversight. The manifest therefore names the renderer and the pull path stamps it onto the local copy. `ollama create` on the same tag reuses every layer, so it costs 0.00 GB and keeps the projector and the license blob; only the small config object is rewritten, and every identifier downstream stays what it was. With it, the three refused shapes answer 200 with nothing else changed. This is what ollama does for the same model: its own library tag declares renderer qwen3.8 / parser qwen3.5, and that renderer ships in the pin — normalizeQwen38Messages folds every system and developer turn into one leading system turn, the same operation the gateway does, with no branch inside it that can refuse a shape. No engine bump was needed; v0.34.0-rc1 registers exactly the same renderers as 0.33.3. Decision 20260828/1930 is untouched. A model that cannot render the shapes a coding agent sends is still one this project does not offer; this one renders them, so the gate is passed rather than exempted. Also here: - qwen3.5-122b-a10b drops to manual_only. Same generation swap as #823: the replacement is lighter on the same hosts (55.1 GB resident against 81.0) and graded on real hardware rather than inherited. - The shapes store records the renderer a measurement was taken under and compares it against the manifest, because VariantSHA cannot: that payload is frozen, so a manifest that quietly drops its renderer keeps the same SHA and the old record would go on claiming shapes the engine would now refuse. - The sources guard from #1240 accepts a manifest-supplied renderer. It was written when the only fix was a different tag; that is no longer true, and it now says which of the two is missing. - The quant ladder gains Q2_K, Q3_K_M and UD-Q2_K_XL. The UD row's bpw is measured, not modelled — dynamic quants have no a-priori table value, and folding one onto plain Q2_K under-estimates its weights by a quarter. - Two hostfit tests asserted on capacity-plus-roofline where they meant the recommendation gate. A 180B-A6B entry separates the two for the first time — 55 GB of weights against a 24 GB card, but only 6B read per token — so they now assert both sides. The default on those hosts does not move; `weights_spill` still holds it. - catalog-radar's licence rule said the catalog carries only Apache-2.0 and MIT. It now carries one Qwen Community License 1.0 entry, so the rule says what it actually is: the bar for what the radar may propose, not a precedent to follow. waired-agent#1255 carries the KV modelling gap this measurement found: the engine allocates a second, asymmetric KV cache the derivation has no term for, so the annotation under-counts real KV by 38%. Fixes #1192 Refs waired-ai/waired#1312 Claude-Session: https://claude.ai/code/session_0167iiPnKQz1qcuz2bhNBGep Signed-off-by: gen16k <gen16k@users.noreply.github.com> Co-authored-by: gen16k <gen16k@users.noreply.github.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
OllamaPinnedVersion0.33.2 → 0.33.3.#1193 は「v0.33.3 が stable になるまで blocked」として起票されていましたが、GitHub の release API は v0.33.3 を
prerelease=false・公開 2026-09-02 と報告します。その日以降、実際には何も塞いでいませんでした。本文冒頭の Blocked 注記は取り消し済みです。なぜ動かすか — アーキテクチャであって、キャッシュではない
同梱の llama.cpp が b10630 → b10760。
qwen4expは b10666 で入った(ggml-org/llama.cpp#27742)ので、これは llama.cpp runner が Qwen3.8-Flash-Next ファミリーをそもそもロードできる最初の pin 版です。#1192 のカタログエントリがmin_engine_version: 0.33.3を名乗るには、TestBundledEngineFloorsNeverExceedThePinが床 ≤ pin を要求するので、pin が先に動いている必要があります。だからこの PR が先で、#1192 は proto/ に触る別 PR です(CLAUDE.md §Modules)。測ったもの(#1132 の一覧)
3 OS。Linux 脚は sv-mag ではありません — 作業時間中ずっと別レーンが確保していたので、開発機(WSL2、RTX 5080 + RTX 5070 Laptop)で採りました。前回の RTX PRO 4000 とは別のカードです。記録には正直にそう書いてあります。
sha256sum.txtTestPinnedReleasePublishesEveryAssetChecksumが実リリースに対して緑(6 アセット)mlx_metal_v3/v4、windows は root にollama.exe+lib/(lib/ollama/は cuda_v12/cuda_v13/vulkan で rocm は無い =amdROCmSupportedの前提)、linux はbin/+lib//v1/api/chatとも 200・実 bodyprompt_eval_countraw vs foldedkeep_aliveの非対称(#908)/v1の 37m は既定(+5 分)のまま、/api/chatの 41m はexpires_atを +41 分へ。健在/api/ps/ engine.logmsg="..."-np(#763)-b 1024、27B は-b 512)測定がコメントを偽にした 3 か所 — 挙動でなくコメントを狭めた
0.33.2 の bump が
convert.goの主張を狭めた先例に倣っています。internal/gateway/convert.go: 「ollama has no equivalent on any surface … a cache hit and a full prefill report the same number there」は 0.33.3 で偽。フラグ無しで/v1のprompt_tokens_details.cached_tokensと/api/chatのprompt_eval_cached_countを返します。定数ではなく実数で、同一プロンプトの 2 回目が 610 トークン中 606 cached(1 回目は 0)。OpenAIUsage.CachedPromptTokensが ollama 経路でも実際の再利用量を返し始め、rr.setCachedInputに流れます。コードは無変更。注意して使うこと: ヒット直後のプロンプトに追記した 3 回目は cached_tokens 0 を返しました。再利用の深さの尺度としてはまだ使えません(gateway: the sticky conversation id merges different sessions and splits one, so KV affinity binds the wrong turns #1125 / inference: measure the served model's prefill rate, publish it, and learn one from real turns #1127)。
cmd/waired-agent/inference_ollama_tuning.go: 「pin 版エンジン自身の既定は 32768」は、0.33.3 ではホスト依存になりました(vram-based default context: 37.4 GiB の Mac で 32768、102.2 GiB の Strix Halo で 262144)。定数の値は無関係(agent が常にOLLAMA_CONTEXT_LENGTHを export するため)なので、doc だけを「範囲の一端」を指す文に狭めています。internal/runtime/ollama_backend.go:amdROCmSupportedResのコメントが指すscripts/install/ollama-windows.ps1は installer/windows: move the bundled Ollama install under the state dir; pin from the Go const #493 で削除済みでした。つまり「keep in sync with」は存在しないファイルを名指しし、そこにあるはずの bump ごとの点検手順はどこにも無かったことになります。手順をリストの隣に移し、「release notes ではなく overlay を読め」と書きました。挙動を変えなかったもの → #1233
Windows の ROCm overlay は
rocm_v7_1(コメントの刻印は v6.1)で、rocBLAS カーネルは gfx906/1030/1100/1101/1102/1150/1151/1200/1201 — Strix Halo と RDNA4 が入りました。upstream の Windows 対応表は逆に成果物より狭い(RX 7900〜7600 と PRO W7900〜W7500 のみ)。私たちの allowlist・upstream の docs・overlay の中身の 3 者が食い違っています。regex も Strix Halo 分岐も変えていません。今のギャップは 2 つとも安全側に落ちる(Vulkan で終わり、Vulkan は動く)し、ファイル一覧を根拠にホストの優先 backend を変えるのは、同じ関数の Linux 分岐が probe することで取らずにいる「成果物から挙動を推論する」一歩だからです。測定は #1233。
その他
reference/cli.md+ ja、troubleshooting.md+ ja、getting-started/doctor.mdx+ ja)。troubleshooting と doctor は 0.32.15 / 0.33.2 で止まっていたので同じ手で揃えました。"0.33.2"リテラル(ベンチキャッシュ系ほか)。定数を import していないので、放置すると製品がもう pin していない版を記述し続けます。EngineVersionでキーされる(inference: the benchmark cache does not key on the engine version, so an engine upgrade keeps the old measurements #1131)ので、全ホストが一度ミスして測り直します。旧エンジンの値なので、それが正しい結果です。docs/decisions/20260906/0230-move-the-ollama-pin-to-0333.md/docs/knowledges/20260906/0230-ollama-pin-0333.mdFixes #1193
Refs #1192
Refs #1233
Refs waired-ai/waired#1312
🤖 Generated with Claude Code
https://claude.ai/code/session_0167iiPnKQz1qcuz2bhNBGep