别以为云上的 T4 跑在标称值上：卡一热，Gemma 4 解码慢 7%
来源：dev.to — 2026-10-16
📋 概述
作者在同一台 Google Cloud 虚拟机的同一块 Tesla T4 上，用 vLLM 服务 Gemma 4 E2B，同一提示下冷卡 45 ℃ 时解码 115.3 token/秒，稳定在 77 ℃ 时降到 106.8，慢 7.4%；整段时间卡都贴着 70 瓦的功耗上限，而更热的芯片在同一频率下耗电更多，于是功耗墙把频率从约 1457 MHz 拉到约 1267 MHz，热降频标志位从未触发。项目每 100 毫秒记录温度、频率、功耗与降频原因，并把每个请求首尾 token 的时间与采样对齐，因此每个解码速率都能对应到生成它时的卡状态。他指出这件事影响三个客户关心的判断：租来的卡在持续负载下能给出多少速度、一次短基准会高估多少、以及背靠背的 A/B 测试是否公平。
🔑 核心要点
- 同一块 T4、同一台机器、同一模型、同一提示：45 ℃ 时 115.3 token/秒，77 ℃ 时 106.8，慢 7.4%。
- 机制不是降频：卡整段时间都贴着 70 瓦功耗上限，更热的芯片同频更耗电，功耗墙把频率从约 1457 MHz 压到约 1267 MHz。
- 热降频标志位「从未触发」，而规格表对此一个字都没有。
- 测量方法：每 100 毫秒记录温度、频率、功耗与 clocks_event_reasons，并把请求首尾 token 时间与采样对齐。
- 受影响的判断有三件：持续负载下的真实速度、短基准高估的幅度、背靠背 A/B 测试是否公平。
💡 金句
卡整段时间都跑在 70 瓦的功耗上限上，热降频从未触发，而规格表对此一字未提。
👍 0
👎 0
← 返回 dev.to 首页