joblib跨机器、会话及运行方式的缓存可靠性是否符合预期？

核心结论 #

你观察到的这些情况完全符合joblib的设计预期，Memory.cache默认并非为跨机器、跨运行环境的持久化缓存设计，它的缓存键生成逻辑高度依赖运行环境的细节。

缓存键的生成逻辑 #

joblib生成缓存哈希时，默认会纳入以下关键信息：

• 函数的定义位置（文件路径）：Jupyter Notebook的代码存储在临时目录的ipykernel文件中，每次会话的临时路径、内核ID都不同；Python脚本有固定文件路径；管道输入的代码没有实际文件路径，会触发碰撞警告。
• 函数的源代码内容：这也是三种运行方式下内部存在相同哈希目录fb65b1dace3932d1e66549411e3310b6的原因——函数本身的代码完全一致。
• 运行环境的系统特征（如机器硬件、操作系统信息）：跨机器时这些信息存在差异，会导致缓存键不一致。

不同运行方式的具体表现 #

• Jupyter Notebook：每次启动会话都会生成新的临时内核文件，缓存目录会包含该临时路径，因此新会话会重新创建缓存目录，但由于函数代码哈希一致，内部的结果哈希目录保持相同。
• Python脚本：脚本有固定的文件路径，缓存目录会关联该路径，只要脚本路径不变，同一机器的不同会话可以复用缓存。
• 管道输入Python解释器：代码没有对应的物理文件，joblib无法生成稳定的路径标识，会触发JobLibCollisionWarning，且无法复用缓存，每次都会重新执行函数。

实现跨环境可靠缓存的方案 #

如果需要在不同机器、不同运行方式下复用缓存，可以通过以下方式调整：

• 在装饰器中使用ignore=['__file__', '__module__']参数，让joblib忽略文件路径和模块信息：

  from joblib import Memory
  
  memory = Memory('./cache', verbose=0)
  
  @memory.cache(ignore=['__file__', '__module__'])
  def job(x):
      print(f'Running with {x}')
      return x**2
  

• 确保函数源代码完全一致，且输入参数在不同环境下可稳定序列化（避免使用无法序列化的对象作为参数）。
• 跨机器场景下，可手动规范缓存哈希的生成规则，或结合分布式缓存工具扩展joblib的缓存能力（joblib原生不支持分布式缓存）。

内容的提问来源于stack exchange，提问作者John Kitchin