Repository navigation
Conversation
Signed-off-by: 0xDexe <dannislife6@gmail.com>
pranavm-nvidia
approved these changes
Nov 6, 2026
Author
|
Hi @kevinch-nv @yuanyao-nv, this PR (fix for #4873) has been approved by @pranavm-nvidia. Could one of you take a look and merge it when you get a chance, or let me know if anything else is needed? Thanks! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #4873. Thanks @v0ropaev for the diagnosis and @gabortar for the
int32_datacorrection.Overview
process_bf16_tensormisreads BF16 initializers. It's shared byinspect sparsity,surgeon prune,surgeon weight-stripandsurgeon weight-reconstruct, so all four are affected. There are two bugs.raw_data: The check loop reuses the variable
i. Butshort2longalso usesito compute positions, so the check ends up reading a diagonal of elements instead of each group of 4. That gives wrong answers, and it often crashes with anIndexErrornear the end of the tensor.int32_data: Each entry holds one BF16 value in its low 16 bits. The check only reads one entry per group of 2, and then it counts that value's two bytes as if they were two separate values. So a dense tensor full of 2.0 (
0x4000) gets reported as sparse, because its low byte happens to be zero.Changes made
Fix: Both formats now use the same loop over groups of 4. A small
is_zerohelper reads two bytes for raw_data and the low 16 bits for int32_data. Pruning output doesn't change. The int32_data branch still zeroes elements 0 and 2 of each group, which is exactly what the old loop did.Test: I added
tests/tools/test_sparse.pywith 18 tests. They run on CPU and don't need TensorRT. They cover sparse tensors, dense all-2.0 tensors, tensors with only one zero in a group, and pruning followed by a re-check. Each case runs for both raw_data and int32_data, and with both stride layouts (pstride == 1andpstride > 1). The tests check the actual sparse or not-sparse answer, not just whether the command exited successfully.Output