[bong-water-water-bong]

Refs #2143. Docs only. This corrects the blockquote #2162 added to docs/determinism.md and docs/zyphra.md.

Why

#2162 tells readers that GGML_HRX_LOG_DISPATCH=1 is "a different code path". The fork at the engine's pin (7a1f2b81ce17) does not show that:

• Every reader of the flag outside *.md is one of the two print functions in dispatch-registry.cpp: dispatch_log_match() and dispatch_log_requested_output(). Both do if (!enabled) return; and then only fprintf.
• The readback check and its decline (first_covered_requested_output() → continue) run on every match whether the flag is set or not, so the dispatches selected are the same in both arms.
• The HRX runtime and engine main do not read the flag.

The details are in #2143 (issuecomment-6790571172).

The measurements #2162 quotes cannot carry the claim either:

• The fail/complete pair and the 2-vs-0 NaN count are one run per arm. hrx: intermittent all-NaN logits at n_slots=1 and 18.8k context on the pin that carries #227 (count=248320 of 248320, 4 sightings in 6 long-context runs) #1536 failed 4 of 6 times, so a 1-1 split happens by chance about one time in three.
• The 271.75 vs 118.86 t/s pair is one pair with box load not recorded, and load alone moves a rate by about 2× on this box (tools: npu_serve_smoke prints the box's load, and names a busy box when only the timing failed (Refs #2106) #2140).
• hrx: intermittent all-NaN logits at n_slots=1 and 18.8k context on the pin that carries #227 (count=248320 of 248320, 4 sightings in 6 long-context runs) #1536 was closed (08:17Z) on 6 of 6 clean runs taken with the flag set, which is only valid if the flag is neutral.

What changed

Both blockquotes now say what the source shows and give the advice that holds whichever way #2143 settles: set the flag in both arms of an A/B, and record box load beside any rate.

Also:

• In docs/zyphra.md the blockquote is indented into its list item. At column 0 it ended the list.
• The two blank lines docs: GGML_HRX_LOG_DISPATCH changes behaviour, so say it where the pages teach the instrument (#2143) #2162 added (after the width table in determinism.md, before the indented table in zyphra.md) are removed.

Diff: 2 files, +14/−10, docs only. Not run: the unset-arm GPU check #2143 proposes. This changes no claim about measured behaviour, only removes one that nobody has shown.

🤖 Generated with Claude Code

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 2143 - Partially compliant Compliant requirements: Corrected the documentation to reflect that GGML_HRX_LOG_DISPATCH=1 is behavior-neutral Updated blockquotes in docs/determinism.md and docs/zyphra.md to accurately describe the flag's behavior Provided advice to set the flag in both arms of an A/B test Included the recommendation to record box load beside any rate Non-compliant requirements: None Requires further human verification: None 1536 - Partially compliant Compliant requirements: The PR does not directly address the intermittent NaN logits issue The PR does not directly investigate the root cause of the intermittent failures Non-compliant requirements: The PR does not directly address the intermittent NaN logits issue The PR does not directly investigate the root cause of the intermittent failures Requires further human verification: The PR does not directly address the intermittent NaN logits issue, which is a release blocker The root cause of the intermittent failures needs further investigation 1051 - Partially compliant Compliant requirements: The PR does not directly address the NPU hang issue The PR does not directly address the TDR recovery issue Non-compliant requirements: The PR does not directly address the NPU hang issue The PR does not directly address the TDR recovery issue Requires further human verification: The PR does not directly address the NPU hang issue, which is a release blocker The TDR recovery issue needs further investigation

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Documentation Inaccuracy The documentation previously claimed that GGML_HRX_LOG_DISPATCH=1 was not behavior-neutral, which contradicts the actual implementation where the flag only affects logging output and does not change dispatch selection or behavior. This has been corrected to accurately reflect that the flag is behavior-neutral. > **Set it in both arms of an A/B, and record box load beside any rate (engine#2143).** #2143 asked whether this > flag changes behaviour: one 18,782-token request failed without it and completed with it, and one 18.6k prefill > measured 271.75 t/s unset against 118.86 t/s set. At the engine's pin the flag only gates `fprintf` calls > (`dispatch_log_match()` and `dispatch_log_requested_output()` in `dispatch-registry.cpp`): the readback check and > its decline run in both arms, so the dispatches selected are the same either way. Each of those measurements is > one run per arm, #1536 then failed in 4 of 6 runs, and box load moves a rate by about 2x here, so neither shows > a flag effect. Setting it in both arms is right whichever way #2143 settles. Documentation Inaccuracy The documentation previously claimed that GGML_HRX_LOG_DISPATCH=1 was not behavior-neutral, which contradicts the actual implementation where the flag only affects logging output and does not change dispatch selection or behavior. This has been corrected to accurately reflect that the flag is behavior-neutral. > **Set it in both arms of an A/B, and record box load beside any rate (engine#2143).** #2143 asked whether this > flag changes behaviour: one 18,782-token request failed without it and completed with it, and one 18.6k prefill > measured 271.75 t/s unset against 118.86 t/s set. At the engine's pin the flag only gates `fprintf` calls > (`dispatch_log_match()` and `dispatch_log_requested_output()` in `dispatch-registry.cpp`): the readback check and > its decline run in both arms, so the dispatches selected are the same either way. Each of those measurements is > one run per arm, #1536 then failed in 4 of 6 runs, and box load moves a rate by about 2x here, so neither shows > a flag effect. Setting it in both arms is right whichever way #2143 settles.

[bong-water-water-bong]

VERDICT at 24912bb: READY

Reviewed head 24912bb (refs #2143). Docs only: docs/determinism.md and docs/zyphra.md, +14/−10. This is the first verdict.

• The source claim holds at the engine's current pin, 204493d40, not only at the 7a1f2b81ce17 the body cites. git grep GGML_HRX_LOG_DISPATCH outside *.md finds dispatch-registry.cpp:138 (dispatch_log_requested_output) and :161 (dispatch_log_match), plus a comment in dispatch-mul-mat.cpp. Both functions return when the flag is unset, and otherwise only fprintf under a mutex, throttled. Their call sites (:261, :278) sit on paths the matcher takes either way: first_covered_requested_output() → continue, and fusion_order_accepts(). So "the dispatches selected are the same either way" is what the code says.
• The advice survives either outcome of #2143: set the flag in both arms, and record load beside a rate.
• The markdown fixes are right. The zyphra.md blockquote is now indented into its list item (at column 0 it ended the list), and the two stray blank lines are gone.
• git merge-tree onto main: no conflicts. CI build succeeded (waited for it before posting).

I posted a correction on #2162: my READY there checked its figures against #2143, but not the "different code path" claim against the source.