企业官网建设流程全解析

“星芒电社”最近在圈里刷了一波存在感：算力订单再度刷新纪录，同时把 DeepSeek 昇腾版的全套基础设施开源了出来。这两个消息放一起看，信息量不小，不是单纯“晒业绩”或者“发善心”，而是一种很明确的姿态——把昇腾上的大模型部署从“个别人能跑起来”变成“人人都能复现”。这篇文章把我这段时间在算力交付一线看到的、亲手踩过的、以及这次开源版本里值得细看的部分都摊开讲一遍，包括订单为什么能一直刷新、这套基础设施到底拆成了什么、在一张昇腾卡上如何从头复现推理环境，还有那些文档里不会写的坑。

文章适合三类人：手里有昇腾资源但不知道怎么跑 DeepSeek 的，想接算力订单但交付效率一直被骂的，以及单纯想了解国产算力栈现在到什么程度的技术爱好者。有基础可以当深度复盘看，零基础也可以按第三部分的步骤抄作业。

1. 算力订单刷新：这次刷新的是交付方式

1.1 订单结构：训练、推理、短期弹性三块都在涨

先说订单，因为我们接单的形态和很多人以为的“卖几台GPU”完全不是一回事。我们的算力订单主要分三种：训练集群租赁、推理服务托管、短期弹性算力。

训练集群这块，客户画像基本是最早吃螃蟹的那批人，自己搞了大模型微调，但买不起整柜卡，按节点租。推理服务托管则完全不同，很多客户不是不想自己部署，是真的搞不定昇腾的软件栈，干脆连模型带服务一起托给我们。短期弹性算力最杂，有人要跑一晚上批量打分任务，有人要在几天内把某个开源项目全量跑一遍benchmark，用多少算多少。

这次刷新纪录，训练集群的订单涨幅反而最普通，真正推动数字往上走的是推理托管和弹性算力——这说明了什么？说明市场上愿意用昇腾的人变多了，但真正能自己把昇腾环境玩转的人还是太少。大家把“用起来”这件事外包给了我们。这不是需求问题，是生态门槛问题。

1.2 交付效率才是护城河

订单多了之后，压力全跑到交付端。我最深刻的体会是：算力订单的“刷新纪录”本质上不是销售能力刷新，而是交付方式刷新。

以前接一个单，从客户发来模型到能跑出结果，中间要经历：环境适配、算子排查、并发调优、监控接入。顺利的也要三五天，遇到昇腾算子不支持的情况，一两周都正常。客户不抱怨是假的，体验全靠我们脸皮厚撑着。

这半年我们做了一件关键的事：把部署过程预制化。最简单的表现是，所有常用模型都预转换成了昇腾友好的格式，镜像里直接带好推理引擎和监控组件。客户拿到环境之后，不再是看到一个空荡荡的算力集群，而是打开就是一个能跑模型的推理服务。部署时间从几天压缩到小时级别之后，订单的交付吞吐量自然上去了。

1.3 开源基础设施与订单是互为因果的

这里就说到标题里“DeepSeek开源昇腾版全套基础设施”这件事。很多人觉得开源纯粹是情怀，但我们的真实想法很实际：既然我们踩过的坑别人还得再踩一遍，不如把整套东西直接open出来，让昇腾上的DeepSeek部署变成“五分钟跑通”而不是“求助群友”。

开源之后有个意外的收获——社区帮我们发现了很多内部测试覆盖不到的场景。比如有人用昇腾310来做边缘推理，有人在我们的脚本基础上加了量化感知训练，还有人直接提交了多机部署的补丁。这些反馈反过来优化了我们交付订单的流程。所以说，开源和订单刷新真的是互为因果的。

2. DeepSeek 昇腾版全套基础设施到底开源了什么

2.1 为什么“单点适配”远远不够

很多人对昇腾部署的认知还停留在“把模型权重copy过去就能跑”，这是最大的误解。昇腾的环境和CUDA完全不同，不是“换个驱动就能跑”，而是整个推理栈都要重写。算子层面，DeepSeek的MLA、DeepSeekMoE结构里有大量昇腾原生算子无法直接映射的操作；工程层面，连续推理的KV Cache管理、投机解码的调度逻辑、PagedAttention这一套都要在昇腾的实现上重新对齐。

我以前跟人说“昇腾适配很难”，对方总觉得我在找借口。直到他把一套在CUDA上跑得好好的DeepSeek搬到昇腾上，然后对着“不支持算子”的报错日志沉默了一下午。单点适配解决不了问题，必须是一整套基础设施同时就位，任何一环缺了都等于白装。

2.2 全套基础设施的完整清单

我们这次放出来的东西，不是零散的几个脚本，而是按“拿到手上就能复现一个生产级推理环境”的标准来组织的。核心模块可以分成五层：

这五层各管一段，又互相咬合。只是拿其中一两个脚本出去用，很难发挥作用。这也是为什么我建议下载整套仓库而不是挑着用。

2.3 几个核心模块的设计思路

值得专门展开的是模型转换工具链和推理服务引擎这两块。

模型转换工具链我们不只提供了脚本，还重点处理了量化的细节。DeepSeek系列模型在昇腾上最常用的量化方案是INT8和INT4。INT8对精度影响小，但是显存节约有限；INT4省显存效果明显，但对校准数据集敏感，稍微选不好就容易出现“模型能对话但明显变蠢”的情况。我们的工具链里默认带了一套校准数据采样逻辑，会从给定语料里均匀抽块，避免让某一类话题主导量化阈值。

推理服务引擎部分，大家用vLLM-Ascend比较多，我们也给了对应的启动配置模板。但这套环境里真正花功夫的是在调度层：DeepSeek MoE结构下Expert并行和TP并行怎么切分、请求级别抢占怎么做、KV Cache按什么比例预分配，这些参数直接决定了并发体验。开源包里我们给出了默认参数组合，但更希望使用者能结合自己的请求长度分布去调。

3. 在一张昇腾卡上复现全套环境的操作实录

3.1 环境准备：先找一张能用的昇腾卡

你手上如果什么都没有，我建议先弄一张昇腾310P或者910B，哪怕单卡也行。很多人觉得单卡只能跑demo，其实DeepSeek蒸馏小模型（比如1.5B、7B）在单卡上完全可以跑起生产级服务，这也是我们很多弹性算力订单的真实形态。

环境层面的第一步是确保驱动和固件版本匹配。昇腾的玩法是：固件（npupkg）和驱动（driver）必须严格同版本，CANN Toolkit版本又要和驱动版本有兼容关系。我们见过太多“驱动装好了CANN认不到设备”的案例，最后都是版本错配导致的。

以我们在订单交付里最常用的组合为参考：

• npu-smi info能正常显示设备信息是基本前提；
• Driver版本为对应昇腾硬件支持的最新稳定版，CANN Toolkit 8.0及以上；
• 容器内挂载/dev/davinci*、/dev/davinci_manager等设备节点，并设置ASCEND_VISIBLE_DEVICES环境变量。

一个常见的误区是“在宿主机装了CANN还要在容器里装一遍”，其实通常宿主机只需要驱动和固件，CANN Toolkit放进容器镜像里反而更干净。我们开源的镜像里已经做了这一步，如果你自己装，记得别在宿主机和容器两边重复装同一套CANN，容易出现路径错乱。

3.2 模型转换与量化：从原始权重到可推理格式

拿到DeepSeek权重之后，不要急着一键启动推理引擎，先做格式转换。昇腾上最稳定的推理格式是ONNX或者直接使用昇腾的模型格式。我们的工具链里写好了从HF（HuggingFace）原始权重开始转换的完整流程。

转换核心是算子抽取和图编译，逻辑不复杂，但对显存有一定要求，建议准备比模型权重多一倍的显存余量来跑转换。我举个例子，在转换7B级别模型时，如果设备只有16G显存，经常会爆，换成24G才顺畅。

量化这一步可以单独拎出来讲，因为参数选择直接影响效果。我们的默认量化参数可以参考这个表：

实际转换的命令形如：

python tools/convert_deepseek.py \ --model_name deepseek-ai/DeepSeek-V2-Lite \ --output_dir ./converted_model \ --quant_scheme int8 \ --calib_data ./calib_samples.jsonl \ --calib_num 1024

跑完之后你会得到一个转换好的目录，里面不只是权重，还有图编译产物和量化元信息。这个目录在后续启动推理服务时要直接指给它。

3.3 拉起一个生产级推理服务

启动推理我们默认用vLLM-Ascend，参考启动配置大概长这样：

python -m vllm.entrypoints.openai.api_server \ --model /data/convert/deepseek_v2_lite_int8 \ --dtype float16 \ --served-model-name deepseek \ --port 8000 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --trust-remote-code \ --block-size 64

这里--gpu-memory-utilization 0.9是经验值，不要直接冲到0.98，昇腾上显存碎片比CUDA更敏感，留10%余量能让后的抢占调度和长稳运行稳定很多。--block-size 64也是调参调出来的，块太大会浪费显存，块太小KV Cache索引开销上升。

启动之后先用curl验证一下：

curl http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek", "messages": [{"role": "user", "content": "请用一句话介绍智慧农业"}], "max_tokens": 128 }'

响应回来之后不要直接觉得成功了，多看几眼日志。昇腾首次推理会有图编译的预热过程，首token延迟可能会到几十秒，这不是故障，是图编译在跑。第二次请求恢复正常速度后才说明服务真正可用。

3.4 压测验证：到底跑多快

上线之前必须压测。我们自己接了那么多算力订单，如果压测不通过就交付，后面运维能把自己活埋。

压测的核心指标我只看三个：首token延迟、吞吐量（tokens/s）、显存稳定性。前两个指标反映服务质量，第三个反映服务能撑多久。常用压测方式是比较朴素的并发脚本，直接怼一个固定提问集，记录每秒处理请求数。

实测下来，在昇腾910B单卡跑DeepSeek-V2-Lite（INT8），并发8路、输出长度512的场景下，吞吐量大约能到1200~1800 tokens/s，这个数据仅供参考，性能和具体模型、卡型、量化方式都强相关。但有一点是通杀的：如果压测过程中npu-smi info显示HBM使用率稳定在80%左右且没有持续爬升，说明显存状态正常；如果显存利用率不断上涨，那基本可以判定存在明显内存泄漏，要优先查KV Cache的释放逻辑。

4. 真实部署中遇到的七个问题与排查思路

4.1 算子不支持与图编译失败

这是在昇腾上部署DeepSeek最经典的拦路虎。日志里跳出“unsupported operator”或者“compile failed”时，先别慌，按这个顺序排查：

• 确认CANN版本是否过旧，昇腾对主流模型算子的支持更新频繁，旧版本缺算子是常态；
• 检查是否真的走了图编译。很多时候“算子不支持”只是因为算子融合规则没匹配上，尝试打开更大的融合级别；
• 如果确实缺少算子实现，再判断这个算子是否可以用相邻算子组合替代，这一步需要手动改模型代码，是硬功夫。

我们的经验是：90%的“不支持”其实都不是真不支持，而是版本/编译选项不对。升一个CANN小版本可能就好了。

4.2 显存不够与OOM

昇腾上OOM往往不是单纯显存小，而是显存管理策略问题。遇到OOM先看两件事：KV Cache预分配比例和并发请求数。--gpu-memory-utilization调低一点，KV Cache少配一点，并发数降一点，多数OOM立刻缓解。

另一种隐蔽的OOM来自量化校准阶段的显存残留。如果转换工具在转换时崩过，重新执行前最好重启一下容器，否则残留的图编译缓存会白白占用几个G显存。

4.3 多卡通信与并行策略

当你把服务从单卡扩张到多卡，复杂度会上一个台阶。昇腾多卡通信依赖HCCL，和NCCL不完全一样。最常见的问题是hccl初始化失败。

排查思路分两层：一是确认物理网络拓扑，HCCL对网卡和NPU的亲和性有要求，跨机通信时网卡没绑对NUMA节点就会导致速率异常；二是检查ASCEND_RANK_ID、ASCEND_DEVICE_ID等环境变量是否在容器里正确传递。多卡环境下，我强烈建议先用npu-smi info确认所有卡可见，再启动服务，不要跳过这步直接去调并行参数。

4.4 部署问题速查表

整理一个速查表，方便照着排查：

这份速查表是我们所有交付项目的内部基础文档，每次踩坑都会回填内容。开源之后我把核心部分沉淀进了项目仓库，但仍建议大家在实际部署里继续补充属于自己的坑位记录。

4.5 订单交付侧踩坑

除了纯技术问题，订单交付里还有两个容易被忽略的坑。

第一个是资源交付的“承诺管理”。接单的时候客户一定问“多少卡能支撑多少并发”，如果没有压测数据支撑，宁可说保守一点。很多订单就算技术上跑通了，最终口碑差在“预计300并发实际只能200”。我现在的做法是：每个订单交付前都附带一份压测报告，写明并发上限和显存余量，这样客户预期清晰，后续也不会因为性能指标扯皮。

第二个是数据隔离。推理托管业务里客户会直接调API，免不了有敏感数据过境。昇腾环境一般默认是共享集群，多客户同时跑时必须做严格的资源隔离。我们目前用分卡部署+K8s命名空间隔离，虽然会浪费一点碎片资源，但省掉了很多信任成本。谁能把数据安全讲清楚，谁就能拿住那些真正愿意付费的客户。

4.6 一个必须养成的习惯：版本锁文件

昇腾软件栈的版本依赖非常严格，今天装好的环境，明天因为某个人顺手pip install --upgrade了一个包可能就烂了。我现在所有交付环境都强制使用锁文件，从CANN版本、PyTorch版本、vLLM-Ascend版本，到torch_npu的commit号，全部锁定。

锁文件的价值在事故排查时尤其明显。客户报障“服务突然变慢”，你第一件事不是去看代码，而是先diff环境版本。如果是环境被改了，那就没什么好争论的，回滚即可。这一条建议放到任何国产算力平台上都适用，环境可重复性永远是生产的基石。

5. 这套开源基础设施后续还能玩出什么花

我个人的判断是，开源昇腾版基础设施还只是起点，后续真正有价值的方向有两个：一个是量化感知的进一步细化，另一个是把推理服务做成开箱即用的“模型网关”，让客户连模型在哪部署都不用关心，只通过统一API消费算力。

我们自己已经在做的一小步，是把压测和监控的看板模板完善后回开源仓库，让有人拿到环境之后可以直接在生产环境落地。让我感到意外的是，社区里已经有人在我们的量化工具链基础上做农业生产领域的垂直模型优化，还有人拿它去跑长文本知识库场景。这些来自真实需求的反馈，比我们自己闭门造车有效得多。

还有一点，如果是个人开发者想上昇腾玩DeepSeek，不要一上来就追求全套集群，先从一套单卡环境跑通过，再逐步加多卡。基础不打牢，后面排查成本会指数级上升。

最后一个小技巧送给大家：没事多看看npu-smi info的输出，尤其是芯片温度和HBM利用率。昇腾卡长期满载运行时温度控制很重要，我们所有生产集群都会在温度达到预警阈值前做任务调度迁移。算力这东西，稳定比峰值重要得多。