关于双卡的一个发现，温度协同->频率协同
-
双卡张量并行：温度与频率为什么必须协同
双 3090 风冷跑大模型的一点实战心得
一、TP 的本质：两张卡是拴在一起的
张量并行（TP=2）把每层权重矩阵切成两半，两张卡各算一半（并且是类似奇偶交替接力的)，但每一步都要 AllReduce 同步才能进入下一步。所以单个 step 的耗时永远由较慢的那张卡决定——典型的木桶效应：快卡算完只能原地干等，多出来的算力全部浪费在等待里。二、频率差的来源：温度墙
满载时 GPU 普遍贴着温度墙跑。两卡因风道位置、积灰、硅脂老化差异，同负载下温度常差 5~10°C。热卡先触发降频，频率差一旦出现，慢卡就拖垮整条流水线，decode 速度肉眼可见地掉一截。三、锁频不是万能解
锁频（-lgc）能把两卡频率钉死，但前提是散热扛得住：散热弱的卡根本锁不住，反而更热；且锁频牺牲自动 boost 的峰值性能（本机实测 decode 慢约 3.5%）。四、正解：温度协同
与其追求"各自最凉"，不如把控制目标改成"两卡温差趋近于零"：热卡风扇加速时，冷卡风扇同步跟进，维持同频散热；
两卡温度收敛 → 频率自然同步 → 谁也不用等谁；
实测 ΔT 5~6°C 时，约 26 秒收敛归零，两卡 SM 利用率重新持平。
一句话总结：TP 架构下整体性能 = min(卡1, 卡2)。频率协同保住下限，而温度协同是频率协同的前提。风冷双卡跑大模型的朋友，与其盯着单卡温度数字，先看看两卡温差。
我让GLM 5.2给我写了个风扇控制程序，后面再跑，感觉就顺多了：
—— 欢迎交流指正 ——
-
这篇写得实在，TP 的木桶效应和温度墙分析都说到点上了。补两个实操点：
1. 不想牺牲 boost，可以先试功耗墙对齐
锁频 -lgc 会损失峰值（你实测 3.5%），更温和的做法是把两卡功耗墙设成同一个值：nvidia-smi -pl 260（按散热余量定）。两卡同功耗墙 + 同负载 → boost 行为基本一致，频率差自然收窄，还保留低频卡偶尔冲高的空间。比 -lgc 省心，也适合不想写风扇控制脚本的人先顶着用。2. 温差根源在风道，先动物理再动软件
两卡叠放时，下卡（靠近进风口）和上卡（吃下卡尾气）的进气温度能差 5°C+，这是最普遍的 ΔT 来源。先试：换槽位让两卡进风温度接近、清灰换硅脂、或者把热卡的风扇曲线整体前移——很多时候物理对齐之后，软件协同就没那么必要了。另外补充一个容易忽略的维度：TP 的 AllReduce 除了等时钟，还吃互联带宽。双 3090 如果没插 NVLink 桥，同步走 PCIe 4.0 x16，短 prompt 高频同步时开销占比不小；温度协同解决的是"时钟差"，"带宽争用"是另一层——两张卡同时干重活（一边 LLM 一边 ComfyUI）时也会互相拖。你的风扇控制脚本思路没问题，跑完欢迎回来贴实测数据。
-
双卡张量并行：温度与频率为什么必须协同
双 3090 风冷跑大模型的一点实战心得
一、TP 的本质：两张卡是拴在一起的
张量并行（TP=2）把每层权重矩阵切成两半，两张卡各算一半（并且是类似奇偶交替接力的)，但每一步都要 AllReduce 同步才能进入下一步。所以单个 step 的耗时永远由较慢的那张卡决定——典型的木桶效应：快卡算完只能原地干等，多出来的算力全部浪费在等待里。二、频率差的来源：温度墙
满载时 GPU 普遍贴着温度墙跑。两卡因风道位置、积灰、硅脂老化差异，同负载下温度常差 5~10°C。热卡先触发降频，频率差一旦出现，慢卡就拖垮整条流水线，decode 速度肉眼可见地掉一截。三、锁频不是万能解
锁频（-lgc）能把两卡频率钉死，但前提是散热扛得住：散热弱的卡根本锁不住，反而更热；且锁频牺牲自动 boost 的峰值性能（本机实测 decode 慢约 3.5%）。四、正解：温度协同
与其追求"各自最凉"，不如把控制目标改成"两卡温差趋近于零"：热卡风扇加速时，冷卡风扇同步跟进，维持同频散热；
两卡温度收敛 → 频率自然同步 → 谁也不用等谁；
实测 ΔT 5~6°C 时，约 26 秒收敛归零，两卡 SM 利用率重新持平。
一句话总结：TP 架构下整体性能 = min(卡1, 卡2)。频率协同保住下限，而温度协同是频率协同的前提。风冷双卡跑大模型的朋友，与其盯着单卡温度数字，先看看两卡温差。
我让GLM 5.2给我写了个风扇控制程序，后面再跑，感觉就顺多了：
—— 欢迎交流指正 ——
