算力强，显存弱 —— 这样一颗芯片，该配什么样的活

零这一讲只回答一个问题

专题二立过一条线：算力 ÷ 显存带宽。它的物理含义是 「每从显存搬一个字节，这台机器本来能算多少次」 —— 一个纯粹由硬件规格决定的数，跟你跑什么模型无关。

那一讲量了两颗：B200 是 312，TPU v7 是 313。几乎一模一样。 当时的结论是「这一代旗舰的胃口都差不多」。

这一讲把同一把尺子多量两颗。其中一颗立刻破了那个「都一样」。

零点一　为什么这个数值得单独拿出来说

因为它是一条分界线，而分界线的用途只有一个：判某一段计算落在哪一侧。

把你要跑的那段计算也算出一个数 —— 算术强度，即 「这段计算每搬一个字节，实际算了多少次」。两个数一比：

• 强度 < 屋脊点 —— 算力在等数据。此时提升算力毫无意义， 要么加带宽，要么想办法让每个字节多干点活。
• 强度 > 屋脊点 —— 数据管够，算力是唯一瓶颈。 此时加带宽也毫无意义。

就这么两句话。这一讲剩下的全部内容，都是在给这两句话填具体的数。

一同一把尺子，量四颗芯片

一点一　这个数是怎么除出来的

分子是稠密 bf16 算力，分母是HBM 带宽。两个都取官方规格表上的数， 不取任何实测值 —— 这一点很重要，它保证了这条线在跑任何东西之前就能画出来。

一点二　我们凭什么信这条公式 —— 拿一个已知答案复现它

公式再简单，也得验。验的办法不是再推一遍，而是找一个别人已经算过的例子， 看我们的算法能不能把他的答案原样复现出来。

用的是 Google 那本公开的《How to Scale Your Model》。它在讲屋顶线的那一章里， 对 TPU v5p 给出了自己的屋脊点。我们把 v5p 的官方算力和带宽代进 「算力 ÷ 带宽」，得到的数跟它印出来的一致。

一点三　「算力强、显存弱」具体是多强、多弱

把 v6e 跟 H100 逐项相除，三个比值：

三项里两项是短板，只有一项打平。所以「v6e 合适」这句话， 从这里开始就注定只能是有条件的 —— 条件就是那两个短板得不参与。

⭐ 屋脊点 560 其实就是这三个比值的一句话总结： 分子基本没变，分母砍了一半，商自然涨到约两倍。
560 ÷ 295 ＝ 1.90 —— 这个 1.9 倍，跟带宽那栏的 49% 是同一件事的两种说法。

二把两颗芯片拆开

上一节的三个比值是结果。这一节看它们是从什么样的硅片布局里长出来的 ——两颗芯片在同样的三个问题上，做了完全相反的选择。

二点一　v6e：算力集中在两个大方阵里

三件事值得记住：

1. 算力集中。整颗芯片的稠密算力就装在两个 256×256 的方阵里。 要喂饱它，你的矩阵得足够大 —— 小矩阵会让方阵大半空转。
2. 片上有一整块暂存。128 MiB 的 VMEM，比 H100 一个 SM 的 共享内存大三个数量级。但它全部由编译器安排，没有硬件缓存兜底。
3. 通往片外的管子窄。1,638 GB/s，不到 H100 的一半 —— 这就是上一节那个 49% 的物理来源。

二点二　H100：同样的画法，三个相反的选择

下面这张图刻意用了跟 X-2 完全一样的画法和比例尺 ——尤其是那道「门」的宽度，两张图是按带宽等比画的，可以直接叠着看。

二点三　一颗装得下吗 —— 那三条「减配」其实是配套的

X-2 右栏有三条规格看着像减配：只有 4 个 ICI 口、二维环面、一个 Pod 只有 256 颗（对照 v7 是 6 口、三维、9,216 颗）。把模型的体积摆出来，这三条立刻说得通。

逻辑很直接：v7 那套三维环面、九千多颗的规格，是为「一个模型摊在几千颗上」 准备的。而扩散这一族根本不打那场仗。

不打，就不用付那个成本 —— 少两个 ICI 口、少一个维度、Pod 小一个数量级， 省下来的面积和功耗，全都还给了算力密度。这三条不是减配，是不同的题面。

二点四　X-2 右栏那两样只标了存在的：SparseCore 与二维环面

更正后的结论整个反过来：只要跨卡，SparseCore 就在干活。 扩散确实没有大 embedding 表，所以它走的不是第 ① 条路； 但只要模型要切开，all-gather 和 reduce-scatter 就一大堆 —— 第 ② 条路它走得很勤。

三那么扩散模型是哪一种活

要判它落在轴的哪一侧，得先算出它的算术强度。而算强度之前，得先回答一个更基础的问题：这类模型为什么是「计算密集」的？—— 拿 Wan2.1-T2V-14B 的官方配置当场算一遍，一步都不跳。

三点一　第一步：一段视频到底有多少个 token

输入是 1280×720、81 帧。它要过两道压缩才进 Transformer：

对照一下：一次 LLM 解码，一步只处理 1 个 token。差了将近五个数量级 —— 而这个差距，就是后面所有结论的源头。

三点二　第二步：这 FLOP 是怎么花掉的

一层 DiT、一个去噪步，四项开销。N ＝ 75,600，d ＝ 5,120，FFN 中间层 13,824。

七成花在那个 N² 项上。而 N² 意味着：token 数翻倍，这一项翻四倍。 上一小节那个 75,600 之所以是源头，原因就在这个平方上。

三点三　那一行 config 才是分水岭

上面那个「注意力占七成」完全取决于一个字段：

window_size = (-1, -1)   # ← 不开滑窗，全局注意力

如果它不是 −1，而是一个有限的窗口 w，注意力就从 4·N²·d 掉成 4·N·w·d —— 从平方变成线性。整套结论会怎么变：

三点四　凭什么信这一整套算式 —— 一个能证伪它的锚点

上面那张 FLOP 表里，任何一项的系数写错 2 倍，结果看起来都一样合理。 所以必须找一个独立的、有标准答案的量来验。

用参数量。同一份 config，把一层的权重数出来：

三点五　⚠️ 强度够高 ≠ 算力自动吃满

到这里可以算强度了：这段计算的算术强度约等于 N ＝ 75,600， 是 v6e 那条 560 的 135 倍。带宽完全不是瓶颈。

但落在算力侧，不等于算力就用满了。 ⛔ 这里的口径要说准（2026-09-09 审计改）：上面整段算的是 Wan2.1，而下面这个 MFU 出自我们 Wan2.2 的 profile 分析 （tpu/Wan2.2/docs/wan_tpu_optimization_guide.md）， 而且它是单个算子的数，不是整模型的：

两个数都说明同一件事 —— 六成多的算力没吃到。原因不在带宽，在别处：

三点六　结构上的三条：它把编译期想知道的全提前说了

三点一到三点五讲的是算术上的匹配。还有结构上的一半 —— 而这一半恰好对上 §二点二那个「CMEM ＝ 0」的设计前提。

四把活放回那两条线上

前面每算一种负载都要拆一遍 FLOP，太慢。其实有一条心算规则， 三十秒就能把任何一种负载放到轴上。

四点一　一条能心算的规则：强度 ≈ 同一份权重被多少个「位置」共用

推导只要三行。看一个权重矩阵 W，形状 in × out，bf16 存储：

• 要搬的字节：每个参数 2 字节 → 2 · in · out
• 能算的次数：batch 里有 B 个位置，每个位置每参数 2 次浮点 （一乘一加）→ 2 · B · in · out
• 相除：强度 ＝ B

⭐ 就这么干净：强度直接等于「有多少个位置在共用这一次权重搬运」。
它跟模型多大、多少层、什么架构全都无关 —— 那些量在分子分母上同时出现，约掉了。

四点二　于是四类负载各自落在哪

五流水线的形状：又胖又瘦

到 §四为止，这门课一直把「跑一次扩散」当成一件事。 实际部署时它是三件事：文本编码 → 五十步去噪 → VAE 解码。

而这三件事可以拆到三台机器上跑。这一节回答两个问题： 凭什么能拆（本节前半），拆完怎么摆（后半）。

五点一　管子里每一处有多粗

下面这张图把一次生成从头到尾的数据体积画在一根对数轴上。 全部以 Wan2.1-T2V-14B、1280×720、81 帧为准。

拿 Wan 2.2 图生视频当例子 —— 十个模型都是这套布局： github.com/yangwhale/gpu-tpu-pedia/tree/main/tpu/Wan2.2

tpu/Wan2.2/
├── generate_i2v_torchax.py                   ← ① 一体化：一个进程从头跑到尾
├── generate_diffusers_i2v_torchax_staged/    ← ② 三阶段
│   ├── stage1_encoder.py                        文本 ＋ 首帧 → embedding
│   ├── stage2_transformer.py                    五十步去噪 → latent
│   ├── stage3_vae_decoder.py                    latent → 成片
│   ├── utils.py                                 落盘 / 读盘的 helper 全在这
│   └── stage_outputs/                        ← ⭐ 切口就在这个目录里
│       ├── stage1_embeddings.safetensors     ← 段与段之间唯一交接的，就这三个文件
│       ├── stage2_latents.safetensors
│       ├── generation_config.json
│       └── output_video.mp4                     成片
├── docs/wan_tpu_optimization_guide.md        约 1,970 行迁移与优化指南
└── README.md

⚠️ 下面这张图上的字节数取自 Wan2.1 那一份同名目录 （tpu/Wan2.1/generate_diffusers_torchax_staged/stage_outputs/）—— 两个模型目录结构相同，数不同。

三个数值得单独读：

五点二　三段的胃口完全不一样 —— 这才是分开部署的真正理由

切得动只是可行性。真正的收益来自另一件事：这三段吃的根本不是同一种资源。

• ① 文本编码 —— 几乎不吃算力，就是把权重读一遍。占全程 1.3%。
• ② DiT 去噪 —— 吃算力。占全程 98.3%。§三算过的那 3.26 × 10¹⁷ FLOP 全在这儿。
• ③ VAE 解码 —— 吃显存峰值。把 480 万个数展开成 2.24 亿个，占全程 0.4%。

五点三　⛔ 一条顺口的结论，和一个当场推翻它的反例

看完上面那张图，最容易得出的结论是：「文本编码那么轻，放 CPU 就行。」 这条在 Wan2.1 上成立 —— 它用 T5，那一段只要 3 秒。

但 Flux.2 立刻推翻它。

五点四　一个节点摆几路：先看塞不塞得下，再看它够不够忙

一台 v6e-8 是 8 颗 × 32 GB ＝ 256 GB。同一台机器，两种截然不同的用法：

六这套说法，我们自己验过吗

前五节讲的全是应该怎样：屋脊点该怎么算、活该落在轴的哪一侧、 流水线该在哪儿切。这一节讲实际怎样。

—— 同一批道理，在十个真模型上跑了五个月之后，留下了什么。

六点一　五个月，十个模型

值得单独指出的是提交数的走向：

六点二　为什么又是 JAX 版、又是 torchax 版

这是客户最常问的一条。而它讲道理是讲不赢的 —— 「用 PyTorch 生态」和「用 JAX 原生」，两边都能说出一串听起来对的理由。

我们的答法是：三条都走完，把对照版原样留在仓库里。

六点三　这十个模型跟前面五节是什么关系

不是「附录里的项目清单」。每一个都在验证前面某一节的某一条断言：

收尾落点

—— 选芯片不是选「更强的那颗」，是先看你的活落在那根轴的哪一边。
落右边（扩散、prefill、大 batch）比的是算力，v6e 打平； 落左边（小 batch decode）比的是带宽，v6e 吃亏。
而这两件事，从两颗芯片的布局图上就能提前看出来 —— 不用等跑完。