[Model Runner V2] batch-sharded sample - #50465
WoosukKwon merged 1 commit into
Conversation
e3b3e22 to
d45cbca
Compare
d45cbca to
099c13e
Compare
2449ffd to
dd476b1
Compare
|
This pull request has merge conflicts that must be resolved before it can be |
a04afb6 to
fd7016a
Compare
fd7016a to
f569ca8
Compare
| max_num_logprobs = self.sampling_states.max_num_logprobs(idx_mapping_np) | ||
| max_per_req_token_ids = self.logprob_token_ids_state.max_num_token_ids( | ||
| idx_mapping_np | ||
| ) | ||
| return_logprobs = max_num_logprobs != NO_LOGPROBS or max_per_req_token_ids > 0 |
There was a problem hiding this comment.
Moved this logic into the get_logprobs_dims helper method that is used for sharding the batch for sampling
f569ca8 to
f477444
Compare
c5b71e3 to
8bbd62b
Compare
8bbd62b to
6c447e6
Compare
|
/ci run |
|
✅ Triggered Buildkite CI #84330 for commit |
6c447e6 to
285609a
Compare
|
/ci run |
|
✅ Triggered Buildkite CI #84340 for commit |
285609a to
dc100e6
Compare
|
/ci run |
|
✅ Triggered Buildkite CI #84430 for commit |
|
This pull request has merge conflicts that must be resolved before it can be |
Signed-off-by: Giancarlo Delfin <gdelfin@inferact.ai>
|
/ci run |
|
✅ Triggered Buildkite CI #84867 for commit |
WoosukKwon
left a comment
There was a problem hiding this comment.
thanks for the PR and sorry for the late review.
| SAMPLING_PARAMS = [ | ||
| SamplingParams(temperature=0.0, max_tokens=32, logprobs=5, prompt_logprobs=1), |
There was a problem hiding this comment.
Can we add an extra test for bitwise correctness (without top-p and top-k)?
Summary
Currently before sampling, the full target logits are materialized, allocating memory of size
O(batch_size * (num_spec_tokens + 1) * vocab_size). This PR reduces that per-step memory allocation by a factor of1/Pduring tensor parallelism by sharding the logits and sampler inputs along the batch dimension, and sampling in parallel on a subset of the batch.Sharding the sampler inputs (
InputBatch) was straightforward, and is handled byBatchSharder.shard_sampler_inputs. Requests are assigned to ranks by partitioning the request state index mapping (usingidx_mapping % tp_size) in a deterministic way. From there, we derive the new sharded input batch CPU arrays & GPU tensors for the local rank, based on the requests that it "owns".Sharding the logits along the batch dimension is accomplished by having the model compute logits for only its slice of the vocab size by implementing the
compute_logits_localmethod. After that, each rank has a[num_tokens, vocab_size // P]slice of the full logits. However, instead of all-gathering to get the full[num_tokens, vocab_size], we instead all-to-all along the batch dimension, so that each rank ends up with[num_tokens // P, vocab_size].In summary, this PR (1) reduces peak target logits memory from
O(batch_size * (num_spec_tokens + 1) * vocab_size)=>O(batch_size * (num_spec_tokens + 1) * vocab_size / P), and (2) parallelizes the sampling operation, which can be particularly beneficial for TPOT whenever heavy sampling operations (e.g. top-k, top-p, block verification, etc) are performed. No changes had to be made to theSamplerorRejectionSamplerbecause they work perfectly fine with smaller batch sizes as long as we shard theInputBatchproperly, which we do.NOTE: A big motivation for this PR is to enable sharding of the draft logits. The cached draft logits from the speculator forward pass(es) are preallocated in memory for the worst case, with a size of
O(max_num_reqs * num_spec_tokens * vocab_size). We can reduce that by a factor of1/Pas well, but sharded sampling is a prerequisite.Speed-Bench 2K/2K, Temp=1.0, Top-p=0.95
DSV4 + DSpark (7 spec tokens)
Concurrency 64
Low Concurrencies (4-16)
Batch-sharded sampling is not expected to (and indeed does not) yield improvements at low concurrencies.
Concurrency 4 (mean of 3 runs)
Concurrency 8 (mean of 3 runs)
Concurrency 16 (mean of 3 runs)
Minimax M3 + DSpark (8 spec tokens)