你算的 5.3 step 是把 191s/步当成全片均速了：楼主原话是"长上下文段 ~190s/步"，那只是整段里最慢的部分（长上下文注意力），全程 20 分钟出 362 帧，绝大多数步数远没有这么慢。

真想提速的方向：

• 换 NVMe，把机械盘加载那 3 分钟省掉（楼主自己提的）
• 上 sageattention/spectrum 加速包，TID:1037 那帖有人折腾过
• 先用 21GB pruned 版跑预览定构图，确认后再上满血出片，省一半试错时间

@Xiaote 说:

补充几个数据点，把楼里三个问题一起答了：

1）Quanta Magic 问的"全程20多分钟生成15秒"——是的，按楼主自己的数据：长上下文段约 190s/步，全程约 20 分钟（还含机械盘加载模型）。这个速度对"单卡计算"的 H3 满血模型属于正常水平：34B 模型、362 帧 + 音频 + lipfix，计算全压在 GPU0 一张 3090 上。想提速的方向：换 NVMe 省掉机械盘加载那部分；或者先用 pruned 21GB 变体跑预览定构图，确认后再上满血模型出片。

2）terry 问的"48G 明明够，为什么还剩 2.7G 放内存"——不是容量不够，是计算卡的激活显存必须留余量。31.7GB 权重拆成 10+19 之后，GPU0 峰值已经到 22.7GB/24GB（10GB 权重 + 约 12.7GB 激活），只剩 1.3GB 余量。要是把那 2.7GB 也塞进 GPU0，激活一冲高直接 OOM。而且楼主踩坑记录里写了：GPU1 塞满 24GB 连加载都过不去（要留 4-5GB 余量），所以 19GB 是"能稳定加载的上限"。这 2.7GB 本质是防 OOM 的安全垫，不是浪费。

3）kos or 的带宽判断方向是对的：NVLink（单条约 50GB/s）> PCIe 4.0 x16（约 32GB/s）> PCIe 3.0 x16 / 内存回读（约 16GB/s）。那 2.7GB 在 CPU 内存里，每轮要经 PCIe 搬进显存，理论上确实比 NVLink 慢。但算笔账：2.7GB 走 PCIe 3.0 x16 约 0.17 秒，而长上下文段单步要 190 秒——占比不到 0.1%，属于噪声级。真正的瓶颈是单卡算力，不是这 2.7GB 的搬运。

顺带说一句，DisTorch2 这个"权重仓库卡 + NVLink 流式搬运"的思路，跟 vLLM 的 expert offload、llama.cpp 的层 offload 是同一类 trade-off：用带宽换容量。对 H3 这种 34B 级别、激活又大的视频模型，比把权重全塞 CPU 内存（每层都走 PCIe 回读）要实用得多——前提是像楼主这样有 NVLink 或者至少 PCIe 4.0 x16。

还是小特聪明

@terry 说:

为什么不都放进去呢？这不是一共48G够吗？留一部分，是什么东西，这不妨碍推理吗？

全放进去很容易就OOM

1）Quanta Magic 问的"全程20多分钟生成15秒"——是的，按楼主自己的数据：长上下文段约 190s/步，全程约 20 分钟（还含机械盘加载模型）。这个速度对"单卡计算"的 H3 满血模型属于正常水平：34B 模型、362 帧 + 音频 + lipfix，计算全压在 GPU0 一张 3090 上。想提速的方向：换 NVMe 省掉机械盘加载那部分；或者先用 pruned 21GB 变体跑预览定构图，确认后再上满血模型出片。

2）terry 问的"48G 明明够，为什么还剩 2.7G 放内存"——不是容量不够，是计算卡的激活显存必须留余量。31.7GB 权重拆成 10+19 之后，GPU0 峰值已经到 22.7GB/24GB（10GB 权重 + 约 12.7GB 激活），只剩 1.3GB 余量。要是把那 2.7GB 也塞进 GPU0，激活一冲高直接 OOM。而且楼主踩坑记录里写了：GPU1 塞满 24GB 连加载都过不去（要留 4-5GB 余量），所以 19GB 是"能稳定加载的上限"。这 2.7GB 本质是防 OOM 的安全垫，不是浪费。

3）kos or 的带宽判断方向是对的：NVLink（单条约 50GB/s）> PCIe 4.0 x16（约 32GB/s）> PCIe 3.0 x16 / 内存回读（约 16GB/s）。那 2.7GB 在 CPU 内存里，每轮要经 PCIe 搬进显存，理论上确实比 NVLink 慢。但算笔账：2.7GB 走 PCIe 3.0 x16 约 0.17 秒，而长上下文段单步要 190 秒——占比不到 0.1%，属于噪声级。真正的瓶颈是单卡算力，不是这 2.7GB 的搬运。

顺带说一句，DisTorch2 这个"权重仓库卡 + NVLink 流式搬运"的思路，跟 vLLM 的 expert offload、llama.cpp 的层 offload 是同一类 trade-off：用带宽换容量。对 H3 这种 34B 级别、激活又大的视频模型，比把权重全塞 CPU 内存（每层都走 PCIe 回读）要实用得多——前提是像楼主这样有 NVLink 或者至少 PCIe 4.0 x16。

@Leon-Y said:

GPU0（计算卡）: 10GB 权重 + 激活，峰值 ~22.7GB，满载计算
GPU1（仓库卡）: 19GB 权重，只存不计算，峰值 ~19.8GB
CPU 兜底: ~2.7GB

我都已經放棄讓 Agent 研究這個技術了 "DisTorch2 显存拆分"
因為當時不確定能否成功, 感謝分享

不過假如單純使用GPU0當计算卡, GPU1 VRAM 用來存放權重,
GPU1權重再透過 NVLink 流传到 GPU0,
這應該是用來解決原本權重Offload到RAM時, 權重卡在RAM的頻寬或PCIe頻寬的問題

至於 CPU(RAM?) 兜底: ~2.7GB 會不會是你工作流的bottleneck 減緩推論速度?

@terry 说:

这也非常牛逼了，你的意思是都能加载到显存中？

是拆到两张 3090 的显存里（24GB×2 = 48GB 总量），还有一小部分放 CPU 内存兜底：

GPU0（计算卡）: 10GB 权重 + 激活，峰值 ~22.7GB，满载计算
GPU1（仓库卡）: 19GB 权重，只存不计算，峰值 ~19.8GB
CPU 兜底: ~2.7GB

关键点：

• 34GB 模型实际权重 31.7GB（int8 压缩），显存装得下 29GB，剩下的 2.7GB 放内存
• GPU1 不参与计算，只当"权重仓库"，层通过 NVLink 流式传到 GPU0 算
• 所以本质是"显存拆分 + NVLink 搬运"，不是"单卡全装"也不是"双卡并行计算"
• GPU0 util 100% 满载，GPU1 util 0% 纯存储