Skip to content

5080deploy: merge upstream #414, order the batch-memcpy probe against the current stream - #50

Open
gdevenyi wants to merge 2 commits into
5080/11-msgpack-frames-466from
5080/12-memcpy-probe-order-414
Open

gdevenyi wants to merge 2 commits into
5080/11-msgpack-frames-466from
5080/12-memcpy-probe-order-414

Conversation

@gdevenyi

@gdevenyi gdevenyi commented Sep 18, 2026 •

Copy link
Copy Markdown
Owner

Stacked on #49. Merges upstream FlashML-org#414 (head b6e7995) into 5080deploy, rebuilt on upstream main cac247a (v0.1.3).

Why it is in scope for this deployment: Generic kernel fix (the expert-cache batch memcpy probe); this deployment uses the offload expert cache it probes for.

Merge: Clean merge.

Testing (RTX 5080 16 GB, production flags: FTW-fp8, nvfp4 KV, 262,144 tokens, 1,280 expert slots):

  • pytest tests/ -m "not slow" at 69a5efa (the tip before the middleware commit 8adde91, which touches only server/api_server.py and adds one test; tests/server rerun at 8adde91: 871 passed): 2412 passed, 206 skipped; the 4 failures are environment-only (3x test_muse_glimmer_vision.py fail identically on pristine upstream cac247a with transformers 5.15.1, and test_async_pull_coalesced is an async def test that needs pytest-asyncio, which the project does not declare).
  • Bench after the merge stack (RTX 5080, production flags): 1K: 526 prefill / 38.43 decode tok/s, 30K: 1175 prefill / 40.46 decode tok/s, 90K: 1203 prefill / 38.5 decode tok/s.

Rebased 2026-09-19 onto upstream main cc1f5c2 (4 commits past cac247a: FlashML-org#471 greedy sampling in mixed batches, FlashML-org#518 WeightLoadError, FlashML-org#521 tvm-ffi jit arch, FlashML-org#524 install index). Same replay as before via git rerere; the replayed stack differs from the previous tip 8adde91 by exactly the cac247a..cc1f5c2 file set. This PR's head is now b63d524.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Bu6LgoxLR4wETqb7RPR2vt

_probe allocates its destination with torch.zeros, which enqueues the fill on
the current stream, then enqueues the verification copy on a fresh probe
stream. Nothing joins the two. When the current stream has a backlog the copy
completes first on the independent probe stream and the fill lands on top of
it, so the probe reads back zeros and load_batch_memcpy raises
"cudaMemcpyBatchAsync probe copied wrong bytes" on a GPU that supports the API.

OffloadMoeCache catches that and falls back to full-layer copies, so
--moe-prefill-hit-d2d silently does nothing whenever the current stream is busy
as the probe runs -- in practice during prefill warmup, which is exactly when
the flag is first exercised.

A cold process hides the bug: the first torch.zeros pays a cudaMalloc and the
first torch.cuda.Stream() populates the per-device stream pool, and each of
those synchronizes the device, draining the backlog before the copy is
enqueued. That is why the probe passes when run standalone and fails inside a
warmed-up server.

Join the probe stream to the current stream before the copy.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@gdevenyi
gdevenyi force-pushed the 5080/11-msgpack-frames-466 branch from fff12a0 to 7c58f01 Compare September 23, 2026 23:36
@gdevenyi
gdevenyi force-pushed the 5080/12-memcpy-probe-order-414 branch from b63d524 to 0a62baa Compare September 23, 2026 23:36
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.

2 participants