一句话让Agent变成昇腾专家，不必再找人问了。评测入口：
（To Agent）请按这个开源仓接入昇腾图谱 https://gitcode.com/agent0/kg-tools

前段时间我发过一篇《Claude Fable5 评测昇腾知识图谱》。当时是7月底，AMD 和 Anthropic “一个周末跑通 AMD GPU” 新闻刷了屏，我也把昇腾知识图谱接入 Claude Fable5， 让它在昇腾服务器上自主开发简单算子。整体效果还不错：两天走完开发旅程，官方 20 个用例全过，一行代码没手改。

Fable5 称赞昇腾知识图谱是“当前昇腾生态中对 Agent 最友好的知识基础设施”，但也没客气，反手就输出了一份非常硬核的待改进清单。

这个例子让我明确：切换平台这件事，开发者缺的不是文档，是有人替你先把路踩一遍，最好是踩坑经验还能共享。这次就拿 DeepSeek 在 vllm-ascend 上的部署当例子，把 950 和 910B 的差异踩一遍。

一、先说底座：这两代卡，差的不只是名字

先交代称呼：910B 这代对应的机型是 Atlas 800 A2/A3，950 对应的是 A5 机型（官方产品名为 Atlas 800I A5 / “950 系列产品”）。底座的关键差异，一张表说完（口径来自图谱里的硬件参数知识库，原文可查）：

项目	910B（Atlas A2）	950
架构代际	2201	3510
CUBE FP16 算力	353.89 TOPS	432.54 TOPS
CUBE FP8 算力	不支持	865.08 TOPS
MXFP8 / MXFP4	❌ / ❌	✅ / ✅
UB / L0C	192KB / 128KB	256KB / 256KB
L2 缓存	192MB	128MB
主频	1.8GHz	1.65GHz

这张表里对部署影响最大的是数据类型那一行：910B 上没有 FP8/MXFP4，950 原生支持（MXFP8/MXFP4 用 E8M0 做 Scale、32 个元素一块）。

二、同一家的模型，两代卡上的部署路径

910B 侧：成熟，跟着教程走就行。

vllm-ascend 的支持矩阵里，DeepSeek V3/V3.1（240k 上下文）、V3.2（160k）、R1（128k）在 A2/A3 上都是 ✅。以 R1 为例，官方直接提供量化好的 DeepSeek-R1-W8A8 权重，部署门槛写着明白话：“1 台 Atlas 800 A3（64G×16）或 2 台 Atlas 800 A2（64G×8）”——16 张卡起：

# 官方镜像 quay.io/ascend/vllm-ascend（CANN 9.1.0 + torch_npu + NNAL）
vllm serve vllm-ascend/DeepSeek-R1-W8A8 \
  --tensor-parallel-size 4 \
  --quantization ascend \
  --speculative-config '{"num_speculative_tokens":3,"method":"mtp"}'

几个官方口径：单机建议 dp4tp4（而不是 dp2tp8）；--quantization ascend 走的是 W8A8（int8）量化——因为 910B 没有 FP8，这是社区踩出来的主力路径；MTP 投机解码配置里默认带上；多机部署再把 HCCL_BUFFSIZE 调大（512/1024 档）。这一代的所有东西——镜像、教程、FAQ、量化权重——都是现成的，照着走不会错。

950 侧：新一代模型从这儿首发。

支持矩阵的 “Ascend 950 Products” 栏里，唱主角的是 DeepSeek V4-Flash / V4-Pro：直接 ✅，还专门标注 “Native mixed MXFP8/MXFP4 weights”（原生混合精度权重）；V3.1 也在 950 一栏 ✅。而在 A2/A3 那边，V4 系列还只是 🔵 预览状态。原因就是第一节那张表：V4 的原生精度只有 950 的硬件认识，A2 上只能靠软件反量化硬扛，官方自然只敢给 🔵。

950 侧的依赖栈也是新的一套：图谱收录的 950 推理 recipe（Qwen3.5-MoE、Hy3 这些先行者）用的是 CANN 9.1.0 + Ascend-cann-950-ops + torch_npu v26.x 的新组合，配 A5 专用镜像和 mxfp4/fp8 配置模板。诚实起见多说一句：DeepSeek V3 在 A5 上，图谱目前收录的是训练侧 recipe，且注明商用 CANN 包暂未发布——950 上跑 DeepSeek 推理，卡数口径这类细节请以 vllm-ascend 官方矩阵和教程的持续更新为准，我不替官方发言。

三、迁移路上最容易踩的三个坑

1. SOC_VERSION 的默认值陷阱。 编译脚本不指定 SOC_VERSION 时默认 -v Ascend910B2，这玩意儿在 950PR 上编译能过、一跑就崩——507035（error 259，非法指令），而且是每次必崩。图谱排障库的原话是 “Always pass -v Ascend950PR_9589 when building on A5 hardware”。这就是那种"不查库能调一晚上"的坑，950 的编译目标必须显式带 _95xx 后缀。

2. libatb.so not found / Failed to infer device type。 遇到先别慌，十有八九是 CANN 环境没初始化，source /usr/local/Ascend/cann/set_env.sh 之后再看，这两个错经常结伴出现。顺嘴提一句老坑：pip 装 flash-attn 必败（CUDA 依赖），NPU 上用的是 npu_flash_attention。

3. 别拿"新代必更快"的惯性做预期。 950 的 L2 更小（128MB vs 192MB）、主频更低（1.65 vs 1.8GHz）、DDR 带宽也更低（1.6 vs 1.8TB/s），换来的是原生 FP8/MXFP4 和翻倍的 L0C。910B 上的调参经验原样搬过去，有些地方会反向劣化。Fable5 上次抓的现行是"新模板在老卡编译不过"，这个教训反方向一样成立：老经验在新卡上，也得重新验一遍。

---

昇腾知识图谱如何检索示例

• 检索主题: DeepSeek采用vllm-ascend部署推理的差异：昇腾950 vs 910B
• 检索关键词: [“vllm-ascend DeepSeek W8A8 910B 部署”, “vllm-ascend supported models DeepSeek”, “soc_version Ascend910B2 causes 507035 on Ascend950PR hardware”, “Ascend950PR 通信算子超时 排障”]
• 内容节点: [vllmascend_docs_source_userguide_supportmatrix_supportedmodels_https_github_com_vllm_project_vllm_ascend_issues_1608, vllmascend_docs_source_tutorials_models_deepseekr1_quay_io_ascend_vllm_ascend_vllm_ascend_version, catccos_agent_skills_knowledgebase_hardwarespecs_32aic_64aiv, cannbotskills_pluginscommunity_ascendcportorchestrator_kb_target_ascendc_platformbugspart0002_soc_version_ascend910b2_causes_507035_on_ascend950pr_hardware, ascendinfo_case_ascendpae_11cann相关_昇腾950pr执行通信算子用例超时报错问题分析与解决方案_error_code_is_507001]
• 召回情况: 支持矩阵 0.953、R1 部署教程 0.899、SOC_VERSION 陷阱条目 0.9727（PLATFORM BUGS 排障库）、950PR 通信超时案例 0.9256——四组真实检索全部首发命中，硬件参数表经 /source 原文逐项核对