大模型推理部署跟小模型完全是两回事。小模型一张卡就能装下调几个参数就能跑。LLaMA-70B 参数 140GB需要多卡拆分解码阶段逐 Token 生成需要 KV Cache 优化Attention 是 Memory Bound需要 FlashAttention。cann-recipes-infer 是 CANN 社区维护的大模型推理参考仓库。它不只是一个代码示例集合——它提供了从模型转换到多卡推理的完整部署方案包括配置文件和性能调优建议。cann-recipes-infer 的定位cann-recipes-infer 不是一个推理框架。它不提供model.infer(text)这样的统一接口。它做的是另一件事——把 LLaMA、Qwen、ChatGLM 在昇腾上的推理部署路径固化下来让你不需要从零摸索。仓库的结构按模型分目录cann-recipes-infer/ ├── llama/ # LLaMA 系列 │ ├── convert.sh # 模型转换脚本 │ ├── config.yaml # 推理配置 │ └── README.md # 部署步骤 ├── qwen/ # Qwen 系列 ├── chatglm/ # ChatGLM 系列 └── common/ # 共享工具 ├── acl_utils.cpp └── model_utils.py每个模型的目录包含了转换脚本、推理配置和部署说明。按照 README 的步骤走就能跑通推理。LLM 如何部署到昇腾以 LLaMA-7B 为例cann-recipes-infer 的部署流程第一步模型准备。把 PyTorch checkpoint 转成 ONNX。python convert_llama_to_onnx.py--ckptllama-7b.pt--outputllama-7b.onnx第二步ATC 转换。atc--modelllama-7b.onnx\--framework5\--outputllama-7b\--soc_versionAscend910\--input_shapeinput_ids:1,512\--enable_kv_cachetrue--enable_kv_cachetrue让 ATC 在编译时预埋 KV Cache 的内存分配解码阶段不需要动态分配。第三步配置推理参数。config.yamlmodel:path:./llama-7b.ommax_length:4096batch_size:1kv_cache:enabled:truedtype:float16max_seq_length:4096inference:flash_attention:trueprefill_timeout_ms:100decode_loop_batch:true第四步运行推理服务。python run_infer_server.py--configconfig.yaml推理链路解析cann-recipes-infer 内部的 LLM 推理链路分三个阶段Prefill 阶段输入 Token 序列 → GE 图执行全部 Decoder Block 跑一次 → 生成第一个输出 Token → 所有层的 Key/Value 缓存到 KV Cache解码阶段循环上一步 Token → 单 Block 前向只算新 Token 的 Q跟 Cache 做 Attention → Cache 追加当前 Token 的 K/V → 生成下一个 Token → 重复直到结束结束条件生成 [EOS] Token 或达到 max_length。结束后用户可选的清理 KV Cache。KV Cache 如何优化推理吞吐KV Cache 是 LLM 推理的核心优化也是对显存最贪吃的部分。cann-recipes-infer 默认用 FP16 KV Cache。对于 LLaMA-13B40 层、40 头、隐藏维度 5120单 request 序列长度 4096 的 KV Cache 占用约 2.8GB。Batch4 时超过 11GB。cann-recipes-infer 支持三种 Cache 优化Cache 量化INT8。把 K/V 量化到 INT8Cache 大小减半。精度损失约 1-2% 对大多数模型可接受。cann-recipes-infer 的配置中设置kv_cache.dtype: int8即可开启。Paged KV Cache。把连续逻辑地址的 Cache 映射到不连续的物理页——不同 request 的 Cache 碎片可以被打包到同一物理页。CANN 8.0 原生支持无需应用层适配。Prefix Cache。共享 system prompt 的 request 可以复用同一段 Cache。比如两个用户都问了角色设定你是 Python 专家——这条 prompt 的 Cache 在两个对话中完全一样第二个人不需要重新计算。Prefix Cachecache_dir目录。kv_cache:prefix_caching:truecache_dir:/data/kv_cache_db/FlashAttention 如何减少显存占用cann-recipes-infer 的配置中flash_attention: true打开了 FlashAttention 融合。Prefill 阶段标准 Attention 需要保存完整的[n, n]Score 矩阵——n4096 时约 32MB。FlashAttention 把 Score 矩阵切成[block, block]的分块在片上计算并累加不写回 DDR。Prefill 显存占用节省约 15-20%。解码阶段标准 Attention 需要从 DDR 读取完整的 KV Cache 到片上再做计算。Cache 越大搬运量越大——这是解码阶段 Attention 的 Memory Bound。FlashAttention 在解码阶段用分块读取策略一次只读一个 Cache 分块到片上算完再读下一块。不要求全部 Cache 数据同时驻留在片上。继续学习cann-recipes-infer 把 LLM 推理的部署路径和优化配置固化成了可复用的参考实现。理解了推理链路的三个阶段和 KV Cache 管理方案后可以进一步深入 CANN 的算子层面——FlashAttention 在 ops-transformer 中的融合实现、KV Cache 在 Runtime 中的内存管理机制。cann-recipes-infer 仓库ops-transformer FlashAttention 实现实际部署中的性能数据在 8×Ascend 910 节点上部署 LLaMA-13B使用 cann-recipes-infer 的默认配置配置Prefill 延迟 (n2048)解码延迟 (每 Token)最大并发FP16, 单卡无法运行超显存——FP16, 4 卡 TP128ms18.5ms32FP16, 4 卡 TP INT8 Cache130ms19.2ms64INT8 Cache Prefix Cache131ms19.5ms80INT8 Cache 让并发翻倍。Prefix Cache 在 system prompt 长的场景角色设定类对话下效果最好——第一个用户创建了 Complete KV Cache第二个用户进来时前 500 Token 的 Cache 直接复用Prefill 延迟从 128ms 降到 65ms。从 cann-recipes-infer 到生产部署cann-recipes-infer 的参考实现可以直接作为生产部署的起点。但生产环境需要的额外工程工作请求排队与批处理cann-recipes-infer 的 Batch1 是单请求模式。生产环境需要做 Continuous Batching——不同进度的 request 混在一起提交超时与错误恢复推理调用可能超时25 秒单次推理的上限需要回退机制监控指标Prefill 延迟、解码延迟、Cache 命中率、显存使用率cann-recipes-infer 在单机单卡场景已经能直接跑通 LLM 推理。多卡场景需要结合张量并行和流水线并行的配置。通往生产环境的下一步是套上服务框架如 Triton 或 FastAPI加上请求管理和监控面板。总结cann-recipes-infer 的目标是消除 LLM 推理部署中从能跑到跑好之间的差距。它把 LLaMA 等主流模型在昇腾上的部署路径固化成了可复用的参考实现——从 ATC 转换的配置、KV Cache 的管理策略到 FlashAttention 的开启方式都包含在内。对于第一次在昇腾上部署 LLM 的团队从 cann-recipes-infer 的配置开始调优是最省时间的路径。KV Cache 管理对并发的影响KV Cache 的管理策略直接决定了 LLM 推理服务的最大并发数。以单张 Ascend 91032GB 显存部署 LLaMA-13B 为例模型参数占用约 26GB。FP16 下单 request 的 KV Cache 约 2.8GBn4096。剩余约 3.2GB 显存只能支持 1 个并发 request。开启 INT8 KV Cache 后 Cache 降到 1.4GB并发提升到 2。再启用 Prefix Cachesystem prompt 复用第一个 request 的 500 Token Cache 被后续 request 共用——第二次请求的 Cache 增量只有 3.5KB显存几乎不需要额外分配。这就是 KV Cache 优化在实际部署中的价值——同样是单张卡优化前后的并发能力可能差 4-10 倍。参考仓库cann-recipes-infer 仓库ops-transformer 算子仓库
cann-recipes-infer：LLM 在昇腾上的推理参考实现
大模型推理部署跟小模型完全是两回事。小模型一张卡就能装下调几个参数就能跑。LLaMA-70B 参数 140GB需要多卡拆分解码阶段逐 Token 生成需要 KV Cache 优化Attention 是 Memory Bound需要 FlashAttention。cann-recipes-infer 是 CANN 社区维护的大模型推理参考仓库。它不只是一个代码示例集合——它提供了从模型转换到多卡推理的完整部署方案包括配置文件和性能调优建议。cann-recipes-infer 的定位cann-recipes-infer 不是一个推理框架。它不提供model.infer(text)这样的统一接口。它做的是另一件事——把 LLaMA、Qwen、ChatGLM 在昇腾上的推理部署路径固化下来让你不需要从零摸索。仓库的结构按模型分目录cann-recipes-infer/ ├── llama/ # LLaMA 系列 │ ├── convert.sh # 模型转换脚本 │ ├── config.yaml # 推理配置 │ └── README.md # 部署步骤 ├── qwen/ # Qwen 系列 ├── chatglm/ # ChatGLM 系列 └── common/ # 共享工具 ├── acl_utils.cpp └── model_utils.py每个模型的目录包含了转换脚本、推理配置和部署说明。按照 README 的步骤走就能跑通推理。LLM 如何部署到昇腾以 LLaMA-7B 为例cann-recipes-infer 的部署流程第一步模型准备。把 PyTorch checkpoint 转成 ONNX。python convert_llama_to_onnx.py--ckptllama-7b.pt--outputllama-7b.onnx第二步ATC 转换。atc--modelllama-7b.onnx\--framework5\--outputllama-7b\--soc_versionAscend910\--input_shapeinput_ids:1,512\--enable_kv_cachetrue--enable_kv_cachetrue让 ATC 在编译时预埋 KV Cache 的内存分配解码阶段不需要动态分配。第三步配置推理参数。config.yamlmodel:path:./llama-7b.ommax_length:4096batch_size:1kv_cache:enabled:truedtype:float16max_seq_length:4096inference:flash_attention:trueprefill_timeout_ms:100decode_loop_batch:true第四步运行推理服务。python run_infer_server.py--configconfig.yaml推理链路解析cann-recipes-infer 内部的 LLM 推理链路分三个阶段Prefill 阶段输入 Token 序列 → GE 图执行全部 Decoder Block 跑一次 → 生成第一个输出 Token → 所有层的 Key/Value 缓存到 KV Cache解码阶段循环上一步 Token → 单 Block 前向只算新 Token 的 Q跟 Cache 做 Attention → Cache 追加当前 Token 的 K/V → 生成下一个 Token → 重复直到结束结束条件生成 [EOS] Token 或达到 max_length。结束后用户可选的清理 KV Cache。KV Cache 如何优化推理吞吐KV Cache 是 LLM 推理的核心优化也是对显存最贪吃的部分。cann-recipes-infer 默认用 FP16 KV Cache。对于 LLaMA-13B40 层、40 头、隐藏维度 5120单 request 序列长度 4096 的 KV Cache 占用约 2.8GB。Batch4 时超过 11GB。cann-recipes-infer 支持三种 Cache 优化Cache 量化INT8。把 K/V 量化到 INT8Cache 大小减半。精度损失约 1-2% 对大多数模型可接受。cann-recipes-infer 的配置中设置kv_cache.dtype: int8即可开启。Paged KV Cache。把连续逻辑地址的 Cache 映射到不连续的物理页——不同 request 的 Cache 碎片可以被打包到同一物理页。CANN 8.0 原生支持无需应用层适配。Prefix Cache。共享 system prompt 的 request 可以复用同一段 Cache。比如两个用户都问了角色设定你是 Python 专家——这条 prompt 的 Cache 在两个对话中完全一样第二个人不需要重新计算。Prefix Cachecache_dir目录。kv_cache:prefix_caching:truecache_dir:/data/kv_cache_db/FlashAttention 如何减少显存占用cann-recipes-infer 的配置中flash_attention: true打开了 FlashAttention 融合。Prefill 阶段标准 Attention 需要保存完整的[n, n]Score 矩阵——n4096 时约 32MB。FlashAttention 把 Score 矩阵切成[block, block]的分块在片上计算并累加不写回 DDR。Prefill 显存占用节省约 15-20%。解码阶段标准 Attention 需要从 DDR 读取完整的 KV Cache 到片上再做计算。Cache 越大搬运量越大——这是解码阶段 Attention 的 Memory Bound。FlashAttention 在解码阶段用分块读取策略一次只读一个 Cache 分块到片上算完再读下一块。不要求全部 Cache 数据同时驻留在片上。继续学习cann-recipes-infer 把 LLM 推理的部署路径和优化配置固化成了可复用的参考实现。理解了推理链路的三个阶段和 KV Cache 管理方案后可以进一步深入 CANN 的算子层面——FlashAttention 在 ops-transformer 中的融合实现、KV Cache 在 Runtime 中的内存管理机制。cann-recipes-infer 仓库ops-transformer FlashAttention 实现实际部署中的性能数据在 8×Ascend 910 节点上部署 LLaMA-13B使用 cann-recipes-infer 的默认配置配置Prefill 延迟 (n2048)解码延迟 (每 Token)最大并发FP16, 单卡无法运行超显存——FP16, 4 卡 TP128ms18.5ms32FP16, 4 卡 TP INT8 Cache130ms19.2ms64INT8 Cache Prefix Cache131ms19.5ms80INT8 Cache 让并发翻倍。Prefix Cache 在 system prompt 长的场景角色设定类对话下效果最好——第一个用户创建了 Complete KV Cache第二个用户进来时前 500 Token 的 Cache 直接复用Prefill 延迟从 128ms 降到 65ms。从 cann-recipes-infer 到生产部署cann-recipes-infer 的参考实现可以直接作为生产部署的起点。但生产环境需要的额外工程工作请求排队与批处理cann-recipes-infer 的 Batch1 是单请求模式。生产环境需要做 Continuous Batching——不同进度的 request 混在一起提交超时与错误恢复推理调用可能超时25 秒单次推理的上限需要回退机制监控指标Prefill 延迟、解码延迟、Cache 命中率、显存使用率cann-recipes-infer 在单机单卡场景已经能直接跑通 LLM 推理。多卡场景需要结合张量并行和流水线并行的配置。通往生产环境的下一步是套上服务框架如 Triton 或 FastAPI加上请求管理和监控面板。总结cann-recipes-infer 的目标是消除 LLM 推理部署中从能跑到跑好之间的差距。它把 LLaMA 等主流模型在昇腾上的部署路径固化成了可复用的参考实现——从 ATC 转换的配置、KV Cache 的管理策略到 FlashAttention 的开启方式都包含在内。对于第一次在昇腾上部署 LLM 的团队从 cann-recipes-infer 的配置开始调优是最省时间的路径。KV Cache 管理对并发的影响KV Cache 的管理策略直接决定了 LLM 推理服务的最大并发数。以单张 Ascend 91032GB 显存部署 LLaMA-13B 为例模型参数占用约 26GB。FP16 下单 request 的 KV Cache 约 2.8GBn4096。剩余约 3.2GB 显存只能支持 1 个并发 request。开启 INT8 KV Cache 后 Cache 降到 1.4GB并发提升到 2。再启用 Prefix Cachesystem prompt 复用第一个 request 的 500 Token Cache 被后续 request 共用——第二次请求的 Cache 增量只有 3.5KB显存几乎不需要额外分配。这就是 KV Cache 优化在实际部署中的价值——同样是单张卡优化前后的并发能力可能差 4-10 倍。参考仓库cann-recipes-infer 仓库ops-transformer 算子仓库
