-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Metrics metadata support #1240
Comments
I'd be interested in helping with this feature. I implemented a similar feature for Neural Magic's Sparsezoo calculate_ops.py I propose support of both weight sparsity metrics and operations metrics. Counting operations depends upon whether the runtime engine and hardware supports sparsity, block sparsity, and quantization. The UI design should be capable of supporting these subtypes, if not now then in the future.
As for visualizing operations, I'm in favor of separating the UI from the node metadata tab as to make it clear that these performance (operation) metrics are computed values separate from the data which is embedded in the model file. For example, these could be a togglable UI displayed to the left of a node. |
Another UI idea might be togglable horizontal bars which appear to the left of a node and have different sizes depending on how many operations of which types are associated with it. There should also be a UI element for the total number of ops/sparsity in the model, perhaps in the bottom right |
@kylesayrs all great questions. Fundamentally, there seem to be 3 types of data and a question how these are unified and exposed at which API layer.
Since there are likely metrics at the model, graph, node and weights level, initially exposing them as another section in properties pages might be a good way to get started. Which data types exist for metrics in the API. For example, if |
@lutzroeder Hm, we can implement two classes,
To respond to the questions you posed
Let me know what you think †Note that in order to calculate per-node metrics for ONNX, we'll need to hard code which arguments are weights and which arguments are biases for each op type |
I prefer the compact view, at least for the frontend. The backend can maintain a separate members for |
For weight tensors there should be a Tensor Properties view similar to #1122. This will be needed for visualizing tensor data #65, avoids duplicating tensor information, gives each tensor a less crowded space, and solves the issue of mixing node metrics and tensor metrics. The individual metrics would be rendered similar to attribute or metadata, which hopefully results in a single mechanism across attributes, metadata, metrics to annotate the graph. For implementation, |
@lutzroeder In order to analyze sparsity, |
Tensor decoding is generalized in
If the general metrics implementations get complex and impact load times it might be worth considering dynamically loading a module from For tensor, the challenge is multiple changes are needed to enable #1285. Some formats have separate concepts for tensor initializer and tensor and how to opt-in quantization, what level of abstraction should this view operate on. |
Scenarios:
Questions:
The text was updated successfully, but these errors were encountered: