--tensor-parallel-size是什么：张量并行：把模型的注意力头与中间维切分到 N 张卡，每步做 allreduce。
深入：TP 组内的通信量与 head 数成正比；GLM-5.2 A5 双脚本均用 TP8（单机 8 卡跑满）。
调优：多机场景优先 DP/EP，TP 一般不超过单机卡数；TP>1 会激活 o_proj TP 切换等分支（GLM 案已证 TP1 下这些分支不触发）。
源码（vLLM 上游）：vllm/config.py（SchedulerConfig / CacheConfig）· vllm-ascend 侧适配见 platform.py
--data-parallel-size / -local / -address / -rpc-port是什么：数据并行：每个 DP rank 持有完整模型副本、独立调度器，请求按负载分发。
深入：GLM-5.1-198k 双机部署为 DP8（local 4）×TP4 的 internal-DP 形态；DP 之间通过 rpc-port 组网。DP 下存在 dummy run/idle 同步问题（3e30d711 等）。
调优：增大 DP 提升吞吐但放大尾延迟不均衡；注意 DP rank 间负载不均会放大 prefix 差异。
源码（vLLM 上游）：vllm/config.py（SchedulerConfig / CacheConfig）· vllm-ascend 侧适配见 platform.py
--enable-expert-parallel是什么：MoE 专家并行：专家按 EP 维分布在卡间，token 经 all-to-all 路由到所在专家。
深入：W8A8 大 MoE 部署标配（GLM/DSV/Kimi 案 yaml 均开）。EP 与 MC2/AllToAll 通信路径强相关。
调优：EP 下若见精度问题，先排查通信路径（mc2_comm_alg/flashcomm）而非量化本身。
源码（vLLM 上游）：vllm/config.py（SchedulerConfig / CacheConfig）· vllm-ascend 侧适配见 platform.py
--max-model-len是什么：KV cache 能容纳的最大上下文长度。
深入：直接决定 KV block 总数与显存占用（133120/202752 这类值即按 128 对齐）。设小了长请求直接拒绝。
调优：不要为省显存设到刚好等于最长请求——预留给 MTP draft 与 hash 对齐余量（hybrid 命中取 LCM 对齐）。
源码（vLLM 上游）：vllm/config.py（SchedulerConfig / CacheConfig）· vllm-ascend 侧适配见 platform.py
--max-num-seqs是什么：同时在跑的请求上限（decode batch 的请求维度）。
深入：16/20/32 这类取值直接影响 decode 每步 token 数：32 请求 × MTP4 ≈ 128 token/步（prefix 案中走 batch_matmul_transpose 分支的临界条件）。"Part A"已标注其与算子分支的关联。
调优：调大提升吞吐但推高每步 token 数，可能跨过 BMM_TRANS_MAX_SUPPORTED_TOKENS=1024 这类算子分支阈值。
源码（vLLM 上游）：vllm/config.py（SchedulerConfig / CacheConfig）· vllm-ascend 侧适配见 platform.py
--max-num-batched-tokens是什么：单个调度步最多处理的 token 预算（chunked prefill 粒度）。
深入：16384 是 GLM 部署常用值。spec decode 下会被压到 4096 级别（max_num_scheduled_tokens 由 spec 设置，日志有提示）。
调优：与 spec decode 组合时留意日志里的 max_num_scheduled_tokens 提示行。
源码（vLLM 上游）：vllm/config.py（SchedulerConfig / CacheConfig）· vllm-ascend 侧适配见 platform.py
--gpu-memory-utilization是什么：模型权重+KV 之外允许使用的显存占比。
深入：0.90/0.92/0.95 常见。PD 分离两端可以不同。
调优：留余量给 activations；调大直接增加 KV blocks（对长上下文命中率无影响）。
源码（vLLM 上游）：vllm/config.py（SchedulerConfig / CacheConfig）· vllm-ascend 侧适配见 platform.py
--enable-prefix-caching是什么：前缀缓存：相同前缀的请求复用已算好的 KV blocks。
深入：开关打开≠命中：混合注意力模型走 HybridKVCacheCoordinator，命中是跨 KV 组取最小值。GLM-5.2 案：开关打印正常但实际命中 0%（详见 prefix RCA 报告）。
调优：验证口径用每请求 cached_tokens，不要只看启动日志。
源码（vLLM 上游）：vllm/config.py（SchedulerConfig / CacheConfig）· vllm-ascend 侧适配见 platform.py
--enforce-eager是什么：禁用目标模型的 ACL 图捕获，全部 eager 执行。
深入：只影响目标模型；draft 是否走图由 speculative-config 的 enforce_eager 决定（参数 1/2 都给 draft 设了 enforce_eager=true）。参数 2 顶层也加了 enforce-eager → 全 eager。
调优：排障第一开关：任何疑似图/编译问题先加它复测。
源码（vLLM 上游）：vllm/config.py（SchedulerConfig / CacheConfig）· vllm-ascend 侧适配见 platform.py
--async-scheduling是什么：异步调度：调度与执行重叠。
深入：与投机解码组合时 cascade attention 会被自动禁用（198k 日志可见 Disabling cascade attention 警告）。
调优：按需开启；排障时先关。
源码（vLLM 上游）：vllm/config.py（SchedulerConfig / CacheConfig）· vllm-ascend 侧适配见 platform.py
--enable-chunked-prefill是什么：长 prompt 分块 prefill，避免单次巨长计算。
深入：与 max-num-batched-tokens 配合。
调优：长上下文部署建议开。
源码（vLLM 上游）：vllm/config.py（SchedulerConfig / CacheConfig）· vllm-ascend 侧适配见 platform.py
--quantization ascend是什么：启用 vllm-ascend 量化方案（w8a8_dynamic/w4a8/w4a16/mxfp4 等按 checkpoint 自动选择）。
深入：quant method 决定走哪套 quantization/methods 子目录；MoE 重构后文件已按子目录组织（73acadef6）。
调优：checkpoint 与 quant 参数必须匹配。
源码（vLLM 上游）：vllm/config.py（SchedulerConfig / CacheConfig）· vllm-ascend 侧适配见 platform.py
--tool-call-parser glm47 / --reasoning-parser glm45是什么：GLM 系输出的工具调用与思考段解析。
深入：aisbench 的 extract_non_reasoning_content 依赖 parser 产出的结构；若精度/格式异常，先核对该参数与 checkpoint 模板匹配。
调优：GLM 部署必配。
源码（vLLM 上游）：vllm/config.py（SchedulerConfig / CacheConfig）· vllm-ascend 侧适配见 platform.py
--seed是什么：采样随机种子。
深入：精度评估固定 1024 保证两次运行可比（GLM 案两版脚本一致）。
调优：对比实验必须同 seed。
源码（vLLM 上游）：vllm/config.py（SchedulerConfig / CacheConfig）· vllm-ascend 侧适配见 platform.py
method —— proposer 选择（15 种）是什么：选择投机解码的起草器。vllm-ascend/spec_decode/ 下有 15 个 proposer 实现： mtp.py（deepseek_mtp，DeepSeek/GlmMoeDsa 专用）、step3p5.py（mtp，Step3.5 式通用 MTP，每个 MTP 层独立 KV 组）、 eagle_proposer.py（eagle3）、dflash/dflash2_proposer.py、dspark_proposer.py、medusa_proposer.py、ngram_proposer.py（NPU 版）、suffix_proposer.py、 draft_proposer.py、extract_hidden_states_proposer.py。
深入：method 决定 KV cache 组结构——deepseek_mtp 是单 draft KV 组（在协调器支持形态内）； mtp 是每 MTP 层独立组（可能超出 AscendHybridKVCacheCoordinator 声明支持的“两类型组合”）。 这是 GLM-5.2 A5 prefix 案的头号嫌疑（详见 pr_learn/prefix_cache_rca_report.html）。
调优：方法一旦变更，务必重测精度 + prefix 命中 + 接受率三项。
源码：vllm_ascend/spec_decode/（15 个 proposer）· GitHub
num_speculative_tokens —— draft token 数是什么：每步起草的 token 数。GLM-5.1-198k 用 3、DSV32-MTP2 用 2、A5 GLM-5.2 两份脚本都用 5。
深入：越大潜在加速越多，但 draft 变差时浪费越多；同时 max_num_scheduled_tokens 会被压（日志有提示行）。
调优：3 是常用值；AIME 精度评估下接受率可在日志/spec_decode_metrics 中观察。
源码：deepseek_mtp.py · GitHub
enforce_eager（speculative-config 内）—— draft 强制 eager是什么：draft 模型禁用 ACL 图。注意它只管 draft：目标模型是否走图由顶层 enforce-eager / compilation-config 决定。
深入：target eager + draft eager 是最保守组合（GLM-5.1-198k 即此形态）；target FULL_DECODE_ONLY + draft eager 也常见。 若 draft 走图且行为异常，先改这里做二分。
调优：保持 true；draft 图化的收益通常被捕获开销抵消。
源码：llm_base_proposer.py（_create_draft_vllm_config 的 runner_type 处理见 748acedf）
cudagraph_mode —— ACL 图模式选择是什么：目标模型的图捕获策略。FULL_DECODE_ONLY（decode 整图 + prefill eager，最常用）、 FULL_AND_PIECEWISE（全图/分段混合）、false（无图）。
深入：图 replay 时注意力块表经 update_graph_params 刷新——窗口内该路径有大变更（827a11d3 PA workspace 复用、 4c9cdea56 input_batch 修复、b0a0aa59c breakable capture）。GLM-5.2 prefix 案的候选 C：图 replay 下新命中的前缀块 若未进入块表 → 等效于没命中。draft 侧另有 aclgraph 捕获（日志 Replaying aclgraph）。
调优：排障第一步通常是加顶层 --enforce-eager 二分；确认性能后可尝试 FULL_DECODE_ONLY 提吞吐。
源码：attention_v1.py（update_graph_params）· compilation/acl_graph.py
enable_sparse_sfa_c8是什么：SFA 主注意力的 KV cache 打包量化：把 k_nope+k_pe 合并为单个 int8（A3）或 float8_e4m3fn（FP8 平台）张量 packed_kv，配合 scale（fp16/fp32）供 NPU 算子 npu_kv_quant_sparse_flash_attention 做稀疏反量化注意力计算。KV cache 槽位从 [k_nope, k_pe, indexer_k, scale] 变为 [packed_kv, indexer_k, scale, unused]。
深入：生效前提：model_uses_sfa_sparse()（hf config 含 index_topk 且无 compress_ratios，即 GLM-5.1/5.2、DeepSeek-V3.2+ 等 DSA 模型）；同时伴随 q/k Hadamard 变换（L625-629 类级共享静态张量）。【GLM 案实证】0.26.0 得 100 分、0.27.1 起 0 分×3——精度回归的头号定位开关。
调优：精度异常时第一个对照的开关；与 sparse_kv_offload_config 互斥（ascend_config L845-849 校验会 raise）。
源码：ascend_config.py L446 · 本地源码 · GitHub#L446
enable_sparse_li_c8是什么：Lightning Indexer 的索引缓存量化（与 sfa_c8 是两个独立开关，sfa_v1.py L507 注释明示）。
深入：只对拥有 indexer cache 的层生效；128k_90_50 的 93.33 基线即在 li_c8=true + sfa_c8=false 环境测得。
调优：GLM 案 09-04 dual-nodes 同配置得 93.33 分 → li_c8 单独开不影响精度，说明劣化在 SFA 主路径而非 indexer。
源码：ascend_config.py L447 · 本地源码 · GitHub#L447
enable_dsa_cp是什么：DSA 跨机上下文并行（DeepSeek V3.2+ / GLM 系 DSA 模型的序列维跨机分片）。
深入：联动：ascend_config L602 自动启用 FlashComm；L650-654 要求 has_indexer + use_sequence_parallel_moe，否则静默关闭；L638-641 警告 PCP 就绪后将废弃 enable_dsa_cp（迁移提示按 TP/PCP 分三档）。GLM 案已实证：dcp_size=1 时 DCP 融合路径（5c59cfba9）不激活。
调优：多机稀疏长上下文部署标配；排查时确认 use_sequence_parallel_moe 是否为 true。
源码：ascend_config.py L394 · 本地源码 · GitHub#L394
enable_fused_mc2是什么：融合 MC2 通信：把 MoE 的 dispatch/combine 通信融合进计算。int 枚举（0=关）。
深入：互斥：MiniMax M3 不支持 =1（L688）；mc2_comm_alg='hierarchy' 也与它互斥（L838-842）。GLM-5.1/DSV32 两案 yaml 均为 0 → e24e09ca（MC2 profiling 跳编译）对这些部署无效。
调优：MC2 专用部署才考虑非零值。
源码：ascend_config.py L415 · 本地源码 · GitHub#L415
mc2_comm_alg是什么：MC2 通信算法选择（32d9a3138 新增）。可选值含 fullmesh_v2 / hierarchy。
深入：校验：fullmesh_v2 需硬件 MC2_FULLMESH_V2_COMM 支持（L816-819）；hierarchy 需硬件支持 + 专家总数 ≤512 + 与 fused_mc2 互斥（L821-842）。
调优：hierarchy 模式大 EP 部署时收益明显。
源码：ascend_config.py L407 · 本地源码 · GitHub#L407
enable_prefill_mc2是什么：Prefill 阶段启用 MC2 通信。
深入：默认关。
调优：PD/大 EP 按部署指导。
源码：ascend_config.py L389 · 本地源码 · GitHub#L389
enable_mc2_hierarchy_comm是什么：MC2 层级通信（L453 注释 deprecated，被 mc2_comm_alg='hierarchy' 替代）。
深入：旧开关。
调优：保持 False，新配置用 mc2_comm_alg。
源码：ascend_config.py L392 · 本地源码 · GitHub#L392
enable_balance_scheduling是什么：均衡调度：把长短请求混合编排减少 decode 气泡。
深入：GLM/DSV 大 MoE 部署普遍开（GLM-5.1 案 yaml scheduler_config 显式开）。互斥：profiling_chunk_config 启用时与其冲突会 raise（L581-585）。env 版 VLLM_ASCEND_BALANCE_SCHEDULING 已删除（9bef60ad5）。
调优：在线混合负载可开；精度排障时先关（prefix 案候选 D）。
源码：ascend_config.py L1203 · 本地源码 · GitHub#L1203
recompute_scheduler_enable是什么：重计算调度器：KV 放不下时对请求做重计算而非拒绝。
深入：07482eb32 main2main 0.27.1 引入；PD 分离场景尤为重要。
调优：超长上下文/资源紧张场景按需。
源码：ascend_config.py L1204 · 本地源码 · GitHub#L1204
dyntra_lb_config是什么：动态 DP 内负载均衡（ffa55704 DyntraLB）。
深入：字段：enabled/mode(dynamic)/start_step 250/end_step -1/bubble_threshold 5.0/long_req_block_threshold 700/dynamic_max_step 256/enable_diagnostics。
调优：多 DP 负载不均场景（GLM-5.1-198k 案的 DP4 17/9/2/3 请求分布就是不均的实例）。
源码：ascend_config.py L1156 · 本地源码 · GitHub#L1156
batch_job_sched_config是什么：批量离线作业调度。
深入：enabled/max_jobs 20/reserve_margin_blocks 2/reserve_max_blocks 8/low_available_tokens_threshold 4096/short_decode_token_threshold 32。
调优：离线批量场景。
源码：ascend_config.py L1098 · 本地源码 · GitHub#L1098
short_request_first_config是什么：短请求优先。
深入：enabled/threshold 256/long_max_wait_ms 0.0。
调优：在线混合负载 P99 优化。
源码：ascend_config.py L1139 · 本地源码 · GitHub#L1139
eplb_config是什么：dynamic_eplb(False)/expert_map_path(None)/expert_heat_collection_interval 600/algorithm_execution_interval 50/expert_map_record_path(None)/num_redundant_experts 0/eplb_policy_type 2/eplb_heat_collection_stage(all)/load_collection_phase(all)。
深入：EPLB 全家桶：静态映射、热度采集、均衡策略。0703581 集成上游 EPLB + d37529f 异步 EPLB 为窗口内同族提交。
调优：MoE 负载严重不均时再开。
源码：ascend_config.py L116 · 本地源码 · GitHub#L116
enable_force_eplb是什么：强制启用 EPLB。
深入：互斥：与 dynamic_eplb 同时开启会 raise（L552-557）。
调优：默认关。
源码：ascend_config.py L395 · 本地源码 · GitHub#L395
weight_nz_mode是什么：权重 NZ 分形布局模式。
深入：0c4d84e7 从 env 收编进 pydantic。
调优：随 checkpoint 量化方案走。
源码：ascend_config.py L425 · 本地源码 · GitHub#L425
enable_kv_nz是什么：KV cache NZ 分形布局。
深入：与 weight NZ 同族（128ecf890/035b8d407 同窗口 SFA 变更）。
调优：保持默认。
源码：ascend_config.py L391 · 本地源码 · GitHub#L391
enable_transpose_kv_cache_by_block是什么：按块转置 KV cache。
深入：251334c8 从 env 收编进 pydantic。
调优：默认 True。
源码：ascend_config.py L424 · 本地源码 · GitHub#L424
combine_quant_mode是什么：组合量化模式（0/2/3/4）。
深入：2627f62 移除 mxfp shim 后内联。
调优：随量化方案自动。
源码：ascend_config.py L407 · 本地源码 · GitHub#L407
mega_moe_max_tokens是什么：MegaMoE 单批 token 上限。
深入：L406 注释：同一值传给 dispatch_ffn_combine 的 max_output_size 和 CANN MegaMoe buffer 的 max_recv_token_num。实际每 rank 接收 token 数超过此值时 token 可能被截断导致精度劣化（注释原文'causing precision degradation'）——这是一个有明确精度风险的容量参数。设太大会线性增加 workspace 显存。
调优：MoE 并行规模变化时需要重新评估此值。
源码：ascend_config.py L406 · 本地源码 · GitHub#L406
enable_mlapo是什么：MLAPO：MLA prefill 优化路径。
深入：draft 模型强制关闭（748acedf runner_type 检测）；target 才生效。GLM-5.1/DSV 部署 yaml 均为 true；895ca078b 移除其 env 版。
调优：精度异常排障时可对照关。
源码：ascend_config.py L416 · 本地源码 · GitHub#L416
mlapo_keep_prefill_weights是什么：prefill 权重常驻 NPU。
深入：L422 注释（ca5603874 新增）：设 True 避免 PD 分离 kv_consumer D 节点上权重释放后本地 prefill 路径（recompute/fallback/preempt）崩溃（issue #11882）。用 NPU 显存换稳定性。
调优：PD 分离 D 节点部署时建议开。
源码：ascend_config.py L422 · 本地源码 · GitHub#L422
enable_reduce_sample是什么：reduce 采样优化（实验特性）。
深入：ascend_config L789 打 experimental 警告；L793-802 两道互斥校验：①与 finegrained_tp_config.lmhead_tensor_parallel_size 互斥（raise）②PD 分离 kv_producer 场景不支持（raise）。运行时投机采样可能回退 non-reduce 路径（994765d7 sort-based top-k 为该路径的性能改造）。GLM-5.2 A5 参数 1 脚本里开着——prefix 案候选 B。
调优：排障先去；与 lmhead TP 不可同开。
源码：ascend_config.py L393 · 本地源码 · GitHub#L393
rejection_sampler_config是什么：enable_block_verify(False)/enable_entropy_verify(False)/posterior_threshold 0.95/posterior_alpha 0.4。
深入：rejection sampler 的验证配置（27a94764 概率化 rejection sampling、637417db synthetic RS on MRV2）。fallback 路径下 sort-based top-k（994765d7）会接管采样排序。
调优：RL/一致性场景。
源码：ascend_config.py L175 · 本地源码 · GitHub#L175
draft_window_size是什么：draft 窗口大小。
深入：676e91b 支持 thinking budget 的投机解码相关。
调优：默认 None。
源码：ascend_config.py L396 · 本地源码 · GitHub#L396
finegrained_tp_config是什么：oproj TP / lmhead TP / embedding TP / mlp TP / olora TP，各自独立设置（默认 0 跟随主 TP）。
深入：lmhead TP 与 enable_reduce_sample 互斥（ascend_config 校验 raise，L793-797）。
调优：分层 TP/PP 组合场景。
源码：ascend_config.py L934 · 本地源码 · GitHub#L934
rl_config是什么：enabled/sleep_mode_extra_cleanup/enable_training_consistency/enable_batch_invariant。
深入：RL rollout 与训练-推理一致性（2c72a26 统一 RL 配置）。
调优：RL 场景。
源码：ascend_config.py L199 · 本地源码 · GitHub#L199
sparse_kv_offload_config是什么：enabled/topk_buffer_size 4096/dram_size_per_dp_GB 128/keep_device_kv_cache False/topk。
深入：稀疏 KV 卸载（528276dc9 引入、6b52b112 限内存、d6d93c9 恢复同步写）。互斥：与 enable_sparse_sfa_c8 同时启用会 raise（L845-849）——SFA 主 cache 不支持卸载。
调优：显存受限的长上下文。
源码：ascend_config.py L441 · 本地源码 · GitHub#L441
kvpp_config是什么：KV 并行 prefill 配置。
深入：ascend_config L89-90 校验：KVPP 仅支持 speculative method='mtp'（Step3.5 MTP）。
调优：KVPP 专用部署。
xlite_graph_config是什么：xlite 后端图模式（enabled/full_mode）。
深入：xlite 为轻量适配层（3757271 支持 GLM/DSV3 系）。
调优：xlite 部署。
源码：ascend_config.py L1030 · 本地源码 · GitHub#L1030
ascend_log_path / dump_config_path / msmonitor_use_daemon是什么：日志路径 / 配置 dump（L918-940：支持直接传 dict 自动物化到 .vllm_ascend/msprobe/）/ msMonitor 守护。
深入：排障与监控。dump_config 与 dump_config_path 互斥。
调优：按需。
源码：ascend_config.py L407 · 本地源码 · GitHub#L407
enable_cpu_binding是什么：CPU 绑核。
深入：A5 参数 2 脚本显式开启。
调优：默认即可。
源码：ascend_config.py L387 · 本地源码 · GitHub#L387
pd_tp_ratio / pd_head_ratio / num_head_replica是什么：PD 分离 TP 比 / head 比 / head 副本数。
深入：PD 分离部署拓扑参数。
调优：按 PD 拓扑。
源码：ascend_config.py L448 · 本地源码 · GitHub#L448
pa_shape_list / mix_placement是什么：PA 形状预注册 / 混合放置（互斥：mix_placement 与 shared_expert_dp 或 multistream_overlap 冲突会 raise，L878-881）。
深入：按需。
调优：
源码：ascend_config.py L407 · 本地源码 · GitHub#L407
VLLM_ASCEND_ENABLE_FLASHCOMM1状态：已废弃（92616f3a6 移除 FlashComm v1）。设置只产生 deprecate 警告——GLM/DSV 老 yaml 里的常见残留，可直接删除。
VLLM_ASCEND_BALANCE_SCHEDULING状态：已迁移至 scheduler_config.enable_balance_scheduling（9bef60ad5），env 版删除。
VLLM_ASCEND_ROPE_UB_SIZE_KB / VLLM_ASCEND_ENABLE_BATCH_MEMCPY内核微调：RoPE UB 空间、批量拷贝开关。默认即可。
VLLM_EXECUTE_MODEL_TIMEOUT_SECONDSexecute_model RPC 超时。需 ≥ HCCL 算子时限（1836 秒，platform.py 会校验并提示）。198k 部署脚本设 18000/30000。
HCCL_BUFFSIZE / HCCL_OP_EXPANSION_MODE=AIV / HCCL_INTRA_PCIE_ENABLE / HCCL_INTRA_ROCE_ENABLE / HCCL_ALGO / HCCL_IF_IP / GLOO_SOCKET_IFNAME / TP_SOCKET_IFNAME / HCCL_SOCKET_IFNAMEHCCL 通信族调优：buffer 大小（1024/300）、算子展开模式、卡间 PCIe/ROCE 选择、算法与网卡指定。PD/多机部署按拓扑配置。
PYTORCH_NPU_ALLOC_CONF=expandable_segments / TASK_QUEUE_ENABLE / ASCEND_LAUNCH_BLOCKING / ASCEND_RT_VISIBLE_DEVICES内存分配器（可扩展段）/ 算子下发队列 / 同步调试（置 1 拖性能仅排障）/ 可见 NPU 序列。
链 1 · C++ torch 扩展：csrc/torch_binding.cpp 等（C++17，CMake + gcc/clang）在 pip 构建时编译为
vllm_ascend_C，注册 torch.ops._C_ascend.*（host 侧算子封装，如 batch_matmul_transpose 调用入口）。
链 2 · AscendC 算子：csrc/**/op_kernel/*.cpp（device kernel）经
csrc/build_aclnn.sh 用 毕昇编译器 bisheng（随 CANN 包发布，build.sh 里 which bisheng 检查，
报错原文"bisheng compilation tool not found, Please check whether the cann package"）编译成 ACLNN 算子，依赖 catlass（子模块）。
只有源码构建算子时才需要；pip 官方 wheel 已预编译。头号嫌疑算子 batch_matmul_transpose 的实现即在此链
（csrc/batch_matmul_transpose/op_kernel + op_host/tiling），08-19 的 11921514a 曾整体移除该算子。
链 3 · Triton kernel：triton-ascend==3.2.2（requirements 固定）运行时 JIT 编译
vllm_ascend/ops/triton/*.py（dsa_cp、lightning_indexer、slot_mapping、eplb、compute_slot_mapping 等）。
| 链 | 编译器 | 触发 | 产物 | 与本案关系 |
|---|---|---|---|---|
| 1 | gcc/clang（CMake） | pip 构建 | vllm_ascend_C | — |
| 2 | bisheng（CANN 内） | csrc/build_aclnn.sh | ACLNN 算子二进制 | ★头号嫌疑算子的宿主链 |
| 3 | triton-ascend JIT | 运行时 | Triton kernel | 算子融合开关（fuse_norm_quant 等）作用层 |