Skip to content

Conversation

@jberchtold-nvidia
Copy link
Collaborator

Description

Please include a brief summary of the changes, relevant motivation and context.

Fixes # (issue)

Type of change

  • Documentation change (change only to the documentation, either a fix or a new content)
  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Infra/Build change
  • Code refactoring

Changes

Please list the changes introduced in this PR:

  • Change A
  • Change B

Checklist:

  • I have read and followed the contributing guidelines
  • The functionality is complete
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes

@jberchtold-nvidia jberchtold-nvidia marked this pull request as draft December 4, 2025 20:05
@greptile-apps
Copy link
Contributor

greptile-apps bot commented Dec 4, 2025

Greptile Overview

Greptile Summary

This PR modifies the post-RHT (Random Hadamard Transform) amax calculation in JAX quantization to use an approximation instead of the exact computation. The change replaces the call to calculate_post_rht_amax() with a simple multiplication: post_rht_amax = amax * 2.0.

  • Performance optimization: Avoids the kernel call to RHTAmaxCalculationPrimitive for computing exact post-RHT amax
  • Approximation method: Uses a 2x scaling factor on regular amax as a conservative estimate
  • Dead code introduced: The hardcoded use_approx_amax = True flag leaves the original exact calculation path unreachable

Confidence Score: 4/5

  • This PR is relatively safe - it's a performance optimization that uses a conservative 2x approximation factor
  • The change is straightforward and the approximation approach (multiplying amax by 2.0) appears to be a reasonable conservative estimate. However, the hardcoded boolean creates unreachable dead code which could be cleaned up.
  • No files require special attention beyond the style note about dead code

Important Files Changed

File Analysis

Filename Score Overview
transformer_engine/jax/cpp_extensions/quantization.py 4/5 Changed post-RHT amax calculation from exact computation to approximation using amax * 2.0. Introduces hardcoded use_approx_amax = True flag making the else branch dead code.

Sequence Diagram

sequenceDiagram
    participant Q as _quantize_dbias_impl
    participant A as calculate_amax
    participant K as TE Kernel
    
    Note over Q: When use_rht=True
    
    alt use_approx_amax=True (New Path)
        Q->>A: calculate_amax(x.data)
        A-->>Q: amax
        Q->>Q: post_rht_amax = amax * 2.0
    else use_approx_amax=False (Dead Code)
        Q->>K: calculate_post_rht_amax(x.data)
        K-->>Q: new_amax, post_rht_amax
    end
    
    Q->>K: PrimitiveClass.outer_primitive.bind(..., post_rht_amax)
Loading

Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

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

Additional Comments (1)

  1. transformer_engine/jax/cpp_extensions/quantization.py, line 810 (link)

    style: Hardcoded use_approx_amax = True makes the else branch (lines 820-831) unreachable dead code. Consider either removing the dead code or making this configurable (e.g., via quantizer attribute or function parameter).

1 file reviewed, 1 comment

Edit Code Review Agent Settings | Greptile

@ptrendx ptrendx added the fp4 label Dec 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants