这次我们来看一个非常有意思的嵌入式 + AI 项目：Brainscope 的 examples/ESP32 示例。简单说，它是一个让 ESP32 微控制器跑一个极小型 LLM，然后把模型推理过程实时可视化出来的开源示例。你可以在浏览器里看到单片机里的“大模型”每一步怎么选词、概率如何变化、当前在“想”什么。
这类项目最亮眼的地方不是模型能力，而是把 LLM 内部状态真正“拆开”给人看。过去我们调 LLM，通常只知道输入和输出，很难感知模型在解码时的概率分布变化。Brainscope 的 ESP32 示例把这件事落到了开发板上，非常适合嵌入式开发者、AI 入门者、以及想理解 LLM 推理过程的同学。本文会带大家完整梳理这个示例的硬件要求、环境搭建、烧录流程、可视化界面观察方式，以及常见问题和性能观察方法。
1. 核心能力速览
先给一张速览表，方便快速判断这个示例值不值得折腾。
| 能力项 | 说明 |
|---|---|
| 项目类型 | ESP32 嵌入式示例，结合微型 LLM 推理与 Brainscope 可视化调试工具 |
| 核心功能 | 在 ESP32 上运行微型语言模型，并通过可视化面板观察模型每一步的 Token 概率分布与生成过程 |
| 推荐硬件 | ESP32-S3 系列，建议选择带大容量 PSRAM 的型号，例如 N16R8（8MB PSRAM）或 N32R8 |
| 对普通 ESP32 的支持 | 经典 ESP32 也能编译运行部分示例，但 RAM 和 PSRAM 较小，需按实际模型文件评估，容易编译通过但运行时内存溢出 |
| 主要依赖 | Arduino IDE + ESP32 开发板包，或 PlatformIO，以及 Brainscope 工具链 |
| 启动方式 | 先编译烧录固件到 ESP32，再在浏览器打开可视化面板，需要保持设备通过串口或 WiFi 连接 |
| 是否支持 API 接口 | 示例本身不提供通用 REST API，更偏向实时观测；具体是否具备可编程接口需以仓库内示例代码为准 |
| 是否支持批量任务 | 不适用于传统批量任务；更合适的理解是持续观察多轮生成或连续 Token 决策 |
| 适合场景 | 学习 LLM 解码过程、嵌入式 AI 可视化教学、边缘端模型推理调试、创客项目展示 |
| 使用门槛 | 中等，需要一点 Arduino 开发基础，不需要服务器级 GPU |
这个示例把一个 8 位单片机变成“可观察的 LLM 大脑”，对理解自回归语言模型有很大帮助。最有价值的点在于：它把模型推理过程从黑盒变成白盒。
2. 这个示例解决什么问题：边缘端 LLM 可视化调试
在写环境准备之前，先理解项目定位非常有帮助。Brainscope 这个名字拆开来就是 “Brain” + “Scope”，可以理解为“大脑示波器”。它关注的是 LLM 内部状态，而不是模型最终输出的文本。
在 PC 上跑大模型，我们可以通过 OpenAI 兼容接口、LangChain 回调、TensorBoard 等方式记录日志，但都很难实时看到模型每一步在候选词上的概率分布。Brainscope 做的事情，就是把这种“内部状态观测”下沉到嵌入式设备上。ESP32 算力有限，跑不了 7B 模型，但示例通过量化极小型语言模型，可以在单片机级别完成前向推理。同时通过可视化面板，你可以清楚看到：
- 模型正在处理第几个 Token。
- 当前候选 Token 列表以及概率排序。
- 模型最终选择了哪个 Token。
- 温度、Top-K、Top-P 等采样参数如何影响选择结果。
- 生成整段文本时的“犹豫”过程。
这种可视化调试，对理解采样参数带来的影响极其直观。比如把温度调高，你能看到概率分布变平，模型开始“乱选”；温度调低，概率分布更尖锐，输出更保守。这些在 PC 大模型上也能调，但看不见分布变化，感知不强。在 ESP32 示例里，效果是实时呈现的，非常适合教学演示和科普。
同时，这个示例也给嵌入式 AI 提供了一种调试范式：在资源受限设备上跑模型，如果输出不稳定，过去只能加日志，现在可以通过可视化方式观察内部状态，定位问题效率高很多。
3. 环境准备与硬件选型
3.1 硬件要求
从项目示例的定位来看，它基于 ESP32 平台。考虑到 LLM 推理主要吃 RAM 和 PSRAM，所以硬件选型建议如下：
| 硬件 | 建议 | 说明 |
|---|---|---|
| 开发板 | ESP32-S3-DevKitC-1 或任意 ESP32-S3 开发板 | S3 系列主频更高，支持更大 PSRAM |
| 推荐型号 | ESP32-S3 N16R8（16MB Flash + 8MB PSRAM） | 8MB PSRAM 对微型 LLM 推理更从容 |
| 备选 | ESP32-S3 N8R2、ESP32-S3 N32R8 | R2（2MB PSRAM）偏小，可能需要进一步裁剪模型；N32 适合后续扩展 |
| 普通 ESP32 | 可尝试，但需关注编译内存和运行稳定性 | 经典 ESP32 的 PSRAM 版本可用，但总体资源偏紧 |
| 显示屏 | 可选，不必须 | 如果示例内置屏幕渲染逻辑，则需要参考仓库示例配置 |
| 数据线 | 高质量 USB 数据线 | 部分数据线只供电不能传数据，会导致烧录失败 |
这里要特别强调：不要随便拿一个 ESP32-DevKitC V4 就以为一定能跑。最小模型方案虽然可以做，但 LLM 推理需要相对大的连续内存区，PSRAM 小于 2MB 的设备很容易在运行时崩。
3.2 软件环境
软件层面必须准备以下内容：
| 软件 | 用途 | 版本建议 |
|---|---|---|
| Arduino IDE | 编译和烧录示例代码 | 推荐 2.x 版本及以上，界面更现代，依赖管理更方便 |
| ESP32 Arduino 开发板包 | 提供 ESP32-S3 编译工具链和核心库 | 最新稳定版，或使用离线安装包 |
| Brainscope 示例工程 | 项目源码 | 按仓库 README 拉取 |
| 浏览器 | 打开可视化面板 | Chrome / Edge 均可 |
如果是国内网络环境，Arduino 开发板管理器下载 esp32 包可能比较慢或失败，常见做法是：
- 配置开发板管理器地址。
- 通过离线安装包直接安装 esp32 包。
开发板地址一般为：
https://espressif.github.io/arduino-esp32/package_esp32_index.json在 Arduino IDE 的“文件 -> 首选项 -> 附加开发板管理器网址”中添加该地址，然后在“开发板管理器”中搜索 esp32 并安装。
如果下载失败，建议直接搜索“esp32 离线安装包”，按照对应 Arduino IDE 版本下载离线压缩包，手动放入 Arduino 的 hardware 目录解压，这也是社区里最常用的降级方案。
3.3 磁盘与端口
ESP32 示例编译通常只需要几百 MB 磁盘空间，不需要 GPU，不需要 CUDA。端口方面主要注意：
- 烧录时选择正确的 COM 口。
- 可视化面板一般基于串口或 WiFi 通信，需避免端口被其他串口监视器占用。
- 如果使用蓝牙进行数据传输，则需要留意 ESP32 经典蓝牙与 BLE 的配置差异。
4. 编译烧录 Brainscope ESP32 示例
4.1 拉取工程代码
先把示例工程拉取到本地。通用流程如下：
git clone https://github.com/Brainscope/brainscope.git cd brainscope/examples/esp32具体路径以实际仓库为准。拉取后建议先阅读项目 README，确认示例目录里是否包含模型文件、是否需要单独下载模型权重。
4.2 配置开发板
打开 Arduino IDE，选择开发板为 ESP32S3 Dev Module。
进入“工具”菜单，按以下建议配置：
| 配置项 | 推荐值 | 说明 |
|---|---|---|
| Board | ESP32S3 Dev Module | 选择对应芯片型号 |
| USB CDC On Boot | Enabled | 方便通过 USB 查看日志 |
| CPU Frequency | 240MHz | 除非示例要求，否则保持最高主频 |
| Flash Size | 16MB | 对应 N16R8 开发板 |
| PSRAM | OPI PSRAM | 8MB PSRAM 通常选择此项 |
| Partition Scheme | 根据示例要求选择 | 如果模型文件较大，选择 Huge APP 或自定义分区 |
这里特别提醒，Partition Scheme 如果不匹配，编译出来的固件可能超出分区大小，导致烧录后无法启动或者模型数据无法写入。如果示例文档指定了分区表，一定要改。
4.3 安装依赖库
在编译之前，需要安装示例依赖的 Arduino 库。通用方式是在 Arduino IDE 的“库管理器”中搜索安装。常见的依赖可能包括：
- WebServer 相关库（如果示例通过 WiFi 提供网页面板）。
- ArduinoJson（用于生成 JSON 格式的状态数据）。
- 模型推理库（示例自带或依赖特定推理引擎）。
如果示例目录下有libraries文件夹或platformio.ini，也可以直接使用 PlatformIO 方式构建，依赖管理会更省心。PlatformIO 示例配置示例如下：
[env:esp32-s3-devkitm-1] platform = espressif32 board = esp32-s3-devkitm-1 framework = arduino monitor_speed = 115200 board_build.flash_size = 16MB board_build.psram_type = opi4.4 编译和烧录
在 Arduino IDE 中点击编译，首次编译会下载工具链，时间会比较长。编译成功后，选择正确的 COM 口，然后点击烧录。
烧录过程中，如果遇到连接失败，尝试按住开发板上的 BOOT 键再点击烧录，很多 ESP32-S3 开发板需要手动进入下载模式。
烧录常见报错示例：
| 报错内容 | 处理方式 |
|---|---|
| A fatal error occurred: Failed to connect to ESP32-S3 | 按住 Boot 键重试，检查数据线是否支持数据传输 |
| Serial port COMx not found | 检查驱动是否安装，更换 USB 口 |
| Chip is ESP32-S3, wrong chip | 开发板型号选错，重新选择 ESP32S3 Dev Module |
| Flash write timeout | 降低波特率重试，或者检查供电不足 |
烧录完成后，打开串口监视器，波特率一般设置为 115200，观察设备是否正常打印日志。
5. 启动可视化：在浏览器里观察 LLM“思考”
5.1 启动方式
根据示例的通信方式，一般会有两种启动路径：
- 串口模式：ESP32 通过 USB 串口把 Token 概率数据发送到电脑，电脑端 Brainscope 面板接收并绘制。
- WiFi 模式：ESP32 连接局域网，浏览器直接访问开发板提供的网页，实时绘制概率分布。
如果示例默认使用 WiFi，则需要在代码里配置 WiFi SSID 和密码。示例代码中通常会有类似这样的部分：
const char* ssid = "your_wifi_ssid"; const char* password = "your_wifi_password";修改后重新编译烧录，然后在串口日志中查看分配给开发板的 IP 地址。浏览器打开该 IP 地址即可看到可视化面板。
如果默认走串口通信，则需要在电脑端启动 Brainscope 的面板程序。具体启动命令以项目 README 为准，但常见 Node.js 面板的启动方式是：
cd panel npm install npm start启动后浏览器访问http://127.0.0.1:3000或http://localhost:3000，具体端口以实际项目配置为准。
5.2 面板上能看什么
启动后，面板通常展示以下信息：
- 当前生成文本：逐字显示 LLM 已经生成的 Token 内容。
- Token 概率分布：每个候选 Token 的概率柱状图。
- 采样参数：温度、Top-K、Top-P 的实时数值。
- 生成状态：正在推理、采样、输出等。
- 模型信息：当前加载的模型名称、上下文长度等。
这个过程非常有趣。你可以在输入框给一个开头，比如“Once upon a time”，然后看着开发板上的微型 LLM 一个一个 Token 地生成后面的故事。每一个 Token 的选择过程都变成可视化的概率条，你能清楚看到模型在“the”和“a”之间可能产生微小犹豫，也能看到低概率 Token 被采样选中时模型输出的“跳跃感”。
5.3 判断可视化是否正常的标准
判断这个示例是否跑通，可以通过三条标准：
- 面板能够打开，并且能收到 ESP32 上传的数据。
- 输入提示词后，生成区开始逐字输出文本。
- 概率分布图随着每一步生成而刷新。
如果面板打不开，优先检查串口占用、WiFi 连接、防火墙设置；如果面板能开但没有数据，检查串口波特率是否匹配，WiFi 设备是否在同一个局域网。
6. 功能测试与效果观察
6.1 不同提示词测试
建议准备一组测试提示词，观察模型在指令型、开放型、重复型输入下的表现。
| 测试类型 | 输入示例 | 观察重点 |
|---|---|---|
| 开放续写 | The future of AI is | Token 概率分布是否平滑、连贯 |
| 简单问答 | What is ESP32? | 微型模型是否给出合理回答 |
| 重复模式 | hello hello hello | 模型是否开始重复，概率分布是否塌缩 |
| 中文输入 | 今天天气 | 模型是否支持中文词表，中文 Token 概率分布情况 |
| 符号输入 | 10 + 5 = | 看数值推理稳定性，一般微型模型较弱 |
这个用例的设计思路是：通过不同输入形态，观察模型在不同语境下的概率选择。如果模型在开放式续写中表现不错，但数值推理完全失败，这说明模型能力和关注点所在。
6.2 采样参数调节测试
采样参数是可视化中非常值得调整的变量。在面板中如果可以调节，尝试三组参数对比：
| 场景 | 温度 | Top-K | 预期表现 |
|---|---|---|---|
| 保守模式 | 0.2 | 10 | 输出稳定但可能重复 |
| 默认模式 | 0.7 | 50 | 平衡表达，视觉效果最好 |
| 发散模式 | 1.4 | 100 | 输出跳跃，概率分布明显变平 |
每次调整后，再看概率柱状图的变化。温度调高后，原本几乎为零概率的奇怪 Token 会被点亮，这就是温度对分布拉平作用的直观演示。这种观察比在 PC 上跑大模型再打印 log 直观得多。
6.3 显式观察 Token 选择过程
LLM 的本质是词汇表上的概率分布采样。Brainscope 面板把概率排序可视化之后，可以做几个很有意思的观察：
- 看第一个 Token 的选择：同样的开头是不是每次生成不一样。
- 看高概率 Token 和最终选择 Token 是否一致。
- 看低概率 Token 何时被选中：一般发生在温度较高时。
- 看上下文如何改变分布：同一个前缀后面跟不同上文，概率条变化明显。
这些观察对理解 LLM 的“随机性”非常有帮助。很多人以为 LLM 每次输出不同是因为“模型不固定”，实际上模型参数是固定的，变化来自采样过程。通过可视化概率分布，你能真正看到这种采样随机性。
6.4 长文本与连续生成
微型 LLM 的上下文窗口一般比较有限，可以尝试长时间连续生成，观察：
- 生成到多少 Token 后开始重复。
- 上下文窗口满了之后模型如何“遗忘”早期内容。
- 面板是否出现明显卡顿或数据延迟。
- 开发板温度和稳定性。
如果出现面板卡顿，优先怀疑串口数据量过大，或者浏览器渲染性能不够；降低刷新频率或者缩短上下文可以明显改善。
7. 资源占用与性能观察
7.1 内存占用观察方法
ESP32 上的内存分几种：
- Flash：存放固件和模型文件。
- SRAM：运行时的程序变量。
- PSRAM：扩展内存，主要用于模型权重和中间激活值。
编译时，Arduino IDE 会输出 Flash 和内存占用情况，这是第一步观察。示例启动后，还可以在串口日志中看到剩余堆内存、最大可分配块等信息。
推荐在代码中定期打印内存状态：
Serial.printf("Free heap: %d\n", ESP.getFreeHeap()); Serial.printf("Free PSRAM: %d\n", ESP.getFreePsram()); Serial.printf("Largest free block: %d\n", heap_caps_get_largest_free_block(MALLOC_CAP_8BIT));这样可以看到模型推理过程中内存的变化情况。如果 Free heap 持续下降，说明存在内存泄漏，需要检查推理代码是否反复申请内存但没有释放。
7.2 CPU 与推理速度
LLM 推理在 ESP32-S3 上属于重负载任务。240MHz 双核 MCU 跑微型模型，每个 Token 的生成时间可能是几十毫秒到几百毫秒级别。实际速度取决于模型大小、量化精度、上下文长度和 CPU 频率。
建议在实际测试中记录“每秒生成 Token 数”指标。如果太慢，可以考虑：
- 降低模型参数量或量化位数。
- 缩短上下文长度。
- 关闭其他占 CPU 的任务。
- 把双核任务分配调整成推理线程绑定到专用核心。
如果示例支持选择模型文件，优先尝试更小的量化模型，先把流程跑通再逐步升级模型大小。
7.3 降低资源占用的通用策略
| 策略 | 说明 |
|---|---|
| 使用量化模型 | 把浮点权重量化为 int8 或 int4，可以大幅降低 PSRAM 占用 |
| 减少上下文长度 | 控制输入 Token 数量，降低激活内存 |
| 关闭日志输出 | 在推理循环中减少串口打印，降低 CPU 消耗 |
| 降低刷新率 | 面板端降低数据刷新频率，减少上传带宽占用 |
| 升级 PSRAM | 如果开发板支持，选择 8MB 或更大 PSRAM 版本 |
| 裁剪词表 | 如果示例支持，减小词汇表可以降低输出层内存和计算量 |
7.4 功耗与散热
ESP32 在高负载 LLM 推理时，芯片功耗会明显上升，但一般不会过热。如果要长时间运行，建议：
- 避免把开发板放在封闭塑料盒中。
- 使用外部供电代替 USB 供电，确保电流稳定。
- 在串口日志中持续监控芯片温度。
Serial.printf("Temperature: %f\n", temperatureRead());温度持续超过 80 摄氏度时需要检查供电和散热。
8. 常见问题与排查方法
8.1 编译相关
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
编译报错找不到esp_llm.h | 依赖库未安装 | 检查库管理器安装情况 | 安装示例要求的推理库 |
| 编译报错 Flash 分区不够 | Partition Scheme 设置过小 | 查看编译日志中的分区表 | 切换到 Huge APP 分区或自定义分区 |
| 编译报错内存不足 | 模型文件过大或配置过高 | 查看编译输出中的内存统计 | 更换更小模型，减少上下文 |
| 下载 esp32 包失败 | 网络问题 | 检查下载日志 | 使用离线安装包 |
| 重复定义错误 | 示例库和已装库冲突 | 查看具体报错文件 | 卸载冲突库或修改库搜索顺序 |
8.2 烧录相关
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 无法连接开发板 | 驱动未装或数据线仅供电 | 查看设备管理器 | 更换数据线，安装驱动 |
| 烧录卡在等待开机同步 | 未进入下载模式 | 按住 Boot 键重试 | 手动进入下载模式 |
| 烧录后无串口日志 | 波特率不对 | 尝试 115200 或开发板默认速率 | 修改串口监视器波特率 |
| 串口日志乱码 | 波特率不匹配 | 检查代码和监视器波特率 | 统一波特率 |
8.3 运行与可视化相关
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 面板打不开 | WiFi 未连接或端口错误 | 查看串口日志中的 IP 和端口 | 重新配置 WiFi，检查防火墙 |
| 面板能开但无数据 | 串口被占用或协议不匹配 | 关闭其他串口监视器 | 释放串口，重启面板程序 |
| 生成文本全是乱码 | 模型词表和文本编码不匹配 | 查看面板日志 | 更换匹配的模型文件 |
| 运行一段时间后卡死 | 内存泄漏或任务栈溢出 | 查看崩溃日志和堆内存 | 增加任务栈大小，修复泄漏 |
| 概率分布不刷新 | 面板线程阻塞或数据格式错误 | 检查 ESP32 串口输出 | 查看数据帧是否符合预期 |
| 设备发热但不工作 | 电源供电不足 | 测量电流 | 更换稳定外部电源 |
8.4 模型相关
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 模型输出质量差 | 模型参数量太小 | 观察概率分布是否符合预期 | 换更大模型，调整提示词 |
| 中文支持差 | 词表中中文 Token 覆盖不足 | 查看词表文件 | 换中文模型或接受英文为主 |
| 上下文过短 | 示例配置限制 | 查看配置参数 | 有条件时扩大上下文长度 |
| 推理太慢 | 模型大、频率低 | 记录生成耗时 | 量化模型、提升主频 |
9. 最佳实践与使用边界
9.1 工程实践建议
如果是想把这个示例稳定跑起来，并且后续做二次开发，建议遵循以下流程：
- 第一次烧录使用默认配置，不要修改任何参数，确认环境 OK。
- 跑通后备份一份能运行的完整工程，包括库版本、开发板配置、分区表配置。
- 模型文件、代码、可视化面板分目录管理，不要全都堆在下载文件夹。
- 每次修改代码前记录修改点，方便回退。
- 使用 Git 管理自己的改动，不要直接改原始 examples 目录。
如果后续想扩展到自己的嵌入式 AI 项目，可以先在 ESP32-S3 上跑通一个最小模型，再逐步加功能。Brainscope 的价值不只是看演示，更重要的是它给出了一个“嵌入式模型内部状态观测”的参考实现，可以复用它的可视化面板来调试自己部署的模型。
9.2 适合与不适合的场景
适合：
- 想理解 LLM Token 采样过程的人。
- 做边缘端 AI 演示项目的创客。
- 嵌入式开发中需要观察模型状态的人。
- 教学场景中讲解自回归模型原理的老师。
不适合：
- 想把 ESP32 当生产级 LLM 服务器用的人。
- 需要高精度中文文本生成的人。
- 想跑大模型量化版的人，8MB PSRAM 跑大模型不现实。
- 完全没有 Arduino 基础，也不愿意折腾环境的人。
9.3 版权与使用边界
使用这个示例时，需要注意几个基本边界：
- 模型权重如果来自第三方仓库，需要确认开源协议是否允许商用、修改和重新分发。
- 如果模型是在别人的预训练权重基础上微调出来的，需要保留原项目版权声明。
- 示例代码如果采用开源协议，二次开发后发布时需要遵守对应协议。
- 如果你的应用要把生成内容用于公开场景，请审核模型输出，微型 LLM 生成内容质量有限，可能出现有害或不合适的内容。
从安全边界来说，这个项目本质是本地推理，不涉及云端数据回传，但如果示例代码里包含 WiFi 连接功能，需要确认固件不会向未知服务器上传数据，建议在本地网络环境中试验，不要把开发板直接暴露到公网。如果你要扩展成一个带 Web 面板的服务，必须加访问认证，避免局域网内任意设备直接控制开发板。
9.4 固件与数据管理建议
在长时间运行或反复测试时，建议做以下操作：
- 多次烧录前执行擦除 Flash，避免旧配置残留。
- 串口日志定期保存到文件，方便回溯崩溃原因。
- 当面板数据延迟高时，降低串口输出频率。
- 每次换模型后记录模型大小、显存（内存）占用和生成速度，形成对照表。
这里可以做一张实用统计表：
| 模型文件 | 内存占用 | 生成速度 Token/s | 文本质量 | 备注 |
|---|---|---|---|---|
| 默认模型 | 待实测 | 待实测 | 中等 | 推荐先跑通 |
| 更小量化模型 | 待实测 | 待实测 | 稍差 | 用于极限降配 |
| 更大模型 | 待实测 | 待实测 | 更好 | 需要更大 PSRAM |
这种表格在你后续换模型、调参数时非常有参考价值。
10. 扩展思路与下一步
这个示例跑通之后，可以继续往几个方向扩展：
10.1 接入自己的提示词系统
Brainscope 可视化面板可以通过串口和 WiFi 接收数据，如果自己写一个上位机，把任意 LLM 推理引擎的输出格式统一成 Brainscope 协议，就能在 PC 上观察更大模型的概率分布。这是一种很好的二次开发方向。
10.2 扩展更多传感器输入
既然 ESP32 能跑微型 LLM，还能观察推理状态，那么可以尝试把传感器读数作为输入，做成温度预测、动作分类等小型边缘 AI 应用，并用 Brainscope 实时观察状态变化。这就从“看 LLM 思考”扩展到了“看嵌入式模型预测”。
10.3 对比不同模型和采样策略
利用可视化面板，可以做实验对比：
- 不同量化精度的模型。
- 不同上下文长度。
- 不同采样器。
- 不同温度参数。
- 不同 prompt 模板。
这些实验结果都可以导出成 Token 概率分布图，作为学习笔记或教学材料。
10.4 结合 PC 端大模型
ESP32 上跑微型模型更多是验证和教学，要获得更好的生成效果，可以做成混合结构：ESP32 负责传感器采集和系统控制，PC 端跑大模型，通过串口/网络把结果回传。Brainscope 的可视化思路可以继续用在 PC 端模型观察上。
这个示例给嵌入式 AI 调试提供了一个非常直观的新工具。首先要验证的是能不能顺利烧录并打开面板；最容易踩的坑是硬件选型不对、库安装不全、分区表配置错误；一旦跑通，建议优先做温度参数调节实验，看完概率分布变化，你对 LLM 采样的理解会上一个台阶。建议把这篇文章收藏备用，后面折腾 Brainscope 或 ESP32 AI 项目时可以直接照着做。
