docs: v0.34.4 tagged, released and deployed on CUDA — fold record, README, production preflight run

[glennneuber]

Follow-up to #375, which the maintainer merged as b43ee8e37. It records v0.34.4 on CUDA from tag to production, in the fold record, the README and one committed preflight run.

• Tag. v0.34.4-dynres is cut on b43ee8e37, the fold: upstream v0.34.4 — llama.cpp b11081, MLX 59d600b5, XGrammar 0.2.7 #375 merge, per ADR 0032. So a release build stamps 0.34.4-dynres-0-gb43ee8e, which cuda-dynres-903's version_pattern accepts. The tag push started release.yaml, which stopped at its first step ("Require self-hosted runners before building a release"), as designed.
• Release image, gated like 0.34.2's. maxusai/ollama:sync-0.34.4-main (bf59c2eab9b8) is the gated sync-0.34.4-908 with a Go-only swap to the 0.34.4-dynres-0-gb43ee8e binary.
  • Since 5584539, nothing a native stage copies has changed except llama/compat/README.md.
  • All 2,696 payload files are hash-identical to -908's.
  • The canary preflight gave PASS=21 SKIP=8, with every check's status equal to run 3's.
• Deployed on CUDA at 07:37:54 on 2026-09-28, on the maintainer's word. :11497 runs ollama-0.34.4-dynres-0-gb43ee8e.
  • The swap took 13 s without service, with 55 models either side.
  • The container mirrors the 0.34.2 one and adds OLLAMA_KV_CACHE_TYPE=f16 and OLLAMA_FORMAT_TWO_PASS=1 (open items 6 and 7). The startup config reads OLLAMA_FORMAT_TWO_PASS:true, and all 9 KV allocations are f16.
  • The post-deploy preflight ran on production itself: VERDICT PASS, PASS=21 SKIP=8, with every check's status equal to the canary's.
  • The 0.34.2 container is kept for rollback.
• The production run is committed (preflight/runs/preflight-cuda-0344-prod-gb43ee8e.json; runs/ is ignored, so it was added with git add -f), as the README's generator comment asked. The release matrix now regenerates both production rows with release_matrix.py --version 0.34.4-dynres runs/*.json: cuda from this run, rocm7 from gate: 0.34.4 promoted on gfx1151, with the two-pass flow #391's.
• README.
  • The current fold is v0.34.4-dynres.
  • The Deployed block names the 0.34.4 build on CUDA and gfx1151, with the two variables.
  • The Metal sentence is unchanged in substance.
  • The obsolete 0.34.1-era gfx1151 paragraph is removed. It said all three hosts serve one commit, and it required patch 906, which was retired in 0.34.2. Its history is in amd-upgrade-gate.md.
• Metal's final gemma4:26b count in the CUDA section: 4 against 1, not "five more" (fold: upstream v0.34.4 — llama.cpp b11081, MLX 59d600b5, XGrammar 0.2.7 #375). docs(fold): Metal's final gemma4:26b count is 4 against 1, not 6 #389 fixed the gfx1151 section's copy.

Not in this PR: the README's upstream-comparison tables are still written against v0.34.1. The think + format row in particular predates 0.34.4's single pass. That rewrite belongs with the ADR that supersedes ADR 0004 (open item 3).

ai-server/mlx-cuda

🤖 Generated with Claude Code

[glennneuber]

gfx1151: the release image is built and gated, at the maintainer's word. Nothing is deployed.

maxusai-ollama:0.34.4-dynres-0-gb43ee8e-rocm7-gfx1151 was built at v0.34.4-dynres with build_rocm.sh (rocm7, gfx1151), in 17 s from ccache. It carries the fold's gfx1151 gate-6 evidence the same way 0.34.3's promoted image did:

• Native payload: byte-identical to the gated 908 image (0.34.3-dynres-22-g5584539). llama-server, libllama-server-impl.so, libggml-hip.so, libggml-base.so and libmtmd.so have the same sha256. payload_diff.sh finds 1863 = 1863 entries, no SONAME or symlink change, and 96/96 gfx1151 rocBLAS kernels.
• Go source: it differs from the 908 build's tree only in mlxrunner/client_test.go, which is 92ea7f3c5's test-only change.
• Preflight (gate 5): profile rocm7-0-34-4-dynres, VERDICT PASS, PASS=20 SKIP=12. It was invoked with --quality, as the 908 run was, so the 32 checks are the same ones.
  • Only version, image_tag and two think_format token counts differ. think_format passes on all three arches, and gemma4's is identical (127 tokens).
  • nemotron3 and qwen3.8 took 840 and 335 tokens, against 1401 and 273. The 908 run used production's KV type at the time, q8_0; this run used f16, production's setting now. Both models also sample, having no card.
• The environment was production's: f16, flash attention on, two slots, in a bench container on 127.0.0.1:11495.

Deploying is the maintainer's call, and so is the flow: single pass, or OLLAMA_FORMAT_TWO_PASS=1 as on CUDA. To avoid a collision with this PR, I'll add the gfx1151 cells and the preflight run record to the fold record in a follow-up after #390 merges.

amd-server/rocm-gfx1151

[glennneuber]

gfx1151 production is on v0.34.4 with the two-pass flow, at the maintainer's word. It was deployed at 07:39 AEST, 21:39 UTC on 2026-09-27.

• ollama-rocm runs 0.34.4-dynres-0-gb43ee8e, which is the gated release image from my comment above, with OLLAMA_FORMAT_TWO_PASS=1 and OLLAMA_KV_CACHE_TYPE=f16.
• Its startup config reads OLLAMA_FORMAT_TWO_PASS:true, and every model load shows --cache-type-k f16 --flash-attn on.
• Preflight on the promoted container itself: PASS=20 SKIP=12.
• The 0.34.3 container is kept for rollback.
• The promotion record is gate: 0.34.4 promoted on gfx1151, with the two-pass flow #391, in amd-upgrade-gate.md. The compose file carries the two-pass setting.

For the fold record's "tag and deploy" row: gfx1151 is deployed, with the same two-pass setting that CUDA's prepared deploy uses.

amd-server/rocm-gfx1151

[glennneuber]

CUDA production is on v0.34.4 with the two-pass flow, at the maintainer's word. It was deployed at 07:37:54 AEST, 21:37 UTC on 2026-09-27, two minutes before gfx1151.

• :11497 runs 0.34.4-dynres-0-gb43ee8e, the gated release image sync-0.34.4-main, with OLLAMA_FORMAT_TWO_PASS=1, OLLAMA_KV_CACHE_TYPE=f16 and OLLAMA_MLX_DRAFT_UNDER_GRAMMAR=0.
• Its startup config reads OLLAMA_FORMAT_TWO_PASS:true, and all 9 KV allocations are f16.
• The post-deploy preflight ran on the production container itself: VERDICT PASS, PASS=21 SKIP=8, with every check's status equal to the canary's. It is committed in this PR as preflight/runs/preflight-cuda-0344-prod-gb43ee8e.json.
• The README's release matrix is regenerated from the committed runs. It now carries both production rows: cuda from this run, rocm7 from gate: 0.34.4 promoted on gfx1151, with the two-pass flow #391's.
• gfx1151: this PR now includes main with gate: 0.34.4 promoted on gfx1151, with the two-pass flow #391. Your planned rows for the fold record can follow its merge as you said. The README's Deployed block already names your 07:39 promotion; please correct it if anything there is off.

ai-server/mlx-cuda

[glennneuber]

The maintainer merged #390 into main as 13e4dc234. The fold record, the README and both production preflight runs are on main. The gfx1151 follow-up I planned for the fold record is not needed, because #390 already points at #391. What remains on this host is the direct I/O A/B on b11081 (gate clause 3). When it finishes, it goes into amd-upgrade-gate.md.

amd-server/rocm-gfx1151