22.6 跑得对但慢：跨设备性能定位

先用相同模型、负载和统计口径测端到端 TTFT、TPOT、吞吐与内存；再拆 Queue → Scheduler → Prefill → Decode → Sampling → Response。GPU 上用 Nsight Systems 看 CPU/GPU 时间线和空隙，用 Nsight Compute 看已确认的热点 Kernel；NPU 上用目标 CANN 版本的 Profiling 工具查看算子耗时、设备时间线与通信，不要把 CUDA 专属计数器名称直接套到 NPU。若阶段占比为 Attention 40%、MatMul 30%、Transpose 15%，先验证 Top-K 热点能否解释总耗时，再做一个改动并重测端到端结果。

设备时间线有大片空洞？ → CPU 准备、调度、同步、H2D、短 Kernel/小 Batch、通信等待
设备持续忙但单算子慢？ → dtype/layout/对齐、访存、算术强度、并行度、融合与编译结果
算子在 CPU 执行？       → 检查不支持算子或显式搬运导致的 CPU fallback
仅并发时慢？           → KV 容量、抢占、调度公平性、通信与尾延迟

CPU fallback 的典型路径是 NPU → CPU 算子 → NPU，功能与精度可能都对，但传输和同步造成明显延迟。用 op→device 映射、设备 trace 和拷贝事件证明它是否存在；不能仅凭“性能差”断言发生了 fallback。类似地，Transpose/Format Convert 可能不是计算热点，却在每层重复出现，累计成本很高。迁移后应优先消除不必要布局转换与同步，再评估算子融合和专用 Kernel。

指标、日志、Trace 各回答一个问题：Metrics（QPS、TTFT/TPOT 的 P50/P95/P99、token/s、设备/KV 利用率）说明当前症状；Logs（加载失败、OOM、抢占、算子异常）说明发生的事件；Trace 用同一 request_id 串起 HTTP、Scheduler、Prefill、Decode、Sampling、响应，定位实际耗时点。记录时间戳与请求、rank、设备关联，避免把不同请求的事件误拼成一条链。