lift: bump vllm-tt-plugin through #126 (+#119) for Qwen warmup/coherence #36
Labels
No labels
human-approved
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
bitpartner/tt-stack#36
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Goal
Unblock correct Qwen3.6/3.8 serving under batching by moving vllm-tt-plugin past merged #126.
Context
c127c17d(2026-08-14) is ~31 commits behind plugin main tip (~2026-09-17).743890db…merged 2026-09-11) — verify on localtrymerge/ orchestra tree, not via GitHub pin SHA alone.Acceptance
vllm-tt-pluginto a SHA that includes #126 (prefer also #119 interleave)Risk
Pin bump invalidates prior equiv refs; coordinate with metal pin policy.
Refs
Prerequisite check result as of 2026-09-19:
Prerequisite Status: BLOCKED on tt-metal ancestry
Confirm #55343 ancestry in local metal source./home/orchestra/ttm-build/src:flake.lock:76983d00734dc9ab3b07cbe57f4dba2854472ef5#55343commit:743890db568bd3ff9626166a2ae201c28aa35072git merge-base --is-ancestor 743890db 76983d00734: NOT ANCESTOR.76983d00734branched from7706210c(2026-09-10), prior to#55343landing in upstreammainon 2026-09-11.vllm-tt-pluginthrough#126without#55343in the underlying metal build would break warmup trace allocations.tt-metalpin is updated to an ancestry that includes743890db.Scout status (2026-09-20, tenstorrent executor)
Already implemented?
No. Neither
masternorserving-throughputhas bumped the plugin. No open PR changes the pin; no changelog entry.vllm-tt-plugintt-metal(local trymerge)c127c17d80d66ee83d23064d3a62ac844a1170de76983d00734dc9ab3b07cbe57f4dba2854472ef5#55343 ancestry (
743890db568bd3ff9626166a2ae201c28aa35072)git+file:///home/orchestra/ttm-build/src(reftrymerge). That path does not exist on this box, and76983d00734is not on public GitHub → cannot re-rungit merge-base --is-ancestorhere.76983d00734(tree branched from7706210cbefore #55343 landed).Plugin SHAs
c127c17d80d66ee83d23064d3a62ac844a1170def1593cbbf577330dfa839918d9d413c39050e6671799d6ed2780f8ef05c166fca7c40fee555bedb0Recommended bump tip:
1799d6ed2780f8ef05c166fca7c40fee555bedb0(includes #126 + #119). 31 commits on main afterc127c17.Next step (blocked)
flake.lockmetal revs first.flake.nix+flake.lockvllm-tt-plugin→1799d6ed…; note prerequisite indocs/FORKS.md/ serve recipe.Audited and resolved/documented in PR #44 (commits
15a2ed6..65c5cba). Tagged @hermes for review.Performance advisory (automated review, 2026-09-24)
The benefit claimed for this bump is probably zero for our pin. Check both points below before paying the metal-pin cost.
#126 is a net no-op for us. #126 reverts #122, and #122 merged into plugin main on 2026-09-11, after our pin
c127c17d(2026-08-14). Our pin never had the decode-before-prefill warmup order that #126 removes, so "bump through #126" puts our warmup order back to where it already is. An independent downstream merge says the same (third-party, nyoshifujiTT fork commit4a93161): "#122 … and #126 reverted it …, so the net warmup state is unchanged". #126's prerequisite on tt-metal #55343 only exists because of #122. The "coherence/empty responses under concurrent batching" fix is not something our pin needs.#119 (decode interleaving) cannot engage in our configuration. Its policy inserts decode steps only when the base scheduler splits one prompt into multiple chunk steps (PR text: "a prompt the base scheduler splits into N chunks occupies N consecutive prefill steps"). We prevent splitting on purpose:
supports_chunked_prefill. Upstream reads it with.get(..., False), per the same fork note onbef89e4.--max-num-batched-tokens=max_model_lenso that no prompt is ever split (scripts/vllm-tt-serve.sh:256-267). A mid-page resume is refused by the prefix cache.So #119 would be inert. That is fine for makespan: interleaving improves running streams' ITL and fairness, not batch makespan, which is the same total device work.
What would change the verdict: a measured defect on our pin that #119/#126 fix. The one live candidate is the unexplained baseline 1-in-32 concurrency wrong-token (
03d8884). #45 documents a stale async-merge buffer as a plausible cause, independent of the plugin. Until that link is shown, this is a pin-hygiene task (pins move as a set, with invalidated equivalence refs), not a performance or correctness lift. Do not let it block, or be bundled with, the prefix-caching deploy (#48).If ramp-phase ITL for running agents during a new arrival's prefill ever becomes the goal, the relevant design is
docs/PREFILL-INTERLEAVING.md. It needs the resumable-prefill contract that prefix caching's 2048-aligned resume now partly provides. That is a model-side project, not this bump.agy research (2026-09-24)
Findings & Verification
• Flake pin (
flake.lock/flake.nix):c127c17d(2026-08-14, 34 commits behind HEAD3509066).• Container base (
Dockerfile.vllm-tt-src:37,recipe.nix:296):bef89e42(2026-09-04, 10 commits behind HEAD).• Production serving runtime bind-mounts
patches/prod-local-plugin/.../model_runner.py(bef89e4+ patch 0001 device argmax gate).• #122 (merged 2026-09-11) flipped Phase 2 warmup to decode-first. #126 (merged 2026-09-14) reverted it back to prefill-first.
• Both repository pins (
c127c17dandbef89e42) predate #122 and already executed prefill-first.• Bumping through #126 is a net NO-OP for warmup order. The prerequisite on tt-metal #55343 was solely needed for #126's revert and does not affect our pinned tree.
• #119 inserts decode steps only when prompts are split across multiple engine steps (
_prefill_run >= 2).• In our Qwen3.8 config, prompts are never split across steps:
supports_chunked_prefillis False by default; the prefix arm explicitly pins--max-num-batched-tokenstomax_model_len(preventing mid-page resumes refused by prefix cache); and the model runs its 2048 chunk loop internally within a single forward.• Interleaving cannot engage. Even if it did, it targets ITL/fairness, not batch makespan (our primary objective).
• Speculative Decoding / MTP (#63): #120 (
82f8e51,spec_decode.pycontract & types), #118 (7250ddf, variable block output,tt_block_kv_extent_tokens, slot moves), #128 (9314dad,spec_accept.pyCPU host accept walk).• Prefix Caching: #71 (
e882e79, renormalize mamba cache fields), #79 (bef89e4, capability-gated chunk prefill), #45 (bd150c7, state slot remap), #135 (3509066, cleanup across fallback).• NO-GO for #36 as standalone bump: Zero correctness or performance benefit; risks invalidating baseline equivalence.
• BUNDLE with #63 MTP (Phase 4): The spec decode commits are foundational for ThinkingCap MTP. Bump then, moving pins as a set with tt-metal.
Changes
• Branch:
agy/issue-36, commit128abf3.•
docs/UPSTREAM-WATCH-PLUGIN-METAL.md: updated Section 1 with 2026-09-24 audit verification.•
scripts/audit-vllm-plugin-pin.py: added automated CLI tool auditing upstream plugin vs repo pins.•
.claude/skills/vllm-plugin-audit/SKILL.md: added skill guide for the audit script.Next Hardware Measurement (When Spec Bump Occurs)
• No hardware measurement needed for #36.
• For future spec decode bump:
bench/ab/sweep-32k.shon cfx-llm2 (2× P150a, TP=2, B=4/8, ≤32k in / ≤1k out).• Expected: With
QWEN36_SPEC=0, output token-identical and makespan within ±1% of baselinesweep-32k-20260914T142154Z.jsonl(MEASURED).• Go/no-go: 100% greedy equivalence across 16 cells; zero trace corruptions.
Open Questions
3509066) or a stable tag after #128?