Skip to content

serve: completion timings no longer report wall tok/s as decode tok/s - #807

Open
ghazni101 wants to merge 12 commits into
warpfront:betafrom
ghazni101:fix/serve-decode-tok-s
Open

ghazni101 wants to merge 12 commits into
warpfront:betafrom
ghazni101:fix/serve-decode-tok-s

Conversation

@ghazni101

Copy link
Copy Markdown
Contributor

Summary

completion_timings no longer falls back to the wall-inclusive tok_s when decode_tok_s is absent.

Which surface(s) does this touch?

  • serve — crates/hipfire-cli/src/serve (gateway)

Problem

The slots route reports only decode_tok_s, so the .or_else(tok_s) fallback only ever fired on routes that lacked it — and there it surfaced the prefill-inclusive wall rate AS the decode rate (~3× low measured on gfx1101 multi-slot). Clients wanting the wall number still get it under hipfire.tok_s.

Test plan

  • cargo test -p hipfire-cli — 304/304; completion_timings_* tests pass
  • scripts/check-crate-maps.py --check, scripts/leanup-ratchets.sh green

One-liner + comment; extracted from feat/serve-chat-ui-v040 (commit 4b8c1dc).

@ghazni101 ghazni101 mentioned this pull request Oct 2, 2026
6 of 8 tasks
@ghazni101
ghazni101 force-pushed the fix/serve-decode-tok-s branch from a2419cd to 0bf9a8e Compare October 2, 2026 21:56
@ghazni101

Copy link
Copy Markdown
Contributor Author

Empirical evidence (gfx1101, ROCm/HIP 7.15 container, qwen3.5-4b.mq4):

Multi-slot route (daemon reports only tok_s):

before (master/806-shape): timings.decode_tok_s = 100.1  == hipfire.tok_s (wall)
after  (this branch):      timings.decode_tok_s = null  | hipfire.tok_s = 59.8 preserved

Standard route (daemon reports real decode_tok_s) — unchanged:

timings.decode_tok_s = 11.1  vs  hipfire.tok_s = 3.8   (passthrough intact)

serve_harness.py battery on this build: 5/5 turns, finish=stop, 0 runaway/empty/attractor (battery-807.json). The earlier CI flake (serve_respawns_a_daemon_that_exited) was a timing race — same test passed 6/6 locally and the re-run is green.

Bjoern Agent added 3 commits October 3, 2026 08:39
`(b >> 2j) & 0x3 <= 3` is always true; clippy's deny-level bad_bit_mask
stopped `cargo clippy --all-targets` at hipfire-quantize. Pin the block
geometry instead.
The no-GPU CI runner has no /opt/rocm/core-10.0, so peacemaker-ir's codec
gates panicked in the lib-test step and 14 hipfire-isa integration tests
in the GPU-free step. Follow the existing table-gate convention: skip with
a log line when llvm-mc is absent; the gates still run where it exists.
clippy's deny-by-default mut_from_ref stopped `cargo clippy --all-targets`
at hipfire-xdna once hipfire-quantize compiled. Bo is a cloneable handle to
one shared mapping, so &mut self would not prevent aliasing; exclusivity is
the documented caller contract. Same fix as a1ac7f4 on
feat/qwen38-flash-next.
@ghazni101 ghazni101 closed this Oct 3, 2026
@ghazni101
ghazni101 deleted the fix/serve-decode-tok-s branch October 3, 2026 08:53
@ghazni101
ghazni101 restored the fix/serve-decode-tok-s branch October 3, 2026 13:42
@ghazni101 ghazni101 reopened this Oct 3, 2026
@ghazni101
ghazni101 changed the base branch from master to beta October 3, 2026 13:45
completion_timings fell back from decode_tok_s to the wall-inclusive
tok_s when the former was absent. The slots route reports only
decode_tok_s, so the fallback only ever fired there — and on AR/noslots
requests it surfaced the prefill-inclusive wall rate AS the decode rate
(~3x low on gfx1101 multi-slot). Clients that want the wall number still
get it under hipfire.tok_s.
Bjoern Agent and others added 6 commits October 3, 2026 15:59
`(b >> 2j) & 0x3 <= 3` is always true; clippy's deny-level bad_bit_mask
stopped `cargo clippy --all-targets` at hipfire-quantize. Pin the block
geometry instead.
The no-GPU CI runner has no /opt/rocm/core-10.0, so peacemaker-ir's codec
gates panicked in the lib-test step and 15 hipfire-isa integration tests
in the GPU-free step. Follow the existing table-gate convention: skip with
a log line when llvm-mc is absent; the gates still run where it exists.
clippy's deny-by-default mut_from_ref stopped `cargo clippy --all-targets`
at hipfire-xdna once hipfire-quantize compiled. Bo is a cloneable handle to
one shared mapping, so &mut self would not prevent aliasing; exclusivity is
the documented caller contract. Same fix as a1ac7f4 on
feat/qwen38-flash-next.
…ad lifecycle

a31e438 (land/041t) grew crates/hipfire-daemon/src/main.rs to 5392 lines
without moving the ceiling, so beta's own gates job fails. The 15 lines are
no_model_loaded_suffix (an admitted single-device/pp load failure now says
the prior model is gone) and its unit test.

RATCHET-RAISE: daemon_lines 5377 -> 5392, traded for the Flash-Next unload-first load lifecycle (a31e438) that fixes the FN<->VMM swap refusal and names the missing model on admitted-load failure
…ilure suffix helper out of main.rs

land/041t + land/041u grew daemon main.rs to 5392 against the 5377
ceiling, leaving beta's own gates job red for every branch based on its
head. Raising the ceiling needs the maintainer-only 'ratchet-raise'
label, so pay the debt instead: no_model_loaded_suffix and its test
move to request_guards (the module whose charter is exactly 'small
load/generate message helpers kept out of main.rs'), semantics
untouched — main.rs lands at 5372. Also refreshes the stale crate maps
(engine/generate/quantize/cli/config/daemon).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant