企业官网建设流程全解析

最近我花了整整两周时间，把几个关键仓库翻来覆去地看了好几遍——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 模型，使用 MLA（Multi-head Latent Attention）和 DeepSeekMoE 架构，还带了 MTP（Multi-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 区。里面高频出现的问题类型很能说明问题：

1. 版本不匹配导致的报错最多，尤其是torch、torch_npu、CANN、vllm-ascend四者的组合；
2. 量化模型支持还在补课，AWQ/GPTQ 在昇腾上的兼容性不如 CUDA 平台；
3. 偶发的不支持算子报错，比如某些模型里的自定义 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 支持范围，顺序不能乱。

我这次实测的环境如下：

注意：这个版本组合只是我实测时确认可用的组合，不代表最新推荐。你在部署前一定要去Ascend/pytorch仓库的 README 里查最新的版本对应表，它随时可能更新。

3.2 从克隆仓库到启动服务的完整步骤

第一步，确认 NPU 设备可用。昇腾卡一般通过npu-smi工具查看，类似 N 卡的nvidia-smi：

npu-smi info

如果这步直接报错，说明驱动或固件没装好，后面全部免谈。正常能看到卡数量、芯片型号、显存占用就是好的开始。

第二步，设置 CANN 环境变量。这个很容易漏，但漏了你会在 import 阶段就报错，错误信息通常类似libascend_ops.so: cannot open shared object file：

source /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_DEVICES=0 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 运行时会预留一些显存给上下文和算子临时 buffer；CANN 的图模式编译也需要额外显存。我一开始设过 0.95，结果模型加载到一半直接 OOM，后面老实改回 0.85。

其次是--max-model-len。这个参数决定了单条请求能处理的 max 长度，也决定了 KV cache 的预留大小。简单估算方式如下：

KV Cache 每 token 字节数 = 2（K+V） × 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

看结果的时候不要只盯着“单卡最大吞吐”这一个指标。我给你说几个重点：

• TTFT（Time To First Token）：反映首 token 延迟，对交互场景非常关键。如果这个值超过 1 秒，用户体感就会卡。
• 吞吐（tokens/s）：反映并发场景下的总处理能力。模型一样、输入一样的情况下，吞吐主要受显存带宽和算子融合程度影响。
• 显存占用曲线：跑 benchmark 时另开一个终端看npu-smi info，观察显存是不是稳定在设定范围内。

我实测的结果，昇腾单卡跑 7B 模型、bf16 精度、并发 8、输入 1024 输出 512，吞吐大致在几百到一千多 tokens/s 之间。这个数字受 CANN 版本、模型量化、图模式开关影响很大，不同环境差异明显，所以我觉得没必要给一个“推荐数值”。重要的是有一条基线：如果吞吐数值能稳定达到你在线业务需求的 60% 以上，那就是一个可用的状态；如果连一半都达不到，优先去看是不是算子没走融合路径。

4. 常见问题速查：从报错到绕坑的实战记录

在昇腾上跑 DeepSeek，最常见的坑其实不是性能，而是各种莫名其妙的报错。我把实操中遇到的、以及社区里高频出现的问题整理成一张速查表，方便直接对照。

4.1 环境类问题

4.2 算子与显存类问题

4.3 外部工具接入问题

最近社区里很多朋友问 codex、one-api 这些工具怎么接 DeepSeek——如果你用的是昇腾上跑的 vLLM 服务，这事反而简单。vLLM 默认暴露的就是 OpenAI 兼容接口，所以只要把工具的base_url指向你本地服务的地址，api_key随便填一个占位符就行。

示例配置（以常见的 OpenAI SDK 为例）：

from openai import OpenAI client = OpenAI( base_url="http://localhost:8000/v1", api_key="not-needed", ) resp = client.chat.completions.create( model="deepseek-ai/DeepSeek-R1-Distill-Qwen-7B", messages=[{"role": "user", "content": "你好"}], )

唯一要注意的是，很多工具默认会把model参数写成gpt-4之类的名字，你需要在工具配置里把它改成 vLLM 启动时指定的模型名，否则会报 model not found。

5. 从仓库看未来：国产算力替代走到了哪一步

把仓库翻完、模型跑起来、坑也踩了一遍之后，回到标题里那个问题：国产替代到底走到哪了？我的判断是：推理侧已经接近“好用”的门槛，训练侧仍然处于“早期适配”阶段，而生态工具链的差距才是真正的短板。

判断依据不是道听途说，是仓库里那些看得见的变化：

1. release 节奏明显加快了。vLLM-Ascend 的版本更新基本跟上游保持同步，torch_npu 对 PyTorch 新版本的跟进也从季度级缩短到周级。2024 年初“pull request 常年躺尸”的情况已经基本看不到了。

2. 从“能跑”进入“能调优”阶段。早期昇腾跑模型主打一个“跑通就行”，性能差就说是硬件问题。但现在仓库里已经有了系统的性能优化手段：算子融合、图模式、量化推理、KV cache 优化，这些工程手段的成熟度说明团队真的在认真打磨，而不是满足于能用。

3. 训练/微调生态还在早期。DeepSeek-V3 这种级别的 MoE 模型做全参数训练需要的并行策略（DualPipe、Expert Parallel）在昇腾上的支持还很有限。如果你要做大规模预训练或者复杂 RL 训练，现阶段 CUDA 生态仍然是更省心的选择。但如果你只是做推理服务、量化部署、LoRA 微调，昇腾已经不再是“备胎”了，它是一个值得认真评估的选项。

4. 用户迁移成本是最后一块短板。CUDA 生态积累了几年的文档、教程、三方库、人才经验，这些软性资产不可能靠几个仓库补上。我见过很多团队在昇腾上“跑通了就换回 CUDA”的真实原因，不是硬件不行，而是团队里没人熟悉昇腾这套工具链，出了问题不会排查。技术替代在仓库代码里完成 80%，剩下 20% 是靠一代工程师的使用习惯慢慢磨出来的。

老实说，我对这个进程的判断是谨慎乐观的。仓库代码骗不了人：算子覆盖在补齐，适配版本在加速，issue 响应在变快。这些东西在两年前完全不敢想象。但要说“全面替代 CUDA”，那还早得很。

最后分享一个我个人的实操体会：如果你第一次在昇腾上部署，别一上来就冲 671B 大模型，先拿 7B 蒸馏版本把全链路跑通，把版本矩阵、环境变量、启动参数这些基础问题都消化掉了，再考虑上大模型。另外建议把vllm-project/vllm-ascend仓库设个 watch，关注 release 推送的节奏——那个节奏，就是国产算力替代的呼吸声。