mirror of
https://github.com/openmlsys/openmlsys-zh.git
synced 2026-04-13 10:09:43 +08:00
Recsys extension (#208)
* Add detailed introduction to system architecture and NVIDIA Merlin. * Fix bugs Co-authored-by: Dalong <39682259+eedalong@users.noreply.github.com>
This commit is contained in:
@@ -2,7 +2,8 @@
|
||||
|
||||
在线服务系统的两个主要诉求:
|
||||
|
||||
- 大模型的高效存储。为了提升训练和推理的性能,通常推荐模型全部存储在内存中,然而纯内存存储对于内存的需求极高。正如前文分析的,单个模型就要占据至少100GB的内存,而一个在线推荐系统中需要同时运行多个模型负责不同的服务。如果考虑到除了在线服务模型,算法研究人员还需要上线测试不同的模型结构或者训练策略,系统中通常会同时存在上百个超大模型。因此在线推荐系统亟需既能拓展存储容量,又不会影响训练和推理性能的存储解决方案。
|
||||
- 大模型的高效存储。
|
||||
为了提升训练和推理的性能,通常推荐模型全部存储在内存中,然而纯内存存储对于内存的需求极高。推荐模型的输入中包含大量无法直接进行矩阵运算的类别数据,而由于每种类别数据包含的每种情况都需要一个单独的嵌入项来表示,而稠密深度神经网络的参数可以共享,在大规模推荐模型中,嵌入表占据了绝大部分内存 :cite:`MLSYS2021_979d472a,MLSYS2020_f7e6c855`。举例说明,假设一个推荐模型需要处理1亿条短视频内容,而每条短视频对应的嵌入项为一个64维的32位浮点数向量,那么仅该内容嵌入表就需要就需要占据大约24GB内存。如果考虑到用户标识符等其他嵌入表,那么单个模型可以轻易占据近100GB内存。而在工业界生产环境中,TB级的推荐模型 :cite:`MLSYS2020_f7e6c855`也是非常常见的。此外,在线推荐系统中需要同时运行多个模型负责不同的服务,甚至同一个服务也会上线多个模型以供算法开发人员验证不同的模型结构或者训练策略,因此系统中通常会同时存在上百个超大模型。综上所述,在线推荐系统亟需既能拓展存储容量,又不会影响训练和推理性能的存储解决方案。
|
||||
|
||||
- 大模型的快速更新。
|
||||
在线服务系统所面对的环境是复杂多变的,因此其中的机器学习模型必须不断更新以应对新的数据分布。以一个短视频推荐系统为例,其面对的变化主要来自三点。首先,每时每刻都有大量的新视频上传,这些新视频的特征分布和模型训练时所见到的数据不同;其次,对于不断加入的新用户,模型难以直接给出最优的推荐结果;最后,全部用户和内容之间的交互在不断改变,表现为热点视频在持续变化。因此,为了应对以上变化,在线服务中不可能奢望仅仅训练一次模型就能够一劳永逸地解决问题。目前业界主流的做法是利用新产生的数据不断地增量式更新所部属的模型。在学术界和工业界大量的研究和实践 :cite:`10.1145/2020408.2020444,10.1145/2648584.2648589,10.1145/3267809.3267817,9355295`中都发现模型更新可以有效缓解概念漂移带来的危害,而且更新的频率越高,模型的性能越好。
|
||||
|
||||
Reference in New Issue
Block a user