Repository navigation
perf(rollout): reuse filtered prompt token ids - #2309
liuhao-labs wants to merge 1 commit into
Conversation
|
i checked this before and decided not to add it because re-tokenization especially in text-only case wont add too much latency. theoretically yes we should have this. |
|
Thanks for the context. I measured the retained text-only path before opening this, because the benefit depends on dataset size and prompt length. On the same local workload (10,000 retained prompts, 2,189,001 prompt token IDs, an in-memory ByteLevel BPE), the current path made one batched tokenization call during filtering plus 10,000 per-sample The immediate same-process comparison was:
The retained cache payload was 8,756,004 bytes (8.35 MiB) as packed uint32 IDs. It is only created when max-length filtering has already tokenized the prompt, only for retained text prompts on the stock rollout path, and it is consumed before Ray transfer. Multimodal processor outputs and custom rollout/data-source paths remain uncached. So this is not intended to add tokenization work when filtering is disabled; it only reuses work that has already happened. The exact speedup will vary with tokenizer and prompts, but the invariant improvement is one fewer encoding pass per retained text prompt. |
4535cb5 to
37e3654
Compare
37e3654 to
8f27de4
Compare
|
Rebased onto current |
8f27de4 to
8976051
Compare
Signed-off-by: Hao Liu <liuaho6@gmail.com>
8976051 to
71bdd74
Compare
|
@nanjiangwill, refreshed this against the current v0.4 mainline. The cache is wired through the relocated Local validation: 111 CPU tests passed, including stock data sources, repeated epochs/siblings, serialization/reconstruction, eval, buffer/checkpoint behavior, fully async rollout, and plugin contracts. The full refreshed PR Test run is green with 89 successful jobs and no failures. Filtering, Sample, buffer, and real distributed Ray/Straw fan-out all passed, as did pre-commit. The PR is mergeable and ready for another look. The workload benchmark and bounded text-only cache scope are documented in the description. |
Summary
Max-length filtering already tokenizes every retained text prompt, but default rollout preparation encodes the same rendered prompt again. Reuse those IDs for stock training and evaluation, eliminating the second encoding pass.
The cache contains only immutable packed uint32 IDs (4 bytes per token). Deep-copied siblings share the payload and each materializes its own mutable token list on consumption. The cache is excluded from serialization and dataclass reconstruction. Multimodal outputs and custom rollout/generate/data-source contracts remain uncached.
Training is wired through the current
slime.data.data_sourceAPI. Missing rollout configuration disables caching; existing tokens and multimodal processing retain their precedence.Related to #1111.
Validation
tokenizer.encodecalls dropped from 10,000 to 0. The immediate same-process comparison for filtering plus preparation was 2.65s versus 0.57s; packed payload size was 8.35 MiB. Timing is workload-dependent.