LINGBOT · NSIGHT SYSTEMS · 实测证据
时间花在哪里？
计算与通信是否重叠？
先分析已经录到的 kernel 和时间线，再验证 Attention 后端。
正在读取实测数据…
实验进度与报告
这些是 profiler 下的时间线分析，不是干净计时。跨 GPU、跨流累计耗时不能直接相加为端到端时延。时间线本身不提供硬件瓶颈证据；已完成的隔离 FA3 计数器试采单独列出，不外推到全模型。
1 · 哪些 kernel 最耗时、调用最多？
按完整 kernel 名称聚合，显示前 20 项。相同名称可能包含不同 shape；完整调用账本和全部排名 CSV 保存在原始分析目录。
| Kernel 完整名称 | 次数 | 累计 ms | 均值 μs | 耗时比例示意 |
|---|
2 · 拷贝、通信和等待用了多久？
数据拷贝
| 方向 | 调用次数 | 累计 GPU ms | 涉及数据 MiB |
|---|
拷贝时间按选中区间裁剪。字节数统计与区间相交的完整拷贝调用，边界处不按时间比例猜测字节数。
CUDA 同步与主机等待 API
这里是多个线程的累计 API 时间，会互相重叠，也可能包含后台线程等待。它不等于请求被阻塞的墙钟时间；不把所有等待相加成关键路径。
| API | 类型 | 次数 | 累计线程 ms |
|---|
3 · 计算与通信有没有重叠？
按物理 GPU 归并所有相关进程、对时间区间取并集，再计算交集。NCCL 名称识别为通信；“其他 kernel”也包含转换等辅助算子。
| 物理 GPU | 区间 ms | 其他 kernel ms | NCCL ms | 两者重叠 ms | kernel 与 memcpy 重叠 ms | 无所录活动 ms |
|---|
时间线重叠只说明活动区间相交，不证明两者同时占用 SM，也不证明重叠调度带来了加速。“无所录活动”不是已归因的 CPU 等待；未录到的活动、依赖、调度等仍需逐段排查。
4 · Attention 后端：速度与误差
相同已捕获 Q/K/V，强制选择 FA2、FA3 或 SDPA 各后端。数值校验同时对照原始输出和抽样 FP64 数学参考。先声明误差门槛，再计时；gather、通信和端到端收益需另测。
| 配置 / 输入 / 阶段 | 后端 | 结果 | P50 ms（逐次重复） | 参考最大绝对误差 | FP64 最大绝对误差 |
|---|