# 一张 910B3 能跑多大的模型？——vLLM-Ascend 0.23.0 单卡部署实测、踩坑与选型方法

> 关键词：vLLM-Ascend、Atlas A2 / 910B、CANN 9.1、Qwen3、多模态、部署实践、问题排查

## 写在前面

最近在给一个本地化大模型项目做硬件选型。采购之前，我不想只拿参数表和网上的经验值做决定，于是在 CANNLab 上开了一台单卡 910B3 的云环境，用 vLLM-Ascend 从零部署，陆续跑了 Qwen3-8B、Qwen3-VL-8B、Qwen3.8-27B，也在 Qwen3-VL-32B-FP8 上碰了壁。

前后折腾了好几天，踩的坑比预想的多得多。这篇文章不按"第一步、第二步"罗列安装命令，而是想把三件事讲清楚：

1. 单卡 910B3 的上限在哪里？是什么决定的？
2. 从零部署 vLLM-Ascend 0.23.0，最耗时间的坑是什么，根因在哪？
3. 能不能不逐个实测，就提前估出一个模型在 910B 上的表现？

## 一、先测带宽：纸面估算错了三处

上机前我按公开资料做过一份纸面推演。上机后第一件事是测环境，结果三个关键假设都被推翻：

| 项 | 纸面假设 | 实测 |
|---|---|---|
| HBM 带宽 | 800 GB/s | copy 实测 1267 GB/s，推算峰值约 1490 GB/s |
| 宿主内存 | 32 GiB（控制台规格） | cgroup 上限 200 GiB |
| BF16 单卡能跑的模型 | 14B 左右 | 跑通了 27B（原因见第七节） |

带宽这一项影响最大。大模型单流解码时，每生成一个 token 都要把全部权重从 HBM 读一遍，速度基本由带宽决定，而不是算力。按 800 GB/s 算，稠密 32B 模型"物理上不可能"到 30 tok/s；按实测的 1490 GB/s 算，它就擦着线了——结论完全相反。

测带宽只要几行代码，两分钟出结果：

```python
import time, torch, torch_npu
n = 2048 * 1024 * 1024 // 2                      # 2 GiB 的 float16
a = torch.empty(n, dtype=torch.float16, device="npu:0").fill_(1.0)
b = torch.empty_like(a)
for _ in range(3):
    b.copy_(a)                                    # 预热，首次含算子编译
torch.npu.synchronize(); t0 = time.perf_counter()
for _ in range(20):
    b.copy_(a)
torch.npu.synchronize()
print(2 * n * 2 * 20 / (time.perf_counter() - t0) / 1e9, "GB/s")   # copy 一读一写
```

**我的体会：先测带宽，再决定下载哪个模型。** 这比下完几十 GB 权重再发现跑不动要便宜得多。

## 二、为什么只能源码编译：glibc 与 manylinux 的错位

环境最终是 CANN 9.1.0（建环境时选 9.0.0 镜像，再用控制台的"CANN 包升级"升到 9.1.0 正式版）。按 vllm-ascend 官方的版本配套表，对应 vllm-ascend 0.23.0、vLLM 0.23.0、torch 2.10.0、torch_npu 2.10.0.post4——配套表里要整行取，不要跨行混搭。

问题出在 pip。镜像的操作系统底子是 Ubuntu 20.04，glibc 2.31；而 vllm-ascend 0.23.0 在 PyPI 上的 aarch64 轮子标签是 `manylinux_2_34`，要求 glibc 不低于 2.34。pip 判定不兼容，只能退回源码包。vLLM 的依赖 tilelang、以及 tilelang 构建时要的 z3-solver 也是同样的情况，而 z3-solver 在 2.31 上编不过去。

最后 vllm-ascend 是在机器上源码编译的，大约 40 分钟。

这件事给我的启发是：**昇腾软件栈正在往新 glibc 迁移，生产机的操作系统选型要跟上。** 如果用 glibc 2.34 以上的发行版（比如 Ubuntu 22.04 及以后），这 40 分钟的编译和后面一连串依赖问题本来都可以避免。

## 三、依赖以谁为准：vllm-ascend，不是 vllm

这是我踩得最冤的一个坑。

PyPI 上的 vllm 轮子是面向 CUDA 构建的：它钉死 `torch==2.11.0`，把 tilelang 写成硬依赖，还会拉进 flashinfer、nvidia-cutlass-dsl 等一串 CUDA 库。按它的元数据安装，会把与 torch_npu 配套的 torch 2.10.0 直接顶掉。

我的做法是 `pip install vllm==0.23.0 --no-deps`，再从它的元数据里剔除 CUDA 专属项，补齐其余依赖。tilelang 可以放心剔除——翻源码会发现，vLLM 里所有用到它的地方都被 `has_tilelang()` 守着，只有 MHC 算子和 DeepSeek-V4 的 AMD 路径才会用到。

但我犯了一个错误：**依赖清单是从 vllm 推出来的，而不是从 vllm-ascend 推出来的。** 结果服务能启动，第一次推理就崩了：

```
File "vllm_ascend/worker/block_table.py", line 165, in compute_slot_mapping
    _compute_slot_mapping_kernel[(num_reqs + 1,)](
TypeError: 'function' object is not subscriptable
```

`kernel[grid](...)` 是 Triton 的内核启动语法。原因是环境里只有原版 Triton、没有 triton-ascend，Triton 找不到可用的驱动而被禁用，`@triton.jit` 退化成了普通函数。

回头去查 vllm-ascend 自己声明的依赖，才发现它明确要求 `triton-ascend==3.2.2`、`transformers==5.5.4`、`torchvision==0.25.0`、`fastapi<0.124.0` 等。补齐之后问题消失。

**经验：在昇腾上部署 vLLM 这类框架，要以插件（vllm-ascend）的依赖表为权威来源，上游框架的依赖表只能参考。**

## 四、四个最费时间的坑

### 1. 脚本静默退出：`set -u` 遇上 set_env.sh

现象：部署脚本一个字都不打印，退出码为 1。原因是我在脚本开头写了 `set -u`，而 CANN 的 `set_env.sh` 里引用了未定义的变量，被 source 时直接把外层 shell 杀掉了。解法很简单：source 之前 `set +u`，之后再恢复。难的是定位——整个过程没有任何报错输出。

### 2. 编译失败，根因埋在几万行日志里

vllm-ascend 编译到算子生成阶段大面积 FAILED，日志几万行。真正的原因在某个 traceback 的最后一行：

```
ModuleNotFoundError: No module named 'decorator'
```

CANN 的算子编译器 tbe/tvm 是用 Python 写的，依赖 decorator、attrs、sympy 等包。我特意用了不继承系统包的干净 venv——为了隔离镜像里预装的、与 CANN 9.1 不配套的 torch 2.7.1——结果这些包也被一起隔离掉了。错误出现在 ninja 的算子生成阶段，看起来像编译器坏了，实际上只是缺几个 Python 包。

### 3. 强杀后的锁文件，以及一个危险的 glob

云实例中途停机后，我续编 vllm-ascend，每个算子都报：

```
RuntimeError: Another process is using this dir
```

这是 TBE 编译器残留的锁文件。它只检查锁文件在不在，不校验里面记录的进程是否还活着，所以进程被强杀后，锁就一直挡着。

清理时我用了 `find -name '*lock*'`，结果连 `block_table.py`、`transpose_kv_cache_by_block.cpp` 这些源文件也一起删掉了——`block` 里正好含有 `lock`。最后只能从源码包重建整个源码树。**清理锁文件请用精确的 `*.lock`。**

### 4. FP8 通路只认 DeepSeek

Qwen3-VL-32B-Instruct-FP8 只有 34 GB，单卡装得下，但一加载就报错：

```
AttributeError: 'Qwen3VLConfig' object has no attribute 'o_groups'
```

看 vllm-ascend 0.23.0 的代码，FP8 量化配置会把所有线性层都映射到 `ds_linear` 方案，而 `ds_linear` 读取的 `o_groups`、`o_lora_rank` 是 DeepSeek MLA 的专有字段。也就是说，**这个版本的 FP8 通路是为 DeepSeek 写的，其他模型的 FP8 权重进不去。** 在昇腾上做量化部署，更稳妥的路线是 ModelSlim 产出的 W8A8（权重目录里带 `quant_model_description.json`）。

## 五、eager 与图编译：同一个模型，差 5.7 倍

链路打通后，我第一次测出的速度只有 10 tok/s 左右，远低于按带宽推算的水平。原因是当时为了绕过一个问题，服务跑在 `--enforce-eager` 模式下。

eager 模式下，Python 逐个把算子下发给 NPU；解码一个 token 要执行几百个小算子，调度开销占了大头。换成图编译（vLLM 默认模式）后，同一个 Qwen3-VL-8B：

| 模式 | 单流速度 |
|---|---|
| `--enforce-eager` | 10.3 tok/s |
| 图编译 | 58.9 tok/s |

图捕获只花了 3 秒，额外占用 0.46 GiB 显存。

顺带记录当初逼我用 eager 的那个问题：在纯文本的 Qwen3-8B 上，图编译阶段报 `torch.ops.vllm.qkv_rmsnorm_rope` 不存在。我查了 0.23.0 的源码，这个算子在 csrc 里没有实现，编译出来的两个 .so 里也搜不到，而 A2 设备走的 `BaseDeviceAdaptor` 会调用它（A5 走的是 Triton 实现的 SIMT 版本）。vllm-ascend 提供了单独关闭这个融合 pass 的开关：

```bash
--additional-config '{"ascend_fusion_config": {"fuse_qknorm_rope": false}}'
```

这个开关我还没来得及在 Qwen3-8B 上实测，记在这里供大家参考。

**体会：eager 模式下测出来的数字，不能拿来做任何选型结论。** 我差点就按 10 tok/s 得出"910B 跑不动"的结论了。

## 六、实测结果

| 模型 | 权重 | KV cache | 32k 上下文并发 | 单流速度 | 带图推理 |
|---|---|---|---|---|---|
| Qwen3-VL-8B（BF16） | 16.63 GB | 254,336 tokens | 7.76 路 | 58.9 tok/s | 57.6 tok/s |
| Qwen3.8-27B（BF16） | 51.08 GiB | 53,739 tokens | 1.64 路 | 19.3 tok/s | 14.4 tok/s |

Qwen3.8-27B 把显存用到了 92%，是我这次在这张卡上跑通的最大模型。

我还用一张模拟的机械附图对比了两个模型的图像理解。图上是一个电机转子组件，用 10～50 五个附图标记分别指向外壳、转子、轴、底座和引出线。两个模型都能读出全部五个数字，但 8B 把轴和几条引出线都当成了"尺寸标注线"；27B 正确理解了这些数字是指向部件的标记，识别出了转轴和引线。**OCR 能力两者差不多，差距在语义理解上。**

## 七、一个可复用的选型方法

折腾到最后，我觉得最有价值的不是某个模型的数字，而是两个经过实测验证的估算公式。

**单流速度：**

```
tok/s ≈ HBM 峰值带宽 ÷ 每 token 需读取的权重字节数 × 0.65
```

0.65 是我在昇腾上观察到的 vLLM 单流解码效率。两次验证：Qwen3-VL-8B 推算 58、实测 58.9；Qwen3.8-27B 推算 18、实测 19.3，误差都在 7% 以内。MoE 模型按激活参数计算读取量。

**KV cache：**

```
每 token KV = 2（K、V）× 全注意力层数 × KV 头数 × head_dim × 2 字节
```

关键在"全注意力层数"。我原本按标准稠密结构推断（64 层、8 个 KV 头，每 token 256 KB），BF16 下单卡只能到 14B 左右。但 Qwen3.8-27B 是混合架构：64 层里只有 16 层是全注意力，其余 48 层是 Gated DeltaNet 线性注意力，状态大小固定，不随 token 增长：

```
2 × 16 × 4 × 256 × 2 = 64 KB/token      ← 标准架构的四分之一
```

正是 KV 被压到了四分之一，51 GiB 权重之后剩下的那点显存，才撑得起五万多 token 的上下文。

**所以单卡能装多大的模型，取决于架构，而不只是参数量。** 有了这两个公式，拿到新模型的 config.json 就能先估出显存占用和速度，只有估不准的才需要上机验证。

## 八、在 CANNLab 上的几点提示

- 只有 `/mnt/workspace` 和 `/home` 是持久化目录，venv、模型权重、源码树都要放在这里。
- 我遇到的实例运行一段时间（36～85 分钟不等）后会停止。长任务要按"随时可能中断"来设计：源码放在持久盘上就地编译，重试时是增量的；模型用 modelscope 下载，支持断点续传。
- 在这个环境里，有的常用 pip 镜像连不上，但 pip 不会报错，只是以几百 KB/s 慢慢爬。建议先测速再选源，华为云镜像实测最快。
- CANN 安装在 `/home/developer/Ascend`。`npu-smi` 需要把 `/usr/local/Ascend/driver/lib64` 加进 `LD_LIBRARY_PATH`，否则会报 `libc_sec.so` 找不到。
- 起视觉模型要加 `VLLM_ASCEND_ENABLE_FLASHCOMM1=0`；Qwen3 的思考链可以在服务端用 `--default-chat-template-kwargs '{"enable_thinking": false}'` 统一关闭，这样任何客户端接进来都是干净输出。

## 九、几点体会

1. **装得下不等于跑得起来。** 显存够只是必要条件，第一道门槛是引擎支持的量化格式和算子。FP8 的例子就是模型进得了显存、引擎却不认。
2. **单卡上限由架构决定。** 混合线性注意力让 27B 在单卡上成为可能，按参数量一刀切会低估硬件。
3. **不要用 eager 数字下结论。** 同一个模型差 5.7 倍，足以让选型结论完全翻转。
4. **读报错要读根因。** `Engine core initialization failed` 只是表象，真正的原因往往在往上几十行的某个 traceback 里。
5. **依赖以插件为准。** vllm-ascend 的依赖表才是昇腾上的权威来源。

## 结语

从最初的 10 tok/s 到图编译后的 58.9 tok/s，从"BF16 单卡上限 14B"到跑通 27B 多模态模型，这次实测让我对 910B 的能力有了比纸面数据准确得多的认识。单卡 910B3 在速度和质量之间需要取舍：8B 快、并发高，27B 质量好但慢。具体选哪个，最终要看业务更在意哪一头。

希望这些踩坑记录和估算方法，能帮到同样在昇腾上部署大模型的朋友。

关键词：vLLM-Ascend、Atlas A2 / 910B、CANN 9.1、Qwen3、多模态、部署实践、问题排查

一张 910B3 能跑多大的模型？——vLLM-Ascend 0.23.0 单卡部署实测、踩坑与选型方法

人工智能

开发工具

硬件

单卡910B3实测跑通Qwen3.8-27B，速度19.3tok/s，混合架构压缩KV缓存是关键。vLLM-Ascend0.23.0部署需源码编译，依赖以插件为准。实测带宽1490GB/s，按0.65效率估算单流速度误差小于7%。FP8通路仅支持DeepSeek，量化推荐W8A8。图编译比eager快5.7倍，选型需实测验证。

图像理解

代码解释

编译器

DeepSeek

Python

2026上云采购 | AI焕新·智启新局

tione

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

单卡910B3实测跑通Qwen3.8-27B，速度19.3tok/s，混合架构压缩KV缓存是关键。vLLM-Ascend0.23.0部署需源码编译，依赖以插件为准。实测带宽1490GB/s，按0.65效率估算单流速度误差小于7%。FP8通路仅支持DeepSeek，量化推荐W8A8。图编译比eager快5.7倍，选型需实...

一张 910B3 能跑多大的模型？——vLLM-Ascend 0.23.0 单卡部署实测、踩坑与选型方法-腾讯云开发者社区-腾讯云

一张 910B3 能跑多大的模型？——vLLM-Ascend 0.23.0 单卡部署实测、踩坑与选型方法

一张 910B3 能跑多大的模型？——vLLM-Ascend 0.23.0 单卡部署实测、踩坑与选型方法

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐