Advanced

System Design

Relayed Match Reflection

使用延迟反射机制确保分布式网络的两端一致性。当前版本中，挑战者管理可插拔模型的大致流程如图 1 所示：

Fig1. - Flow chart of ModelHub AssetsPuller.

1. 初始化阶段，检查 objects.yaml，读取并注册登记在文件中且已存在在指定目录下的 ONNX 模型文件，并将整个 objects.yaml 内容转码、编排并缓存到内存中。

2. 运行时，通过 match_net() 方法调用预加载的模型进行分类任务。整个匹配的过程遵循 objects.yaml 中的编排信息，即， puller 会自动调用已从“本地”加载的模型或下载已编排但未保存在“本地”的模型文件，这些临时下载的模型文件会被自动读回内存。换句话说，不在 objects.yaml 中的挑战视为无法处理的新挑战，该挑战将被自然跳过。

3. 两端一致性问题，对于一开始就存在本地且被自然加载的模型，其持有一枚 node_id。node_id 标注了该模型的本地运行时版本，而在 _assets 本地缓存中纪录着远程仓库“最新的”模型的 node_id。模型注册时，若 local_node_id != remote_node_id 则视为该模型（同名文件）已更新，此时 puller 会自动下载对应的新版本模型，替换掉本地的旧模型文件。

4. AssetsPuller, 全自动插拔管理器，其在“本地”缓存一个 _assets 资源对象。_assets 纪录 modelhub 的摘要信息，包括模型下载链接，版本号，更新时间等。挑战者初始化时会自动创建这个资源对象，如果它已存在，这个重复的网络请求将被省略。_assets 通常有 2h 的有效时间。puller 在有效期内不会发起重复的网络请求，资源过期后它将自动维护 _assets 的健康状态。此外，你可以通过 python main.py install --upgrade 命令手动刷新缓存。