哎哟小情郎你莫愁 tp8为你挽红袖～

上一篇在讲 ep 的时候写了个 tp8 解君愁，今天咱就来脑补下 tp8 都能解君哪些愁以及大 ep 的收益。至于为啥是脑测，因为没钱买不起万卡集群，只能用我小学二年级的知识口算一下了。咱算完都没和老板说过，怕给他压力，他直接瘫坐在工位上，就像看到原子弹爆炸💥。下面开始发动暴走魔法阵！

首先 tp8 有啥好处。第一大的好处当然就是省头发，国产卡 tp8 也都能顺利地拉起来。然后是intra-node 就算没有自己的互联协议，用的 pcie 也还是比 inter-node 快，通信时间占比要低得多。还有就是上篇文章讲的，ep 有 scale-out 的流量，一旦要到 low-latency 的场景，跟别的流量一冲突就头大，以及并发要是不够会有负载不均，多打一 incast。那么 tp8 有啥问题呢，排第一的问题就是显存容量没法扩容。现在 coding 场景上下文越来越长，如果买不到第一梯队的卡，或者只能弄到国产卡的，tp8 放完模型权重就木有啥显存了，直接 oom 警告！然后就是速度上也无法扩容，tps 上限就被锁在那了，尤其某些国产卡在 decode 场景下，tp8 完了那个速度在 coding 场景完全不够用呢，然后某些国产卡写没写 deepep 也不知道。那么如果 tp16，tp32 呢？这篇文章不打算深入去讲 tp 和 ep 的区别，就大概讲下最大的区别。集合通信是对称通信，所以通信量随 rank 数增加而增加。但 ep 通信的通信量不随 rank 数的增加而增加。然后小 ep 可能还不如 tp，因为有unbalance 的问题。

不同的卡不同的负载下区别比较大，所以我也就不分业务场景去说了，拉个虚空场景把思路先捋捋，首先看下各部分时间占比。

首先是并发不错的情况下，ideal 是硬件完全计算打满无通信的时间。可以看到 rank8 的时候 ep 因为 unbalance 的问题经常比tp8 慢那么点。到了 rank16 两者基本就差不多了。到了 rank32 开始 ep 就超过了 tp。随着 rank 越来越大，tp 的通信问题会越来越明显。所以除非是非要用某个卡，这个卡没写 ep 通信库，又有个 decode 的 sla 一定要达成，不然我觉得最多就到 tp32 了，再往上亏的实在太多。

但是现实是现在 coding 场景下，tp8 压根塞不下那么多并发，mfu 非常低。在 mfu 比较低的情况下，就变成下面这个图。

黄色的就是 mfu 很低的 tp8，rank64 那边是 8 tp8 的吞吐量。这么一看 ep64 岂不是非常屌，吞吐量是 8 * tp8 的好几倍！这还解君愁呢，直接给我愁死睡不着觉了，这卖 token 上不了 ep 的国产卡不是亏死！但是话又说回来了，这个只是 decode 下的情况，我们再把 prefill 拉进来看看。

这里我把单卡的吞吐率拉出来对比一下，可以看到prefill 还是比较好打满一点的。尤其现在coding 场景大多数 token 都是烧在 prefill 上。所以再看看下面这个图，画的是不同的 pd token 比率下，整个集群上要的卡的数量对比。

可以看到，虽然 ep 在 decode 上能省下非常多的卡，但是放到整个 coding 场景下省的卡也没光看性能提升那么多了。prefill 占比越大的模型，大 ep 能省的卡就越少。当然要反馈到最终营收上的话，不同的模型定价，cache 命中，有没有图片等等，还有非常多场景上的区别。所以这里也就不写了，我觉得写这么多也差不多了。

所以对于中破厂来说，要上大 ep 吗？我觉得也未必。首先大 ep 是个绑死的方案，根据流量负载去动态调整的能力很差。当然最近到处流量都爆了，最近要是能上那都是打满，所以这几年感觉问题还不大。然后就是大 ep 要的资源实在太多了，我就随手算了下，算出来建个旗舰卡的 IDC 机房就要个 12 亿的样子。而且这么大的机房，软硬件上调度管理能不能做好，也是个未知数。然后就是 ep 会有 scale-out 的计算流量，这部分跟其他流量的冲突，是否能解决好也是个未知数。上篇文章也讲过这个问题，那其实不用大 ep 的情况下，就只剩业务网和存储网两张网。而且机房小了，从一头到另一头的end-to-end 延迟也更小，调度上会更舒服。大厂要做三网那是大厂的事，咱中破厂就不一定要去掺和了。而且上面那个也是按理想情况算出来的，真要生产环境各种问题一上，可能也就是个 10% 出头的提升。去大厂那 10% 端到端的提升就是好多钱，好多年终奖。咱这说不定就是一堆的夜班和掉不完的头发，完了可能还是吃个大饼，影响我的摸鱼大计。

所以我觉得有钱还是能去做的，反正搞不定拿 tp8 兜底也没差那么多嘿嘿嘿～