[Frontend] Refactor how frontend handles node datatypes

[stomfaig]

This PR implements a more direct reference system in Graph to different node types (e.g. Input, Param etc.).

Some notes about the current version of the draft.

1. GraphImporter still also only receives input and params in TensorMeta (see ambiguity of this below). I've left it this way, because in GraphImporter we do not expect to change this again, so there is no reason to introduce more complication, though the notation will be improved to reflect this.

2. One point of friction here is that thorughout the frontend there seems to be two notions of tensor_meta, one being the type TensorMeta, the other being either a dict[str, Any], the other being dict[str, list[Any]]. For now I left some convenience script in for the sake of this draft, but let's discuss what the general direction with this should be.

Closes #639

[stomfaig]

cc: @zhanghb97 @R-Tars

[R-Tars]

Thanks for pointing this out — I agree it is an important issue.

For now, I don’t think we should rush to unify tensor_meta, as doing so would likely require changes across a large amount of existing operator and frontend code. Given the scope of this PR, deferring that work seems reasonable.

In the longer term, I do think converging on TensorMeta as the unified representation would be preferable, but this can be revisited once the new reference system stabilizes.

[R-Tars]

I ran into a runtime issue when testing this PR locally with Torch 2.8. The build fails while generating the DeepSeek-R1 example, and the traceback points to eliminate_weight_transpose.py in eliminate_transpose, with the following error:

AttributeError: 'int' object has no attribute 'shape'

In this case, tensor_meta seems to be resolved as an int instead of the expected TensorMeta (or at least an object with a shape attribute), so this part likely needs to be fixed or unified in this PR.

[stomfaig]

Thanks for pointing that out, I have been struggling to validate whether the change will cause any breakages.

I'll try to figure out something and maybe add frontend tests.

[R-Tars]

Thanks for looking into this. Just to add some context: a recent commit has caused most models to fail at runtime, so the frontend is currently in a rather unstable state. We are currently trying to address this issue. As a result, even if this specific issue is fixed, models may still not run correctly at the moment.

[R-Tars]

It seems that this PR has not been updated for some time. I pulled the latest changes today and tested them locally against the current main branch. At the moment, the DeepSeek-R1 example still cannot run successfully, so the runtime issue does not appear to be fully resolved yet.

For this PR to be ready for merging, I think a minimum requirement is that the DeepSeek-R1 example can run correctly from start to finish. Currently, this is still not the case.

If you encounter any difficulties fixing the issue, please feel free to let me know — I am happy to help with debugging.