快速结论:在 NVIDIA DGX Spark / Acer GN100(GB10 Blackwell,sm_121,aarch64)上启动 vLLM 时,因预编译 PyTorch/vLLM 二进制缺少 sm_121 CUDA 内核而导致初始化崩溃;优先确认所用 wheel 或容器内的实际 CUDA 架构覆盖,再决定是否从源码针对 sm_121 重建。
适用环境:Issue 已确认的环境为 GPU NVIDIA GB10 Grace Blackwell Superchip(sm_121)、架构 aarch64(ARM v9.2-A)、CUDA 13.0、系统 NVIDIA DGX OS(Ubuntu 24.04 base),测试镜像 avarok/vllm-dgx-spark:v11;另有用户在 0.29.0 aarch64 wheel 上复测(torch==2.13.0、nvidia-cutlass-dsl[cu13]==4.6.2)。
最快修复方案:暂无确认的一步修复方案。Issue 中可复现的做法是:从源码针对 sm_121 重建整套栈(PyTorch 与 vLLM),或改用专门适配 DGX Spark 的社区镜像/构建脚本作为临时替代;社区用户反馈源码重建路径可在其机器上日常使用。
注意事项:修改 TORCH_CUDA_ARCH_LIST、LD_LIBRARY_PATH 或替换兼容库对预编译二进制无效(Issue 已明确);源码重建耗时且依赖本地工具链,社区构建脚本并非官方产物;官方 wheel/Docker 原生的 sm_121 支持依赖相关构建配置 PR 合并,未合并前不要假定已具备原生内核。
问题场景
用户在 NVIDIA DGX Spark(及其 OEM 版本 Acer Veriton GN100)这类 ARM64 设备上,用 vLLM 官方或社区容器/预编译包启动推理服务。启动阶段进入 CUDA 内核初始化时崩溃:GPU 能被识别,但二进制中没有匹配实际计算能力的内核。同类复测也出现在 ASUS GX10(DGX Spark 级别,GB10 sm_121)上,使用已发布的 vLLM 0.29.0 aarch64 wheel 时,部分扩展仍缺少 sm_121 覆盖,其中 _qutlass_C 仅有 sm_100。
报错原文
[Bug]: No sm_121 (Blackwell) support on aarch64 — NVIDIA DGX Spark / Acer GN100
vLLM crashes at startup during CUDA kernel initialization.
PyTorch reports supported architectures up to sm_120 but the GPU requires sm_121.
原因分析
最可能原因是构建期架构缺口,而非运行期配置问题:随包发布的 PyTorch 二进制只编译到 sm_120,没有 sm_121 目标,因此运行时找不到匹配内核。Issue 中已指出,预编译产物缺少 sm_121 时,设置 TORCH_CUDA_ARCH_LIST、调整 LD_LIBRARY_PATH 或替换兼容库都不会生效。
后续复测进一步定位到vLLM 的构建脚本层面:CMakeLists.txt 本身已支持 12.1,但发布 wheel、Docker 镜像和 FlashInfer AOT 所使用的 TORCH_CUDA_ARCH_LIST 未包含 12.1,导致架构交集过滤时把 sm_121 排除在已发布产物之外。此外,在 SM121 硬件上从源码构建 PyTorch 时,CMake 自动检测可能把 12.1 错误改写成 12.1(2.0),相关修复仍在评审中;该现象在 Issue 中是“可能原因”层面的补充,并非所有用户都会遇到。
环境排查
- 确认 GPU 计算能力是否为 sm_121(GB10 Blackwell),以及设备是否为 aarch64。
- 确认 CUDA 版本(Issue 环境为 13.0)、显卡驱动版本。
- 确认所用 vLLM 是官方 wheel、官方 Docker 镜像还是社区镜像,并记录具体版本/标签。
- 确认 PyTorch 版本及构建架构覆盖(是否只到 sm_120);必要时检查各扩展(如
_C、_moe_C、_flashkda_C、_qutlass_C)的 SASS 覆盖。 - 确认是否设置了 TORCH_CUDA_ARCH_LIST 等运行期变量,但不要指望它们修复预编译二进制的缺口。
- 若走源码构建,确认本地 CUDA 工具链、ptxas 路径与构建并发数配置是否合理。
解决步骤
- 先排除运行期误判:记录启动崩溃时的完整日志,确认 PyTorch 报告的支持架构上限为 sm_120、而实际设备为 sm_121。
- 如果必须尽快在 DGX Spark 上获得可用的推理服务,可优先尝试使用 Issue 中其他用户验证过的替代方案:Ollama(自带 llama.cpp 后端,支持 Blackwell),或专门面向 DGX Spark 的社区构建脚本/镜像(例如评论中给出的社区仓库),但需自行评估维护与安全风险。
- 如需继续使用 vLLM,可优先尝试从源码重建:构建 PyTorch 时让 CUDA 架构包含 12.1(社区用户反馈使用 12.1a 目标构建成功),再在该环境下从源码安装 vLLM。Issue 评论中用户称此方式在其 DGX Spark 上可日常使用。
- 关注官方构建配置修复:Issue 中提到的构建配置 PR 计划在各构建配置中补上 12.1,使发布 wheel 与 Docker 镜像包含原生 SM121 内核。合并并发布后,可改用官方产物,无需源码构建。
- 若改用已发布 wheel 或镜像,先核对其内核覆盖是否已包含 sm_121,尤其是
_qutlass_C等单独扩展,避免出现“大部分扩展可用、个别扩展仍缺”的部分可用状态。
验证方法
在目标设备上重新启动 vLLM 并加载一个小模型:若 CUDA 内核初始化不再因缺少 sm_121 而崩溃、服务可正常响应推理请求,即说明构建架构已覆盖 sm_121。对源码构建或新发布产物,建议逐扩展核对实际包含的计算能力列表,确认不再只有 sm_120 或 sm_100;Issue 中复测者也提出可在构建产物上跑核对检查与推理测试来验证。若仍崩溃,回到环境排查,确认当前加载的 PyTorch/vLLM 二进制确实来自新的构建。
参考来源
AI 工具推荐
想把多个 AI 模型放在一个入口?
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型,适合写作、绘图、视频和日常 AI 工作流。
推广链接:通过此链接购买,我可能获得佣金,不影响你的价格。
这个方案解决了吗?
可以继续搜索完整报错,或查看同一工具的其他排查指南。


