Repository navigation
Conversation
|
Thanks @jschmied, this is part 1 as we hoped: no pinning on a GB10, replies and first-row logits equal, and 8k and 32k prompts 1.6 to 2.1% sooner in 8 of 8 rounds against a clean A/A. Your questions: keep counting the states on the host budget, since on a GB10 it's the same memory and moving it would shrink everyone's KV room; yes, please name device memory in the startup line on an integrated GPU, in this PR; and leave the paged path's gather for the paged follow-up. With the startup line and a CHANGELOG line, we'll repeat your cold 32k cell on our GB10 and land it. |
|
Thanks @ashhart. Both are in 2f1fbc5, a new commit on top. On an integrated GPU the startup line now names device memory, and the budget stays on the host. Here's the 35B on our GB10:
With |
|
Thanks @jschmied, that's everything. We'll repeat your cold 32k cell on our GB10 and land it. |
|
@jschmied, our GB10 run is in and it's green: the cold 32K prompt, your head against its base, alternating builds. Tokens are identical in all 4 rows. Prompt speed is 1,278.9 -> 1,282.1 tok/s cold (+0.3%) and 1,262.4 -> 1,266.9 repeated (+0.4%), and decode is level. That's a smaller gain than your 1.6-2.1%, on our box, with no loss. Queuing it to land. Thanks. |
…thout pinning a copy each save On a GB10 a 32k save pinned 655 MB with cuMemHostAlloc (~180 ms) before an 11 ms copy, and its drop unpinned it (~75 ms). The CPU and GPU share that memory, so the copy now goes to a cuMemAlloc buffer (~4 ms) by device-to-device copies, both ways. The store's budget stays the host's. A discrete card, and --learn-conversations (its disk tier reads the bytes on the CPU), keep pinned host copies.
…PU keeps the prompt states The cache stays on the host budget; with --learn-conversations the states, and the line, stay on the host.
2f1fbc5 to
322ea19
Compare
Closes #2043.
On an integrated GPU (
CU_DEVICE_ATTRIBUTE_INTEGRATED), Qwen3.5's kept prompt states now live in acuMemAllocbuffer and are saved and restored with device-to-device copies. Before, every save pinned a fresh host buffer. On a GB10 a 32k save pinned 655 MB withcuMemHostAlloc(167–190 ms) ahead of an 11 ms copy, and dropping the state unpinned it again (about 75 ms). The CPU and GPU share that memory, so nothing needs pinning.A discrete card keeps pinned host copies. So does
--learn-conversations, because its disk tier reads the bytes on the CPU. The store still counts the states against the host budget, which on a GB10 is the same physical memory.Micro (655 MB, 10 repeats, beside a 60 GB held allocation)
cuMemHostAlloc167–190 mscuMemAlloc3.8–4.0 ms (14.6 ms for the first, beside the held 60 GB)cuMemFreeHost72–78 mscuMemFree0.23–1.4 msServing (GB10, SM clock locked at 2300 MHz, page cache dropped before every server start)
speed2.py, 8 rounds × 3 repeats, ABBA, with two runs of main as the A/A control (A/A = main against main, head = this PR against main). Negative is faster. Texts and first-row logits are equal in every arm, round and repeat.Head is faster in 8 of 8 rounds in both prompt cells on both models. The 2k prompt, decode and 4-stream cells are within the A/A on both models. The warm turn doesn't move: restoring its 141 MB state took 1–2 ms either way.
Tests
A new host test with a counting driver checks two things: a device save allocates no pinned memory, and dropping the state frees its device buffer. A planted failure confirmed the test catches it.
zig build test, CI and diff-check pass, and lean reports 0 new problems.Questions
host_snaps = false? That would shrink the KV room planned at startup, so I left it on the host.Overlaps:
cuda_reuse.zigis also touched by #1335 and #1879, which ATC reports as conflicting, and by #2020, which is clean. I'll rebase whichever order you prefer.