Skip to content

perf(kv): stage block table with numpy - #132

Open
adamleex wants to merge 1 commit into
thu-pacman:public-mainfrom
adamleex:perf-kv-block-table
Open

perf(kv): stage block table with numpy#132
adamleex wants to merge 1 commit into
thu-pacman:public-mainfrom
adamleex:perf-kv-block-table

Conversation

@adamleex

@adamleex adamleex commented Jun 2, 2026

Copy link
Copy Markdown

Build the paged KV block table through a reused NumPy int32 buffer and a persistent torch view. A microbenchmark on H200 shows lower CPU staging and CPU-to-GPU update time than rebuilding padded Python lists with torch.tensor.

Benchmark

Microbenchmark on H200, measuring CPU staging + GPU copy + synchronize:

Shape Old Total (µs) New Total (µs) Ratio
1x8 20.44 19.79 0.97
1x16 19.84 20.81 1.05
1x32 24.04 21.41 0.89
1x64 27.38 22.47 0.82
2x32 27.23 22.32 0.82
8x64 73.54 45.08 0.61
32x128 452.68 202.28 0.45

Build the paged KV block table through a reused NumPy int32 buffer and a persistent torch view. A microbenchmark on H200 shows lower CPU staging and CPU-to-GPU update time than rebuilding padded Python lists with torch.tensor.
@roastduck

Copy link
Copy Markdown
Collaborator

Thank you for your contribution!

But I am wondering why this persistent numpy buffer matters. I thought a malloc of a numpy buffer is much cheaper than the following assignment from block_lists, which involves many list to numpy conversions, and I thought the numpy buffer malloc time can be ignored. What profiling have you done to pinpoint this buffer allocation overhead?

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