你有没有买过手机？站在手机店里，店员会问你三件事：“平时打游戏多不多？”“一天能充几次电？”“拍照和刷视频更在意哪个？”——因为一部手机不可能每项都做到满分，顶级的屏幕、超长的续航、极致的拍摄往往相互打架，你要做的只是在其中找到最懂你的那一款。端侧推理框架选型，玩的是同一场游戏：你的 AI 应用是一位“挑剔的用户”，而 ONNX Runtime、MediaPipe、NCNN 这些框架，就是摆在你面前的一台台“手机”。延迟像手指点按的跟手度，功耗像亮屏后的续航与发热，精度像镜头下的画质与美颜还原。选型不是选最贵的，也不是选跑分最高的，而是选一台“延迟、功耗、精度”三角平衡下最适合你场景的手机。

岗位关联

掌握端侧推理框架选型方法，意味着你能在项目方案评审时拿出可量化的对比数据和决策逻辑，而不是凭感觉拍板——这是架构师与工程师从“会用框架”走向“会选框架”的关键一步。

目录
  1. 可视化演示
  2. 框架全景
  3. 延迟测试
  4. 功耗测量
  5. 精度评估
  6. 场景适配
  7. 决策流程
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

通过雷达图对比TF/ORT/NCNN三大端侧推理框架在延迟(Lat)、功耗(Pow)、精度(Acc)三个维度的表现，辅助技术选型决策。

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

端侧推理框架三维权衡 TF Lite适合通用场景，精度高但延迟和功耗中等 ONNX Runtime(ORT)跨平台性能均衡，延迟功耗表现优秀 NCNN专为移动端优化，延迟最低功耗最小，但精度略低 选型公式：Score = w1×Lat + w2×Pow + w3×Acc

框架全景

想象你走进手机店，导购没有先报价，而是带你认了三个招牌：华为店主打“全家桶兼容”，苹果店主打“体验流畅”，小米店主打“性价比高”。端侧推理框架的世界里也有三个响当当的名字——ONNX Runtime、MediaPipe 和 NCNN。ONNX Runtime 背靠微软和 PyTorch/TensorFlow 的生态，几乎什么模型都能跑，像那家“兼容王”旗舰店；MediaPipe 是谷歌出品的移动端利器，手势、人脸、物体检测开箱即用，像专为短视频用户打磨的“体验店”；NCNN 则是腾讯开源的轻量级框架，以“小而快”著称，在国产手机芯片上优化得极其细致。

选框架不是听店员吹得天花乱坠，而是把你真正在意的需求列成一张清单：模型的算子它支持吗？能在你的 ARM 芯片上跑吗？能多平台分发吗？这就像“跨平台能力”这一项，决定了你在 iOS、Android、Linux 之间能否一套代码到处运行。把需求清单里的每一项当成一个“能力维度”，给每个维度配上它在你心里的分量（权重），再给框架在每个维度上的表现打分，加总起来就是它的适配度。

理解了适配度公式，你就掌握了选型的“算账”逻辑：不要问哪个框架最好，而要问哪台“手机”最适合你的需求清单。框架全景只是认识了店门，接下来得亲自测一测它摸上去到底跟不跟手。

Fadapt=∑i=1nwi⋅ci\displaystyle F_{adapt}=\sum_{i=1}^{n} w_i \cdot c_i
适配度 F_adapt 等于每个需求维度的权重 w_i 乘上框架在该维度的能力分 c_i 再全部累加，权重之和通常为 1。权重越大的维度，对总分的影响越强。
  1. 适配度总分F_adapt 是框架对当前需求的综合适配分数，数值越高越值得优先考虑。
    Fadapt\displaystyle F_{adapt}
  2. 求和符号\sum 把 n 个维度的贡献逐一加起来，表示“把每一项需求都算进去”。
    ∑i=1n\displaystyle \sum_{i=1}^{n}
  3. 需求权重w_i 是第 i 个需求维度的重要程度，比如“低延迟”占 0.5，“低功耗”占 0.3，全部 w_i 加起来等于 1。
    wi\displaystyle w_i
  4. 能力得分c_i 是框架在这个维度上的表现，通常是归一化到 0 到 1 之间的分数，越高表示越擅长。
    ci\displaystyle c_i

延迟测试

买手机时你会在柜台疯狂点按屏幕，感受“点了有没有立刻反应”——这就是跟手度。端侧推理的延迟，就是模型从收到输入到吐出输出的“跟手度”。想象你的 AI 应用是个打字员，你说一句话，它要隔多久才打出第一个字？这个指标叫首 Token 延迟（TTFT），智能问答、语音助手这类对话场景对它极度敏感，毕竟没人喜欢对着一个“半天憋不出一个字”的助手。

但手指点的每一屏，其实经历了多个环节：图像要转成张量（预处理）、模型要跑网络（推理）、输出要解析成文字或框（后处理）。所以单纯看“推理耗时”远远不够，要把整条链路拆开量，才知道瓶颈是卡在开锁、走路还是坐下。常见的测量方式是在真机上跑上千次推理，统计平均耗时和 P95 耗时——P95 就像你手机偶尔卡顿的那 5% 时刻，它决定了体验的下限。

延迟测试就像在柜台反复点按屏幕：既要看平均反应快不快，也要留意那偶尔的“卡一下”。测完跟手度，下一步该关心手机烫不烫手、续航撑不撑得住一天了。

Ltotal=Lpre+Linf+Lpost\displaystyle L_{total}=L_{pre}+L_{inf}+L_{post}
总延迟 L_total 由三部分组成：输入预处理耗时 L_pre、模型推理耗时 L_inf、输出后处理耗时 L_post。端到端优化要分别压榨这三段，而不是只看模型的推理时间。
  1. 总延迟L_total 是从数据进入框架到结果返回给用户的完整时间，单位常用毫秒。
    Ltotal\displaystyle L_{total}
  2. 预处理耗时L_pre 包括图像缩放、归一化、数据类型转换等准备工作，你给模型喂的“原料”越规整，这段越快。
    Lpre\displaystyle L_{pre}
  3. 推理耗时L_inf 是模型本身在框架中执行算子的净时间，是延迟的大头，也是框架优化的主战场。
    Linf\displaystyle L_{inf}
  4. 后处理耗时L_post 包括热力图解析、非极大值抑制、文本解码等收尾工作，模型越小它越要盯紧。
    Lpost\displaystyle L_{post}

功耗测量

买手机最怕“用半天就没电，打一局游戏就烫手”。端侧推理的功耗，就是 AI 应用在你设备上“亮屏多久、发热多少”的评判。想想戴着智能手表的用户，如果心率监测的 AI 推理每小时吞掉 5% 电量，这产品根本撑不过一天。功耗测量看两件事：平均功率代表日常续航，峰值功耗代表瞬间发热。平均功率低但峰值功耗飙高，就像平时很省电、一开游戏就烫得握不住。

更隐蔽的是温控策略：手机温度一高就会自动降频，推理速度瞬间掉回“老年机”水平。所以在功耗测量中，要同时记录“功耗曲线”和“温度曲线”，观察模型连续推理 10 分钟、30 分钟后的性能衰减。你测出的不只是一串瓦数，而是一条能耗曲线——就像用户从满电到关机的完整一天，才是续航的真实写照。

功耗测量揭示的“续航与发热”，决定了 AI 应用能不能真正戴在手上、装进口袋。手机选型和框架选型走到这里，还差最后一个关键手感——拍照画质和语音识别到底准不准。

Etotal=∑i=1nPi⋅Δti\displaystyle E_{total}=\sum_{i=1}^{n} P_i \cdot \Delta t_i
总能耗 E_total 等于把整个推理过程切成 n 个小时间段，每段时长 Δt_i 乘上该段的平均功率 P_i，再全部累加。这样既能算总耗电，也能看出哪一段最“吃电”。
  1. 总能耗E_total 表示一次完整推理任务消耗的总能量，单位是焦耳或毫瓦时。
    Etotal\displaystyle E_{total}
  2. 采样段数\sum_{i=1}^{n} 表示把功耗曲线按时间切成了 n 个采样段，切得越细越接近真实能耗。
    ∑i=1n\displaystyle \sum_{i=1}^{n}
  3. 段内平均功率P_i 是第 i 段时长内的平均功率，反映这段时间设备的耗电速率，单位瓦或毫瓦。
    Pi\displaystyle P_i
  4. 段时间间隔\Delta t_i 是第 i 段的持续时间，通常用电流表或功率计按固定频率采样得到。
    Δti\displaystyle \Delta t_i

精度评估

拍照党最关心“放大看会不会噪点爆炸、美颜会不会把脸拍歪”。AI 模型的精度，就是手机镜头里的“画质还原度”。为了在端侧跑得更快，工程师常把模型从 FP32（全精度）压缩成 INT8（8 位整数）——这相当于把一张 40MB 的 RAW 原图压成 3MB 的 JPEG。压缩得当，肉眼看几乎没区别；压缩不当，画面全是“马赛克”。量化精度损失，就是压缩前后模型表现的差距，常用准确率差来衡量。

但精度评估不能只看一个数字。模型里的每一层，就像照片里的不同区域——天空压狠一点没关系，人脸的轮廓压了就露馅。混合精度的策略由此而来：让敏感的层（如注意力层、检测头）保持 FP16 高精度，让不敏感的层大胆量化成 INT8。最终判官是端到端效果：在真实业务数据上跑一遍，看翻译是否通顺、识别是否准确、框是否框得稳。

精度评估让你看清“压缩的代价”：牺牲一档画质，换来翻倍的运行速度，这笔买卖值不值，取决于你的用户是随手拍还是放大看。把延迟、功耗、精度三个维度都测完，下一步就是把它们套到真实用户的头上，看看你服务的到底是谁。

ΔAcc=Accfp32−Accint8\displaystyle \Delta Acc = Acc_{fp32}-Acc_{int8}
精度损失 ΔAcc 等于 FP32 全精度模型的准确率减去 INT8 量化后模型的准确率。这个差值越小，说明量化保留的“画质”越好；如果差异无法接受，就该考虑混合精度或更聪明的量化策略。
  1. 精度损失量\Delta Acc 表示量化前后模型准确率的差值，通常以百分比计，数值越小越好。
    ΔAcc\displaystyle \Delta Acc
  2. 全精度准确率Acc_{fp32} 是原始 FP32 模型在验证集上的准确率，是“无损原图”的基准表现。
    Accfp32\displaystyle Acc_{fp32}
  3. 量化后准确率Acc_{int8} 是量化成 INT8 后模型的准确率，相当于“压缩后再观看”的画质表现。
    Accint8\displaystyle Acc_{int8}

场景适配

现在你手机店里的顾客已经排好了队：游戏党要的是跟手、拍照党要的是画质、户外党要的是续航。端侧 AI 的场景也同样分流。实时交互场景的代表是语音助手和 AR 滤镜，用户说一句话，恨不得 0.1 秒就得到回应，首 Token 延迟是生死线；离线批处理场景的代表是相册分类和日志聚类，它不着急出结果，但一处理就是几千张图，关心的不是延迟而是吞吐量；长续航场景的代表是智能手表和耳机，一次推理必须控制在几毫瓦内，否则用户一天得充三次电。

维度之间的取舍不是二选一，而是按比例倾斜。你可以把不同场景的需求映射成一个“归一化的需求向量”：延迟、功耗、精度的原始测量值，经过 (当前值-最小值)/(最大值-最小值) 的变换，全部落到 0 到 1 的刻度上，这样不同量纲的指标才能放到同一个天平上比较。

场景适配就像帮不同类型的用户推荐手机：游戏党别看续航，户外党别看画质。当每个场景的需求都被拧成了清晰的数值，最后一步就是把这些数值放进一个决策流程里，做最终的拍板。

Si=xi−min⁡(x)max⁡(x)−min⁡(x)\displaystyle S_i=\frac{x_i-\min(x)}{\max(x)-\min(x)}
归一化得分 S_i 把第 i 个指标 x_i 映射到 0 到 1 之间：它是数据中的最小值时得 0 分，是最大值时得 1 分。通过归一化，延迟的毫秒数、功耗的瓦数、精度的百分比才能放在同一个打分表里比较。
  1. 归一化得分S_i 是第 i 个指标换算后的无量纲分数，范围严格在 0 到 1 之间。
    Si\displaystyle S_i
  2. 原始指标值x_i 是该框架在这个维度上的原始测量值，比如延迟 12.5 毫秒。
    xi\displaystyle x_i
  3. 最小值\min(x) 是所有候选框架中该指标的最小值，作为得分下限的基准。
    min⁡(x)\displaystyle \min(x)
  4. 最大值\max(x) 是所有候选中该指标的最大值，作为得分上限的基准。
    max⁡(x)\displaystyle \max(x)

决策流程

你终于决定下单了，但付款前还是老老实实走了四步：先在备忘录写下需求（“3000 元以内、续航一天、不卡”），再给每一条需求标注重要程度，然后去实体店把候选机型各摸了一遍，最后权衡再三选定了那台“不是最好但样样够用”的手机。框架选型的决策流程如出一辙：需求量化列出延迟、功耗、精度的目标数值与容忍底线；多维打分用归一化后的得分乘上权重，算出每个候选框架的综合分；候选试用把排名前二的框架接入真实业务代码，在真机上跑足一天；权衡定稿选定最终框架，并记录下备选方案和回退条件。

打分环节的核心是一条加权公式：综合得分等于延迟分、功耗分、精度分分别乘上对应权重后相加。如果你做的是智能音箱，可以把延迟权重提到 0.5；如果你的产品是睡眠监测手环，功耗权重要压倒一切。权重的总和必须为 1，它代表着你在三难困境中愿意押注的方向。

决策流程走完，你的手机也终于买回了家——也许它没有最快的芯片，但它在你的场景里样样称心。端侧推理框架选型，说到底就是一门“在约束中找最优解”的功课：想清楚用户是谁，测明白三项指标，列清楚打分权重，剩下的交给数据和流程。

Total=α⋅Slat+β⋅Spower+γ⋅Sacc,α+β+γ=1\displaystyle Total=\alpha\cdot S_{lat}+\beta\cdot S_{power}+\gamma\cdot S_{acc},\quad \alpha+\beta+\gamma=1
综合得分 Total 由三部分组成：延迟得分 S_lat 乘权重 α、功耗得分 S_power 乘权重 β、精度得分 S_acc 乘权重 γ。三项权重之和必须等于 1，谁的权重高，谁就在最终决策中拥有更大话语权。
  1. 综合得分Total 是框架的最终评分，选型时直接取最高分，也称作加权总评分。
    Total\displaystyle Total
  2. 延迟项\alpha \cdot S_{lat} 表示延迟维度的贡献，α 越大，越不能容忍卡顿。
    α⋅Slat\displaystyle \alpha \cdot S_{lat}
  3. 功耗项\beta \cdot S_{power} 表示功耗维度的贡献，β 越大，对续航和发热越敏感。
    β⋅Spower\displaystyle \beta \cdot S_{power}
  4. 精度项\gamma \cdot S_{acc} 表示精度维度的贡献，γ 越大，越无法接受画质损失。
    γ⋅Sacc\displaystyle \gamma \cdot S_{acc}
  5. 权重约束\alpha+\beta+\gamma=1 保证三个权重构成完整的“决策预算”，一个权重增加，另外两个必须相应减少。
    α+β+γ=1\displaystyle \alpha+\beta+\gamma=1

AI 应用场景

智能手表的睡眠监测模型选型

阶段：端侧模型部署与推理框架选型

解决的问题：手表的电池只有 300mAh，每隔 5 分钟就要跑一次睡眠阶段分类模型。传统的做法直接在服务器上测试准确率，忽略端侧功耗，导致手环半天就没电、表面发烫。按功耗优先流程测量候选框架的平均功率与温控曲线后，找到了比默认方案省电 40% 的 NCNN 部署方案。

具体案例：某健康科技公司在开发睡眠监测手表时，用“长续航场景”的选型模板，将功耗权重设为 0.6、延迟 0.2、精度 0.2，在多维归一化打分后排除了综合分落后的通用框架，最终让设备续航从 14 小时提升到 36 小时。

智能眼镜的实时语音翻译

阶段：端到端延迟优化与框架性能评估

解决的问题：用户在餐厅里对着智能眼镜说外语，1.2 秒后才弹出翻译字幕，体验如同“对着一个反应迟钝的店员说话”。通过把延迟拆成预处理、推理、后处理三段，定位到推理阶段占了 67%，随后换用对 Transformer 算子优化更激进的推理框架，并开启 INT8 动态量化，首 Token 延迟降到 0.4 秒。

具体案例：某 AR 创业公司将候选框架在同款骁龙芯片上做了 P95 延迟对比，选中延迟得分最高的框架后，还保留了混合精度回退开关：当检测到温度升高时自动降级为更小的模型，避免降频导致的持续性卡顿。

工业质检的端侧图像甄别

阶段：精度评估与量化调优

解决的问题：产线上的质检相机要识别 0.1mm 级别的划痕，FP32 模型量化到 INT8 后误检率从 0.3% 飙到 2.1%，相当于每 1000 个零件多报废 18 个，工厂完全无法接受。按精度评估流程对每一层做敏感度分析后，仅让最后的检测头保持 FP16，其余层量化成 INT8，推理速度提升 1.8 倍、误检率仅上升到 0.4%，精度与速度都过了线。

具体案例：某消费电子代工厂在部署端侧质检模型时，用端到端效果验证替代只看平均精度，发现混合精度方案在划痕、脏污、缺角三类缺陷上均满足产线要求，最终定稿落地。

Python 演示

python41 行
# -*- coding: utf-8 -*-"""端侧推理框架选型评分决策: 基于延迟/功耗/精度加权打分"""FRAMEWORKS = {    "ONNX Runtime": {"latency_ms": 12.5, "power_mw": 320, "accuracy": 0.985},    "MediaPipe":    {"latency_ms": 9.8,  "power_mw": 290, "accuracy": 0.971},    "NCNN":         {"latency_ms": 8.9,  "power_mw": 250, "accuracy": 0.966},} def normalize(metrics, lower_is_better=False):    """把原始指标线性缩放到 0..1"""    lo = min(metrics.values())    hi = max(metrics.values())    if lo == hi:        return {k: 1.0 for k in metrics}    if lower_is_better:        return {k: 1.0 - (v - lo) / (hi - lo) for k, v in metrics.items()}    return {k: (v - lo) / (hi - lo) for k, v in metrics.items()} def select_framework(weights):    """weights 为 [延迟权重, 功耗权重, 精度权重], 三者之和必须为 1"""    assert abs(sum(weights) - 1.0) < 1e-6, "权重之和必须为 1"    s_lat = normalize({k: v["latency_ms"] for k, v in FRAMEWORKS.items()}, lower_is_better=True)    s_pow = normalize({k: v["power_mw"] for k, v in FRAMEWORKS.items()}, lower_is_better=True)    s_acc = normalize({k: v["accuracy"] for k, v in FRAMEWORKS.items()})    scores = {}    for name in FRAMEWORKS:        scores[name] = weights[0] * s_lat[name] + weights[1] * s_pow[name] + weights[2] * s_acc[name]    best = max(scores, key=scores.get)    return scores, best if __name__ == "__main__":    scenarios = [        ("均衡型",   (0.34, 0.33, 0.33)),        ("性能优先", (0.60, 0.20, 0.20)),        ("续航优先", (0.15, 0.65, 0.20)),    ]    for name, w in scenarios:        scores, best = select_framework(w)        print("[%s] 推荐: %s" % (name, best))        for k, v in sorted(scores.items(), key=lambda x: -x[1]):            print("  %s: %.3f" % (k, v))
目的：演示端侧推理框架选型的加权评分决策——输入三种典型场景的权重，程序自动归一化延迟、功耗、精度三项指标并输出最优框架推荐。
  1. "latency_ms": 12.5用字典存储三个候选框架的延迟、功耗、精度原始测量值，对应真机 Benchmark 数据。
  2. def normalize(metrics, lower_is_better=False)把不同量纲的指标缩放到 0 到 1，延迟和功耗越小越好所以要反向。
  3. 1.0 - (v - lo) / (hi - lo)反向归一化的核心式子，值越小得分越高。
  4. assert abs(sum(weights) - 1.0) < 1e-6强制保证三个权重之和为 1，否则评分就变成了“预算超支”。
  5. weights[0] * s_lat[name]把延迟得分乘上延迟权重，权重越高它对总分的影响越大。
  6. <span>max(scores, key=scores.get)选出综合得分最高的框架作为推荐结论。
  7. ("性能优先", (0.60, 0.20, 0.20))定义一个“游戏党式”场景：延迟权重 0.6，功耗和精度各 0.2。

常见误区

误区选框架时只看推理延迟，觉得延迟最少的框架就是最完美的，其他指标都无所谓。

正解延迟低常常是用功耗换来的。某个框架在降低延迟的同时，可能峰值功耗高了 30%，导致设备发热降频，最终长时间运行的平均延迟反而更差。就像一台手机开性能模式打游戏跟手，但 10 分钟就烫手降频，体验照样拉胯。选型必须是延迟、功耗、精度的综合权衡。

为何常见：因为延迟最直观、最容易跑分对比，人的直觉天然偏向“快即好”，忽略了端侧设备续航和散热的隐形代价。

误区在服务器上用 GPU 把候选框架跑了一遍，得出“谁快谁慢”的结论，直接照搬到手机端。

正解端侧的硬件调度、内存带宽、NPU 算子支持与服务器天差地别。同一个框架在服务器上最快，换到骁龙芯片上可能因为 NPU 算子没适配反而最慢。必须在目标真机上、用目标模型、按目标场景跑基准测试，才能得到可信数据。这好比拿赛车场的试驾成绩推断这辆车在市区堵车路段的油耗，根本是两回事。

为何常见：服务器上测试方便、资源充足、环境统一，而真机测试要搭环境、写脚本、盯功耗仪，流程长且繁琐，容易被人偷懒跳过。

误区量化后模型在测试集上的平均准确率只掉了 0.5%，就认为完全没有问题，直接上线。

正解平均指标会掩盖“特定场景崩塌”。某些缺陷样本在量化后可能频繁漏检，比如把浅色划痕全部识别成正常，业务上这就是不可接受的。要用端到端效果验证：把量化模型放进真实业务流，看它在目标场景下的表现，必要时针对敏感层做混合精度。画质压缩后平均色调没变，但人脸糊了，你能说这张照片没问题吗？

为何常见：平均准确率是一个现成的数字，看起来客观又方便汇报，人们容易把“平均损失小”等同于“所有场景都安全”。

误区测功耗只跑 30 秒，看到平均功率很低就宣布该框架省电。

正解端侧设备是热惯性的，连续推理几分钟后温度上升，芯片会主动降频保护，功耗和延迟都会随之恶化。一个框架可能在 30 秒内表现优异，但在 10 分钟连续推理后性能崩盘。要记录完整能耗曲线和温度曲线，观察“稳态表现”而不是“冷启动表现”。这就像手机评测一定要测“玩半小时游戏后的帧率”，不能只看刚开机的跑分。

为何常见：短时间测量省时省力，而且多数工具默认只记录短窗口，测试人员没有意识到热积累才是端侧功耗的隐藏杀手。

误区打分时权重随便填，比如延迟、功耗、精度都填 0.9，做完加权发现所有框架总分接近，选不出结果。

正解权重之和必须为 1，它本质是你在三项指标之间分配“决策预算”：给延迟 0.6，就只剩 0.4 分给功耗和精度。填权重前要先做需求量化，和产品、硬件团队对齐“底线指标”和“期望指标”，再决定预算分配。购买决策时不限定预算，最后一定是越看越贵、无法下单。

为何常见：权重看起来只是一个数字，人们容易凭感觉填写，而不理解它在数学上是一种资源分配，所有权重之间存在此消彼长的约束。

面试题

Q1. 端侧推理与云端推理相比，最核心的差异化优势是？

单选题 · easy

  • A.无需联网、保护数据隐私← 正确答案
  • B.云端没有网络时无法使用
  • C.模型参数规模能做的更大
  • D.训练速度可以变得更快

答案：A。端侧推理把模型部署在设备本地，推理过程不依赖网络，从根源上避免了数据出设备的风险，这是它区别于云端推理最核心的优势。C 和 D 反而是云端的强项，B 是云端缺陷的重复描述，不如 A 完整准确。

Q2. 以下哪个框架主要用于端侧推理？

单选题 · easy

  • A.谷歌MediaPipe工具链← 正确答案
  • B.PyTorch深度学习库
  • C.英伟达CUDA计算库
  • D.Hadoop大数据平台

答案：A。MediaPipe 是谷歌面向移动端的推理框架，专门为端侧场景做了优化。PyTorch 主要用于训练，CUDA 是 GPU 计算库，Hadoop 是大数据处理平台，三者都不是端侧推理框架。

Q3. FP32模型量化为INT8后，最典型的影响是？

单选题 · mid

  • A.精度轻微下降速度提升← 正确答案
  • B.精度大幅提升体积减小
  • C.延迟明显增加功耗升高
  • D.模型体积必然扩大数倍

答案：A。INT8 量化把参数从 32 位浮点压到 8 位整数，模型体积缩小约 4 倍，推理速度因为内存带宽压力降低而显著提升，代价是精度通常会有轻微损失。B、C、D 都和量化实际效果相反。

Q4. 以下哪种指标最能体验智能对话首屏响应？

单选题 · mid

  • A.首Token延迟指标数值← 正确答案
  • B.模型训练集样本数量
  • C.峰值功耗持续的时间
  • D.云端GPU的浮点算力

答案：A。首 Token 延迟（TTFT）指用户输入后到模型吐出第一个字的耗时，是智能对话“首屏响应”的直接度量。训练样本数量、峰值功耗、GPU 算力与首屏响应没有直接关系，属于混淆项。

Q5. 端侧推理框架选型需关注的关键指标有哪些？

多选题 · mid

  • A.端侧推理延迟测量值← 正确答案
  • B.设备功耗与发热表现← 正确答案
  • C.模型量化后的精度损失← 正确答案
  • D.框架作者的社交影响力

答案：ABC。选型三要素是延迟、功耗、精度，对应 A、B、C。框架作者的社交影响力与框架在真实设备上的表现无关，不应作为选型依据，属于明显的干扰项。

Q6. 测量框架功耗时，下列哪项做法最合理？

单选题 · mid

  • A.监控平均功率与峰值功耗← 正确答案
  • B.只记录设备开机时间
  • C.直接采用厂商宣传续航
  • D.只看代码行数多少

答案：A。合理做法是同时记录平均功率（决定续航）与峰值功耗（决定发热），并结合温控降频策略观察长时表现。B、C、D 均不是有效的功耗测量手段，厂商宣传续航也不等于真实推理功耗。

Q7. 关于混合精度量化策略，以下合理的做法是？

多选题 · hard

  • A.注意力层保持高精度表示← 正确答案
  • B.所有层全部压到INT4精度
  • C.对量化敏感层单独保留FP16← 正确答案
  • D.用端到端效果验证量化精度← 正确答案

答案：ACD。混合精度的核心是“敏感层保守、非敏感层激进”，注意力层和量化敏感层保留 FP16 或更高精度，其余层大胆量化，最后必须用端到端效果验证。B 的做法不分层、全压 INT4，可能导致严重精度崩溃，不是合理策略。

Q8. 正确的框架选型决策流程是？

单选题 · hard

  • A.量化需求→多维打分→试用候选→权衡定稿← 正确答案
  • B.先选框架再进行需求定义
  • C.只按精度最优做最终决定
  • D.完全依赖供应商广告宣传

答案：A。正确流程是先明确需求并量化成权重，再用多维打分筛出候选，再上真机试用验证，最后权衡定稿。B 颠倒了需求与选择的顺序，C 犯了单维度决策的错误，D 更是放弃了技术判断。

Q9. 延迟测试时为什么不能只关注平均延迟？

单选题 · hard

  • A.平均延迟会掩盖长尾卡顿问题← 正确答案
  • B.平均延迟的数值必然不精确
  • C.平均延迟在端侧没有意义
  • D.平均延迟不适用于任何场景

答案：A。平均延迟只反映整体水平，P95、P99 等长尾指标才能暴露偶发卡顿。比如平均 10ms 但 P95 有 200ms，用户实际感知是“经常卡”。平均延迟是有效指标，A 揭示的是它单独使用时的盲区，因此选 A。

Q10. 端侧语音助手偶发卡顿，合理的排查方向是？

多选题 · extreme

  • A.分解端到端延迟定位瓶颈← 正确答案
  • B.监控温控降频导致的性能衰减← 正确答案
  • C.检查量化后模型的异常重试率← 正确答案
  • D.直接更换更高端旗舰手机

答案：ABC。偶发卡顿应从端到端延迟分解入手定位瓶颈段，同时监控温度升高导致的降频，并排查量化模型在特定输入上是否触发异常重试。D 回避了问题，换硬件不等于排查，属于错误选项。