Skip to content

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

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

[KMeans] Configure Workspace for Large Batch Sizes#2433
tarang-jain wants to merge 2 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.

@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.

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