Qwen3.8-27B¶
1 简介¶
Qwen3.8-27B 是 Qwen3.8 系列中 270 亿参数的稠密成员,也是迄今为止 Qwen 开放模型系列中最强大的一代。它构建于 Qwen3.5 的架构基础之上,与 2.4T MoE 旗舰共享相同的混合注意力主干:在其 64 层中,只有 16 层运行完整(门控)注意力(full_attention_interval: 4),其余 48 层运行线性注意力(Gated DeltaNet),并采用恒定的循环状态。它是一个原生视觉语言模型——架构为 Qwen3_5ForConditionalGeneration,且 config.json 包含 vision_config——能够理解图像和视频,并内置 MTP(Multi-Token Prediction)草稿头,以及原生 262,144 个 token 的上下文窗口,可扩展至 1,000,000 个 token。
在编码、专业工作、研究和长时程智能体任务方面,相比 Qwen3.5/Qwen3.6 带来显著提升,Qwen3.8-27B 具备更强的自主规划能力、更可靠的端到端任务完成能力,以及与主流 harness 和开发工具更广泛的下游兼容性。思考模式默认开启,可按请求禁用;推理深度可通过 reasoning_effort(xhigh/medium/low)调节,历史消息中的推理上下文通过 preserve_thinking 保留。
本文档聚焦于 Ascend NPU 上的文本服务。它描述了模型的主要验证步骤,包括支持的功能、前提条件、安装、多节点部署、功能验证、精度和性能评估、性能调优以及常见问题。
本文档基于 vLLM-Ascend 0.23.0 验证并编写。当前模型(Qwen3.8-27B)首次在该版本中获得支持。
2 支持的功能¶
参见 支持的功能 以获取模型的支持功能矩阵。
参见 功能指南 以获取功能配置详情。
3 前提条件¶
3.1 模型权重¶
以下模型权重可用:
| 权重版本 | 硬件要求 | 下载链接 |
|---|---|---|
Qwen3.8-27B(BF16 版本) |
1 台 950DT 产品(96GB × 8)节点或 1 台 950PR 产品(128GB × 8)节点或 1 台 Atlas 800 A3(64GB × 16)节点 或 1 台 Atlas 800 A2(64GB × 8)节点 |
ModelScope |
Qwen3.8-27B-w8a8(量化版本) |
1 台 950PR 产品(128GB × 8)节点或 1 台 Atlas 800 A3(64GB × 16)节点或 1 台 Atlas 800 A2(64GB × 8)节点 | ModelScope |
Qwen3.8-27B-w8a8-mxfp8(量化版本) |
1 台 950DT 产品(96GB × 8)或 1 台 950PR 产品(128GB × 8)节点 | ModelScope |
Qwen3.8-27B-w8a8-310p(量化版本) |
1 台 Atlas 300I DUO | ModelScope |
建议将模型权重下载到多节点共享目录,例如 /root/.cache/。
路径说明:将模型权重下载到您选择的目录并记录该目录。确保后续部署命令中的模型路径与该目录一致。
4 安装¶
4.1 Docker 镜像安装¶
根据您的机器类型选择镜像,并在您的节点上启动 Docker 镜像,参见 使用 Docker。
在每个节点上启动 Docker 镜像。
export IMAGE=quay.io/ascend/vllm-ascend:qwen3.8-a5
export NAME=vllm-ascend
docker run --rm \
--name $NAME \
--net=host \
--shm-size=1g \
--device /dev/davinci0 \
--device /dev/davinci1 \
--device /dev/davinci2 \
--device /dev/davinci3 \
--device /dev/davinci4 \
--device /dev/davinci5 \
--device /dev/davinci6 \
--device /dev/davinci7 \
--device /dev/davinci_manager \
--device /dev/hisi_hdc \
--device /dev/ummu \
--device /dev/uburma \
-v /usr/local/Ascend/driver:/usr/local/Ascend/driver \
-v /etc/ascend_install.info:/etc/ascend_install.info \
-v /etc/hccl_rootinfo.json:/etc/hccl_rootinfo.json \
-v /etc/hixlep/:/etc/hixlep/ \
-v /root/.cache:/root/.cache \
-v /usr/local/sbin:/usr/local/sbin \
-v /usr/local/dcmi:/usr/local/dcmi \
-v /usr/local/bin/npu-smi:/usr/local/bin/npu-smi \
-v /usr/local/sbin/npu-smi:/usr/local/sbin/npu-smi \
-v /usr/lib64:/usr/lib64 \
-it $IMAGE bash
在每个节点上启动 Docker 镜像。
export IMAGE=quay.io/ascend/vllm-ascend:qwen3.8-a3
export NAME=vllm-ascend
docker run --rm \
--name $NAME \
--net=host \
--shm-size=1g \
--device /dev/davinci0 \
--device /dev/davinci1 \
--device /dev/davinci2 \
--device /dev/davinci3 \
--device /dev/davinci4 \
--device /dev/davinci5 \
--device /dev/davinci6 \
--device /dev/davinci7 \
--device /dev/davinci8 \
--device /dev/davinci9 \
--device /dev/davinci10 \
--device /dev/davinci11 \
--device /dev/davinci12 \
--device /dev/davinci13 \
--device /dev/davinci14 \
--device /dev/davinci15 \
--device /dev/davinci_manager \
--device /dev/devmm_svm \
--device /dev/hisi_hdc \
-v /usr/local/dcmi:/usr/local/dcmi \
-v /usr/local/Ascend/driver/tools/hccn_tool:/usr/local/Ascend/driver/tools/hccn_tool \
-v /usr/local/bin/npu-smi:/usr/local/bin/npu-smi \
-v /usr/local/Ascend/driver/lib64/:/usr/local/Ascend/driver/lib64/ \
-v /usr/local/Ascend/driver/version.info:/usr/local/Ascend/driver/version.info \
-v /etc/ascend_install.info:/etc/ascend_install.info \
-v /root/.cache:/root/.cache \
-it $IMAGE bash
在每个节点上启动 Docker 镜像。
export IMAGE=quay.io/ascend/vllm-ascend:qwen3.8-a2
export NAME=vllm-ascend
docker run --rm \
--name $NAME \
--shm-size=1g \
--net=host \
--device /dev/davinci0 \
--device /dev/davinci1 \
--device /dev/davinci2 \
--device /dev/davinci3 \
--device /dev/davinci4 \
--device /dev/davinci5 \
--device /dev/davinci6 \
--device /dev/davinci7 \
--device /dev/davinci_manager \
--device /dev/devmm_svm \
--device /dev/hisi_hdc \
-v /usr/local/dcmi:/usr/local/dcmi \
-v /usr/local/Ascend/driver/tools/hccn_tool:/usr/local/Ascend/driver/tools/hccn_tool \
-v /usr/local/bin/npu-smi:/usr/local/bin/npu-smi \
-v /usr/local/Ascend/driver/lib64/:/usr/local/Ascend/driver/lib64/ \
-v /usr/local/Ascend/driver/version.info:/usr/local/Ascend/driver/version.info \
-v /etc/ascend_install.info:/etc/ascend_install.info \
-v /root/.cache:/root/.cache \
-it $IMAGE bash
在每个节点上启动 Docker 镜像。
export IMAGE=quay.io/ascend/vllm-ascend:v0.23.0-310p
export NAME=vllm-ascend
docker run --rm \
--name $NAME \
--shm-size=1g \
--device /dev/davinci0 \
--device /dev/davinci1 \
--device /dev/davinci2 \
--device /dev/davinci3 \
--device /dev/davinci4 \
--device /dev/davinci5 \
--device /dev/davinci6 \
--device /dev/davinci7 \
--device /dev/davinci_manager \
--device /dev/devmm_svm \
--device /dev/hisi_hdc \
-v /usr/local/dcmi:/usr/local/dcmi \
-v /usr/local/bin/npu-smi:/usr/local/bin/npu-smi \
-v /usr/local/Ascend/driver/lib64/:/usr/local/Ascend/driver/lib64/ \
-v /usr/local/Ascend/driver/version.info:/usr/local/Ascend/driver/version.info \
-v /etc/ascend_install.info:/etc/ascend_install.info \
-v /root/.cache:/root/.cache \
-it $IMAGE bash
进入容器后,验证 vLLM 和 vLLM-Ascend 是否可以导入:
预期输出:
4.2 源代码安装¶
你也可以从源代码构建并安装 vllm-ascend。请参阅 使用 Python 设置。
如果要部署多节点服务,请在每个节点上安装相同版本的 vLLM 和 vLLM-Ascend。
Note
在 Atlas 300I DUO 上,你可能需要卸载 triton-ascend 和 triton,以避免依赖冲突:
5 在线服务部署¶
5.1 单节点在线部署¶
单节点部署在同一节点内同时完成 Prefill 和 Decode,适用于开发、测试和中等规模推理场景。在 Atlas 300I DUO 上,至少需要 2 个设备。
启动服务前:
- 将模型路径、并行大小和服务端口替换为目标环境中的值。
以下示例适用于 950DT 产品。
#!/bin/sh
# Load model from ModelScope to speed up download
export MODEL_PATH=Eco-Tech/Qwen3.8-27B-w8a8-mxfp8
export VLLM_USE_MODELSCOPE=True
export HCCL_BUFFSIZE=512
export PYTORCH_NPU_ALLOC_CONF=expandable_segments:True
# Size of the shared buffer (in MB) used by HCCL for NPU-to-NPU collective communication
# To reduce memory fragmentation and avoid out of memory
# Model weight path; can be a ModelScope model id (e.g., Eco-Tech/Qwen3.8-27B-w8a8-mxfp8) or a local directory path
# Ensure the model path matches the directory recorded during download
vllm serve $MODEL_PATH \
--host 0.0.0.0 \
--port 8000 \
--data-parallel-size 1 \
--tensor-parallel-size 1 \
--quantization ascend \
--served-model-name qwen3.8 \
--max-num-seqs 32 \
--max-model-len 131072 \
--max-num-batched-tokens 16384 \
--trust-remote-code \
--enable-prefix-caching \
--gpu-memory-utilization 0.85 \
--speculative-config '{"method": "qwen3_5_mtp", "num_speculative_tokens": 3, "enforce_eager": true}' \
--compilation-config '{"cudagraph_mode":"FULL_DECODE_ONLY"}' \
--additional-config '{"enable_cpu_binding":true}'
关键参数说明:
--data-parallel-size 1和--tensor-parallel-size 1是数据并行(DP)和张量并行(TP)大小的常见设置。--max-model-len表示上下文长度,即单个请求的输入加输出的最大值。--max-num-seqs表示每个 DP 组允许处理的最大请求数。如果发送到服务的请求数超过此限制,超出的请求将保持等待状态,不会被调度。请注意,等待状态所花费的时间也会计入 TTFT 和 TPOT 等指标。因此,在测试性能时,通常建议--max-num-seqs*--data-parallel-size>= 实际总并发数。--max-num-batched-tokens表示模型在单个步骤中可以处理的最大 token 数。目前,vLLM v1 调度默认启用 ChunkPrefill/SplitFuse,这意味着:- (1) 如果请求的输入长度大于
--max-num-batched-tokens,将根据--max-num-batched-tokens分成多轮计算; - (2) Decode 请求优先调度,仅在有可用容量时才调度 prefill 请求。
- 通常,如果将
--max-num-batched-tokens设置为较大的值,整体延迟会更低,但对 HBM 内存(激活值使用)的压力会更大。
- (1) 如果请求的输入长度大于
--gpu-memory-utilization表示 vLLM 将用于实际推理的 HBM 比例。其本质功能是计算可用的 kv_cache 大小。在预热阶段(在 vLLM 中称为 profile run),vLLM 会记录输入大小为--max-num-batched-tokens的推理过程中的峰值 HBM 内存使用量。然后,可用的 kv_cache 大小计算为:--gpu-memory-utilization* HBM 大小 - 峰值 HBM 内存使用量。因此,--gpu-memory-utilization的值越大,可用的 kv_cache 就越多。然而,由于预热阶段的 HBM 内存使用量可能与实际推理期间不同(例如,由于 EP 负载不均衡),将--gpu-memory-utilization设置得过高可能会导致实际推理中出现 OOM(内存不足)问题。默认值为0.9。--quantization ascend表示使用量化。若要禁用量化,请移除此选项。--enable-prefix-caching启用自动前缀缓存。--speculative-config对Qwen3.8-27B使用qwen3_5_mtp,因为它与Qwen3.5-27B共享相同的 MTP 头设计。--compilation-config包含与 aclgraph 图模式相关的配置。最重要的配置是"cudagraph_mode"和"cudagraph_capture_sizes",其含义如下:"cudagraph_mode":表示具体的图模式。目前支持"PIECEWISE"和"FULL_DECODE_ONLY"。图模式主要用于降低算子调度开销。目前推荐"FULL_DECODE_ONLY"。"cudagraph_capture_sizes":表示不同级别的图模式。默认值为[1, 2, 4, 8, 16, 24, 32, 40,..., --max-num-seqs]。在图模式中,不同级别图的输入是固定的,级别之间的输入会自动填充到下一个级别。目前推荐默认设置。只有在某些场景中,才需要单独设置此项以实现最佳性能。
=== "950PR 产品" {#950pr-products}
以下示例适用于 950PR 产品。量化版本需要 `--quantization ascend`。在 950PR 产品上,`Qwen3.8-27B-w8a8` 是当前推荐的权重;后续经过进一步优化后,可切换到 `Qwen3.8-27B-w8a8-mxfp8`。
```bash
#!/bin/sh
# Load model from ModelScope to speed up download
export VLLM_USE_MODELSCOPE=True
# Size of the shared buffer (in MB) used by HCCL for NPU-to-NPU collective communication
export HCCL_BUFFSIZE=512
# To reduce memory fragmentation and avoid out of memory
export PYTORCH_NPU_ALLOC_CONF=expandable_segments:True
# Model weight path; can be a ModelScope model id (e.g., Eco-Tech/Qwen3.8-27B-w8a8) or a local directory path
# Ensure the model path matches the directory recorded during download
export MODEL_PATH=Eco-Tech/Qwen3.8-27B-w8a8
vllm serve $MODEL_PATH \
--host 0.0.0.0 \
--port 8000 \
--data-parallel-size 1 \
--tensor-parallel-size 1 \
--quantization ascend \
--served-model-name qwen3.8 \
--max-num-seqs 32 \
--max-model-len 256000 \
--max-num-batched-tokens 16384 \
--trust-remote-code \
--enable-prefix-caching \
--gpu-memory-utilization 0.9 \
--speculative-config '{"method": "qwen3_5_mtp", "num_speculative_tokens": 3, "enforce_eager": true}' \
--compilation-config '{"cudagraph_mode":"FULL_DECODE_ONLY"}' \
--additional-config '{"enable_cpu_binding":true}'
```
关键参数说明:
- `--data-parallel-size 1` 和 `--tensor-parallel-size 1` 是数据并行(DP)和张量并行(TP)大小的常见设置。
- `--max-model-len` 表示上下文长度,即单个请求的输入加输出的最大值。
- `--max-num-seqs` 表示每个 DP 组允许处理的最大请求数。如果发送到服务的请求数超过该限制,超出的请求将保持等待状态,不会被调度。请注意,等待状态所花费的时间也会计入 TTFT 和 TPOT 等指标。因此,在测试性能时,通常建议 `--max-num-seqs` * `--data-parallel-size` >= 实际总并发数。
- `--max-num-batched-tokens` 表示模型在单个步骤中可处理的最大 token 数。当前,vLLM v1 调度默认启用 ChunkPrefill/SplitFuse,其含义为:
- (1) 如果请求的输入长度大于 `--max-num-batched-tokens`,则会根据 `--max-num-batched-tokens` 将其拆分为多轮计算;
- (2) 解码请求优先调度,仅在有可用容量时才调度预填充请求。
- 通常,如果将 `--max-num-batched-tokens` 设置为更大的值,整体延迟会更低,但对 HBM 内存(激活值占用)的压力会更大。
- `--gpu-memory-utilization` 表示 vLLM 将用于实际推理的 HBM 比例。其核心功能是计算可用的 kv_cache 大小。在预热阶段(在 vLLM 中称为 profile run),vLLM 会记录输入大小为 `--max-num-batched-tokens` 的推理过程中的峰值 HBM 内存使用量。随后,可用的 kv_cache 大小按以下方式计算:`--gpu-memory-utilization` * HBM 大小 - 峰值 HBM 内存使用量。因此,`--gpu-memory-utilization` 的值越大,可使用的 kv_cache 就越多。但是,由于预热阶段的 HBM 内存使用量可能与实际推理时不同(例如由于 EP 负载不均衡),将 `--gpu-memory-utilization` 设置得过高可能会导致实际推理中出现 OOM(内存不足)问题。默认值为 `0.9`。
- `--quantization ascend` 表示使用量化。若要禁用量化,请移除该选项。
- `--enable-prefix-caching` 启用自动前缀缓存。
- `--speculative-config` 对 `Qwen3.8-27B` 使用 `qwen3_5_mtp`,因为它与 `Qwen3.5-27B` 共享相同的 MTP 头设计。
- `--compilation-config` 包含与 aclgraph 图模式相关的配置。最重要的配置是 `"cudagraph_mode"` 和 `"cudagraph_capture_sizes"`,其含义如下:
- `"cudagraph_mode"`:表示具体的图模式。当前支持 `"PIECEWISE"` 和 `"FULL_DECODE_ONLY"`。图模式主要用于降低算子调度开销。当前推荐 `"FULL_DECODE_ONLY"`。
- `"cudagraph_capture_sizes"`:表示不同级别的图模式。默认值为 `[1, 2, 4, 8, 16, 24, 32, 40,..., --max-num-seqs]`。在图模式下,不同级别图的输入是固定的,级别之间的输入会自动填充到下一级别。当前推荐默认设置。只有在某些场景下,才需要单独设置该项以获得最佳性能。
- `--additional-config '{"enable_cpu_binding":true}'` 将 OMP 线程绑定到固定的 CPU 核心。在单台 950PR 产品上,这是实测中最大的性能杠杆:单流解码在没有该设置时为 32 tok/s,启用后为 63 tok/s。
=== "Atlas 800 A3 / Atlas 800 A2" {#atlas-800-a3-atlas-800-a2}
以下示例适用于 Atlas 800 A3 / Atlas 800 A2。
```bash
#!/bin/sh
# Load model from ModelScope to speed up download
export MODEL_PATH=Eco-Tech/Qwen3.8-27B-w8a8
export VLLM_USE_MODELSCOPE=True
export HCCL_BUFFSIZE=512
export PYTORCH_NPU_ALLOC_CONF=expandable_segments:True
# Size of the shared buffer (in MB) used by HCCL for NPU-to-NPU collective communication
# To reduce memory fragmentation and avoid out of memory
# Model weight path; can be a ModelScope model id (e.g., Eco-Tech/Qwen3.8-27B-w8a8) or a local directory path
# Ensure the model path matches the directory recorded during download
vllm serve $MODEL_PATH \
--host 0.0.0.0 \
--port 8000 \
--data-parallel-size 1 \
--tensor-parallel-size 2 \
--quantization ascend \
--served-model-name qwen3.8 \
--max-num-seqs 32 \
--max-model-len 131072 \
--max-num-batched-tokens 16384 \
--trust-remote-code \
--enable-prefix-caching \
--gpu-memory-utilization 0.85 \
--speculative-config '{"method": "qwen3_5_mtp", "num_speculative_tokens": 3, "enforce_eager": true}' \
--compilation-config '{"cudagraph_mode":"FULL_DECODE_ONLY"}' \
--additional-config '{"enable_cpu_binding":true}'
```
关键参数说明:¶
--data-parallel-size 1和--tensor-parallel-size 2是数据并行(DP)和张量并行(TP)大小的常见设置。--max-model-len表示上下文长度,即单个请求的输入加输出的最大值。--max-num-seqs表示每个 DP 组允许处理的最大请求数。如果发送到服务的请求数超过此限制,多余的请求将保持在等待状态,不会被调度。请注意,等待状态所花费的时间也会计入 TTFT 和 TPOT 等指标。因此,在进行性能测试时,通常建议--max-num-seqs*--data-parallel-size>= 实际总并发数。--max-num-batched-tokens表示模型在单步中能够处理的最大 token 数。目前,vLLM v1 调度默认启用 ChunkPrefill/SplitFuse,这意味着:- (1) 如果请求的输入长度大于
--max-num-batched-tokens,则会根据--max-num-batched-tokens分为多轮计算; - (2) Decode 请求优先调度,只有在有可用容量时才调度 prefill 请求。
- 一般来说,如果将
--max-num-batched-tokens设置为更大的值,整体延迟会更低,但 HBM 内存(激活值使用)的压力会更大。
- (1) 如果请求的输入长度大于
--gpu-memory-utilization表示 vLLM 将用于实际推理的 HBM 内存比例。其核心作用是计算可用的 kv_cache 大小。在预热阶段(vLLM 中称为 profile run),vLLM 会记录在输入大小为--max-num-batched-tokens的推理过程中的 HBM 峰值内存使用量。可用的 kv_cache 大小按下式计算:--gpu-memory-utilization* HBM 大小 - HBM 峰值内存使用量。因此,--gpu-memory-utilization的值越大,可用的 kv_cache 就越多。但是,由于预热阶段的 HBM 内存使用量可能与实际推理期间不同(例如,由于 EP 负载不均衡),将--gpu-memory-utilization设置得过高可能会导致实际推理期间出现 OOM(内存不足)问题。默认值为0.9。--quantization ascend表示使用量化。如需禁用量化,请移除该选项。--enable-prefix-caching启用自动前缀缓存。--speculative-config对Qwen3.8-27B使用qwen3_5_mtp,因为它与Qwen3.5-27B共享相同的 MTP head 设计。--compilation-config包含与 aclgraph 图模式相关的配置。其中最重要的配置是"cudagraph_mode"和"cudagraph_capture_sizes",含义如下:"cudagraph_mode":表示具体的图模式。目前支持"PIECEWISE"和"FULL_DECODE_ONLY"。图模式主要用于降低算子分发成本。目前推荐使用"FULL_DECODE_ONLY"。"cudagraph_capture_sizes":表示不同级别的图模式。默认值为[1, 2, 4, 8, 16, 24, 32, 40,..., --max-num-seqs]。在图模式下,不同级别图的输入是固定的,级别之间的输入会自动填充到下一级别。目前推荐使用默认设置。仅在少数场景下需要单独设置该参数以获得最佳性能。
目前仅支持 TP 场景。请根据可用设备选择 TP=2 或 TP=4。将 MODEL_PATH 替换为 ModelScope 模型 ID 或本地目录路径。量化版本需要使用 --quantization ascend 参数启动。
启动命令:¶
#!/bin/sh
# Load model from ModelScope to speed up download
export VLLM_USE_MODELSCOPE=True
# Model weight path; can be a ModelScope model id (e.g., Eco-Tech/Qwen3.8-27B-w8a8) or a local directory path
# Ensure the model path matches the directory recorded during download
export MODEL_PATH=Eco-Tech/Qwen3.8-27B-w8a8-310p
vllm serve $MODEL_PATH \
--host 127.0.0.1 \
--port 8000 \
--tensor-parallel-size 4 \
--served-model-name qwen3.8 \
--max-num-seqs 128 \
--max-model-len 16384 \
--trust-remote-code \
--gpu-memory-utilization 0.90 \
--mamba-ssm-cache-dtype float16 \
--dtype float16 \
--speculative-config '{"method": "qwen3_5_mtp","num_speculative_tokens":1}' \
--compilation-config '{"cudagraph_mode": "FULL_DECODE_ONLY", "cudagraph_capture_sizes": [2,16]}' \
--additional-config '{"ascend_compilation_config": {"enable_npugraph_ex": false}}'
关键参数说明:¶
--tensor-parallel-size设置张量并行大小。请根据可用设备选择 TP=2 或 TP=4。--max-model-len表示上下文长度,即单个请求的输入加输出的最大值。请根据实际工作负载和可用内存进行配置;Qwen3.8-27B最高支持 262144。--max-num-seqs表示最大并发请求数。请根据需要进行配置——设置过高可能会导致 OOM。--gpu-memory-utilization表示 vLLM 将用于实际推理的 HBM 内存比例。请根据实际设备内存配置此值;设置过高可能会导致 OOM。默认值为0.9。--mamba-ssm-cache-dtype设置 Mamba SSM 缓存的数据类型。在 Atlas 300I DUO 上,仅支持float16。- 在 Atlas 300I DUO 上必须设置
--dtype float16。这些设备仅支持 FP16 数据类型。 --speculative-config对Qwen3.8-27B使用qwen3_5_mtp,因为它与Qwen3.5-27B共享相同的 MTP head 设计。在 Atlas 300I DUO 上,建议将num_speculative_tokens设置为1。--compilation-config包含与 aclgraph 图模式相关的配置。其中最重要的配置是"cudagraph_mode"和"cudagraph_capture_sizes",含义如下:"cudagraph_mode":表示具体的图模式。目前支持"PIECEWISE"和"FULL_DECODE_ONLY"。图模式主要用于降低算子分发成本。目前推荐使用"FULL_DECODE_ONLY"。"cudagraph_capture_sizes":表示不同级别的图模式。当启用张量并行(TP)时,受硬件 event-id 限制,最多允许两个捕获大小(例如,[1, 8])。 启用 MTP 后,将每个捕获大小计算为n * (num_speculative_tokens + 1),其中n是未启用 MTP 部署时的捕获大小。例如,当num_speculative_tokens为1时,非 MTP 大小[1,2,4,8]变为[2,4,8,16]。
- 在 Atlas 300I DUO 上,必须使用
--additional-config并设置"ascend_compilation_config": {"enable_npugraph_ex": false},因为该平台不支持enable_npugraph_ex。
等待引擎完成权重加载和图捕获。成功启动时,输出类似于以下内容:
INFO: Started server process
INFO: Waiting for application startup.
INFO: Application startup complete.
6 功能验证¶
服务启动后,可以通过发送 prompt 来调用模型。支持两个 API 接口:completions 和 chat/completions。请使用您配置的 --served-model-name(对于 Qwen3.8-27B 为 qwen3.8)。
Completions API:
curl http://localhost:8000/v1/completions \
-H "Content-Type: application/json" \
-d '{
"model": "qwen3.8",
"prompt": "The future of AI is",
"max_tokens": 50,
"temperature": 0.7
}'
Chat Completions API:
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "qwen3.8",
"messages": [
{"role": "user", "content": "The future of AI is"}
],
"max_completion_tokens": 1024,
"temperature": 1.0,
"top_p": 0.95
}'
预期结果:服务返回 HTTP 200 OK。JSON 响应包含带有生成文本的 choices 字段。以下是 completions API 的示例输出(为简洁起见,内容已截断):
{
"id": "cmpl-xxxxxxxxxxxxx",
"object": "text_completion",
"created": 1780971952,
"model": "qwen3.8",
"choices": [
{
"index": 0,
"text": "The future of AI is a rapidly evolving landscape with breakthroughs in natural language understanding, multimodal reasoning, and autonomous agents. As models grow more capable and efficient...",
"logprobs": null,
"finish_reason": "length"
}
],
"usage": {
"prompt_tokens": 4,
"total_tokens": 54,
"completion_tokens": 50
}
}
7 准确性评估¶
以下是一种准确性评估方法。
7.1 使用 AISBench¶
-
有关详细信息,请参阅 使用 AISBench。
-
执行完成后,您可以获取结果。以下是
Qwen3.8-27B、Qwen3.8-27B-w8a8和Qwen3.8-27B-w8a8-mxfp8在vllm-ascend:v0.23.0rc1中的结果,仅供参考。
| 数据集 | 模型 | 指标 | 模式 | vllm-api-general-chat |
|---|---|---|---|---|
| GPQA Diamond | Qwen3.8-27B | accuracy | gen | 90.40 |
| GPQA Diamond | Qwen3.8-27B-w8a8 | accuracy | gen | 89.90 |
| GPQA Diamond | Qwen3.8-27B-w8a8-mxfp8 | accuracy | gen | 89.39 |
8 性能评估¶
8.1 使用 AISBench¶
有关详细信息,请参阅 使用 AISBench 进行性能评估。
8.2 使用 vLLM 基准测试¶
以运行 Qwen3.8-27B-w8a8 的性能评估为例。
有关更多详细信息,请参阅 vllm benchmark。
| 参数 | 标准部署 | 性能测试 |
|---|---|---|
--max-model-len |
256000 | 250000 |
--max-num-batched-tokens |
16384 | 8192 |
--gpu-memory-utilization |
0.9 | 0.95 |
vllm bench 有三个子命令:
latency:基准测试单个请求批次的延迟。serve:基准测试在线服务吞吐量。throughput:基准测试离线推理吞吐量。
以 serve 为例。按如下方式运行代码。
export VLLM_USE_MODELSCOPE=True
# For Qwen3.8-27B-w8a8:
vllm bench serve --model Eco-Tech/Qwen3.8-27B-w8a8 --dataset-name random --random-input 200 --num-prompts 200 --request-rate 1 --save-result --result-dir ./
大约几分钟后,您可以获取性能评估结果。
9 性能调优¶
9.1 推荐配置¶
注意:当前文档侧重于 Qwen3.8-27B 模型在 Ascend NPU 上的快速适配和验证。性能调优结果尚未完全验证。典型场景(例如长上下文、低延迟和高吞吐量)的推荐配置将在相应验证完成后在此处补充和更新。在此期间,请参阅 第 9.2 节 获取通用调优指导。
Atlas 300I DUO:目前仅支持 TP 场景。根据可用设备选择 TP=2 或 TP=4。使用 TP=4 时,
--max-model-len可支持 128k 和 256k 长序列场景;根据需要配置--max-num-seqs——设置过高可能导致 OOM。
9.2 调优指南¶
9.2.1 通用调优参考¶
请参阅 公开性能调优文档 了解调优方法。 请参阅 功能矩阵 了解详细功能说明。
9.2.2 模型特定优化¶
默认启用的优化¶
以下优化默认启用,无需额外配置:
| 优化技术 | 技术原理 | 性能收益 |
|---|---|---|
| 分块预填充 | vLLM V1 调度器将长预填充输入拆分为块,每个步骤最多处理 --max-num-batched-tokens 个 token。 |
降低每步内存峰值,从而支持更大的批处理大小和更高的吞吐量。 |
| 完整解码 ACL 图 | 使用 --compilation-config '{"cudagraph_mode":"FULL_DECODE_ONLY"}' 一次性捕获并重放整个解码图。 |
降低每步算子调度开销,稳定解码延迟。 |
| CPU 绑定 | 通过 --additional-config '{"enable_cpu_binding":true}' 将工作线程绑定到专用 CPU 核心。 |
减少 CPU 调度抖动,稳定解码延迟。 |
需要显式启用的优化¶
| 优化技术 | 适用场景 | 启用方法 | 技术原理 | 注意事项 |
|---|---|---|---|---|
| 优化技术 | 适用场景 | 启用方法 | 技术原理 | 注意事项 |
|---|---|---|---|---|
| 前缀缓存 | 存在重复前缀的场景(例如共享系统 Prompt、少样本示例) | --enable-prefix-caching |
复用重复前缀的缓存 KV 状态,避免冗余的 prefill 计算。 | 收益取决于前缀缓存命中率。 |
| Qwen3.5 MTP 推测解码 | 具有可接受接受率的以解码为主的工作负载 | --speculative-config '{"method":"qwen3_5_mtp","num_speculative_tokens":3}' |
使用内置 MTP 草稿头,每步推测多个 Token,并在单次前向传播中验证它们。 | 根据目标工作负载调整推测 Token 数量;收益取决于接受率。 |
10 常见问题¶
对于常见环境、安装和通用参数问题,请参阅公共 FAQ。
本页原文 Markdown:在 AtomGit 查看·内容源自开源项目 vl/vllm-ascend