G8 容量与成本
编制：观澜｜日期：2026-10-06｜级别：T2 标准级 层级：G 层 · 企业落地（G 层第 8 课；前接 G6 问答编排、G7 效果评估，后接 G9 企业安全） 素材来源：MindIE 3.1.0（《性能/精度测试工具》AISBench、《大规模专家并行方案典型配置》、《服务化调优工具》msServiceProfiler）+ MindStudio 26.1.0（《MindIE 推理性能解决方案 · TopN 性能问题的解决方案》含服务化性能上限评估与显存瓶颈算法、《服务化专家建议工具》、《服务化自动寻优工具》）+ CANN 9.2.0-beta.2（《服务化自动寻优工具》）+ MindSDK 26.1.0（RAG SDK《模型推理加速》）+ 官方案例库 版本口径：MindIE 3.1.0 / MindStudio 26.1.0 / CANN 9.2.0-beta.2 / RAG SDK 26.1.0，各条已单独标注 数据纪律：任何性能与成本数字都必须有官方出处；官方没给的（单价、"一张卡支持多少并发"的通用值）一律明写「官方未给出」，不编。
第一段 章前定位
这一课不教你什么
先把三课的边界划清——这一课不是 D5，也不是 F4。
| D5《可用性与调优》 | F4《性能调优》 | 本课 G8《容量与成本》 | |
|---|---|---|---|
| 问的问题 | 服务别挂：进程卡死没有、健康检查通不通 | 跑得慢怎么变快：慢在哪一层、数据怎么采、怎么看 | 算力要买多少、卡怎么分、成本怎么算 |
| 视角 | 服务视角（就绪、自愈、静默故障） | 设备与执行视角（算子、搬运、通信、下发） | 采购与业务视角（并发数、显存容量、节点台数、单位成本） |
| 触发场景 | 服务起来了但不稳定 | 服务稳定但时延/吞吐不达标 | 服务达标了，但老板问"这要几台机器、一年多少钱" |
一句话分工：
D5 管"活着"，F4 管"跑得快不快"，G8 管"要花多少、怎么花最省"。
三课都会碰到 maxBatchSize、吞吐、显存 这些词，但问的问题完全不同：
F4 问"怎么把吞吐提上去"，G8 问"这个吞吐下，显存够撑到多少并发、要几台机器、每台机器摊到每千 token 多少钱"。
F4 是把机器跑快，G8 是决定买几台机器。
其次，这一课有几件事给不了你答案
这是本课最需要提前说明的一条，因为它直接决定这份文档可不可信：
| 你想要的 | 为什么给不了 |
|---|---|
| "一张 Atlas 800I A2 能支持多少并发" 的通用值 | 并发上限取决于模型、权重精度、输入输出长度、序列长度、NPU_MEMORY_FRACTION 等；官方未给出与场景无关的通用数字，只能按你的场景实测 + 按官方公式估算 |
| "一年多少钱" 的报价 | 硬件/云资源价格随采购渠道与时间变；官方文档不含价格数字。本课给的是算成本的公式与取数口径，价格按实际采购/计费填进去 |
| "这个模型该用几台机器" 的固定答案 | 官方给的是按 AI 计算节点规模查的典型配置表（P/D 实例与节点数的对应），不是按模型名给的固定值 |
⭐ 所以本课教的是四件"能自己算出来"的事： ① 怎么测出发上限；② 怎么把上限折算成并发/批量；③ 怎么按官方表查出机器台数；④ 怎么用实测吞吐 × 按实际计价得到单位成本。
第三，一条数据纪律先讲明
性能与成本数字最容易被编造（"这张卡能带 1000 并发"这类）。本课的原则：
凡官方给了公式/阈值/示例值的，写明「出处 + 版本 + 是示例还是要现场确认」；官方没给的，正文里明写「官方未给出，需现场实测/按实际计价」。
一个必须记住的口径： 官方在不同产品、不同场景下给的数字口径并不统一（例如"未掩盖通信 ≤10%"来自 MindSpeed LLM 的 FSDP2 训练场景）。 本课会逐条标明每个数字来自哪篇文档、哪个场景，避免把一个场景的值当普适真理用。
第二段 学习目标
学完这一课，你应该能：
- ✅ 说清容量规划的四个问题：一张卡能扛多少并发 → 卡怎么分 → 要几台机器 → 一年多少钱，以及每个问题各自的依据来源
- ✅ 用官方公式把"显存"折算成"最大并发/
maxBatchSize"：记住cacheBlockSize默认值、最大/平均 Block 数量公式、Floor[Total Block Num / Block 数量]这条上限 - ✅ 用实测拿到
Total Block Num（查日志关键字npuBlockNum）和纯模型性能上限，并知道服务化吞吐要按纯模型折算（官方口径 0.8~0.9） - ✅ 说清"卡怎么分"的四个维度：TP / DP / PP / EP，以及官方的三条调优建议（Attention 的 TP 尽量小、增加 DP、纯 DP 可省 KV Cache）
- ✅ 按官方典型配置表查出机器台数：知道 A2 与 A3 两种服务器各自的 P/D 实例规格、每套集群管理组件管多少节点、以及前提条件
- ✅ 说清成本怎么算、哪里算不出来：用实测吞吐 × 按实际计价；知道单价官方未给出，"一张卡多少并发"官方也没有通用值
- ✅ 排错时先分清"算错了（约束没查）"和"跑不对（参数太大/太小）"
第三段 全景：容量与成本是"四问一条链"
3.1 一句话总览
容量与成本 = 四问，从下往上问，不能跳：
④ 一年多少钱？ ← 吞吐（实测）× 单价（官方未给，按实际计价）
↑
③ 要几台机器？ ← 查官方「大规模专家并行方案典型配置」表（按节点规模查 P/D 规格）
↑
② 卡怎么分？ ← 并行策略 TP/DP/PP/EP + 显存策略（MEMORY_FRACTION / 量化 W8A8）
↑
① 一张卡能扛多少？ ← 显存约束 → KV Cache Block 数 → 反推 maxBatchSize（官方有公式）
⭐ 顺序为什么不能跳： 不先测出"一张卡的上限"，就不知道要几台机器；不知道要几台机器，谈"一年多少钱"就是猜。 而"一张卡能扛多少"这件事，官方没有通用答案 —— 只能①按公式估、②按实测定。
3.2 四个问题各自的"依据来源"（本课的骨架，后面逐段展开）
| # | 问题 | 依据来源 | 关键官方物 |
|---|---|---|---|
| ① | 一张卡能扛多少 | 官方有公式 + 需实测取数 | TopN 解决方案的"服务化性能上限评估"（KV Cache Block 算法） |
| ② | 卡怎么分 | 官方有建议策略 + 需现场调 | TopN 的"并行策略调优 / 通信策略优化" |
| ③ | 要几台机器 | 官方有典型配置表，按节点规模查 | MindIE《大规模专家并行方案典型配置》 |
| ④ | 一年多少钱 | 官方无价格；给定吞吐与取数口径由你填价 | 无需官方物，价格按实际采购/计费 |
3.3 三个必须记住的"官方没有"
在往下看之前，先把三件官方没给的事记牢，免得后面误用：
① 官方未给出「一张（某型号）卡在通用场景下能支持多少并发」的通用数字。
→ 并发上限 = 显存能容纳多少 Block / 每个请求占多少 Block（要按你的场景算 + 实测）
② 官方未给出硬件/云资源的单价。
→ 本文只给「成本 = 吞吐（实测，tokens/s 或 req/s）× 单价」的框架，
价格按实际采购合同或云计费填。
③ 官方未给出「本模型该用几台机器」的固定值。
→ 官方给的是「按 AI 计算节点规模查典型配置表」，台数由你的模型规模与并发需求决定。
3.4 一条"先测纯模型、再算服务化"的官方思路（很重要）
官方《MindIE 推理性能解决方案》给的整体思路是分两层看：
MindIE 推理性能可以从纯模型和服务化两个角度进行优化。 先确认当前纯模型的性能是否有调优空间 → 达到预期则进行服务化性能调优。
这条思路在容量规划里就是一句话：
先用纯模型测试量出"硬件上限"，再折算成服务化能交付的容量。
官方给出的折算口径（照抄）：
服务化的输出吞吐和非首 Token 时延，可参考相同并发（即 Decode Batchsize）下的纯模型结果作为理论估计的上限； 考虑到服务化推理会有框架侧调度等额外的时间开销，服务化吞吐的乐观估计可折算为纯模型吞吐 0.8~0.9 倍。
⭐ 0.8~0.9 这个系数是本课唯一敢写的"折算比例"——因为它出自官方原文。 除此之外，任何"提升 N 倍 / 单卡 N 并发"的数字本课一个都不写，因为官方没给。
3.5 本课也要用到的"加速"这一侧（RAG SDK）
在 G 层，容量里还有一块容易被漏掉的算力：embedding（向量化）。 知识库的"灌数据"和"在线问答的每一问"都要跑一次 embedding —— 官方在 RAG SDK 里专门给了模型推理加速这一支：
模型推理加速配置说明：TextEmbedding 模型当前支持 bert、roberta、xlm_roberta 类 embedding 模型向量化推理加速， 支持的数据类型为 float16。如需使用该功能，安装 RAG SDK 软件包时需将算子模块一并安装， 并且确保已经启用该功能（默认为关闭状态）。
这段话对容量规划的含义：embedding 的算力是默认没有加速的 —— 你按默认状态估的吞吐，会比开启加速后低；
反过来，你要先把加速开关打开，再测容量，不然基数就错了。具体命令见第五段。
第四段 【如果我来做】——一次真实的容量测算路径
这一节是本课的核心。 前三段讲的是"容量分四问、各自的依据在哪"，这一节讲： 如果客户把"这套要几台机器、卡怎么分"交给我，我按什么顺序做、每一步凭什么判断。
4.0 先亮结论：我会按这个顺序做
为什么顺序不能反：
- 不先对口径就开测 → 测出来的数字不知道对应什么场景，没法用；
- 不先量纯模型上限 → 直接压服务化，得到的是"服务化交付值"，不知道还有多少优化空间（也分不清是模型慢还是框架慢）；
- 不先算清显存能撑多少 →
maxBatchSize只能拍脑袋，要么拉不起来，要么显存浪费； - 先谈价格再谈台数 → 台数没定，价格无从谈起。
我会按这个顺序做（顺序 = 我"手伸进去"的顺序）：
① 先对口径：确认 TTFT/TPOT 的 SLO、输入/输出长度、目标并发或请求速率——没有这三样，后面全白算 ② 先看卡与显存：
npu-smi info看有几张卡、显存多大、有没有残留进程占着显存（占着就会算错） ③ 先量纯模型上限：按官方口径把"输入长度→Preill 时间、输出长度→Decode 时间"测出来，拿到 prefill_batchsize / decode_batchsize ④ 再取Total Block Num：查日志关键字npuBlockNum，拿 KV Cache 总 Block 数 ⑤ 算出maxBatchSize上限：按官方公式算"每个请求占几个 Block"，再Floor[Total Block Num / Block 数量]⑥ 用工具定推荐值：advisor给maxBatchSize范围，optimizer自动搜参数组合 ⑦ 定"卡怎么分"：选 TP/DP/PP/EP，先按官方给的参考配置起步，再按输入输出调 ⑧ 定"几台机器"：按节点规模查官方典型配置表，确定 P:D 比例与集群管理组件 ⑨ 算成本：实测吞吐 × 按实际计价，单价官方没有，必须问采购/看云计费 ⑩ 同口径复测 + 出证据：TTFT / 吞吐 / 成功率，调前调后同一个场景比 ⑪ 诚实：官方没给的部分（单价、通用并发值），明说是我按现场条件取的数
下面把中间的每一步展开。
4.1 第 0 步：先把"容量"定义出来（不做任何操作）
目的：在做任何测算之前，先拿到一组能对得上的口径。官方《MindIE 推理性能解决方案》把"明确优化目标"拆成两类场景：
| 场景 | 关注点 | 关注哪个阶段 |
|---|---|---|
| 低时延场景 | 实时交互（如对话系统），关注首 Token 生成速度 | Prefill 阶段优化 |
| 高吞吐场景 | 离线批量处理（如文档生成），关注 Tokens/秒 | Decode 阶段优化 |
我要对齐的四样（对齐不了就不做测算）：
| 要对齐的 | 为什么 | 官方给的对齐依据 |
|---|---|---|
| 时延 SLO | 是 TTFT 还是 TPOT？限制多少？ | 官方寻优工具参数里就有 ttft_slo / tpot_slo（单位 s） |
| 输入 / 输出长度 | 决定每个请求占多少 KV Cache Block | 官方算法明确按"输入 Token 数 / 最大输出 Token 数"算 |
| 并发 / 请求速率 | 决定显存与算力压力 | 官方压测工具里有 Concurrency 与 RequestRate 两个可设定项 |
| 数据类型 | float16 / float32 决定算力与显存口径 | RAG SDK 推理加速支持 float16 |
⚠️ 官方有一条重要提醒（照抄）： 有时性能目标和实际差异较大，可以根据纯模型性能简单评估性能上限，判断时延或吞吐的极限，从而判断目标是否有可能达成。 这句话我要背下来：客户给的 SLO 有可能物理上就达不到。 先估上限、再承诺 —— 这一步不做，后面就是白干一场。
4.2 第 1 步：先看卡与显存（零成本粗判）
先敲 npu-smi info（见第五段命令 ①）。我要看三件事：
- 有几张卡、每卡多大显存 —— 这直接决定"最多能放几个请求的 KV Cache"；
- 利用率是不是高 —— 如果设备已经很忙，说明现有配置下算力已接近上限（利用率口径见第六段）；
- 有没有残留进程占着显存 —— 这是最容易让容量算错的一条（官方案例
topic_0000001589894865就是"用npu-smi info查看显存时发现 Python 进程残留"）。 残留进程没清，你会以为"这张卡只剩这么点显存"，于是把并发算小。
所以第 1 步的作用是：确认"这张卡的可用显存到底是多少"，而不是直接读出并发数。读取的显存只能当"分母"，分子要靠第 2、3 步。
4.3 第 2 步：先量纯模型上限（这是"分母"的来源）
官方《MindIE 推理性能解决方案》"纯模型初步测试"给了一条可照做的步骤，我把它当清单抄下来：
- 设
--case_pair [[输入长度,1]]，模拟单个 Prefill Batch 的纯模型测试，--batch_size记为 prefill_batchsize，结果中的Total Time(s)记为 prefill_time； - 按实际输入输出长度设
--case_pair正常测试，--batch_size记为 decode_batchsize，结果中的Non-first token time(ms)记为 decode_token_time； - 调整两个 batchsize，找满足要求的配置；
- 如需要（并行策略、环境变量等），对不同配置重复步骤 1，选最优；
- 把纯模型的 Decode Batchsize 和 Prefill Batchsize 转化为服务化参数
maxBatchSize和maxPrefillBatchSize； - 设服务化与测试参数，按实测结果调整
maxBatchSize/maxPrefillBatchsize/ RequestRate。
官方还给了"按目标怎么配"的对照表（这是第 3 步的决策依据）：
| 场景 | 配置方法（官方原文） |
|---|---|
| 不限时延、要基线吞吐 | 调大 decode_batchsize 至 OOM（或选增速放缓的 decode_batchsize） |
| 限制 TPOT，不限制 TTFT | 调整 decode_batchsize 至 decode_token_time 刚好满足 TPOT 限制 |
| 限制 TPOT 和 TTFT（爬坡测试，限 Request Rate） | 调 decode_batchsize 至刚好满足 TPOT；调 prefill_batchsize 令 prefill_time 接近 TTFT 限制 |
| 限制 TPOT 和 TTFT（固定并发，不限 Request Rate） | 调 decode_batchsize 至刚好满足 TPOT；设 prefill_batchsize = dp，调小 decode_batchsize 直至接近平均 TTFT 限制 |
⭐ 上表第一行"调大至 OOM"很关键："最省心"的容量基线，就是把批量一直加到显存装不下—— 加不动的那个点，就是这张卡在这个场景下的吞吐上限。这与第 3 步的公式是同一个物理约束的两面。
4.4 第 3 步：把"显存"折算成"最大并发"（官方公式）
这一步是 G8 区别于 F4 的地方：F4 讲"怎么把显存用得更满"，G8 讲"显存这么大，最多能同时服务几个请求"。
官方原话（《MindIE 推理性能解决方案 · 服务化性能上限评估》）：
显存瓶颈下的最大并发/maxBatchsize 的理论上限：Decode 阶段 maxBatchSize 主要受显存限制，可根据 KV Cache Block 数量和序列长度计算。 - KV Cache 缓存池以 Block 为单位分配，Block 的大小通过 MindIE 服务化参数配置中的 cacheBlockSize 设置，一般使用默认值 128，即每个 Block 可存储 128 个 Token，根据使用场景的上下文长度计算每个请求需要占用的 KV Cache Block 数量：
最大Block数量 = Ceil(输入Token数 / cacheBlockSize) + Ceil(最大输出Token数 / cacheBlockSize)
平均Block数量 = Ceil(平均输入Token数 / cacheBlockSize) + Ceil(平均输出Token数 / cacheBlockSize)
- MindIE 服务端 NPU 上 KV Cache Block 总可用数量 Total Block Num 可通过实测获取。
- 为保持最佳性能，maxBatchSize 一般不宜超过
Floor[Total Block Num / 最大Block数量]； 若请求之间的上下文长度差距较大，则上限可适当提高至Floor[Total Block Num / 平均Block数量]。
把公式翻译成一句话：
能放多少并发 = 显存里的总 Block 数 ÷ 每个请求要占的 Block 数。
官方还给了一个完整算例（照抄，用作"期望输出长什么样"的参照）：
估算显存瓶颈下的并发上限，Profiling 显示可用的 KV Cache block 数量是 1747，默认配置下每个 Block 大小是 128 个 Token， 根据 1024 输入 2048 输出的上下文要求，平均上下文为 1536，KV Cache 平均可容纳 1747 / [(1024+2048)/2/128] ≈ 145。
⭐ 这个算例的价值：它把"显存 → 并发"这条链完整走了一遍。 注意官方的口径是用"平均上下文"算平均值（145 是平均值口径）， 而上限要用"最大 Block 数量"——两者别混（第六段会明确区分）。
4.5 第 4 步：拿 Total Block Num（实测取数）
官方给的取数方法（照抄）：
MindIE 服务端 NPU 上 KV Cache Block 总可用数量 Total Block Num 可通过实测获取。 - 清空
/root/mindie/log下的所有旧日志文件，通过使能环境变量MINDIE_LLM_PYTHON_LOG_LEVEL和MINDIE_LLM_PYTHON_LOG_TO_FILE，使 MindIE LLM 中 Python 程序运行时产生 INFO 级别日志并写入文件； - 在确定除maxBatchSize之外的其他服务化配置后，使用默认值拉起服务，在服务端拉起成功后，使用grep命令搜索 MindIE LLM Python 程序日志中的npuBlockNum关键字，根据使用的卡数不同会返回多个结果，其中的最小值即为 MindIE 服务端 NPU 上 KV Cache Block 总可用数量，以图为例，总可用数量为 817。
这条我要记住两点：
- 为什么先"清空旧日志" —— 不清空，
grep出来的是历史值，会拿旧配置的 Block 数去算新配置的上限； - 为什么取"最小值" —— 多卡时会返回多条，最小值代表最紧的那张卡 —— 容量要按最紧的算，不能按最松的算。
4.6 第 5 步：用工具把"拍脑袋"变成"有推荐值"
手动算完上限，还要落到具体参数。官方给了两个工具：
| 工具 | 干什么 | 官方定位 |
|---|---|---|
| 服务化专家建议工具（advisor） | 给 maxBatchSize / maxPrefillBatchSize 的推荐值 |
基于 benchmark 输出、config.json、NPU 显存情况、部署模型综合分析 |
| 服务化自动寻优工具（optimizer） | 用 PSO 算法自动搜服务化参数组合 | 获取符合时延要求的最佳吞吐参数组合，支持 MindIE 与 vLLM |
官方对 advisor 的一句话坦白（必须转述）：
注意：由于 CPU、内存等硬件差异，网络环境等不同，以及模型参数配置的细节不同等，当前建议值不能保证性能一定有提升，需要实际修改后验证。
⭐ 所以 advisor 的定位是"起点"不是"答案" —— 它替你从 0 猜到一个范围，最终值仍要实测。 官方还给了两条经验：
maxPrefillBatchSize通常都设置为maxBatchSize的一半； 且建议先把maxBatchSize设为建议范围的平均值再逐步向最大值靠（设太大会导致模型拉起失败）。
4.7 第 6 步：定"卡怎么分"——并行策略
"卡怎么分"就是问：N 张卡，沿哪几个维度切。 官方给的维度与参考配置：
当前 16 卡推理场景，一般最优配置是 TP=8，DP=2，MOE_TP=4，MOE_EP=4； 但用户有不同的 Host 端（arm/x86）、输入输出要求等，这会造成最优的并行策略发生变化，因此需要调整并行策略。
官方另给了一批通信策略调优建议（照抄，这是"卡怎么分"背后的判断依据）：
- Attention 的 TP 尽量减小，增加 DP，避免 KV Cache 复制，避免重复访问和存储。
- 纯 DP 通信可节省 KV Cache，但模型权重需要占更多空间。
- 专家通信（EP）通过 ATB-Models 安装目录中配置文件
config.json里的ep_level关键字配置。- 通信可选择走 LCCL 或 HCCL，通常 LCCL 性能更优，但部分并行策略下适配可能有问题。
⭐ 学会读上面这段话："TP 小、DP 大"能省 KV Cache（因为 TP 会把 KV Cache 复制到每张卡上）； 但纯 DP 会让每张卡都要放完整权重 —— 于是显存被权重吃掉。 "卡怎么分"的本质就是在这两头之间找平衡：省了 KV Cache 可能装不下权重，权重分开了 KV Cache 又翻倍。
"卡怎么分"还牵涉显存策略，官方给的方向是量化：
优化达到瓶颈后，一个直观的方法是优化显存来使用更优的配置（例如并发数，并行策略等），可考虑采用量化来降低计算量和显存，目前适配最好方案为 W8A8。
还有一条可直接改的显存开关（官方案例里用的）：
调整服务化参数，
export NPU_MEMORY_FRACTION=0.96，maxSeqLen降低到 3K，达到最优效果。⚠️
0.96与3K是官方案例里的取值，不是通用推荐值 —— 照抄前要按你的场景重测。
4.8 第 7 步：定"要几台机器"——查官方典型配置表
"几台机器"不是算出来的，是查出来的。 官方在《大规模专家并行方案典型配置》里，按AI 计算节点规模给了 P/D 实例规格表。
先看前提条件（选型先过这一关）：
大规模专家并行方案采用的 Atlas 800I A2 仅支持 Atlas 800I A2 HCCS 款，且 NPU 片上内存必须为 64GB，NPU 网口光模块必须为 200G。
再看 A2 的典型配置表（照抄）：
| AI 计算节点规模 | PD 实例规格 | 集群管理组件实例规格 | 通算节点规格 |
|---|---|---|---|
| 8 节点 | 2P+1D，每 P 实例 2 个计算节点，每 D 实例 4 个计算节点，另可配 1 冗余节点 | 1*(Coordinator+Controller) | 单机或双机 |
| 16 节点 | 4P+1D（每 P 2 节点、每 D 8 节点），另可配 1 冗余节点；也可组成 4P+2D | 1*(Coordinator+Controller) | 单机或双机 |
| 32 节点 | 8P+2D（每 P 2 节点、每 D 8 节点） | 1*(Coordinator+Controller) | 单机或双机 |
| 64 节点 | 16P+4D（每 P 2 节点、每 D 8 节点） | 1*(Coordinator+Controller) | 单机或双机 |
| 96 节点 | 24P+6D（每 P 2 节点、每 D 8 节点） | 1*(Coordinator+Controller) | 单机或双机 |
| N * 96 节点 | N*(24P+6D) | 1*(Coordinator+Controller) | 单机或双机 |
两条容量相关的硬约束（照抄）：
每套集群管理组件实例（即 Coordinator/Controller 实例）管理一套 PD 实例，每套集群管理组件实例最大支持管理 96 节点（24P+6D）。 以 192 节点集群为例，需划分为两套独立的 24P+6D 实例，集群管理组件实例也需要对应创建两套。
通算节点用于部署集群管理组件（Coordinator/Controller），不承担模型主体推理计算。
A3 超节点则是另一套规格（照抄要点）： 每 P 实例分配 1 个计算节点，每 D 实例可分配 1/2/4/8 个计算节点； 每套集群管理组件实例管理一个超节点（48 计算节点）；如现场部署多个超节点，需划分多套独立的 PD 实例（每套 48 节点）。
通算节点的硬件最低要求（照抄）：按每个 Controller 实例 4 核 / Coordinator 实例 16 核计算，一套 Controller+Coordinator 实例共需要 20 核；内存最低 8GB；至少 2 个 25GE 网口。
⭐ "几台机器"的最后一块拼图：算力节点（P/D）+ 通算节点（跑集群管理组件）。 通算节点不参与模型推理 —— 报价时别漏了它，也别把它算进算力。
4.9 第 8 步：算成本——官方只给了"骨架"
成本 = 吞吐（实测）× 单价（按实际计价）
| 要填的 | 从哪来 | 官方给不给 |
|---|---|---|
| 每分钟/秒的吞吐 | AISBench 或自有压测工具的实测结果（如 Total Token Throughput） |
工具会给，具体数字要自己测 |
| 算力节点台数 | 4.8 的典型配置表 + 你的并发需求 | 表给，规模由你的场景定 |
| 通算节点台数 | 每套集群管理组件一套 | 表给 |
| 单价（元/卡·时 或 元/台·年） | 采购合同或云计费单 | ❌ 官方未给出 |
| 单位成本 | 吞吐 ÷ 成本 | 自定义口径 |
⚠️ 本课在这里必须停住：官方文档不含任何价格数字。 任何"一年 X 万""每千 token X 分"的说法，如果不是来自你的采购合同或云计费单，就是编的。 本课能给的是公式与取数口径，价格那一格留给你填。
4.10 第 9 步：复测与出证据
官方给的验证方法（照抄）：
业务指标：在相同负载下使用 AISBench 或自有压测工具，对比调优前后的 TTFT（首 Token 时延）、吞吐（Output Token Throughput）、端到端时延等，确认有提升且无劣化。 剖析数据：使用 msprof 或 MindIE 提供的 msServiceProfiler 服务化调优工具 采集调优后的性能数据（含算子级与调度链路），解析后通过 MindStudio Insight 等工具做可视化分析。
验收证据（我会留给客户的三样）：
- 一份压测报告：同场景下的 TTFT / TPOT / 吞吐 / 成功率（AISBench 输出）；
- 一页容量测算：总 Block 数、每请求 Block 数、
maxBatchSize上限、实际设定值； - 一张成本表：算力节点数 + 通算节点数 + 实际单价 + 单位成本口径。
4.11 第 10 步：诚实——哪些地方我要明说"官方没给"
| 我做不到的 | 为什么 |
|---|---|
| 给"某型号卡支持多少并发"的通用值 | 取决于模型/精度/输入输出长度/序列长度/显存策略；官方未给出通用数字 |
| 给"一年多少钱"的报价 | 官方文档不含价格；只有采购合同/云计费单能回答 |
| 给"某模型该用几台机器"的固定值 | 官方给的是按节点规模查的典型配置表，不是按模型名给的固定值 |
| 承诺"这套参数在你的场景也行" | 官方明说建议值需实际修改后验证；并行策略随 Host 端与输入输出变化 |
第五段 怎么确认"算对了"：可照抄的命令与取数
本节命令全部来自官方文档，逐条标注出处；每条给「含义 / 拆解 / 用法 / 期望 / 不过会怎样」五项。 命令用行内码书写；只有真正的多行配置/输出才用代码块。
命令 ① npu-smi info
命令 npu-smi info
含义：查 NPU 设备信息与显存占用——容量测算的分母来源（先知道有多少显存、有没有被占） 拆解：
npu-smi（昇腾设备管理工具）＋info（显示设备信息） 用法：直接敲。官方 RAG SDK 文档明确：可用它获取对应 npu 卡的<bus-id>（后面绑核要用） 期望：一张表，列出每张卡的型号、温度、显存占用、进程等；没被占用时应只有系统进程 不过会怎样：命令不存在 → 驱动没装（回 A1）；有 Python 进程残留占着显存 → 你会把"可用显存"算小， 先清残留（官方案例topic_0000001589894865就是这个现象）
命令 ② lspci -vs 0000:83:00.0
命令 lspci -vs 0000:83:00.0
含义：按命令 ① 拿到的
<bus-id>，查这张 NPU 卡对应的 NUMA node 拆解：lspci（列 PCI 设备）＋-v（详细信息）＋-s（指定设备地址）＋0000:83:00.0（换成你查到的 bus-id） 用法：官方 RAG SDK"绑CPU核提升推理性能"章节第 2 步；这是为后面numactl绑核做准备的 期望：输出里能看到该设备的 NUMA node 编号 不过会怎样：参数不对 → 报No such device；bus-id 抄错（npu-smi info里有多个卡，容易抄到别的卡上）
命令 ③ lscpu | grep NUMA
命令 lscpu | grep NUMA
含义：查 NUMA node 对应的 CPU 核数范围，为
numactl准备核号 拆解：lscpu（打印 CPU 架构信息）＋ 管道|＋grep NUMA（只留含 NUMA 的行） 用法：官方同章节第 3 步 期望：看到 NUMA node 数、每个 node 的 CPU 列表（如NUMA node0 CPU(s): 0-47） 不过会怎样：输出为空 → 机器不支持或lscpu缺失；不看这一步直接抄官方示例的48-71→ 核号不属于该 NUMA node，绑核反而更慢
命令 ④ numactl -C 48-71 xxxx程序
命令 numactl -C 48-71 xxxx程序
含义：在程序执行前把程序绑到指定 CPU 核上，减少跨 NUMA 访问 拆解：
numactl（NUMA 控制工具）＋-C 48-71（绑到 48–71 号核，须按命令 ③ 的实测核号替换）＋ 后面跟你的程序 用法：官方同章节第 4 步；注意官方写的是"在程序执行前添加"，即它是命令前缀 期望：程序正常跑，逻辑上减少跨 NUMA 访问（具体收益官方未给数字，要实测） 不过会怎样：核号不属于该 NUMA node → 报错或性能反而下降；numactl未安装 →command not found⚠️ 官方把这条归在"如果设备为鲲鹏系列服务器" —— 非鲲鹏平台是否适用，需现场确认
命令 ⑤ pip3 show mx_rag
命令 pip3 show mx_rag
含义：查 RAG SDK 的安装路径，用来判断它是 run 包装的还是 whl 包装的 拆解：
pip3 show（显示已装 Python 包信息）＋mx_rag（包名） 用法：官方明确：run 包安装时mx_rag装在$HOME/./local/lib下；这决定你在代码里用哪一种导包方式 期望：打印包的版本、路径（如Location: /root/.local/lib/python3.x/site-packages） 不过会怎样：报Package(s) not found→ RAG SDK 没装（回 G3 的安装步骤）；用错导包方式 →ImportError
命令 ⑥ export ENABLE_BOOST=True
命令 export ENABLE_BOOST=True
含义：打开 embedding 向量化的推理加速（官方默认关闭） 拆解：
ENABLE_BOOST是官方环境变量；官方原文：设置值为"True"、"true"、"1"时表示使能加速，设置其他值表示不使能加速 用法：官方示例是在 Python 里os.environ["ENABLE_BOOST"] = "True"；shell 里就是本命令。必须在测容量前打开，否则你测的是未加速的基数 期望：加速生效；但注意官方提示：clip 类模型开启加速后"首次推理会进行图编译，预计耗时 1-2 分钟" 不过会怎样：设成"true "（带空格）等非法值 → 静默不生效（官方口径：设其他值表示不使能）； 加速不生效时你的容量测算偏低，而且不会报错——这是最难发现的一类错 ⚠️ 官方注明：clip 系列模型在 Atlas 300I Duo 上支持加速的 batch 为<=4，其他 batch 加速无明显性能提升甚至有劣化
命令 ⑦ MINDIE_LLM_PYTHON_LOG_LEVEL + grep npuBlockNum
命令 grep npuBlockNum <MindIE LLM Python 程序日志>
含义：从日志里取到 KV Cache 总 Block 数（Total Block Num）—— 这是算
maxBatchSize上限的分母 拆解：官方给的前置动作是使能MINDIE_LLM_PYTHON_LOG_LEVEL与MINDIE_LLM_PYTHON_LOG_TO_FILE（让 Python 程序输出 INFO 级日志到文件）； 然后用grep搜关键字npuBlockNum用法：先清空/root/mindie/log下的旧日志 → 用默认值拉起服务 → 再 grep。官方明说：多卡会返回多个结果，取其中最小值 期望：日志中出现多行含npuBlockNum的记录，最小值即总可用 Block 数（官方示例值：817） 不过会怎样：没清旧日志 → grep 到历史值，上限算错；没开 INFO 日志 → grep 不出任何东西； 取的是最大值而非最小值 → 按最松的卡算，实际跑起来会掉 ⚠️ 默认值 817、cacheBlockSize 默认 128 都是官方示例/默认口径，你的机器是多少要现场取
命令 ⑧ export MINDIE_LLM_PYTHON_LOG_LEVEL=...（配合 ⑦ 使用）
命令 export MINDIE_LLM_PYTHON_LOG_LEVEL=INFO export MINDIE_LLM_PYTHON_LOG_TO_FILE=1
含义：打开 MindIE LLM 的 Python 侧 INFO 日志并落盘，否则命令 ⑦ 无数据可查 拆解：官方原文只说"通过使能环境变量
MINDIE_LLM_PYTHON_LOG_LEVEL和MINDIE_LLM_PYTHON_LOG_TO_FILE，使 Python 程序运行时产生 INFO 级别日志并写入文件"， 这两个变量的取值范围官方未在本处给出，须以你所用版本的《MindIE 用户指南》为准 用法：拉起服务前 export；配合命令 ⑦ 一起用 期望：服务拉起后，MindIE 日志目录下出现 Python 程序的 INFO 日志文件 不过会怎样：变量名拼错 → 不报错、也不生效（日志照样不生成）； ⚠️ 取值口径由你按版本确认，本课不写死（避免照抄一个过期值）
命令 ⑨ msserviceprofiler advisor -in 4096 -out 256
命令 msserviceprofiler advisor -in 4096 -out 256
含义：让服务化专家建议工具根据显存、模型、输入输出长度给出
maxBatchSize的建议取值范围 拆解：advisor（专家建议子命令）＋-in/--input_token_num 4096（请求输入长度）＋-out/--output_token_num 256（请求输出长度）； 另有-t/--target（ttft默认 /firsttokentime/throughput）、-m/--target_metrics（average默认 /P90/P99等）、-tp用法：先装工具：git clone https://gitcode.com/Ascend/msserviceprofiler.git→cd msserviceprofiler/msservice_advisor→pip install .； 前置要有 MindIE Service 的config.json，且npuDeviceIds对应的 NPU 显存占用贴近拉起服务前的实际情况 期望：输出形如[config] maxBatchSize / [advice] 取值范围为 [xx, xx]，平均值为 xx / [reason] ...； 官方建议先把maxBatchSize设为平均值，maxPrefillBatchSize设为maxBatchSize的一半，再向 range 最大值靠 不过会怎样：以 root 运行会被官方劝阻（官方安全警告：请勿以 root 用户身份运行此工具）； 显存数据不准 → 建议值偏离；maxBatchSize设太大会导致模型拉起失败（官方原文），此时要往 range 最小值靠
命令 ⑩ msserviceprofiler advisor -i /your/path/instance/
命令 msserviceprofiler advisor -i /your/path/instance/
含义：同上工具，但改成基于 benchmark 的
instance结果拟合，同时给出maxBatchSize与maxPrefillBatchSize拆解：-i / --instance_path（benchmark 输出的 instance 路径）；官方要求样本量不少于 1000 条 用法：先用 MindIE benchmark 跑出instance结果并落盘到该路径，再执行本命令 期望：输出[advice] 尝试设置为 X，原值 Y（含两个参数），并生成拟合数据图像（如func_curv_xxxx.png）用于查看拟合是否合理 不过会怎样：样本量不足 1000 → 拟合不可靠；报找不到 instance 路径 → benchmark 没跑或路径写错； ⚠️ 官方提醒：可尝试把推荐值应用到config.json并重新验证性能，如果结果不理想，可只应用其中一个值再验证
命令 ⑪ msserviceprofiler optimizer
命令 msserviceprofiler optimizer
含义：服务化自动寻优 —— 基于 PSO 算法自动搜服务化参数组合，找出符合时延要求的最佳吞吐参数组合 拆解：
optimizer（寻优子命令）；常用参数：-e/--engine（mindie默认 /vllm）、-b/--benchmark_policy（ais_bench默认 /vllm_benchmark）、-d/--deploy_policy（single默认 /multiple）、--pd（competition默认 /disaggregation）、-c/--config（自定义 TOML 配置） 用法：先装：cd msserviceprofiler/ms_serviceparam_optimizer→pip install -e .[real]（轻量化版）；vLLM 场景加-e vllm期望：寻优时间由模型大小和数据集大小决定，一般在 4~8 小时完成；结束后在当前目录result/store下生成data_storage_*.csv， 每行一组参数，前四列为generate_speed/time_to_first_token/time_per_output_token/success_rate，另有throughput/CONCURRENCY/REQUESTRATE/fitness不过会怎样：配置文件里n_particles/iters/ttft_slo/tpot_slo等寻优参数均为必填 —— 删掉或省略会直接报错； 不设ASCEND_RT_VISIBLE_DEVICES→ 可能用到不是你预期的那张卡
命令 ⑫ msserviceprofiler train -i=/path/to/input -o=/path/to/output
命令 msserviceprofiler train -i=/path/to/input -o=/path/to/output
含义：仿真模式下，先用 profiling 数据训练一个时延预测模型，之后寻优可在低 NPU 占用下快速给出推荐值 拆解：
train子命令 ＋-i/--input（必选，profiling 的输出路径）＋-o/--output（输出目录）＋-t/--type（mindie默认 /vllm） 用法：官方要求先按"服务化调优快速入门"实际跑一遍 MindIE 推理服务测试并采集 profiling，再拿来训练 期望：训练完成后，寻优时需开启MODEL_EVAL_STATE_ALL=True、MODEL_EVAL_STATE_IS_SLEEP_FLAG=True与PYTHONPATH不过会怎样：profiling 数据缺字段则训练不好 —— 官方点名需要包含batch_type、batch_size、forward_time、need_blocks、first_token_latency(ms)等； 仿真结果文件里real_evaluation=false的行是模型预测值，不是实测值（官方口径），别把预测当实测 ⚠️ 官方注明仿真模式的版本配套：MindIE 侧为 CANN 8.3.RC2 / MindIE 2.2.RC1；VLLM 侧为 CANN 8.2.RC1 / VLLM 0.8.4 —— 与本文其他部分的版本不同，注意区分
命令 ⑬ export NPU_MEMORY_FRACTION=0.96
命令 export NPU_MEMORY_FRACTION=0.96
含义：调整服务化可用的显存占比，把更多显存让给 KV Cache（容量不够时的一个开关） 拆解：
NPU_MEMORY_FRACTION是服务化参数；官方在显存瓶颈案例里用的取值是0.96，并同时把maxSeqLen降低到 3K 用法：案例语境是"Batchsize 达不到期望、KV Block 用尽" 时用；配合序列长度一起调 期望：同配置下能容纳的 KV Cache 变多，实际可达的 batchsize 提高 不过会怎样：0.96是官方案例取值，不是通用推荐值 —— 照抄到别的模型可能直接拉不起来； 只调这一个而不调maxSeqLen/maxBatchSize，可能仍达不到目标 ⚠️ 官方未给出该参数的取值范围与各值影响，需按你的版本手册与实测确认
第六段 判据：怎么算"容量估对了"
⚠️ 先看这一行：下面的每条判据都标了来源与口径。 官方未给出跨场景通用的"容量达标线" —— 容量是"你的场景 + 你的 SLO"决定的，没有通用阈值。
6.1 容量公式类判据（来源：MindStudio 26.1.0《MindIE 推理性能解决方案》）
| 判据 | 官方公式 / 口径 | 口径提醒 |
|---|---|---|
| 每个请求占几个 Block（上限） | 最大Block数量 = Ceil(输入Token数/cacheBlockSize) + Ceil(最大输出Token数/cacheBlockSize) |
用最大输出长度算，是"最坏情况" |
| 每个请求占几个 Block（平均） | 平均Block数量 = Ceil(平均输入Token数/cacheBlockSize) + Ceil(平均输出Token数/cacheBlockSize) |
官方算例 145 就是这个口径 |
| 最优性能下的并发上限 | maxBatchSize 一般不宜超过 Floor[Total Block Num / 最大Block数量] |
官方原话是"为保持最佳性能" |
| 上下文长度差异大时 | 上限可适当提高至 Floor[Total Block Num / 平均Block数量] |
是"可以适当放宽"不是"可以随便用" |
| Block 大小 | cacheBlockSize一般使用默认值 128（每 Block 128 个 Token） |
是默认值，"一般"用 |
| 总 Block 数 | Total Block Num 须实测（grep npuBlockNum，取最小值） |
官方示例 817 / 案例 1747 都是具体环境的实测值 |
6.2 折算类判据（来源同上）
| 判据 | 官方口径 |
|---|---|
| 服务化吞吐的乐观估计 | 折算为纯模型吞吐的 0.8~0.9 倍（考虑框架侧调度等额外开销） |
| 单并发 | 与纯模型单并发性能接近 |
| 大并发下的首 Token 时延上限 | 用纯模型测到算力瓶颈处的 Prefill Batchsize，以它划分服务化的并发请求数；FCFS 调度下平均首 Token 时延约为该轮的折算 |
| 显存瓶颈的物理边界 | 调大 decode_batchsize 至 OOM —— 加不动处即吞吐上限 |
⭐ 这两条要一起记："0.8~0.9"是服务化相对纯模型的折扣，"至 OOM"是纯模型自身的边界。 先找 OOM 边界，再打 0.8~0.9 的折，就是你要规划的服务化吞吐。
6.3 并行策略的参考值（来源：MindStudio 26.1.0，场景级参考）
| 判据 | 官方口径 | 口径提醒 |
|---|---|---|
| 16 卡推理的一般最优配置 | TP=8，DP=2，MOE_TP=4，MOE_EP=4 | 官方原话带"一般"，且随 Host 端（arm/x86）与输入输出要求变化，因此需要调整 |
| 省 KV Cache 的方向 | Attention 的 TP 尽量减小，增加 DP，避免 KV Cache 复制 | 是方向，不是数值 |
| 纯 DP 的代价 | 可节省 KV Cache，但模型权重需要占更多空间 | 一头省必然一头费 |
| 专家通信 | 通过 ATB-Models 目录 config.json 的 ep_level 配置 |
— |
| 通信库选择 | 可选 LCCL 或 HCCL，通常 LCCL 性能更优，但部分并行策略下适配可能有问题 | "通常"不是"一定" |
| 显存优化的首选量化 | 目前适配最好方案为 W8A8 | 官方口径：用于在满足精度前提下降低计算量和显存 |
6.4 可复用的性能判据（来自体系已有 F4，口径必须带）
⚠️ 这一小节是"借用"，不是"新增"。它们是性能调优口径的判据，不是容量判据—— 在 G8 里它们的用途是：当你把容量压到上限时，会用这些指标去确认"设备是不是真的忙起来了"。
| 判据 | 数值 | 来源与口径（逐条标） |
|---|---|---|
| Device Free 时间占比 | < 3% 好，≥ 3% 需关注 |
来源：MindSpeed LLM 26.1.0《FSDP2 后端模型性能优化指南》；口径：FSDP2 分布式训练场景，官方另声明该文不适用于在线推理、KV Cache 与推理量化 |
| 未掩盖通信 | ≤ 10% 好，> 20% 需关注 |
来源同上（同一张表、同一场景） |
| 访存 bound 初判 | aiv_mte2_ratio > 0.8（大量出现则需优化） |
来源：Rec SDK 26.1.0《性能调优》；口径：算子级字段，ratio = 该单元耗时 ÷ 总耗时 |
| 通信等待时长比例 | Wait Time Ratio > 0.2（怀疑慢卡） |
来源：CANN 9.2.0-beta.2《性能调优工具·扩展功能》；口径：等待时长/(等待时长+通信时长)，较新版本建议改用 msprof-analyze |
| 带宽使用率 | > 0.8 说明链路无瓶颈 |
来源同上 |
⭐ 一句必须记住的话：以上阈值全部是"场景级参考值"，跨场景不可直接套用。 官方未给出通用阈值 —— 你要做的是给自己的场景建一条基线，然后"改前 vs 改后"用同一口径比。
6.5 容量测算的验收清单（自查）
| 项 | 判据 |
|---|---|
| 口径齐了 | TTFT/TPOT SLO、输入输出长度、目标并发/请求速率、数据类型 —— 四样都在 |
| 显存干净 | npu-smi info 无残留进程占显存 |
| 总 Block 数取了最小值 | grep npuBlockNum 的结果取最小，且基于清空旧日志后的新日志 |
| 上限算过 | 有 Floor[Total Block Num / 最大Block数量] 的计算记录，且实际 maxBatchSize 不超过它 |
| 纯模型基线有 | 有 prefill_time / decode_token_time 的纯模型测试记录 |
| 服务化口径对 | 计划吞吐按纯模型 × 0.8~0.9 折算过 |
| 台数有表可依 | 机器台数来自典型配置表 + 显存/算力复核，不靠拍脑袋 |
| 成本有价可填 | 单价来自采购合同/云计费单（不是文档里的数字） |
第七段 出问题怎么查
排查原则：先分"算错了（约束没查）"和"跑不对（参数不对）"两类，再往下查。
算错了（规划链） ── 显存看错 / Block 数取错 / 上限公式用错 / 台数漏了通算节点
跑不对（运行链） ── 服务拉不起来 / 并发上不去 / 吞吐不达标 / 加速没生效
7.1 先看现象 → 先查什么（排查顺序）
| 现象 | 大概是什么 | 先查什么 |
|---|---|---|
| 容量算出来跟实测差很多 | 显存分母错了 | npu-smi info 看有没有残留进程占显存（官方案例 topic_0000001589894865） |
| 并发上限忽大忽小 | 总 Block 数取的是历史值 | 是不是没清 /root/mindie/log 旧日志就 grep npuBlockNum；是不是取了最大值而非最小值 |
按公式算的 maxBatchSize 一设就拉不起来 |
显存被权重/其他占用吃掉 | 官方明说设太大会导致模型拉起失败，先降到 range 最小值再往上试；查 NPU_MEMORY_FRACTION、是否开了量化 |
| 请求变多后吞吐反而下降 | 到了显存/KV Block 边界 | 官方服务化调优工具篇专门点过这种"反直觉现象"（并发量增加时吞吐反而降低）；查 KV Block 是否用尽 |
| 显存够但并发上不去 | 序列长度太长 | 查 maxSeqLen / maxInputTokenLen / maxIterTimes（官方的"序列长度三件套"）；官方案例里就是把 maxSeqLen 降到 3K 才达到最优 |
| 多卡时个别卡先打满 | 负载/显存不均 | 看是不是按"平均值"而不是"最小值"算的上限；查并行策略（TP/DP）分布 |
| embedding 那一段特别慢 | 推理加速没开 | 查 ENABLE_BOOST 是不是设成了 "True"/"true"/"1"（设其他值静默不生效）；clip 模型注意首次图编译 1-2 分钟与 batch ≤4 的限制 |
| 一模一样的配置，两台机器性能差很多 | 环境不一致 | 查 CPU/内存/网络/驱动与 CANN 版本；官方寻优工具文档把"CPU、内存等硬件差异、网络环境不同"列为会导致建议值失效的原因 |
| 寻优跑完结果都是预测值 | 用了仿真模式没训练好 | 看结果 csv 的 real_evaluation=false 就是 gp 模型预测值（官方口径），不是实测 |
| 测吞吐时数字比预期低一截 | 把纯模型值当服务化值 | 记得按官方口径折算 0.8~0.9 倍；或用 AISBench 直接测服务化 |
7.2 按"规划 vs 运行"排的排查顺序
① 先确认"分母"对不对（显存与 Block 数）
├─ 有残留进程 → 清掉，重取显存
└─ Block 数取自旧日志/取了最大值 → 清日志、重拉服务、取最小值
② 再确认公式用对没有
├─ 用了"平均Block数量"当上限 → 只在上下文差异大时才允许，默认用"最大Block数量"
└─ 没按 0.8~0.9 折算服务化吞吐 → 补上
③ 再看"卡怎么分"
├─ 想起步 → 按官方 16 卡参考（TP=8/DP=2/MOE_TP=4/MOE_EP=4）试，再按 Host 与输入输出调
└─ 想省 KV Cache → 减小 Attention 的 TP、增加 DP（但注意权重会占更多显存）
④ 最后看"台数"
├─ 只算了算力节点 → 别忘了通算节点（跑 Coordinator/Controller，不参与推理）
└─ 节点规模超限 → 每套集群管理组件最多管 96 节点（A2），超了要划多套
⑤ 若始终对不上 → 用 optimizer 自动寻优兜底，并注意结果里的 real_evaluation 标记
⚠️ 一条判断法（本课自用，非官方表述）： "先怀疑分母，再怀疑公式，最后才怀疑硬件。" 容量算错，十次有八次是"显存/Block 数"这个分母取错了，而不是卡不行。
7.3 一条最容易漏的检查：集群管理组件的容量上限
官方对每套集群管理组件的管理规模有明确上限： A2：每套最大支持管理 96 节点（24P+6D）；A3：每套管理一个超节点（48 计算节点）。
这条为什么容易漏：你在算"要几台机器"时，很容易只数算力节点， 忘了"节点数到一定规模，要额外划出第二套集群管理组件实例" —— 而每多一套集群管理组件，就要多一台/一对通算节点。 官方口径是"192 节点需划分为两套独立的 24P+6D 实例，集群管理组件实例也需要对应创建两套"。
第八段 常见报错清单
检索口径：到官方案例库
https://www.hiascend.com/document/caselibrary按现象里的稳定特征词检索， 不要按"容量规划"这种泛词检索。下表的案例编号均为官方真实编号，另附查看量供参考。
| 报错 / 现象 | 官方案例编号 | 查看量 | 口径与做法 |
|---|---|---|---|
| 部署 service 服务，加载 LLaMA-65B 模型时出现 out of memory | topic_0000002250112009 |
727 | 官方服务化加载大模型时的显存不足；与"容量规划"直接相关 —— 先算清总 Block 数与权重占用再定 maxBatchSize |
npu-smi info 查看显存时发现 Python 进程残留 |
topic_0000001589894865 |
2117 | 残留进程占着力算显存；不清掉会把可用显存放小、并发算少 |
| 在 310P 上部署 qwen2.5-32b 推理报错内存不足（明确指出 NPU0 卡内存不足） | topic_0000002549203555 |
595 | 官方案例：单卡内存不足；多卡时"哪张卡先满"是容量估算的关键线索 |
| 设备 device 侧内存不足导致片上内存压测失败 | toolboxcase_0075 |
2208 | 官方工具案例；与"片上内存容量"直接相关 |
| 加载大模型时耗时过长（1300B 模型加载约 3 小时） | topic_0000002214923358 |
1337 | 官方案例；加载时间也是容量规划的一部分（它影响上线时长与停机窗口） |
模型调测时报 RuntimeError: malloc ... NPU error, error code is 500000 |
topic_0000001589894849 |
1425 | 官方案例；500000 属 AscendCL 的"无法识别的错误"（见 E1 的分段规则），软硬件内部异常，别死磕 |
| 部署 DeepSeek 服务化，性能不佳（实测与预期差异较大） | topic_0000002193154190 |
7969 | 官方服务化性能案例（浏览量最高的一条）；注意这是"服务化"口径，与单机性能分析不同 |
在 estimator 模式下执行 train_and_evaluate 提示显存不足 |
topic_0000002176651049 |
1005 | 官方案例；训练侧显存不足，与推理侧容量口径不同，注意区分 |
⚠️ 三条本课要明说的"没有答案"：
- 没有"某型号卡支持多少并发"的官方通用数字 —— 只能按你的场景（模型/精度/输入输出/序列长度/显存策略）实测 + 按官方公式估算。
- 没有官方价格 —— 硬件/云资源价格不在官方文档里；成本必须用实际采购或计费数据填。
- 没有"某模型该几台机器"的固定答案 —— 官方给的是按节点规模查的典型配置表。
第九段 小结与下一课
这一课要带走的三句话：
- 容量是"四问一条链"，顺序不能反 —— 一张卡能扛多少 → 卡怎么分 → 要几台机器 → 一年多少钱； 不先量出单卡上限，后面全是猜。
- 官方给了"算"的公式和"查"的表，但没给"价" ——
显存→并发有公式（
Floor[Total Block Num / 最大Block数量]），台数有典型配置表（P/D 实例规格）， 只有价格要按实际采购/计费填；"一张卡多少并发"也没有通用值。 - 所有数字都要带出处与口径 ——
cacheBlockSize默认 128、服务化吞吐折算 0.8~0.9 倍、16 卡参考 TP=8/DP=2/MOE_TP=4/MOE_EP=4 是官方给的口径；Free < 3%、未掩盖通信 ≤10%、aiv_mte2_ratio > 0.8来自其他场景， 用之前先看它是哪篇文档、哪个场景；通用阈值官方未给出，要自己建基线。
一次完整容量测算的动作顺序（串联本课）：
对口径（TTFT/TPOT SLO + 输入输出长度 + 并发 + 数据类型）
→ npu-smi info 看卡与显存（先清残留进程）
→ 纯模型测试量上限（prefill_batchsize / decode_batchsize）
→ grep npuBlockNum 取总 Block 数（清空旧日志，取最小值）
→ 算 maxBatchSize 上限（Floor[Total Block Num / 最大Block数量]）
→ advisor 给范围 / optimizer 自动搜参数
→ 定卡怎么分（TP/DP/EP，起步用官方参考配置）
→ 定几台机器（查典型配置表 + 别漏通算节点）
→ 算成本（实测吞吐 × 按实际计价）
→ 同口径复测 → 出证据
→ 官方没给的，明说"这是按现场条件取的数"
下一课预告（G9 企业安全）：
容量算完、机器定了，最后一环是"交出去之后怎么管住"：
权限与审计（官方只给到 user_id / role）、多租户隔离（AVI 虚拟化实例），
以及一条官方安全警告 —— Cache 数据库未做加密存储，涉及银行卡号、身份证号、护照号、口令等个人数据请勿存放。
G8 讲"用多少"，G9 讲"怎么用得安全"。
自测（能答上来才算学完）
- 容量规划的四问是什么？每一问的依据来源在哪？
- "能放多少并发"的官方公式是什么？为什么上限用"最大 Block 数量"而不是"平均"？
Total Block Num怎么取？为什么必须清空旧日志、为什么取最小值？- 服务化吞吐相对纯模型要打几折？这个系数出自哪篇文档？
- "卡怎么分"里的四条官方建议是什么？为什么"TP 小、DP 大"能省 KV Cache，代价是什么？
- A2 服务器每套集群管理组件最多管多少节点？通算节点为什么不能漏？
Free < 3%/未掩盖通信 ≤10%/aiv_mte2_ratio > 0.8各来自哪里、为什么不能当通用红线？- 成本公式里的单价从哪来？为什么本课不写价格？
附录 A · 本课引用的官方出处
| 内容 | 来源文档（版本） |
|---|---|
| AISBench 支持的功能特性表（推理模式/推理引擎/数据集/发送模式/精度测试/性能测试/token 推理/多模态/稳态/压力/多任务/可视化/断点续测/自定义数据集）、性能测试结果指标表（TTFT / ITL / TPOT / E2EL / PrefillTokenThroughput / OutputTokenThroughput / Concurrency / Request Throughput / Total Token Throughput 等） | 《性能/精度测试工具》（MindIE 3.1.0 · MindIE Motor CPP 开发指南 · 配套工具） |
整体思路（纯模型 vs 服务化两个角度）、纯模型初步测试步骤与 --case_pair / --batch_size 用法、按目标配置的四种场景表、服务化性能上限评估（单并发/大并发首 Token 时延/大并发吞吐）、KV Cache Block 算法与 cacheBlockSize 默认 128、Floor[Total Block Num/最大Block数量]、grep npuBlockNum 取总 Block 数、显存瓶颈算例（1747 / 1024-2048 / ≈145）、核心参数表（低时延/高吞吐）、并行策略调优（16 卡 TP=8/DP=2/MOE_TP=4/MOE_EP=4）、通信策略优化四条建议、ep_level、LCCL/HCCL、显存分析（W8A8）、NPU_MEMORY_FRACTION=0.96 + maxSeqLen 3K、设置总请求数=并发数×10 |
《MindIE 推理性能解决方案 · TopN 性能问题的解决方案》（MindStudio 26.1.0 · 实践案例） |
| 大规模专家并行方案典型配置：A2 表 1（8/16/32/64/96/N*96 节点的 P/D 规格）、每套集群管理组件最大 96 节点（24P+6D）、192 节点划两套、通算节点不承担主体推理计算；A3 表 3（2/4/8/16/32/48 节点规格、每套管一个超节点 48 节点）；前提条件（HCCS 款 / 64GB 片上内存 / 200G 光模块）；通算节点硬件要求（Controller 4 核 + Coordinator 16 核 = 20 核，内存最低 8GB，至少 2 个 25GE 网口）；验证方法（AISBench 对比 TTFT / 吞吐 / 端到端） | 《大规模专家并行方案典型配置》（MindIE 3.1.0 · MindIE Motor CPP 开发指南 · 附录） |
服务化调优工具定位（黑盒→白盒、框架调度透视 / 性能瓶颈定界 / 动态采集）、SERVICE_PROF_CONFIG_PATH、[msservice_profiler] 日志、配置字段（enable / prof_dir / acl_task_time 及其"推荐集中采集 3~5s"）、解析命令 python3 -m ms_service_profiler.parse --input-path=、依赖版本（python ≥ 3.10 / pandas ≥ 2.2 等） |
《服务化调优工具》（MindIE 3.1.0 · MindIE Motor CPP 开发指南 · 配套工具） |
服务化专家建议工具（advisor）简介、支持产品表、数据准备、安装（pip install scipy loguru pandas psutil）、命令（-in / -out / -i / -s / -t / -m / -tp）、输出建议格式、maxPrefillBatchSize 设为 maxBatchSize 一半、设太大会拉起失败、不能保证性能一定有提升需实测验证、安全警告勿用 root |
《服务化专家建议工具》（MindStudio 26.1.0 · msServiceProfiler） |
服务化自动寻优工具：PSO 算法、仿真/轻量化两模式、三大模块、支持产品表、安装（pip install -e .[real]/[speed]/[train]）、msserviceprofiler optimizer / train 参数表、config.toml 寻优参数（n_particles / iters / ttft_penalty / tpot_penalty / success_rate_penalty / ttft_slo / tpot_slo / service / sample_size）、输出结果文件字段表（含 real_evaluation / fitness）、4~8 小时完成、ASCEND_RT_VISIBLE_DEVICES、target_field 的 dtype 与 ternary_factories（dp = 总卡数 ÷ (tp × pp)）、PD 分离寻优约束、仿真模式版本配套（CANN 8.3.RC2 / MindIE 2.2.RC1；VLLM 侧 CANN 8.2.RC1 / VLLM 0.8.4） |
《服务化自动寻优工具》（CANN 9.2.0-beta.2 调试与分析工具 · 性能调优工具 · 服务化调优工具；同文另见 MindStudio 26.1.0） |
模型推理加速配置说明（TextEmbedding 支持 bert/roberta/xlm_roberta，数据类型 float16，默认关闭，需装算子模块）、clip 支持型号与首次图编译 1-2 分钟、ENABLE_BOOST 取值口径、ATB_LOG_* 日志变量、Atlas 300I Duo 上 clip batch ≤4、绑 CPU 核提升推理性能四步（npu-smi info 取 bus-id → lspci -vs → lscpu \| grep NUMA → numactl -C）、pip3 show mx_rag 判断安装方式 |
RAG SDK《模型推理加速》（MindSDK 26.1.0 · 知识增强 · 接口参考；在线版亦见 72rc1） |
案例 topic_0000002250112009、topic_0000001589894865、topic_0000002549203555、toolboxcase_0075、topic_0000002214923358、topic_0000001589894849、topic_0000002193154190、topic_0000002176651049 |
官网 案例库（https://www.hiascend.com/document/caselibrary/detail/<案例编号>） |
可复用的性能判据：Free < 3% / 未掩盖通信 ≤10%（来自 MindSpeed LLM 26.1.0《FSDP2 后端模型性能优化指南》，训练场景）；aiv_mte2_ratio > 0.8（Rec SDK 26.1.0《性能调优》）；Wait Time Ratio > 0.2 / 带宽使用率 > 0.8（CANN 9.2.0-beta.2《性能调优工具 · 扩展功能》） |
见各条括注；本课仅转述口径，均为场景级参考值 |
本课未写的东西（数据纪律：官方未给出，故不编）
- 任何价格数字（元/卡·时、元/台·年、元/千 token）—— 官方文档不含价格，只能按实际采购或云计费填。
- "某型号卡在通用场景下能支持多少并发"的通用值 —— 官方未给出；只能按场景实测 + 按官方公式估算。
- "某模型该用几台机器"的固定值 —— 官方给的是按节点规模查的典型配置表，不是按模型名给的固定值。
cacheBlockSize的取值 128 之外的推荐值 —— 官方只说"一般使用默认值 128"，未给其他场景的推荐值。MINDIE_LLM_PYTHON_LOG_LEVEL/MINDIE_LLM_PYTHON_LOG_TO_FILE的取值范围 —— 官方在本处只说了"使能…产生 INFO 级别日志"，未给取值；须按用户所用版本的《MindIE 用户指南》确认。NPU_MEMORY_FRACTION的取值范围与各取值影响 —— 官方只给了案例里的0.96，未给取值范围。NPU_MEMORY_FRACTION=0.96、maxSeqLen=3K、TP=8/DP=2/MOE_TP=4/MOE_EP=4的通用性 —— 均为官方案例/参考值，换模型或换 Host 端需重调。- 服务化调优/寻优工具在 Atlas 训练系列上的支持 —— 官方支持表标注为 "×"（不支持）；是否可绕过须现场确认。
- 训练侧容量规划（显存、并行度、集群规模）—— 属官方四大场景的"训练开发"，不在本课范围，计划归 H 层。
附录 B · 命令与参数逐条详解
B.1 容量测算的"取数三件套"
| 要取的数 | 命令 | 出处 |
|---|---|---|
| 显存与卡 | npu-smi info |
RAG SDK《模型推理加速》绑核章节第 1 步 |
| Total Block Num | 使能 MINDIE_LLM_PYTHON_LOG_LEVEL + MINDIE_LLM_PYTHON_LOG_TO_FILE 后 grep npuBlockNum |
MindStudio《MindIE 推理性能解决方案》 |
| 纯模型 batchsize 与耗时 | 设 --case_pair / --batch_size 跑纯模型测试，读 Total Time(s) 与 Non-first token time(ms) |
同上"纯模型初步测试" |
B.2 KV Cache Block 算法（照抄，仅作参照，数字要换成你的实测值）
最大Block数量 = Ceil(输入Token数/cacheBlockSize) + Ceil(最大输出Token数/cacheBlockSize)
平均Block数量 = Ceil(平均输入Token数/cacheBlockSize) + Ceil(平均输出Token数/cacheBlockSize)
maxBatchSize 上限 ∝ Floor[Total Block Num / 最大Block数量] （最佳性能口径）
上下文差异大时可提高到 Floor[Total Block Num / 平均Block数量] （官方"可适当提高"）
官方算例：可用 block = 1747，cacheBlockSize = 128，1024 输入 / 2048 输出
平均上下文 = 1536 → 平均可容纳 ≈ 1747 / [(1024+2048)/2/128] ≈ 145
B.3 AISBench 性能测试指标（照抄表 2 性能测试结果指标，取容量规划最常用的几条）
| 指标 | 官方含义 |
|---|---|
| TTFT | Time To First Token，首 token 时延（beam search 场景下无法测量） |
| TPOT | Time Per Output Token，decode token 间时延，公式 (E2EL - TTFT)/(OutputTokens - 1)（beam search 下无法测量） |
| E2EL | End To End Latency，请求端到端时延 |
| OutputTokenThroughput | 请求的吞吐，公式 OutputTokens / E2EL |
| Input Token Throughput | 本次测试的 input token 计算速度，公式 Total Input Tokens / Benchmark Duration |
| Output Token Throughput | 本次测试的 output token 计算速度，公式 Total generated tokens / Benchmark Duration |
| Total Token Throughput | 输入输出总 token 速度，公式 (Total Input Tokens + Total generated tokens) / Benchmark Duration |
| Concurrency | 平均并发连接数，公式 sum(E2EL)/Benchmark Duration |
| Request Throughput | 请求吞吐量，公式 Successful Requests / Total Requests |
| Failed / Successful Requests | 失败 / 成功总请求数 |
⭐ 算成本时要挑对指标： 按"多少人在线"收费 → 看 Concurrency；按"消耗多少 token"收费 → 看 Total Token Throughput。
B.4 AISBench 的能力覆盖（照抄表 1 工具特性，选型时对照）
| 特性 | AISBench | 与容量规划的关系 |
|---|---|---|
| 推理模式 | 支持 Client 模式下的流式推理和文本推理 | 流式与否影响 TTFT 口径 |
| 推理引擎 | 支持 MindIE、vLLM、SGLang、TGI 和 Triton | 换引擎要重测容量 |
| 数据集 | 支持 39 个开源数据集和 synthetic 随机数据集 | 随机数据集用来构造压力 |
| 发送模式 | 支持均匀分布和泊松分布 | 泊松更接近真实到达 |
| 并发/速率 | 支持压测（并发与请求速率可设） | 容量测算的直接输入 |
| 稳态测试 / 压力测试 | 均支持 | 找饱和点用 |
| 过程可视化 / 断点续测 | 均支持 | 长压测用 |
⚠️ 官方在 MindIE 文档里只给了这张"能力表"，具体命令行请见官方文档指向的 AISBench 工具仓库 —— 本课不转述仓库里的命令（那是站外文档，且会随版本变），需要时按官方链接取当版本文档。
B.5 两个调优工具的定位差异（别用混）
| 工具 | 输入 | 输出 | 适用 |
|---|---|---|---|
| advisor（专家建议） | instance 结果 或 输入输出长度 + config.json + 显存 |
maxBatchSize / maxPrefillBatchSize 建议值 |
已知场景、想快速拿到参数起点 |
| optimizer（自动寻优） | config.toml（寻优参数 + 测评工具参数 + 服务化参数范围） |
data_storage_*.csv（各组参数的 TTFT / TPOT / 吞吐 / 成功率） |
不知道最优在哪、愿意花 4~8 小时自动搜 |
对照记法：advisor 给"一个值"，optimizer 给"一堆组合 + 谁最好"。
B.6 寻优工具的 target_field：把"卡怎么分"交给工具推导（官方示例，照抄）
官方给的核心用法：让 dp 由总卡数自动推导，tp / pp 只枚举合法候选。
[[mindie.target_field]]
name = "tp"
config_position = "BackendConfig.ModelDeployConfig.ModelConfig.0.tp"
min = 0
max = 1
dtype = "enum"
dtype_param = [1, 2, 4, 8]
[[mindie.target_field]]
name = "dp"
config_position = "BackendConfig.ModelDeployConfig.ModelConfig.0.dp"
min = 0
max = 0
dtype = "ternary_factories"
dtype_param = {target_names = ["tp", "pp"], product = 16, dtype = "int"}
官方口径：
ternary_factories是product ÷ (field_a × field_b)；示例tp=4, pp=2 → dp = 16 ÷ (4 × 2) = 2。 派生字段由依赖关系自动推导，不参与粒子群搜索 —— 所以要把它的min/max都设为0。 ⚠️ 官方约束：product必须能被依赖字段乘积整除，否则会触发修复（修复失败则按 min/max 降级并输出 WARNING）。
B.7 服务化调优工具的采集配置（照抄，字段与推荐值均为官方口径）
{
"enable": 1,
"prof_dir": "${PATH}/prof_dir/",
"acl_task_time": 0
}
| 字段 | 官方说明 |
|---|---|
enable |
总开关：0 关闭 / 1 开启。即便其他开关开启，该开关不开启仍不会采集；只开它则只采服务化性能数据 |
prof_dir |
性能原始数据存放路径，默认 ${HOME}/.ms_server_profiler。⚠️ enable 为 1 时直接改 prof_dir 不生效 |
acl_task_time |
采集算子下发/执行耗时：0 关闭 / 1 开启。⚠️ 官方：开启会占用设备性能导致数据不准，建议仅在模型执行耗时异常时开启；推荐集中采集 3~5s |
⭐ 最后一条与容量测算相关：采集本身会拖慢服务。所以测容量时不要同时开算子级采集 —— 你会把"采集开销"当成"服务变慢"，从而把吞吐报小、把机器要多了。
B.8 落盘与安全提示（官方原文，跑这些工具前必读）
- advisor：官方安全警告 —— 请勿以 root 用户身份运行此工具，建议使用普通用户账户。
- optimizer 轻量化版依赖最少；
[speed]（仿真插件）与[train]（大数据量训练）为额外选项。 - 寻优参数均为必填：
n_particles（建议 15~30）/iters（建议 5~10）/ttft_penalty/tpot_penalty/success_rate_penalty/ttft_slo/tpot_slo/service—— 删除或省略会直接报错。 - 数据量控制：官方建议
sample_size取原数据集请求的 1/3；num_prompts控制运行数据集的条数。 - 结果里
real_evaluation=false的行是模型预测值，不是实测 —— 报容量时不要引用预测行。