ESP32上运行微型LLM：用Brainscope实时可视化Transformer推理

把 LLM 跑在 ESP32 这类微控制器上，从资源角度看是一件反直觉的事：一颗芯片通常只有几百 KB SRAM，而主流大语言模型的权重动辄以 GB 计。但小型 Transformer 加量化推理方案已经能把参数压到几 MB 甚至更小，ESP32 也能逐 token 地生成文本。Brainscope/examples/ESP32 这个示例把问题又推进一步：不仅要在微控制器上运行 LLM，还要通过 Brainscope 可视化面板实时观察 token 概率、层激活和上下文状态，让开发者能看到一颗微控制器里的 LLM 到底是怎么思考的。

这篇文章按实际动手的路线展开：先讲清楚 MCU 上的 LLM 和 Brainscope 之间的角色划分，再给出硬件和工具链的最小要求，然后从权重转换、推理内核、事件采集到 WebSocket 上传，搭出可运行的完整链路，最后补上常见报错的排查路径和工程化建议。适合有一定嵌入式基础、想尝试边缘 AI 可视化，或者对 LLM 推理细节感兴趣的开发者。

1. 先理解这条链路：MCU、Transformer 与可视化工具如何配合

1.1 为什么要在微控制器上运行 LLM

把生成式模型放到微控制器上的动机通常有三个：离线可用、数据不出设备、响应链路短。比如一个基于语音关键词触发的文本生成设备，如果全部推理都在本机完成，就不依赖云服务，也不存在把用户语音或文本内容上传到远端的问题。对教学和原型验证来说，在一颗几十块钱的开发板上跑通一次完整的 token 生成，能比在服务器上调 API 更直观地理解 Transformer 的每一步计算。

但代价也明显。ESP32 的典型场景是传感器采集、蓝牙网关、小型显示屏驱动，工程上的经验是“内存按 KB 规划、循环里不要做重计算”。一旦引入 LLM，哪怕是一个只有几百万参数的微型 Transformer，也要重新考虑权重存放位置、临时张量分配和单次推理耗时。Brainscope/examples/ESP32 示例的价值，正是把这种资源受限状态下的推理过程透明化。

1.2 Brainscope 在这个示例中承担什么角色

Brainscope 是一个自托管的神经网络可视化工具，它不负责推理本身，而是接收模型运行时暴露出来的内部状态，把张量、概率、文本 token 等数据渲染成可交互的面板。在服务器场景里，它可以接到一个跑在 GPU 上的模型；在 ESP32 示例里，它的角色没有变化，只是数据来源从大模型变成了微控制器。

也就是说，Brainscope 与 ESP32 之间是典型的“数据生产者和消费者”关系。ESP32 负责：

• 加载量化后的模型权重；
• 执行 Transformer 推理；
• 完成温度采样和 top-k 采样；
• 把每一步产生的 token、概率、注意力或激活信息打包成事件；
• 通过 WiFi 发送到 Brainscope。

Brainscope 服务端负责：

• 启动 HTTP 服务和 WebSocket 接口；
• 接收事件并解析；
• 在浏览器面板里渲染生成过程。

理解这条角色划分很重要。很多人一开始把注意力放在“ESP32 怎么跑模型”，却忽略了“模型跑起来之后数据怎么出去”。如果事件协议不稳定、发送频率过高或发送任务阻塞了推理循环，最终看到的就是生成正常但面板空白，或者面板有数据但生成明显卡顿。

1.3 四条主线和一条数据流

整个示例可以拆成四条主线：

• 模型准备：选一个参数量足够小的 Transformer，导出权重，量化成 MCU 可加载的格式。
• 推理内核：在 C 里完成嵌入、LayerNorm、注意力、MLP、softmax 和采样。
• 事件采集：在推理循环的关键位置打点，生成结构化事件。
• 传输与展示：通过 WiFi 和 WebSocket 把事件推给 Brainscope。

数据流是单向的：文本 prompt 进入推理引擎，引擎逐个生成 token；每生成一个 token，采集模块拿到 token_id、概率和可选的层状态，组装成 JSON；JSON 进入发送队列，由 WebSocket 任务发送；Brainscope 收到后更新面板。这样设计的好处是采集逻辑和发送逻辑解耦，即使网络抖动，推理也不会被网络写操作卡死。

2. 环境准备：按“能跑推理”而不是“能点灯”的标准选硬件和工具链

2.1 主控选型：内存差别的优先级高于主频

在 ESP32 系列里，型号差异主要体现在核心、SRAM、PSRAM 支持和外设上。对 LLM 推理来说，最关键的指标排序是：可用内存、权重存储容量、整数计算能力、调试便利性。

推荐使用带 8MB PSRAM 的 ESP32-S3 开发板，例如 ESP32-S3-DevKitC-1 或类似板型。PSRAM 用于存放推理过程中的中间激活值、KV 缓存和模型权重的工作副本。如果使用没有 PSRAM 的板子，不是完全不能跑，但模型规模要压到极小，且malloc出来的大数组会很快耗尽内部 SRAM。

还需要准备一根数据线，确认开发板的 USB-UART 芯片驱动已安装。很多“烧录失败”问题其实不是编译错误，而是电脑没有识别到串口设备。

2.2 固件工程：PlatformIO 配置示例

可以用 ESP-IDF 直接构建，也可以用 PlatformIO。下面的platformio.ini是一个常见组合，实际使用时根据板型和分区方案调整：

[env:esp32-s3-devkitc-1] platform = espressif32 board = esp32-s3-devkitc-1 framework = espidf monitor_speed = 115200 board_build.partitions = partitions_brainscope.csv [env:esp32dev] platform = espressif32 board = esp32dev framework = espidf monitor_speed = 115200 board_build.psram = enable

关键点：

• framework = espidf方便使用esp_websocket_client等组件；如果示例是 Arduino 版本，则把 framework 改成arduino，但 WebSocket 客户端库需要另行引入。
• board_build.partitions指向分区文件，分区里要单独留出一块区域存放模型权重。
• board_build.psram = enable只对部分环境生效，最可靠的方式还是进入menuconfig确认 PSRAM 已启用。

分区文件示例：

# Name, Type, SubType, Offset, Size nvs, data, nvs, 0x9000, 0x5000 phy_init, data, phy, 0xe000, 0x1000 factory, app, factory, 0x10000, 0x300000 model, data, spiffs, 0x310000, 0x1C0000

这样划分后，固件占前 3MB，模型权重放在独立的 SPIFFS 分区里，约 1.75MB。模型文件通过idf.py partition_table或 PlatformIO 的文件系统上传命令写入，不混在固件里，方便后续只更新模型而不重刷应用。

2.3 Brainscope 服务端：下载、安装与启动

Brainscope 服务端通常需要 Node.js 环境。常见步骤是：

git clone <brainscope 仓库地址> cd brainscope npm install npm run start

启动后，服务端会监听一个本地端口，默认情况下浏览器访问仪表盘，ESP32 连接 WebSocket 事件接口。由于端口、事件路径和鉴权方式会随版本变化，落地前要以仓库 README 和示例配置为准。

调试验证时，可以先用一个 WebSocket 测试工具连上服务端，手动发送一条事件，确认面板能更新，再把 ESP32 接入。这样能把问题定位到“ESP32 没发”还是“服务端没收到”，避免两头同时排查。

2.4 模型怎么来：选型、导出与量化

ESP32 无法运行 GPT-4 或 7B 级别的模型。这个示例中使用的模型通常是参数量在 1M 到 10M 之间的小型 GPT，比如 nanoGPT 风格的结构：若干层 Transformer block，隐藏维度几十到一百多，词表几百到几千。

模型来源一般有两种：

• 从公开的小型预训练权重转换；
• 在自己的语料上训练一个迷你模型后导出。

无论哪种方式，最终都要经过导出和量化两步。导出是指把 PyTorch 或 TensorFlow 的权重文件序列化成二进制格式；量化是指把 FP32 权重转成 INT8 加 zero/scale 的形式，以减少 Flash 和 PSRAM 占用。

需要注意：原始示例如果只给了标题，没有明确模型版本和格式，那么到这一步先确认仓库里有没有现成的转换脚本。没有脚本时，可以按“FP32 权重 + INT8 量化 + 自定义二进制头”的方式自己写，下面第 3 节会给出一个可参考的实现思路。

3. 搭建最小可运行工程：目录、权重转换和推理内核

3.1 看一遍示例目录结构

一个典型的 ESP32 + Brainscope 示例工程结构如下：

examples/ESP32/ ├── main/ │ ├── app_main.c # 启动流程、WiFi、任务创建 │ ├── model.c # 权重加载、反量化 │ ├── tinygpt.c # Transformer 推理内核 │ ├── sampler.c # top-k、温度采样 │ ├── events.c # 事件采集与 JSON 组装 │ └── ws_transport.c # WebSocket 发送 ├── tools/ │ ├── export_model.py # 权重导出与量化脚本 │ └── tokenizer.json # 词表文件 ├── partitions_brainscope.csv ├── CMakeLists.txt └── platformio.ini

这个结构把“模型 IO、推理、采样、事件、传输”分开，原因是嵌入式调试时很难一次定位问题，模块边界清楚能大幅缩短排错时间。如果示例仓库的目录不同，也建议保持同样的分层逻辑再做裁剪。

3.2 把模型权重转成 MCU 能直接加载的二进制

模型导出脚本要做三件事：读取权重、逐层量化、按固定格式写入二进制文件。下面是一段思路示例，实际字段名以仓库为准：

import numpy as np import torch def quantize_tensor(t): t = t.float() amin = t.min().item() amax = t.max().item() scale = (amax - amin) / 255.0 if amax > amin else 1.0 q = np.clip(np.round((t.numpy() - amin) / scale), 0, 255).astype(np.uint8) return q, np.float32(amin), np.float32(scale) def export_model(ckpt_path, out_path, header): ckpt = torch.load(ckpt_path, map_location="cpu") with open(out_path, "wb") as f: # 固定头：magic、层数、维度、词表大小、最大序列长度 f.write(np.array(header, dtype=np.int32).tobytes()) for name in ["wte", "ln1", "attn_q", "attn_k", "attn_v", "attn_o", "ln2", "mlp_fc", "mlp_proj", "head"]: if name not in ckpt: continue q, zero, scale = quantize_tensor(ckpt[name]) shape = list(q.shape) f.write(np.array([len(shape)], dtype=np.int32).tobytes()) f.write(np.array(shape, dtype=np.int32).tobytes()) f.write(zero.tobytes()) f.write(scale.tobytes()) f.write(q.tobytes())

要点：

• 每个张量先写形状，再写 zero 和 scale，最后写量化后的权重。C 端读取时必须按相同顺序解析。
• INT8 通常用uint8_t存储，因为int8_t在不同平台的符号扩展行为容易踩坑。
• 如果模型权重在亿级以上，不要用 Python 脚本临时算 scale，而是先做校准集统计，再量化。这个示例里权重小，简单 min-max 也能工作。

3.3 推理引擎：从 forward 到采样

C 端的模型结构可以简化成下面几组声明：

typedef struct { int layers; int dim; int vocab_size; int max_seq_len; } GPTConfig; typedef struct { uint8_t *q; float zero; float scale; } QTensor; typedef struct { QTensor wte; QTensor ln1_scale, ln1_bias; QTensor attn_q, attn_k, attn_v, attn_o; QTensor ln2_scale, ln2_bias; QTensor mlp_fc, mlp_proj; QTensor head; } TinyGPT;

INT8 的矩阵乘需要一个反量化步骤。训练好的 FP32 权重被压缩成q, zero, scale后，恢复近似值的方法是：

static float dequant(uint8_t q, float zero, float scale) { return zero + (float)q * scale; }

实际做矩阵乘时，不要对每个元素都调用dequant，否则性能会很差。更好的做法是先把输入激活量化成 INT8，然后用整数乘法累加，最后只在输出端乘一次 scale。下面是简化示意：

// y[m] = sum_n x[n] * w[n][m] // 输入 x 已量化，w 的 q 和 scale 已知 int32_t acc = 0; for (int n = 0; n < dim; n++) { acc += (int32_t)x_q[n] * (int32_t)w_q[n * out_dim + m]; } y[m] = acc * w_scale; // 再叠加 zero 修正

采样是生成循环的关键。softmax 之后得到概率分布，再按温度和 top-k 决定下一个 token：

static void softmax(float *logits, int n) { float max_l = logits[0]; for (int i = 1; i < n; i++) { if (logits[i] > max_l) max_l = logits[i]; } float sum = 0.0f; for (int i = 0; i < n; i++) { logits[i] = expf(logits[i] - max_l); sum += logits[i]; } for (int i = 0; i < n; i++) { logits[i] /= sum; } } static int sample_from_probs(float *probs, int n, float temperature) { if (temperature > 0.0f) { for (int i = 0; i < n; i++) { probs[i] = powf(probs[i], 1.0f / temperature); } float sum = 0.0f; for (int i = 0; i < n; i++) sum += probs[i]; for (int i = 0; i < n; i++) probs[i] /= sum; } float r = (float)rand() / RAND_MAX; float cdf = 0.0f; for (int i = 0; i < n; i++) { cdf += probs[i]; if (r < cdf) return i; } return n - 1; }

这段代码省略了 top-k 排序和 KV 缓存的完整实现，但已经能说明生成循环的结构：推理出 logits，softmax 转概率，采样得到下一个 token，再把它拼回输入序列。

3.4 采集思考过程：在哪些位置打点

要让 Brainscope 看到“思考过程”，不能只在最终输出处打点。建议在四个位置采集：

• 采样之后：记录当前 token、token 文本、概率。
• softmax 之后：记录 top-k 的候选 token 和对应概率，用于展示分布变化。
• 每个 Transformer block 之后：记录激活范数，用于判断数值是否稳定。
• 注意力层之后：记录注意力分布的摘要，例如对前几个位置的注意力均值。

一个最小的事件结构可以这样组织：

typedef struct { int step; int token_id; char text[16]; float prob; float temperature; float psram_free; } TokenEvent;

事件采集要控制频率。注意力矩阵和激活范数如果每个 token 都传，数据量会迅速增加，对 ESP32 的小内存和 WiFi 吞吐都是负担。比较稳妥的策略是：token 和概率每步都发；注意力每 2 到 4 步发一次；激活范数每 4 步发一次。

3.5 传输通道：用 WebSocket 把事件送到 Brainscope

ESP-IDF 提供了esp_websocket_client组件。初始化代码大致如下：

#include "esp_websocket_client.h" static esp_websocket_client_handle_t g_client; void ws_init(const char *uri) { esp_websocket_client_config_t cfg = { .uri = uri, .buffer_size = 2048, }; g_client = esp_websocket_client_init(&cfg); esp_websocket_client_start(g_client); } void ws_send_json(const char *json) { if (g_client && esp_websocket_client_is_connected(g_client)) { esp_websocket_client_send_text(g_client, json, strlen(json), pdMS_TO_TICKS(100)); } }

发送 JSON 时，用snprintf拼字符串：

char buf[512]; snprintf(buf, sizeof(buf), "{\"type\":\"token\",\"step\":%d,\"token_id\":%d,\"text\":\"%s\",\"prob\":%.4f,\"temperature\":%.2f,\"psram_free\":%u}", evt.step, evt.token_id, evt.text, evt.prob, evt.temperature, (unsigned)heap_caps_get_free_size(MALLOC_CAP_SPIRAM));

一条完整事件大概是：

{ "type": "token", "step": 12, "token_id": 847, "text": "temperature", "prob": 0.684, "top_k": [ ["the", 0.684], ["a", 0.102], ["an", 0.051] ], "temperature": 0.8, "psram_free": 4190208 }

这里要注意：不要在推理循环里直接调用esp_websocket_client_send_text，尤其是当网络不通时，这个调用可能阻塞。推荐做法是建立一个固定大小的环形队列，推理任务只负责入队，独立的发送任务负责出队和发送。队列满时丢弃旧事件或跳过本次发送，保证推理不被网络拖慢。

4. 编译、烧录、运行：从串口日志到仪表盘逐步确认

4.1 编译和烧录

PlatformIO 环境下，先编译再上传：

pio run -t upload pio device monitor -b 115200

ESP-IDF 环境下对应：

idf.py build idf.py -p /dev/ttyUSB0 flash monitor

烧录完成后，第一步不是看生成结果，而是确认三件事：系统启动正常、PSRAM 可见、模型分区可读。如果这三件事有一件不成立，后续所有问题都会被放大。

4.2 启动 Brainscope 并确认 WebSocket 连接

先启动服务端，然后在浏览器里打开仪表盘。在 ESP32 固件里配置好服务端地址后，重启设备。串口日志里应该能看到 WebSocket 连接成功的记录。

如果连接失败，优先检查：

• 服务端地址是否写成了ws://而不是http://；
• 端口是否正确；
• ESP32 和电脑是否在同一局域网，且路由允许本地 WebSocket；
• 防火墙是否拦截了服务端端口。

4.3 串口日志里的预期输出

一次正常运行的串口日志大致如下：

I (5821) brainscope: loading model from flash, size=2986412 bytes I (5842) brainscope: PSRAM total=8388608, free=5668160 I (5861) brainscope: model loaded, layers=8 dim=64 vocab=512 I (5900) brainscope: wifi connected, ip=192.168.1.42 I (5951) websocket: connected to ws://192.168.1.10:8080/feed I (6003) gen: prompt=The quick brown I (6021) gen: token 0/64: fox prob=0.713 I (6088) gen: token 1/64: jumps prob=0.452

日志里出现 token 编号、文本和概率，说明推理链路已经通。接下来才需要去面板上看渲染是否正常。

4.4 仪表盘上的验证点

面板刷出数据后，按三个层次验证：

• token 是否逐个出现，文本是否和串口日志一致。
• 概率柱状图是否随采样变化，top-k 候选是否在合理范围内。
• 激活和注意力图是否随着生成步数增加而更新。

如果 token 有，但注意力图一直不动，大概率是事件类型名不匹配，或注意力数据根本没进发送队列，而不是面板渲染问题。

5. 看懂数据链路：一次 token 生成背后发生了什么

5.1 生成循环的五个阶段

一次 token 生成可以拆成五个阶段：

1. Token 嵌入：把当前 token 映射为向量。
2. Transformer block：经过多头注意力和 MLP，更新隐藏状态。
3. LM Head：把最后一层隐藏状态映射成词表大小的 logits。
4. Softmax：把 logits 转成概率分布。
5. 采样：按温度和 top-k 从概率分布中选择下一个 token。

Brainscope 面板上看到的“思考过程”，本质是这五个阶段中某些中间值的可视化。比如 token 概率对应第 4 阶段，注意力热力图对应第 2 阶段，激活范数对应第 2 阶段和第 3 阶段之间。

5.2 哪些数据值得可视化

把这些数据放在同一时间轴上，就能回答一个很有意思的问题：模型在生成某个 token 时，到底是“非常确定”还是“在几个候选里勉强选了一个”。这在调温度参数时特别有用。

5.3 采样频率与事件协议设计

数据采样频率和网络带宽需要作取舍。一个 token 的事件如果包含完整注意力矩阵，JSON 可能膨胀到几千字节；ESP32 的 WiFi 吞吐本来就不高，高频发送会挤占推理时间。

实际项目里推荐两种策略：

• 低频完整：每 4 到 8 个 token 发送一次完整状态，其余 token 只发文本和概率。
• 高频摘要：每个 token 都发，但只发 top-3 概率和激活范数，不发完整矩阵。

事件协议里的type字段要固定，Brainscope 面板靠它区分 token、attention、memory 等不同事件。扩展新事件时，保持向后兼容，不要在旧字段上改语义。

6. 常见问题排查：从启动崩溃到仪表盘空白

6.1 PSRAM 相关：启动反复重启或分配失败

现象：串口反复输出abort()，或者出现类似heap out of memory的日志，设备不断重启。

常见原因：PSRAM 没有启用；模型权重被当成普通内存分配到了内部 SRAM；PSRAM 引脚配置和板子不匹配。

检查方式：在代码里打印heap_caps_get_total_size(MALLOC_CAP_SPIRAM)和heap_caps_get_free_size(MALLOC_CAP_SPIRAM)，确认 PSRAM 是否可见；再用menuconfig检查Component config -> ESP32-S3-Specific -> Support for external, SPI-connected RAM是否打开。

解决方案：启用 PSRAM，大数组统一用heap_caps_malloc(size, MALLOC_CAP_SPIRAM)分配，模型权重从 Flash 读取后放在 PSRAM 缓冲区内。

6.2 模型加载与反量化：乱码和重复 token

现象：能生成，但输出全是同一个 token，或者文本明显错乱。

常见原因：二进制格式读写顺序不一致；zero 和 scale 的字节序错误；量化时用错 dtype；加载时下标越界。

检查方式：在 Python 端打印几个关键权重，C 端加载后也打印同样位置的数值，逐项对比。如果数值差一个 scale 或 zero，就能定位到反量化公式。

解决方案：统一按“形状数组 + zero + scale + 权重”的格式，C 端解析时严格按写入顺序读取；在文件头加 magic 和版本号，C 端加载时先校验，不匹配就报错而不是继续跑。

6.3 WebSocket 连不上或事件丢失

现象：串口显示推理正常，但 Brainscope 面板一直没有数据。

常见原因：服务端地址错误；事件 type 不被面板识别；发送队列太短或发送任务优先级太低；防火墙拦截。

检查方式：用测试工具手动连接服务端，发送一条已知合法的 JSON，确认面板能更新；再看 ESP32 串口日志里有没有connected字样；最后在发送任务里加计数器，确认send_text返回值。

解决方案：把 WebSocket URI 做成可配置项；事件发送失败时保留最近一条并记录错误码；事件队列不满时累积批量发送，降低连接开销。

6.4 性能与稳定性：卡顿、看门狗复位

现象：生成速度很慢，或者运行几秒后设备被看门狗复位。

常见原因：推理循环里没有让出 CPU；int8 矩阵乘实现低效；在循环里反复调用snprintf和 JSON 拼接，导致栈或堆压力大。

检查方式：串口日志里查看复位原因，常见的是Task watchdog got triggered；用perfmon或定时器统计单次 forward 耗时。

解决方案：把推理拆成多个较小步骤，在步骤之间调用vTaskDelay(1)喂看门狗；矩阵乘改用循环展开和固定点数乘；JSON 缓冲区在任务栈里提前分配，不要在热路径上频繁动态分配。

7. 最佳实践：从学习 Demo 走到可复用工程

7.1 学习环境与生产环境的差异

学习环境中，开发板放在电脑旁边，模型文件通过串口烧写，Brainscope 跑在同一台电脑上，这种配置足够的验证“能不能跑”。但生产环境完全不同。

生产环境需要额外考虑：

• 模型和固件分开存储，支持 OTA 升级，避免每次改模型都重新烧录整个设备。
• WebSocket 事件加上权限校验，避免其他设备向面板注入伪造数据。
• 事件传输改用二进制或压缩 JSON，降低带宽和内存占用。
• 增加日志落盘和错误上报，设备不在手边时也能排查。
• 对推理耗时和内存使用做监控，提前发现模型退化或权重损坏。

7.2 可复用的验收清单

把这个示例复用到自己的项目时，按下面的清单过一遍，能省去大量排错时间：

• [ ] 开发板型号和 PSRAM 容量已确认，代码里能打印出正确内存大小。
• [ ] 分区表已给模型文件预留独立区域，且偏移不与 app 重叠。
• [ ] 模型转换脚本输出固定格式，文件头带 magic 和版本号。
• [ ] ESP32 能用串口正常加载权重，且不出现abort()。
• [ ] WiFi 能连接，WebSocket 握手成功，接口地址可配置。
• [ ] 推理任务和网络发送任务分离，网络断开时推理不阻塞。
• [ ] 事件 type 字段与 Brainscope 面板配置一致。
• [ ] 采样频率已控制，不会导致内存持续增长或网络拥塞。
• [ ] 看门狗已喂，长序列生成不会复位。
• [ ] 日志能区分启动、加载、连接、生成、异常五类状态。

7.3 扩展方向

跑通这个示例之后，可以往几个方向继续深入。

第一个方向是模型侧：尝试更大的词表、更深的层数，观察 ESP32-S3 的推理上限；或者用 INT4 量化把模型再压小，争取塞进更低成本的芯片。

第二个方向是数据侧：把 GPIO 传感器数据、麦克风音频特征或蓝牙设备信息作为 prompt 上下文，让生成结果跟真实环境关联起来。比如温湿度异常时，让微控制器生成一段自然语言告警。

第三个方向是可视化侧：在 Brainscope 面板中加入自定义事件类型，把 KV 缓存变化、内存占用曲线和 WiFi 信号强度一起展示，形成一个完整的边缘设备运行监控面板。

对刚接触这个组合的开发者，建议先不要在模型规模上追求极限，而是把一个 5M 参数左右的量化模型完整跑通，再把注意力可视化和 WebSocket 事件链路调稳定。这一步比盲目追求更大模型更能建立对 MCU 上 LLM 推理的整体认知。