想象你花半年时间精心设计了一套大别墅：挑高客厅、智能家电、宽敞衣帽间——这就是云端训练出的深度学习模型，动辄数百MB。但今天，用户递来一块指甲盖大小的MCU芯片，说：“请让AI住进去。” 它的“卧室”只有几十KB内存。这听起来像天方夜谭，但TVM微模型部署正是解决这个问题的专业“搬家公司”。它把模型视作家具：先用真空压缩袋压扁羽绒服（INT8量化），再把沙发和床合并成沙发床（算子融合），最后像日式收纳师一样规划每一寸空间（内存复用）。读完这篇文章，你会理解如何把AI大别墅改造为能在MCU小公寓里安居的微模型，并掌握跨平台部署的完整链路。

岗位关联

掌握微模型部署，你就具备了把AI落地到MCU、传感器等边缘设备的工程能力——这是物联网和嵌入式AI产品从原型走向量产的关键一环。

目录
  1. 可视化演示
  2. 部署概述：为什么要搬到小公寓
  3. 模型压缩：给行李减负
  4. 算子融合：多功能家具的智慧
  5. 内存优化：小户型的收纳艺术
  6. MicroTVM架构：专业搬家公司
  7. 跨平台部署流程：搬家四步曲
  8. 边缘场景应用：新家的幸福生活
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示模型压缩流水线、内存优化对比与跨平台部署架构，切换模式查看边缘部署的不同优化环节。

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

压缩流水线：FP32到MCU级模型 INT8量化将模型从100%压缩到50% 算子融合+优化最终降至18% 压缩率 = 优化后体积 / 原始体积 多级压缩使模型适配MCU资源限制

部署概述：为什么要搬到小公寓

你花半年精心装修的大别墅突然被通知要拆掉，取而代之的是楼下12平米的杂物间——这就是深度学习模型从云端走向MCU芯片的真实处境。云端GPU服务器是你的大别墅，模型权重动辄上百MB；而MCU微控制器，那块能放进笔帽的芯片，只有几十KB内存。要在这种设备上运行模型，不亚于把一整套家具塞进一个旅行箱。

好在TVM的MicroTVM项目正是这场“搬家工程”的总承包商。所谓微模型部署，就是把训练好的模型压缩、优化、重组，最终编译成能在MCU上运行的机器码。它的核心目标可以浓缩为三句话：放得下、跑得起、稳得住。放得下指模型参数和运行时占用必须小于Flash和RAM；跑得起指推理延迟满足实时性要求；稳得住指功耗和数值稳定性达标。

围绕这三个目标，TVM给出了三条技术路径：INT8量化把参数体积压缩四分之三，算子融合把中间结果的存储开销降到最低，内存规划则让有限的RAM被反复复用。三者合起来，才让一个几万参数的图像分类模型在几十KB内存的MCU上跑起来成为可能。首先需要算一笔账：模型到底占多大？

所以搬家顾问的第一条建议永远是：先量化评估“哪些家具必须带、哪些可以换成压缩版”，先算出总重量，后面的打包方案才有依据。这也是为什么TVM的优化链中，参数统计和内存估算总是最先执行的两个Pass。

F=Ptotal×bF = P_{\text{total}} \times b
模型占用的存储空间 = 参数量 × 每个参数所需字节数，就像行李总重量 = 物品件数 × 单件重量。
  1. 参数总量把网络每一层参数量加起来，就像清点别墅里所有家具的总件数。
    Ptotal=∑l=1LPlP_{\text{total}} = \displaystyle\sum_{l=1}^{L} P_l
  2. 单参数字节数FP32格式下每个参数占4字节，INT8只占1字节，相当于每件家具从4立方米缩到1立方米。
    bb
  3. 模型存储占用家具总件数乘以单件体积，就是整体占用。
    F=Ptotal×bF = P_{\text{total}} \times b
  4. 量化收益位宽从32位降到8位，占用自然缩小4倍。
    Fint8=Ffp324F_{\text{int8}} = \dfrac{F_{\text{fp32}}}{4}

模型压缩：给行李减负

搬家时最占空间的是衣物棉被，而真空压缩袋能像抽去空气一样把羽绒服压成薄片。深度学习模型的FP32权重就是“蓬松的羽绒服”——每个数用32位表示，很多位其实是冗余的。INT8量化正是那台真空压缩机，它把32位浮点权重映射到8位整数范围[-128, 127]。为什么能这么干？因为权重分布通常集中在一个小区间，只需要一把“尺子”（scale）和一个“刻度原点”（zero point），就能把连续实数换算成整数刻度。

TVM在做图优化时，会在计算图中自动插入量化和反量化节点，让模型保持“数值上近似、存储上紧凑”。精度损失通常很小，因为scale是逐层校准的，专门适配每一层权重的真实分布。量化前后的映射关系由下面的公式表达：scale决定整数刻度之间的“宽度”，zero point决定整数刻度的“原点”。

真空压缩袋会让羽绒服稍微“变形”，但展开后照样保暖。INT8量化也一样：压缩后的权重虽然不完全等于原值，但对图像分类、关键词识别这类任务，TVM逐层校准后的精度损失通常控制在千分之一以内——小公寓里的生活品质并没有因此打折扣。

q=round(rscale)+zq = \text{round}\left(\frac{r}{\text{scale}}\right) + z
量化把连续的实数映射到离散的整数，就像用标准刻度尺把窗帘长度换算成精确到厘米的整数。
  1. 缩放因子把实数范围均匀压缩到整数范围的“比例尺”，它决定了每个整数刻度代表多少实数。
    scale=rmax−rminqmax−qminscale = \dfrac{r_{max} - r_{min}}{q_{max} - q_{min}}
  2. 归一化去掉比例尺，把实数换算到整数刻度坐标系，就像用尺子量出布料对应几格刻度。
    rscale\dfrac{r}{scale}
  3. 四舍五入把小数收成整数，就像把散钱换成整钞，必然舍弃零头。
    round(⋅)\text{round}\left(\cdot\right)
  4. 零点偏移修正实数区间的起点不在零点的情况，确保映射不会整体偏移。
    z=qmin−rminscalez = q_{min} - \dfrac{r_{min}}{scale}
  5. 量化映射加回零点偏移，得到最终落在 [-128, 127] 区间的INT8整数。
    q=round(rscale)+zq = \text{round}\left(\dfrac{r}{scale}\right) + z

算子融合：多功能家具的智慧

在小公寓里，最浪费空间的是走廊——它不能放东西，却每天要走好几趟。模型推理中的“走廊”就是相邻算子之间传递的中间结果。以Conv+ReLU为例，卷积层输出的特征图要完整写进内存，ReLU再把它读出来处理，这一写一读，就像把行李从客厅搬到走廊再搬回来。

TVM的算子融合优化，相当于把走廊直接拆掉：卷积输出的每个元素算完后立即送入ReLU，根本不用落地。这样既省了内存空间，又省了读写时间。在MCU上，内存访问的代价常常比计算本身还要昂贵，这项优化的价值因此被放得更大。

融合能省下多少内存，关键看被消除的中间特征图有多大。它由特征图的高、宽、通道数和数据类型共同决定：

沙发床让客厅既宽敞又实用，融合后的算子也让MCU的“客厅”少堆一件巨型家具，内存留给真正必须保留的中间结果。除Conv+ReLU外，常见的融合还有“卷积+批归一化”、“全连接+Softmax”等，本质思路完全相同——能合到一起的家具，绝不分开摆。

Msaved=Cout×H×W×bM_{\text{saved}} = C_{\text{out}} \times H \times W \times b
融合省下的内存 = 中间特征图的通道数 × 高度 × 宽度 × 每元素字节数。
  1. 输出通道数卷积层输出的通道数，相当于特征图的“厚度”。
    CoutC_{\text{out}}
  2. 空间尺寸中间特征图的高和宽，对应“长和宽”。
    H×WH \times W
  3. 数据类型每元素占用的字节数，FP32为4，INT8为1。
    bb
  4. 省下的内存中间特征图若写进内存所需占用的总空间。
    Msaved=Cout×H×W×bM_{\text{saved}} = C_{\text{out}} \times H \times W \times b

内存优化：小户型的收纳艺术

小公寓收纳的秘诀是“错峰使用”：冬天的棉被和夏天的凉席不会同时用，放进同一个衣柜就没问题。模型的中间张量也是这样——张量A算完就被“消费”掉，张量B这时才“出生”，两者从不共存，于是可以共享同一块内存。

TVM的内存规划器会先做活性分析：给每个中间张量标注生命周期，从哪个算子产生，到哪个算子被消费完。然后像排课表一样，把生命周期不重叠的张量安排进同一块缓冲。目标只有一个：让任意时刻的内存占用峰值尽量小。同时，TVM还会做张量布局转换，比如把通道优先还是像素优先的存储顺序调整为更适合目标CPU的模式，减少内存碎片、提升访存局部性。

峰值内存是衡量内存规划效果的关键指标，它等于所有时刻中，每一时刻“还活着”的张量占用的内存总和的最大值：

收纳师不会把所有季节的衣服同时铺开，而是按使用时间错开堆放。TVM的内存规划器干的就是这件事——给每个张量安排“储物格”，同一格在不同时间存放不同张量。于是，几十KB的RAM里竟然运转起原本需要几百KB的模型，这就是收纳艺术的威力。

Mpeak=max⁡t∈[1,T]∑i∈L(t)miM_{\text{peak}} = \max_{t \in [1,T]} \sum_{i \in L(t)} m_i
峰值内存 = 所有时刻中，任意时刻同时“存活”张量的内存总和的最大值。
  1. 生命周期集合在 t 时刻还活着的张量集合，s_i 和 e_i 分别是张量 i 的出生与死亡时间。
    L(t)={i∣si≤t≤ei}L(t) = \{ i \mid s_i \leq t \leq e_i \}
  2. 时刻总占用把 t 时刻所有活着的张量内存加起来。
    M(t)=∑i∈L(t)miM(t) = \sum_{i \in L(t)} m_i
  3. 取峰值遍历所有时刻，找到内存最紧张的那个瞬间。
    Mpeak=max⁡tM(t)M_{\text{peak}} = \max_{t} M(t)
  4. 复用收益通过共享缓冲，让实际峰值进一步降低。
    M复用≤MpeakM_{\text{复用}} \leq M_{\text{peak}}

MicroTVM架构：专业搬家公司

搬家不是把东西扔进卡车就完事。专业搬家公司有评估、打包、运输、拆装的标准流程，而且只带必要的工具——每多一件工具，油耗就多一点。TVM的MicroTVM就是这样一家“AI模型搬家公司”，它的服务对象是MCU这样资源极度紧张的小公寓。

MicroTVM是TVM编译框架面向微控制器的扩展。它复用TVM成熟的图解析与Pass优化能力，同时在代码生成阶段面向MCU目标产出精简C源码，并配上一套极简运行时。整个部署包由三部分组成，每一部分都必须严格控制在Flash预算内：

MicroTVM还提供了调试工具，可以通过USB连接宿主机和MCU，像调试云端程序一样在真机上设置断点、观察张量内容——这就是搬家公司提供的“入住验收”服务，确保模型真的在芯片上运行，而不是纸上谈兵。

Sdeploy=Sruntime+Scodegen+SparamsS_{\text{deploy}} = S_{\text{runtime}} + S_{\text{codegen}} + S_{\text{params}}
部署包总大小 = 运行时基础 + 生成算子代码 + 模型参数量，三者之和必须小于Flash容量。
  1. 精简运行时包含内存分配器、调度器、硬件抽象，目标控制在几KB内。
    SruntimeS_{\text{runtime}}
  2. 生成算子代码TVM针对目标CPU生成的算子实现，只编译模型实际用到的部分。
    ScodegenS_{\text{codegen}}
  3. 模型参数量化后的权重字节数，等于参数量乘以每个参数的字节数。
    Sparams=Ptotal×bS_{\text{params}} = P_{\text{total}} \times b
  4. 总包预算三部分总和必须小于目标MCU的Flash空间，否则部署方案不成立。
    Sdeploy=Sruntime+Scodegen+SparamsS_{\text{deploy}} = S_{\text{runtime}} + S_{\text{codegen}} + S_{\text{params}}

跨平台部署流程：搬家四步曲

一次成功的搬家讲究流程：先上门评估，再分房间打包，然后装车运输，最后在新家拆包验收。TVM的部署流程同样是四步走，每一步都有明确的输入和输出：模型导入、编译优化、代码生成、烧录部署。

把模型从框架格式变成MCU可执行文件，开发者只需写几行Python调用Relay API，就能完成端到端编译。跨平台的秘密在于：同样的优化流程可以被不同后端的代码生成器复用。换一块芯片，只需要换目标参数和工具链——就像搬家公司的标准化流程，换一辆卡车照样能干活。

整个流程的耗时估算如下。编译优化往往是最耗时的一步，但它只发生在开发期，不影响设备的运行时性能：

整个搬家过程分四步，每一步都是“一间房一间房地打包”，但最终目标只有一个：让模型在小公寓里安顿下来并开始工作。而因为流程标准化，下次换一套房子（换一块芯片），同样四步就能搞定。

Ttotal=Timport+Topt+Tcodegen+TflashT_{\text{total}} = T_{\text{import}} + T_{\text{opt}} + T_{\text{codegen}} + T_{\text{flash}}
部署总耗时 = 模型导入 + 编译优化 + 代码生成 + 烧录部署 四个阶段的累加。
  1. 模型导入解析ONNX、TFLite等格式，转成TVM的Relay计算图。
    TimportT_{\text{import}}
  2. 编译优化应用量化、算子融合、内存规划等Pass，是最耗时的环节。
    ToptT_{\text{opt}}
  3. 代码生成为目标CPU生成C源码，再调用MCU工具链编译链接。
    TcodegenT_{\text{codegen}}
  4. 烧录部署把二进制烧入Flash，在真机上调试验证。
    TflashT_{\text{flash}}

边缘场景应用：新家的幸福生活

搬进小公寓后，生活并没有变糟——反而因为“小而精”变得更便捷。智能音箱、运动手环、工业传感器，这些原本没有AI能力的小设备，因为微模型部署而开始“长脑子”。以语音唤醒词检测为例：设备平时处于低功耗待机，只有当检测到唤醒词时才启动主系统。这个模型通常只有几万参数，运行在MCU上，功耗仅毫瓦级。

部署前，团队会用延迟公式估算是否满足实时性。理论延迟等于计算量除以设备吞吐量：假设模型FLOPs为100万，MCU算力为1000万FLOP/s，那么延迟约100ms，对唤醒场景完全够用。

小公寓也可以智能而温馨。微模型部署的意义，不是让模型变得更强大，而是让AI在最需要的地方以最低成本运行——这就是跨平台边缘部署的“最后一公里”价值。

Latency≈FLOPsThroughput\text{Latency} \approx \frac{\text{FLOPs}}{\text{Throughput}}
推理延迟 ≈ 一次推理的计算量 ÷ 设备每秒能完成的运算量，就像路程除以速度得到时间。
  1. 计算量模型一次完整推理所需的运算次数，相当于“路程”。
    FLOPs\text{FLOPs}
  2. 设备吞吐MCU每秒能完成的运算次数，相当于“速度”。
    Throughput\text{Throughput}
  3. 延迟估算路程除以速度，得到理论上最短推理时间。
    Latency≈FLOPsThroughput\text{Latency} \approx \dfrac{\text{FLOPs}}{\text{Throughput}}

AI 应用场景

智能音箱语音唤醒

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

解决的问题：传统云端唤醒方案需要设备联网，响应延迟高且待机功耗大；将唤醒模型部署到设备端MCU后，本地即可完成唤醒判断，功耗降至毫瓦级，隐私数据也不出设备。

具体案例：某智能音箱方案商将3万参数的唤醒词分类模型量化为INT8，通过TVM MicroTVM编译后部署到Cortex-M4芯片，RAM占用仅12KB，Flash占用28KB，唤醒延迟从云端方案的800ms降至45ms。

工业电机振动异常检测

阶段：边缘推理与实时监控

解决的问题：传统方案需要把振动波形上传到云端分析，受带宽和时延限制，无法及时发现突发故障；在传感器节点本地运行1D-CNN模型，可以在80ms内识别异常并报警。

具体案例：某工厂在电机轴承上安装内置MCU的振动传感器，用TVM把1D-CNN模型编译部署到Cortex-M0+芯片，模型参数仅9KB，检测精度达96%，功耗仅2.1mW。

可穿戴设备健康监测

阶段：低功耗在线推理

解决的问题：健康手环电池容量小，若持续通过蓝牙传输心率数据会快速耗电；在本地完成心率异常检测，只上报异常事件，可延长续航数倍。

具体案例：某健康手环集成MicroTVM部署了一款轻量LSTM模型，用于在MCU上实时识别心律不齐，每次推理仅消耗0.3mJ能量，待机功耗0.3mW，精度达到医院级参考标准的95%。

Python 演示

python34 行
import numpy as np  def quantize(tensor, bits=8):    qmin = -(1 << (bits - 1))    qmax = (1 << (bits - 1)) - 1    amin = float(np.min(tensor))    amax = float(np.max(tensor))    scale = max(amax - amin, 1e-12) / (qmax - qmin)    zero_point = qmin - amin / scale    q = np.clip(np.round(tensor / scale + zero_point), qmin, qmax)    return q.astype(np.int8), scale, zero_point  def dequantize(qt, scale, zero_point):    return (qt.astype(np.float32) - zero_point) * scale  def main():    np.random.seed(42)    weights = np.random.randn(256, 64).astype(np.float32)    fp32_size = weights.nbytes    qt, scale, zero_point = quantize(weights, bits=8)    int8_size = qt.nbytes    deq = dequantize(qt, scale, zero_point)    mae = float(np.mean(np.abs(deq - weights)))    print(f"原始 FP32 权重大小: {fp32_size} 字节")    print(f"量化后 INT8 权重大小: {int8_size} 字节")    print(f"压缩比: {fp32_size / int8_size:.1f}x")    print(f"反量化平均绝对误差: {mae:.6f}")  if __name__ == "__main__":    main()
目的：模拟TVM微模型部署中的INT8量化环节，直观演示“真空压缩袋”如何把FP32权重压成原来四分之一的大小。
  1. scale = max(amax - amin, 1e-12) / (qmax - qmin)计算比例尺：把实数范围映射到整数范围，1e-12 防止除零。
  2. zero_point = qmin - amin / scale计算零点偏移，修正实数起点不在零的情况。
  3. q = np.clip(np.round(tensor / scale + zero_point), qmin, qmax)每个权重换算成整数并裁剪到 [-128, 127]，这就是量化主体。
  4. return q.astype(np.int8), scale, zero_point转换成INT8类型，内存占用立刻缩为四分之一。
  5. deq = dequantize(qt, scale, zero_point)反量化还原权重，用于验证量化精度。
  6. mae = float(np.mean(np.abs(deq - weights)))计算平均绝对误差，量化损失一目了然。

常见误区

误区我刚学INT8时以为量化就是 `int8_data = int8(float_data)`，直接把小数部分砍掉。这样做好像也能让模型变小。

正解量化不是截断，而是重新标度。截断会严重失真，正确做法是用 scale 和 zero_point 把实数区间整体映射到整数区间，反量化时还能还原出接近原始的值。就像把尺子的刻度从毫米换成厘米，测量结果依然准确，而不是把3.7厘米直接写成"3"。

为何常见：因为编程语言里固有 float 转 int 的截断操作，初学者最容易联想到它。

误区我最初觉得算子融合是代码层面的合并——把Conv函数和ReLU函数的代码放进同一个函数里，省点函数调用开销。

正解算子融合的实质是消除中间张量的内存往返。Conv输出的中间结果不写回内存，而是直接传递给ReLU。这省掉的不是几次函数调用，而是一整块特征图的内存写入与读取——在MCU上，内存带宽比计算更稀缺。

为何常见：开发者常从“代码组织”的角度理解优化，忽略了数据流动才是模型推理的主要成本。

误区我以为MicroTVM是一个全新框架，专门为嵌入式设计的深度学习推理引擎，跟TVM没什么关系。

正解MicroTVM是TVM编译器栈的一部分，它复用TVM的图解析、Pass优化和代码生成能力，只是在后端增加了面向微控制器的代码生成目标和精简运行时。相当于TVM的“微型版后端”，而不是另起炉灶。

为何常见："Micro"前缀容易让人误以为是独立项目，实际上它是TVM仓库中的一个子模块。

误区我以为把训练好的模型权重导出成 .bin 文件，用烧录工具烧进芯片就能运行。

正解MCU没有文件系统，也无法直接解释PyTorch或ONNX模型。必须经过TVM编译：量化压缩权重、优化计算图、生成C代码，再经目标工具链编译成MCU可执行的机器码。模型文件只是“图纸”，真正运行的是“盖好的房子”。

为何常见：在服务器上部署时可以直接用推理框架加载模型文件，这种惯性思维被带到了MCU上。

面试题

Q1. INT8量化相比传统FP32存储，模型权重体积大约缩小多少倍？

单选题 · easy

  • A.体积缩小到原来的二分之一
  • B.体积缩小到原来的四分之一← 正确答案
  • C.体积缩小到原来的八分之一
  • D.体积缩小到原来的十六分之一

答案：B。FP32每个参数占4字节，INT8只占1字节，所以体积缩小4倍。就像四本厚书的内容被压缩进一本薄书。

Q2. 量化公式 q = round(r/scale) + z 中，z 的作用是什么？

单选题 · mid

  • A.控制量化中数据的精度
  • B.平移整数范围到正确区间← 正确答案
  • C.防止分母出现除零错误
  • D.记录浮点数中的符号位

答案：B。当实数区间不从零开始时，除以scale后的整数结果会整体偏移，需要加上零点偏移z才能映射到正确的整数范围，比如[-128, 127]。

Q3. 关于INT8量化，下列说法正确的是？

多选题 · mid

  • A.存储体积缩小为原来的四分之一← 正确答案
  • B.权重数值完全保持不变
  • C.需要尺度因子和零点偏移← 正确答案
  • D.量化后精度一定大幅下降

答案：AC。A正确，4字节降到1字节；C正确，scale和z是量化映射的核心。B错误，量化必然引入微小损失；D错误，逐层校准后精度损失通常很小。

Q4. 算子融合最直接的效果是什么？

单选题 · easy

  • A.减少模型整体参数量
  • B.消除中间张量的内存往返← 正确答案
  • C.提升训练集的最终精度
  • D.减少训练所需的轮次

答案：B。算子融合把相邻算子合为一体，中间结果不必写回内存再读回。就像沙发床不需拆成沙发和床两个物件，少占空间也少花时间。

Q5. 关于TVM内存优化，以下说法正确的是？

多选题 · hard

  • A.生命周期不重叠可共享同一缓冲区← 正确答案
  • B.内存规划的目标是降低峰值内存占用← 正确答案
  • C.峰值内存等于所有张量大小之和
  • D.所有中间张量必须同时驻留内存

答案：AB。A对，生命周期错开的张量可复用缓冲；B对，内存规划就是为了压低峰值。C错，峰值是同一时刻存活张量之和，而非全部张量之和；D正是要避免的情况。

Q6. MCU设备RAM只有几十KB，部署模型时必须优先控制什么？

单选题 · mid

  • A.训练时间的长短
  • B.峰值内存的占用← 正确答案
  • C.GPU利用率大小
  • D.训练数据集大小

答案：B。RAM小意味着模型运行时峰值内存必须严格受控，这正是内存复用与静态分配要解决的问题，如同小公寓必须精打细算地安排储物空间。

Q7. MicroTVM部署包通常不包含以下哪一项？

单选题 · mid

  • A.运行时基础模块
  • B.目标CPU算子实现
  • C.量化后的模型参数
  • D.原始的词汇表数据← 正确答案

答案：D。部署包由运行时、生成代码、模型参数三部分构成。训练数据、词汇表等离线资源不会进入MCU部署包。

Q8. TVM跨平台部署流程中包含以下哪些阶段？

多选题 · hard

  • A.模型文件导入← 正确答案
  • B.计算图编译优化← 正确答案
  • C.目标代码生成← 正确答案
  • D.训练数据增广

答案：ABC。部署四阶段为模型导入、编译优化、代码生成与烧录部署。数据增广在训练阶段完成，与部署流程无关。

Q9. 一个模型共3072个参数，按1KB=1024字节，FP32存储约多少KB？INT8量化后约多少KB？

单选题 · easy

  • A.约9KB，量化后约2KB
  • B.约12KB，量化后约3KB← 正确答案
  • C.约24KB，量化后约6KB
  • D.约16KB，量化后约4KB

答案：B。3072×4=12288字节=12KB；3072×1=3072字节=3KB。FP32恰好是INT8的四倍，验证了量化压缩4倍的结论。

Q10. MCU Flash为128KB，运行时占8KB、生成代码占20KB，模型参数为30000个INT8权重，部署后剩余空间约为多少？

单选题 · extreme

  • A.约51KB
  • B.约71KB← 正确答案
  • C.约91KB
  • D.约111KB

答案：B。参数=30000/1024≈29.3KB，部署包=8+20+29.3=57.3KB，剩余=128-57.3≈70.7KB，最接近约71KB。