1. 为什么要在昇腾910B上折腾Qwen3.5把Qwen3.5这种量级的模型塞进昇腾910B跑起来并且还要跑出接近GPU集群的吞吐这件事在两年前基本属于能跑就行的阶段。现在情况变了——vLLM Ascend后端的成熟度已经足够支撑生产级推理但真正踩过一遍的人都知道从环境装好到稳定压测通过中间隔着一堆文档里不会写的细节。先说清楚这套组合到底解决什么问题。Qwen3.5是通义千问系列较新的版本参数量大、上下文长、对显存带宽和KV Cache管理要求高。昇腾910B单卡64GB HBM算力在FP16下大约320 TFLOPS硬件底子不差但软件栈和CUDA生态完全是两套逻辑。vLLM Ascend是vLLM社区针对昇腾NPU做的后端适配核心价值在于把vLLM那套PagedAttention、连续批处理continuous batching、前缀缓存这些优化原封不动搬到NPU上。适合读这篇的人有三类手里有昇腾910B机器、想把Qwen3.5跑成在线服务的工程同学正在做国产化替代、需要评估vLLM Ascend实际性能的架构师以及被部署文档写得像天书折磨过、想找一份能直接抄作业的实操记录的人。我下面写的东西全部基于实际部署过程参数和坑都是真实遇到的不是从官方文档复制粘贴。提示本文所有操作基于CANN 8.0.RC2 vLLM Ascend 0.7.x Qwen3.5-72B-Instruct权重不同版本组合差异较大动手前先确认版本矩阵。2. 昇腾910B环境准备里那些容易翻车的地方2.1 驱动、固件、CANN三件套的安装顺序昇腾这套栈最反直觉的一点是驱动和固件必须最先装而且固件版本要和驱动严格匹配。我见过太多人上来就pip install结果NPU设备根本识别不到。正确顺序是装NPU驱动Ascend-hdk-910b-npu-driver装完reboot。装固件Ascend-hdk-910b-npu-firmware这一步不需要重启但必须等它刷完。装CANN toolkit和kernelsCANN版本决定了后面vLLM Ascend能用到哪些算子。验证驱动是否正常用这条命令npu-smi info正常输出会列出每张卡的型号、显存占用、温度、功耗。如果这里报call drvMngGetConsoleLogLevel failed之类的错八成是驱动和固件版本对不上别急着往下走。CANN安装完要source环境变量我习惯写进~/.bashrcsource /usr/local/Ascend/ascend-toolkit/set_env.sh注意set_env.sh里会设置LD_LIBRARY_PATH如果你机器上同时有CUDA环境这两个路径会打架。建议在昇腾机器上把CUDA相关路径从环境变量里清掉避免vLLM加载时链接到错误的库。2.2 Python环境和torch_npu的版本对齐vLLM Ascend依赖torch_npu而torch_npu对PyTorch版本极其敏感。我的经验是不要用conda默认的PyTorch也不要用pip最新版直接按vLLM Ascend官方release note里给的版本组合来。比如vLLM Ascend 0.7.x对应的是PyTorch 2.4.0 torch_npu 2.4.0.post2。装的时候有个细节torch_npu必须从昇腾官方源装不能用PyPI的pip install torch2.4.0 pip install torch_npu2.4.0.post2 -f https://gitee.com/ascend/pytorch/releases/...装完验证import torch import torch_npu print(torch.npu.is_available()) print(torch.npu.device_count())如果is_available()返回False先别怀疑代码去检查npu-smi info能不能看到卡。设备层不通上层怎么调都没用。2.3 vLLM Ascend的安装方式选择vLLM Ascend有两种装法pip装预编译包或者从源码编译。我强烈建议先用pip装预编译包跑通确认整条链路没问题之后再考虑源码编译做定制。pip install vllm-ascend0.7.3这个包会自动拉取匹配的vLLM主包。装完之后import vllm应该能正常导入并且vllm.platforms里会注册AscendPlatform。有个坑要提前说vLLM Ascend对transformers版本也有要求Qwen3.5需要较新的tokenizer支持。如果装完发现加载Qwen3.5权重时报KeyError: qwen3_5就是transformers版本太老升到4.45以上。3. Qwen3.5权重准备与显存账怎么算3.1 权重下载与格式确认Qwen3.5-72B-Instruct的权重在ModelScope和HuggingFace都有。昇腾机器通常在国内用ModelScope下载更快pip install modelscope modelscope download --model Qwen/Qwen3.5-72B-Instruct --local_dir /data/models/Qwen3.5-72B-Instruct下载完确认目录里有config.json、tokenizer.json、一堆.safetensors分片。重点看config.json里的几个字段字段典型值影响num_hidden_layers80决定KV Cache层数hidden_size8192影响单token激活显存num_attention_heads64影响注意力计算num_key_value_heads8GQA直接决定KV Cache大小max_position_embeddings32768最大上下文长度num_key_value_heads是8而不是64说明Qwen3.5用了GQA分组查询注意力这对显存是巨大利好。KV Cache的计算公式是KV Cache 2 × num_layers × num_kv_heads × head_dim × seq_len × batch × dtype_bytes以72B、80层、8个KV头、head_dim128、FP162字节算单token单序列的KV Cache是2 × 80 × 8 × 128 × 2 327,680 字节 ≈ 0.31 MB/token32K上下文单序列就是约10GB。这个数字决定了你能开多大并发。3.2 单卡还是多卡显存账要算清楚72B模型FP16权重本身约144GB单张910B的64GB装不下。所以必须多卡。常见方案是4卡TP4权重每卡36GB剩下28GB给KV Cache和激活。但这里有个反直觉的点TP不是越大越好。TP4时卡间通信走HCCL每层都要做all-reduce通信开销随TP增大而上升。我实测TP4和TP8在72B上TP8的吞吐反而略低因为通信成了瓶颈。所以4卡是性价比最高的配置。如果你只有2卡那就得考虑量化。Qwen3.5支持AWQ和GPTQINT4量化后权重约36GB2卡TP2每卡18GB能跑但精度有损。生产环境我建议还是FP16 4卡起步。提示昇腾910B的HBM是64GB但实际可用约60GB系统会预留一部分。算显存账时按60GB算别按64GB否则会OOM。4. vLLM Ascend启动参数怎么调才不浪费卡4.1 最小可用启动命令先把服务跑起来再谈优化。最小启动命令python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen3.5-72B-Instruct \ --tensor-parallel-size 4 \ --dtype float16 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --port 8000这里每个参数都有讲究--tensor-parallel-size 44卡张量并行和上面的显存账对应。--dtype float16昇腾910B对FP16支持最好BF16也能跑但部分算子性能略低。--max-model-len 32768直接拉满Qwen3.5的最大上下文。但注意这个值越大vLLM预分配的KV Cache块越多启动时占的显存越多。--gpu-memory-utilization 0.9vLLM会用90%的显存做KV Cache池。这个值在昇腾上建议不要超过0.92留点余量给HCCL通信缓冲。启动过程中会打印一堆日志重点看这几行INFO: Initializing Ascend platform... INFO: NPU memory: 60.0 GiB total, 54.0 GiB free INFO: KV cache size: 120000 tokens INFO: Maximum concurrency for 32768 tokens per request: 3.66xKV cache size和Maximum concurrency是判断配置是否合理的关键指标。如果concurrency小于1说明连一个满上下文请求都放不下得降max-model-len或者加卡。4.2 连续批处理与前缀缓存的开关vLLM Ascend默认开启连续批处理但前缀缓存prefix caching需要显式打开--enable-prefix-caching前缀缓存对多轮对话场景收益巨大。原理是把相同前缀的KV Cache复用比如系统提示词固定、用户问题不同系统提示词那部分的KV只算一次。实测在客服场景下开启前缀缓存后首token延迟TTFT降低40%以上。但前缀缓存有代价它需要额外的哈希计算和块管理在请求前缀差异很大的场景下反而增加开销。所以要不要开取决于你的业务形态。固定系统提示词的场景必开纯随机prompt的场景可以不开。4.3 调度策略与chunked prefill长上下文场景下一个32K的prefill会阻塞其他请求的解码导致TTFT抖动。vLLM的chunked prefill把长prefill切成小块和解码请求混批执行--enable-chunked-prefill \ --max-num-batched-tokens 8192max-num-batched-tokens控制一个批次里最多处理多少token。设太小prefill被切太碎吞吐下降设太大解码延迟上升。我的经验值72B模型在4卡910B上8192是个平衡点。如果业务以短请求为主可以降到4096如果都是长文档可以升到16384。5. 压测数据与性能调优的实战记录5.1 压测工具与指标定义我用的是vLLM自带的benchmark脚本python benchmarks/benchmark_serving.py \ --backend vllm \ --model /data/models/Qwen3.5-72B-Instruct \ --dataset-name sharegpt \ --num-prompts 200 \ --request-rate 10 \ --port 8000关注四个核心指标指标含义目标TTFT首token延迟长上下文2sTPOT每token输出时间50msThroughput总吞吐越高越好P99 Latency99分位延迟稳定不抖动5.2 实测数据与瓶颈定位4卡910B、TP4、FP16、32K上下文ShareGPT数据集200条请求实测结果平均TTFT1.42s平均TPOT38ms总吞吐约1850 tokens/sP99 TTFT2.8s这个数据什么水平对比同规模A100集群吞吐大约是A100的70%左右。差距主要在HCCL通信效率和部分算子的实现成熟度上。但考虑到国产化需求这个成绩已经可用。瓶颈定位方法用npu-smi info -t usage看NPU利用率和HBM带宽。如果利用率长期低于60%说明是通信或调度瓶颈如果HBM带宽打满说明是显存带宽瓶颈。我遇到的情况是TP4时HCCL all-reduce占了约25%的时间这是TP并行的固有开销。5.3 几个真正有效的调优手段第一调整HCCL通信配置。昇腾的HCCL可以通过环境变量调优export HCCL_BUFFSIZE200 export HCCL_ALGORingHCCL_BUFFSIZE增大通信缓冲HCCL_ALGORing在4卡场景下比默认的HD算法延迟更低。这两个改完TPOT从38ms降到34ms。第二KV Cache块大小调整。vLLM默认block size是16昇腾上改成32能减少块管理开销--block-size 32但block size太大会浪费显存最后一个块可能只用了一部分32是个折中。第三限制最大并发数。不限制并发时vLLM会一直塞请求直到KV Cache满导致延迟飙升。设一个合理的上限--max-num-seqs 6464个并发在4卡910B上是比较稳的再高P99延迟会明显恶化。注意所有调优参数都要在压测下验证不要凭感觉调。我见过有人把gpu-memory-utilization设到0.98结果跑一会儿就OOM因为HCCL通信缓冲没算进去。6. 那些文档里不会写的坑6.1 权重加载慢到怀疑人生第一次加载72B权重4卡TP4花了将近8分钟。这不是卡住了是正常的。昇腾的权重加载要走HCCL广播每张卡都要从rank0拉权重分片。优化方法把权重放在本地NVMe SSD上别放网络存储。网络存储的IO带宽会成为瓶颈加载时间可能翻倍。另外vLLM Ascend支持权重预加载到host内存再分发但需要足够大的host内存。72B FP16权重144GBhost内存至少256GB才够。如果host内存不够就会走流式加载更慢。6.2 tokenizer的坑Qwen3.5用的是新的tokenizer如果transformers版本不对会出现tokenize结果和预期不一致的情况。表现是模型输出乱码或者重复。验证方法from transformers import AutoTokenizer tok AutoTokenizer.from_pretrained(/data/models/Qwen3.5-72B-Instruct) print(tok.encode(你好世界))对比官方给的token id如果对不上就是版本问题。6.3 长上下文下的显存碎片32K上下文跑一段时间后KV Cache会出现碎片表现为明明还有空闲显存但新请求分配不到块。vLLM的PagedAttention本身就是为了解决碎片但在昇腾上块管理器的实现和GPU版有差异。缓解方法定期重启服务或者把max-model-len设得比实际需要略大留出碎片空间。6.4 OpenAI API兼容层的细节vLLM Ascend的OpenAI兼容API基本可用但有几个差异logprobs参数在昇腾上返回的格式和OpenAI不完全一致。stream_options里的include_usage支持不完整。函数调用function calling需要模型本身支持Qwen3.5支持但需要在prompt里正确构造。如果你的上游系统强依赖这些细节建议在API网关层做适配别指望vLLM Ascend完全对齐OpenAI。7. 生产部署还要考虑的事7.1 多实例与负载均衡单实例4卡跑72B吞吐1850 tokens/s。如果业务量更大需要多实例。但昇腾机器通常8卡可以拆成两个4卡实例前面挂Nginx做负载均衡upstream vllm_backend { server 127.0.0.1:8000; server 127.0.0.1:8001; }两个实例共享同一份权重文件只读显存各自独立。这样单机吞吐能到3700 tokens/s。7.2 监控指标暴露vLLM自带Prometheus metrics端点在/metrics。关键指标vllm:num_requests_running当前运行请求数vllm:gpu_cache_usage_percKV Cache使用率vllm:time_to_first_token_secondsTTFT直方图vllm:time_per_output_token_secondsTPOT直方图把这些接进Prometheus Grafana设好告警阈值。KV Cache使用率持续超过90%就该考虑扩容了。7.3 模型热更新生产环境难免要换模型版本。vLLM Ascend目前不支持真正的热更新只能重启。但可以通过蓝绿部署减少停机新实例起来后Nginx切流量旧实例再下线。切换过程中会有短暂的双倍显存占用要确保机器显存够。8. 一些个人体会这套组合我从头到尾部署过三遍每遍都能遇到新问题。最大的感受是昇腾的软件栈迭代很快但文档和社区案例的更新跟不上。很多问题的答案不在官方文档里而在Gitee的issue区和一些技术博客的评论区。另一个体会是vLLM Ascend的性能调优和GPU版思路一致但具体参数的最优值完全不同。GPU上好用的配置直接搬到昇腾上大概率不是最优。必须重新压测、重新找平衡点。最后说个实际的如果你的业务对延迟极其敏感比如要求TTFT稳定在500ms以内那72B 4卡910B这个配置可能不够得考虑更小的模型或者更多的卡。性能这件事没有银弹只有权衡。