type
status
date
slug
summary
tags
category
icon
password
priority
本文不是从系统优化角度谈复杂的模型的部署和优化问题，而是从行业成本角度，看线上推理多复杂的模型是可以满足成本及ROI要求的。
做一个假设：
- 电商推荐行业，主要是更熟悉成本核算
- 部署标准的Transformer作为排序模型，参考OneTrans结构
- 参数规模对齐qwen2的系列模型，更直观看看能跑哪个尺寸
我们得思路是，先算清楚每一个请求可用的GPU TFlops，然后讲清楚怎么用Transformer做排序，对比qwen2各个尺寸的每请求的TFlops，就可以知道大概能跑什么样的模型了。
成本约束计算
思路：我们计算清楚每一个请求的预期GMV，然后GMV的一部分可以用于支付推荐系统的机器成本，其中一部分用于GPU在线推理，考虑推理的MFU和GPU使用成本，计算出能买多少次浮点运算。
核心公式：
变量解释：
- Expected GMV：预期GMV，可以用曝光数*CTR*CVR*avgPrice计算得到
- Tech Ratio：有多少比例能用于推荐机器成本。
- Online Ratio：推荐机器成本有多少用于线上。
- GPU Ratio：线上的服务中GPU占了多少成本。
- GPU Peak TFLops：GPU的峰值TFlops，取决于GPU型号。
- MFU：实际的GPU利用率。
这些参数我让大模型给出P20、P80和均值，用于估计平均和范围，它给出的结果如下：
参数 | 含义 | P20 (保守) | Mean (中位) | P80 (乐观) | 调整逻辑 |
Exposure | 有效曝光数 | 6 | 10 | 14 | 排除无效刷新和极深浏览 |
CTR | 点击率 | 1.5% | 2.5% | 3.5% | 排除冷启动和作弊流量 |
CVR | 转化率 | 1.0% | 2.0% | 3.0% | 排除误点和超高转化大促品 |
AvgPrice | 客单价 (CNY) | ¥40 | ¥80 | ¥120 | 聚焦腰部商品，剔除9.9包邮和奢品 |
Tech Ratio | 算力成本占比 | 0.15% | 0.25% | 0.35% | 行业成熟期通常在0.2%-0.3% |
参数 | 含义 | P20 (保守) | Mean (中位) | P80 (乐观) | 调整逻辑 |
Online Ratio | 在线算力占比 | 35% | 40% | 45% | 在线/离线比例相对稳定 |
GPU Ratio | 在线中GPU占比 | 30% | 50% | 70% | 随着深度模型应用，GPU占比提升 |
Price | 单卡时价 (CNY) | ¥4.5 | ¥3.0 | ¥2.0 | P20对应按需实例，P80对应Spot/自建 |
Buying Power | 1元能买的TFLOPS* | 160,000 | 240,000 | 430,000 | 基于L20 (239T) 和 A30 (165T) 换算 |
MFU | 推理有效利用率 | 25% | 35% | 45% | 推理场景MFU很难超过50% |
代入上面的公式，得到：
场景 | 场景描述 | 有效算力约束 (Effective TFLOPs) |
P20 (保守) | 普通用户/长尾品类/低转化时段 | 0.023 TFLOPs |
Mean (预期) | 日常标准流量 | 16.8 TFLOPs |
P80 (乐观) | 大促/高净值用户/核心场景 | 375.4 TFLOPs |
我们先拿到第一个数值，电商行业的平均水平可以跑每Request 16.8TFlops的模型。
模型TFlops计算
我们假设使用Transformer（LLM）用于推荐最复杂的排序模型，使用的方式参考OneTrans：
再简述下OneTrans如何使用Transformer处理精排推理的，它先在用户序列（长度L）上做一次计算，然后把序列的KV Cache准备好，然后再计算用户、物品和上下文特征，以token输入，N个候选，每个候选K个特征token。
它非常类似大模型的Prefill和Decoder，只不过Decoder了N次，每次K个token。它是非常标准的LLM计算模式，所以后面对比qwen不同尺寸模型，处理计算复杂度是容易且一致的。
计算模型的TFlops有两种方式：
- 精细计算：知道Transformer的参数，如隐藏层维度，FFN的intermediate维度，层数等信息，然后按prefill和Decoder各自计算，计算Attention和FFN部分，相加得到结果。
- 简便计算：只需要知道模型的Dense参数，每token前向的Flops为参数量*2，然后乘以L+N*K（用户长的tokens+N个候选的NK个tokens）。这种计算方式忽略了Attention里的QK^T计算，这是由于在不考虑长上下文情况下，LLM的主要算力是QKV和FFN计算贡献的，模型的size越大Attention的算力越不需要计算。
我们优先采用第二种，先做粗略估计。如果不计算Attention部分，模型就已经不满足成本约束了，那它铁定做线上推理。
我们假设一个例子：
- 用户序列1K
- 候选300个物品
- 每个物品16个特征token
然后只需要用Dense的参数*2*(1000+300*16)就能得到模型单Request的TFlops需求。
直接列出计算结果：
模型尺寸 (Size) | 总参数量 (Total) | Dense 参数 (推理核心) | 隐藏层 (Hidden) | FFN 维度 (Inter.) | 层数 (Layers) | 预估TFlops | ㅤ |
0.5B | 0.49 B | 0.36 B | 896 | 4,864 | 24 | 4.18 T | ㅤ |
1.5B | 1.54 B | 1.31 B | 1,536 | 8,960 | 28 | 15.3 T | ㅤ |
3B | 3.09 B | 2.77 B | 2,048 | 11,008 | 36 | 32.1 T | ㅤ |
7B | 7.61 B | 6.53 B | 3,584 | 18,944 | 28 | 75.7 T | ㅤ |
14B | 14.7 B | 13.1 B | 5,120 | 13,824 | 48 | 152 T | ㅤ |
32B | 32.5 B | 31.0 B | 5,120 | 27,648 | 64 | 360 T | ㅤ |
72B | 72.7 B | 70.2 B (约) | 8,192 | 29,568 | 80 | 814 T | ㅤ |
可以初步看出，0.5B和1.5B尺寸的Transformer用户排序模型，在相对标准的成本约束（16.8 TFLOPs）下是不存在成本瓶颈的。当然，继续拉高用户序列从1k到8k，扩充候选打分条数，增加特征tokens数，都使得1.5B尺寸模型不满足成本约束，需要在效率、资源分配和利用以及模型结构优化做一些调整。
大家可能会担心简易计算忽略了Attention的Flops，会不会偏差较大，我们使用qwen2-0.5B做一次精算。Dense参数本身会发生一次矩阵乘加 2 Flops运算外，Attention忽略了QK^T和Softmax @ V的计算。
prefill 阶段： 和 的flops都是 ，考虑层数一共是，具体计算是约0.086TFlops。
decoder 阶段：生成的decoder_len个tokens每个都和前面产生计算，所有token看到的KV总数是从prefill_len累计到prefill_len+decoder_len-1， ，flops是 ，代入是0.416 TFlops。
精确估计是4.652TFlops，和快速估算的4.18T差异不大，且参数量越大差异的百分比越小。
一些思考
对于判别式模型，由于存在候选数量和特征tokens的乘积，这里占据了300*16=4800个token，且无法优化，用户序列1k可以通过KV Cache预先计算、金字塔逐层缩减优化。这部分候选的target aware特征输入即是优势，又是模型规模的限制。
而生成式可以在线直接产生一条推理结果，我们把之前的计算改成候选数为1，作为生成式TFlops。
模型尺寸 (Size) | 总参数量 (Total) | Dense 参数 (推理核心) | 判别式TFlops | 生成式TFlops |
0.5B | 0.49 B | 0.36 B | 4.18 T | 0.72T |
1.5B | 1.54 B | 1.31 B | 15.3 T | 2.62T |
3B | 3.09 B | 2.77 B | 32.1 T | 5.54T |
7B | 7.61 B | 6.53 B | 75.7 T | 13.06T |
14B | 14.7 B | 13.1 B | 152 T | 26.2T |
32B | 32.5 B | 31.0 B | 360 T | 62T |
72B | 72.7 B | 70.2 B (约) | 814 T | 140.4T |
从这个表格来看，如果我们能支付地起1.5B的判别式模型，那么生成式就可以上一个7B的模型。同样成本下，是小模型+target aware交叉有优势，还是大模型生成式有优势，正式未来需要探索的。