chore: extract MTP benchmark tooling from #109 - #151
Merged
Conversation
#109 bundled a sliding-window KV cap, a Gemma4-specific MTP-assistant auto-resolution path, and this benchmark tooling into one PR. The first two are not part of this extraction: - the KV cap was independently ported and evaluated earlier this session — no measurable benefit at 150 tokens or ~9k context, parked - the auto-resolution wiring (Gemma4MTPRegistry, mtpAsstRef reusing the draft-model path) duplicates what #137 already shipped more generally as the explicit --mtp-assistant-model flag; rebasing it forward would reintroduce a second, narrower implementation of a feature that already exists on main This PR is only the tooling, and it rebases clean because it is genuinely orthogonal: mtp_bench.py drives the server with --mtp --num-mtp-tokens N --turbo-kv, the single-checkpoint MTP path, not the Gemma4 dual-model wiring in conflict. Verified none of these three files reference Gemma4MTPRegistry, mtp-assistant-model, or anything else from the withheld part of #109. run_benchmark.sh's Test 13 previously shelled out to `swift run Gemma4MTPBench`, a product that no longer exists in Package.swift — that path was already broken on main before this PR. It now drives mtp_bench.py against the regular SwiftLM binary instead. README's benchmark numbers (Gemma4 26B, 4-bit and 8-bit) are carried over from the original PR's measurements, not reproduced in this extraction — a 40K/100K context benchmark run is multi-hour. The 8-bit table matches data already used as reference in mlx-swift-lm#46 and the #137 comment thread earlier this session, so it is not new to this repo's history, just newly landing in the README. Verified: run_benchmark.sh syntax checked, mtp_bench.py compiles and its --help output parses correctly; confirmed --mtp, --num-mtp-tokens and --turbo-kv all already exist on main independent of --mtp-assistant-model. Refs #109 Co-Authored-By: Claude Opus 5 <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
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.
#109 bundled three unrelated things: a sliding-window KV cap, a Gemma4-specific MTP-assistant auto-resolution wiring, and this benchmark tooling. Only the tooling comes forward here.
Why not the rest of #109
Why this part rebases clean
`mtp_bench.py` drives the server with `--mtp --num-mtp-tokens N --turbo-kv` — the single-checkpoint MTP path, not the Gemma4 dual-model wiring that's in conflict. Verified none of these three files reference `Gemma4MTPRegistry`, `--mtp-assistant-model`, or anything else from the withheld part of #109. All three flags it uses already exist on main independently of that wiring.
`run_benchmark.sh`'s Test 13 previously shelled out to `swift run Gemma4MTPBench` — that product no longer exists in `Package.swift`, so the path was already broken on main before this PR. It now drives `mtp_bench.py` against the regular `SwiftLM` binary.
On the README numbers
Carried over from the original PR's measurements, not reproduced in this extraction — a 40K/100K context run is multi-hour. The 8-bit table matches data already used as reference in mlx-swift-lm#46 and the #137 comment thread earlier this session, so it isn't new to this repo's history, just newly landing in the README.
Verification
Refs #109
🤖 Generated with Claude Code