Repository navigation
Creating a new ascend branch for better compatibility is worth a try. #119
PrometheusComing
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hello, I am an infrastructure engineer at Huawei.
During the current transition phase of the AREAL community from v1 to v2, it seems that in the main branch, v1 only supports co-located awex, and v2 only supports separated awex, both in the sglang scenario. In the ascend branch, v1 supports both co-located and separated scenarios, and adds the AREAL register model to supplement the awex register model, which is in the form of a patch. Therefore, the community lacks an NPU and cannot easily verify the NPU scenario, while vllm & vllm-ascend are also heavily using awex in the NPU scenario. Additionally, the awex register model approach causes GPU and NPU to use the same converter. These factors inevitably lead to compatibility issues.
My idea is to try creating an ascend branch, periodically rebasing the model implementation from the main branch and adding ascend compatibility handling. This way, both branches can maintain their own version and model development pace while ensuring their respective applicable scenarios. If you agree, I would appreciate it if you could grant me maintainer permissions for the ascend branch. I think it might be worth trying out.
All reactions