最近我花了整整两周时间把几个关键仓库翻来覆去地看了好几遍——deepseek-ai/DeepSeek-V3、vllm-project/vllm-ascend再加上Ascend/pytorch也就是 torch_npu。标题里说“DeepSeek 开源昇腾算力组件”更准确的理解是DeepSeek 模型开源之后昇腾生态里配套的推理组件也陆续开源了而这 3 个仓库恰好把“模型权重 → 推理引擎 → 底层算子”这条完整链条串了起来。这篇文章就是想把我在这些仓库里看到的真实信号以及我在昇腾单机上实操跑 DeepSeek 的全过程记录下来给正在评估国产算力替代方案的朋友一个可参考的坐标。先说结论如果你只看 star 数会被误导如果你只看 issue 列表又会觉得生态还很糙。真正判断“国产替代走到哪了”要看仓库的提交节奏、release 频率、issue 响应速度以及最关键的一环——你到底能不能照着 README 把模型跑起来。下面我会逐个拆解这 3 个仓库也会把实操中踩过的坑原原本本写出来。1. 为什么是这 3 个仓库一个观察国产算力替代的窗口先说清楚我为什么选这 3 个仓库而不是去看那些“国产替代全景图”之类的宏观文章。做技术评估最怕的就是只看 PPT不看代码。算力替代这件事嘴上说一百遍“生态起来了”不如去 GitHub 上看看最核心的几个仓库发生了什么。1.1 模型仓库算力吃下去才知道行不行第一个仓库是模型本身。DeepSeek-V3 是 671B 总参数、37B 激活参数的 MoE 模型使用 MLAMulti-head Latent Attention和 DeepSeekMoE 架构还带了 MTPMulti-Token Prediction模块。这个仓库里你能看到的远不止权重文件pytorch_model-00001-of-000163.bin这样的分片权重说明模型有多大、能不能在单机单卡上跑config.json里的关键参数比如n_routed_experts: 256、top_k: 8、kv_lora_rank: 512这些参数决定了推理时的显存占用和算子形态inference/目录下的脚本是官方给出的最小推理实现不依赖 vLLM纯 PyTorch 语言写的适合阅读理解。真正决定“能不能在昇腾上跑”的不是模型本身而是模型结构里的算子在昇腾 NPU 上有没有对应的实现。昇腾的 CANN 算子库虽然覆盖了绝大多数 Transformer 算子但像 MLA 这种偏门结构早期 torch_npu 上就没有高效实现只能 fallback 到 CPU 或者用组合算子硬凑。所以模型仓库是你评估国产算力时第一个要打开的仓库——它定义了你的“工作量上界”。1.2 推理引擎适配真正卡脖子的地方第二个仓库是vllm-project/vllm-ascend。这是 vLLM 在昇腾 NPU 上的适配层本质上是一个 backend 插件。为什么要单独拉一个仓库而不是合入 vLLM 主干因为昇腾 NPU 的编程模型和 CUDA 差异很大vLLM 内建的 CUDA Graph、PagedAttention 等核心机制都需要针对 NPU 重新实现。这个仓库值得关注的几个点vllm/attention/backends/ascend_attention.py这类文件对应的是昇腾上的注意力算子实现你能直接看到它调用了 CANN 的哪些底层接口docs/目录里的安装说明和版本矩阵这是实操最需要的东西examples/目录里的启动命令通常直接抄就能跑。你在这个仓库里看什么看 release 频率。如果 vLLM 上游发一个新版本昇腾适配层能在两周内跟进说明背后有团队在持续投入。如果拖了一个季度还没更新那说明适配工作基本靠社区“用爱发电”你部署时就要做好自己 patch 的心理准备。1.3 算子与底层后端适配工作的“地基”第三个仓库是Ascend/pytorch也就是 torch_npu 的源码仓库。torch_npu 是 PyTorch 在昇腾 NPU 上的后端插件提供了torch.npu接口、HCCL 分布式通信、混合精度支持等。这个仓库属于“平时没人看出问题就抓瞎”的类型。它决定了三件事你的 PyTorch 能不能在昇腾上跑精度对不对分布式训练/推理时多卡通信效率高不高遇到未知算子时是直接报错、CPU fallback、还是能通过torch.npu的原语拼接出来。这三个仓库在逻辑上是递进的模型开源是“有米”推理引擎适配是“有锅”算子底座是“有火”。三个都齐了才能做出一顿饭。所以当你听到“某国产算力已经支持 DeepSeek”的时候别急着高兴先去看这 3 个仓库各自处于什么阶段心里就有数了。2. 三个仓库逐个拆解哪些信号决定国产替代进展这一节我把每个仓库里真正值得盯的内容拆开讲。不是给你念 README而是告诉你应该从哪些代码、哪些文件、哪些动态里去判断这个生态的成熟度。2.1 DeepSeek 官方仓库开源到什么程度deepseek-ai/DeepSeek-V3仓库的开源程度其实远超很多人的预期。它不只是扔了一堆权重出来而是把推理路径完整开放了。先看模型结构。config.json 里我会重点看这几个字段{ n_layer: 61, n_head: 128, kv_lora_rank: 512, q_lora_rank: 1536, n_routed_experts: 256, n_shared_experts: 1, moe_intermediate_size: 2048, top_k: 8, first_k_dense_replace: 3 }这些参数对昇腾适配的影响很大。比如kv_lora_rank和q_lora_rank这两个 MLA 特有的低秩压缩参数意味着注意力计算路径和标准 MHA 不一样。如果用标准 FlashAttention 算子去套算出来的 K/V 是压缩后的 latent不能直接参与 attention 计算必须先做解压缩。这个转换过程在 CUDA 上可以用几个核函数完成但在昇腾上就得看 CANN 是否支持对应的 reshape、matmul 组合。仓库里还有model.py和inference/目录下的代码建议直接读model.py里的MLA类理解它做了哪些压缩。我的经验是如果模型结构越接近“标准 Transformer 少量定制”昇腾适配的坑就越少如果像 MLA 这样改动核心注意力机制那就要做好“跑通容易跑快难”的心理准备。另外要提醒一点这不是一个“傻瓜式”仓库它不提供开箱即用的部署脚本。所有组件的组合——权重分片、config、tokenizer、推理脚本——需要你自己拼装。我第一次拉完仓库后一度有点懵因为文件太散了后面才理解这正是开源模型的常态模型开源和部署方案开源是两回事。2.2 vLLM-Ascend一个适配层暴露的生态成熟度vllm-project/vllm-ascend这个仓库坦白说质量比我想象中要高。它的定位很明确不是另起炉灶而是作为 vLLM 的一个后端插件。安装方式也简单pip install vllm-ascend它会自动依赖 torch_npu 和 CANN。让我真正觉得“生态认真了”的是它的代码结构。适配层没有把 vLLM 的核心逻辑全部重写而是通过抽象接口插进去比如自定义了AscendWorker实现 NPU 上的模型加载和推理循环实现了AscendAttentionBackend把 PagedAttention 映射到 CANN 的算子保留了 vLLM 的调度器、KV cache 管理器等核心模块因为这些跟硬件无关不需要重写。这种“尽量复用上游只替换硬件相关部分”的做法正是正经适配该有的样子。对比有些国产硬件厂商动不动就 fork 一个版本然后三年不跟上游同步vLLM-Ascend 的跟进速度可以用“活跃”来形容。但看这个仓库不能光看优点还得看它的 issue 区。里面高频出现的问题类型很能说明问题版本不匹配导致的报错最多尤其是torch、torch_npu、CANN、vllm-ascend四者的组合量化模型支持还在补课AWQ/GPTQ 在昇腾上的兼容性不如 CUDA 平台偶发的不支持算子报错比如某些模型里的自定义 CUDA kernel 在 NPU 上找不到对应实现。这些现象说明什么说明适配工作已经从“能不能跑”进入“能不能用得舒服”的阶段。2024 年上半年的时候大家还在为“torch_npu 装不上”挣扎现在的问题是“哪个版本配哪个版本”“这个量化格式支不支持”这本身就是生态往前走的证据。2.3 torch_npu 与 CANN底座还差多远torch_npu 这个仓库平时没人关注但它是整个昇腾 AI 生态的地基。它的核心工作有两块一是实现 PyTorch 算子在 NPU 上的映射二是维护一套 NPU 专属的高性能算子。我花了不少时间在它的torch_npu/contrib和op_api相关的目录里翻代码。一个比较直观的感受是业内常用的 LLM 推理算子覆盖率已经不错了Transformer 里常见的 matmul、rope、softmax、layernorm、silu 等都有对应的融合实现。但如果你用到一些冷门算子比如某些模型实现里特有的一维卷积、稀疏操作就很容易踩到“算子不支持”的坑。这里有个判断底座成熟度的实用技巧看 torch_npu 跟随 PyTorch 版本发布的速度。PyTorch 2.1 发布后torch_npu 的对应版本大概过了一两个月才跟上到 PyTorch 2.4、2.5 时代这个滞后时间已经缩短到几周以内。版本跟进速度快说明有全职团队在维护而不是纯社区志愿者。跟 CUDA 生态相比差距最明显的还不是算子数量而是“可观测性”和“调试工具”。CUDA 有 nvcc、nsight、CUDA Graph inspect 等等一整套工具链而昇腾这边早期我只能靠print打点看耗时。虽然 CANN 也提供了msprof之类的性能剖析工具但用起来的顺滑程度和文档质量跟 CUDA 生态还是有不小差距。这也是判断“替代走到哪了”时最容易被忽略的一个维度——你不仅需要能跑还需要能在出问题的时候诊断问题。3. 实操实录在昇腾单机上把 DeepSeek 跑起来前面说了那么多“看仓库”最后还是要落到“跑起来”。这一节我完整记录一次在昇腾单机上跑 DeepSeek-R1-Distill-Qwen-7B 的操作过程给了具体的命令、参数和部署逻辑方便直接参考复现。3.1 环境准备和版本矩阵先说结论昇腾上的版本匹配比你想象的更严格。一句话总结就是torch、torch_npu、CANN、vllm-ascend四者必须互相匹配谁先动手谁踩坑。我的建议是先确定 CANN 版本再去找匹配的 torch_npu 版本最后确认 vllm-ascend 支持范围顺序不能乱。我这次实测的环境如下组件版本操作系统Ubuntu 22.04Python3.10CANN Toolkit8.0.RC1PyTorch2.1.0torch_npu2.1.0.post1vLLM0.7.2vllm-ascend0.7.2注意这个版本组合只是我实测时确认可用的组合不代表最新推荐。你在部署前一定要去Ascend/pytorch仓库的 README 里查最新的版本对应表它随时可能更新。3.2 从克隆仓库到启动服务的完整步骤第一步确认 NPU 设备可用。昇腾卡一般通过npu-smi工具查看类似 N 卡的nvidia-sminpu-smi info如果这步直接报错说明驱动或固件没装好后面全部免谈。正常能看到卡数量、芯片型号、显存占用就是好的开始。第二步设置 CANN 环境变量。这个很容易漏但漏了你会在 import 阶段就报错错误信息通常类似libascend_ops.so: cannot open shared object filesource /usr/local/Ascend/ascend-toolkit/set_env.sh第三步验证 PyTorch 与 torch_npu 是否正确安装python -c import torch; import torch_npu; print(torch.__version__); print(torch.npu.device_count()); print(torch.npu.get_device_name(0))如果输出里能看到昇腾的设备名说明底座已经通了。第四步克隆 vllm-ascend 仓库并安装git clone https://github.com/vllm-project/vllm-ascend.git cd vllm-ascend pip install -e .装的时候它会拉取 vLLM 依赖所以网络状况要好一点。如果 pip 下载特别慢可以考虑配置国内镜像源这个属于常规操作我在这就不展开了。第五步启动 DeepSeek 模型服务export ASCEND_RT_VISIBLE_DEVICES0 vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \ --device npu \ --dtype bfloat16 \ --max-model-len 8192 \ --max-num-seqs 8 \ --gpu-memory-utilization 0.85 \ --trust-remote-code--device npu是告诉 vLLM 使用昇腾后端如果不加这个参数vLLM 默认只会尝试 CUDA。这一点跟你在 N 卡上跑命令的习惯很不一样容易漏。第六步用 curl 快速验证服务curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-ai/DeepSeek-R1-Distill-Qwen-7B, messages: [{role: user, content: 讲个冷笑话}], max_tokens: 128 }能返回正常文本就说明整条链路已经通了。3.3 关键参数怎么定参数这个东西网上能搜到一堆默认值但我不建议直接抄。你要理解每个参数背后的显存账才能根据你的卡来调。首先是--gpu-memory-utilization。它表示 vLLM 最多能用多少比例的显存。昇腾卡上我建议从 0.85 起步不要直接拉满 0.95。原因有两个torch_npu 运行时会预留一些显存给上下文和算子临时 bufferCANN 的图模式编译也需要额外显存。我一开始设过 0.95结果模型加载到一半直接 OOM后面老实改回 0.85。其次是--max-model-len。这个参数决定了单条请求能处理的 max 长度也决定了 KV cache 的预留大小。简单估算方式如下KV Cache 每 token 字节数 2KV × num_layers × num_kv_heads × head_dim × dtype_bytes以 7B 模型为例28 层、8 个 KV heads、head_dim 128、bf16 每元素 2 字节那么每 token 的 KV 缓存大约 2 × 28 × 8 × 128 × 2 114,688 字节约 112KB。也就是说8192 token 长度的单条序列KV cache 大约要 900MB。再加上权重本身7B 参数 bf16 约 14GB以及激活内存你在 32GB 的 910B 上跑 8192 上下文是够的但想塞进 16GB 的卡就有点悬。最后是--max-num-seqs。它控制并发序列数直接影响吞吐。设大了容易 OOM设小了吞吐上不去。我的习惯是先跑一次 benchmark用 4 和 8 各测一轮取吞吐的峰值点。不要指望单卡并发拉到 32在昇腾单卡上 8 到 16 之间通常是比较舒服的区间。3.4 上线前的 benchmark 怎么看服务跑通只是第一步接下来要看性能。vLLM 仓库自带一个 benchmark 脚本可以拿来直接测python benchmarks/benchmark_throughput.py \ --model deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \ --backend vllm \ --num-prompts 100 \ --input-len 1024 \ --output-len 512 \ --device npu看结果的时候不要只盯着“单卡最大吞吐”这一个指标。我给你说几个重点TTFTTime To First Token反映首 token 延迟对交互场景非常关键。如果这个值超过 1 秒用户体感就会卡。吞吐tokens/s反映并发场景下的总处理能力。模型一样、输入一样的情况下吞吐主要受显存带宽和算子融合程度影响。显存占用曲线跑 benchmark 时另开一个终端看npu-smi info观察显存是不是稳定在设定范围内。我实测的结果昇腾单卡跑 7B 模型、bf16 精度、并发 8、输入 1024 输出 512吞吐大致在几百到一千多 tokens/s 之间。这个数字受 CANN 版本、模型量化、图模式开关影响很大不同环境差异明显所以我觉得没必要给一个“推荐数值”。重要的是有一条基线如果吞吐数值能稳定达到你在线业务需求的 60% 以上那就是一个可用的状态如果连一半都达不到优先去看是不是算子没走融合路径。4. 常见问题速查从报错到绕坑的实战记录在昇腾上跑 DeepSeek最常见的坑其实不是性能而是各种莫名其妙的报错。我把实操中遇到的、以及社区里高频出现的问题整理成一张速查表方便直接对照。4.1 环境类问题现象根因处理方式启动时报libascend_ops.so: cannot open shared object fileCANN 环境变量未加载source /usr/local/Ascend/ascend-toolkit/set_env.sh容器内提示找不到 NPU 设备容器启动时没有挂载昇腾设备目录启动时加--device/dev/davinci0 --device/dev/davinci_manager --device/dev/hisi_hdc并把/usr/local/Ascend挂载进容器import torch_npu 后设备数为 0torch_npu 版本与 torch/CANN 不匹配删掉重装严格按版本矩阵安装vllm 启动时提示 only support--device npu忘记指定 NPU 后端加--device npu参数4.2 算子与显存类问题现象根因处理方式推理时报Unsupported operator或Not implemented模型里某个算子没有 CANN 对应实现先用torch.npu官方算子库排查覆盖情况如果确实缺失换一个模型结构更标准的版本比如 Distill 系列模型加载完直接 OOMgpu-memory-utilization设太高降到 0.75~0.85同时降低max-num-seqs推理过程中显存缓慢增长最终 OOMKVCache 碎片化或图模式没开启重启服务并开启 CANN 图模式具体参数见 vllm-ascend 文档升级到最新版本首次推理极慢之后变快CANN 图编译的冷启动开销属于正常现象上线前先做一轮 warmup 请求4.3 外部工具接入问题最近社区里很多朋友问 codex、one-api 这些工具怎么接 DeepSeek——如果你用的是昇腾上跑的 vLLM 服务这事反而简单。vLLM 默认暴露的就是 OpenAI 兼容接口所以只要把工具的base_url指向你本地服务的地址api_key随便填一个占位符就行。示例配置以常见的 OpenAI SDK 为例from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keynot-needed, ) resp client.chat.completions.create( modeldeepseek-ai/DeepSeek-R1-Distill-Qwen-7B, messages[{role: user, content: 你好}], )唯一要注意的是很多工具默认会把model参数写成gpt-4之类的名字你需要在工具配置里把它改成 vLLM 启动时指定的模型名否则会报 model not found。5. 从仓库看未来国产算力替代走到了哪一步把仓库翻完、模型跑起来、坑也踩了一遍之后回到标题里那个问题国产替代到底走到哪了我的判断是推理侧已经接近“好用”的门槛训练侧仍然处于“早期适配”阶段而生态工具链的差距才是真正的短板。判断依据不是道听途说是仓库里那些看得见的变化release 节奏明显加快了。vLLM-Ascend 的版本更新基本跟上游保持同步torch_npu 对 PyTorch 新版本的跟进也从季度级缩短到周级。2024 年初“pull request 常年躺尸”的情况已经基本看不到了。从“能跑”进入“能调优”阶段。早期昇腾跑模型主打一个“跑通就行”性能差就说是硬件问题。但现在仓库里已经有了系统的性能优化手段算子融合、图模式、量化推理、KV cache 优化这些工程手段的成熟度说明团队真的在认真打磨而不是满足于能用。训练/微调生态还在早期。DeepSeek-V3 这种级别的 MoE 模型做全参数训练需要的并行策略DualPipe、Expert Parallel在昇腾上的支持还很有限。如果你要做大规模预训练或者复杂 RL 训练现阶段 CUDA 生态仍然是更省心的选择。但如果你只是做推理服务、量化部署、LoRA 微调昇腾已经不再是“备胎”了它是一个值得认真评估的选项。用户迁移成本是最后一块短板。CUDA 生态积累了几年的文档、教程、三方库、人才经验这些软性资产不可能靠几个仓库补上。我见过很多团队在昇腾上“跑通了就换回 CUDA”的真实原因不是硬件不行而是团队里没人熟悉昇腾这套工具链出了问题不会排查。技术替代在仓库代码里完成 80%剩下 20% 是靠一代工程师的使用习惯慢慢磨出来的。老实说我对这个进程的判断是谨慎乐观的。仓库代码骗不了人算子覆盖在补齐适配版本在加速issue 响应在变快。这些东西在两年前完全不敢想象。但要说“全面替代 CUDA”那还早得很。最后分享一个我个人的实操体会如果你第一次在昇腾上部署别一上来就冲 671B 大模型先拿 7B 蒸馏版本把全链路跑通把版本矩阵、环境变量、启动参数这些基础问题都消化掉了再考虑上大模型。另外建议把vllm-project/vllm-ascend仓库设个 watch关注 release 推送的节奏——那个节奏就是国产算力替代的呼吸声。