llama.cpp b11282修复MUSA后端架构宏缺失，摩尔线程GPU内核不再被编译为空
MUSA厂商头文件从未定义 __CUDA_ARCH__，导致共享ggml-cuda源码里所有架构判断都取值为 0，按架构门控的内核被编译成空；b11282参考HIP后端的做法补上该宏。
AI解读：这次改的是一个看起来很小、但会让整块GPU内核凭空消失的宏。MUSA是摩尔线程的GPU计算平台，llama.cpp的MUSA后端复用了大量ggml-cuda的共享源码，而这些源码用 __CUDA_ARCH__判断自己在哪一代架构上编译。MUSA厂商头文件从来没定义过这个宏，于是所有架构判断都等于 0，被架构条件包住的内核主体直接编译成空。
受影响的不只是理论上的边角路径。提交说明点名了convert.cu里的q8_0 → f16反量化内核：它的NO_DEVICE_CODE回退在主机代码里展开为空函数体，也就是说设备端并没有生成对应实现。换句话说，在MUSA上真正跑量化模型时，这条反量化路径很可能根本不存在。
修复方式是把 __CUDA_ARCH__定义成最新架构，跟HIP后端此前的做法保持一致，同时显式排除NVIDIA专属特性，因为这些特性在MUSA上不可用。提交还只对设备编译阶段定义该宏，理由是CUB和nvcc都用defined(__CUDA_ARCH__) 判断当前是否在编译设备代码。
顺带清理了一批冗余判断：CUDA和MUSA在主机阶段本来就不定义 __CUDA_ARCH__，HIP则是每个阶段都定义，因此原来写成两种形式的架构比较实际上会选择同一分支，去掉重复检查不改变行为。
这个改动对普通用户没有可见变化，也不会让MUSA突然追平CUDA或ROCm。它解决的是“能编译但内核是空的”这类最难排查的问题，真正受益的是在摩尔线程GPU上跑llama.cpp的人，以及后续要往ggml-cuda共享代码里加架构分支的开发者。
发布包里同时更新了macOS、Linux、Windows、Android和Snapdragon等平台的预编译产物，CUDA 12、CUDA 13、ROCm 10.0、Vulkan、SYCL、OpenVINO等后端均有对应下载项，openEuler构建仍处于禁用状态。
llama.cpp发布b11282，合入PR #29508，为MUSA后端在设备编译阶段定义 __CUDA_ARCH__宏。
提交说明称，MUSA厂商头文件从未定义 __CUDA_ARCH__，因此共享ggml-cuda源码里的每一项架构判断都求值为 0。
被架构条件门控的内核主体因此被编译为空，其中包括convert.cu中的q8_0 → f16反量化内核，其NO_DEVICE_CODE回退在主机代码中展开为空函数体。
修复方式是像HIP后端那样上报最新架构，并显式排除在MUSA上不可用的NVIDIA专属特性；该宏只在设备编译阶段定义，因为CUB使用defined(__CUDA_ARCH__) 来检测设备编译，nvcc的行为也是如此。
提交同时删除了架构比较中已冗余的defined(__CUDA_ARCH__) 检查，理由是CUDA和MUSA在主机阶段不定义该宏，而HIP在所有阶段都定义它，两种写法会选择同一分支。
发布产物覆盖平台
b11282的预编译包覆盖macOS、Linux、Windows、Android与openEuler相关平台，并包含UI包。
- macOS/iOS：Apple Silicon（arm64）、Intel（x64）、iOS XCFramework；开启KleidiAI的macOS Apple Silicon构建处于DISABLED状态。
- Linux：Ubuntu x64/arm64/s390x CPU、Vulkan、CUDA 12.8、CUDA 13.4、ROCm 10.0、OpenVINO、SYCL FP32/FP16，以及Snapdragon的CPU、Adreno GPU、Hexagon NPU整合包。
- Android：arm64 CPU，以及Snapdragon的CPU、Adreno GPU、Hexagon NPU整合包。
- Windows：x64/arm64 CPU、OpenCL Adreno（arm64）、CUDA 12.4、CUDA 13.4（x64与arm64）、Vulkan、OpenVINO、SYCL、ROCm 10.0。
- openEuler：x86与aarch64的 310p、910b（ACL Graph）构建均标记为DISABLED。