Skip to content

[KMeans] Configure Workspace for Large Batch Sizes - #2433

Open
tarang-jain wants to merge 11 commits into
NVIDIA:mainfrom
tarang-jain:mem-resource
Open

[KMeans] Configure Workspace for Large Batch Sizes#2433
tarang-jain wants to merge 11 commits into
NVIDIA:mainfrom
tarang-jain:mem-resource

Conversation

@tarang-jain

@tarang-jain tarang-jain commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

RAFT limits the regular workspaces to one-fourth the available GPU memory. If a batch size larger than that is used, fall back to the large workspace to avoid OOM.

Merge this after #2484

Experiment to check managed vs pool MR to check if this selectively choosing the workspace makes sense. The idea is that the workspace MR is mostly a pool MR and the large MR is a managed MR. We show the difference in throughput for data transfer from host to pool and managed workspace.

H100 + Intel(R) Xeon(R) Platinum 8480CL

Mode E2E Time (s) kmeans_fit Time (s) Average H2D Throughput (GB/s)
Managed 217.838 126.545 51.59
Pool 208.082 118.157 56.71

@tarang-jain tarang-jain self-assigned this Aug 11, 2026
@tarang-jain tarang-jain added bug Something isn't working non-breaking Introduces a non-breaking change labels Aug 11, 2026

@viclafargue viclafargue left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

if (weight_ptr != nullptr) {
batch_staging_bytes += static_cast<size_t>(device_buffer_samples) * sizeof(DataT);
}
if (batch_staging_bytes > raft::resource::get_workspace_free_bytes(handle)) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not just always use the large workspace? I think doing this conditionally creates an additional challenge for user debugging that we could avoid if we just use the same workspace resources all the time. Will let @achirkin comment here too.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thats a good point, especially since we do expect batches to be quite large ( > 20 GB or so per batch).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The user may set up the large workspace to use a slower memory than the normal workspace (e.g. managed memory vs device pool - a setup we recommend and also set in benchmarks).
Therefore, please view this as an optimization: if access to arrays allocated via this resource is the bottleneck, we should keep it; otherwise, it's ok to use the large workspace by default.
In this case, we're talking about batching, so my understanding is having small enough batches is a normal behavior, whereas the switch to the large workspace is an edge case to make the algorithm not fail if there's not enough memory.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated the PR desc to show the throughput with a managed and pooled workspace respectively. I am in favor of keeping this PR as is: use the large MR only when the required bytes exceed the workspace.

@tarang-jain
tarang-jain requested review from a team as code owners August 20, 2026 15:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working non-breaking Introduces a non-breaking change

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants