「悦味轩」的老板老周，最怕的不是菜不好吃，而是饭点一到后厨乱成一锅粥。某天他在墙上挂了一块「后厨看板」：每道菜从下单到上桌花了多少秒、每分钟能端出几盘、仓库食材还剩多少、每家分店的灶台火力够不够。有了这块看板，高峰该加人、该换速食菜谱、该拦下哪个包间，心里门儿清。Web 端的 AI 推理（比如用 TensorFlow.js 在浏览器里做人体分割、AR 试妆、智能抠图），就像这门后厨——模型推理是炒菜，而推理性性能监控就是那块看板：推理耗时是「出菜时间」，FPS 是「上菜频率」，内存是「库房容量」，设备分布是「各家分店的灶台型号」。本文就带你把这块看板从头搭起来，学会什么时候该加人、什么时候该换菜单。

岗位关联

学好前端 AI 推理性能监控，你将从「能跑通 Demo」进阶到「扛得住真实流量」，掌握定位卡顿、保障不同设备体验的硬核工程能力——这是前端 AI 工程师区别于普通调包侠的核心竞争力。

目录
  1. 可视化演示
  2. 监控指标体系
  3. 推理耗时剖析
  4. 帧率与掉帧
  5. 内存与显存
  6. 设备分布画像
  7. 采样上报策略
  8. 降级与调优
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

演示TensorFlow.js推理FPS/延迟/内存实时监控仪表盘、设备性能分布分析及自适应降级策略，直观展示前端AI推理性能管理。

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

推理性能实时监控 FPS/延迟/内存三项核心指标实时采集 采样上报策略平衡精度与性能开销 perf={fps,latency,memory} requestAnimationFrame循环采集推理性能指标实时上报

监控指标体系

老周问自己：后厨到底健不健康？答案不是盯着一道菜看，而是同时看四张表——出菜耗时、上菜频率、库存水位、灶台分布。前端 AI 应用的监控同理，四大指标缺一不可：推理耗时、FPS、内存占用、设备分布。

推理耗时回答「一次识别要多久」，像出菜时间；FPS 回答「连续识别的节奏跟不跟得上」，像上菜频率；内存占用回答「模型在浏览器里挤占了多少空间」；设备分布回答「低端机用户是不是被抛弃了」。四张表合起来，才是一张完整体检单。

工程上通常用 performance.now() 打点采集每次推理耗时，配合 FPS 计数器、performance.memory（Chrome 可用）估算 JS 堆内存，再用 WebGL 渲染器信息与 UA 识别设备档位。第一层基础指标是「平均耗时」，定义最朴素：

老周盯着四张表心知肚明：平均出菜 30 秒不代表没有 3 分钟的钉子户。指标体系的正确用法是先看整体、再挖长尾，下一节就沿着「耗时」这条线往下拆。

Tˉ=1n∑i=1nTi\displaystyle \bar{T} = \frac{1}{n}\sum_{i=1}^{n} T_i
平均耗时等于 n 次推理耗时加起来除以 n，是监控看板上最基础的「体温计」，但它会掩盖长尾问题。
  1. T_i第 i 次推理的耗时，相当于记下第 i 道菜的出菜秒数。
    Ti\displaystyle T_i
  2. 求和把从第 1 次到第 n 次的所有耗时累加，像把整晚每道菜的出菜时间都加在一起。
    ∑i=1nTi\displaystyle \sum_{i=1}^{n} T_i
  3. 平均除以次数 n，得到单次平均耗时；平均只能看整体，个别「超慢菜」会被淹没。
    Tˉ=1n∑i=1nTi\displaystyle \bar{T} = \frac{1}{n}\sum_{i=1}^{n} T_i

推理耗时剖析

一道鱼香肉丝从下单到上桌 38 秒，究竟是洗菜慢、炒菜慢还是摆盘慢？老周把流水线拆成三段分别计时。前端推理同理，一次「识别人脸」也是一个三段拼接的流水线。

第一段预处理：图片缩放、归一化、转成张量，相当于洗菜切菜；第二段推理本体：模型在 GPU/WASM 上跑前向计算，相当于下锅爆炒；第三段后处理：把重叠的检测框合并（NMS 去重）、画框上屏，相当于装盘。端到端耗时公式：

具体做法是给三段分别埋点打时间戳，再按占比排序。平均耗时之外更要看 P95/P99 长尾：平均 30ms 但 5% 的请求要 120ms，说明存在间歇性卡顿源，比如 GC 停顿、后台标签页抢占资源。老周的台账除了记总时长，还标注「是哪一段超时」——该加切菜工、换大铁锅还是重摆盘，一目了然。

Te2e=Tpre+Tinfer+Tpost\displaystyle T_{e2e} = T_{pre} + T_{infer} + T_{post}
端到端耗时 = 预处理 + 推理 + 后处理。绝大多数场景下推理本体占比最高，是优化的主战场。
  1. T_e2e用户从触发到看到结果的端到端耗时，即「下单到动筷」。
    Te2e\displaystyle T_{e2e}
  2. T_pre预处理耗时，包括缩放、归一化、CPU 到 GPU 的纹理上传。
    Tpre\displaystyle T_{pre}
  3. T_infer模型前向计算耗时，是「下锅爆炒」的核心环节。
    Tinfer\displaystyle T_{infer}
  4. T_post后处理耗时，如 NMS 去重、画框上屏。
    Tpost\displaystyle T_{post}

帧率与掉帧

老周还关心节奏：客人要求 20 分钟上齐一桌菜，后厨能不能稳定 30 秒一盘地出，而不是前 10 秒猛出 5 盘、后 2 分钟干瞪眼。对应到前端，就是帧率 FPS 与帧时间的稳定性。

FPS 是每秒渲染帧数。对 Web AI 应用而言，一帧内往往混着「推理 + 渲染」，单帧时间一旦超过预算，动画就卡顿。60 FPS 对应约 16.7ms 预算，30 FPS 对应约 33.3ms。FPS 与掉帧率的计算口径：

工程上用 requestAnimationFrame 的时间戳计算帧间隔，超过阈值计一次掉帧；再配合 PerformanceObserver 监听 Long Tasks，定位是哪个脚本霸占了主线程。老周给后厨定规矩：宁可匀速 35 秒一盘，也不要「冲 5 秒歇 2 分钟」。前端同理——稳定 30 FPS 远好于 40↔20 的剧烈抖动。

FPS=1000Tˉframe,ρ=NdropNtotal×100%\displaystyle FPS = \frac{1000}{\bar{T}_{frame}}, \qquad \rho = \frac{N_{drop}}{N_{total}} \times 100\%
FPS 由平均帧间隔换算而来；掉帧率是「帧间隔超过预算」的帧占比。掉帧率比 FPS 更能暴露体验劣化。
  1. 平均帧间隔连续两帧之间的平均间隔（毫秒），即「两盘菜上桌的时间差」。
    Tˉframe\displaystyle \bar{T}_{frame}
  2. FPS 换算1000 除以平均帧间隔，得到每秒帧数；帧间隔越小，FPS 越高。
    FPS=1000Tˉframe\displaystyle FPS = \frac{1000}{\bar{T}_{frame}}
  3. 掉帧数帧间隔超过预算（通常取 50ms）的帧数，即「空档太久的那些菜」。
    Ndrop\displaystyle N_{drop}
  4. 掉帧率掉帧数与总帧数之比，反映卡顿在全部帧中的占比。
    ρ=NdropNtotal×100%\displaystyle \rho = \frac{N_{drop}}{N_{total}} \times 100\%

内存与显存

库房管理是悦味轩的隐形利润。食材进了库房不出货，两周后仓库爆仓，厨房连转身都难。前端 AI 的「库房」是浏览器内存与 GPU 显存：TensorFlow.js 的模型权重、中间激活张量、输入输出 buffer 都是占用空间的「食材」。

模型每次推理在 WebGL 后端会产生临时纹理，若不复用就会反复分配回收，推高 GC 压力。监控内存不能只看瞬时水位，要看增量趋势：

判定规范通常是：连续 5 个采样窗口平均增量为正，且手动回收纹理或切换页面后再采样仍不回落，就触发泄漏告警。优化手法包括复用 tensor buffer、推理后调用 dispose()、固定输入 Shape 避免重复分配、必要时换 WASM 后端。老周的库房台账每两小时登记一次余量，发现「只进不出」立刻查采购单——内存监控的价值正在于趋势异常时第一时间揪出没被释放的模型实例。

ΔMˉ=1k∑i=1k(Mi−Mi−1)\displaystyle \bar{\Delta M} = \frac{1}{k}\sum_{i=1}^{k}(M_i - M_{i-1})
连续多个窗口的平均内存增量持续为正、且强制回收后不回落，基本可判定为内存泄漏——就像库房只进不出。
  1. M_i第 i 个采样时刻的内存快照（JS 堆 + GPU 纹理估算）。
    Mi\displaystyle M_i
  2. 增量相邻两次采样的内存差，正数表示「这周又囤了一批食材」。
    Mi−Mi−1\displaystyle M_i - M_{i-1}
  3. 窗口平均取 k 个增量的平均，抹平瞬时波动，只看稳定趋势。
    ΔMˉ=1k∑i=1k(Mi−Mi−1)\displaystyle \bar{\Delta M} = \frac{1}{k}\sum_{i=1}^{k}(M_i - M_{i-1})

设备分布画像

悦味轩在三条街开了分店：旗舰店的进口燃气灶、居民区的家用电磁炉、学校旁的老式煤炉。同一套菜谱在不同灶台上表现天差地别。Web AI 应用也一样——用户设备从旗舰手机到千元机应有尽有。

设备画像要采集四类信息：GPU 渲染器名称（通过 WEBGL_debug_renderer_info）、硬件并发数 navigator.hardwareConcurrency、设备内存 deviceMemory、UA 平台。把设备分成高、中、低三档，监控各档占比，并计算「性能覆盖分」：

覆盖分直接服务于「兼容矩阵管理」：高分人群跑完整模型，低分人群自动落到轻量模型或 WASM 后端，同一套代码按档位下发不同配置，而不是一刀切。老周根据各家灶台调菜谱：旗舰店做精致大菜，煤炉店做快炒小碟。设备画像就是让 AI 应用「看人下菜碟」，既不辜负高端机，也不抛弃低端机。

S=∑g∈{H,M,L}wg⋅NgNtotal\displaystyle S = \sum_{g \in \{H, M, L\}} w_g \cdot \frac{N_g}{N_{total}}
性能覆盖分是各档位占比的加权和：高端用户占比越高，整体越有条件跑大模型；低端占比高，就该准备轻量方案。
  1. N_g第 g 档设备的数量，H、M、L 分别代表高、中、低三档。
    Ng\displaystyle N_g
  2. 占比该档设备数除以总设备数，即「用这类灶台的店占几成」。
    NgNtotal\displaystyle \frac{N_g}{N_{total}}
  3. 权重w_g 是档位权重，例如高 1.0、中 0.6、低 0.3，体现各档对体验的贡献。
    wg\displaystyle w_g
  4. 加权求和把三档占比加权相加，得到整体性能覆盖分。
    S=∑g∈{H,M,L}wg⋅NgNtotal\displaystyle S = \sum_{g \in \{H, M, L\}} w_g \cdot \frac{N_g}{N_{total}}

采样上报策略

领班不可能记录每桌每道菜的出菜时间，否则记录本身就把工作拖垮了。他的办法是「每 10 桌抽 1 桌详细记录」。前端性能监控同样必须采样上报——全量逐帧上报会让监控自己成为最大的性能瓶颈。

采样要回答两个问题：采多少（采样率）和什么时候采（上报时机）。采样率与抽样误差的关系如下：

工程惯例是默认 10%–20% 采样率，首屏强制上报一次，其余在 requestIdleCallback 空闲时段批量发送；本地数组累积满 5 条或 10 秒合并成一次请求，再做 gzip 压缩。设备指纹需哈希脱敏，只上报档位标签，不回报原始 GPU 型号。老周给领班定规矩：忙时只记「这桌快不快」，闲时再补细节——抽样的台账既有代表性，又不耽误端菜。

p=nN,E=1.96p(1−p)n\displaystyle p = \frac{n}{N}, \qquad E = 1.96\sqrt{\frac{p(1-p)}{n}}
采样率 p 是上报样本占总体的比例；抽样误差 E 随样本量 n 增大而缩小，1.96 对应 95% 置信水平。
  1. 采样率p 等于抽样会话数 n 除以总会话数 N，即「每 10 桌抽 1 桌」。
    p=nN\displaystyle p = \frac{n}{N}
  2. 标准误根号内是样本比例的方差，除以 n 后开方，得到抽样分布的标准误。
    p(1−p)n\displaystyle \sqrt{\frac{p(1-p)}{n}}
  3. 误差界限1.96 乘标准误，得到 95% 置信区间下的抽样误差上限。
    E=1.96p(1−p)n\displaystyle E = 1.96\sqrt{\frac{p(1-p)}{n}}

降级与调优

晚市高峰，老周把 40 道菜的菜单缩到 8 道招牌菜，出菜速度立刻翻倍。他把这招叫「菜单降级」。Web AI 应用在低端机或弱网环境下，同样需要主动降级，而不是等用户投诉了再改。

降级手段分三层：模型降级（换成 MobileNet 等轻量模型，或量化到低精度）、输入降级（降低分辨率、抽帧推理）、功能降级（关掉实时手部跟踪，只保留人脸框）。评估一次降级值不值，看收益公式：

调优要用 Profile 工具定位瓶颈：Chrome DevTools 的 Performance 面板看主线程占用，tf.profile() 看算子级耗时。常见瓶颈包括：频繁 reshape 引发 GPU 同步、纹理上传慢、激活张量未释放导致 GC 高峰。每次发版前跑一遍固定设备、固定 100 帧、固定模型的基准测试，记录耗时与 FPS 作为「回归基线」——菜谱改了先让熟客试菜，指标不倒退才允许上线。老周把「降级台账」钉在墙上：哪个时段、哪些分店、降到了哪一档菜单。性能监控的终点不是报表，而是能自动决策：该降就降、降完看效果、效果不好再调。

G=Tfull−TliteTfull×100%\displaystyle G = \frac{T_{full} - T_{lite}}{T_{full}} \times 100\%
降级收益 = 全量模型耗时与轻量模型耗时的差，再除以全量耗时。收益必须和精度损失一起评估，不能只看提速。
  1. 全量耗时T_full 是完整模型单帧推理耗时，对应高峰前的精致大菜。
    Tfull\displaystyle T_{full}
  2. 轻量耗时T_lite 是轻量模型单帧推理耗时，对应高峰期的小炒。
    Tlite\displaystyle T_{lite}
  3. 收益比例两者之差占全量耗时的比例，衡量「砍菜单」省下的时间。
    G=Tfull−TliteTfull×100%\displaystyle G = \frac{T_{full} - T_{lite}}{T_{full}} \times 100\%

AI 应用场景

场景一：电商 AR 试妆的「流畅红线」监控

阶段：推理性能监控与设备适配（对应监控指标体系、设备分布画像两节）

解决的问题：传统 AR 试妆靠 Native SDK，改为 Web 版后用 TensorFlow.js 跑人脸 468 关键点，低端机帧率掉到 15FPS，用户试两下就流失。没有性能监控，团队连「卡在哪类设备上」都不知道。

具体案例：某美妆品牌小程序上线前先按真实用户采集设备分布（高：中：低 ≈ 4:3:3）生成兼容矩阵，低于 30FPS 的档位自动切换到 128 分辨率、并降为每 3 帧推理一次。上线后 P95 耗时从 110ms 降到 45ms，低端机用户时长提升 32%。

场景二：在线会议的背景虚化降级

阶段：采样上报与降级策略（对应采样上报策略、降级与调优两节）

解决的问题：视频会议每帧都要做人像分割，如果全量上报性能数据，监控本身会吃掉带宽和 CPU。且不同参会者的设备差异巨大，统一跑大模型会让低端机直接卡死。

具体案例：某 Web 会议产品用 10% 采样率 + requestIdleCallback 批量上报，按设备档位下发策略：高端机跑自研分割大模型，低端机降级为轻量版，并在检测到低电量时自动关闭背景虚化。掉帧率从 18% 降到 4%。

Python 演示

python64 行
import randomimport statistics DEVICE_LEVELS = {"high": 0.42, "mid": 0.34, "low": 0.24}  def simulate_latency(level, base):    if level == "high":        return max(10, random.gauss(base, 8))    if level == "mid":        return max(10, random.gauss(base * 1.4, 14))    return max(10, random.gauss(base * 2.1, 22))  class Monitor:    def __init__(self, sample_rate=0.2):        self.sample_rate = sample_rate        self.latency_list = []        self.device_count = {"high": 0, "mid": 0, "low": 0}     def should_sample(self):        return random.random() < self.sample_rate     def collect(self, level, infer_ms):        self.device_count[level] += 1        if self.should_sample():            self.latency_list.append(infer_ms)     def report(self):        n = len(self.latency_list)        if n == 0:            return None        p95 = sorted(self.latency_list)[int(n * 0.95) - 1]        fps = 1000.0 / statistics.mean(self.latency_list)        return {            "avg_ms": round(statistics.mean(self.latency_list), 1),            "p95_ms": round(p95, 1),            "fps": round(fps, 1),            "device_share": self.device_count,        }  def decide_degrade(report):    if report["p95_ms"] > 80 and report["device_share"]["low"] > 0.2:        return "switch to lite model"    return "keep full model"  def main():    random.seed(42)    mon = Monitor(sample_rate=0.2)    for i in range(500):        level = random.choices(            list(DEVICE_LEVELS), weights=list(DEVICE_LEVELS.values())        )[0]        base = 30.0 if level == "high" else (42.0 if level == "mid" else 62.0)        mon.collect(level, simulate_latency(level, base))    report = mon.report()    print("monitor report:", report)    print("degrade decision:", decide_degrade(report))  if __name__ == "__main__":    main()
目的：模拟 500 次前端 AI 推理，用 20% 采样率收集耗时，统计平均耗时、P95、FPS 与设备占比，并自动给出是否降级模型的决策。
  1. mon = Monitor(sample_rate=0.2)创建监控器，只记录 20% 的采样样本，对应「领班每 10 桌抽 1 桌」。
  2. self.device_count[level] += 1所有会话都累加设备档位计数，因为设备占比需要全量统计，但耗时只需要抽样。
  3. if self.should_sample():只有被抽中的样本才进入 latency_list，避免逐帧记录拖垮主线程。
  4. p95 = sorted(self.latency_list)[int(n * 0.95) - 1]排序后取第 95% 位的耗时，这是「长尾真相」，比平均值更能暴露卡顿。
  5. fps = 1000.0 / statistics.mean(self.latency_list)用平均推理耗时换算帧率，呼应「1000 ÷ 平均帧间隔」公式。
  6. if report["p95_ms"] > 80 and report["device_share"]["low"] > 0.2:降级决策规则：长尾超时且低端机占比超两成，就切换轻量模型。

常见误区

误区「我测了 100 次推理，平均 30ms，性能很好，不用优化了。」很多初学者把平均耗时当作性能好坏的唯一依据。

正解平均耗时掩盖长尾。P95/P99 才是体验真相：哪怕平均 30ms，若 5% 的帧要 120ms，用户每 20 帧就卡一次，感知就是「很卡」。就像平均上菜 30 秒，但周五晚 20% 客人等了 3 分钟，客人记住的是 3 分钟那一桌。监控必须同时上报平均、P95、P99 三档。

为何常见：平均值最容易计算，人也习惯用平均概括整体，却忽略了耗时的分布形状。

误区「FPS 显示 50，说明很流畅。」初学者把 FPS 数字当作流畅度的唯一标准。

正解FPS 是平均帧间隔的倒数，帧时间的方差才是关键——平均 50FPS 但忽 30 忽 60 的抖动，体感比稳定 35FPS 更差。监控要同时看掉帧率与帧间隔分布。就像上菜「冲 5 秒歇 2 分钟」，比匀速 35 秒一盘更让客人崩溃。

为何常见：FPS 是游戏玩家最熟悉的数字，本能地把它当作唯一指标，忽略了「稳定」的意义。

误区「等线上报告 P95 超时了，再手动切换模型。」很多团队把降级当成救火手段。

正解性能问题一旦被用户感知，损失就已发生。应在监控中预置规则：某档位连续 N 个窗口掉帧率超阈值 → 自动降级 + 上报决策记录。就像老周提前定好「晚市减菜单」预案，而不是等客人掀桌才改菜谱。

为何常见：手动可控的惯性思维，总觉得自动切换有风险，却没意识到「慢」本身才是最大的风险。

误区「性能监控当然要全量采集，抽样会丢数据。」初学者担心样本少了看不准。

正解全量逐帧上报会让监控自身抢占主线程和带宽，反而制造性能问题。10%–20% 采样在统计上完全够用（样本量几千时抽样误差小于 3%），关键是采样均匀 + 首屏必报。领班事无巨细地记录每道菜，结果耽误了端菜，得不偿失。

为何常见：直觉上数据越多越好，没意识到监控本身也有成本。

误区「当前内存占用 80MB，不高啊，没有泄漏。」初学者习惯看某一时刻的快照值。

正解泄漏是趋势问题而非水位问题。要看连续采样窗口的增量是否持续为正、GC 后是否回落。单看某一时刻，可能恰好处于 GC 后的低点，下一轮又会涨上去。库房现在空着，但这周每天都进 5 箱货只进不出，下月必然爆仓。

为何常见：快照式思维，缺少时间维度的观察习惯。

面试题

Q1. 端到端推理耗时中，通常占比最高的环节是？

单选题 · easy

  • A.模型推理内核← 正确答案
  • B.前端日志输出
  • C.按钮点击事件
  • D.CSS动画渲染

答案：A。端到端耗时 = 预处理 + 推理 + 后处理。推理本体是「下锅爆炒」的核心，通常占大头；日志、点击、CSS 渲染都不属于推理链路，选项 A 正确。

Q2. FPS 为 60 时，单帧预算大约是多少毫秒？

单选题 · easy

  • A.约16.7毫秒← 正确答案
  • B.约33.3毫秒
  • C.约50.0毫秒
  • D.约100毫秒

答案：A。FPS = 1000 ÷ 平均帧间隔，所以 60FPS 对应 1000/60 ≈ 16.7ms。33.3ms 是 30FPS 的预算，50ms 常作为掉帧判定阈值，100ms 则意味着只有 10FPS，均不符合。

Q3. 判断一帧是否「掉帧」的标准通常是？

单选题 · mid

  • A.帧间隔超过预算← 正确答案
  • B.帧图画质变差
  • C.颜色出现偏差
  • D.音频音量变小

答案：A。掉帧指帧间隔超过了预算（如 50ms），相当于「两盘菜上桌的空档太久」。画质、颜色、音频都不是帧率层面的监控指标。

Q4. 以下哪种情况最能暴露真实性能问题？

单选题 · mid

  • A.只看平均耗时
  • B.看P95长尾耗时← 正确答案
  • C.只看首帧耗时
  • D.只看峰值内存

答案：B。平均耗时会掩盖「5% 的帧特别慢」的长尾问题，P95/P99 才能暴露间歇性卡顿源。首帧和峰值内存只代表单点状态，不具备统计代表性。

Q5. 采样上报中，抽样误差随样本量增大会？

单选题 · hard

  • A.快速单调递减← 正确答案
  • B.缓慢线性上升
  • C.保持恒定不变
  • D.先上升后回落

答案：A。误差公式 E = 1.96√(p(1-p)/n)，n 在分母上，因此 n 越大误差越小。样本量从 100 涨到 1000，误差大约降至原来的三分之一，呈递减趋势。

Q6. 前端 AI 推理「降级策略」的核心目标是？

单选题 · hard

  • A.牺牲部分体验保流畅← 正确答案
  • B.完全停止推理服务
  • C.无差别拒绝所有请求
  • D.只对高端机开启功能

答案：A。降级是用轻量模型、低分辨率等「小炒」替代「大菜」，牺牲少量精度换取流畅，而非停服或拒客。老周减菜单是为了出菜更快，不是关店。

Q7. 判定内存泄漏最可靠的依据是？

单选题 · mid

  • A.内存增量持续为正← 正确答案
  • B.单次峰值居高
  • C.首屏加载时间变慢
  • D.帧率瞬间降低一点

答案：A。泄漏是「只进不出」的趋势：连续窗口平均增量持续为正，且 GC 后不回落。单次峰值可能是瞬时分配，加载变慢和帧率波动也各有其他原因。

Q8. 前端推理的端到端耗时包含哪些环节？

多选题 · mid

  • A.图片预处理耗时← 正确答案
  • B.模型推理计算耗时← 正确答案
  • C.结果后处理耗时← 正确答案
  • D.服务器磁盘扩容

答案：ABC。端到端耗时 = T_pre + T_infer + T_post，即预处理（缩放归一化）、推理本体、后处理（NMS 去重）。服务器磁盘扩容属于后端基础设施，与浏览器内推理链路无关。

Q9. 设备能力画像应当采集哪些信息？

多选题 · hard

  • A.GPU渲染器名称← 正确答案
  • B.硬件并发线程数← 正确答案
  • C.指纹哈希脱敏后← 正确答案
  • D.用户明文密码

答案：ABC。GPU 渲染器、硬件并发数、设备内存是判断算力的关键信号；指纹必须哈希脱敏，只保留档位标签。采集用户明文密码既违反隐私规范，也与性能画像无关。

Q10. 下列哪些属于前端 AI 推理的核心监控指标？

多选题 · easy

  • A.推理耗时数据← 正确答案
  • B.每秒帧率FPS← 正确答案
  • C.内存占用趋势← 正确答案
  • D.后端数据库表

答案：ABC。四大核心指标是推理耗时、FPS、内存占用、设备分布，对应后厨的出菜时间、上菜频率、库存容量和灶台类型。数据库表属于服务端范畴，不是前端推理的监控对象。