云上T4跑不满规格：Gemma 4解码因过热掉速7%

租来的 GPU 按型号和小时计费,但规格表上的数字从来不带温度条件。一位开发者在 Google Cloud 的单卡 T4 上做了一件很少有人认真做的事:把显卡的温度、频率、功耗和降频原因每 100 毫秒记录一次,然后把每个推理请求的 token 生成速度与当时的卡状态一一对应。结论是:同一张卡、同一个模型、同一个提示词,冷态 45°C 时解码 115.3 tokens/s,热态稳态 77°C 时只有 106.8 tokens/s,持续掉速 7.4%,而热节流一次都没有触发。

被忽略的变量:温度

短跑成绩不等于持续性能

T4 的规格表给了一个干脆的数字:FP32 8.1 TFLOPS、FP16 65 TFLOPS。跑一两分钟 benchmark 得到的成绩,通常就被当作这张卡的速度写进对比表格里。问题是,这个数字对应的是 1,590 MHz 的最高频率——按 2,560 个 CUDA 核心、每时钟两次运算反推,8.1 TFLOPS 需要约 1,582 MHz 才能成立。

一旦进入持续负载,卡的真实频率远低于此。作者在 1,430 MHz(44°C 冷态)时按算术换算只有 7.32 TFLOPS,即规格值的 89.9%;在 1,241 MHz(77°C 热态)时只剩 6.35 TFLOPS,约为规格的 78.1%。这个实验要回答的正是:规格数字在卡发热之后还剩下多少。

谁在拉低频率

关键在于功耗墙。T4 在这台 VM 上的功耗上限被锁定在 70W,而这块卡从第一个请求开始就一直贴在这个上限上运行。热芯片的漏电流更高,同样的频率会消耗更多功耗,于是 70W 的预算能买到的频率就被压缩了:45°C 时买到约 1,457 MHz,77°C 时只能买到约 1,267 MHz。

作者用锁频实验直接验证了漏电流效应。把 SM 频率固定在 1,200 MHz、不设功耗限制,66°C 时中位功耗 62.0W,78°C 时升到 66.0W,斜率 0.26 W/°C。同样的时钟、同样的工作量,仅仅因为更热就多消耗 4.0W。NVIDIA 的 TensorRT 文档明确写到了这一现象,并点名 T4 这类容易被功耗墙限制的 GPU,散热不佳会导致稳定频率下降、性能变差。

功耗墙与漏电流的物理机制

现代 GPU 通过片上传感器和固件共同执行一套动态管理策略:芯片内嵌的 PMU(功耗管理单元)实时估算整卡功耗,一旦接近预设的 TDP 上限就动态下调 SM 时钟,这个过程称为 DVFS(动态电压频率调节)。T4 的 70W 上限属于这一机制下的"功耗墙"。

漏电流(leakage current)是理解温度与功耗关系的关键。半导体中的晶体管即使在截止状态也会因亚阈值导通和栅氧隧穿产生微小电流,这部分电流随温度呈指数增长。温度每上升约 10°C,漏电流大致翻倍,于是芯片在相同频率下会消耗更多总功率。由于 DVFS 的总预算固定,多出来的漏电流功耗必然从频率预算里扣除,形成"越热越慢、越慢越需要更长时间、更长时间又进一步加热"的负反馈。这与 CPU 上常见的"温度越高越省电"直觉相反,是高性能芯片散热设计的核心矛盾之一。

实验怎么做的

采样与对齐

实验环境是 n1-standard-2 VM、单张被动散热的 Tesla T4、驱动 615.71.09,推理侧跑 vLLM 0.29.0,模型是 4-bit 权重的 Gemma 4 E2B,单请求、贪心解码、每次输出 256 tokens。

thermal.py 在后台以 100 毫秒为间隔持续调用 nvidia-smi,记录时间戳、温度、SM 频率、显存频率、功耗、降频事件原因、GPU 利用率和电源状态。每个请求记录每个流式 token 的墙钟时间,analyze.py 再把请求跨越的时间窗口内的采样点取出来,让每一次解码速率都能对应到它生成时的温度与频率。

其中 clocks_event_reasons.active 是判断降频原因的关键字段:0x4 表示软件功耗限制,0x20 和 0x40 分别表示软件与硬件热降频。

clocks_event_reasons.active 位掩码解读

NVIDIA 驱动的 clocks_event_reasons.active 返回一个十六进制位掩码,每一位对应一类触发降频的原因,多个原因可以同时置位。常用的位含义包括:0x1 表示 GPU 空闲;0x2 表示应用时钟设置;0x4 表示软件功耗上限;0x8 表示硬件功耗限制;0x10 表示同步提升时钟(boost);0x20 表示软件热降频;0x40 表示硬件热降频;0x80 表示显示时钟;0x100 表示外接电源限制。

这个字段的价值在于把"频率低"从模糊症状变成可归因现象:如果掩码显示 0x4,说明瓶颈是功耗预算而非散热;如果显示 0x40,才是真正的热保护触发。很多性能回归排查之所以无果,正是因为查错了位。建议在监控脚本里把这个字段与 SM 频率、温度一起记录,并在分析时按位分解,而不是只看数值大小。

两组热浸泡测试

实验从低于 50°C 的冷卡开始,连续发送请求做 5 分钟与 20 分钟两组热浸泡。5 分钟组的输出显示解码速率从 114.0 一路降到 106 附近后趋稳;20 分钟组从 57°C 起步,呈现同样的曲线形状。

把所有样本按解码时的平均温度分档后,趋势非常干净:45–49°C 档 115.3 tokens/s、SM 频率 1,457 MHz;75–79°C 档 106.9 tokens/s、SM 频率 1,267 MHz。20 分钟热浸泡的对应数据是 112.7 降到 105.6。散热高低温差在两组测试中分别造成 7.4% 和 6.3% 的损失。

更有意思的是,当卡稳定在 76–78°C 后,解码速率在随后 18 分钟里保持平稳——损失跟随的是温度,而不是时间本身。按单个请求统计,解码速率与 SM 频率的相关系数高达 0.99,与温度的相关系数为 -0.97 和 -0.86。

降频原因与锁频代价

154,815 个样本里没有热节流

把所有运行的数据汇总,154,815 个采样点中,卡只报告过两种降频原因:空闲(idle)和软件功耗墙。软件与硬件热降频从未触发,最高温度读数是 83°C。也就是说,性能损失并非来自保护性的热节流,而是功耗墙与漏电流共同作用下的频率压缩。

这一点很重要:如果看到性能下降就去查热节流标志,很可能什么都查不到。

锁频能稳住,但要付出代价

把 SM 频率锁在 1,200 MHz 后,温度从 65–69°C 升到 75–79°C,解码速率只从 104.8 降到 104.1 tokens/s,漂移从 7% 压缩到 0.7%。代价同样清晰:热态锁频只有 104.1 tokens/s,低于热态不锁频的 106.8 和冷态不锁频的 115.3。即便锁在 1,200 MHz,卡热起来后仍有 29% 的采样点触及功耗上限。NVIDIA 自己的指导文档也承认,锁频下的平均性能不如频率浮动时。

锁频(nvidia-smi -lgc / -lmc)的适用边界

锁频通过 nvidia-smi -lgc <min>,<max> 固定 SM 时钟范围,或用 -lmc 固定显存时钟,把浮动的 DVFS 策略替换为固定工作点。优点是消除了冷热态之间的频率漂移,让 A/B 对比或延迟 SLA 更可预测;缺点是放弃了动态调度带来的平均性能优势,因为 GPU 在负载较松时本可以在功耗预算内冲上更高频率。

生产环境中锁频通常出现在两类场景:一是推理服务的 p99 延迟对频率抖动敏感,宁可牺牲均值换取方差;二是多卡训练需要各卡频率一致以避免同步等待。实验中的 T4 锁在 1,200 MHz 后热态仍有 29% 采样点触及 70W 上限,说明锁频并不能让芯片摆脱功耗约束,只是把"降频"换成了"降频加抖动"。NVIDIA 文档也明确建议:除非有明确的确定性需求,否则不应长期锁频。

对 A/B 测试的直接影响

这个项目最初来自一个推测解码对比:Gemma 4 E2B 单独运行,对比搭配 4-bit drafter、3 个候选 token 的版本。每个服务端跑 6 个提示词、各 3 次请求,并交换运行顺序、控制是否预冷。

结果很能说明问题。每次启动服务端前把卡冷却到 50°C,加速比稳定在 1.297x 或 1.298x,与谁先跑无关。不预冷时,后启动的服务端从热卡起步,比它自己先跑时慢 1.9% 到 2.5%,同样的加速比会读成 1.279x 到 1.337x 之间的任意值。

冷却到 50°C 在这台主机上不到四分钟就能完成;而带着模型空闲运行,同一张卡在 72–76°C 停留 30 分钟都降不下来。所以正确的做法是先停服务端、等温度降到位,再启动下一个。

规格与 SLA 的空白

NVIDIA 的 T4 规格表只列出 8.1 TFLOPS、65 TFLOPS、130 TOPS 和被动散热,没有频率、没有条件、没有脚注。Google Compute Engine 的 GPU 页面重复了 65、130、260 TOPS,同样不带条件说明。而 Compute Engine 的 SLA 把故障定义为外部连接或持久磁盘访问的中断,它保证的是可用性,对速度只字未提。

客户按同样的时价付费,拿到的却可能是 115 或 107 tokens/s,而决定这个差异的散热条件掌握在服务商手里。

实践建议

作者给出的两条建议成本都接近零。第一,任何 benchmark 都应同时记录降频原因:nvidia-smi --query-gpu=clocks_event_reasons.active,clocks.sm,temperature.gpu,power.draw -lms 100 能把"感觉变慢了"变成一个有代码可查的原因。只报 tokens/s 而不报频率的测试,漏掉的正是让这次数字变动 7% 的那个变量。第二,A/B 测试的每一组都要先冷却到同一温度再开始,否则运行顺序本身就会污染结论。

当一致性比速度更重要时,锁频是合理选择,但要清楚它相对热态不锁频还要再低 2.5%。

需要说明实验边界:这是单台笔记本级别配置的 VM 上、单张 T4、单请求、单一模型、两天内完成的三组浸泡测试,每个顺序条件只跑了一次。其他 T4 主机、批处理服务和其它模型都未覆盖,结论不宜直接外推。作者也披露部分分析与写作借助了 AI 辅助,但所有数字都来自已提交的输出文件,代码与日志可在 GitHub 仓库 xbill9/t4-thermal-drift 复现。