AMD 显卡执行 CLIP 模型时 OpenCL 内核编译时间过长的缓存优化

AMD 显卡运行 CLIP 模型时，OpenCL 内核编译时间过长通常表现为程序启动延迟。OpenCL 内核在进程启动时会重新编译，缓存优化目标是让驱动复用已生成的二进制。先确认耗时来源，再决定用环境变量还是代码级缓存。

判断方向：如果每次启动编译时间都长，优先检查 AMD OpenCL 运行时是否启用了磁盘缓存，并确认缓存目录可写；若代码可修改，可通过手动保存和加载内核二进制来绕过重复编译。具体效果取决于驱动版本和模型封装方式，需要结合环境实测。

1. 先确认编译耗时发生在哪一步

适用场景：程序启动慢，但无法确定耗时来自内核编译还是初始化。
操作动作：用系统计时工具记录启动全程，并在代码中分别记录 OpenCL 上下文创建、clBuildProgram、首次内核执行的时间。
验证方式：对比首次运行和第二次运行的总耗时。如果第二次仍然慢，说明缓存未生效；如果第一次慢第二次快，说明缓存可能部分生效。
风险边界：如果程序每次创建不同的上下文或设备选择变化，缓存无法在两次运行间被命中。

2. 调整 AMD OpenCL 环境变量以启用磁盘缓存

AMD 驱动在部分版本中会通过环境变量指定内核缓存目录。可先检查当前环境是否有类似变量：

env | grep -iE 'ocl|opencl'

若为空，可在启动前设置一个常见缓存目录变量并创建目录：

export AMD_OPENCL_CACHE_DIR=/home/user/.amd_ocl_cache
mkdir -p /home/user/.amd_ocl_cache
chmod 700 /home/user/.amd_ocl_cache

适用场景：使用 AMD 官方驱动或 ROCm 运行时，且未在代码中主动缓存内核。
操作动作：设置上述变量后启动 CLIP 推理程序，连续运行两次。
验证方式：观察缓存目录是否生成新的二进制文件，以及第二次启动耗时是否缩短。
风险边界：不同 AMD 驱动版本的变量名和语义可能不同，上述变量名只是常见示例。若设置后目录为空，需要确认驱动是否支持或变量名是否正确，不能视为成功。

3. 在代码中手动保存和加载内核二进制

如果无法通过环境变量命中缓存，且 CLIP 代码使用标准 OpenCL API，可以在 clBuildProgram 成功后保存编译结果，后续运行直接加载。

// 第一次运行：构建后保存二进制
clGetProgramInfo(program, CL_PROGRAM_BINARY_SIZES, ...);
// 读出二进制数组并写入文件

// 后续运行：读取文件并用 clCreateProgramWithBinary 创建程序
// 然后直接用 clBuildProgram 加载

适用场景：代码可修改，且需要在同一 GPU 和驱动版本上长期运行。
操作动作：按上述骨架实现，将二进制文件放在固定目录，并在程序启动时检查。
验证方式：加载成功后 clBuildProgram 会很快返回，且程序不会出现重新编译日志。
风险边界：二进制与 GPU 型号、驱动版本绑定；更换显卡或升级驱动后必须重新生成，否则可能加载失败。

4. 如果使用的是现成推理工具

对于 whisper.cpp、stable-diffusion.cpp 这类开源工具，优先查看其命令行是否提供缓存或预编译相关选项。部分工具会在用户目录下创建缓存子目录，可通过帮助信息中的“cache”关键词判断。

适用场景：不打算修改代码，只通过启动参数调整。
操作动作：运行 your_tool `--help` 或 -h，查找与缓存、预编译相关的参数；将缓存目录设置为可写且剩余空间充足。
验证方式：使用相同参数连续运行两次，观察启动时间变化。
风险边界：如果工具内部每次重新创建 OpenCL 上下文或自带缓存逻辑，外部环境变量可能不生效。

5. 验证清单

确认首次运行和第二次运行的耗时差异，缓存生效时应明显缩短。
确认缓存目录已创建且包含新的内核二进制文件。
确认环境变量在程序启动前生效，可用 echo $AMD_OPENCL_CACHE_DIR 检查。
用 clGetProgramBuildInfo 获取构建状态，确认是否直接使用缓存二进制。
更换 GPU 或驱动版本后，重新生成一次缓存。