LongCat 2.0 昇腾 NPU 推理部署实践基于 cann-recipes-infer 构建 192 卡 PD 分离长上下文推理服务【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer本文基于 cann-recipes-infer 仓库中的 LongCat 2.0 推理优化实践样例介绍如何在昇腾 Atlas A2 Pod 平台上完成 LongCat 2.0 大模型的服务化部署包括 CANN 与 torch_npu 环境准备、flash-npu-kernel 自定义算子编译安装、Int8 权重准备以及基于 PD 分离架构的 Prefill/Decode 推理服务启动与功能验证。读完本文您可以按照文档步骤复现一套支持超长上下文1M 序列的 192 卡集群推理服务并理解其背后 PD 分离、DSA 稀疏注意力与融合算子等优化设计。样例概述与部署规模本样例基于美团开源的 LongCat 2.0 推理代码SGLang-FluentLLM 仓库在 CANN 平台上完成性能优化支持在昇腾 Atlas A2 Pod 平台部署。LongCat 2.0 在 LongCat-Flash 的 Shortcut MoESC-MOE结构基础上叠加 Sink Sliding Window Attention 与 DeepSeek Sparse AttentionDSA并支持 Over Embedding 与零专家机制参数量约 1.6TMoE 与 MLP 部分原生使用 Int8 量化总显存占用约 2.1TB可为用户提供长达 1M 序列的高性能推理能力。样例在真实权重加载条件下完成部署部署规模如下基础模型机器型号PrefillDecodeLongCat 2.0Atlas A2 192卡集群单机16卡64卡128卡更完整的模型结构分析、并行策略设计与算子优化说明可参见本仓库的技术报告 NPU LongCat-2.0 推理优化实践。支持的产品型号与软硬件要求支持产品Atlas A2 系列产品。项目要求产品型号Atlas A2 系列操作系统Linux x86_64驱动版本Ascend HDK 25.0.RC1.1或配套 CANN 8.5.0 的驱动以昇腾社区 CANN 版本兼容性文档为准Python 版本3.11PyTorch 版本2.6注意该样例的软硬件版本组合HDK 25.0.RC1.1 / CANN 8.5.0 / Python 3.11 / PyTorch 2.6与仓库内其他模型样例如面向 Atlas A3、CANN 9.x 的 LongCat-Flash 样例不同复现时请以本文档声明的版本为准CANN 包下载与安装参考昇腾官方 CANN 安装文档。环境准备手动方式1. 安装 CANN 软件包样例的编译执行依赖两类 CANN 软件包CANN 开发套件包cann-toolkitAscend-cann-toolkit_${version}_linux-${arch}.runCANN 二进制算子包910b-opsAscend-cann-910b-ops_${version}_linux-${arch}.run其中${version}表示 CANN 包版本号如 8.5.0${arch}表示 CPU 架构如 aarch64、x86_64。从昇腾官网下载后参考官方 CANN 安装文档完成安装。2. 安装 Ascend Extension for PyTorch安装 torch_npu / torchair 插件op-plugins 插件安装参考 SGLang-FluentLLM 仓库中flash-npu-kernel/op-plugins/README.mdtorchair 插件安装参考flash-npu-kernel/torchair/README.MD。3. 下载项目源码并安装依赖# 下载项目源码以 master 分支为例 git clone https://github.com/meituan-longcat/SGLang-FluentLLM.git # 安装依赖的 python 库 cd SGLang-FluentLLM pip3 install -r ./npu_test/requirements.txt --no-deps项目源码的关键目录结构原文有适当省略SGLang-FluentLLM-main ├── 3rdparty ├── assets ├── benchmark ├── examples | ├── chat_template ├── flash-npu-kernel # 自定义算子实现 | |── attention_update | |── compute_n_gram_ids | |── flash_ops | |── lightning_indexer | |── mlp_lightning_indexer | |── torch_ops_extension # Pytorch调用接口代码 | |── transformer | |── update_oe_token_table ├── Makefile ├── npu_test | ├── flash26b # 模型拉起脚本 | | ├──run_pro_dsa_pp.sh | ├── requirements.txt ├── python | ├── sglang # 算子调用等模型代码 ├── README.md ├── test4. 编译安装 flash-npu-kernel 自定义算子flash-npu-kernel 目录下的自定义算子与本样例的模型结构一一对应compute_n_gram_ids、update_oe_token_table是 Over Embedding 的两个融合算子lightning_indexer、mlp_lightning_indexer、flash_opsSparse Flash Attention 等是 DSA 稀疏注意力的融合算子torch_ops_extension提供 PyTorch 调用接口。flash-npu-kernel |—————— compute_n_gram_ids |—————— mlp_lightning_indexer |—————— flash_ops |—————— update_oe_token_table |—————— torch_ops_extension # Pytorch接口调用步骤一设置环境变量source /usr/local/Ascend/ascend-toolkit/set_env.sh步骤二按算子目录依次编译并安装 run 包。以compute_n_gram_ids为例compute_n_gram_ids、mlp_lightning_indexer、flash_ops、update_oe_token_table四个算子依次执行cd flash-npu-kernel/compute_n_gram_ids bash build.sh安装编译生成的自定义算子包bash build_out/{opName}_{arch}.run${opName}表示自定义算子名称如compute_n_gram_ids、update_oe_token_table等${arch}表示 CPU 架构如 aarch64、x86_64。注flash_ops目录执行build.sh会同步生成对应的 torch extension whl 包需要用pip install --force-reinstall flash_npu_kernel-1.0.0-cp38-abi3-linux_x86_64.whl --no-deps安装。步骤三安装 PyTorch 接口调用的 whl 包cd flash-npu-kernel/torch_ops_extension bash build_and_install.sh57. 编译安装 transformer、attention_update 与 lightning_indexer patchtransformer 仓参考flash-npu-kernel/transformer/路径下的 README.md 编译安装attention_update 仓参考flash-npu-kernel/attention_update/路径下的 README.md 编译安装lightning_indexer patch参考flash-npu-kernel/lightning_indexer/路径下的 README.md 编译安装。从本仓库源码可以看到同类算子的工程形态ops/ascendc目录下的 quant_lightning_indexer 算子文档给出了 Lightning Indexer 量化版算子的函数原型与调用示例其核心语义是在稀疏 Attention 前处理中选出关键稀疏 token并对 query/key 做量化实现存8算8关键参数包括sparse_countTopK 保留数量支持 [1, 2048]LongCat 2.0 使用 2048、sparse_mode0 为 defaultMask3 为 rightDownCausal 下三角模式、cmp_ratiokey 压缩倍数等与 LongCat 2.0 中为每个 token 选择 topk2048 组 KV的 DSA 计算流相呼应。8. 配置样例运行所需环境信息修改npu_test/flash26b/run_pro_dsa_pp.sh中的如下字段iplist配置所有节点的 IP按照 rank id 排序MODEL_PATH权重所在路径例如/data/meituan-longcat/LongCat-2.0-Int8。权重准备请根据所使用的模型类型自行下载原始权重到本地路径例如/data/meituan-longcat/LongCat-2.0-Int8。LongCat-2.0-Int8 权重可从 Hugging Face 的 meituan-longcat 组织的LongCat-2.0-INT8仓库下载下载方法参考# 从 huggingface 下载权重 pip install -U huggingface_hub mkdir -p /data/meituan-longcat hf download meituan-longcat/LongCat-2.0-INT8 --local-dir /data/meituan-longcat/LongCat-2.0-Int8推理执行1. 启动推理服务ln -s SGLang-FluentLLM fluentllm cd fluentllm # 修改 npu_test/flash26b/run_pro_dsa_pp.sh 脚本中如下参数 # testpath 和 logdir 为实际测试执行路径 # iplist 为实际测试节点 ip # port 为测试节点 ssh 登陆端口 bash npu_test/flash26b/run_pro_dsa_pp.sh code # 分发网络脚本到各个节点 bash npu_test/flash26b/run_pro_dsa_pp.sh start # 启动服务说明如在测试执行节点上进行上述操作则testpath不能与当前代码路径相同。脚本的code子命令负责把网络脚本分发到 iplist 中的各节点start子命令在 Prefill64卡与 Decode128卡两侧分别拉起服务。2. 启动结果检查启动成功后在 Decode 和 Prefill 节点的首台设备上均能看到如下启动成功标志INFO - The server is fired up and ready to roll!可通过样例单请求验证服务功能正常其中service_ip为前述 iplist 配置中 minilbmini load balancer所在设备 IPcurl -X POST http://${service_ip}:8081/v1/chat/completions \ -H Content-Type: application/json \ -d { model: , messages: [ {role: user, content: 你好请介绍一下自己} ], max_tokens: 1024, temperature: 0.7, stream: false }部署背后的核心优化点延伸阅读上述部署步骤的每一步都服务于一个目标把 1.6T 参数、2.1TB 显存占用的模型在 192 卡集群上跑出可接受的首包时延TTFT与解码时延。以下要点摘自 LongCat-2.0 推理优化技术报告用于理解样例脚本与算子包为什么这样设计。模型结构SC-MOE、3S DSA、Over Embedding 与 MTPShortcut MoE每个 Layer 包含两轮 Attention 与 FFN 计算MoE 部分共 768 个路由专家 128 个零专家每 token 每次激活 12 个专家平均 8 个路由专家 4 个零专家MOE 单专家 intermediate size 为 2048。3S DSALightning Indexer 为每个 token 选择topk2048组 KV其中固定选择序列最前面的init 16sink与最后面的local 1024sliding window再从中间选top 1008形成 3S 筛选。Over Embedding将每个 token 与前序oe_n - 1个 token 做哈希得到 n-gram再经oe_k张子表的 Embedding 与 Projection 计算后与原始 hidden states 加权平均。样例中compute_n_gram_ids与update_token_table两个自定义算子分别承担 n-gram id 生成与 Token Table 离散刷新的融合计算。MTP样例支持 MTP 3每次推理 Step 额外进行三次 MTP 推理以摊薄单 token 时延由于 3S DSA 中 Lightning Indexer 在长序列下成为瓶颈MTP 可提高其计算访存比。PD 分离部署与并行策略Prefill64卡将 64 卡划分为 m×n 组m 维做 Pipeline 并行按 Layer 切分n 维做 Context Parallel按序列维度切分请求。在做 Indexer 与 SFA 计算前分别对 Indexer Key Cache 和 KV Cache 做all_gather每个 rank 持有部分 q 与完整 Cache。MLA 计算选用 Absorb Sparse Attention 方案BMM 的 M 轴为 128矩阵乘效率更高且 KV 的 HBM 访存量相对 Naive 方案降低几十倍使 Prefill 与 Decode 的 MLA 计算流归一。Decode128卡采用 KV Parallel 部署把不同请求的 Indexer Key Cache 与 KV Cache 分散存放在不同 rank每个 rank 用完整的 q 与部分 Cache 计算再all_gather汇总从而针对长序列 Lightning Indexer 瓶颈实现 rank 间负载均衡。MoE 通信优化将节点间低带宽通信限制在topk12扩展前的原始 Token 上——节点间按local_rank_id相同卡间all_gather汇集 Token节点内做 EP 域all_to_all与专家计算节点间再reduce_scatter汇聚专家结果。分层 KV Cache 传输PD 之间使用分层 Cache 传输释放多专家与超长序列带来的内存压力。性能优化GE 静态图、多流控核与权重预取图模式通过torch.compile指定ge_graphbackend 成图削减 Decode 阶段算子下发开销并支持图编译缓存tng.inference.cache_compile缓存后的静态图在下次启动时直接加载缩短首次推理时延主模型缓存路径./compile_cache/CASE_NAMEMTP 模型为./compile_cache/CASE_NAME_spec。多流并行与控核将第二段 Attention 与 FFN 专家提前执行到独立 stream 上与 MoE 流水重叠并对双流分别施加c12v2412 Cube 核 24 Vector 核控核使双流计算时间接近、无明显拖尾。实现示意伪代码attn layernorm with npu_stream_switch(True, 1): with limit_core_num(True, 12, 24): router dispatch gmm combine with limit_core_num(True, 12, 24): dense attn layernorm dense本仓库 NPU 多流原理 文档从 Cube/Vector 物理资源竞争、Stream 与 Event 同步机制的角度解释了这类并行为何成立。权重预取利用torch_npu.npu_prefetch在前序非访存瓶颈算子如 RmsNorm执行期间把后续 Matmul/GMM 的部分权重提前从 HBM 搬入 L2 Cache。本仓库 NPU Prefetch 原理 给出了分析 profiling → 判断前序算子是否访存密集 → 调整预取大小与位置的通用调试流程。参考文档内容路径本实践样例部署文档models/longcat-2.0/README.mdLongCat 2.0 推理优化技术报告docs/models/longcat-2.0/longcat_2.0_optimization.md量化版 Lightning Indexer 算子文档ops/ascendc/docs/custom-npu_quant_lightning_indexer.mdNPU 多流原理docs/cann/zh/multi_stream_principles.mdNPU Prefetch 原理docs/cann/zh/prefetch_principles.md【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考