基于客户不同的业务现状和需求可开通不同的资源组合，不同的算法组合也影响需要的资源。
对于DAU小于5万的客户
推荐系统可以用相对简单的方案，以便控制成本并提高业务的推荐效果：
召回模型：使用etrec、swing、分组热门等；不使用向量召回模型，可以节约在线的向量召回。
排序模型：使用相对简单的单目标多塔模型，推理速度快效果比较好，同时节约PAI-EAS的资源。
实时用户序列：通过Flink写入到Redis中。
物品和用户特征较少：可以使用Redis的存储方案，把物品特征、用户特征、实时行为序列全部存储在Redis中；如果用户特征太大，还可以尝试把用户特征存储在OTS（表格存储）中。
PAI-EAS：注意在业务高峰期配置定时扩容，同时配置自动扩缩容保证到业务低峰期收缩资源。
注意：上面5万DAU不是一个严格的分界线（下面的DAU数据同理），主要是基于提高推荐效果是否能带来足够的业务价值，以覆盖推荐系统的成本。下面的其他方案是在此基础上的变化。
对于DAU大于5万的客户
推荐系统可以使用更加复杂的方案以便帮助业务得到更好的推荐结果。
召回模型：可以增加向量召回。所有特征存储、向量查询都使用hologres产品。
排序模型：使用多目标排序模型。
用户特征存储：当用户特征快速变化的情况，可考虑Graphcompute
当物品的状态有快速变化的情况：可考虑使用BE。
对于DAU大于20万的客户
当业务对物品的实时特征对推荐效果非常敏感的时候，建议增加实时特征，物品实时特征的统计需要在flink中完成。
模型训练：建议使用增量训练以节约训练成本。
召回引擎：可考虑使用BE
用户特征存储：可以考虑Graphcompute
用户有社交关系：建议使用Graphcompute管理用户之间的关注、好友关系。有社交关系的推荐场景建议使用GraphSage等图算法。
对于DAU大于50万的客户
如果经常有活动影响推荐系统的效果，可以考虑增加在线学习的方案。
即通过Flink实时拼接样本，在线学习模型并且每天多次更新线上的模型。
可考虑预付费的MaxCompute资源。
PAI-EAS打分服务，可考虑预付费资源和弹性扩缩容资源相结合。
当新物品较多
建议使用物品冷启动算法，让新物品分发更加合理。
当需要调控指定物品、指定类目的流量
建议使用流量调控的算法，按照物品、物品集合、物品类目来调整曝光流量数量、曝光占比。