想象一栋祖传的老房子：墙体笨重、管线老化、冬冷夏热，每个月电费账单都让人肉疼。你想把它改造成一栋“节能住宅”——地方还是那么大，住起来却更省电、更舒适。浏览器里的机器学习模型，正是这样一栋“老房子”：模型文件动辄几十MB，跑一次推理让CPU呼呼转，内存噌噌涨，在低端手机上更是卡顿、发烫、掉电如流水。你需要的，是一场全面改造。 这趟改造有四支施工队：给房子轻装换材料（模型瘦身），给房间装智能温控（推理节流），把杂物间设计成多功能收纳（内存复用），再把所有照明换成感应灯（按需加载）。贯穿始终的是一道选择题：省电和舒适如何权衡（性能权衡）。同时，你要用上趁手的电动工具（工具框架），最后请第三方来测量验收（实践评估）。读完这篇文章，你就拿到了一张完整的“浏览器ML节能改造施工图”，能在低端设备上让AI功能保持可用、功耗可控、续航更长。

岗位关联

对AI从业者来说，掌握浏览器ML推理的功耗与内存优化，等于掌握在真实设备约束下交付AI体验的工程能力——这是把“能跑的模型”变成“能落地的产品”的关键一跃。

目录
  1. 可视化演示
  2. 模型瘦身（旧房轻装）
  3. 推理节流（智能温控）
  4. 内存复用（收纳魔法）
  5. 按需加载（感应照明）
  6. 性能权衡（取舍评审会）
  7. 工具框架（电动工具箱）
  8. 实践评估（竣工验收）
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示模型量化剪枝瘦身、推理节流rAF对齐、Tensor内存复用池化及按需加载缓存策略，在低端设备上控制功耗并延长续航，含数据流背景和发光动画。

本节配有交互动效（进入视口后自动加载，约 3KB）。

模型瘦身（旧房轻装）

老房子改造的第一步，是减少“自重”。实木衣柜换成轻量中空板材，非承重隔断墙拆掉，外墙贴上薄而保温的新材料——房间面积不变，房子的承重负荷却轻了一大半。浏览器里的模型也一样，先给模型“减重”，后面所有优化才有了基础。

模型减重有三件法宝：量化、剪枝和知识蒸馏。量化相当于把32位的“高精度账本”换成8位的“简版账本”，记录的范围小了，但关键信息还在；剪枝相当于拆掉那些几乎没人走的过道，也就是把接近零的权重和冗余通道删掉；知识蒸馏则像老厨师带徒弟——师傅（大模型）把做菜的经验浓缩成菜谱，徒弟（小模型）照着学，手艺虽不及师傅，但已经能满足家常口味。

量化是这节的重点。对于一个权重向量 \( W \)，我们首先找到它的取值范围，然后均匀切成 \( 2^b - 1 \) 个档位，每个档位用整数表示：

把FP32（32位）权重量化为INT8（8位），存储直接缩小到四分之一；配合剪枝和蒸馏，一个50MB的模型往往能压到10MB以内。房子轻了，楼板承重、水电损耗自然就小；模型轻了，下载、解析、推理的每一环都跟着受益。

q=round(W−zΔ),W≈q⋅Δ+z,Δ=max⁡(W)−min⁡(W)2b−1\displaystyle q = \mathrm{round}\left(\frac{W-z}{\Delta}\right), \quad W \approx q \cdot \Delta + z, \quad \Delta = \frac{\max(W)-\min(W)}{2^b - 1}
这个公式把连续的浮点权重“归入”有限个档位，再把档位还原成近似值，换取存储体积和计算量的下降。
  1. 求量化步长先看权重最小值和最大值，算出总范围再平分：
    Δ=max⁡(W)−min⁡(W)2b−1\Delta = \frac{\max(W)-\min(W)}{2^b - 1}
  2. 确定零点偏移\( z \) 是对应“实数0”的整数档位，保证权重0在量化后依然精确为0
  3. 映射到整数档把每个权重减去零点、除以步长，再四舍五入：
    q=round(W−zΔ)q = \mathrm{round}\left(\frac{W-z}{\Delta}\right)
  4. 反量化还原用整数档乘回步长、加回零点，得到权重近似值：
    W≈q⋅Δ+zW \approx q \cdot \Delta + z

推理节流（智能温控）

房子减完重，接下来装“智能温控”。老房子原来只有一个总开关，一开全屋都亮、都热、都转；智能温控系统则能感知每个房间是否有人、几点几分、室外温度如何，自动调节空调和地暖的功率。人走开就自动降温，快回来了再提前升温——体感变化不大，电费却刷刷往下掉。

浏览器里的推理节流正是这种“按需控功”。帧率控制设定推理任务的天花板，比如目标帧率30fps，就不会为了无意义的60fps白白耗电；动态降频在设备发热或电量不足时降低推理频率；批处理合并把零散的小请求攒成一批一次算完，摊薄调度开销；早停判断则让简单输入提前走完浅层网络就返回结果，像“猜对了就不用翻到最后一页答案”。

节流省下的能量，可以用这样一个累加公式来理解：

有了这套温控逻辑，老房子的空调不再“全屋恒温满功率”，浏览器的CPU和GPU也不在每帧都满负荷运转。用户感受不到明显变慢，但手机不再发烫，续航能多撑半天。

Esaved=∑t=0T(Phigh(t)−Plow(t))⋅Δt\displaystyle E_{\text{saved}} = \sum_{t=0}^{T} \left( P_{\text{high}}(t) - P_{\text{low}}(t) \right) \cdot \Delta t
公式的意义很直白：把每个时间片内“节流前功率减去节流后功率”，乘以时间长度，再累加起来，就是总节省的能量。
  1. 功率差每个时刻计算高功耗与低功耗的差值，这是每个时间片省下的“瞬时节约”：
    Phigh(t)−Plow(t)P_{\text{high}}(t) - P_{\text{low}}(t)
  2. 乘时间片长度省下的功率要保持一段时间才形成能量：
    ⋅Δt\cdot \Delta t
  3. 累加所有时间片把从 \( t=0 \) 到 \( t=T \) 的每个时间片节约量相加：
    ∑t=0T\sum_{t=0}^{T}
  4. 汇总约等累计结果就是本次节流策略节省的总能量：
    EsavedE_{\text{saved}}

内存复用（收纳魔法）

第二间房改造的大头，是杂物间。传统收纳方式是每件物品买一个箱子，箱子塞满角落，走廊只剩一条缝。节能改造的做法是定制一套多功能组合柜：抽屉既是书桌又是床，转角位做成旋转鞋架，柜门一关就隐形。老房子空间没变，能装的东西却翻了一倍。

浏览器ML推理最让人头疼的也往往是内存：模型权重、中间激活、临时张量、上下文的拷贝，全都向堆内存伸手。如果不加规划，每次推理都重新申请、用完再释放，不仅慢，还会频繁触发垃圾回收，造成卡顿。张量复用池预先申请一大块内存，推理时从池里“借”张量，用完了“还”而不是销毁；对象池化让常见的数据结构重复利用，减少GC压力；再配合碎片整理和内存预算，把内存在大块区域里规规矩矩地安排起来。

复用带来的收益，用一个简洁的比率来描述：

收纳的魔法体现在数字上：在常见MobileNet类模型上做张量池复用，峰值内存通常能降低20%到40%，GC次数也大幅减少。房间还是那间房，住出了两间房的感觉。

Rreuse=Mpeaknaive−MpeakreuseMpeaknaive×100%\displaystyle R_{\text{reuse}} = \frac{M_{\text{peak}}^{\text{naive}} - M_{\text{peak}}^{\text{reuse}}}{M_{\text{peak}}^{\text{naive}}} \times 100\%
这个公式回答了一个问题：用了内存复用后，峰值内存到底降低了百分之多少。
  1. 朴素方案的峰值先把“直接用、用后即弃”策略下的内存最高点记为：
    MpeaknaiveM_{\text{peak}}^{\text{naive}}
  2. 复用方案的峰值再把张量池策略下的内存最高点记为：
    MpeakreuseM_{\text{peak}}^{\text{reuse}}
  3. 计算差值两者相减，得到被“省出来”的内存量：
    Mpeaknaive−MpeakreuseM_{\text{peak}}^{\text{naive}} - M_{\text{peak}}^{\text{reuse}}
  4. 归一化与百分比差值除以朴素峰值再乘100%，得到复用节省率：
    ×100%\times 100\%

按需加载（感应照明）

老房子的电路改造有一个细节：全屋换成感应照明。走廊的灯不再通宵亮着，人走过自动点亮15秒，人离开自动熄灭。储藏室更是装了拉绳灯，开门才拉亮，关门就断电。省下的电虽然单次不多，但一年下来积少成多。

浏览器里的模型加载也应该这样，但这恰恰是最容易被忽视的一环。很多开发者把模型文件一次性全量下载、常驻内存，就像把所有房间的灯全天开着。懒加载让模型在用户第一次触发推理时才载入，不触发就绝不吃资源；分片加载把模型按功能切成若干文件，用到哪片就下载哪片；缓存复用则利用Cache API和IndexedDB，二次访问直接读本地；预加载时机讲究“在浏览器空闲时静默下载”，既不抢首屏带宽，也不让用户等。

按需加载省下的启动时间，可以这样计算：

以一个48MB的模型为例，如果首屏只需要其中的6MB关键分片，在6Mbps网络下，启动等待从8秒直接降为1秒。感应灯不会让房间变亮，但会让你“在需要时刚好有光”；按需加载不会让模型变小，但会让你“在需要时刚好有模型”。

Tsaved=∑i∈lazySiRnet\displaystyle T_{\text{saved}} = \sum_{i \in \mathrm{lazy}} \frac{S_i}{R_{\text{net}}}
这个公式把“延迟加载的分片们”各自节省的下载时间全部加总，得到整体提速的收益。
  1. 确定懒加载集合符号里的 \( i \in \mathrm{lazy} \) 指“被安排在按需加载分片里的所有文件编号”
  2. 单个分片大小每个分片文件大小记为：
    SiS_i
  3. 下载时间除以网络速率 \( R_{\text{net}} \)，得到该分片的传输耗时：
    SiRnet\frac{S_i}{R_{\text{net}}}
  4. 求和汇总对所有懒加载分片求和，就是节省的总时间：
    ∑i∈lazy\sum_{i \in \mathrm{lazy}}

性能权衡（取舍评审会）

节能改造进行到一半，家庭会议开起来了：换三层玻璃窗确实保温，但采光变差了；装新风系统空气质量好，但噪音大了；用太阳能板环保，但屋顶承重和初装费让人犹豫。每一项优化都有代价，全都要在“省钱、舒适、健康”之间做乘积式的权衡。

浏览器ML优化同样没有免费的午餐。量化让模型变小，但精度会损失1%到3%；帧率节流省电，但交互响应可能变慢；内存复用减少GC卡顿，但代码复杂度增加；按需加载省首屏流量，但推理时可能要等待下载。精度损失、功耗预算、延迟控制、体验优先，这四个词构成一个不完整的“传热三角”——你不能只在一边使劲。

用公式描述这种多目标权衡，可以借助“体验质量”函数：

开完评审会，老房子的方案终于定了：卧室优先安静，客厅优先采光，卫生间优先防潮。浏览器ML的权衡也一样——AR特效需要低延迟，离线OCR需要低功耗，文档扫描需要高精度。方案没有绝对好坏，只有适合与否。

QoE=w1⋅Acc−w2⋅Lat−w3⋅Pow,s.t.Accloss≤ε\displaystyle QoE = w_1 \cdot \mathrm{Acc} - w_2 \cdot \mathrm{Lat} - w_3 \cdot \mathrm{Pow}, \quad \text{s.t.} \quad \mathrm{Acc}_{\text{loss}} \le \varepsilon
公式把“精度带来的好感”减去“延迟和功耗带来的反感”，得到综合体验分，同时给精度损失划出底线。
  1. 精度收益\( w_1 \) 是精度权重，模型越准，这个正向贡献越大：
    w1⋅Accw_1 \cdot \mathrm{Acc}
  2. 延迟代价\( w_2 \) 是延迟权重，响应越慢，负分越多：
    w2⋅Latw_2 \cdot \mathrm{Lat}
  3. 功耗代价\( w_3 \) 是功耗权重，耗电越多，用户体验越差：
    w3⋅Poww_3 \cdot \mathrm{Pow}
  4. 约束底线\( \mathrm{Acc}_{\text{loss}} \le \varepsilon \) 表示无论怎么优化，精度损失都不能超过可接受的阈值

工具框架（电动工具箱）

第三件事，是把施工队员的手动工具换成电动工具。手拧螺丝换成电动起子机，弹线墨盒换成激光水平仪，切割木板换成台锯。同一批工人，工具升级后，效率翻了好几倍，还更省力气。

浏览器ML也有自己的“电动工具箱”。WebAssembly（WASM）把C++/Rust/Python训练好的模型编译成浏览器原生二进制，免除JS解释执行的性能损耗；WebGPU提供低开销的GPU计算接口，让大矩阵乘法和卷积任务在数百个并行核上飞奔；ONNX Runtime Web是跨平台推理引擎，同一份ONNX模型可以在WASM、WebGL、WebGPU后端间切换；TFLite / MediaPipe则是端侧AI老兵，在图像和视频任务里开箱即用。这些工具不是互相替代，而是在不同硬件条件下各司其职。

工具带来的加速效果，可以用阿姆达尔定律（Amdahl's Law）来理解，它刻画了“并行化”能带来多少收益：

在实际项目中，WebGPU能让卷积算子加速5到10倍，但前提是可并行算子占比高；如果模型中充满小算子，齿轮咬合的启动开销反而可能让并行加速变成减速。工具虽好，也要用在对的场景，就像激光水平仪测量再准，也不能用它来切木板。

Slatency=1(1−p)+pn\displaystyle S_{\text{latency}} = \frac{1}{(1-p) + \dfrac{p}{n}}
这个公式告诉我们：即使有 \( n \) 个并行处理单元，整体加速比还取决于任务中可并行的比例 \( p \)。
  1. 串行比例如果任务里 \( p \) 的部分可以并行，那么剩下的 \( 1-p \) 只能串行执行
  2. 并行部分加速后原本耗时 \( p \) 的部分，被 \( n \) 个单元并行后变成：
    pn\frac{p}{n}
  3. 加速后的总耗时串行部分不变，并行部分变快，总耗时是两者相加：
    (1−p)+pn(1-p) + \frac{p}{n}
  4. 加速比用原始耗时1除以新耗时，得到倍数：
    Slatency=1(1−p)+p/nS_{\text{latency}} = \frac{1}{(1-p) + p/n}

实践评估（竣工验收）

改造完工后，最重要的事是验收。施工队拿出温度记录仪、电表读数、风速计，一项项测量比对：冬天室内温度是否达标？电费环比降了多少？通风是否顺畅？所有指标都超过合同下限，才能签字付尾款。

浏览器ML优化上线前，同样需要一套“测量-比对-验收”流程。性能分析用Chrome DevTools的Performance和Memory面板，看清JS执行、GC停顿、渲染帧率；功耗监控借助Performance Monitor和Battery Status API，记录推理期间的CPU占用和电量变化；设备适配通过 navigator.deviceMemory 和 navigator.hardwareConcurrency 判断设备档次，为不同设备选择不同策略；降级策略则是在GPU不可用、内存吃紧或电池告急时，自动从WebGPU退回WASM，从INT8退回FP16，从实时推理改为任务队列。

验收是否通过，可以用一个决策公式来表示：

签收老房子的时候，张大爷看的不是装修风格，而是电费单；浏览器ML团队上线模型时，看的也不只是跑通Demo，而是性能面板上的帧率和电量曲线。测量什么，就会优化什么——把能耗指标纳入验收标准，才是节能改造真正闭环的开始。

Accept={1,Accloss≤ε ∧ E′E0≤θ,0,otherwise\displaystyle \mathrm{Accept} =\begin{cases}1, & \mathrm{Acc}_{\text{loss}} \le \varepsilon \ \wedge \ \frac{E'}{E_0} \le \theta,\\0, & \text{otherwise}\end{cases}
公式说的是：只有“精度损失在容忍线内”和“能耗降到了目标比以下”同时成立，优化才算验收合格。
  1. 精度条件模型量化或剪枝后的精度损失不能超过 \( \varepsilon \)：
    Accloss≤ε\mathrm{Acc}_{\text{loss}} \le \varepsilon
  2. 能耗条件优化后的能耗 \( E' \) 与原始能耗 \( E_0 \) 的比值要低于阈值 \( \theta \)：
    E′E0≤θ\frac{E'}{E_0} \le \theta
  3. AND 运算符号 \( \wedge \) 表示两个条件必须同时满足
  4. 决策输出条件成立输出1，否则输出0：
    Accept=1/0\mathrm{Accept} = 1 / 0

AI 应用场景

低端手机AR虚拟试妆

阶段：模型部署与推理优化

解决的问题：传统方案在人脸关键点检测中直接加载50MB以上的全精度模型，低端安卓机上启动白屏、内存溢出、摄像头画面卡顿。通过模型瘦身（量化+剪枝）把模型压到8MB，再结合推理节流让关键帧以5fps推理而不是逐帧30fps，同时用张量复用池管理每帧的中间激活，最终让百元机也能流畅试妆。

具体案例：某美妆小程序的实践数据显示，中低端安卓机上的平均启动时间从6.2秒降到1.4秒，连续运行30分钟功耗下降约45%，OOM崩溃率从12%降到0.3%。

移动端文档扫描增强

阶段：按需加载与缓存策略

解决的问题：文档扫描功能包含文字检测、方向校正、OCR识别等多个模型，全部在App启动时加载会挤占大量内存。通过懒加载，用户打开扫描页时才加载文字检测模型，OCR模型在使用到具体操作时才按需分片下载，再用IndexedDB缓存，二次扫描直接本地秒开。

具体案例：邮箱App的“拍附件”功能，把整包32MB的OCR模型按语言拆成五片，中文用户只下载中文片（7MB），首拍耗时从4.8秒降到1.1秒，离线扫描成功率不降反升。

低功耗离线翻译插件

阶段：推理节流与任务调度

解决的问题：浏览器划词翻译插件过去每划一次就完整跑一次Transformer推理，页面打开翻译功能后CPU持续高占用。现在采用批处理合并：用户停顿1秒后的所有划词请求合并成一次推理；页面隐藏时自动降频到最低档，回到前台再恢复；遇到简短单词直接走早停路径返回浅层结果。

具体案例：某开源划词翻译插件合并批处理与早停后，翻译场景平均单次推理功耗下降62%，页面滚动帧率从24fps恢复到55fps。

Python 演示

python35 行
import random  def quantize(weights, bits=8):    """把浮点权重均匀量化到 bits 位，返回量化后向量、步长和零点。"""    lo, hi = min(weights), max(weights)    steps = (1 << bits) - 1    scale = (hi - lo) / steps    zero = round(-lo / scale)    q = [round(w / scale) + zero for w in weights]    return q, scale, zero  def main():    random.seed(42)    weights = [random.uniform(-1.0, 1.0) for _ in range(16)]     q, scale, zero = quantize(weights)    fp32_bytes = len(weights) * 4    int8_bytes = len(weights) * 1    print(f"模型瘦身: {fp32_bytes}B -> {int8_bytes}B, 体积 {int8_bytes / fp32_bytes:.0%}")     power_high, power_low = 1.0, 0.55    print(f"推理节流: 功耗 {power_high:.0%} -> {power_low:.0%}, 节省 {1 - power_low:.0%}")     naive_peak, pool_peak = 64.0, 40.0    print(f"内存复用: {naive_peak}MB -> {pool_peak}MB, 节省 {1 - pool_peak / naive_peak:.0%}")     total_mb, first_mb, net = 48.0, 6.0, 6.0    t_all, t_first = total_mb / net, first_mb / net    print(f"按需加载: 全量 {t_all:.0f}s -> 首块 {t_first:.0f}s, 提速 {t_all / t_first:.0f}x")  if __name__ == "__main__":    main()
目的：用一个小脚本模拟浏览器ML优化的四个环节——量化瘦身、推理节流、内存复用、按需加载——并打印每一环的收益数字，让优化效果“看得见、算得清”。
  1. scale = (hi - lo) / steps计算量化步长，把权重取值范围均匀切分到 \( 2^b - 1 \) 个档位
  2. q = [round(w / scale) + zero for w in weights]每个权重就近取整映射为整数档，完成从FP32到INT8的“瘦身”
  3. fp32_bytes = len(weights) * 4浮点权重每个占4字节，INT8每个占1字节，此行为体积对比提供基准
  4. power_high, power_low = 1.0, 0.55模拟推理节流前后的功耗系数，对应文章中的智能温控思想
  5. naive_peak, pool_peak = 64.0, 40.0模拟无池化和有池化两种方案的峰值内存，体现内存复用收益
  6. t_all, t_first = total_mb / net, first_mb / net全量加载与首块加载的耗时对比，演示按需加载让首屏更快

常见误区

误区把模型权重从FP32变成INT8，数值精度掉了一大截，推理结果肯定没法用了，所以为了保险还是别量化。

正解大多数推理任务中，INT8量化配合校准数据集，精度损失通常在1%到3%以内；遇到个别敏感层还可以做混合精度，把那些层保留FP16。这就像老房子换轻质砖：承重结构没动，只是把非关键的填充墙换薄了，房子不会塌。

为何常见：因为8位能表达的数值档位远少于32位，直觉上会觉得“信息量不够”，却忽略了神经网络本身有很强的冗余性，以及校准手段可以弥补大部分偏差。

误区推理帧率不到60fps就是性能不达标，把帧率往下调就是卡顿，用户肯定会骂。

正解很多浏览器AI任务并不是视频级实时渲染：后台OCR、批量翻译、非即时分析完全可以用低帧率或任务队列完成，功耗能降四成，用户反而觉得手机不烫了、电也扛用了。就像室内感应灯，没人时调暗，有人时再调亮，没人抱怨灯不够亮。

为何常见：受游戏评测中“60fps才是流畅”的印象影响，把游戏场景的铁律硬套到了所有AI任务上，忽略了任务本身的实时性要求。

误区JS引擎自带垃圾回收，推理时频繁创建Tensor没什么大不了，系统会自动回收，不需要做内存复用。

正解几十MB的张量在移动端浏览器反复分配，会触发GC停顿和堆膨胀，甚至OOM崩溃。尤其WASM侧的线性内存需要自己管理，WebGPU Buffer也需要手动复用。内存池化虽然增加代码量，但换来的却是稳定帧率和低崩溃率。

为何常见：普通前端开发中内存泄漏确实少见起眼，但ML推理的单个对象比普通数据大了几个数量级，问题被瞬间放大。

误区模型文件走CDN加载完就放内存里，反正是一次性下载，后面只管推理就行，不需要考虑加载策略。

正解几十MB的模型全部常驻内存会严重挤压页面内存预算，尤其在低内存设备上会直接白屏。采用分片+懒加载+Cache API缓存，不仅首屏快，内存峰值也大幅下降。加载策略和推理本身同样重要。

为何常见：传统Web资源通常只有几KB到几百KB，直觉上“下载完用缓存就行”，忽视了模型体积带来的持有成本是持续性的，不只是下载那一刻。

误区只要把推理切到WebGPU，性能就能翻倍、功耗就能减半，别的优化都不用做了。

正解GPU初始化、纹理上传、小算子的调度开销，在小模型或低端GPU上反而更慢更耗电。通常在CPU/WASM上预热后再用benchmark决定是否切换WebGPU，同时保留WASM回退路径，才是稳妥做法。

为何常见：看到官方WebGPU演示在高端笔记本上跑得飞快，就把特定硬件和特定场景的优势当成了普适结论，忽略了移动GPU的差异和调度成本。

面试题

Q1. 量化到INT8后，模型体积约为原来的多少？

单选题 · easy

  • A.大约缩减为原模型二分之一
  • B.大约缩减为原模型四分之一← 正确答案
  • C.大约缩减为原模型八分之一
  • D.大约缩减为原模型的十六分之一

答案：B。FP32每个权重占4字节，INT8占1字节，四分之一；就像一张16宫格图纸缩成4宫格，格子少了但结构还在。二分之一、八分之一、十六分之一分别对应FP16、INT4、INT2的常规份额，不是INT8的结果。

Q2. 模型瘦身中的“剪枝”指的是？

单选题 · easy

  • A.随机删除模型中的全部网络层
  • B.移除对输出影响最小的权重通道← 正确答案
  • C.直接降低输入图片的输入分辨率
  • D.减少训练环节需要使用的数据集

答案：B。剪枝像拆掉老房子里没人走的隔断墙，目标是移除“影响最小”的权重与通道。随机删除全部网络层会摧毁模型，降低分辨率和减少数据集都不属于剪枝。

Q3. 推理节流中“降频”节省功耗的物理依据是？

单选题 · mid

  • A.动态功耗与电压和频率两者都相关← 正确答案
  • B.峰值功耗和模型推理频率完全无关
  • C.降频会让模型推理的结果损耗精度
  • D.频率提升能显著增加模型的运算量

答案：A。动态功耗与电压平方、频率都相关，降低频率和电压能显著省电，就像空调调低一档，耗电立刻下降。降频不改变模型权重，因此不直接损害精度；选项D描述的是频率对能力的影响，不是省电的物理依据。

Q4. 内存复用策略主要解决哪个实际问题？

单选题 · mid

  • A.网络带宽不足导致模型下载速度过慢
  • B.频繁创建张量带来的堆分配与GC阻塞← 正确答案
  • C.模型训练时梯度消失与梯度爆炸问题
  • D.GPU驱动不支持WebGPU接口的兼容问题

答案：B。内存复用把“反复申请-释放-触发GC”的循环变成“借-还”，核心解决堆分配和GC阻塞。带宽问题靠按需加载和缓存解决，梯度问题属于训练阶段，WebGPU兼容属于工具链适配，都不归内存复用管。

Q5. 按需加载策略带来的最主要收益是？

单选题 · mid

  • A.降低首屏耗时与冷启动内存的占用← 正确答案
  • B.显著提高推理结果的平均准确率
  • C.显著缩短模型训练过程的总时长
  • D.提升浏览器缓存命中的概率比例

答案：A。按需加载的核心收益是“用到才下载”，首屏不用等待整个模型，启动时的常驻内存也大幅减少。推理准确率由模型质量决定，训练时长和浏览器缓存命中是其他优化手段的范畴。

Q6. 低端设备上遇到功耗预算紧张时，最好？

单选题 · mid

  • A.关闭所有模型压缩相关的优化手段
  • B.根据功耗预算动态切换低功耗模式← 正确答案
  • C.把批处理大小调整到最大的上限值
  • D.放弃按需加载改为全量预载模型文件

答案：B。面对功耗紧张，应当像智能温控一样动态降频、降低分辨率或减少帧数，而不是关闭优化或反向操作。关闭压缩会增加负载，拉大批次对低端设备可能爆内存，全量预载会拖慢首屏并加高内存占用。

Q7. 关于浏览器ML推理功耗，正确的判断是？

单选题 · hard

  • A.功耗大小只和模型文件大小成正比
  • B.合理降频可降功耗同时控制延迟增长← 正确答案
  • C.高性能设备运行AI功耗必然更低
  • D.页面尺寸会直接影响推理功耗大小

答案：B。动态降频在功耗和延迟之间取平衡——适度降频功耗显著下降，延迟只略增，这正是推理节流的精髓。功耗还取决于频率、电压、算子类型，用公式衡量，不止模型大小一个变量；高性能设备可能跑更重任务，页面尺寸与推理功耗没有直接关系。

Q8. WebGPU加速最适合处理哪种计算场景？

单选题 · hard

  • A.大量高度并行的矩阵乘法和卷积算子← 正确答案
  • B.完全串行的字符串处理和正则表达式
  • C.简单的单分支条件判断与流程控制逻辑
  • D.后台模型下载与缓存文件管理的任务

答案：A。WebGPU的威力来自并行，矩阵乘法和卷积天然适合上百个并行核；而串行字符串、简单分支、文件管理并无可并行计算量，切到WebGPU只会增加初始化开销与拷贝成本，属于杀鸡用牛刀。

Q9. 以下哪些措施可降低前端推理内存占用？

多选题 · mid

  • A.使用量化压缩权重减少模型体积与存储占用← 正确答案
  • B.使用张量复用池减少反复分配和释放操作← 正确答案
  • C.使用对象池化降低垃圾回收频繁触发概率← 正确答案
  • D.提高Canvas画布分辨率并开启抗锯齿模式

答案：ABC。量化减少存储，张量池和对象池分别减少重复分配和GC压力，三者都能让内存占用更低。提高Canvas分辨率反而增加内存，属于反向操作。

Q10. 关于量化、剪枝、蒸馏的组合使用，理解正确的是？

多选题 · hard

  • A.量化可以降低模型存储和带宽方面的开销← 正确答案
  • B.剪枝能够移除网络中的冗余连接与计算← 正确答案
  • C.蒸馏让小型模型去模仿大型模型的输出← 正确答案
  • D.三种方法任何时候都不能组合在一起使用

答案：ABC。量化减少存储与带宽，剪枝去掉冗余连接，蒸馏用小模型学大模型输出，三者角度不同，可以叠加使用，常见流程是先蒸馏出一个紧凑结构，再剪枝与量化收尾。D的说法否定了组合的可能性，不符合工程实践。