Skip to content

[Perf][Integration] Reserve Python batch transfer request capacity - #4104

Open
adenzhou1350 wants to merge 1 commit into
kvcache-ai:mainfrom
adenzhou1350:codex/batch-request-vector-reserve-7dee8db
Open

adenzhou1350 wants to merge 1 commit into
kvcache-ai:mainfrom
adenzhou1350:codex/batch-request-vector-reserve-7dee8db

Conversation

@adenzhou1350

@adenzhou1350 adenzhou1350 commented Sep 14, 2026 •

Copy link
Copy Markdown
Contributor

Description

The classic Python transfer wrapper knows the final request count before it builds synchronous, asynchronous, and CUDA-callback batches. Reserve that exact capacity before the existing push_back loops.

This avoids geometric std::vector growth and relocation while preserving request count and order, addresses, lengths, opcodes, retry fields, transport hints, submission, completion, error handling, and object lifetime.

A local component benchmark using the actual 56-byte TransferRequest type measured these construction-only improvements across two alternating runs:

  • 1,024 descriptors: 1.17-1.19x, saving 1.55-1.83 us per vector
  • 4,096 descriptors: 4.33-4.37x, saving 124-126 us per vector
  • 16,384 descriptors: 5.26-5.43x, saving 664-695 us per vector

These are request-vector construction measurements, not transport or end-to-end results.

Module

  • Transfer Engine (mooncake-transfer-engine)
  • Mooncake Store (mooncake-store)
  • Mooncake Conductor (mooncake-conductor)
  • Reshard (mooncake-reshard)
  • Mooncake EP (mooncake-ep)
  • Mooncake PG (mooncake-pg)
  • Integration (mooncake-integration)
  • P2P Store (mooncake-p2p-store)
  • Python Wheel (mooncake-wheel)
  • Common (mooncake-common)
  • Mooncake RL (mooncake-rl)
  • CI/CD
  • Docs
  • Other

Type of Change

  • Bug fix
  • New feature
  • Refactor
  • Breaking change
  • Documentation update
  • Performance improvement
  • Other

How Has This Been Tested?

Test commands:

./scripts/code_format.sh --check --changed-lines \
  --base 7dee8db1a68c5656ea699acf71617783a13633c7

cmake -S . -B /build -DSKBUILD=ON -DWITH_STORE=OFF \
  -DWITH_TE=ON -DBUILD_UNIT_TESTS=ON -DUSE_TCP=ON \
  -DUSE_CUDA=OFF -DCMAKE_BUILD_TYPE=Release
cmake --build /build --target engine -j3

python3 -m unittest \
  mooncake-wheel.tests.transfer_engine_initiator_test.TestVLLMAdaptorTransfer.test_batch_write_read \
  mooncake-wheel.tests.transfer_engine_initiator_test.TestVLLMAdaptorTransfer.test_async_batch_write_read

The build and tests ran in a pinned local container with network disabled and no GPU. Both tests passed two TCP rounds with batch size 100. Follow-up on ba61a790: the complete transfer_engine_py.cpp translation unit now also compiles with -DUSE_CUDA -DUSE_TCP using GCC 11.4 and CUDA 13.0.2 headers; nm -C confirms the batchTransferOnCuda symbol is emitted. A further isolated Release build now also successfully links the complete engine Python extension with USE_CUDA=ON and USE_TCP=ON (GCC 11.4, Python 3.10, CUDA 13.0.2). The linked module depends on libcudart.so.13 and references cudaLaunchHostFunc. Build inputs were cached, apart from pinned NumPy 1.26.4 installed only in the temporary container; configure/compilation ran offline. CUDA callback execution and RDMA transport remain untested; this is no new performance result. All six applicable PR-scoped pre-commit hooks and the changed-line clang-format 20.1.8 check pass; five non-applicable hooks were skipped. No source changes or GPU use were needed.

Test results:

  • Unit tests pass
  • Integration tests pass (if applicable)
  • Manual testing done (component construction benchmark described above)

Checklist

  • I have performed a self-review of my own code
  • I have formatted my code using ./scripts/code_format.sh
  • I have run pre-commit on the files changed in this PR and all hooks pass
  • I have updated the documentation (not applicable; no API or behavior change)
  • I have added tests to prove my changes are effective (existing batch tests cover the unchanged behavior)
  • For changes >500 LOC: I have filed an RFC issue (not applicable; 3 LOC)

AI Assistance Disclosure

  • No AI tools were used
  • AI tools were used (specified below)

OpenAI Codex helped identify the allocation pattern, prepare the three-line capacity hint, replay it on the latest upstream main, and run the focused build, format, duplicate, benchmark, and TCP correctness checks. The human submitter reviewed and approved the final diff and claim boundary.

Signed-off-by: Xucheng Zhou <aden1350@outlook.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant