ESP32 端侧 LLM 推理可视化：从串口日志到思考过程监控

之前在做 ESP32 端侧 AI 小项目时，最头疼的不是把模型部署到板子上，而是模型跑起来之后完全看不到它“在想什么”。传统开发模式下，我们只能看到串口输出的最终结果，中间过程像一个黑盒。直到我看到 Brainscope 仓库中的examples/ESP32示例，主题是 “Watch a microcontroller's LLM think”，才发现原来可以把微控制器上 LLM 的“思考过程”也变成可观察、可回放的日志流。本文会从概念到实战，带你在 ESP32 上复现这套监控链路，适合刚接触 ESP32、想尝试端侧 LLM 或者单纯好奇“单片机怎么展示思考过程”的开发者。

1. 背景与核心概念

1.1 Brainscope 是什么

Brainscope 是一个围绕“观察模型推理过程”的示例与工具集合，它强调把模型运行时的内部状态转成结构化的观测数据。你可以把它理解为“模型推理的可观测性工具”：传统调试只能看结果是否正确，而 Brainscope 这类思路更关注推理过程中每个 token 是怎么产生的、每一步耗时多少、模型内部状态如何变化。

仓库里有很多 examples，ESP32这个示例专门面向微控制器场景。它要解决的核心问题是：ESP32 资源比服务器小得多，但当它运行一个微型模型时，我们依然需要知道模型的实时状态。比如当前生成到第几个 token、剩余堆内存还有多少、单次推理耗时多少、温度参数是多少，这些信息如果不进行结构化输出，很难直观判断模型是否正常工作。

需要注意的是，Brainscope 的“观察”能力依赖于设备端日志协议和上位机解析，两者必须配合使用。本文不会逐行解析仓库源码，因为不同版本接口差异较大，但会把核心链路完整复现出来，让你能照着跑通，再根据实际仓库 README 调整细节。

1.2 ESP32 与微控制器上的 LLM

ESP32 是乐鑫推出的一系列低功耗物联网芯片，自带 Wi-Fi 和蓝牙，价格低、生态成熟，在 Arduino IDE、ESP-IDF、PlatformIO 中都有很好的支持。它通常被用来做传感器采集、智能家居、小屏幕交互等场景。

然而“在 ESP32 上跑 LLM”并不是一个常规操作。LLM 通常指大语言模型，参数规模从几亿到几千亿不等，需要 GB 级内存和高速计算单元。而 ESP32 经典款只是双核 240MHz 的 MCU，内存一般只有 320KB 到 512KB SRAM，算力和存储都非常有限。

所以当我们说“微控制器上的 LLM”时，通常指下面几种情况：

本文的实战案例采用“模拟推理”的方式，重点先跑通 Brainscope 的观测链路。如果你手头有量化后的微型模型，也可以把模拟推理部分替换成真实推理函数，通信和解析代码几乎不用改。

1.3 “Watch a microcontroller's LLM think” 是什么

这个标题可以拆成两层理解。

第一层，字面意思是“观看微控制器的 LLM 思考”。LLM 的生成过程并不是一次性输出完整回答，而是逐 token 生成的。每生成一个 token，模型就要做一次前向推理，根据候选词概率选出下一个 token。这就像人在说话之前，每个词都是经过思考后说出来的。我们把这些“思考步骤”打印出来，就能看到模型按什么顺序逐步生成文本。

第二层，工程意义是“让嵌入式 AI 推理过程可观测”。服务器端跑大模型时，有完整的监控平台查看 GPU 使用率、推理延迟、token 速度；但到了 ESP32 上，这些能力都被极度压缩了。Brainscope 的 ESP32 示例提供了一种低成本方案：通过串口把 token 流、内存、时间戳、温度等信息结构化输出，再在上位机用脚本解析渲染，最终在电脑屏幕上动态看到“模型思考”的过程。

这对调试工作流很有价值。比如同样一个模型，温度参数调高后生成结果可能更随机，而观察 token 概率分布就能定位问题；如果内存不足导致生成中断，也能从日志里一眼看出是哪一步堆内存告急。

2. 环境准备与版本说明

2.1 硬件准备

建议先准备一块 ESP32 开发板。优先选择 ESP32-S3 系列，因为它有更多 PSRAM，适合后续挂载真实微型模型；如果只是复现本文的监控链路，经典 ESP32 DevKitC 也完全够用。

需要说明的是，本文示例的重点是“监控链路”，对硬件规格要求很低。你只要有一块能通过 USB 串口烧录的 ESP32 开发板即可。接线方式非常简单：开发板通过 USB 线连接电脑，开发板上的板载串口芯片（如 CP2102、CH340）会映射成一个系统串口。

如果你不确定串口驱动是否安装成功，可以先在设备管理器里查看端口是否被识别；如果看不到端口，大概率需要手动安装 CP210x 或 CH340 驱动。

2.2 Arduino IDE 搭建 ESP32 开发环境

这里使用 Arduino IDE，因为它对新手最友好，配置 ESP32 环境也比较简单。建议使用 Arduino IDE 2.x，界面更现代，库管理更方便。

打开 Arduino IDE 后，在“首选项 - 附加开发板管理器网址”中添加 ESP32 官方 JSON 地址，然后在“开发板管理器”中搜索 esp32 并安装。国内网络如果下载较慢，可以改用离线安装包方式，把下载好的 esp32 包放到 Arduino 的硬件目录下解压。

安装完成后，在“工具 - 开发板”中选择你的板子型号，比如ESP32 Dev Module或ESP32S3 Dev Module。烧录前确认：

如果点击烧录后提示Failed to connect to ESP32，通常是因为进入了下载模式失败。经典 ESP32 需要按住 BOOT 键不放在烧录过程中再松开，或者检查串口是否被串口监视器占用。

2.3 Python 端准备

上位机监控脚本使用 Python 3，需要安装pyserial库：

pip install pyserial

Python 脚本通过串口读取 ESP32 发送的日志，并按 JSON 格式解析，最后在终端中渲染出“思考过程”。建议同时安装一个终端工具，比如 VS Code 的串口监视器插件，方便在烧录前先查看原始输出。

版本方面，Python 3.8 以上均可。pyserial版本没有特殊要求，使用 pip 默认安装即可。

3. 核心原理拆解

3.1 微控制器跑 LLM 的约束

在进入代码前，先理解为什么 ESP32 上做 LLM 观测和服务器端不一样。

服务器端跑大语言模型时，GPU 显存通常是几十 GB，权重可以全部驻留，推理引擎会批量处理请求，监控指标可以通过 NVIDIA 驱动、推理框架 API 获取。但在 ESP32 上，内存可能是 KB 级到 MB 级，CPU 频率也只有几百 MHz，此时你面对的第一个问题不是“模型效果好不好”，而是“模型能不能装进内存、推理一次需要多久”。

因此微控制器上的 LLM 部署通常要经过这几步：

1. 模型压缩：使用 int8/int4 量化，有时还会做剪枝和蒸馏。
2. 内存优化：利用 PSRAM 作为权重缓存，按需加载层级权重。
3. 算子精简：只保留必要算子，避免引入大运行时。
4. 推理异步化：边推理边输出 token，避免长时间阻塞主循环。

但无论模型怎么压缩，我们都希望看到推理过程。于是监控系统必须做到“轻量”：不能在设备端做复杂渲染，最好只输出结构化日志，把可视化交给自己开发的脚本或上位机工具。

3.2 推理过程可视化：观察什么

“Watch a microcontroller's LLM think”到底要观察什么指标？这并没有标准答案，但根据模型推理的通用特性，可以归纳为以下五类：

除了这些，真实场景中还可以输出当前候选 token 的概率分布、注意力权重、KV cache 使用量等。但考虑到 ESP32 的性能，建议优先输出最关键字段，避免序列化本身影响推理速度。

Brainscope 示例里一个重要思路是：设备端只负责产生事件流，不负责存储和渲染。事件流可以被串口接收，也可以被保存成 JSONL 文件回放。这样即使你不在现场，也能通过日志复盘模型当时“在想什么”。

3.3 日志协议设计

为了让上位机能稳定解析，我们需要设计一个简单的日志协议。建议使用 JSON 格式，一次性输出所有字段，每一行日志代表一个事件。

例如表示“初始化”的事件：

{"event":"init","model":"demo-llm","device":"esp32"}

表示“生成一个 token”的事件：

{"event":"token","step":1,"token":"Hello","temp":0.80,"mem_free":183000}

表示“生成结束”的事件：

{"event":"done","reason":"eos"}

使用 JSON 的好处是 Python 端可以直接json.loads解析，不需要自己写字符串拆解逻辑。坏处是 ESP32 构造 JSON 字符串会多花一点时间和内存。因此建议在设备端只输出必要的调试字段，不要每个 token 都附带大字段。

4. 完整实战案例

4.1 项目结构

我们先规划一个完整的最小项目：

esp32_llm_think/ ├── esp32_llm_think.ino # ESP32 端 Arduino 代码 ├── observer.py # Python 上位机监控脚本 └── README.md # 说明文件（可选）

Arduino 代码运行在 ESP32 上，模拟一个轻量 LLM 的 token 生成过程；Python 脚本运行在电脑上，读取串口日志并实时渲染。

4.2 ESP32 端代码

新建一个 Arduino 工程，文件名为esp32_llm_think.ino，粘贴以下代码：

// 文件路径：esp32_llm_think/esp32_llm_think.ino #include <Arduino.h> // 模拟模型的 token 输出流 const char* token_stream[] = { "Hello", ",", " I", " am", " ESP32", ",", " my", " current", " token", " is", " ...", "\n" }; const int token_count = sizeof(token_stream) / sizeof(token_stream[0]); // 模拟模型采样温度 float fake_temperature = 0.8f; // 模拟每个 token 的生成间隔（毫秒） const unsigned long token_interval_ms = 300; int current_step = 0; unsigned long last_token_time = 0; void sendInitEvent() { Serial.print("{\"event\":\"init\",\"model\":\"demo-llm\",\"device\":\"esp32\"}\n"); } void sendTokenEvent(int step, const char* token, float temperature) { uint32_t free_heap = ESP.getFreeHeap(); Serial.print("{\"event\":\"token\",\"step\":"); Serial.print(step); Serial.print(",\"token\":\""); Serial.print(token); Serial.print("\",\"temp\":"); Serial.print(temperature); Serial.print(",\"mem_free\":"); Serial.print(free_heap); Serial.print(",\"uptime_ms\":"); Serial.print(millis()); Serial.println("}"); } void sendDoneEvent() { Serial.print("{\"event\":\"done\",\"reason\":\"eos\"}\n"); } void setup() { Serial.begin(115200); delay(2000); // 等待串口稳定 sendInitEvent(); last_token_time = millis(); } void loop() { if (current_step < token_count) { unsigned long now = millis(); if (now - last_token_time >= token_interval_ms) { sendTokenEvent(current_step, token_stream[current_step], fake_temperature); current_step++; last_token_time = now; } } else { if (current_step == token_count) { sendDoneEvent(); current_step++; } delay(1000); } }

这段代码的核心逻辑很简单：

• setup中初始化串口，并发送一条init事件。
• loop中每 300ms 模拟生成一个 token，调用sendTokenEvent输出该 token 的内容、step、温度、剩余堆内存和运行时间。
• 所有 token 输出完毕后，发送done事件。

为什么要在日志里带上uptime_ms？因为微控制器端不像电脑端有统一时钟，millis()可以从设备启动开始计时，上位机用它计算每个 token 的生成间隔和整体耗时。

注意代码里Serial.println("}")分成了两段输出，这样做是为了避免浮点数转字符串时占用太多临时缓冲区，也便于阅读。

4.3 Python 端监控脚本

在电脑上新建observer.py，粘贴以下代码：

# 文件路径：esp32_llm_think/observer.py import serial import sys import time import json # Windows 示例端口，Linux 下通常是 /dev/ttyUSB0 或 /dev/ttyACM0 SERIAL_PORT = "COM3" BAUD_RATE = 115200 def main(): try: ser = serial.Serial(SERIAL_PORT, BAUD_RATE, timeout=1) except serial.SerialException as exc: print(f"[错误] 无法打开串口 {SERIAL_PORT}: {exc}") print("请检查端口号是否被占用，或者串口驱动是否安装成功。") sys.exit(1) print("Brainscope observer started. Waiting for ESP32 logs...") time.sleep(2) token_start_time = None try: while True: line = ser.readline().decode("utf-8", errors="ignore").strip() if not line: continue try: payload = json.loads(line) except json.JSONDecodeError: print(f"[raw] {line}") continue event = payload.get("event") if event == "init": print("[init] model={} device={}".format( payload.get("model"), payload.get("device") )) token_start_time = time.time() elif event == "token": step = payload.get("step") token = payload.get("token") temperature = payload.get("temp") mem_free = payload.get("mem_free") uptime_ms = payload.get("uptime_ms") now = time.time() if token_start_time is not None: elapsed = now - token_start_time else: elapsed = 0.0 print("[token {:02d}] {:8.2f}s temp={:.2f} mem={} uptime={}ms -> {}".format( step, elapsed, float(temperature), mem_free, uptime_ms, token )) elif event == "done": print("[done] generation finished, reason={}".format( payload.get("reason") )) print("如果你想让日志继续运行，可以按 Ctrl+C 退出。") else: print(f"[unknown] {line}") except KeyboardInterrupt: print("\n[observer stopped by user]") finally: ser.close() if __name__ == "__main__": main()

这个脚本做的事情分四步：

1. 打开串口，绑定端口和波特率。
2. 循环读取一行字符串。
3. 尝试把字符串解析成 JSON，如果不是 JSON 就原样打印。
4. 根据event字段分别处理初始化事件、token 事件和结束事件。

token_start_time用来记录从收到init到收到当前 token 的累计时间，方便你判断整个生成过程是否流畅。如果 ESP32 端输出速度变慢，可以明显看到s列的增长速度不规律。

4.4 运行与验证

运行分为两步。

第一步，用 Arduino IDE 把esp32_llm_think.ino烧录到 ESP32。烧录成功后打开串口监视器，如果你看到以下输出，说明设备端逻辑正常：

{"event":"init","model":"demo-llm","device":"esp32"} {"event":"token","step":0,"token":"Hello","temp":0.80,"mem_free":180000,"uptime_ms":2030} {"event":"token","step":1,"token":",","temp":0.80,"mem_free":180000,"uptime_ms":2330} ... {"event":"done","reason":"eos"}

第二步，关闭 Arduino IDE 串口监视器，因为同一个串口不能被两个程序同时占用。然后在电脑终端中运行：

python observer.py

注意根据系统修改SERIAL_PORT，Windows 通常是COM3，Linux 通常是/dev/ttyUSB0。如果运行正常，你会在终端中看到：

Brainscope observer started. Waiting for ESP32 logs... [init] model=demo-llm device=esp32 [token 00] 2.05s temp=0.80 mem=180000 uptime=2030ms -> Hello [token 01] 2.35s temp=0.80 mem=180000 uptime=2330ms -> , [token 02] 2.65s temp=0.80 mem=180000 uptime=2630ms -> I ... [done] generation finished, reason=eos

4.5 结果说明

到这里，你就拥有了一个最小可用的“微控制器 LLM 思考观察器”。ESP32 模拟模型逐 token 生成内容，Python 脚本把每一步实时显示出来。虽然这里用的是token_stream固定数组，但整条数据链路已经完整：

• 采集：ESP32 端把每个 token 变为 JSON 事件。
• 传输：通过串口发生到上位机。
• 解析：Python 脚本按字段解析。
• 展示：终端可视化输出。

如果你后续接入了真实微型模型，只需要把sendTokenEvent里的token参数换成模型实际生成的 token，把温度换成模型推理参数，把内存换成真实堆内存即可。

为了让展示更丰富，你还可以用 Python 把日志写成 JSONL 文件：

with open("think_log.jsonl", "a", encoding="utf-8") as f: f.write(line + "\n")

这样后续可以回放分析，也可以导入到其他可视化工具中。

5. 常见问题与排查思路

在跑这个项目时，最容易遇到以下几类问题，这里按现象、原因和解决思路整理成表。

如果你在烧录过程中发现 Arduino IDE 下载库失败，或者开发板管理器安装 ESP32 支持包很慢，可以考虑使用离线安装包方式。把从可信渠道下载的 esp32 包解压到 Arduino 的hardware/espressif目录下，再重启 IDE，也能正常使用。

6. 最佳实践与工程建议

6.1 日志结构要稳定

一旦准备做模型推理可视化，建议从一开始就固定日志格式。字段名不要频繁变化，至少包含event、step、token、timestamp这几个核心字段。如果后续要接入真实仪表盘，最好使用统一的时间戳基准。

6.2 采样频率要克制

ESP32 的性能有限，如果每个 token 都输出大量字段，序列化耗时可能比推理本身还长。建议在两个位置做取舍：

• 字段层面：设备端只输出关键字段，完整的概率分布等数据可以用“按需开启”的方式在调试模式下输出。
• 频率层面：如果模型生成速度很快，可以每 N 个 token 输出一行摘要，避免串口成为瓶颈。

6.3 注意安全与隐私边界

当你把真实 prompt 和生成结果通过串口或 Wi-Fi 发送到上位机时，要注意这些内容可能包含隐私信息。如果设备部署在公开环境，不要明文输出用户输入；本地调试时也要避免把敏感数据写入长期保存的日志文件。串口本身没有加密能力，在非可信环境传输时需要考虑其他安全措施。

6.4 可维护性设计

建议将设备端代码拆成两部分：

• 模型推理模块：负责真实模型的前向计算，输出 token。
• 观测上报模块：负责把 token 包装成结构化日志，并通过串口发送。

这样当你从“模拟模型”切换到“真实模型”，只需要改动模型推理模块，观测上报代码完全复用。在 Arduino 项目中可以使用多个.h和.cpp文件管理，不要让所有逻辑都塞进一个.ino文件。

6.5 数据回放与自动化测试

日志不只是用于实时观察，也可以用于自动化验证。你可以把 JSONL 日志保存下来，在电脑上跑回归测试，检查指定 step 生成的 token 是否符合预期。如果更换模型或调整参数后，日志中 token 序列发生异常变化，就能快速定位问题。

7. 总结与学习路线

通过本文的实战，你已经掌握了一条完整的微控制器 LLM 观测链路：ESP32 端通过串口输出结构化 token 事件，Python 端实时解析并展示“模型思考”过程。这个链路看似简单，却是后续做端侧 AI 调试的重要基础。

下一步可以从三个方向继续深入：

1. 把模拟推理替换为真实微型模型。比如在 ESP32-S3 上尝试加载 int8/int4 量化的小型 Transformer，让监控脚本显示真实 token。
2. 把串口传输替换为 Wi-Fi。ESP32 本身支持无线通信，可以把日志通过 WebSocket 或 MQTT 发送到电脑或手机，实现远程观察。
3. 做更复杂的前端可视化。如果你熟悉 Web 开发，可以把 token 流渲染成对话气泡、把内存和耗时绘制成折线图，这就是一个完整的模型调试仪表盘。

最后提醒一句，端侧 LLM 的资源限制非常现实，不要期望在 ESP32 上跑出服务器级效果。先用监控链路把调试工具搭好，再逐步优化模型和内存，才是更稳的路线。如果这篇文章对你有帮助，可以收藏备用，也欢迎动手实践，用你自己的 token 流替换示例数组，观察“单片机思考”的过程。