中秋前夜，一家糕点厂烤好了一批一模一样的月饼——这就是你训练好的 AI 模型——需要立刻送到用户手中。调度中心（TVM 编译器）准备好了四条配送路线：GPU 特快专线、CPU 干线大卡、移动端小电驴、WebAssembly 无人机。包裹还是那批包裹，可路线不同，抵达时间、油耗、载货量天差地别。本文就是调度中心的“路线对比报告”：用延迟、内存、吞吐量三张报表，把四条路线的表现摊开对比，帮你在真实项目里选出最划算的那条路。理解了这份报告，就等于掌握了跨平台部署的选型心法。

岗位关联

学会读这份性能对比报告，你就能像资深调度员一样，根据延迟、内存、吞吐量给模型挑最合适的部署路线，让工程选型有数据可依、有逻辑可循。

目录
  1. 可视化演示
  2. 四大平台概览
  3. 推理延迟对比
  4. 内存占用分析
  5. 吞吐量评估
  6. 基准测试方法
  7. 平台优劣总结
  8. 选型决策指南
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

对比GPU、CPU、移动端与WebAssembly在推理延迟、吞吐量与内存占用上的差异，助力部署方案选型与优化。

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

延迟对比：GPU vs CPU vs 移动端 GPU并行归约推理延迟最低 移动端NPU轻量模型表现优异 lat=compile+infer 按硬件特性选型部署方案

四大平台概览

想象调度中心面前的四条路：GPU 特快专线修着成千上万条平行轨道，一次能拉海量货物，是所有路线中最快的；CPU 干线大卡走的是普通国道，哪儿都能去，不挑路况；移动端小电驴灵活轻巧，但电池有限、一次驮不了太多；WebAssembly 无人机最特殊，不需要专门的配送站——只要客户打开浏览器，它就能直达窗口，只是每趟只能带一个小包裹。

把这四条路对应到技术世界，就是模型部署的四种环境。TVM 就像一个聪明的调度中心，它把同一份训练好的模型“重新打包”成四种形态：为 GPU 生成 CUDA 算子代码，为 CPU 生成带 AVX 向量化的指令，为移动端生成 ARM 平台的 NEON 指令，为 WebAssembly 生成浏览器沙箱里可执行的字节码。包裹的原料相同，包装方式不同，跑起来的效果自然也不同。

经验数据也印证了这个直觉：同样的图像分类模型，GPU 推理往往只需几毫秒，CPU 要几十毫秒，移动端和 WebAssembly 则更慢。这背后的原因是硬件结构的差异——GPU 有数千个计算核心适合并行，CPU 核心少但主频高，移动端芯片优先考虑省电，浏览器沙箱则对计算能力有天然限制。

有了这张“路况图”，后续的延迟、内存、吞吐量报表才有了参照系。调度员知道四条路的底细，接下来就要看每份报表里藏着什么门道。

LGPU<LCPU<L移动端<LWASM\displaystyle L_{\text{GPU}} < L_{\text{CPU}} < L_{\text{移动端}} < L_{\text{WASM}}
这条不等式是“路线对比报告”的第一行结论：在典型基准测试中，四类平台的推理延迟从低到高依次是 GPU、CPU、移动端、WebAssembly。
  1. L 表示延迟$L$ 是英文 Latency 的首字母，指从输入进入模型到输出返回的总耗时，单位通常用毫秒（ms）。
    LGPUL_{\text{GPU}}
  2. 下标表示平台$\text{GPU}$ 指图形处理器平台，其余下标同理，每一项都代表“在该平台上推理一次的时间”。
    LCPUL_{\text{CPU}}
  3. 不等号表示排序$<$ 表示“小于”，整串不等式说明在硬件条件相仿的基准测试中，延迟从低到高的固定顺序。
    <<

推理延迟对比

月饼从装车到签收，总耗时可以拆成三截：装月饼的时间、路上跑的时间、卸货清点的时间。AI 推理的延迟也一样，不是铁板一块，而是由多个环节累加而成。如果只盯着“总延迟”这个数字，你就不知道时间到底浪费在了哪一截。

在技术世界里，我们把端到端延迟拆成三部分：计算时间（真正做矩阵乘法、卷积等数学运算的耗时）、传输时间（把数据从内存搬运到计算单元、把中间结果搬回来的耗时）、框架开销（调度算子、分配内存、同步线程等固定成本）。这三截在不同平台上的比例完全不同。

GPU 上计算时间被压缩到极致，但数据搬运的“装车卸货”反而可能成为瓶颈——显存和算力之间的通道就那么宽；CPU 上三者相对均衡，缓存命中率高时传输开销会小很多；移动端芯片在省电模式下会主动降频，计算时间被拉长；WebAssembly 则每走一步都要经过浏览器沙箱的“安检”，框架开销尤其明显。

调度员拿到延迟报表后，正确的做法是“拆开看”：GPU 上优化数据搬运，WASM 上压缩计算量，移动端则要避免降频。延迟不是一句话能概括的数字，而是三个环节的合奏。

L总=L计算+L传输+L开销\displaystyle L_{\text{总}} = L_{\text{计算}} + L_{\text{传输}} + L_{\text{开销}}
端到端延迟不是单一指标，而是计算时间、数据传输时间和框架固定开销三者的总和。优化前先定位瓶颈在哪一截。
  1. 总延迟$L_{\text{总}}$ 是用户感知到的完整响应时间，也就是三截耗时加起来的“签收总时长”。
    L总L_{\text{总}}
  2. 计算时间$L_{\text{计算}}$ 是模型真正做数学运算的耗时，GPU 之所以快，主要就是这一项被大幅压缩。
    L计算+L传输L_{\text{计算}} + L_{\text{传输}}
  3. 传输与开销$L_{\text{传输}}$ 是数据搬运耗时，$L_{\text{开销}}$ 是框架调度等固定成本，两者在小模型上往往比计算时间更不可忽略。
    L传输+L开销L_{\text{传输}} + L_{\text{开销}}

内存占用分析

四条配送路线的载货量天差地别。GPU 特快专线背后是大型货车队，载货量大但养护成本高；CPU 卡车中等吨位，中规中矩；移动端小电驴只能驮小包裹，塞多了就跑不动；WebAssembly 无人机被浏览器限得最死，超重直接拒飞。

模型推理时的内存占用同样可以拆成三块：权重参数（模型训练出来的“肌肉记忆”，数量固定）、激活缓冲（输入数据流过网络时产生的中间结果，随输入大小变化）、运行时开销（推理引擎本身占用的基础空间，比如算子库和内存池）。三块之和就是平台的内存压力。

对比下来，GPU 显存充裕，权重参数可以大方地以高精度存放，激活缓冲也铺得开；CPU 内存最宽裕但带宽有限；移动端和 WebAssembly 内存紧张，往往需要把权重从 32 位浮点压缩到 8 位整数，甚至做剪枝——就像一个行李箱不够用时，只能把月饼压得更紧实。

内存报表告诉调度员：同样的月饼，货车能整箱拉，小电驴只能把箱子拆了重新打包。选平台前先算清“包裹体积”，否则模型在边缘端可能连加载都加载不进去。

M总=M权重+M激活+M运行时\displaystyle M_{\text{总}} = M_{\text{权重}} + M_{\text{激活}} + M_{\text{运行时}}
内存占用 = 固定的权重参数 + 随输入变化的激活缓冲 + 推理引擎的运行时开销。小模型在大平台上感受不到差异，大模型在边缘端则寸步难行。
  1. 总内存$M_{\text{总}}$ 是部署平台要为推理准备的全部内存，单位常用 GB 或 MB。
    M总M_{\text{总}}
  2. 权重与激活$M_{\text{权重}}$ 是模型参数的存储空间，$M_{\text{激活}}$ 是前向计算时中间张量的临时缓冲。
    M权重+M激活M_{\text{权重}} + M_{\text{激活}}
  3. 运行时开销$M_{\text{运行时}}$ 是推理引擎、算子库、内存池等固定的基础消耗，模型越小它占比越明显。
    M运行时M_{\text{运行时}}

吞吐量评估

派送员的考核指标不是“一趟多快”，而是“一小时能送多少个包裹”。这就是吞吐量——衡量系统在单位时间内能处理多少条请求。延迟看的是单件速度，吞吐量看的是整体流量，两者有关联，却不是一回事。

吞吐量的计算公式很直观：每秒吞吐量 = 批量大小 × 1000 ÷ 平均延迟（延迟单位为毫秒）。批量大小指一次推理同时塞进去多少条样本，GPU 一次能并行处理几十上百条样本，批量大自然吞吐惊人；CPU 一次只能处理十来条；移动端和 WebAssembly 更少。

这带来一个微妙的权衡：把批量调大，吞吐量会上升，但单条样本的延迟可能因为排队而变长。反过来，为了最低延迟而把批量设为 1，吞吐量反而上不去。所以在线高并发服务看吞吐量，单用户交互看延迟，两者要按业务场景取舍。

吞吐量报表回答了调度中心最关心的问题：这条路线一小时能吞吐多少货？GPU 是物流枢纽，CPU 是干线运输，移动端和 WASM 只能算末端配送——各司其职，不必强求。

Q=1000×BL平均\displaystyle Q = \dfrac{1000 \times B}{L_{\text{平均}}}
吞吐量 Q = 每秒处理的样本数，B 是批量大小，L 是平均单次推理延迟（毫秒）。批量越大、平均延迟越低，系统每秒能消化的请求就越多。
  1. 吞吐量 Q$Q$ 是 Throughput 的量化值，单位是“样本/秒”，直接决定一台服务器能扛多大流量。
    QQ
  2. 批量大小 B$B$ 是 Batch Size，即一次推理同时处理的样本条数，GPU 的优势就在能把 $B$ 拉得很大。
    BB
  3. 换算因子$\dfrac{1000}{L_{\text{平均}}}$ 把“每条样本多少毫秒”换算成“每秒能跑多少批”，毫秒转秒的 1000 就藏在这个分式里。
    1000×BL平均\dfrac{1000 \times B}{L_{\text{平均}}}

基准测试方法

调度中心要出对比报告，最忌讳“今天测一趟、明天再测一趟”的随意劲儿。月饼必须同一批、路线必须同一条、天气必须差不多，否则数据根本没法比。基准测试（Benchmark）就是给 AI 部署立的“统一度量衡”。

一套合格的基准测试包含四个要点：多轮取均值（跑 20 次甚至更多，把 CPU 频率波动、缓存冷热带来的随机抖动抹平）、控制变量（四个平台用同一个模型、同一份测试数据集、同一份编译配置）、统一数据（输入形状和精度保持一致）、报告加速比（用相对指标而不是绝对数字说话）。

加速比是基准测试最常用的输出：以某一平台为基准，S = 基准平台延迟 ÷ 目标平台延迟。如果以 CPU 为基准，GPU 的加速比约 2.7 倍，意味着同样的模型在 GPU 上快了近三倍；反过来以 GPU 为基准，WASM 的加速比小于 1，说明它比基准慢。相对指标比绝对数字更能说明“谁比谁快多少”。

一份严谨的基准测试报告，就像物流公司的“同货同路同标准”对比表。数据可以有噪声，但方法必须公平——否则你得出的结论连自己都说服不了。

S=L基准L目标\displaystyle S = \dfrac{L_{\text{基准}}}{L_{\text{目标}}}
加速比 S 是一个相对指标：S > 1 表示目标平台比基准平台更快，S < 1 则表示更慢。它是“以谁为参照系”的游戏，报告里必须写清楚基准是什么。
  1. 基准延迟$L_{\text{基准}}$ 是作为参照物的平台的延迟，通常选 CPU 这类“大众平台”当标尺。
    L基准L_{\text{基准}}
  2. 目标延迟$L_{\text{目标}}$ 是被测平台（比如 GPU 或 WASM）的延迟。
    L目标L_{\text{目标}}
  3. 比值含义$\dfrac{L_{\text{基准}}}{L_{\text{目标}}}$ 用除法消掉了模型的绝对规模，只留下平台间的相对快慢关系。
    S=L基准L目标S = \dfrac{L_{\text{基准}}}{L_{\text{目标}}}

平台优劣总结

每条配送路线都有自己的脾气。GPU 特快专线最快，但修铁路、养车队的电费和硬件成本高得惊人；CPU 干线大卡不快不慢、不挑路况，是最稳妥的万金油；移动端小电驴便携省电，可驮不了重货；WebAssembly 无人机免安装、随开随用，但载重和续航都受限。

把四个平台的优劣放到一张表上：GPU 的优势是低延迟、高吞吐，代价是高功耗、高成本；CPU 的优势是通用、均衡、生态成熟，代价是性能上限不如 GPU；移动端的优势是便携、省电、隐私好，代价是算力有限、内存紧张；WebAssembly 的优势是零安装、跨平台、数据不出浏览器，代价是峰值性能垫底。

工程选型的本质不是找“最快的平台”，而是找“性价比最高的平台”。我们可以定义一个简化的性价比指标：性价比 = 吞吐量 ÷（功耗 × 硬件成本）。GPU 吞吐最高，但分母里的电费和硬件成本同样巨大；移动端吞吐虽低，但功耗和成本几乎可以忽略——在手机这种场景里，它就是最优解。

优劣总结不是给平台排名次，而是给每一条路线贴标签。调度员心里有这本账：快有快的价签，省有省的代价，没有全能的路线，只有更匹配的路线。

C=QP×C硬件\displaystyle C = \dfrac{Q}{P \times C_{\text{硬件}}}
性价比 = 吞吐量 ÷（功耗 × 硬件成本）。这个式子告诉你：性能报表里的第一名不一定是账本上的第一名，要把代价算进去。
  1. 性价比 C$C$ 表示每一单位“功耗与成本”能换来的吞吐量，值越高越划算。
    CC
  2. 分子吞吐量$Q$ 是平台的吞吐能力，代表它能创造多少价值。
    QQ
  3. 分母代价$P \times C_{\text{硬件}}$ 是功耗与硬件成本的乘积，GPU 的大分母正是它“用不起”的根源。
    P×C硬件P \times C_{\text{硬件}}

选型决策指南

调度中心的墙上贴着三张决策卡：客户着急要货、预算不敏感，走 GPU 特快专线；客户要便宜、能等一会儿，走 CPU 干线大卡；客户在偏远地区、没法建配送站，走移动端小电驴或 WASM 无人机。选型决策，本质是把场景需求翻译成平台指标。

我们可以把这个决策过程写成加权打分：给每个平台算一个综合代价分数，取分数最小的平台。分数 = 延迟权重 × 该平台的延迟 + 内存权重 × 该平台的内存占用 + 能耗权重 × 该平台的能耗。不同业务设定的权重不同——在线客服把延迟权重拉满，智能手表把能耗权重拉满，浏览器插件则把内存权重拉满。

实践中的经验法则更直接：延迟敏感型在线服务（推荐、搜索、对话），选 GPU 服务器；边缘低资源场景（手机、IoT、浏览器），从移动端和 WASM 中二选一，前者偏原生性能、后者偏免安装覆盖；成本敏感的中等流量服务，CPU 服务器往往是最平衡的选择。TVM 的价值就在于：无论选哪条路，它都能把同一份模型“翻译”成那条路最擅长的代码，让性能对比在同一个起跑线上进行。

选型指南的终点，是让每个项目都能回答“为什么选这个平台”。有了延迟、内存、吞吐量的实测数据，再把场景权重摆上桌，调度员就不再凭感觉拍板，而是让数据替路线说话。

最优平台=arg⁡min⁡i(aLi+bMi+cEi)\displaystyle \text{最优平台} = \arg\min_{i} \left( a L_i + b M_i + c E_i \right)
选型可以量化：对每个平台计算“加权代价”，取最小者。权重 a、b、c 由业务场景决定，分别代表对延迟、内存、能耗的重视程度。
  1. argmin 符号$\arg\min_{i}$ 表示“在全部候选平台中，让括号里的值最小的那个平台 i”。
    arg⁡min⁡i\arg\min_{i}
  2. 三项代价$a L_i + b M_i + c E_i$ 把延迟、内存、能耗三个指标按权重加总成一个综合分。
    aLi+bMi+cEia L_i + b M_i + c E_i
  3. 权重系数$a, b, c$ 是业务场景给出的偏好——直播通话把 $a$ 调大，手环把 $c$ 调大，浏览器插件把 $b$ 调大。
    a,b,ca, b, c

AI 应用场景

在线商品推荐的低延迟推理服务

阶段：模型部署与在线推理服务

解决的问题：传统推荐系统用规则脚本拼接商品列表，响应虽快但个性化差；引入深度学习后，单条推理延迟直接决定用户体验。TVM 将模型编译为 GPU 算子并做算子融合，让毫秒级推荐成为可能。

具体案例：某电商平台大促期间，推荐模型 QPS 峰值达 20 万。通过 TVM 部署在 GPU 集群，批量推理配合算子融合，平均延迟稳定在 5ms 内，点击率提升 18%。

手机端实时人像分割

阶段：模型压缩与边缘端部署

解决的问题：视频通话美颜需要实时人像分割，上传云端有隐私泄露和网络延迟风险；移动端芯片算力小、内存有限。TVM 自动调优出 ARM 平台的 NEON 指令与异构调度方案，让模型在手机上流畅运行。

具体案例：某视频会议 App 在千元机上部署人像分割模型，内存占用从 1.2GB 压到 300MB，端侧离线推理延迟 25ms，达到 30 帧实时处理。

浏览器端 PDF 文档 OCR

阶段：前端零安装部署

解决的问题：传统 OCR 需要下载客户端或上传服务器，前者安装门槛高，后者有数据泄露风险。TVM 把模型编译成 WebAssembly，嵌入网页后本地完成识别，图片不出浏览器。

具体案例：某在线合同审核系统把版面分析模型编译为 WASM，2MB 的包体让用户打开网页即用，身份证号识别延迟约 180ms，全程数据不出浏览器。

Python 演示

python47 行
"""跨平台推理性能基准测试模拟器,基于TVM四平台对比经验数据"""import randomimport statistics PLATFORMS = {    "GPU": {"latency": 3.2, "memory": 2.5, "batch": 64},    "CPU": {"latency": 8.5, "memory": 1.0, "batch": 16},    "移动端": {"latency": 15.0, "memory": 0.4, "batch": 8},    "WebAssembly": {"latency": 22.4, "memory": 0.3, "batch": 4},}  def measure_latency(platform, noise=0.1):    """模拟一次推理的延迟,单位毫秒,带随机抖动"""    base = PLATFORMS[platform]["latency"]    return base * (1 + random.uniform(-noise, noise))  def benchmark(platform, rounds=20):    """对单个平台跑多轮基准测试,返回平均延迟与吞吐量"""    samples = [measure_latency(platform) for _ in range(rounds)]    avg = statistics.mean(samples)    batch = PLATFORMS[platform]["batch"]    throughput = batch * 1000 / avg  # 每秒处理的样本数    return {        "platform": platform,        "latency_ms": round(avg, 2),        "throughput": round(throughput, 1),        "memory_gb": PLATFORMS[platform]["memory"],    }  def compare():    """横向对比四个平台,输出报告并给出选型建议"""    results = [benchmark(p) for p in PLATFORMS]    results.sort(key=lambda r: r["latency_ms"])    print(f"{'平台':<12}{'延迟(ms)':>10}{'吞吐(样本/s)':>14}{'内存(GB)':>10}")    for r in results:        print(f"{r['platform']:<12}{r['latency_ms']:>10}{r['throughput']:>14}{r['memory_gb']:>10}")    fastest = min(results, key=lambda r: r["latency_ms"])    lightest = min(results, key=lambda r: r["memory_gb"])    print(f"\n低延迟首选:{fastest['platform']}")    print(f"低内存首选:{lightest['platform']}")  if __name__ == "__main__":    compare()
目的：模拟 TVM 四平台基准测试流程——对每个平台跑 20 轮推理取平均延迟，再结合批量大小计算吞吐量，最终输出对比报告和选型建议。
  1. measure_latency(platform, noise=0.1)用 random.uniform 给理论延迟加随机抖动，模拟真实环境中 CPU 频率波动、缓存冷热带来的噪声
  2. samples = [measure_latency(platform) for _ in range(rounds)]对同一平台跑 20 轮，对应正文里“多轮取均值”的基准测试方法
  3. avg = statistics.mean(samples)用平均值抹平单次测量的随机误差，这就是“多轮取均值抗噪声”
  4. throughput = batch * 1000 / avg正是正文公式 $Q = \dfrac{1000 \times B}{L_{\text{平均}}}$ 的代码实现
  5. results.sort(key=lambda r: r["latency_ms"])按延迟升序排列，输出顺序就是 GPU → CPU → 移动端 → WebAssembly

常见误区

误区性能对比报告里 GPU 延迟最低、吞吐最高，那还有啥好选的？把所有模型都丢到 GPU 上跑就行了！

正解GPU 虽快，但功耗大、显存贵、部署成本高。对小模型或边缘场景，GPU 是“杀鸡用牛刀”，甚至可能因为数据搬运开销而优势尽失。选型要看整体性价比 C = Q ÷（功耗 × 成本），不能只盯着峰值性能一个数字。

为何常见：对比报告往往只列延迟和吞吐两张表，初学者只看见最高的数字，看不见数字背后的电费单和硬件账单。

误区单次推理延迟是 10ms，那 1 秒自然能处理 100 个样本，所以延迟低必然吞吐高。

正解吞吐量还取决于批量大小和并发度。批量加大时单样本延迟可能变长，但总吞吐反而提升；反之延迟最低的配置（批量=1）往往吞吐并不高。延迟是“单件速度”，吞吐是“单位时间件数”，两者不能直接划等号。

为何常见：人容易把“单件耗时”直接换算成“每秒件数”，忽略了批量处理带来的排队等待——就像高速路上车多了，单车间距拉大但总车流反而更大。

误区WASM 延迟最高、吞吐垫底，排名倒数第一，说明它一无是处。

正解WASM 的价值不在绝对性能，而在零安装、跨平台、数据不出浏览器。对文档解析、图像预处理等中低负载场景，几百毫秒延迟完全可接受，还省去了下载客户端的成本。性能报表的垫底位置，恰恰是它“免安装”优势的代价。

为何常见：只看延迟排名表，不看部署场景与用户体验，就容易得出“性能差 = 没用”的绝对化结论。

误区我在 GPU 上跑了一次推理，耗时 3ms，于是写进 PPT：GPU 延迟 3ms。

正解单次测量受 CPU 频率波动、显存带宽争抢、缓存冷热的影响，抖动可能超过 ±10%。正确做法是固定同一模型、同一数据集、同一编译配置，跑 20 轮以上取均值，并用加速比做相对对比。

为何常见：中学物理“测一次取读数”的直觉根深蒂固，但计算机体系结构里有调度器、缓存、动态调频这些看不见的变量，一次读数几乎没有说服力。

面试题

Q1. 在 TVM 跨平台性能对比中，哪一平台通常拥有最低的推理延迟？

单选题 · easy

  • A.GPU 靠并行计算获得最低延迟← 正确答案
  • B.CPU 靠高频主频获得最低延迟
  • C.移动端靠省电设计获得最低延迟
  • D.Web 端靠即时编译获得最低延迟

答案：A。GPU 拥有数千个并行计算核心，矩阵运算能力最强，推理延迟通常最低，对应不等式 $L_{\text{GPU}} < L_{\text{CPU}} < L_{\text{移动端}} < L_{\text{WASM}}$ 的第一项。CPU 主频虽高但核心少，移动端优先省电，WebAssembly 受浏览器沙箱限制，均非延迟最优。

Q2. 关于 CPU 平台推理，下列说法正确的是哪一项？

单选题 · easy

  • A.完全不支持常见神经网络的推理
  • B.通用性强适配大量既有服务器← 正确答案
  • C.内存占用必定高于所有平台
  • D.延迟表现绝对差于移动端

答案：B。CPU 是不挑路况的“干线大卡”，绝大多数服务器都已配备，生态成熟、通用性强。它能做神经网络推理（只是不如 GPU 快），内存占用不一定最高，延迟通常比移动端和 WASM 更低。

Q3. 端到端推理延迟中的“传输开销”指的是下列哪一项？

单选题 · mid

  • A.模型训练时梯度传递的耗时
  • B.数据在内存与算力间搬运耗时← 正确答案
  • C.网络下载模型压缩包的时间
  • D.用户等待浏览器加载的响应

答案：B。延迟分解公式 $L_{\text{总}} = L_{\text{计算}} + L_{\text{传输}} + L_{\text{开销}}$ 中，传输开销指推理阶段数据在内存与计算单元之间的搬运耗时。训练梯度、下载模型、浏览器加载都属于部署之外的过程，不在推理延迟的统计范围内。

Q4. 某平台单次推理平均延迟为 10ms，批量大小设为 8，其吞吐量约为多少？

单选题 · mid

  • A.每秒约处理 80 个样本
  • B.每秒约处理 800 个样本← 正确答案
  • C.每秒约处理 8 个样本
  • D.每秒约处理 200 个样本

答案：B。根据吞吐公式 $Q = \dfrac{1000 \times B}{L_{\text{平均}}}$，代入 B=8、L=10ms：Q = 1000 × 8 ÷ 10 = 800 样本/秒。其他选项要么忘了乘批量大小，要么把毫秒换算搞错。

Q5. WebAssembly 部署的典型特点是下列哪一项？

单选题 · mid

  • A.内存占用小且可在浏览器运行← 正确答案
  • B.仅能运行在高性能专用服务器
  • C.必须预装重量级 Python 环境
  • D.强制外接加速卡才可完成推理

答案：A。WebAssembly 的优势是包体小、浏览器内零安装运行，内存占用在四平台中最小（约 0.3GB）。它恰恰不需要专用服务器、不需要 Python 环境、也不需要外接加速卡——“轻”就是它的立身之本。

Q6. 基准测试为什么要多轮取平均延迟？

单选题 · mid

  • A.减少随机抖动对数据的干扰← 正确答案
  • B.让模型训练轮数看起来很多
  • C.防止浏览器限制 WebAssembly
  • D.让 GPU 缓存失效从而更公平

答案：A。真实环境存在 CPU 频率波动、缓存冷热、显存带宽争抢等随机噪声，单次测量可能偏离真实水平 ±10% 以上。多轮取均值能抹平这些抖动，让测试结果更接近平台的“真实实力”。

Q7. 某在线客服系统对响应延迟极其敏感，应优先选择哪个平台部署？

单选题 · hard

  • A.GPU 服务器实现毫秒级快速响应← 正确答案
  • B.WebAssembly 浏览器即时加载
  • C.移动端芯片充分降低电量消耗
  • D.CPU 服务器平衡整体部署开销

答案：A。延迟敏感型业务应把延迟权重 a 调到最大，GPU 服务器以最低延迟胜出。WASM 适合免安装场景、移动端适合省电场景、CPU 适合成本敏感场景——它们各有分工，但都不是“最快响应”的第一选择。

Q8. 哪些平台适合边缘端低资源部署？

多选题 · easy

  • A.移动端芯片功耗内存双受限← 正确答案
  • B.桌面级 CPU 规模庞大功耗高
  • C.WebAssembly 包小且免安装← 正确答案
  • D.大型 GPU 集群吞吐量最高

答案：AC。低资源部署 = 小内存、低功耗、免运维。移动端芯片天然为此设计，WASM 包体小且零安装，都是边缘端常客。桌面 CPU 和大型 GPU 集群虽然性能强，但功耗、体积、成本都不符合“低资源”的前提。

Q9. 关于延迟与吞吐量的关系，正确的说法有哪几项？

多选题 · mid

  • A.降低单次延迟通常能提升吞吐量← 正确答案
  • B.增大批量未必改善单样本延迟← 正确答案
  • C.延迟与吞吐量完全没有关联
  • D.延迟越低吞吐量必然随之降低

答案：AB。由 $Q = 1000B/L$ 可知延迟 L 降低通常带来吞吐量 Q 提升，但增大批量 B 会引入排队等待，单样本延迟可能不降反升——所以 A、B 正确。C 否认两者关联、D 说反向关系，都是对公式的误读。

Q10. 模型推理时的总内存占用包含哪些部分？

多选题 · extreme

  • A.权重参数占据的存储空间← 正确答案
  • B.激活张量临时缓冲的区域← 正确答案
  • C.运行时框架固定的基础开销← 正确答案
  • D.训练数据集的标注人工成本

答案：ABC。内存公式 $M_{\text{总}} = M_{\text{权重}} + M_{\text{激活}} + M_{\text{运行时}}$ 的三项分别对应权重参数、激活缓冲、运行时框架。训练数据集的标注成本属于生产流程的人力开销，与推理阶段的内存占用无关，是典型的干扰项。