先建立端到端基线
分别记录预处理、模型执行、后处理和传输时间，明确延迟与吞吐的统计口径，避免只看框架内的一次 forward。
自我图书馆SELF LIBRARY持续整理中SHELF 02 / INFERENCE
推理加速
围绕计算图、算子、内存和运行时建立端到端性能判断，而不是只优化一个孤立 kernel。
01 / WHY THIS EXISTS
先明确它要解决的
工程瓶颈。
推理加速之所以成为独立工程主题，是因为训练时可接受的冗余在部署阶段会被放大：每一次格式转换、内存拷贝、动态 shape 分支和未融合算子都会累计为用户可见的等待时间。优秀的运行时通过图优化、内核选择与资源调度，把模型表达转化为目标设备上的有效执行计划。
02 / STUDY MAP
从原理到验证，
每个环节都应可观察。
以下条目不是固定配方，而是建立工程判断的最小框架。不同模型、硬件与负载需要在各自的边界内重新测量。
用 profiler 定位瓶颈
识别主要耗时算子、kernel launch、显存分配与同步点。优化应从可观测的热点开始，而不是默认某一种编译器或算子一定更快。
让图优化可落地
导出时固定输入输出语义，尽量保留能被运行时识别的标准算子。融合、常量折叠和 layout 选择需要结合目标后端验证。
处理 shape 与显存
动态 shape、KV cache、workspace 和 batch 策略会改变 engine 选择与峰值显存。需要使用真实请求分布而非理想单样本测试。
03 / IMPLEMENTATION PATH
01
→定义基线
固定模型、输入 shape、精度、batch 与测量方法
02
→定位热点
用 profiler 拆分端到端耗时与资源占用
03
→构建优化图
图编译、融合、精度选择与内核调优
04
目标设备验证
在真实并发、缓存和长尾输入下复测
交付判断
只有当功能正确性、质量指标、端到端延迟、峰值资源占用和故障回退方式都在目标设备上验证过，部署才算完成。单个 benchmark 或单张输出不能代表线上行为。
READING LIST / ORIGINAL SOURCES
页面用于整理工程概念和验证路径。API、硬件支持与性能特性会随版本改变，应以对应版本的官方文档和实际 profiling 结果为准。