推荐模型应该做到多大？
一年前，我手推荐系统中，计算最密集的一个精排模型在A10上训练和serving MFU都只有个位数，而LLM在训练时可以在H100上把MFU做到40-50%（不考虑fp8）。#card
这个差距主要在于精排模型里特殊的设计算子太多了，做了非常多算力有限假设下“精细”设计，
这些“精细”设计都是短期有效，长期会变成负担的工作，所以推荐模型的MFU越来越低。
知道了需要把MFU做高，但是应该把模型做到多大，还是没有明确的概念。
推荐是一个商业化非常成熟的场景，模型可以做多大其实是一笔能算出来账，我们先只考虑边际成本也就是在线服务的开销：#card
1 以内容社区为例，国内大部分内容平台的CPM（千次曝光广告价格）在20元 rmb左右，毛利率在60～80%。比较有意思的是，LLM里面以DS为参考，DS的输入输出1M token高峰期收费也是20元，毛利也是80%附近，神奇的巧合 。
2 如果做一个和LLM同架构的模型，计算总量为 2ND，D(data) 是输入输出token总量（不做特殊处理输入输出对计算量影响一样，只是做高MFU难度不一样，所以收费不同），N(ParamNumber)是模型的尺寸。
3 如果我们采用L20作为线上的计算设备，单卡的计算上界是119.5TFLOPS，月度单卡OpEx成本大概是2500元（这是比较敏感的数字，各家不一样，大概是这个水位吧），单卡成本每天接近84元。
如果我们做一个10B大小的模型，输入+输出token控制在1000。#card
- 而单块L20卡，一天的成本约等于84元，这种情况下仅考虑计算成本，内容流量业务的毛利就能做到84%附近。
这个推导逻辑不算很严密，不过足够我指引自己工作了。这意味着在现有的硬件环境和业务收入形态下，我应该去做一个10B尺寸的模型，单样本Token量在1K左右。#card
当然了，模型的尺寸和token量是可以做trade off的。
不用纠结1k token够不够长，用户行为序列超过1k的部分其实是可以压缩的不用每一层都输入原始序列长度，未来硬件更好了，可能也不需要压缩。
算完这些账，我们不用担心做出一个大的推荐模型之后它无法上线。10B 是一个之前推荐模型想都不敢想的尺寸。
有了明确的模型尺寸目标之后，剩下的问题就是#card
如何让高并发低延时的推荐系统能使用更多的算力，
以及怎么让模型算力投入变大之后效果对应显著增长。