-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Op][Spec] RMSNorm Operator Specification #23569
Conversation
* *compute_type* | ||
|
||
* **Description**: The precision for internal computation, before scaling. | ||
* **Range of values**: Supported floating point type: "f32", "f16", ... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
any other types except fp16
and fp32
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the models I've seen cast to f32, in general any type can be allowed to comply with Convert capabilities, but it can be not a real use case.
(x / Sqrt(ReduceMean(x^2, axes) + eps)) | ||
|
||
|
||
- If the optional ``scale`` input is provided: | ||
|
||
.. math:: | ||
|
||
(x / Sqrt(ReduceMean(x^2, axes) + eps)) * scale |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the final decision to have multiplication by x
inside RMSNorm
? Why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The discussion I mentioned in the PR description is about having the scale
inside or outside the formula.
And I proposed to keep it optional for compatibility with existing GPU RMSNorm op.
Could you please precise, do you see other options for the RMSNorm formula?
### Details: - RMSNorm op core class - Registration in the opset and op check (conformance) test will be added in the next PRs Spec PR: - #23569 ### Tickets: - 136261
...ocumentation/openvino-ir-format/operation-sets/operation-specs/normalization/rms-norm-15.rst
Show resolved
Hide resolved
### Details: - RMSNorm op core class - Registration in the opset and op check (conformance) test will be added in the next PRs Spec PR: - openvinotoolkit#23569 ### Tickets: - 136261
This comment was marked as outdated.
This comment was marked as outdated.
Ongoing discussion: The "compute_type" attribute supposed to cover |
### Details: - RMSNorm reference implementation - The `Scale` input is optional ** The conversion of the input/output type is not included (proposed as `computation_type` - conversion logic can be handled by the Convert operations (or the reference can be extended with the conversion logic separately if agreed on the spec). Related PRs: - Specification Proposal: #23569 ### Tickets: - 136262
Closing - Decided to keep RMS as internal operator for now (moved from gpu custom). |
Details:
To be discussed:
compute_type
- precision for the internal computation and accumulation (usually f32 for better results on lower precisions), inside the op or outside and implemented by Convert - proposed as attribute to comply with existing GPU RMSNorm (output_type)Related GPU kernel and fusion transformation.
Related PRs:
Tickets: