想象一家米其林大饭店要开一辆街头餐车：招牌菜“佛跳墙”需要一整面墙的厨具、三位厨师同时掌勺，可餐车只有几平米、一个灶台、一罐燃气。多模态大模型就是这道“佛跳墙”——它既能看懂图片、听懂语音，又能生成流畅的文字，在云端服务器里火力全开。但手机是辆小餐车：内存就这么大、电池就这么点、用户还没耐心。怎么办？聪明的工程师发明了四把“厨房改造”的扳手：砍掉菜单上没人点的菜（模型剪枝）、把高汤浓缩成料包（量化压缩）、提前备好常用食材（KV缓存优化）、顾客点什么才做什么（动态计算）。再用标准化的灶台设计（移动端推理框架）把它们串起来，最后走一遍试运营流程（部署路线）。读完这篇文章，你将拿到把大模型“装进口袋”的完整配方。

岗位关联

端侧部署是大模型从云端走向千行百业的“最后一公里”。掌握剪枝、量化、缓存与动态计算这套组合拳，你就能亲手把大模型装进用户的手机里——这是 AI 落地工程师最值钱的能力之一。

目录
  1. 可视化演示
  2. 部署挑战：餐车装不下满汉全席
  3. 模型剪枝：砍掉菜单上的冷门菜
  4. 量化压缩：浓缩高汤料包
  5. KV缓存优化：备菜不重做
  6. 动态计算：点啥做啥
  7. 移动端推理框架：标准化灶台
  8. 部署路线：试运营再开业
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

动态演示端侧多模态大模型部署方案的核心机制，通过架构/数据/状态/性能四种模式展示关键概念与交互流程。

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

端侧多模态大模型部署方案：端侧部署 端侧部署的三重约束分析 模型剪枝与轻量化策略 核心机制可视化 端侧多模态大模型部署方案整体架构与关键组件

部署挑战：餐车装不下满汉全席

米其林大饭店的后厨里，“佛跳墙”要占一整面墙的厨具，三位厨师同时掌勺才能出菜。多模态大模型就是这道硬菜——它能看图、听音、说话，可它的“厨房”是云端机房里一排排昂贵的 GPU 服务器。现在要让手机这辆小餐车也能出这道菜，第一件事不是搬厨具，而是量一量车厢到底能装下什么。

端侧部署，本质是把训练好的多模态大模型压缩、改造后放进手机 SoC（系统级芯片，也就是手机那颗“大脑”）。云端不够用可以加显卡，手机却不行：内存是焊死的、电池是有限的、处理器是固定的。这三条硬约束被称为“三堵墙”。

第一堵“内存墙”：一个 70 亿参数的模型，光权重就占好几个 GB，手机可用内存往往只有几 GB；第二堵“功耗墙”：模型一跑，手机发烫降频，续航断崖；第三堵“延迟墙”：用户点一次屏幕，超过两秒没反应就会关闭 App。综合起来，端侧内存占用可以写成下面的公式，它像一张“家当清单”：

这就像餐车改造前必须量好车厢：先数清楚总共多少家当、哪些调料最占地方，才能决定是扔东西、换小包装，还是改灶台。三堵墙摸清了，后面的四把扳手才有地方下手。

Mtotal=P×b8+MKV+MactM_{\text{total}} = \frac{P \times b}{8} + M_{KV} + M_{\text{act}}
  1. 总内存 M_total整个模型在端侧运行时的内存占用，单位是字节，相当于搬家前清点的全部家当体积。
    MtotalM_{\text{total}}
  2. 参数存储 P×b⁄8P 是参数量，b 是每个参数占用的比特数，除以 8 把比特换算成字节；FP32 就是每参数 4 字节。
    P×b8\frac{P \times b}{8}
  3. KV 缓存 M_KV模型解码时缓存下来的键值向量，对话越长越大，是“家当清单”里悄悄长大的部分。
    MKVM_{KV}
  4. 激活值 M_act前向计算中每层输出的临时张量，推理瞬间占用的一块“操作台”。
    MactM_{\text{act}}

模型剪枝：砍掉菜单上的冷门菜

大饭店的菜单有八十道菜，可翻看一个月的点单记录，七成菜根本没人点。餐车老板果断把菜单砍到十道招牌菜，出餐快、备料省、口碑还不掉——这就是剪枝的思路：把模型里“不重要的参数”删掉，让模型变轻。

神经网络里的参数就像菜谱上的字，有的字决定了口味，有的字纯属凑数。模型剪枝的任务就是找出这些凑数参数。如果把它们全部清零，叫“非结构化剪枝”——精度损失小，但稀疏矩阵在普通手机芯片上跑不出加速效果，等于菜谱变薄了，做菜时间却没变。于是工程师更常用“结构化剪枝”：按通道（一整列神经元）整体删除，直接改变模型的形状，硬件特别买账。

判断一个通道该不该留，常用 L1 范数打分：把这一列权重的绝对值加起来，总和越大说明它对输出的贡献越关键。再设定一个阈值，低于阈值就剪掉，公式像一个“淘汰赛规则”：

剪枝不是闭眼乱砍。就像删菜单前要翻点单记录，剪枝前也要做敏感度分析——把每层通道挨个剪一遍，看哪层砍了不掉精度、哪层一碰就崩。砍错的菜会砸招牌，剪错的层会让模型精度断崖式下跌。

mi={1,∥Wi∥1≥τ0,∥Wi∥1<τm_i = \begin{cases} 1, & \|W_i\|_1 \ge \tau \\ 0, & \|W_i\|_1 < \tau \end{cases}
  1. 掩码 m_i第 i 个通道的保留标记，1 表示留下，0 表示剪掉，相当于菜单上的“印/撕”决定。
    mim_i
  2. L1 范数 ‖W_i‖₁把该通道所有权重的绝对值相加，数值越大说明这个通道对输出的贡献越关键。
    ∥Wi∥1\|W_i\|_1
  3. 阈值 τ经过敏感度分析选出的裁剪线，低于这条线的通道直接删除；阈值越高，菜砍得越多，但味道也可能变淡。
    τ\tau

量化压缩：浓缩高汤料包

佛跳墙的高汤，饭店会熬成浓缩料包：体积只有原来的四分之一，加水一冲就能还原七八分味道。量化的思路如出一辙——把模型权重的“高汤”浓缩成“料包”。

模型权重出厂时是 FP32（32 位浮点数，每个数占 4 字节），像一口占地方的大汤锅。量化把这些连续浮点数映射到低比特整数（比如 INT8，占 1 字节），锅里只留精华刻度。最常用的是“均匀量化”：先看权重的取值范围，算出一个缩放因子 s，把范围均分成 255 个整数刻度，每个数四舍五入落到最近的刻度上：

不过料包兑水还原的味道，总归和现熬高汤有差距。训练后量化（PTQ）是直接拿现成模型浓缩，简单但可能掉精度；量化感知训练（QAT）则是在训练时反复“试喝”，让模型提前适应料包的口感。混合精度好比贵食材单独保鲜：对精度敏感的层保留 FP16，其余层大胆压到 INT8。料包省地方，但能不能上桌，得看配方调得对不对。

s = \frac{x_{\max} - x_{\min}}{2^{b} - 1}, \quadx_q = \operatorname{round}\left(\frac{x - z}{s}\right)
  1. 缩放因子 s数值范围除以量化等级数，决定每个整数刻度对应多大步长，相当于料包上“一包兑 500ml 水”的刻度。
    s=xmax⁡−xmin⁡2b−1s = \frac{x_{\max} - x_{\min}}{2^{b} - 1}
  2. 位宽 b量化比特数，b=8 时共有 255 个等级，b=4 时只有 15 个，等级越少料包越浓但越容易失真。
    2b−12^{b} - 1
  3. 量化值 x_q原始浮点值除以步长、四舍五入后的整数，之后推理全用这个整数计算，快且省。
    xq=round⁡(x−zs)x_q = \operatorname{round}\left(\frac{x - z}{s}\right)

KV缓存优化：备菜不重做

好厨师有个习惯：顾客还没点单，葱姜蒜已经切好码在灶台边。大模型的解码过程也一样——它生成每个新词时，都要把前面所有的词“重新看一遍”。如果不做任何准备，每炒一个菜都要从头切一遍葱姜蒜，时间全浪费在路上。

自回归解码是一个词一个词往外蹦的：每生成一个新 token（词元），都要重新关注之前所有的 token。KV 缓存就是提前把算好的 Key/Value 向量（注意力机制里的键值对，相当于切好的食材包）存在内存里，下次直接取用，不再重复计算。

但备菜不能无限备——缓存会随着对话变长而线性增长，挤占手机本就不多的内存。它的体积可以用下面这个公式估算，每一项都是一格“冷藏柜”：

灶台就那么大，备菜必须讲究取舍。端侧部署常用“缓存驱逐”策略：太旧的键值先清掉，最近对话的内容优先保留；还可以用低比特 KV 缓存压缩食材包。备菜不重做，也不能把仓库塞满——这正是缓存优化的精髓。

MKV=2×L×H×d×S×bM_{KV} = 2 \times L \times H \times d \times S \times b
  1. 系数 2（键值两份）每个 token 要同时存 Key 和 Value 两份向量，所以整体翻倍。
    22
  2. 层数 L模型有多少层 transformer，每一层都各有一份缓存，像每一层货架都要放食材。
    LL
  3. 注意力头数 H 与头维度 d多头注意力中，每个头独立计算和缓存自己的向量。
    H×dH \times d
  4. 序列长度 S对话越长，缓存越大，这是缓存增长的“主犯”。
    SS
  5. 每元素字节数 b每个元素占几个字节，用 4 比特低比特缓存能再省一半空间。
    bb

动态计算：点啥做啥

顾客点一盘拍黄瓜，十秒出菜；点佛跳墙，得耐心等四十分钟。聪明的餐车老板不会提前把满汉全席都做好摆着，而是看人下菜碟。可传统的大模型是个“实诚老板”：不管输入多简单，都得把全部几百层网络走一遍，让所有顾客都等佛跳墙的时间。

大模型的输入难度天差地别：识别一张门牌号照片很简单，理解一张复杂数据图表却很难。动态计算的核心思想就是：根据输入难度自适应选择计算路径，简单的走快线，复杂的走慢线。

三种主流实现方式里，“早退出”最直观：在模型的浅层加一个小分类器，先看它对当前输入的把握有多大。如果置信度够高，直接返回结果，不再往下走深层。判断公式像一个“快线放行条”：

除了早退出，动态路由和投机采样也是“看人下菜碟”的变体：动态路由只激活最相关的专家子网络，投机采样让小模型先草拟答案、大模型快速验证。就像餐车备好“快菜档”和“慢炖档”两条灶线，简单的活不让大厨亲自上手，整体平均出餐时间自然大幅下降。

exit(x)=1[max⁡ipi(x)≥θ]\text{exit}(x) = \mathbf{1}\left[\max_{i} p_i(x) \ge \theta\right]
  1. 概率输出 p_i(x)浅层分类器对第 i 个类别的预测概率，表示模型此时“觉得”答案有多靠谱。
    pi(x)p_i(x)
  2. 最大概率 max p_i取所有类别中最大的概率，代表模型对当前输入的总体把握。
    max⁡ipi(x)\max_{i} p_i(x)
  3. 阈值 θ 与指示函数最大概率超过阈值 θ 就放行（值为 1，提前退出），否则值为 0，继续走深层精算。
    1[⋅≥θ]\mathbf{1}\left[\cdot \ge \theta\right]

移动端推理框架：标准化灶台

餐车空间小，灶台、货架、水管全靠标准化设计，厨师才能在方寸之间游刃有余。模型压缩得再瘦，没有一套顺手的“灶台”也是白搭——移动端推理框架干的正是这个活。

像 MNN、NCNN 这类移动端框架，相当于一支“装修队”：把模型的计算图重新改造，适配手机 CPU/GPU/NPU（神经网络处理器）各自的硬件脾气。模型原来在云端 GPU 上怎么算，到了手机不能原样照搬，得按手机芯片的算子库重新编排。

框架最核心的招数是算子融合与图优化：把互相衔接的小算子合并成一个大算子，减少中间结果的搬运。端侧推理还常被“内存带宽”卡脖子——模型权重从内存搬到计算单元的速度，可能比计算本身还慢，推理时延可以用这个公式估算：

多模态模型在端侧还要做“多模态对齐”：视觉编码器把图片变成特征向量，交给文本解码器生成回答，就像配菜间和炒灶要接成流水线。框架把这条流水线焊死，避免图像和文本在内存里来回倒手——灶台标准化了，出餐速度才有保障。

T≈MweightBmemory+TcomputeT \approx \frac{M_{\text{weight}}}{B_{\text{memory}}} + T_{\text{compute}}
  1. 权重体积 M_weight每轮推理需要从内存读入的模型权重字节数，模型越瘦，这笔搬运费越省。
    MweightM_{\text{weight}}
  2. 内存带宽 B_memory手机内存每秒能搬运的字节数，相当于餐车进货通道的宽度。
    BmemoryB_{\text{memory}}
  3. 计算耗时 T_compute权重到位后，算力真正干活的时间；带宽不够时第一项会远大于第二项。
    TcomputeT_{\text{compute}}

部署路线：试运营再开业

新餐车上路前要试运营：先试菜，再改装车厢，上街巡游一圈，收集食客反馈后改菜单，最后才正式开业。端侧部署同样不是“把文件拷进手机”一步到位，而是一条环环相扣的流水线。

完整路线分四步：模型评估、压缩适配、端侧测试、灰度迭代。第一步先定目标——这个多模态模型要在什么场景跑、能容忍多少精度损失；第二步做压缩适配，在剪枝、量化、缓存优化、动态计算之间挑组合；第三步拿到真机上压测，看内存、功耗、延迟的真实表现；第四步小流量灰度上线，持续收集反馈迭代。

压缩方案五花八门，怎么科学地选？工程上常用一个综合评分来权衡精度、速度和体积，每一项乘以权重系数，像餐车评选“最优菜单”的打分表：

灰度迭代就像餐车先在小巷试卖一周：反馈好就扩大营业，反馈差就回炉重造。没有一条路线是放之四海皆准的，只有用真机数据说话，不断在精度、速度、功耗之间走钢丝，才能找到那道最适合你的“端侧招牌菜”。

Score=α×ACCrel−β×Tlatency−γ×Msize\text{Score} = \alpha \times \text{ACC}_{\text{rel}} - \beta \times T_{\text{latency}} - \gamma \times M_{\text{size}}
  1. 相对精度 ACC_rel压缩后模型相对原始模型的精度保持率，相当于食客对菜品的满意度。
    ACCrel\text{ACC}_{\text{rel}}
  2. 推理延迟 T_latency端侧单次推理耗时，越短越好，所以前面是减号。
    TlatencyT_{\text{latency}}
  3. 模型体积 M_size最终安装包里的模型大小，直接决定用户下载意愿和内存占用。
    MsizeM_{\text{size}}
  4. 权重系数 α/β/γ根据业务场景手动调节的偏好，比如车载场景更看延迟，离线翻译更看体积。
    α,β,γ\alpha, \beta, \gamma

AI 应用场景

手机端离线图文问答助手

阶段：模型压缩与端侧部署

解决的问题：传统云端图文问答依赖网络，弱网环境卡顿、有隐私泄露风险；AI 助手先用剪枝把 7B 级多模态模型砍到 3B 级，再用 INT8 量化把体积压到 2GB 以内，最后通过 KV 缓存优化长对话场景，让“拍照识物、语音提问”全程离线完成。

具体案例：某翻译 App 推出“拍照识物”功能，端侧跑压缩后的多模态模型，用户对着小区植物拍照，0.8 秒内返回名称和养护建议，全程无网络请求，数据不出手机。

智能眼镜实时翻译与导览

阶段：动态计算与端侧推理框架

解决的问题：智能眼镜电池只有几百毫安时，全量推理撑不过半小时；通过早退出机制让简单指令（“接下来往哪走”）走快线、复杂场景（“分析这幅名画”）走慢线，配合算子融合框架把功耗降低 60%，续航提升到全天。

具体案例：博物馆智能导览眼镜在游客注视展品时启动多模态识别，轻度场景下用浅层网络快速返回展品名，深度讲解时才唤醒完整大模型，镜片温度始终控制在 38 度以内。

车载语音助手离线导航

阶段：KV缓存优化与部署路线验证

解决的问题：车载场景对话长、环境嘈杂，云端交互时延不稳定；通过 KV 缓存复用历史上下文，减少重复计算，冷启动时间从 3 秒压到 0.5 秒，再按“评估→压测→灰度”路线在真车上完成功耗与稳定性验证。

具体案例：某国产新能源车型的语音助手在隧道、地库等无网路段照常工作，支持连续多轮指令（“导航去机场”“换条不堵的路”），缓存命中率高达 87%，单轮响应快于云端。

Python 演示

python78 行
# -*- coding: utf-8 -*-"""端侧部署模拟: 剪枝 + 量化 压缩小型MLP, 并对比精度与体积"""import numpy as np  def make_data(n=1024, dims=16, seed=0):    rng = np.random.default_rng(seed)    x = rng.normal(size=(n, dims))    y = (x[:, 0] * x[:, 1] + x[:, 2] > 0).astype(np.int64)    return x, y  class SmallMLP:    def __init__(self, dims=16, hidden=32, seed=0):        rng = np.random.default_rng(seed)        self.w1 = rng.normal(scale=0.5, size=(dims, hidden))        self.b1 = np.zeros(hidden)        self.w2 = rng.normal(scale=0.5, size=(hidden, 2))        self.b2 = np.zeros(2)     def forward(self, x):        h = np.maximum(x @ self.w1 + self.b1, 0)        logits = h @ self.w2 + self.b2        return logits.argmax(axis=1)  def accuracy(model, x, y):    return float((model.forward(x) == y).mean())  def l1_prune(model, ratio=0.3):    score = np.abs(model.w1).sum(axis=0)    thr = np.quantile(score, ratio)    keep = score > thr    model.w1 = model.w1[:, keep]    model.b1 = model.b1[keep]    model.w2 = model.w2[keep, :]    return int(keep.sum())  def quantize_int8(w):    lo, hi = float(w.min()), float(w.max())    scale = (hi - lo) / 255.0    q = np.round((w - lo) / scale)    q = np.clip(q, -128, 127).astype(np.int8)    return q, scale, lo  def dequantize(q, scale, zero):    return q.astype(np.float32) * scale + zero  def main():    x, y = make_data()    model = SmallMLP()    acc0 = accuracy(model, x, y)    full_params = model.w1.size + model.w2.size + model.b1.size + model.b2.size     keep = l1_prune(model, 0.3)    acc1 = accuracy(model, x, y)     w1q, s1, z1 = quantize_int8(model.w1)    w2q, s2, z2 = quantize_int8(model.w2)    model.w1 = dequantize(w1q, s1, z1)    model.w2 = dequantize(w2q, s2, z2)    acc2 = accuracy(model, x, y)     cur_params = model.w1.size + model.w2.size + model.b1.size + model.b2.size    size_full = full_params * 4    size_now = (model.w1.size + model.w2.size) * 1 + (model.b1.size + model.b2.size) * 4    print("原始fp32精度: %.4f" % acc0)    print("剪枝后精度: %.4f (保留%d个隐藏单元)" % (acc1, keep))    print("int8量化后精度: %.4f" % acc2)    print("权重体积: %.2fKB -> %.2fKB (%.2fx)" % (size_full / 1024, size_now / 1024, size_full / size_now))  if __name__ == "__main__":    main()
目的：用纯 numpy 模拟端侧部署中最核心的两步——L1 结构化剪枝和 INT8 均匀量化，直观对比压缩前后的精度与体积变化。
  1. score = np.abs(model.w1).sum(axis=0)按 L1 范数给每个隐藏通道做重要性打分，对应正文中“翻点单记录”。
  2. thr = np.quantile(score, ratio)用分位数确定剪枝阈值，砍掉得分最低的 30% 通道。
  3. model.w1 = model.w1[:, keep]结构化剪枝：直接删除整列通道，模型形状变小。
  4. scale = (hi - lo) / 255.0计算 INT8 均匀量化的缩放因子，对应“料包刻度”。
  5. q = np.clip(q, -128, 127).astype(np.int8)四舍五入后截断到 int8 范围，完成仓储。
  6. model.w1 = dequantize(w1q, s1, z1)反量化还原权重，验证量化后的精度损失。

常见误区

误区我听说剪枝就是把权重里绝对值最小的那些直接置零，剪得越多模型越轻，剪掉 90% 参数应该也能用。

正解把单个权重清零是非结构化剪枝，它确实省参数，但手机 CPU/GPU 算稀疏矩阵并不快，等于菜谱变薄了做菜时间却没变。端侧更看重结构化剪枝——把整个通道、注意力头成块删除，模型形状直接变小，硬件才能真正加速。另外，每层对剪枝的敏感度不同，必须逐层做敏感度分析，蒙头乱剪会让精度断崖式下跌。

为何常见：论文里常说“小权重不重要”，初学者容易只盯着权重数值，忽略了硬件结构和层的敏感度差异这两个关键约束。

误区模型量化后准确率下降了 0.5%，看来量化这条路走不通，还是老老实实跑 FP32 吧。

正解训练后量化（PTQ）精度损失大，可以换成量化感知训练（QAT）——在训练时就模拟量化误差，让模型提前适应“料包口味”，往往能把损失拉回来。还可以用混合精度，只把最敏感的层保留 FP16，其余层大胆压到 INT8。更重要的判断标准是下游任务的实际表现，而不是单个离线指标。

为何常见：把离线评测精度当成唯一标准，忽略了量化方案是一个可调优的集合，而不是非黑即白的开关。

误区KV 缓存能避免重复计算，那我把历史上所有对话内容都缓存下来，反正缓存命中率越高越省时间。

正解KV 缓存的体积随序列长度线性增长（公式里乘的 S 就是对话长度），缓存全留会把手机内存挤爆，甚至直接 OOM。端侧通常做定长缓存加驱逐策略，或者用 4 比特低比特缓存，在命中率和内存占用之间找平衡——就像灶台只放最近要用的食材，不是把整个仓库搬上车。

为何常见：因为缓存命中率这个指标很直观，让人忽略了“内存是有限的”这个端侧最残酷的现实。

误区压缩完的模型权重拿到手，直接拷进手机 App 的 assets 目录，点开就能跑了吧？

正解权重文件只是半成品。还得用移动端推理框架做算子适配、计算图优化、内存池设计；多模态模型还要把视觉编码器和文本解码器串成高效流水线。不同手机芯片（高通、联发科、苹果）的 NPU 算子各不相同，同一份模型要分别适配。这就像拿到一辆改装好的餐车，还得重新规划灶台和货架才能出餐。

为何常见：看到演示视频里手机流畅跑模型，以为只是“文件拷贝”一步，忽略了背后庞大的框架工程。

误区端侧部署的目标就是让推理越快越好，速度快到极致就成功了，其他都不用管。

正解端侧是内存、功耗、延迟的三角平衡。一味追求速度可能把功耗拉爆，手机发热降频后反而更卡，续航也崩。正确的做法是用综合评分（精度、延迟、体积、功耗加权）来选方案，比如智能眼镜场景里，省电比快 10 毫秒重要得多。

为何常见：云端部署习惯了“延迟优先”的思维，忘了手机是电池驱动的移动设备，温度和续航同样是硬指标。

面试题

Q1. 端侧多模态大模型部署的三大核心约束是什么？

单选题 · easy

  • A.内存、功耗和延迟← 正确答案
  • B.价格、品牌和外观
  • C.算子、框架和接口
  • D.数据、标签和算力

答案：A。端侧芯片的内存焊死、电池有限、用户等待耐心有限，所以内存墙、功耗墙、延迟墙是三大核心约束。价格品牌是商业因素，算子框架是手段而非约束，数据标签算力是训练阶段的三要素，均与部署约束无关。

Q2. 结构化剪枝相比非结构化剪枝的主要优势是什么？

单选题 · easy

  • A.完全没有精度损失
  • B.对硬件更友好易加速← 正确答案
  • C.不需要做任何重训练
  • D.比非结构化更省参数

答案：B。结构化剪枝按通道或注意力头整块删除，模型形状变小，CPU/GPU/NPU 都能直接受益，就像删掉整道菜能加快出餐。非结构化剪枝逐个权重清零虽然省参数，但稀疏矩阵在普通硬件上加速有限。结构化剪枝同样会有精度损失，也可能需要重训练恢复精度。

Q3. 一个 70 亿参数的多模态模型用 FP32 存储，权重部分约占用多少内存？

单选题 · mid

  • A.约 0.7GB
  • B.约 2.8GB
  • C.约 7GB
  • D.约 28GB← 正确答案

答案：D。FP32 每个参数占 4 字节，70 亿参数即 7×10⁹×4=2.8×10¹⁰ 字节，按十进制换算约 28GB。这也是为什么必须做量化压缩——压到 INT8 后能降到约 7GB，再配合剪枝才能塞进手机。

Q4. 均匀量化中缩放因子 s 的作用是什么？

单选题 · mid

  • A.控制量化后的位宽
  • B.映射浮点到整数刻度← 正确答案
  • C.只对激活值生效
  • D.消除所有精度损失

答案：B。缩放因子 s 由取值范围除以量化等级数得到，决定每个整数刻度对应浮点的步长，相当于料包上“一包兑多少水”的刻度。位宽由 b 决定而非 s；s 对权重和激活都生效；量化必然有精度损失，无法完全消除。

Q5. KV 缓存优化的核心目的是什么？

单选题 · mid

  • A.减少模型参数量
  • B.免重复计算历史← 正确答案
  • C.提高训练收敛速度
  • D.增加序列长度上限

答案：B。自回归解码每生成一个新词元都要重新关注历史 token，KV 缓存把算好的键值向量存下来，下次直接取用，避免重复计算。它不改变参数量，作用在推理阶段而非训练阶段，且缓存本身就占内存，反而会挤压序列长度上限。

Q6. 早退出机制最适合处理哪类输入？

单选题 · mid

  • A.所有输入都走深层
  • B.浅层置信度高的输入← 正确答案
  • C.图像输入而非文本输入
  • D.需要长回答的输入

答案：B。早退出在浅层加分类器，置信度超过阈值就返回结果，天然适合“简单问题快答”的场景，比如识别门牌号。所有输入走深层等于没优化；早退出与模态无关；需要长回答的输入通常更复杂，恰恰不适合早退。

Q7. 手机内存带宽为 25GB/s，一个 INT8 量化后权重体积 2GB 的模型，每轮推理只读一次权重，理论时延下限约是多少？

单选题 · hard

  • A.约20ms
  • B.约80ms← 正确答案
  • C.约200ms
  • D.约2000ms

答案：B。根据 T≈M_weight/B_memory，2GB÷25GB/s=0.08s=80ms。这是带宽受限时的理论下限，实际还会加上计算耗时。这也解释了为什么量化对端侧如此重要——权重体积减半，时延下限就减半。

Q8. 下列哪些属于动态计算的实现方式？

多选题 · mid

  • A.早退出机制← 正确答案
  • B.动态路由← 正确答案
  • C.投机采样← 正确答案
  • D.权重共享

答案：ABC。早退出让简单输入浅层返回，动态路由按输入激活部分专家网络，投机采样用小模型草拟大模型验证，三者都是“按需计算”的体现。权重共享是参数复用手段，属于模型结构设计，不属于动态计算。

Q9. 移动端推理框架常用的优化手段包括哪些？

多选题 · hard

  • A.算子融合← 正确答案
  • B.计算图优化← 正确答案
  • C.增加模型参数量
  • D.异构调度← 正确答案

答案：ABD。算子融合把小算子合并成大算子减少内存搬运，图优化重排计算顺序，异构调度把不同算子分配到 CPU/GPU/NPU 上各展所长——这三者是端侧框架的看家本领。增加参数量只会让部署更难，与优化方向相反。

Q10. 端侧部署完整路线包含哪些步骤？

多选题 · mid

  • A.模型评估与选型← 正确答案
  • B.压缩与适配改造← 正确答案
  • C.端侧的AB测试← 正确答案
  • D.删除全部缓存数据

答案：ABC。标准路线是“评估选型→压缩适配→端侧测试→灰度迭代”，AB 测试属于端侧测试阶段的验证手段。删除缓存数据没有任何意义，反而会破坏 KV 缓存优化成果，是典型的干扰项。